2008-09-17 13 views
20

Después de leer Practical Common Lisp, finalmente entendí cuál era el problema con las macros, y he estado buscando un lenguaje para la plataforma .NET que lo soporte. Hay algunos dialectos lisp para .NET pero de lo que he podido reunir son muy beta o abandonados. Recientemente, Clojure ha despertado mi interés, pero es para la plataforma java y, aunque probablemente utilice ikvm, no parece estar integrado. Especialmente cuando quieres hacer cosas como WPF.soporte macro en F #

Recientemente he estado oyendo susurrar sobre F #, traté de mirar la documentación si podía encontrar algo sobre soporte macro, pero no lo he encontrado. Entonces, ¿alguien sabe?

Gracias :)

Respuesta

10

Bueno, F # está basado en OCaml y OCaml tiene un más bien extensive macro system. Dadas las similitudes sintácticas y semánticas de F # y OCaml, es posible que pueda trasladar el sistema macro Ocaml a F #.

Además de robar el sistema macro de Ocaml, no conozco un sistema de macro enlatado para F #.

+3

Portar camlp4 no es una tarea trivial. Pero no es necesario mientras permanezca en el subconjunto compatible con ocaml de F #. Aunque todo el proceso requerirá una configuración manual y dará lugar a ciertas restricciones. – ygrek

+0

Este enlace está roto: (http://www.ocaml-tutorial.org/camlp4_3.10) – theoski

7

Nope. No hay macros para F #.

+0

Uno podría optar por considerar las expresiones de cálculo como un reemplazo para un macro sistema, en el sentido de que permite la creación de lenguajes de dominio específicos de tipo. – BitTickler

4

pero los buenos horrores de la sintaxis en esos ejemplos OCaml se ve oscura

No se está ejecutando en la misma sintáctica disyuntiva fundamental que se hace con Lisp. Si quieres el poder de las macros tipo lisp, tiendes a terminar con una sintaxis parecida a lisp para el lenguaje, o bien tu macro sintaxis se ve bastante diferente de tu sintaxis regular ... nada de malo en cualquier enfoque, solo diferentes opciones

+1

No realmente. Las macros de OCaml se complican por la necesidad de diferenciar entre diferentes tipos de construcciones sintácticas (por ejemplo, definiciones de tipo frente a expresiones) porque están representadas por valores de diferentes tipos estáticos. Mathematica tiene una sintaxis rica y macros potentes al mismo tiempo, por ejemplo. –

13

Nemerle, en http://nemerle.org/, es un lenguaje .NET (también es compatible con mono) que es compatible con gran parte del paradigma de programación funcional al tiempo que se mantiene visualmente cerca de C#. Tiene un amplio soporte de macros.

6

¿Has mirado Boo? Si bien Boo no tiene macros, tiene una cartera de compilación abierta, que es una buena alternativa a las macros para la metaprogramación sintáctica.

[EDITAR] Como se señala en los comentarios, Boo tiene tiene ahora macros.

+4

Boo actualmente tiene macros (puede que no haya sido el caso cuando publicaste). – JasonTrue

+0

Podría ser. Lo más probable es que * sí * tuviera macros cuando publiqué eso, pero no lo hizo cuando lo revisé por última vez (lo cual fue mucho antes de esa publicación). No importa de todos modos, ya que puede hacer todo lo que puede hacer con macros con un código abierto compilador y viceversa. –

1

Eso puede ser al revés de lo que usted quiere, pero ¿sabe usted acerca de RDNZL? Es una interfaz de función directa (FFI) que le permite llamar a bibliotecas .NET desde su código Lisp.

Probablemente son mucho menos maduros que cualquier implementación Common Lisp o Scheme, pero hay dialectos Lisp para .NET: L# y DotLisp.

+1

Justo FYI Dotlist ya no se mantiene (Rich es el tipo detrás de Clojure) así que no creo que me meta con eso. Ten en cuenta que si quieres un ceceo que no sea CL/Scheme, usaría Clojure, personalmente. – Runevault

+0

DotLisp es un poco atrofiado, pero eso se debe a que es estable, funciona y estoy demasiado ocupado para cargar mis parches :-( –

1

Hay dos Lisps desarrollado activamente para .NET

IronScheme - basado DLR implementación del esquema

Xronos - DLR basados ​​puerto de clojure

+0

Xronos me parece que no funciona. Consulte ClojureCLR - https://github.com/richhickey/ clojure-clr/wiki/ – Justin

2

Cómo sobre el uso de F # citas?

http://tomasp.net/blog/fsquotations.aspx

+2

Las citas solo le permiten citar el código para obtener una representación en tiempo de ejecución de él, y las citas F # a menudo ni siquiera le permiten hacer eso (por ejemplo, F # se niega a citar '<@ a @>'). Las macros le permiten hacer más, por ejemplo, cambiar la sintaxis del idioma. No hay forma de hacerlo en F #. F # no tiene un CodeDOM completo, por lo que no se puede usar el compilador F # programáticamente. De hecho, se podría decir que F # está específicamente diseñado para evitar este tipo de la programación. –

3

Recientemente he estado susurro sobre F # oyendo, traté de mirar la documentación si podía encontrar nada sobre soporte de macros, pero no lo he encontrado. Entonces, ¿alguien sabe?

F # no admite macros y es poco probable que lo haga.

4

Pensé que debería señalar que ahora hay un puerto .NET/Mono bastante activo de Clojure. Clojure admite macros de estilo LISP como se indica en la pregunta.

Como han dicho otros, las macros no son compatibles con F # en este momento (finales de 2010).

0

Actualmente estoy investigando las posibilidades de meta-programación en F #. Si definimos macros como plantilla de texto que se expande en código, existen dos enfoques obvios:

  1. plantillas T4. Hay una implementación para F #: https://github.com/kerams/Templatus

  2. He visto en algún lugar la invocación de F # de cadenas en un ensamblaje separado y luego cargando el ensamblaje.