On 2006-09-08, Jón Fairbairn <[EMAIL PROTECTED]> wrote:
> "Brian Hulley" <[EMAIL PROTECTED]> writes:
>> In the context of programming, I don't see the problem of
>> just thinking of the integers as a primitive built-in data
>> type which contains some range of positive and negative
>> integers which I'd argue should all be treated on an equal
>> footing when the context of discourse is the integers not
>> the naturals.
>
> I'm not sure what that means. Why should they be equal? Why
> shouldn't Naturals be more primitive than Integers? 

Certainly they're more primitive.  Too primitive to have reasonable
algebraic properties.

>> I don't think there is a need to force spaces to be put
>> around every infix application. It's only when there would
>> be a conflict with the lexical syntax that spaces are
>> needed, just as at the moment we have (F . G) versus (F.G),
>> (f  $  g) versus (f  $g) etc.
>
> That rather goes against your simplicity of design argument,
> doesn't it? Why the special cases? For years I've been
> rather sloppy about spaces around “$”, and now when I use
> template haskell, this bites me.  At some point in the
> future someone might decide that & or % is needed to
> introduce a new chunk of syntax, and formerly valid
> programmes break. So why not just say that varsym varid is
> in general reserved for future special syntaxes, and require
> varsym whitespace varid everywhere?

Hmm.  Quite reasonable, actually, if we were designing the language de
novo.  And easily enough to write correctors for current code.

-- 
Aaron Denney
-><-

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to