On Sun, Sep 19, 2010 at 8:57 PM, Shriram Krishnamurthi <s...@cs.brown.edu> wrote: > In replying to the below, I'm not ignoring the rest of your message. > >> By, the way, why'd you decide on "numeq" instead of >> "number=?". > > I don't think there's a good verbal choice here (though numeq is > especially ugly). You can already write plain ol' =, as in, > > =(1, 2) > -- evaluates to --> > false > > but people found it ugly and suggested something more "verbal". I'm > not happy with numeq and welcome better suggestions.
Oh. I'm perfectly happy with =, here. If it works and you can still have = in function definitions, then you've made the right choice and people who think =(1, 2) looks ugly should look at +(1, 2), -(1, 2), *(1, 2), and /(1, 2) repeatedly until it doesn't seem ugly anymore. (I hesitate to mention this, but I've been playing around with Scala quite a bit recently, and it allows infixing of methods, so 1 + 2 is actually just a syntactic variant of (1).+(2). You can do the same thing with functions, so if you define max(x, y), you can write max(4, 5) or 4 max 5 and both are the same thing semantically. With variable arity, I'm not suggesting P4P adopt this approach, but functions written +(1, 2) or =(x, y) don't bother me nearly so much as they would have a couple of months ago.) Todd > >> Or, alternatively, why not use "as:" in place of the "=" in the >> first line and then you can use "=" as a function on numbers. > > The first line of what? You mean in function definitions? > > 1. As I say above, you CAN already use = on numbers. > > 2. Just to be clear, the use of = in function headers is unrelated to > the availability of = for numeric equality. The = there is just a > keyword. In fact, the = in all three of > > deffun: f(x) = *(x, x) > > let: x = 3 in: *(x, x) > > =(1, 2) > > are independent: Coolness. If all three are independent, then they're all three good choices. > neither one precludes the other, and each could > change without having any impact on the other. (That is, changing "=" > to "as:" in function definitions would leave the other two completely > unchanged. However, I rather like the function definition syntax and > intend to leave it alone -- the "has:" for structures was because an = > there would have been less accurate.) > > Shriram > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users