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)
signature.asc
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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
