|
 |
andrel wrote:
> Indeed, but only if you assume you have a language that makes that
> distinction.
That's what I said.
> Maths does not have 'reserved words'. I.e. for the casual
> observer things like '=' and '+' looks as though they are universally
> defined and understood the same way. In practice even these are
> sometimes redefined to suit a specific field or application in a way
> that may even go deeper than overloading.
Correct. Except that given the programming language, reserved words are
fundamentally different from functions or variables. That's why they're
reserved.
Kind of like parens in math - once you decide you have a grouping
operator that's written ( ), you really can't use it to define functions
called ( and ).
The confusion, I think, is that you think maths doesn't have reserved
words. It does. They're just outside of the maths.
For example, the "summation function" is kind of the same as the for
loop: start variable and value below the sigma, stop value above the
sigma, expression to evaluate to the right of the sigma. The reserved
words, in this case, is the English sentence I just wrote describing the
functionality.
Unfortunately, to communicate with the computer about how a compiler
works, we need to speak something other than English. That's where the
reserved words come in. They're a way for the compiler writer to let the
compiler user communicate with the compiler. They are part of the syntax
of a language that is implicit in the rules for evaluating the
functions, just like (A^A)->C you can do a production to find that A->C
because of the rules of pattern matching and substitution. It's
virtually impossible (or even utterly impossible) to formalize the
productions you use in your formalization.
> want to model a language on the way mathematics is used, defining
> 'reserved words' is something you might want to leave out.
Granted. But Haskell doesn't model a language on the way mathematics is
used. It models a language on one particular mathematics. The reserved
words are a syntactic shortcut for a much larger lambda expression, just
like "193" is a syntactic shortcut for a big long string of bits in a
turing machine.
>> Knowing what's an argument and what's a function is also pretty
>> important for understanding how a given line of code works.
>
> Again absolutely true, for a imperative language. In lambda calculus and
> any functional language derived from that this distinction make no sense
> at all.
Except that Haskell is obviously beyond lambda calculus in its
implementation and meaning. See any of Andrew's postings about writing
"2+2" in lambda calculus.
>> If you can't look at the code and figure out which function bodies get
>> evaluated, it makes it really rough to work out what's going on, even
>> in a functional language.
>
> I don't think so. If you have an entity called current_temperature it
> should not matter if that is derived by looking at a specific memory
> location (a variable), by looking at an index in a circular buffer
> (array) or by doing something more complicated like calling a function
> of generating an interrupt. OK, it does matter sometimes but only in an
> implementation. It should not have any influence on understanding the
> code conceptually.
Sure. And if you have an entity called "o" or "+" or "case" or "start"?
> I think you understood that my mean reason for my response was that Warp
> is looking with imperative spectacles to lines of code in a functional
> language and desperately trying to force it into his own mindframe.
I wouldn't go that far, but yes. But if you have a language that defines
complex syntax (which Haskell does a little and C++ does a lot) and you
can't even parse the syntax tree because you can't distinguish reserved
words from variables or functions, then you must admit it's going to be
difficult to read the code. Indeed, if you can't even tell where one
expression ends and another starts, it can be very difficult to
understand the code.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
