[racket-dev] P4P: A Syntax Proposal

Hi all,

I thought I'd mention Scala's behaviour, which could be relevant. Any single-operator method like:

	class X {
		def method(arg: Y): Z = { ... }
	}

can be written as an infix operator:

	val answer = x method y

as well as the traditional dot/paren syntax.

Scala uses a set of hard-coded rules to determine precedence and left/right associativity from the name of the method. When I first saw this I thought it was completely mad (still do to an extent), but it does make for readable code.

Cheers,

-- Dave

On 30 Jul 2010, at 15:11, Robby Findler wrote:

> Given SK's teaching goals of "all of these operators are really the
> same" and Eli's (implicit?) goal of "lets get wider hacker-types
> interested" perhaps the right thing is to have a special infix-like
> mode that you can switch into with a keyword (ala what was discussed
> earlier in this thread)? This would be a special purpose mode where
> there is some simple rule that distinguishes infix operators from
> prefix ones (perhaps something like Haskell's convention)?
> 
> Robby
> 
> On Fri, Jul 30, 2010 at 9:05 AM, Eli Barzilay <eli at barzilay.org> wrote:
>> On Jul 30, Robby Findler wrote:
>>> On Fri, Jul 30, 2010 at 4:05 AM, Eli Barzilay <eli at barzilay.org> wrote:
>>>> IMO, this thing is missing the point (the usual "parens, ewww!"
>>>> one), as long as it ignores infix.
>>> 
>>> Seems to me that this point directly contradicts one of Shriram's
>>> design goals, namely showing that + is no more special than append
>>> or one of your own functions.
>> 
>> To make my point better: I think that this (treating them all the
>> same) is exactly what makes people dislike it.  Whether the open
>> paren appears before the function or after it, and whether you
>> separate arguments by spaces or commas is a minor point that is easy
>> to get adjusted too.  As an experiment, try these:
>> 
>>  (< (^ x 2) (/ d 10))
>>  <(^(x, 2), /(d, 10))
>>  x^2 < d/10
>> 
>> I obviously see the simplicity and elegance of the first.
>> I can certainly see the point that makes people want the third.
>> 
>> But the second looks like a mixed up version of the first, which makes
>> it harder to follow (I actually wrote it "top-down" since it didn't
>> make any sense otherwise).  So I don't see any advantages for the
>> second -- *especially* through the eyes of the many people who
>> complain about sexprs, and OTOH, I see a huge disadvantage (which
>> might be just me not being used to the open paren shift and the comma,
>> so if that cost goes away I'm left with a syntax that is redundantly
>> incompatible with sexprs).
>> 
>> And yes -- this is an arithmetic example, and most code is not
>> arithmetic, still -- it's these places that bother me (and seem to
>> bother others) most when it gets to sexpr syntax.  Avoiding infix
>> altogether (and even SK's manifesto has just a comment about not using
>> it) is IMO sticking your head in the sand, and makes the whole thing
>> look like the N+1th step in a long series of amusing posts in various
>> places that end up with no practical results besides a long discussion
>> thread.
>> 
>> --
>>          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>>                    http://barzilay.org/                   Maze is Life!
>> 
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev