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