En Cuanto A Los DSL Incrustadas

En cuanto a los DSL incrustadas

ANDY GILL, DE LA UNIVERSIDAD DE KANSAS

Hay muchas maneras de dar instrucciones a un equipo: un ingeniero eléctrico que podría escribir un programa MATLAB; un administrador de base de datos podría escribir un script SQL; un ingeniero de hardware podría escribir en Verilog; y un contador podría escribir una hoja de cálculo con fórmulas incorporadas. Aparte de la diferencia en el lenguaje utilizado en cada uno de estos ejemplos, hay una diferencia importante en la forma y elidioma. Cada uno utiliza un lenguaje personalizado para el trabajo a mano, y cada uno se construye peticiones computacionales en una forma a la vez familiar y productivo para los programadores (aunque los contables pueden no pensar en sí mismos como programadores).En pocas palabras, cada uno de estos ejemplos utiliza un DSL (lenguaje de dominio específico).

Programación "Sobre todo funcional" no funciona.

ERIK MEIJER

CONCLUSIÓN

La idea de "programación en su mayoría funcional" es inviable. Es imposible hacer lenguajes de programación imperativos más seguro sólo por la eliminación parcial de los efectos secundarios implícitos. Dejando a un tipo de efecto es a menudo suficiente para simular el efecto muy que acaba de intentar quitar. Por otro lado, lo que permite efectos de ser "olvidados" en un lenguaje puro también provoca el caos en su propio camino.

Desafortunadamente, no hay medio de oro, y nos enfrentamos a una dicotomía clásica: la maldición del tercero excluido, que presenta la posibilidad de elegir entre (a) tratando de domar efectos utilizando anotaciones de pureza, sin embargo aceptar plenamente el hecho de que su código es siendo fundamentalmente effectful; o (b) la incorporación completa de pureza al hacer explícita todos los efectos en el sistema tipo y ser pragmático mediante la introducción de nonfunctions tales como unsafePerformIO. Los ejemplos que se muestran aquí son para convencer a los diseñadores de lenguajes y desarrolladores para saltar a través del espejo y empezar a mirar más en serio en la programación funcional fundamentalista.

DSL de alto nivel para la programación de bajo nivel

BO SVENSSON JOEL, LA UNIVERSIDAD DE INDIANA

MARÍA SHEERAN, CHALMERS UNIVERSITY OF TECHNOLOGY

RYAN NEWTON, LA UNIVERSIDAD DE INDIANA

CONCLUSIÓN

En este artículo se ha puesto de relieve una serie de beneficios potenciales de la tecnología DSL. Si usted va a dar una SL incrustadas una oportunidad, sin embargo, hay algunas desventajas a tener en cuenta también. En primer lugar, los mensajes de error puede ser problemático, ya que estos se expresan en la terminología de la lengua de acogida. Si los programadores de Obsidian intentan utilizar alguna característica en el nivel correcto en la jerarquía de la GPU (por ejemplo, una muy profunda de anidación del paralelo de bucles aplicando demasiados pConcats), a continuación, el mensaje de error es probable que indique que hay que faltan instancias de algunos Haskell clase, en lugar de explicar la razón por lo que trataron no se puede hacer en una GPU. Además, las nuevas DSL carecen naturalmente la biblioteca y herramientas ecosistemas de grandes lenguas establecidas.

El uso de un EDSL como la obsidiana, que expone estructura arquitectónica subyacente, permite el control sobre los detalles que determinan el rendimiento. Elegir exactamente qué abstracto y lo de exponer, sin embargo, sigue siendo importante. Por ejemplo, en los programadores de Obsidian puede operar fuera del trabajo secuencial y paralela y utilizar memoria compartida (a través de la fuerza), pero los detalles de diseño de memoria compartida de matrices, o la gestión de sus vidas en que

...