 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Now, if it was pretty-printed like THIS:
>
> http://hpaste.org/10565
>
> you wouldn't be as confused. (?) If you have some kind of text editor
> with syntax-hilighting, this isn't an issue.
So I'm guessing either nobody noticed this tucked away here, or it
doesn't make much difference. (Or nobody even cares anymore... o_O )
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 21-Sep-08 6:27, Darren New wrote:
> 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.
I definitely think they exist, only that which ones are reserved and
what they actually mean can vary wildly from field to field. And yes, I
have seen a serious paper where they redefined '=' in a way that is
slightly incompatible with standard use (and with a good reason).
Perhaps you understood me a bit wrong. I am not arguing that you have
variables, constants, reserved words, functions or whatever in Haskell.
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. For languages designed to just give a
slightly abstract representation of current hardware and current
programming techniques that may be quite different.
> 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.
I did both a course on lambda calculus and one on functional programming
languages when I was at university. That was 20 years ago, but I don't
think lambda calculus and functional programming has changed a lot since
then. The point I was trying to make is that the fact that there is no
difference in syntax of functions and arguments in lambda calculus is so
fundamental that it is not a good idea to use these terms to analyse
Haskell.
>>> 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"?
yes?
>> 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.
I don't think I ever claimed a program in Haskell or any functional
language is easy to understand. Nor can I easily understand a paper in
the field of string theory for that matter. That does not mean however
that people working in that field or with that language can see the
structure immediately. I know that, so I won't complain if I don't get
it myself. Just as that I won't tell a Korean that she should use our
alphabet because otherwise it won't make sense to me.
(Next time I'll snip unnecessary parts, I promise. Now I am just to tired.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> My only point was that on a fundamental level the difference between th
e
> 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.
[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.
> 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.
> The point I was trying to make is that the fact that there is no
> difference in syntax of functions and arguments in lambda calculus is s
o
> fundamental that it is not a good idea to use these terms to analyse
> Haskell.
And can you name a variable λ or . or ) or ( in the lambda calculus?
>> 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?
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> I understand the C++ one and the Haskell one looks like line noise.
I just found this in the Haskell humour section:
bos: come on, real programmers use "(((,) <$>) .) . (<*>)"
(It's an IRC quote.)
I wish to point out that I had to actually go look up some of those
operators just to find out what they do!
(,) takes two values and returns a 2-element tuple.
<$> is a generalised version of "map" (not just for lists).
. is function composition, as always.
<*> takes a collection of functions and a collection of values and
applies one to the other.
So that little expression has the type signature
(Applicative col) => col (x -> y) -> col x -> col (z -> (y, z))
which more or less tells you what it does (once you realise that "col"
means "a collection of"). Quite why this particular function would be
useful for anything is another matter...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> you don't. you refrain from using 'case' as a variable by self
> censoring.
Or, to phrase it differently, it's not just a convention of
self-censoring that you can't name a function ) in the lambda calculus.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22-Sep-08 22:40, Darren New wrote:
> andrel wrote:
[snip]
>> 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.
>
> 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.
My point was always the other way around: does Haskell allow you to
introduce concepts and control structures that from that point on will
become conceptually 'part of the language' for you? To the extent that
for you they behave like 'reserved words'. In the sense that overriding
them will result in mayhem everywhere, not least within your own brain.
I think it does.
[snip]
>>>>> 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.
>
> 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.
Normal scoping rules may apply.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22-Sep-08 22:42, Darren New wrote:
> andrel wrote:
>> you don't. you refrain from using 'case' as a variable by self censoring.
>
> Or, to phrase it differently, it's not just a convention of
> self-censoring that you can't name a function ) in the lambda calculus.
>
no of course not. You can not even define a function '0' or '+" or
'increment'. i.e. you can define things that behave that way, given some
interpretation, but you can not name them as such.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> My point was always the other way around: does Haskell allow you to
> introduce concepts and control structures that from that point on will
> become conceptually 'part of the language' for you?
No, I don't think it does. I don't think it's possible to write "case"
or "let" in Haskell. That's kind of the point. I think you're taking
"reserved words" to mean the same as "meaningful concepts." I'm talking
from the point of view of someone building a compiler or something, not
from someone conceptualizing about an application.
> To the extent that
> for you they behave like 'reserved words'.
I don't care what it behaves like in my brain. I care what happens when
it compiles.
>> 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.
>
> Normal scoping rules may apply.
Then it wouldn't be a reserved word, would it? :-)
I don't know if Haskell actually disallows the use of variables named
the same as "reserved words", but if it doesn't, then that's a reserved
word.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
