Hi David:
On Fri, Jul 27, 2012 at 1:53 PM, David A. Wheeler <dwhee...@dwheeler.com>wrote:
> 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.
>
I think these complications could be handled by having an infix operator
scoping mechanism, similar to how (let ... ) scopes lexical variables. So
you would have to explicitly state that operator * has this associativity
and precedence level for this block of code. As I said before, this would
all be taking place inside the reader, and only applies to the scoped block
of code, so there shouldn't be any confusion for the person writing that
block of code as to how the infix-to-prefix transformation will occur.
Macros would see the prefix-ified version and could treat it as regular
LISP code.
>
> 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.
>
It would only be treated as infix inside the predefined infix operator
scope.
>
> 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 agree that curly infix is more straightforward and simpler to implement.
I'm just saying... having real infix operators would be nice :-)
Ben
------------------------------------------------------------------------------
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
