Hi Alan, Sorry for not answering for so long… and thank you very much for your answers!
I now have a working parser (it only took a few hours of concentration, but try to get that with two kids and some other projects competing for the free time ;) ), and I grew quite fond of your idea of a restricted inline ENLIST - after getting over the initial “gah”-phase :). I grew so fond of it that I just implemented it :) Am Donnerstag, 21. Februar 2013, 11:08:12 schrieb Alan Manuel Gloria: > We're saddened at your unhappiness with the current direction, and > glad that you have made a concrete effort at defining a suitable > alternative semantics for special indentation extensions. Not every project can be for everyone, otherwise it would have no direction. Just look at the Python Enhancement Proposals which got rejected… >From what I see, readable is focussed on making lisp more readable for >newcomers, but to my taste it loses touch with the simplicity of lisp. But >that *is* a matter of taste. Python also has a quite complex parser, and I >like it a lot. When I code in Lisp, though, I want that simplicity. > Granted, your approach can be implemented using some sort of > preprocessor separate from the core Lisp implementation; in fact, it > seems to be defined so that this is easy (hence the need to denote > single items with ".") and the preprocessor does not even need to > actually understand Lisp syntax (meaning that potentially, a single > preprocessor implementation can work with many Lisp implementations - > the Lisp implementations just need to implement n-expressions, or even > just curly-infix, both of which are far more trivial to add than > indentation). This may be considered a point in its favor, although > it certainly risks falling into the One True Implementation. That is the goal, yes: Essentially a bracket-adding preprocessor, which gives me indentation sensitive syntax while staying dead simple. The first worked out. The second not as well as I had hoped, since I’m now at about 200 lines, 170 lines if I ignore the license header :) > We hope you continue to work with or on indentation-based syntaxes for > Lisp, whether sweet-expressions, your current proposal, or some other > future notation you can develop. Definitely! (I’ve been hearing that answer echoing in my head ever since I read your mail - 1 month ago ;) ) Actually the wisp.py parser can now emit correct Lisp from indentation based syntax - though I assume I still miss a few corner cases. What it can already process is this: ------ ------ ------ defun a (b c) let : d "i am a string do not break me!" : ; comment f ; comment ` g ; comment : h (I am in brackets do not change me) . i , ' j k . l ; comment a c defun b : n o . "second defun, with a docstring!" message "I am here" . t ...... ...... ...... It becomes this: ------ ------ ------ (defun a (b c) (let ( (d "i am a string do not break me!") ( ; comment (f) ; comment `(g )); comment ( (h (I am in brackets do not change me)) i))) ,'(j k) l ; comment (a c)) (defun b (n o) "second defun, with a docstring!" (message "I am here") t) ...... ...... ...... You can get it here: https://bitbucket.org/ArneBab/wisp Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. - Arne (http://draketo.de)
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________ Readable-discuss mailing list Readablefirstname.lastname@example.org https://lists.sourceforge.net/lists/listinfo/readable-discuss