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)
      d "i am a string
do not break me!"
  ; comment
; 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)
      (d "i am a string
do not break me!")
  ; comment
; comment
        `(g )); comment
        (h (I am in brackets
           do not change me))
  ,'(j k)


; comment

  (a c))

(defun b (n o)
  "second defun, with a docstring!"
  (message "I am here")
...... ...... ......

You can get it here:


Best wishes,
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
- Arne (http://draketo.de)

Attachment: 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:
Readable-discuss mailing list

Reply via email to