andrel wrote:
>> 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. you
r 
> 'λ' 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 flo
w 
> 'if'/'fi' and 'do'/'od'[1] in C with Dijkstra's non deterministic guard
s 
> 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.

Sure, I agree. Reserved words should have a meaning that introduces synta
x.

In Tcl, there are what you might think of as "reserved words" like 
braces and dollar signs and whitespace and newlines - things where 
escaping them probably changes the meaning of what you wrote. Then 
there's predefined functions, like "for" and "if" and "proc" (which 
defines new procedures), which you'll wind up breaking everything if you 

change the meaning too much.

But people rewrite things like "proc" all the time, to do things like 
extend the syntax or add tracing or something like that. It's not a 
reserved word if you can use it for something else.

> 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 safel
y 
> conclude that we totally agree on everything in this thread.

No, because you can't change Haskell syntax, as far as I know. You can't 

name an operator :: and you can't name a function "case". They're 
reserved. As far as I know, you can't make up new syntax for the 
language, and you can't change the syntax it has. I may be wrong about 
that.

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

But that wouldn't be a "reserved word". You can't name a function in C 
with the name "if", because then
    if (x == 5) ;
would change meaning. That's *why* it's a reserved word. Not to avoid 
confusion for the user, but to avoid confusion for the compiler.

> Nobody had trouble parsing that.

Right. Because the words serving the function of reserved words told you 

which variable meant which. In math, those pseudo-reserved words are the 

english telling you what symbols mean. If I just wrote
   e = e ^ ( ... )
and didn't tell you verbally which field of measurements each "e" 
belonged to, you wouldn't be able to understand what the equation means. 

Math is an abbreviation for a whole lot of prose - you can't understand 
a mathematical equation unless the rules are explained outside the 
system of mathematics. The lambda calculus is meaningless until you 
specify how the substitution rules work, and you can't specify that in 
lambda calculus.

Computer programs aren't like that. You don't get to explain in English 
what the compiler should do with your code.

>>>> Sure. And if you have an entity called "o" or "+" or "case" or "star
t"?
>>> 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. 

OK, maybe I misphrased it. How does the compiler distinguish the 
variable name from the syntactic form that "case" currently introduces 
in Haskell?  If "you don't", then it means your compiler's behavior is 
unspecified when you use the word "case" as a variable. People generally 

don't like compiler behavior to be unspecified for valid programs.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message