Goto es una declaración que se encuentra en muchos lenguajes de programación informática . Realiza una transferencia unidireccional de control a otra línea de código; en contraste, una llamada a una función normalmente devuelve el control. Las ubicaciones a las que se salta normalmente se identifican mediante etiquetas , aunque algunos lenguajes utilizan números de línea . A nivel de código de máquina , una goto
es una forma de declaración de salto o ramificación , en algunos casos combinada con un ajuste de pila. Muchos lenguajes admiten la goto
declaración y muchos no (consulte § compatibilidad de lenguajes).
El teorema del programa estructurado demostró que la goto
afirmación no es necesaria para escribir programas que puedan expresarse como diagramas de flujo ; alguna combinación de las tres construcciones de programación de secuencia, selección/elección y repetición/iteración es suficiente para cualquier cálculo que pueda ser realizado por una máquina de Turing , con la salvedad de que puede ser necesario introducir duplicación de código y variables adicionales. [1]
El uso de goto era común en el pasado, pero desde la llegada de la programación estructurada en los años 1960 y 1970, su uso ha disminuido significativamente. Sigue utilizándose en ciertos patrones de uso comunes, pero generalmente se utilizan alternativas si están disponibles. En el pasado, hubo un debate considerable en el ámbito académico y en la industria sobre los méritos del uso de las instrucciones goto. La principal crítica es que el código que utiliza instrucciones goto es más difícil de entender que las construcciones alternativas. Los debates sobre sus usos (más limitados) continúan en los círculos académicos y de la industria del software.
goto label
La goto
declaración a menudo se combina con la declaración if para provocar una transferencia condicional de control.
IF condition THEN goto label
Los lenguajes de programación imponen distintas restricciones con respecto al destino de una goto
instrucción. Por ejemplo, el lenguaje de programación C no permite un salto a una etiqueta contenida dentro de otra función, [2] sin embargo, los saltos dentro de una sola cadena de llamadas son posibles utilizando las funciones setjmp/longjmp .
En la reunión previa a ALGOL celebrada en 1959, Heinz Zemanek puso en duda explícitamente la necesidad de las sentencias GOTO; en ese momento nadie [ cita requerida ] prestó atención a su observación, incluido Edsger W. Dijkstra , quien más tarde se convirtió en el oponente icónico de GOTO. [3] Las décadas de 1970 y 1980 vieron un declive en el uso de sentencias GOTO a favor del paradigma de programación estructurada , con GOTO criticado por conducir a un código espagueti inmantenible . Algunos estándares de codificación de estilo de programación , por ejemplo, los Estándares de codificación GNU Pascal, recomiendan no usar sentencias GOTO. [4] La prueba de Böhm-Jacopini (1966) no resolvió la cuestión de si adoptar la programación estructurada para el desarrollo de software, en parte porque la construcción tenía más probabilidades de oscurecer un programa que de mejorarlo porque su aplicación requiere la introducción de variables locales adicionales. [5] Sin embargo, desencadenó un importante debate entre científicos informáticos, educadores, diseñadores de lenguajes y programadores de aplicaciones que vieron un cambio lento pero constante en el uso antes omnipresente de GOTO. Probablemente la crítica más famosa de GOTO es una carta de 1968 de Edsger Dijkstra llamada " Declaración Go-to considerada dañina ". [3] En esa carta, Dijkstra argumentó que las declaraciones GOTO sin restricciones deberían abolirse de los lenguajes de alto nivel porque complicaban la tarea de analizar y verificar la corrección de los programas (en particular aquellos que involucraban bucles). [6] La carta en sí desencadenó un debate, incluida una carta ""GOTO considerado dañino" considerado dañino" [7] enviada a Comunicaciones de la ACM (CACM) en marzo de 1987, así como otras respuestas de otras personas, incluida la de Dijkstra en Sobre una correspondencia algo decepcionante . [8]
Un punto de vista alternativo se presenta en Structured Programming with go to Statements de Donald Knuth , que analiza muchas tareas de programación comunes y descubre que en algunas de ellas GOTO es la construcción de lenguaje óptima para usar. [9] En The C Programming Language , Brian Kernighan y Dennis Ritchie advierten que es "infinitamente abusable", pero también sugieren que podría usarse para manejadores de errores de fin de función y para cortes de múltiples niveles de bucles. [10] Estos dos patrones se pueden encontrar en numerosos libros posteriores sobre C de otros autores; [11] [12] [13] [14] un libro de texto introductorio de 2007 señala que el patrón de manejo de errores es una forma de evitar la "falta de manejo de excepciones incorporado dentro del lenguaje C". [11] Otros programadores, incluido el diseñador y codificador del kernel de Linux Linus Torvalds o el ingeniero de software y autor de libros Steve McConnell , también se oponen al punto de vista de Dijkstra, afirmando que los GOTO pueden ser una característica útil del lenguaje, mejorando la velocidad del programa, el tamaño y la claridad del código, pero solo cuando se usan de manera sensata por un programador comparativamente sensato. [15] [16] Según el profesor de informática John Regehr , en 2013, había alrededor de 100.000 instancias de goto en el código del kernel de Linux. [17]goto
Otros académicos adoptaron un punto de vista más extremo y argumentaron que incluso instrucciones como break
y return
desde el medio de los bucles son una mala práctica, ya que no son necesarias en el resultado de Böhm-Jacopini, y por lo tanto defendieron que los bucles deberían tener un único punto de salida. [18] Por ejemplo, Bertrand Meyer escribió en su libro de texto de 2009 que instrucciones como break
y continue
"son simplemente las viejas goto
con piel de oveja". [19] Sin embargo, una forma ligeramente modificada del resultado de Böhm-Jacopini permite evitar variables adicionales en la programación estructurada, siempre que se permitan cortes de varios niveles de los bucles. [20] Debido a que algunos lenguajes como C no permiten cortes de varios niveles a través de su break
palabra clave, algunos libros de texto recomiendan al programador que utilice goto
en tales circunstancias. [14] El estándar MISRA C 2004 prohíbe goto
, continue
, así como múltiples declaraciones return
y break
. [21] La edición 2012 del estándar MISRA C degradó la prohibición goto
de "requerida" a "consultiva"; la edición 2012 tiene una regla adicional obligatoria que prohíbe solo los saltos hacia atrás, pero no hacia adelante con goto
. [22] [23]
FORTRAN introdujo construcciones de programación estructurada en 1978, y en revisiones sucesivas las reglas semánticas relativamente laxas que regulaban el uso permitido de goto se hicieron más estrictas; el "rango extendido" en el que un programador podía usar un GOTO para salir y volver a entrar en un bucle DO que aún se estaba ejecutando se eliminó del lenguaje en 1978, [24] y para 1995 se habían eliminado varias formas de Fortran GOTO, incluyendo el GOTO calculado y el GOTO asignado. [25] Algunos lenguajes de programación modernos ampliamente utilizados como Java y Python carecen de la declaración GOTO (ver soporte de lenguaje), aunque la mayoría proporciona algún medio para salir de una selección, o bien para salir o pasar al siguiente paso de una iteración. El punto de vista de que alterar el flujo de control en el código es indeseable se puede ver en el diseño de algunos lenguajes de programación, por ejemplo, Ada [26] enfatiza visualmente las definiciones de etiquetas utilizando corchetes angulares .
La entrada 17.10 en la lista de preguntas frecuentes de comp.lang.c [27] aborda el problema del uso de GOTO directamente, indicando
El estilo de programación, al igual que el estilo de escritura, es algo así como un arte y no se puede codificar mediante reglas inflexibles, aunque las discusiones sobre el estilo a menudo parecen centrarse exclusivamente en torno a dichas reglas. En el caso de la sentencia goto, se ha observado durante mucho tiempo que el uso sin restricciones de goto conduce rápidamente a un código espagueti inmantenible. Sin embargo, una prohibición simple e irreflexiva de la sentencia goto no conduce necesariamente de inmediato a una programación hermosa: un programador no estructurado es igualmente capaz de construir una maraña bizantina sin utilizar ninguna sentencia goto (quizás sustituyendo bucles anidados de forma extraña y variables de control booleanas, en su lugar). Muchos programadores adoptan una postura moderada: las sentencias goto suelen evitarse, pero son aceptables en unas pocas situaciones bien restringidas, si es necesario: como sentencias break de varios niveles, para fusionar acciones comunes dentro de una sentencia switch o para centralizar tareas de limpieza en una función con varios retornos de error. (...) Evitar ciegamente ciertas construcciones o seguir reglas sin comprenderlas puede conducir a tantos problemas como los que se supone que las reglas deben evitar. Además, muchas opiniones sobre el estilo de programación son sólo eso: opiniones. Pueden estar fuertemente argumentadas y sentidas, pueden estar respaldadas por evidencias y argumentos aparentemente sólidos, pero las opiniones opuestas pueden estar igualmente fuertemente sentidas, apoyadas y argumentadas. Por lo general, es inútil involucrarse en "guerras de estilos", porque en ciertas cuestiones, los oponentes nunca parecen estar de acuerdo, o acordar estar en desacuerdo, o dejar de discutir.
Si bien el uso general de goto ha ido disminuyendo, aún existen situaciones en algunos lenguajes en las que un goto proporciona la forma más corta y directa de expresar la lógica de un programa (si bien es posible expresar la misma lógica sin gotos, el código equivalente será más largo y, a menudo, más difícil de entender). En otros lenguajes, existen alternativas estructuradas, en particular excepciones y llamadas finales.
Las situaciones en las que goto suele ser útil incluyen:
Estos usos son relativamente comunes en C, pero mucho menos comunes en C++ u otros lenguajes con características de nivel superior. [34] Sin embargo, lanzar y capturar una excepción dentro de una función puede ser extraordinariamente ineficiente en algunos lenguajes; un buen ejemplo es Objective-C , donde un goto es una alternativa mucho más rápida. [37]
Otro uso de las sentencias goto es modificar código heredado mal factorizado , donde evitar un goto requeriría una refactorización extensa o duplicación de código . Por ejemplo, dada una función grande donde solo cierto código es de interés, una sentencia goto permite saltar hacia o desde solo el código relevante, sin modificar de otra manera la función. Este uso se considera un error de código [38] , pero se usa ocasionalmente.
La noción moderna de subrutina fue inventada por David Wheeler cuando programó el EDSAC . Para implementar una llamada y un retorno en una máquina sin una instrucción de llamada de subrutina, utilizó un patrón especial de código automodificable, conocido como salto de Wheeler . [39] Esto dio como resultado la capacidad de estructurar programas utilizando ejecuciones bien anidadas de rutinas extraídas de una biblioteca. Esto no habría sido posible utilizando solo goto
, ya que el código de destino, al ser extraído de la biblioteca, no sabría a dónde volver a saltar.
Más tarde, se diseñaron lenguajes de alto nivel como Pascal en torno al soporte de la programación estructurada , que se generalizó desde subrutinas (también conocidas como procedimientos o funciones) hacia otras estructuras de control como:
while
, repeat until
odo
, yforswitch
También conocidas como case
declaraciones, una forma de ramificación multidireccional.Estos nuevos mecanismos de lenguaje reemplazaron flujos equivalentes que antes se habrían escrito utilizando goto
s y if
s. La ramificación multidireccional reemplaza el "goto calculado" en el que la instrucción a la que se debe saltar se determina dinámicamente (condicionalmente).
Bajo ciertas condiciones, es posible eliminar las declaraciones goto locales de programas heredados reemplazándolas con declaraciones de salida de bucle multinivel. [40]
En la práctica, una estricta adherencia a la plantilla básica de tres estructuras de la programación estructurada produce un código altamente anidado, debido a la incapacidad de salir prematuramente de una unidad estructurada, y una explosión combinatoria con datos de estado del programa bastante complejos para manejar todas las condiciones posibles.
En general, se han adoptado dos soluciones: una forma de salir de una unidad estructurada de forma prematura y, de forma más general, excepciones : en ambos casos, estas suben por la estructura y devuelven el control a los bloques o funciones que las contienen, pero no saltan a ubicaciones de código arbitrarias. Estas son análogas al uso de una sentencia return en una posición no terminal: no estrictamente estructurada, debido a la salida temprana, sino una relajación leve de las restricciones de la programación estructurada. En C, break
y continue
permiten terminar un bucle o continuar con la siguiente iteración , sin requerir una sentencia while
or adicional if
. En algunos lenguajes, también son posibles los cortes de varios niveles. Para manejar situaciones excepcionales, se agregaron construcciones especializadas de manejo de excepciones , como try
/ catch
/ finally
en Java.
Los mecanismos de manejo de excepciones throw-catch también pueden ser fácilmente abusados para crear estructuras de control no transparentes, al igual que se puede abusar de goto. [41]
En un artículo presentado en la conferencia ACM en Seattle en 1977, Guy L. Steele resumió el debate sobre GOTO y la programación estructurada, y observó que las llamadas a procedimientos en la posición de cola de un procedimiento pueden tratarse de manera más óptima como una transferencia directa de control al procedimiento llamado, eliminando típicamente operaciones de manipulación de pila innecesarias. [42] Dado que estas "llamadas de cola" son muy comunes en Lisp , un lenguaje donde las llamadas a procedimientos son ubicuas, esta forma de optimización reduce considerablemente el costo de una llamada a procedimiento en comparación con el GOTO utilizado en otros lenguajes. Steele argumentó que las llamadas a procedimientos mal implementadas habían llevado a una percepción artificial de que el GOTO era barato en comparación con la llamada a procedimiento. Steele argumentó además que "en general, las llamadas a procedimientos pueden considerarse de manera útil como instrucciones GOTO que también pasan parámetros y pueden codificarse uniformemente como instrucciones JUMP de código de máquina ", con las instrucciones de manipulación de pila de código de máquina "consideradas una optimización (¡en lugar de al revés!)". [42] Steele citó evidencia de que los algoritmos numéricos bien optimizados en Lisp podían ejecutarse más rápido que el código producido por los compiladores Fortran comerciales disponibles en ese momento porque el costo de una llamada a un procedimiento en Lisp era mucho menor. En Scheme , un dialecto de Lisp desarrollado por Steele con Gerald Jay Sussman , la optimización de la llamada de cola es obligatoria. [43]
Aunque el artículo de Steele no introdujo muchas novedades en la ciencia informática, al menos tal como se practicaba en el MIT, sacó a la luz el alcance de la optimización de las llamadas a procedimientos, lo que convirtió las cualidades de promoción de la modularidad de los procedimientos en una alternativa más creíble a los hábitos de codificación entonces comunes de los grandes procedimientos monolíticos con estructuras de control interno complejas y datos de estado extensos. En particular, las optimizaciones de llamadas de cola discutidas por Steele convirtieron el procedimiento en una forma creíble de implementar la iteración a través de la recursión de cola única (recursión de cola que llama a la misma función). Además, la optimización de llamadas de cola permite la recursión mutua de profundidad ilimitada, suponiendo llamadas de cola; esto permite la transferencia de control, como en las máquinas de estados finitos , que de lo contrario generalmente se logra con instrucciones goto.
Las corrutinas son una relajación más radical de la programación estructurada, permitiendo no solo múltiples puntos de salida (como retornos en posición no de cola), sino también múltiples puntos de entrada, similares a las declaraciones goto. Las corrutinas son más restringidas que goto, ya que solo pueden reanudar una corrutina que se esté ejecutando actualmente en puntos específicos (continuando después de un yield) en lugar de saltar a un punto arbitrario en el código. Una forma limitada de corrutinas son los generadores , que son suficientes para algunos propósitos. Aún más limitados son los cierres : subrutinas que mantienen el estado (a través de variables estáticas ), pero no la posición de ejecución. Una combinación de variables de estado y control estructurado, en particular una declaración switch general, puede permitir que una subrutina reanude la ejecución en un punto arbitrario en llamadas posteriores, y es una alternativa estructurada a las declaraciones goto en ausencia de corrutinas; este es un modismo común en C, por ejemplo.
Una continuación es similar a un GOTO en el sentido de que transfiere el control desde un punto arbitrario en el programa a un punto marcado previamente. Una continuación es más flexible que GOTO en aquellos lenguajes que la admiten, porque puede transferir el control fuera de la función actual, algo que un GOTO no puede hacer en la mayoría de los lenguajes de programación estructurada. En aquellas implementaciones de lenguaje que mantienen marcos de pila para el almacenamiento de variables locales y argumentos de funciones, ejecutar una continuación implica ajustar la pila de llamadas del programa además de un salto. La función longjmp del lenguaje de programación C es un ejemplo de una continuación de escape que se puede utilizar para escapar del contexto actual a uno circundante. El operador GO de Common Lisp también tiene esta propiedad de desenrollado de pila, a pesar de que la construcción tiene un alcance léxico , ya que la etiqueta a la que se saltará puede referenciarse desde un cierre .
En Scheme , las continuaciones pueden incluso mover el control de un contexto externo a uno interno si se desea. Este control casi ilimitado sobre qué código se ejecuta a continuación hace que las estructuras de control complejas, como las corrutinas y la multitarea cooperativa, sean relativamente fáciles de escribir. [43]
En los paradigmas no procedimentales, goto es menos relevante o completamente ausente. Una de las principales alternativas es el paso de mensajes , que es de particular importancia en computación concurrente , comunicación entre procesos y programación orientada a objetos . En estos casos, los componentes individuales no tienen una transferencia arbitraria de control, sino que el control general puede programarse de formas complejas, como por ejemplo a través de la preempción . Los influyentes lenguajes Simula y Smalltalk fueron de los primeros en introducir los conceptos de mensajes y objetos. Al encapsular los datos de estado, la programación orientada a objetos redujo la complejidad del software a las interacciones (mensajes) entre objetos.
Hay varias construcciones de lenguaje diferentes bajo la clase de declaraciones goto .
En Fortran , un salto calculadoGOTO
salta a una de varias etiquetas en una lista, en función del valor de una expresión. Un ejemplo es goto (20,30,40) i
. [44] La construcción equivalente en C es la sentencia switch , y en Fortran más reciente la SELECT CASE
construcción a es la alternativa sintáctica recomendada. [45] BASIC tenía una 'On GoTo'
sentencia que lograba el mismo objetivo, pero en Visual Basic esta construcción ya no se admite. [46]
En versiones anteriores a Fortran 95, Fortran también tenía una variante goto asignada que transfiere el control a una etiqueta de declaración (número de línea) que se almacena en (asignada a) una variable entera. Saltar a una variable entera que no había sido ASIGNADA era, lamentablemente, posible, y era una fuente importante de errores relacionados con gotos asignados. [47] La declaración Fortran assign
solo permite que se asigne un número de línea constante (existente) a la variable entera. Sin embargo, algunos compiladores permitían tratar accidentalmente esta variable como un entero a partir de entonces, por ejemplo, incrementarla, lo que resultaba en un comportamiento no especificado en goto
ese momento. El siguiente código demuestra el comportamiento de goto i
cuando la línea i no está especificada:
asignar 200 a i i = i + 1 ir a i ! comportamiento no especificado 200 escribir ( * , * ) "este es un número de línea válido"
Varios compiladores de C implementan dos extensiones no estándar de C/C++ relacionadas con gotos introducidos originalmente por gcc . [48] La extensión GNU permite que la dirección de una etiqueta dentro de la función actual se obtenga como un operador de valor de etiquetavoid*
de prefijo unario . La instrucción goto también se extiende para permitir saltar a una expresión arbitraria . Esta extensión de C se conoce como goto calculado en la documentación de los compiladores de C que la admiten; su semántica es un superconjunto del goto asignado de Fortran, porque permite expresiones de puntero arbitrarias como el objetivo del goto, mientras que el goto asignado de Fortran no permite expresiones arbitrarias como objetivo de salto. [49] Al igual que con el goto estándar en C, la extensión GNU C permite que el objetivo del goto calculado resida solo en la función actual. Intentar saltar fuera de la función actual da como resultado un comportamiento no especificado. [49] &&
void*
Algunas variantes de BASIC también admiten un GOTO calculado en el sentido utilizado en GNU C, es decir, en el que el objetivo puede ser cualquier número de línea, no sólo uno de una lista. Por ejemplo, en MTS BASIC se podría escribir GOTO i*1000
para saltar a la línea numerada 1000 veces el valor de una variable i (que podría representar una opción de menú seleccionada, por ejemplo). [50]
Las variables de etiqueta PL/I logran el efecto de GOTO
s calculadas o asignadas.
Hasta el estándar ANSI COBOL de 1985 existía la declaración ALTER, que podía utilizarse para cambiar el destino de un GO TO existente, que tenía que estar en un párrafo por sí solo. [51] La característica, que permitía el polimorfismo , era frecuentemente condenada y rara vez utilizada. [52]
En Perl , existe una variante de la goto
instrucción que no es una instrucción GOTO tradicional en absoluto. Toma un nombre de función y transfiere el control sustituyendo efectivamente una llamada de función por otra (una llamada de cola ): la nueva función no regresará a la instrucción GOTO, sino al lugar desde el que se llamó a la función original. [53]
Existen varios lenguajes de programación que no admiten GOTO de forma predeterminada. Si se utiliza la emulación GOTO, aún es posible utilizar GOTO en estos lenguajes de programación, aunque con algunas restricciones. Se puede emular GOTO en Java, [54] JavaScript, [55] y Python. [56] [57]
PL/I tiene el tipo de datos LABEL , que se puede utilizar para implementar tanto el "goto asignado" como el "goto calculado". PL/I permite ramificaciones fuera del bloque actual. Un procedimiento que llama puede pasar una etiqueta como argumento a un procedimiento llamado que luego puede salir con una ramificación. El valor de una variable de etiqueta incluye la dirección de un marco de pila, y un goto fuera del bloque hace que la pila salga de la pila.
/* Esto implementa el equivalente de */ /* el goto asignado */ declarar donde está la etiqueta; donde = en algún lugar; ir a donde; ... en algún lugar: /* declaración */ ; ...
/* Esto implementa el equivalente de */ /* el goto calculado */ declarar dónde (5) etiqueta; declarar inx fijo; donde(1) = abc; donde (2) = xyz; ... ir a donde(inx); ... abc: /* declaración */ ; ... xyz: /* declaración */ ; ...
Una forma más sencilla de obtener un resultado equivalente es utilizar una matriz de constantes de etiqueta que ni siquiera necesita una declaración explícita de una variable de tipo LABEL :
/* Esto implementa el equivalente de */ /* el goto calculado */ declarar inx fijo; ... ir a donde(inx); ... donde(1): /* declaración */ ; ... donde(2): /* declaración */ ; ...
En un archivo por lotes de DOS , Goto dirige la ejecución a una etiqueta que comienza con dos puntos. El destino de Goto puede ser una variable.
@ echo off ESTABLECER D8str = %date% ESTABLECER D8dow = %D8str:~0,3%PARA %% D en ( lunes mié vie ) hacer si " %% D" == " %D8dow% " goto SHOP%%D echo Hoy, %D8dow% , no es un día de compras. goto end: SHOPMon echo compra pizza para el almuerzo - El lunes es el día de la pizza. ir al final: SHOPWed echo comprar Calzone para llevar a casa - hoy es miércoles. ir al final: SHOPFri echo comprar Seltzer en caso de que alguien quiera una bebida sin calorías. : fin
Muchos lenguajes soportan la goto
declaración, y muchos no. En Java , goto
es una palabra reservada , pero no se puede usar, aunque .class
los archivos compilados generan GOTO y LABEL. [58] Python no tiene soporte para goto, aunque hay varios módulos de broma que lo proporcionan. [56] [57] No hay una declaración goto en Seed7 y los gotos ocultos como las declaraciones break y continue también se omiten. [59] En PHP no hubo soporte nativo para goto
hasta la versión 5.3 (había bibliotecas disponibles para emular su funcionalidad). [60]
Tanto C# como Visual Basic .NET admiten goto
. [61] [62] Sin embargo, no permite saltar a una etiqueta fuera del ámbito actual y respeta la eliminación de objetos y las construcciones finally, lo que lo hace significativamente menos poderoso y peligroso que la goto
palabra clave en otros lenguajes de programación. También hace que las etiquetas de las declaraciones case y default , cuyo ámbito es la declaración switch que las encierra ; goto case o goto default se usa a menudo como un reemplazo explícito para el fallthrough implícito, que C# no permite.
El lenguaje de programación PL/I tiene una declaración GOTO que desenrolla la pila para una transferencia fuera del bloque y no permite una transferencia a un bloque desde fuera del mismo.
Otros lenguajes pueden tener sus propias palabras clave para los fallthroughs explícitos, que pueden considerarse una versión goto
restringida a este propósito específico. Por ejemplo, Go usa la fallthrough
palabra clave y no permite fallthroughs implícitos en absoluto, [63] mientras que Perl 5 usa next
fallthroughs explícitos de manera predeterminada, pero también permite configurar fallthroughs implícitos como comportamiento predeterminado para un módulo.
La mayoría de los lenguajes que tienen instrucciones goto las llaman así, pero en los primeros tiempos de la informática se utilizaban otros nombres. Por ejemplo, en MAD se utilizaba la instrucción TRANSFER TO. [64] APL utiliza una flecha que apunta hacia la derecha →
para goto.
C tiene goto, y se usa comúnmente en varios modismos, como se mencionó anteriormente.
Los lenguajes de programación funcional como Scheme generalmente no tienen goto, en su lugar utilizan continuaciones.
{{cite web}}
: CS1 maint: nombres numéricos: lista de autores ( enlace ){{cite web}}
: CS1 maint: URL no apta ( enlace )(a veces llamado WWG , por las iniciales de sus autores) fue el primer libro sobre programación de computadoras.
Este documento describe la sintaxis, la semántica y la implementación de IBM z/OS XL C/C++ de los lenguajes de programación C y C++. Para obtener una referencia estándar de C o C++ de uso general, consulte cppreference.com.
{{cite web}}
: CS1 maint: nombres numéricos: lista de autores ( enlace )