On Sun, Sep 19, 2010 at 8:57 PM, Shriram Krishnamurthi <s...@cs.brown.edu> 
> 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.)


>> 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:

Reply via email to