Ben Booth:
>
> I have a (possibly controversial, possibly insanely stupid) feature request:
Feel free to propose controversial and insane things! We're tackling something
that people have claimed "can't be done", so we need out-of-the-box ideas.
> So, curly infix is great because it's simple to understand, easy to
> implement, and retains homoiconicity. However, it would be *really* nice to
> be able to define infix operators that don't need to be surrounded by curly
> braces, as in haskell:
I think that won't work at all, for same reasons that version 0.1 didn't work
out so well.
In version 0.1 of my "readable" approach, infix operators were automatically
detected. In that case, it used function name patterns and an "escape"
mechanism.
Having to define the infix operators actually adds more complications; now you
need to make sure that those operators are defined before you read something
(whereas, if they are patterns built into the reader, that's not a problem).
But the REAL nasty is, what happens when there are multiple language levels
(which there often are)?
In the base language, "*" may be an infix operator, but not in LANG1. In
LANG2, "*" is an infix operator, but it's often embedded in LANG1. Oh, and
their precedence levels are different. As well as their associativity. And,
they're freely intermingled, and there's probably no way to tell the difference
in the reader.
Eeek.
> (infixl 6 +++)
> (infixr 7 *** ///)
> And then all instances of +++, ***, and /// symbols would be treated as infix
> operators, no curly braces required.
But that's a *problem*. That means that "+++" has to be treated as an infix
operator, at THAT level, all the time.
Also, I'm finding that the operators I might USUALLY use as infix (e.g., "and')
I sometimes use in prefix form. Having {} denote infix lists gives me that
flexibility, and it turns out to be highly useful.
> I am aware that what I am suggesting amounts to blasphemy in LISP circles.
Oh, blasphemy is fine. We're talking about changing the syntax of
S-expressions, so we are already among the heathen :-).
> You'd have to implement this functionality into the reader as it would need
> to be applied globally to the entire AST.
But there's where it runs off the rails. In a Lisp, there's no reason to
believe that a given operator always has the same meaning, at all levels. It
would excessively limiting to do so.
I think curly-infix solves, at a stroke, the issue. After playing with them
for a little while, I've found that they are remarkably easy to use. In
particular, curly-infix are clearly homoiconic and general; you create exactly
one (and only one) list with each {}. Yet for their simplicity, they give
what people want: a simple way to express infix operations.
--- 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
