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 <e...@barzilay.org> wrote:
>> On Jul 30, Robby Findler wrote:
>>> On Fri, Jul 30, 2010 at 4:05 AM, Eli Barzilay <e...@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
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
