One of the things that attracts me to this project is the theoretical
simplicity of it. Curly braces are a simple, elegant solution to the infix
issue--it provides a way to unambiguously define infix expressions, without
worrying about issues like precedence, or registering functions, or other
such nonsense. It is my understanding that previous attempts to add infix
to Lisp have severely clashed with macros, because of the complications
that come with precedence.
So the rejection of precedence isn't arbitrary, by any means...
Having said that, the idea of taking an infix list like {a + b * c} and
mapping it to (nfx a + b * c) is ingenious! It allows for the possibility
of including precedence, if it can be found to be compatible with Lisp
macros after all.
While I, for one, want nothing to do with precedence (I think one of the
things that makes s-exprs elegant is the lack of precedence), I think the
"nfx" macro idea is still beautiful: it will allow for the possibility of
converting something {a <= b < c} into an expression that can
short-circuit, yet produce the correct behaviour. If I recall correctly,
Python allows such constructs; in languages that don't, it just seems wrong
to have to type something like
if (5 <= a && a < 5) {do_something();}
but then, that's probably just because I'm a mathematician. :-)
Come to think of it, I don't know how many times I've had to wrap things in
parentheses, because I was either burned by behaviour I didn't expect
(mostly because of some obscure precedence rule), or because I didn't fully
understand the precedence rules (and I didn't want to be bothered with
figuring them out), or because I simply wanted to override precedence.
I've seen code written in *Python*, of all languages, that makes the
complaints against Lisp parentheses moot! (Having said that, I think
writing lists using whitespace instead of parentheses, or any delimiter for
that matter, is also good idea, because making indentation significant
works so well in Python.)
Another thought: I actually kindof like how Haskell allows you to define
operators, or use back-quotes to use an operator as infix (but, oh, how I
can imagine such conventions becoming a nightmare in Lisp!). I have a
little bit of experience trying to learn Haskell, but I haven't tried
Template Haskell, which allows for Haskell macros written in Haskell
syntax. Does anyone have experience with Template Haskell? If so, how
well do macro work with the precedence system?
(It is also my understanding that Dylan is a Lisp with infix notation, but
because precedence causes complications, writing macros in Dylan is rather
rare.)
Perhaps it would be a good idea to collect examples where having precedence
causes a macro to be more difficult to write than it otherwise would be.
Perhaps, if enough examples are given, we could even see how the
complications could be avoided...
On Fri, Jul 27, 2012 at 1:53 PM, David A. Wheeler <dwhee...@dwheeler.com>wrote:
> 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
>
------------------------------------------------------------------------------
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
