On 22-Sep-08 2:19, Darren New wrote:
> andrel wrote:
>> My only point was that on a fundamental level the difference between 
>> the categories is so blurred that you should not expect a language to 
>> have visual clues to distinguish between them. At least not for 
>> languages based on an abstract concept. 
> 
> I'm just going to have to disagree here. I think any category that has 
> syntax[1] is going to have syntactic equivalents of reserved words.

I agree totally ;) . The point where we might disagree is that I think 
that there are reserved words that are vital to the language ( e.g. your 
'λ' and '.' and ')' and  '(' of the snipped part below), reserved words 
that are better left untouched because they are too common and it would 
make code incomprehensible if redefined ('for', 'case' and other 
constructs that could be substituted by other constructs) but also 
things that are not reserved but could be (I'd like to have control flow 
'if'/'fi' and 'do'/'od'[1] in C with Dijkstra's non deterministic guards 
and I like them to behave as if they are reserved words). So for me the 
concept of 'reserved words' is too fuzzy to merit special handling.

[1] with probably different names, because 'do' and 'if' already have a 
meaning.

> [1] By which I mean to rule out things like FORTH and Tcl and such, much 
> of whose syntax is defined by the code itself rather than the compiler.

I think that some functional and declarative languages can also be 
included in your list. If we put Haskell on that list, I think we safely 
conclude that we totally agree on everything in this thread.

>> For languages designed to just give a slightly abstract representation 
>> of current hardware and current programming techniques that may be 
>> quite different.
> 
> I don't think it has anything to do with how high-level it is. It has to 
> do with whether you can parse the syntax of the language. If "case" is 
> allowed to be a variable, and "->" is allowed to be a function, then 
> there's no way to write the code in http://hpaste.org/10565 and have it 
> make sense.

Even if you allow total freedom, nothing prevents a community to impose 
restrictions. E.g. on the 1802 all registers are totally equivalent, any 
of the 16 registers can function as a numeric value, a stackpointer or a 
program counter. Nonetheless the programcounter and stackpointer are 
more or less fixed by convention. Indeed to prevent unreadable code.

Another, possibly unrelated, remark. I always though that π (pi) was a 
reserved word throughout mathematics and physics. Until someone 
introduced it as a generalized impulse (with arrow on top, but still). I 
also know that once we had a formula of the energy of a particle in a 
electric field. Something along the lines of:
e=e^(e/..)
where the first e is the energy, but lower case because it is per 
particle. The second e is the conventional constant 2.71... and the 
third is the unit charge 1.6e-19 coulomb (hmm, might have been e^2, it 
is too long ago). Nobody had trouble parsing that.

[I promised to snip something, this part was the most likely candidate]

>>> Sure. And if you have an entity called "o" or "+" or "case" or "start"?
>> yes?
> 
> How do you distinguish that variable name from the syntactic form that 
> "case" currently introduces in Haskell?
> 
you don't. you refrain from using 'case' as a variable by self 
censoring. (and you refrain from introducing new reserved words in 
future versions. Is anybody from Mathworks listening? I repeat, you don't.)

Post a reply to this message