Or alternatively, you could omit the precedence and associativity, and have
the precedence be determined by the order that the operators are given, and
default to left associativity:

{{+ - * / =}
   x = 5 * 3 - 2 + 1
   y = x * 3 + 2}

Ben

On Fri, Jul 27, 2012 at 3:38 PM, Ben Booth <benwbo...@gmail.com> wrote:

> Here's a quick example of how this could be implemented. I'm going to call
> this "extended curly infix" notation:
>
> {{{+ 1 l} {- 1 l} {* 2 l} {/ 2 l} {= 0 r}}
>    x = 5 * 3 - 2 + 1
>    y = x * 3 + 2}
>
> So the syntax is a bit like (let ...), each operator gets associativity
> and precedence values that remain in place for the extent of the code block.
>
> Ben
>
>
> On Fri, Jul 27, 2012 at 3:05 PM, Ben Booth <benwbo...@gmail.com> wrote:
>
>> 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

Reply via email to