stringtranslate.com

Discusión:Lisp (lenguaje de programación)

Las "citas necesarias" aleatorias no son

Hay varios lugares donde alguien ha puesto la anotación [cita requerida], pero es sólo una característica del lenguaje que se está describiendo. Por ejemplo, que los símbolos pueden aparecer en más de un lugar, pero hacer referencia al mismo objeto. Afirmo que el ejemplo, por ejemplo, no necesita citación. Cualquiera de las referencias del lenguaje lo respaldará (como lo hará cualquiera que conozca Lisp). Yo mismo eliminaría las tontas, pero no soy un wikipedista y no sé cómo o qué es el protocolo. —Comentario anterior sin firmar añadido por 75.198.239.200 (discusión) 08:24, 21 de enero de 2009 (UTC) [ responder ]

Hola, el protocolo es WP:BOLD y simplemente hacerlo. -- MarSch ( discusión ) 17:13 22 ene 2009 (UTC) [ responder ]

Licencia

Propietario o no - Melab -1 21:12, 4 de septiembre de 2008 (UTC) [ responder ]

Algunas implementaciones de algunos Lisp lo son, otras no. -- MarSch ( discusión ) 17:17 22 ene 2009 (UTC) [ responder ]

Manual de Qi

Las páginas 18 a 31 del manual de Qi [1] contienen una buena explicación de la historia de Lisp en términos de la creación de un RS para discutir el por qué sucedieron varias cosas. jbolden1517 Talk 15:40, 12 de abril de 2009 (UTC) [ responder ]

Le eché un vistazo a este libro. Aunque supongo que es una historia resumida aceptable para un libro introductorio a la informática, no es muy buena como historia. Además de ignorar todo el trabajo sobre los primeros lenguajes de programación distintos de Lisp, también hace la afirmación completamente incorrecta de que fueron las máquinas Lisp las que introdujeron las ventanas, los ratones de ordenador y la informática personal. Y simplemente por razones técnicas (es autopublicado por alguien que no es un experto publicado en la historia de los lenguajes de ordenador), no cumple los criterios de WP:RS . -- macrakis ( discusión ) 20:39, 12 de abril de 2009 (UTC) [ responder ]
Vale, gracias por tomarte el tiempo de considerarlo. También me parecieron extrañas las afirmaciones sobre el uso de ventanas, pero no estaba seguro, ya que Smalltalk sí las tenía (varios años después) y esas dos comunidades eran amistosas... Pero si esa afirmación es errónea, entonces no hay razón para respaldar la historia de los aspectos de LISP. jbolden1517 Talk 21:15, 12 de abril de 2009 (UTC) [ responder ]

Influenciado

La lista de "influenciados" se está haciendo bastante larga y vaga. Algunas de estas no están confirmadas ni en el artículo sobre el lenguaje al que se hace referencia ni en la cronología de los lenguajes de programación . Creo que la lista debería restringirse a los lenguajes cuya influencia principal fue Lisp, en los que Lisp fue mencionado específicamente como una influencia principal por el diseñador o los diseñadores del lenguaje. De lo contrario, podemos terminar con una lista que contenga casi todos los lenguajes posteriores a Lisp, lo que no es muy útil. Yworo ( discusión ) 15:27 2 ago 2009 (UTC) [ responder ]

Bueno, hay muchos lenguajes que están influenciados por Lisp, y no es de extrañar, ya que Lisp tiene 50 años y muchos dialectos. ML se implementó por primera vez en Lisp, Perl menciona a Lisp como una influencia, Python menciona a Lisp, Smalltalk menciona a Lisp, Ruby menciona a Lisp, Dylan menciona a Lisp, Mathematica no menciona a Lisp pero está influenciada por él (Wolfram implementó una versión anterior, SMP, en Lisp), Rebol menciona a Lisp, Qi está implementado en Lisp, Lua menciona a Lisp, Javascript menciona a Scheme, Forth menciona a Lisp, Nu menciona a Lisp, ...

Hay muchos lenguajes que no están o están muy poco influenciados por Lisp: C, C++, Ada, Oberon, Modula 2, Pascal, Visual Basic, C#, PHP, D, etc.

Joswig ( discusión ) 23:34 6 dic 2009 (UTC) [ responder ]

Expresiones simbólicas, forman un sistema de Funciones Recursivas

La principal influencia es el uso de listas en los lenguajes funcionales. Otros trabajos influyentes en lenguajes modernos (principalmente funcionales) son APL, que influyó en la programación funcional y la programación funcional basada en predicados de John Backus, y el trabajo de P. Landing. Milner también influyó con el aprendizaje automático. Prolog también utiliza listas, pero se basa en la lógica de predicados.

Creo que basta con decir que Lisp es uno de los lenguajes de programación más influyentes.

Sin embargo, podemos decir lo mismo de Fortran, todos los lenguajes de programación con estructuras de asignación y control.

¿Es esta genealogía el tema principal de los lenguajes de programación? No lo es.

Los lenguajes procedimentales tienen un cuello de botella: la asignación. Véase John Backus, Can Programming Be Liberated From Von Neuman Style?, CACM, 1978.

Creo que es más importante mencionar cómo Lisp evolucionó a un lenguaje basado en el cálculo lambda, debido al trabajo en semántica denotacional (en los inicios de Lisp no se basaba en el cálculo lambda). Scheme es un buen ejemplo de ello, y de cómo se puede utilizar para implementar muchos lenguajes de programación, conociendo su semántica denotacional. Se podría incluir un ejemplo de implementación del lenguaje while a partir de su semántica denotacional.

Para mí, este es un papel más influyente de este lenguaje que una simple genealogía. — Comentario anterior sin firmar añadido por Elias ( discusión • contribs ) 04:58, 9 de marzo de 2011 (UTC) [ responder ]

¿Quién usa Lisp?

Creo que sería bueno ver una sección sobre usos industriales de Lisp, es decir, empresas, etc. que utilizan Lisp en software interno o para la venta. Scheme (lenguaje de programación) tiene una sección de este tipo. 174.99.120.127 ( discusión ) 20:30, 22 de agosto de 2009 (UTC) [ responder ]

¿Lenguaje orientado a objetos?

El término "orientado a objetos" ha sufrido una transformación a lo largo de los años. Lisp fue pionero en su uso. Antes se trataba más de la cuestión de que los objetos eran estructuras de datos a las que se hacía referencia mediante punteros y tenían identidad (no sólo valores copiados por todas partes), como los tipos de referencia de C#, y menos de cómo se programaban. En el antiguo sentido de "orientado a objetos", incluso se pensaba que cosas como los símbolos eran cosas "orientadas a objetos", afirmo. No fue hasta más tarde que el estilo de programación y la encapsulación empezaron a utilizar ese término (y de forma inapropiada, creo, pero eso es algo que podemos debatir en otro lugar, porque aquí lo único que importa es que había un uso más antiguo y que cambió). Me opongo al cambio reciente de Macrakis (22 de agosto de 2009 22:07) que elimina esta referencia, pero no quería entrar en una guerra de ediciones cambiándola de nuevo, así que simplemente hago constar mi preocupación aquí: el hecho de que alguien haya reutilizado el nombre no significa que Lisp no deba reclamar ningún crédito aquí, al menos no sin destacar el cambio en la terminología. Los artículos que utilizan "orientado a objetos" en la forma original no están inventando una realidad falsa. Véase mi ensayo ¿Qué hay en un nombre? - Usos y abusos de la terminología de Lisp de Lisp Pointers, Volumen VI, Número 1, enero-marzo de 1993, donde analicé el cambio terminológico cuando estaba empezando a ganar terreno. - Netsettler ( discusión ) 16:58, 24 de agosto de 2009 (UTC) [ responder ]

¿Lisp basado en cálculo lambda?

En el segundo párrafo introductorio de este artículo se afirma que Lisp se basaba en el cálculo lambda. Acabo de leer una transcripción de una conferencia que dio McCarthy en la que dijo que no entendía el cálculo lambda en ese momento y que Lisp no se basaba en él.

1. http://www.computerhistory.org/search/?q=interview+John+McCarthy&site=chm_collection&client=chm_collection&output=xml_no_dtd

2. Haz clic en el enlace que dice "ME ENCANTA" (No me preguntes por qué dice eso)

3. Página 29

Si el hecho de que es un error común pensar que Lisp se basa en Lambda Calc no se menciona en el artículo, creo que al menos se debería eliminar la afirmación de que ERA ASÍ. — Comentario anterior sin firmar agregado por 198.29.2.254 ( discusión ) 06:32, 18 de septiembre de 2009 (UTC) [ responder ]

Creo que es justo decir que Lisp está influenciado por el cálculo Lambda, pero no se basa en él.

Joswig ( discusión ) 23:33 6 dic 2009 (UTC) [ responder ]

Sí, pensé que había editado este artículo para dejarlo claro, pero al mirarlo nuevamente creo que la edición que hice fue en Scheme (lenguaje de programación) , donde escribí:
La notación matemática de Alonzo Church , el cálculo lambda, inspiró el uso de "lambda" en Lisp como palabra clave para introducir un procedimiento, además de influir en el desarrollo de técnicas de programación funcional que implican el uso de funciones de orden superior en Lisp. Pero los primeros Lisp no eran expresiones adecuadas del cálculo lambda debido a su tratamiento de las variables libres .
La introducción del alcance léxico resolvió el problema al establecer una equivalencia entre algunas formas de notación lambda y su expresión práctica en un lenguaje de programación funcional. Sussman y Steele demostraron que el nuevo lenguaje podía utilizarse para derivar de manera elegante toda la semántica imperativa y declarativa de otros lenguajes de programación, incluidos ALGOL y Fortran , y el alcance dinámico de otros lenguajes Lisp, utilizando expresiones lambda no como simples instancias de procedimientos sino como "estructuras de control y modificadores del entorno". Introdujeron el estilo de paso de continuación junto con su primera descripción de Scheme en el primero de los Documentos Lambda, y en documentos posteriores procedieron a demostrar el poder puro de este uso práctico del cálculo lambda.
Por supuesto, esa es una forma de ver las cosas muy orientada a Scheme, y obviamente Lisp moderno tiene mucho más que Scheme. Sin embargo, sí demuestra que el cálculo lambda inspiró o influyó en Lisp, pero que al menos originalmente Lisp no se basaba en él. Scheme puede afirmar con justicia que es un dialecto de Lisp que implementa una forma pura de cálculo lambda, pero esa es otra historia. -- TS 05:27, 7 de diciembre de 2009 (UTC) [ responder ]
Creo que esto no es del todo cierto: "Pero los primeros Lisp no eran expresiones adecuadas del cálculo lambda debido a su tratamiento de las variables libres ". Los primeros Lisp basados ​​en listas a ( por ejemplo, Lisp 1.5) sí admitían el alcance léxico, pero a costa de una costosa búsqueda de variables. Los Lisp posteriores utilizaban atajos de implementación que no admitían el alcance léxico completo (en la terminología de la época, admitían funargs descendentes pero no ascendentes ). Véase Joel Moses, "La función de FUNCTION en LISP, o por qué el problema FUNARG debería llamarse el problema del entorno", MIT Project MAC Memo AI-199/MAC-M-428 (junio de 1970) texto completo. -- macrakis ( discusión ) 15:30, 7 de diciembre de 2009 (UTC) [ responder ]
Gracias. Creo que tienes razón y desde hace algún tiempo sé vagamente que el ámbito léxico estaba soportado hasta cierto punto por Lisp 1.5 e incluso por MACLisp. Estoy pensando cómo expresar eso en el artículo de Scheme. En última instancia, esta preocupación será parte del artículo sobre la historia de Scheme y (si alguna vez llegamos a escribir uno) un artículo sobre la historia más amplia de Lisp. Creo que la clave puede ser el nivel de coherencia con el que se aplica el ámbito léxico en Scheme, en contraste con los Lisp anteriores. -- TS 08:54, 8 de diciembre de 2009 (UTC) [ responder ]

También pensé que había escrito esta parte :)

Vine aquí porque la entrada Formalismo McCarthy tiene muchos errores y propongo eliminar ese artículo. Se trata de la relación entre funciones recursivas y expresiones simbólicas.

Como dije allí, desde que McCarthy escribió "Funciones recursivas de expresiones simbólicas...", presentó un sistema equivalente a las funciones recursivas. Hay una correspondencia entre Zero y Nil, Succ y Cons, U y Car, Cdr, etc. McCarthy dijo en un artículo sobre Lisp de alrededor de 1980 en el CACM que no entendía el cálculo lambda en ese momento. De lo contrario, no habría cometido el error de enlace dinámico, lo único que cambiaría si pudiera hacer retroceder el tiempo.

Este error debería corregirse en este artículo (Lisp (lenguaje de programación)). Además de esa elección de expresiones Lambda por McCarthy. Hay otra razón que hace que muchas personas (yo era uno de ellos) piensen que Lisp se basa en el cálculo lambda. Los dialectos más nuevos, tal vez Scheme sea el más elegante en este aspecto, se utilizan para enseñar lenguajes de programación implementando su semántica denotacional . Friedman et-al Esentials of programming language, es un libro muy bueno con ese enfoque. Muestran cómo implementar combinadores de punto fijo en ese lenguaje estricto. Puede enseñar cómo escribir la función factorial usando combinadores de punto fijo, como se hace en el cálculo lambda. Pero eso es otra cosa. Solo digo que ese enfoque refuerza el mito de que Lisp se basó en el cálculo lambda.

De todas formas, creo que ambos estáis de acuerdo conmigo en corregir esto. En general, creo que este artículo está bien. Aunque está más sesgado hacia el punto de vista práctico del programador. Eso puede introducir cierta resistencia a hacer esta corrección. — Comentario anterior sin firmar añadido por Elias ( discusión • contribs ) 05:17, 14 de febrero de 2011 (UTC) [ responder ]

BEE Lisp, posible spam

Tenga en cuenta que los usuarios anónimos (194.154.66.35, 212.5.80.7, 212.5.80.7 nuevamente, ¿otros?) están agregando BEE Lisp a varios lugares del artículo, incluidos "Dialectos" y "Enlaces externos".

BEE Lisp es un compilador comercial de Lisp, de ahí mi preocupación de que sea spam. Si es de hecho un dialecto importante, pido disculpas. 75.45.97.117 (discusión) 12:04 27 ene 2010 (UTC) [ responder ]

BEE Lisp es, en efecto, un producto comercial totalmente nuevo (probablemente basado en una implementación libre de la GPL) y no se relaciona con ningún dialecto relevante. Creo que es spam y debería eliminarse. —Comentario anterior sin firmar añadido por 76.238.143.15 (discusión) 21:11, 24 de junio de 2010 (UTC) [ responder ]

¿"de alguna manera compatible"?

Al final de la sección Historial, donde se menciona por primera vez Common Lisp, ¿no debería cambiarse "de alguna manera compatible" por "algo compatible"? Peter Delmonte ( discusión ) 06:24 20 feb 2010 (UTC) [ responder ]

Dialectos de Lisp

¿Por qué no hay información sobre muLisp? ¿Por qué se omite? —Comentario anterior sin firmar añadido por 84.193.134.35 (discusión) 10:59, 11 de julio de 2010 (UTC) [ responder ]

Probablemente se trate de un descuido. Estoy de acuerdo en que mulisp es interesante desde el punto de vista histórico. Se menciona muLisp en tres entradas, pero no como hipervínculo. Merece su propia página si alguien tiene información al respecto. Tampoco se menciona Portable Standard Lisp (PSL) , y debería serlo. -- Netsettler ( discusión ) 16:28 12 jul 2010 (UTC) [ responder ]

Historia -> ¿"en"?

La primera línea de la sección Historia:

"Lisp fue inventado por John McCarthy en 1958 mientras estaba en el Instituto Tecnológico de Massachusetts (MIT)".

"At" es ambiguo: ¿McCarthy asistía al MIT o enseñaba allí? Tras leer brevemente su artículo , parece que se trataba de lo segundo, pero como en realidad no lo sé, pensé que lo traería a colación aquí y dejaría que alguien con un poco más de conocimiento sobre el tema lo corrija. 69.105.38.18 ( discusión ) 02:37 4 ago 2010 (UTC) [ responder ]

McCarthy era profesor en el MIT. -- FOo ( discusión ) 21:09 6 nov 2010 (UTC) [ responder ]

¿Es Lisp el segundo lenguaje de alto nivel más antiguo en uso?

El artículo afirma que Lisp, especificado originalmente en 1958, es el segundo lenguaje de programación de alto nivel más antiguo en uso generalizado en la actualidad; sólo Fortran es más antiguo.

¿Es Lisp realmente de uso generalizado hoy en día? Quiero decir, los dialectos modernos (por ejemplo, Common Lisp) lo son, pero los dialectos Lisp que se usan hoy en día son completamente diferentes al Lisp que se creó en 1958; se podría argumentar que son lenguajes derivados, en lugar de dialectos (¿o es C un dialecto de ALGOL?). Eso es como decir que ALGOL todavía se usa ampliamente porque los lenguajes derivados de ALGOL se usan ampliamente hoy en día. —Comentario anterior sin firmar agregado por 89.101.42.6 (discusión) 19:18, 10 de septiembre de 2010 (UTC) [ responder ]

Los dialectos Lisp que se usan hoy en día son más descendientes de los primeros que C de Algol. En los primeros tiempos no había un único estándar Lisp; más bien, cada universidad o grupo de investigación que creaba un sistema Lisp tenía uno ligeramente diferente, pero todos ellos se reconocían mutuamente como "Lisp". Probablemente valga la pena señalar que CL se consideraba un esfuerzo por encontrar un terreno común entre los dialectos existentes, en lugar de crear un lenguaje completamente nuevo. En cualquier caso, el Lisp de los años 60 se reconoce hoy como un Lisp, mientras que Algol en realidad no se parece a C. -- FOo ( discusión ) 21:08, 6 de noviembre de 2010 (UTC) [ responder ]

¿Ortografía?

¿El número 1178 que aparece en la sección «Dialectos de importancia histórica», enlace «IEEE Scheme – IEEE standard, 1178–1990 (R1995)» se supone que es un año? —Comentario anterior sin firmar añadido por 130.92.9.55 ( discusión ) 12:36, 4 de noviembre de 2010 (UTC) [ responder ]

No, en realidad es 1178, no 1978. El número 1178 es parte del nombre del documento de estándares, el número después del guión denota una revisión específica (o el año en que se publicó esa revisión). La Asociación de Estándares IEEE utiliza (en su mayoría) códigos numéricos para identificar los estándares individuales que publica, como IEEE 754-2008 para la revisión de 2008 del estándar de aritmética binaria de punto flotante, IEEE 1394 para FireWire o IEEE 1541-2002 para el documento que define los prefijos binarios estandarizados. Estrictamente hablando, creo que el número denota el comité de estándares IEEE respectivo. — Tobias Bergemann ( discusión ) 15:06, 4 de noviembre de 2010 (UTC) [ responder ]

Complejidad asintótica de añadir dos listas.

No quería cambiar nada, ya que todo lo que sé sobre Lisp es lo que he leído hasta ahora en este artículo. Pero a mí me parece sospechoso que la complejidad asintótica de añadir dos listas enlazadas sea O(n). — Comentario anterior sin firmar añadido por Enisbayramoglu ( discusión • contribs ) 16:48, 8 de septiembre de 2011 (UTC) [ responder ]

O(n) donde n es la longitud total de todas las listas que se van a añadir excepto la última. La función "append" es O(1) para la última lista. Se necesitan n operaciones de cdr sólo para llegar al final de una lista de longitud n en la representación estándar; también se necesitan O( n ) para copiarla (lo que hay que hacer para "append"). Por supuesto, es posible utilizar otras representaciones (véase la codificación de CDR y las listas enlazadas desenrolladas), pero tienen peores características de rendimiento al modificar listas (RPLACD). -- Macrakis ( discusión ) 17:30, 8 de septiembre de 2011 (UTC) [ responder ]

Clojure

He realizado algunas modificaciones básicas de las distintas menciones a este dialecto de Lisp. No soy un experto en Lisp y, por lo tanto, no pretendo saber cuál es su importancia y notoriedad entre los programadores de Lisp más acérrimos, pero las afirmaciones de que es "uno de los tres dialectos más importantes de Lisp" parecen un poco exageradas y, en cualquier caso, no se hace referencia a ellas, por lo que he eliminado esa parte.

También he eliminado un par de superlativos y he intentado darle a las menciones un tono más neutral. Aun así, unas cuantas referencias relevantes serían bienvenidas; hasta entonces, este sería sólo un dialecto "importante" porque Wikipedia así lo dice. — Comentario anterior sin firmar añadido por 92.243.22.61 (discusión) 10:46 19 abr 2012 (UTC) [ responder ]

Respuesta:
http://wenshanren.org/?p=267 — Comentario anterior sin firmar añadido por 85.243.248.53 (discusión) 09:01 30 jul 2013 (UTC)[ responder ]
Los blogs no son fuentes fiables. La cantidad de descargas de Github tampoco es lo mismo que la popularidad o la importancia. Se necesitan fuentes reales que hagan tales juicios o afirmaciones, no una evaluación errónea de un blog a través de estadísticas web. Yworo ( discusión ) 22:30 30 jul 2013 (UTC) [ responder ]
Muchas páginas relacionadas con Lisp mencionan Clojure, lo que generalmente implica que es tan importante como Scheme y Common Lisp. Me pregunto si todas estas menciones fueron insertadas por el implementador de Clojure. 87.113.146.102 (discusión) 13:25 17 may 2014 (UTC) [ responder ]
He eliminado la mención de 'Clojure' de la última oración del primer párrafo. El libro citado, Practical Clojure, que es una guía para principiantes del lenguaje, solo menciona que está ganando impulso, no que es uno de los 'dialectos de Lisp de propósito general más conocidos' o una declaración equivalente. Una mejor referencia sería una que demuestre su afirmación con datos recopilados. Incluso entonces, no debería mencionarse antes de Scheme y/o Common Lisp. Wickedjargon ( discusión ) 21:16 12 may 2015 (UTC) [ responder ]

¿Alguien me puede decir qué significa "alojado" en "Clojure, que está alojado..."? ¿La palabra es demasiado ambigua o la mayoría de los lectores expertos la entenderán en función del contexto? Wickedjargon ( discusión ) 16:13 14 may 2015 (UTC) [ responder ]

Respuesta: La palabra "alojado" definitivamente necesitaría ser explicada. Aquí significa que el lenguaje Clojure no viene con su propio entorno de ejecución e infraestructura. La implementación principal utiliza la JVM para servicios como administración de memoria, recolección de basura, administración de subprocesos, interfaz del SO, carga de código, generación de código nativo (a través de JVM JIT) y más. Las versiones para CLR (el Common Language Runtime de Microsoft) y Javascript utilizan los entornos de ejecución respectivos de estos. Además, la implementación principal de Clojure tiene su compilador escrito en Java. Esto contrasta con muchas otras implementaciones de Lisp que utilizan su propio sistema de entorno de ejecución directamente sobre el sistema operativo y tienen su compilador escrito en Lisp. Para Common Lisp también hay implementaciones alojadas. Por ejemplo, ABCL para la JVM. Scheme: KAWA y varios otros. "Alojado" tiene la ventaja de que los servicios del entorno de ejecución (por ejemplo, JVM) se pueden reutilizar y que la integración con otro lenguaje (por ejemplo, Java) es más fácil. También significa que algunas funciones típicas de Lisp no están muy bien soportadas. Por ejemplo, por alguna razón, Clojure suele tener tiempos de inicio más largos, no puede guardar imágenes, no admite la optimización de llamadas finales (porque la JVM no admite directamente el TCO) y los seguimientos de pila durante la depuración exponen una gran cantidad de elementos internos de la JVM/Java... La explicación de "alojado" debería hacerse en otro artículo. Por ejemplo, en el artículo de Wikipedia sobre Clojure. Joswig ( discusión ) 07:09, 19 de mayo de 2015 (UTC) [ responder ]

Formato de macros {{Lisp2}}

La macro {{de Lisp2 }}no es compatible con el generador de PDF. Me gustaría crear un libro de referencia sobre Lisp y otros temas a los que se refiere este artículo, pero la macro de Lisp2 está traducida en el generador de PDF a formato HTML (también lo he introducido en el servicio de asistencia técnica).

¿Cuándo se produjo el “resurgimiento del interés”?

¿Qué significa la palabra 'recientemente' en la siguiente oración?

"Tras haber declinado un poco en la década de 1990, Lisp ha experimentado recientemente un resurgimiento de interés".

¿No debería eliminarse la palabra «recientemente» de Wikipedia?

¿Dónde está el 'recently-bot'?

Jack-cnv (discusión) 14:18 2 ene 2013 (UTC) [ responder ]

Mucha confusión

El artículo no distingue entre macros de lectura y evaluación. El evaluador ( eval) toma una expresión como (QUOTE FOO)y devuelve el átomo FOO; el evaluador nunca ve algo que se parezca a 'foo; esa bestia no es una expresión s. El lector de expresiones s (read)hace uso de macros de lectura que transforman el flujo de caracteres 'fooen la expresión s (QUOTE FOO); algún tiempo después evalpuede mirar esa expresión y calcular su valor. En cierto sentido, las macros de lectura están fuera del lenguaje; cuando un programa Lisp examina una expresión s, nunca ve 'foo. Las macros de lectura son ejemplos del barro de Moisés. Quasiquote es simplemente una macro de lectura más poderosa que crea una expresión que construye el patrón especificado.

El artículo también confunde la noción de operador y forma especial. Muchos lenguajes tratan +como un operador y utilizan un mecanismo diferente para funciones como atan(y, x). Lisp no hace eso; +parece un carácter alfabético y se utiliza igual que otras funciones (polimórficas). Un programador de Lisp puede pasarlo +como un argumento funcional; un programador de FORTRAN no puede hacerlo (debe definir su propia función ADD). Lisp tiene formas especiales; no tiene operadores en el sentido de +.

En consecuencia, el artículo pierde la noción clara de eval. Glrx ( discusión ) 04:02 30 abr 2013 (UTC) [ responder ]

GC generacional

Eliminé la afirmación de que el GC generacional se desarrolló originalmente para Lisp; de hecho, fue desarrollado originalmente por David Ungar para una variante de Smalltalk-80, como se evidencia aquí. Teslacuted (discusión) 17:42 5 ago 2013 (UTC) [ responder ]

La edición en cuestión sobre la recolección de basura (informática) . La declaración original parece ser precisa, por lo que me siento tentado a restaurarla. La recolección de basura original, la copia de Baker y la generación parecen estar motivadas por Lisp.
  • David Ungar cita un artículo de 1984 sobre la recolección de basura generacional
http://www.cs.washington.edu/education/courses/cse501/03wi/slides/slides.03-06.pdf generación de menciones y citas a Ungar
  • http://c2.com/cgi/wiki?GenerationalGarbageCollection sugiere que Baker comprendió el problema generacional en 1983
  • El artículo de Lieberman y Hewitt, Un recolector de basura en tiempo real basado en la vida útil de los objetos (LISP), es anterior a 1984. http://web.media.mit.edu/~lieber/Lieberary/GC/Realtime/Realtime.html
También publicado en CACM, Volumen 26, Número 6, junio de 1983, páginas 419-429, doi 10.1145/358141.358147, http://dl.acm.org/citation.cfm?id=358147
http://www.cs.utexas.edu/users/mckinley/395Tmm-2003/talks/LH83.pdf cita al CACM de junio de 1983
No sé si el artículo de L&H cita a Ungar.
Glrx ( discusión ) 19:34 26 ago 2013 (UTC) [ responder ]

El propio Ungar atribuye aquí la Luna. Mi error. Teslacuted (discusión) 22:29 28 ago 2013 (UTC) [ responder ]

Si te sirve de consuelo, la afirmación original no tenía fuentes. Glrx ( discusión ) 23:12 28 ago 2013 (UTC) [ responder ]

Se restauró una definición factorial más clara

He revertido la implementación factorial básica de Marcodx ( discusión  · contribs ) a la versión anterior que usaba una simple sentencia 'if'. No hay nada en la sentencia if que la haga menos funcional; la expresión de comparación = es más directa que un predicado zerop, y tanto el caso base como el recursivo son más fáciles de leer que las cláusulas guardadas. Recuerda que esta página está destinada a gente que aún no conoce Lisp. Diego Moya ( discusión ) 21:09 5 ago 2013 (UTC) [ responder ]

El ejemplo tal como está ahora no resulta claro para quienes no conocen Lisp, o incluso para alguien que lo estudió hace décadas y lo ha olvidado. 211.225.33.104 ( discusión ) 07:05 16 jun 2014 (UTC) [ responder ]

Falta de buenos ejemplos

Hola,

Soy un programador experimentado y no muy estúpido. Entiendo el cálculo lambda y la mayoría de los lenguajes procedimentales simples (C es mi especialidad). Solía ​​programar mucho en FORTH. Esperaba que al leer este artículo pudiera tener una idea del lenguaje LISP relacionado. Lamentablemente, este artículo es deficiente.

Para decirlo de forma sencilla (+ 1 2 3 4) evalúa 10. Vale. No es tan bueno como el pulido inverso de FORTH 1 2 3 4 + + + evalúa 10 --- pero ¿a dónde voy desde aquí? ¡Nada en este artículo me permite definir (foo 1 2 3 4)! Tal vez podría usar lambda, pero no está claro cómo. ¿De dónde viene defun? En FORTH puedo definir una función: : FOO * + ; y 1 2 3 FOO evaluaría 7. No puedo leer este artículo y hacer lo mismo en LISP (creo).

Para que este artículo sea de utilidad *debe* incluir un ejemplo claro de definición de función. No me disculpo por el hecho de que la definición de función puede no estar en el paradigma LISP. Dígame cómo definir (foo xy) u olvídelo.

Un cordial saludo, MikeMichaelbarclay (discusión) 22:44 17 oct 2013 (UTC) [ responder ]

((Dios sabe por qué las tildas me envían un correo a [email protected] Soy una persona real y estoy tratando de ayudar))

El artículo ofrece muchos ejemplos claros de definición de funciones. La función foo se definiría como (defun foo (abcd) (+ abcd)). En algunos dialectos de Lisp, también se podría definir como algo como (setq foo (lambda (abcd) (+ abcd))) -- consulte Lisp-1_vs._Lisp-2#The_function_namespace .
Re "evalúa 10..."; no decimos que la expresión evalúa su valor, sino que Lisp/el sistema Lisp/el intérprete/el sistema de lenguaje evalúa una expresión y devuelve un valor, por ejemplo, "Lisp evalúa (+ 1 2) como 3" o "(+ 1 2) evalúa como 3".
Re: "no tan bueno como FORTH...", este artículo describe Lisp, no lo evalúa como mejor o peor que otros lenguajes.
Re "de dónde viene defun": (defun f (a) b...) es una abreviatura de (place-in-function-definition-slot-of-symbol 'f #'(lambda (a) b...)). El espacio de definición de función puede estar en la lista de propiedades del símbolo (en los primeros Lisp), en un espacio especial adjunto al símbolo (en la mayoría de los Lisp modernos) o en el espacio de valor (Lisp-1 con un único espacio de nombres de función). -- Macrakis ( discusión ) 23:22 17 oct 2013 (UTC) [ responder ]

No dialectos en el cuadro de información

Considero que los siguientes enlaces en la ranura "dialectos" no son dialectos:

Rursus dixit. ( m bork 3 !) 11:19, 10 de enero de 2014 (UTC) [ respuesta ]

Si entonces si no

El artículo afirmaba: La estructura if-then-else , que hoy se da por sentada como un elemento esencial de cualquier lenguaje de programación, fue inventada por McCarthy para su uso en Lisp, donde apareció por primera vez en una forma más general (la estructura cond). Fue heredada por ALGOL , que la popularizó. No se cita. If/Then/Else aparece en Algol58, tal como se definió a mediados de 1958. En ese momento, Lisp tenía cond, si existía. -- Zz ( discusión ) 18:23 4 jun 2014 (UTC) [ responder ]

Ahora vemos dos referencias. Una es de Paul Graham y no es una fuente independiente ni autorizada sobre la historia de Algol o Lisp. La otra, de John McCarthy, incluso refuta la afirmación: Inventé expresiones condicionales en relación con un conjunto de rutinas de movimientos legales de ajedrez que escribí en FORTRAN para el IBM 704 en el MIT durante 1957-58. Este programa no usaba procesamiento de listas. La declaración IF proporcionada en FORTRAN 1 y FORTRAN 2 era muy difícil de usar [...] Esto condujo a la invención de la expresión condicional verdadera que evalúa solo uno de N1 y N2 según si M es verdadero o falso y al deseo de un lenguaje de programación que permitiera su uso. Un artículo que definía expresiones condicionales y proponía su uso en Algol fue enviado a Comunicaciones de la ACM pero fue degradado arbitrariamente a una carta al editor, porque era muy breve. Por un lado, aquí no dice If/Then/Else, como se afirma. En segundo lugar, el desarrollo comenzó en un contexto Fortran y se ha transmitido directamente a Algol58. Por lo tanto, Algol no puede heredar nada de Lisp. -- Zz ( discusión ) 19:16 4 jun 2014 (UTC) [ responder ]
Estos relatos no parecen incoherentes. McCarthy, al escribir un programa Fortran, adoptó un paradigma estructural COND o if-then-else; presumiblemente lo implementó con IF y GOTO de Fortran.
McCarthy, mientras desarrolla Lisp, crea la forma de lenguaje COND para realizar M/N1/N2.
McCarthy escribe un artículo proponiendo que Algol utilice if-then-else.
Glrx ( discusión ) 19:11 15 jul 2014 (UTC) [ responder ]
Algol 60 tuvo la primera *declaración* condicional if-then-else. Hubo muchas propuestas de sintaxis diferentes para declaraciones condicionales durante el proceso de diseño de Algol 58, y la mayoría de ellas son muy extrañas desde una perspectiva moderna: consulte <https://github.com/enf/if-then-else/blob/master/if-then-else.md>. La palabra clave `else` provino de los miembros alemanes del comité de Algol 58. La palabra clave `then` apareció por primera vez en un borrador de Algol 60. McCarthy estuvo involucrado con Algol. Su nombre aparece (con coautores) en una propuesta que incluye una condicional de múltiples ramas sin una sintaxis especial para un `else` o para una cláusula de respaldo predeterminada.
McCarthy inventó la expresión condicional, que devuelve un valor. Su sintaxis preferida era (cond1 -> expr1, cond2 -> expr2, ...). No había una cláusula `else` diferenciada: en su lugar, se usaba `T -> expr` como cláusula final para especificar una alternativa. 209.183.136.7 ( discusión ) 20:05 19 abr 2023 (UTC) [ responder ]

Segundo lenguaje de programación más antiguo

El artículo afirma: Lisp, que se especificó originalmente en 1958, es el segundo lenguaje de programación de alto nivel más antiguo que se usa ampliamente en la actualidad; solo Fortran es más antiguo (por un año). Los dialectos de Lisp y Fortran actuales son al menos tan diferentes de los originales como, por ejemplo, C o Pascal lo son de Algol. La familia Algol es tan común que a la gente le interesan los detalles finos que contiene, pero para una afirmación de tal solidez, esperaría una cita de una fuente confiable (en la medida en que se considere una visión común) o una definición práctica de la familia de lenguajes. -- Zz ( discusión ) 18:31, 4 de junio de 2014 (UTC) [ responder ]

La referencia dada se relaciona con las opiniones personales de John McCarthy. Se necesita algo más general, preferiblemente algo que aborde los puntos anteriores. -- Zz ( discusión ) 19:25 4 jun 2014 (UTC) [ responder ]
No estoy de acuerdo. Los dialectos actuales de Lisp y Fortran se han ampliado, pero siguen siendo muy similares. Algunos programas antiguos seguirán funcionando en los nuevos sistemas. No ocurre lo mismo con un programa en C o Pascal que se introduce en un compilador de Algol.
McCarthy es una autoridad importante, por lo que sus opiniones son WP:DUE . Glrx ( discusión ) 19:03 15 jul 2014 (UTC) [ responder ]
A menos que se trate de una opinión generalizada, la pauta general de Wikipedia es marcarla como la opinión del autor. Considero que McCarthy es bastante relevante, pero no es la única opinión posible. Si crees que es una opinión mayoritaria, busca una fuente que lo indique.
La primera frase del artículo dice: Lisp (históricamente, LISP) es una familia de lenguajes de programación informática[.] . Por lo tanto, es un artículo sobre una familia de lenguajes, al contrario de lo que afirmas. Y te reto a que me muestres programas Lisp 1.5 relevantes que se ejecuten en implementaciones actuales. Sin necesidad, la segunda frase cambia el tema de la familia de lenguajes a un lenguaje y afirma que es el segundo más antiguo. Pero han sucedido cosas mientras tanto. Ya no hay un solo Lisp, y lo que tenemos ahora es diferente de los primeros Lisp. Y si nos basamos en familias de lenguajes, la familia Algol es incluso un poco más antigua. Propongo convertir la segunda frase en una afirmación de que la familia de lenguajes Algol y Lisp empatan en el segundo lugar en antigüedad. -- Zz ( discusión ) 18:19, 16 de julio de 2014 (UTC) [ responder ]
En realidad, los dialectos principales de Lisp, como Common Lisp (o Emacs Lisp), pueden ejecutar el antiguo Lisp con relativa facilidad. Aún conservan gran parte del núcleo del lenguaje Lisp 1.5. Aquí hay un ejemplo para cargar código Lisp de 1960 (algoritmo Wang para cálculo proposicional): http://www.informatimago.com/develop/lisp/com/informatimago/small-cl-pgms/wang.html Joswig ( discusión ) 23:52 19 jul 2014 (UTC) [ responder ]

El ejemplo 1+ es falso

Al menos en lo que respecta a Common Lisp. El operador x++ de C tiene un efecto secundario, pero el operador (1+ x) de Lisp es exactamente equivalente a (+ x 1). incf sería un paralelo más cercano al operador de C++. — Comentario anterior sin firmar añadido por Wolfamade ( discusión • contribs ) 10:08, 30 de enero de 2015 (UTC) [ responder ]

¿Por qué mencionar el libro de Peter Seibel en2000-presentsección

La última frase del primer párrafo de la sección 2000-presente dice: "En 2005 se publicó una nueva edición impresa de Practical Common Lisp de Peter Seibel, un tutorial para nuevos programadores de Lisp". ¿No hay muchos libros publicados recientemente sobre Lisp? ¿Por qué se menciona específicamente este libro? La frase no se conecta con el texto anterior y el siguiente de forma fluida. Esta frase debería eliminarse. -- Wickedjargon ( discusión ) 00:15 9 may 2015 (UTC) [ responder ]

Practical Common Lisp tenía un enfoque diferente para un libro introductorio de Lisp. Se centraba en el estándar ANSI Common Lisp, incluidos CLOS y macros. También venía con más ejemplos prácticos, no relacionados con la IA (como Winston/Horn Lisp). Explicaba un poco más del estilo de desarrollo. Se publicó tanto en línea de forma gratuita en HTML como en un libro impreso. Además, estaba bien escrito y mostraba un buen estilo de programación. Esto lo convirtió en uno de los favoritos en la comunidad de Lisp. http://www.lispforum.com/viewtopic.php?f=18&t=13 ITA/Google se lo dio a todos los nuevos empleados para que aprendieran Lisp. La Guía de estilo de Google para Common Lisp dice "Esta guía no es un tutorial de Common Lisp. Para obtener información básica sobre el lenguaje, consulte Practical Common Lisp". https://google-styleguide.googlecode.com/svn/trunk/lispguide.xml Dado que es la mejor introducción actual a la programación práctica de Lisp, recomendaría que se mencionara. Joswig ( discusión ) 07:18 19 may 2015 (UTC) [ responder ]

Revertí [el libro] como sugirió Wickedjargon. El tema del párrafo era el resurgimiento de Lisp, pero el mero hecho de publicar un libro no conlleva esa implicación. La implicación es WP:SYN . De lo contrario, es una frase descartable. Además, WP no pretende ser un libro/tutorial introductorio para aprender un lenguaje o una fuente de reseñas de productos o libros. Las encuestas informales no son fuentes secundarias confiables. WP usa fuentes para respaldar afirmaciones, por lo que el libro puede usarse para respaldar afirmaciones sobre el lenguaje, pero simplemente mencionar la publicación en el cuerpo del artículo es publicidad. No tengo reparos en incluirlo en EL o en lecturas adicionales, y ahí es donde ya se menciona. Glrx ( discusión ) 15:00, 19 de mayo de 2015 (UTC) [ responder ]

Volver a WickedJargon 12 de mayo de 2015

Estoy intentando revertir el artículo al 12 de mayo de 2015, pero me aparece una excepción.

Las ediciones intermedias han confundido la cronología de Lisp, han confundido las versiones de Common Lisp, han asignado dialectos principales de manera arbitraria y no tienen un punto de vista neutral con respecto a Clojure. Maclisp e Interlisp fueron dialectos principales en su época. Una fuente dada para Clojure niega la relevancia de su metodología de clasificación; en general, las fuentes de Clojure son débiles porque son tendenciosas: se debe usar una referencia que no sea de Clojure ni de JVM para indicar prominencia. Las búsquedas en Google sobre Clojure también muestran fuentes débiles que se quejan de una implementación única, falta de especificación y un aspecto de juguete. Compare múltiples implementaciones de Common Lisp y Scheme.

Scheme ha tenido sus propias conferencias y se ha enseñado en importantes universidades. Common Lisp es un estándar ANSI; hubo reuniones y votaciones. Ambos dieron pasos importantes para hacer avanzar a Lisp en comparación con los lisp contemporáneos Maclisp y LispM.

La introducción de Clojure como dialecto principal ha sido revertida muchas veces en el pasado.

Glrx ( discusión ) 23:49 18 may 2015 (UTC) [ responder ]

Clojure se utiliza en aplicaciones profesionales, se cita varias veces de forma fiable y se revierte.
Así no funciona este proceso. Véase WP:BRD . Es necesario debatir aquí y llegar a un consenso. Glrx ( discusión ) 14:41 19 may 2015 (UTC) [ responder ]

Veamos las ediciones de OMPIRE.

Java como lenguaje influenciado por Lisp. La cita de Guy Steele no es una referencia útil para Wikipedia. En la página de Java no se menciona a Lisp en absoluto. No se proporcionan fuentes que describan la influencia de Lisp en Java. Java puede tener cierta influencia de Lisp (Gosling había implementado Mocklisp para su Emacs y Guy Steele trabajó en el documento estándar de Java), pero necesitaríamos referencias útiles donde se describa esta influencia y cuáles son sus consecuencias.

Las referencias a Clojure tampoco son muy convincentes. Clojure es un lenguaje derivado de Lisp muy popular, pero las citas son más bien de tipo sensacionalista («Puedes apostar a que cualquier lenguaje que uses en 10 años estará muy influenciado por Clojure»).

La reordenación de partes del artículo no mejora el artículo. Joswig ( discusión ) 18:00 26 may 2015 (UTC) [ responder ]

Deshacer la revisión de Loadmaster a las 15:13, 20 de junio de 2015

Estoy deshaciendo la revisión de Loadmaster por las siguientes razones. Cambió el texto...

-- Wickedjargon ( discusión ) 06:49 21 jun 2015 (UTC) [ responder ]

(1) Quizás no lo vi, pero no veo ninguna indicación de que se trate de una cita. Poner una nota al pie en una oración no la designa como una cita. A menos que sea un extracto citado de una fuente y esté claramente indicado como tal , se considera texto parafraseado, que puede modificarse de cualquier forma que consideremos conveniente para hacerlo más comprensible.
(2) ¿Por qué deberíamos limitar la comparación a Fortran? Otros ejemplos de lenguajes más antiguos que han evolucionado a lo largo de las décadas incluyen COBOL y RPG , que todavía se utilizan en la actualidad.
(3) La palabra “llamado” también significa “es nombrado”; “invocar” no tiene tal ambigüedad.
—  Loadmaster ( discusión ) 14:53 22 jun 2015 (UTC) [ responder ]
La sección trata sobre la edición de Loadmaster y la reversión de Wickedjargon. Estoy de acuerdo con la mayor parte de la reversión.
(1) La evidencia de una cita es el parámetro {{ cite web }} . quote=La cita se encuentra dentro de una nota al pie.
(2) Sí, muchos lenguajes han cambiado con el tiempo. Es mejor quedarse con el específico "Fortran" en lugar del vago "muchos lenguajes de programación antiguos". ¿Un lector sabría qué lenguajes han cambiado y cuáles no? Dudo que el lector típico de WP esté familiarizado con COBOL o RPG. Estoy de acuerdo con la observación de Loadmaster sobre que otros lenguajes están cambiando, pero el ejemplo de Fortran es específico.
(3) No soy muy partidario de la diferencia entre "llamado" y "invocado", pero la oración ya lo ha indicado, es decir, sobre cómo escribir una "llamada a función". Sin embargo, la oración original es extraña: "... sería llamado "; yo habría usado "llamado como". Sin duda, decorar "f" es una mejora.(f arg1 arg2 arg3)
Glrx ( discusión ) 15:43 22 jun 2015 (UTC) [ responder ]
Estoy de acuerdo con Glrx (3). Wickedjargon ( discusión ) 01:05 24 jun 2015 (UTC) [ responder ]
No voy a extenderme en la discusión, pero señalaré que
(1) según Wikipedia:Quotations#Comparison_with_paraphrases , la cita no se indica visiblemente como una cita en línea en el párrafo inicial y, como no lo es, se puede parafrasear. O se puede etiquetar específicamente como una cita (por ejemplo, rodeándola con comillas explícitas).
(2) El "lector típico de WP" probablemente tampoco estaría familiarizado con Fortran.
(3) "llamado como" es ciertamente más claro que "llamado". Y si vamos a adornar la invocación (f a b c), entonces deberíamos adornar ftambién el nombre en sí.
—  Loadmaster ( discusión ) 04:34 3 jul 2015 (UTC) [ responder ]
No entiendo qué quieres decir con "se puede etiquetar específicamente como una cita (por ejemplo, rodeándola con comillas explícitas)". De hecho, está rodeada de comillas. Revisa el segundo elemento bajo referencias en tu revisión. Con respecto a (3), esos cambios se han vuelto a agregar. Wickedjargon ( discusión ) 19:55, 3 julio 2015 (UTC) [ responder ]
La frase no está indicada explícitamente como una cita en el párrafo inicial . Me refiero a parafrasear la frase en el párrafo inicial , no el texto citado en las notas al pie . —  Loadmaster ( discusión ) 02:37 4 jul 2015 (UTC) [ responder ]

(2) Como solución de compromiso, cambié la redacción de la tercera oración inicial por: "Al igual que Fortran y otros lenguajes más antiguos que todavía se utilizan, Lisp...". —  Loadmaster ( discusión ) 22:07 7 jul 2015 (UTC) [ responder ]

Las dos primeras viñetas de mi mensaje original hacen referencia a los cambios que has realizado en las notas a pie de página, donde has editado una cita de un libro de texto. La próxima vez, selecciona Editar>Buscar en tu navegador para evitar confusiones. Wickedjargon ( discusión ) 14:47 8 jul 2015 (UTC) [ responder ]
Mea culpa. Todo este tiempo, pensé que mi edición era (solamente) para el texto del párrafo principal. —  Loadmaster ( discusión ) 18:08 9 jul 2015 (UTC) [ responder ]

Enlaces externos modificados

Hola compañeros wikipedistas,

Acabo de agregar enlaces de archivo a un enlace externo en Lisp (lenguaje de programación) . Tómese un momento para revisar mi edición. Si es necesario, agregue después del enlace para evitar que lo modifique. Alternativamente, puede agregar para mantenerme fuera de la página por completo. Hice los siguientes cambios:{{cbignore}}{{nobots|deny=InternetArchiveBot}}

Cuando haya terminado de revisar mis cambios, configure el parámetro marcado a continuación como verdadero para informar a los demás.

Este mensaje fue publicado antes de febrero de 2018. Después de febrero de 2018 , las secciones de la página de discusión "Enlaces externos modificados" ya no son generadas ni monitoreadas por InternetArchiveBot . No se requiere ninguna acción especial con respecto a estos avisos de la página de discusión, aparte de la verificación regular utilizando las instrucciones de la herramienta de archivo que se encuentran a continuación. Los editores tienen permiso para eliminar estas secciones de la página de discusión "Enlaces externos modificados" si desean despejar las páginas de discusión, pero consulte la RfC antes de realizar eliminaciones sistemáticas masivas. Este mensaje se actualiza dinámicamente a través de la plantilla (última actualización: 5 de junio de 2024) .{{source check}}

Saludos.— cyberbot II Habla con mi dueño :En línea 11:26, 27 de febrero de 2016 (UTC) [ responder ]

¿Alguien tiene una referencia para una historia de n-tuplas de Lisp?

Hace décadas me contaron una historia sobre un error en la impresora Lisp, pero no recuerdo quién lo dijo. Sé que hablé con Whitfield Diffy sobre su bonita impresora Lisp, así que tal vez fue él quien lo dijo. No estoy seguro.

De todas formas, el Lisp original se centraba en n-tuplas, por lo que se suponía que la impresora original las imprimía utilizando la típica notación de paréntesis y coma: (A, B, C, D). La rutina tenía un error, por lo que imprimía las tuplas sin comas (o ponía una coma impar al final). La gente prefería el resultado sin comas, por lo que se eliminaron las comas. Glrx ( discusión ) 04:41 26 mar 2016 (UTC) [ responder ]

Añadir ejemplos de Scheme (y otros dialectos)

Los ejemplos en la sección Ejemplos me parecieron bastante buenos, pero pensé que reflejaría mejor a Lisp como una colección de dialectos si agregáramos los mismos ejemplos en Scheme y quizás varios otros dialectos (Clojure o cualquiera de los otros dialectos más nuevos, o tal vez uno de los dialectos extintos).

He estado experimentando con tablas de syntaxhighlights (al revés - syntaxhighlights con tablas en ellas - no funciona), pero (especialmente con la sangría enseñada en "Estructura e interpretación de programas informáticos") los ejemplos no tienen todos la misma altura en diferentes dialectos, lo que parece incorrecto ya que el contenido de las tablas sí lo es. ¿Quizás haya alguna manera de extender el syntaxhighlight para unas cuantas líneas adicionales? Los espacios en blanco no funcionan.

Por ahora, he recurrido a tablas sin bordes y me gustaría que alguien mejore; con respecto a la edición de WP, no tengo idea de lo que estoy haciendo. --El-totsira ( discusión ) 22:26, ​​22 de junio de 2016 (UTC) [ responder ]

He revertido las modificaciones recientes a la sección de Ejemplos para proporcionar comparaciones CL/Scheme por considerarlas inapropiadas. Hay pocas razones para comparar las diferencias sintácticas entre implementaciones: definev. defunno es interesante; algunos ejemplos son idénticos salvo por esa distinción. La versión Scheme de factorialno explota una acumulación léxica; una versión CL podría explotar el mismo alcance. Las comparaciones no muestran ninguna distinción fundamental en el lenguaje. El uso de un argumento opcional para la acumulación probablemente surgió como una forma de ilustrar argumentos opcionales, pero parece ser un método deficiente para calcular un factorial recursivo de cola. Que las macros existan y puedan crear sintaxis diferentes no es algo que se pueda demostrar con ejemplos. Glrx ( discusión ) 20:56, 27 de junio de 2016 (UTC) [ responder ]

Enlaces externos modificados

Hola compañeros wikipedistas,

Acabo de modificar 2 enlaces externos en Lisp (lenguaje de programación) . Tómese un momento para revisar mi edición. Si tiene alguna pregunta o necesita que el bot ignore los enlaces o la página en su totalidad, visite esta sencilla sección de preguntas frecuentes para obtener información adicional. Hice los siguientes cambios:

Cuando haya terminado de revisar mis cambios, puede seguir las instrucciones de la plantilla a continuación para solucionar cualquier problema con las URL.

Este mensaje fue publicado antes de febrero de 2018. Después de febrero de 2018 , las secciones de la página de discusión "Enlaces externos modificados" ya no son generadas ni monitoreadas por InternetArchiveBot . No se requiere ninguna acción especial con respecto a estos avisos de la página de discusión, aparte de la verificación regular utilizando las instrucciones de la herramienta de archivo que se encuentran a continuación. Los editores tienen permiso para eliminar estas secciones de la página de discusión "Enlaces externos modificados" si desean despejar las páginas de discusión, pero consulte la RfC antes de realizar eliminaciones sistemáticas masivas. Este mensaje se actualiza dinámicamente a través de la plantilla (última actualización: 5 de junio de 2024) .{{source check}}

Saludos.— InternetArchiveBot ( Reportar error ) 21:29, 16 de mayo de 2017 (UTC) [ responder ]

¿Cierre de soporte tipo C?

¿Es normal, como se muestra en los ejemplos, apilar todos los paréntesis en un bloque enorme? De esa manera, parece difícil llevar un registro de ellos. Pero espaciarlos en líneas adicionales, como ocurre con las llaves en C/C++, parece mejorar la legibilidad.

(factorial defuncional (n) (si (= n 0) 1 (* n (factorial (- n 1)))))

vs algo como:

(factorial defuncional (n) (si (= n 0) 1 (*n (factorial (-n 1) ) ) ))

-- DMahalko ( discusión ) 18:00 29 may 2017 (UTC) [ responder ]

Sí, apilar paréntesis de cierre es absolutamente normal, y usar el posicionamiento al estilo C de los mismos sería absolutamente poco idiomático. El código Lisp se lee por indentación, y cualquier IDE de Lisp formateará automáticamente el código de esa manera y hará que el balanceo de los paréntesis y la navegación por el árbol de expresiones sean convenientes. Véase, por ejemplo, el capítulo correspondiente del manual de GNU Emacs . Tea2min ( discusión ) 14:33, 30 de mayo de 2017 (UTC) [ responder ]
No, otra forma es separar con espacios los paréntesis abiertos en líneas anteriores. Por ejemplo:
(factorial defuncional (n)
(si (= n 0) 1
(* n (factorial (- n 1))) ))
o
(factorial defuncional (n)
(si (= n 0) 1
(* n (factorial (- n 1))) ) )
donde la sangría muestra la estructura, los espacios que separan los paréntesis nos permiten ver cómo coinciden. — Comentario anterior sin firmar añadido por 2806:107E:C:2568:218:DEFF:FE2B:1215 (discusión) 12:27 4 abr 2018 (UTC)[ responder ]

Enlaces externos modificados

Hola compañeros wikipedistas,

Acabo de modificar 2 enlaces externos en Lisp (lenguaje de programación) . Tómese un momento para revisar mi edición . Si tiene alguna pregunta o necesita que el bot ignore los enlaces o la página en su totalidad, visite esta sencilla sección de preguntas frecuentes para obtener información adicional. Hice los siguientes cambios:

Cuando haya terminado de revisar mis cambios, puede seguir las instrucciones de la plantilla a continuación para solucionar cualquier problema con las URL.

Este mensaje fue publicado antes de febrero de 2018. Después de febrero de 2018 , las secciones de la página de discusión "Enlaces externos modificados" ya no son generadas ni monitoreadas por InternetArchiveBot . No se requiere ninguna acción especial con respecto a estos avisos de la página de discusión, aparte de la verificación regular utilizando las instrucciones de la herramienta de archivo que se encuentran a continuación. Los editores tienen permiso para eliminar estas secciones de la página de discusión "Enlaces externos modificados" si desean despejar las páginas de discusión, pero consulte la RfC antes de realizar eliminaciones sistemáticas masivas. Este mensaje se actualiza dinámicamente a través de la plantilla (última actualización: 5 de junio de 2024) .{{source check}}

Saludos.— InternetArchiveBot ( Reportar error ) 04:03, 24 de diciembre de 2017 (UTC) [ responder ]

Es una tradición aprender LISP escribiendo un intérprete de LISP, lo que lo convierte en un lenguaje formativo.

No tengo referencias para esta afirmación, sólo navego por muchos cursos de LISP.

Es muy fácil escribir un intérprete simple, porque la función eval es el núcleo del intérprete. Por ese motivo, se convirtió en una tradición aprender LISP construyendo el intérprete. La recolección de basura no siempre se incluye en dichos cursos, a menos que sean avanzados.

Algunas veces el intérprete LISP está escrito en algún dialecto LISP, otras veces las funciones LISP básicas se implementan en otro lenguaje de programación, en cuyo caso también se construye un analizador S-Expression.

Un programador que aprende a construir un analizador, representar estructuras de datos e incluso implementar un algoritmo de recolección de basura, adquiere conocimientos clave para los programadores.

Esa tradición fue en gran parte la razón por la que se produjeron muchos dialectos LISP. Fue genial, porque LISP también se convirtió en un lenguaje ideal para experimentar y agregarle otras características, como ampliarlo con funciones de resolución de problemas y programación lógica.

Lo sé por mi experiencia, pero no puedo citar ningún estudio sobre esta característica particular que está ausente en el aprendizaje de la mayor parte de los idiomas.

Aunque algunos lenguajes expresan su semántica de forma circular, es decir, mediante un programa en el mismo lenguaje que la interpreta, esa es una forma de demostrar que dicho lenguaje es como una Máquina de Turing Universal, una Máquina de Turing que puede programarse para funcionar como cualquier Máquina de Turing, idea en la que John von Neumann basó la arquitectura de la máquina de programas almacenados.

Desafortunadamente hoy en día, la semántica de muchos lenguajes de programación populares sólo se describe en lenguaje natural, es decir, inglés simple.

Tengo la tentación de añadir una sección, tal vez titulada Entrenamiento LISP para describir la ventaja de LISP para desarrollar una mente más estructurada. — Comentario anterior sin firmar añadido por 2806:107E:C:2568:218:DEFF:FE2B:1215 (discusión) 09:31 5 abr 2018 (UTC) [ responder ]

Solicitud de traslado el 20 de febrero de 2019

Lo que sigue es una discusión cerrada de una movida solicitada . No la modifique. Los comentarios posteriores deben hacerse en una nueva sección en la página de discusión. Los editores que deseen impugnar la decisión de cierre deben considerar una revisión de la movida después de discutirla en la página de discusión del cerrador. No se deben realizar más modificaciones en esta sección.

El resultado de la solicitud de traslado fue: CONSENSO PARA NO TRASLADAR. Crlf0710 (discusión) 12:36 27 feb 2019 (UTC) [ responder ]


Lisp (lenguaje de programación) → Lisp (familia de lenguajes de programación) – Este artículo trata sobre la familia de lenguajes de programación Lisp, no sobre el miembro con el nombre LISP 1.5 u otro. Crlf0710 (discusión) 19:31 20 feb 2019 (UTC) [ responder ]

ACTUALIZACIÓN: Cambié de opinión y desisto de la propuesta de cambio de nombre. Crlf0710 (discusión) 12:32 27 feb 2019 (UTC) [ responder ]

Encuesta

Siéntete libre de expresar tu posición sobre la propuesta de cambio de nombre comenzando una nueva línea en esta subsección con *'''Support''' o *'''Oppose''', luego firma tu comentario con ~~~~. Dado que las encuestas no sustituyen a la discusión , explica tus razones, teniendo en cuenta la política de Wikipedia sobre los títulos de los artículos .

Discusión

La discusión anterior se conserva como archivo de una solicitud de traslado . No la modifique. Los comentarios posteriores se deben realizar en una nueva sección de esta página de discusión o en una revisión de traslado . No se deben realizar más modificaciones en esta sección.

Primer compilador LISP

El artículo dice actualmente: "El primer compilador completo de Lisp, escrito en Lisp, fue implementado en 1962 por Tim Hart y Mike Levin en el MIT", haciendo referencia a AIM-39 escrito en 1962. Sin embargo, el Manual del programador de Lisp I publicado en mayo de 1960, sección 4.2, establece claramente que ya había un compilador disponible en ese momento. ¿Tenemos alguna evidencia de que este compilador fuera de alguna manera "incompleto"? Ciertamente no hay ninguna indicación de eso en L1PM. Cjs ( discusión ) 03:41, 9 de septiembre de 2019 (UTC) [ responder ]

Construcciones indefinidas

En los ejemplos aparecen dos construcciones no definidas: # y block. ¿Alguien puede solucionar esto?

(La nota al pie 54 explica un uso de #, pero no parece arrojar luz sobre otros ejemplos. Una solución adecuada para el problema del bloque podría ser eliminar el ejemplo arcano que lo utiliza).

También sugiero presentar un ejemplo más sencillo de mapcar, sin #. Tal vez el ejemplo existente sea una buena ilustración de #. Mdmi ( discusión ) 21:04 15 dic 2019 (UTC) [ responder ]

LISP apareció por primera vez en 1960

¿Cuándo apareció por primera vez LISP? Su desarrollo comenzó en 1958. El artículo que describe el diseño de LISP se publicó en abril de 1960. La primera implementación funcional de LISP se escribió basándose en este artículo de 1960 (pero no sabemos el año).

En la página de FORTRAN, el desarrollo comenzó en 1953, se publicó un borrador de especificación en 1954, el manual oficial se publicó en 1956 y el compilador completo se lanzó en 1957. Wikipedia dice que FORTRAN apareció por primera vez en 1957.

Según la redacción del artículo de FORTRAN, es coherente decir que LISP apareció por primera vez en 1960, cuando se publicó la especificación. Lamentablemente, no sabemos el año en que se implementó el intérprete, aunque ese año podría haber sido 1960. — Comentario anterior sin firmar añadido por 209.183.136.7 ( discusión ) 18:04, 15 de diciembre de 2022 (UTC) [ responder ]

Consulte Early LISP History (1956-1959) de Herbert Stoyan disponible aquí: [3]https://web.archive.org/web/20050405213907/http://informatik.uni-erlangen.de/html/lisp/histlit1.html
Hacia el final dice:
Esto era pura teoría entonces porque el primer recolector de basura fue implementado por Dan Edwards durante junio/julio de 1959. A finales de abril, Dan Edwards fue uno de los primeros usuarios del sistema LISP.
Debemos dejar claro que la implementación de LISP en desarrollo ya tenía usuarios serios en ese momento...
Y unos párrafos más abajo:
Por casualidad, en el MIT se guarda una versión temprana del intérprete LISP (fechada el 15/5/59) (en posesión de J. Moses) que no contiene el recolector de basura.
Además, hay que tener en cuenta que las dos referencias que aparecen en la página indican que solo Fortran es más antiguo que Lisp. Se trata de referencias de personas que estaban en el mundo de la programación en esa época, y no es que no supieran que COBOL existía.
Nombre absurdo e inapropiado (discusión) 07:40 21 ene 2024 (UTC) [ responder ]