Arne Babenhauserheide:
> I just realized that it might be possible to implement curly infix as
> normal macro and still have it easily readable when using sweet
> expressions.
> I did a very partial port of curly to emacs lisp, but only as macro,
> and it struck me, that sweet gets rid of the enclosing braces.
Thanks for the note!
That's a fine "poor man's" approach if you absolutely cannot change the reader.
> Currently I can do this in normal elisp code:
>
> ({ 2 + 4 })
>
> With sweet that would transform directly to
>
> { 3 + 4 }
Fair enough, but only when directly executed. A quote would expose the facade;
I haven't done a lot of coding with emacs lisp, but I suspect:
'({ 2 + 4 })
would become something like:
(quote ( { 2 + 4 } ))
Then macros that expect to operate on "+" might suddenly see an unexpected "{"
in various cases.
In contrast, curly-infix '{2 + 4} does yield '(+ 2 4), and thus integrates much
more cleanly with quoting, macros, etc.
> For nested formulas, it might be possible to have the recursivity in
> the infix-macro, so we could simply use
>
> ({ 3 + 4 + { 5 * 6 } })
>
> In sweet that would transform to
>
> { 3 + 4 + { 5 * 6 } }
>
> without having to change the reader.
An alternative, with this poor man's approach, is to just treat the surrounding
markers as ({...}). Then you'd see:
({ 3 + 4 + ({ 5 * 6 }) })
Instead of setq nil, you might consider using "{" as the last parameter, and
just removing it if it's "}". You could even require it. If you have "{"
evaluate to anything, you don't have to worry about evaluation before the call
if it gets evaluated.
> Also this could be a very simple point of entry. TODO for that: make
> the {-macro recognize nested curly-braces and parse them recursively,
> as if they had been called as ({.
>
> Then a very basic sweet expression reader could simply consist of a
> deterministic whitespace-to-brackets conversion and it would have
> curly-infix for free (the macro could even be implemented in sweet).
If you can't change the reader, this has several merits. Others have also
created infix macros, often calling the operation "nfx" (which is basically the
same idea but with different symbols). AMG implemented one, many years ago. A
number of implementations of infix macros have popped up over the years, though
I don't immediately recall anyone using {...}.
However, this approach doesn't mesh well with quoting and other macros, and
that makes it a problem. The operators are in the wrong place until the infix
macro fires, and it's not always fired at the right time. Which is why "we
won't change the reader" infix solutions like this haven't really caught on.
They're easy to do, but they often don't work well when you need them.
All other programming languages have had to build in *some* capability into
their equivalent of a reader to get good infix support. It should be
unsurprising that Lisp would need *some* reader mod to get good infix support
too. And if you're doing sweet-expressions or neoteric-expressions, you're
changing the reader anyway, so there's no reason to be shy about it.
So if it works for you, I'm delighted!! But I think we should strive to do
better.
Oh, btw, I'm trying use consistently say:
* "Brackets" = square brackets = [ ]
* "Braces" = curly braces = { }
It gets annoying to have to say long multi-word phrases over and over again.
--- David A. Wheeler
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
