 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> The way Haskell does it has advantages.
No question.
> 1. You can tell that stuff is quoted, and what quoting rule it's using.
Trivially true of LISP and FORTH, too. LISP syntax is so simple it's hard
not to know what you're quoting, and in FORTH *everything* works that way,
including all the "normal" stuff.
> 2. You can't accidentally write a quoting rule which changes the meaning
> of a valid Haskell fragment.
Yeah. That's the only thing you *can* do in Erlang, which is kind of odd.
> 3. The new stuff can have completely different parsing rules to Haskell.
> (Presumably the Lisp, Forth and Erlang methods can't do that.)
Erlang, no, because it's already parsed when you get it. FORTH and LISP,
yes, it's exactly the point of it. If you can read arbitrary amount of
input off the input file as you're compiling, you can pretty much completely
change the parsing rules.
Of course, the parsing rule for FORTH is "read up to the next whitespace,
then run that function. Repeat." So the whole point of FORTH is that there
isn't any syntax beyond that defined by the libraries. (For example, the
function to define functions, and the "if" statement, are both library
routines.) It can make things rough, tho.
> If you could write XML tags literally, then an expression like "if x<y
> then if y>z then..." would suddenly parse as an XML tag, which would be
> a Very Bad Thing. Really, having to explicitly say you're doing weird
> stuff isn't so bad.
Yeah, that was just an example I saw. Obviously you'd have to take care. I
haven't used Erlang enough to understand the subtleties of its mechanisms.
--
Darren New, San Diego CA, USA (PST)
The question in today's corporate environment is not
so much "what color is your parachute?" as it is
"what color is your nose?"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] dev null> wrote:
> case size c of
> 3 -> case (size (c ! 0), size (c ! 1), size (c ! 2)) of
> (1, 2, 3) -> (c ! 0 ! 0) + (c ! 1 ! 0) + (c ! 2 ! 0)
> _ -> 0
> _ -> 0
I don't know why, but I got an irresistible urge to write some faux haskell
after seeing that.
case closed in d by
x -> case (open, not!, closed, yes!, 2) because
(1, 2, 3) -> (one, two, three) + x
hence -> yes
hence -> no
To me, it makes exactly as much sense. :P
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
>> Ada. D. Simula.
> I wasn't aware those were *ever* popular.
Ada still goes strong in the areas it is designed for, like safety-critical
firmware.
>> C#. Visual Basic.
> VB is OO now?
It always was. Certainly VB.NET is.
>> Hell, even Fortran is OO for the last 10 years.
> People use Fortran? I thought that was only for scientific applications.
And scientists aren't people?
> Look at job adverts, or websites which talk about programming.
That's not "mainstream", that's "popular". :-)
> If you specifically want a binary tree, the simplest and most logical OO
> way would be to make leaves and branches different subclasses.
Not especially. What about a branch with only one child node? Is that a leaf
or a branch? And what's the value in the second branch?
And yes, even if leaves and branches are separate classes, it doesn't mean
that they both aren't of type "treenode", or the leaf could be a subclass of
branch or vice versa.
> I meant I've never seen it done like that in an OO language.
You've never seen a N-ary tree in an OO language that used the same class
for branches and leaves? Wow.
> My point is that something like a parse tree usually doesn't need to be
> dynamically extensible. If you make an extension to the language, you
> typically need to rewrite all the code for processing the parse tree
> anyway, so the fact that it's monolithic isn't too much of an issue.
I disagree. The whole point of giving you the list of passes was showing you
how modular each pass can be, as well as showing you how modular each parse
node type needs to be.
> And you can take a C++ program and use pointer arithmetic to access
> private member variables. Does that mean C++ doesn't provide encapsulation?
Yes.
>>> What's a closure?
>>
>> It's the value that a lambda expression returns. A "new" statement
>> returns an instance, a lambda expression returns a closure.
>
> I still don't really understand.
What is this?
(lambda (x) (x + 1))
It's a lambda expression.
y = (lambda (x) (x + 1))
What is y? It's a closure.
>> window["foo"] = Function(){...}
> OK. So in what way does this mean that "functions are not first-class"?
I didn't say it did. I said that everything in Javascript is an object.
There are no functions unassociated with a corresponding instance.
OK, you said
> The difference is that Haskell functions work on data, while Smalltalk
only has objects. In other words, you can't invoke a function without
knowing what object that "function" is a method of. (This is also the case
for Javascript, btw.)
I wasn't sure what "this is also the case for javascript" meant, but I
thought you meant you can invoke a function without knowing what object it
is a method of. That isn't true of Javascript, altho there is a top-level
object that serves as a global namespace.
> As I said, avoiding success so that they don't have to keep things
> stable actually went out the window some years ago in reality. Most
> people now *want* Haskell to succeed. (Not that I think it will...)
Fair enough.
> I can imagine there are product written in Java that somebody has to
> support, or that there are Java compilers that somebody has to support.
> But the Java language itself?
Well, no, there's nobody who has to support the spec, as such. I meant there
are major systems where someone is paid to make sure the Java it's based on
keeps working.
--
Darren New, San Diego CA, USA (PST)
The question in today's corporate environment is not
so much "what color is your parachute?" as it is
"what color is your nose?"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 3. The new stuff can have completely different parsing rules to
>> Haskell. (Presumably the Lisp, Forth and Erlang methods can't do that.)
>
> Erlang, no, because it's already parsed when you get it. FORTH and LISP,
> yes, it's exactly the point of it. If you can read arbitrary amount of
> input off the input file as you're compiling, you can pretty much
> completely change the parsing rules.
The way you said "take each token and pass it through a macro" made it
sound like the input stream gets tokenised first - which means if what
you want to quote has different ideas about what constitutes a "token",
you've got a problem.
>> If you could write XML tags literally, then an expression like "if x<y
>> then if y>z then..." would suddenly parse as an XML tag, which would
>> be a Very Bad Thing. Really, having to explicitly say you're doing
>> weird stuff isn't so bad.
>
> Yeah, that was just an example I saw. Obviously you'd have to take care.
> I haven't used Erlang enough to understand the subtleties of its
> mechanisms.
Square enuf.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> The way you said "take each token and pass it through a macro" made it
> sound like the input stream gets tokenised first
It gets tokenized one token at a time. Otherwise, how would your "macro" be
able to read the input? I'm not saying "it looks at the already-parsed
input". I'm saying "it invokes the read() function on stdin to consume input
that was sent to the compiler". The funky syntax is never seen by the
tokenizer (in FORTH and LISP).
--
Darren New, San Diego CA, USA (PST)
The question in today's corporate environment is not
so much "what color is your parachute?" as it is
"what color is your nose?"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Orchid XP v8 <voi### [at] devnull> wrote:
>> case size c of
>> 3 -> case (size (c ! 0), size (c ! 1), size (c ! 2)) of
>> (1, 2, 3) -> (c ! 0 ! 0) + (c ! 1 ! 0) + (c ! 2 ! 0)
>> _ -> 0
>> _ -> 0
>
> I don't know why, but I got an irresistible urge to write some faux haskell
> after seeing that.
>
> case closed in d by
> x -> case (open, not!, closed, yes!, 2) because
> (1, 2, 3) -> (one, two, three) + x
> hence -> yes
> hence -> no
>
> To me, it makes exactly as much sense. :P
I think c ! 2 is the third element of c, not unlike c[2].
switch (size(c)) {
case 3:
switch (size(c[0]), size(c[1]), size(c[2])) {
case (1,2,3):
return c[0][0] + c[1][0] + c[2][0];
default:
return 0;
}
default:
return 0;
}
It's not *that* hard to figure out. :-)
You should look into playing around with a completely different kind of
programming language not based on C. Erlang or APL or something like that.
--
Darren New, San Diego CA, USA (PST)
The question in today's corporate environment is not
so much "what color is your parachute?" as it is
"what color is your nose?"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Orchid XP v8 wrote:
>> The way you said "take each token and pass it through a macro" made it
>> sound like the input stream gets tokenised first
>
> It gets tokenized one token at a time. Otherwise, how would your "macro"
> be able to read the input? I'm not saying "it looks at the
> already-parsed input". I'm saying "it invokes the read() function on
> stdin to consume input that was sent to the compiler". The funky syntax
> is never seen by the tokenizer (in FORTH and LISP).
Tokenising isn't parsing; it's just the initial part where you split the
input into tokens. Thing is, each language has different ideas about
what a "token" is...
Obviously I'm never going to use Lisp or Forth, never mind macros. I'm
just mildly curious to know whether you can implement your own
tokenising rules or not.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> I think c ! 2 is the third element of c, not unlike c[2].
[] is used almost universally for indexing in most languages (not only
for random access of arrays, but also eg. accessing relational sets (where
the thing inside the square brackets is the key and the return value is the
data)). Is there a logical reason why Haskell chooses an odd syntax of
"x ! y" for the same thing than most other languages express as "x[y]"?
Using ! for the nth element is not very expressive. In mathematics ! is
usually used for factorials, in many programming languages it's used to
express logical negation (granted, not a very logical choice per se, but
quite established), and in natural languages it's used to express shouting
or to emphasize the importance of something (like "WARNING!").
So why choose ! as "the nth element"? Did they run out of obfuscated
one-character operators and it was the only one left? Or is there a logical
reason to choose that symbol out of all possible that I'm not aware of?
(Well, I wouldn't actually be surprised if that symbol had been used for
that purpose in some weird mathematical notations eg. in some lambda
calculus or the like since the 1930's or such.)
I know Haskells undying love for obfuscating brevity, but would it have
hurt to actually use a descriptive *name* for that function? I don't know,
like "c element_at 2" (or even "c at 2") or whatever.
Btw, what is logical not in Haskell?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> just mildly curious to know whether you can implement your own
> tokenising rules or not.
You're actually reading the input from the file. How could you *not*
implement your own tokenizing rules?
--
Darren New, San Diego CA, USA (PST)
The question in today's corporate environment is not
so much "what color is your parachute?" as it is
"what color is your nose?"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> [] is used almost universally for indexing in most languages
Well, most based on C syntax. The rest (Pascal, Fortran, Ada, etc) use ().
> data)). Is there a logical reason why Haskell chooses an odd syntax of
> "x ! y" for the same thing than most other languages express as "x[y]"?
I would guess it makes the thing into an infix operator, while x[y] is
neither prefix, postfix, infix, or ... whatever.
Plus, list literals are [ ... ], so I'm guessing that x [ y ] is ambiguous
as to whether you're calling function x with an argument htat's a
one-element list containing y.
Now, why they picked ! instead of (say) @ is beyond me. "@" is what I've
seen used in all the languages that make this strictly an infix operator.
--
Darren New, San Diego CA, USA (PST)
The question in today's corporate environment is not
so much "what color is your parachute?" as it is
"what color is your nose?"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
