The goal of this project is to help you write programs that users can change and extend. Besides its practical advantages, there's something really powerful about modifying a deployed program, especially when it's done interactively.
As to what language users should write in, I've come to believe it isn't lisp and thus I settled on a syntax close to SML. My reasons are anecdotal and also influenced by Wadler's experience teaching lisp at Oxford [*]. As he writes, is not that lisp can't be explained, but that tricky things tend to compound in the middle of the user trying to do something. Considering that the star of the show is whatever the user gets from a program, I think the language should be effective but low key. Furthermore, the basic Eisen language can itself be extended or built almost from the ground up, so there's room for experimenting and trying things out. The API has functions for hooking up user code, configuring and extending the language, reusing parsing and translation functions. There's also a primitive repl. The project: https://github.com/blancas/eisen Documentation: https://github.com/blancas/eisen/wiki Codox API: http://blancas.github.com/eisen/ For feedback, feature requests and bug reports: https://github.com/blancas/eisen/issues [*] http://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
