 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
>>> Haskell has automatic type inference, for example.
>>
>> Lots of languages have this a little. In C#
>
> Just out of curiosity, just how new *is* C#?
Like 7 or 8 years. Newer versions are, of course, younger.
> ...there are statically-typed OO languages which aren't Java? [Or
> Eiffel, which nobody ever uses.]
You're trolling here, right?
> All I know is that Eiffel makes it seem like this really exotic feature
> that you "shouldn't need to use" under normal circumstances, and if you
> find yourself using it, you've probably designed your program wrong.
I thnk you've misread that, since one of the primary purposes in the design
of Eiffel was to provide a language where doing this tricky thing is right.
> Haskell, on the other hand, makes it trivial.
As long as you don't have inheritance, it *is* pretty trivial.
>> Integers are finite?
> They are if there fixed-precision. ;-)
Oh. I thought Haskell had bigints. Nevermind.
>> I've never seen it done that way. :-)
> Oh really? So how would you do it then?
Generally with the same class for nodes regardless of whether they're leaves
or not.
> My point is that there are major classes of problems which *are* the
> other way around, and for that ADTs win.
Yep.
> For example, the parse tree of
> an expression. You are almost never going to add new types of node to
> that, but you *are* going to be adding new processing passes all the
> time.
I'd disagree with this, but OK. I get your point. I just think this specific
example is probably wrong.
>> It also means you have to recompile everything whenever you change a
>> type. Which kind of sucks when it takes several days to compile the
>> system.
>
> Are there systems in existence which actually take that long to compile?
Yep. Hell, it takes about 3 hours to compile the toolchain and 3 hours to
compile Qt on my machine, and that's just C and C++ without anything
sophisticated going on.
>> Huh? Javascript is about as OO as Smalltalk is. There's nothing in
>> Javascript that is *not* an object.
>
> 1. Smalltalk has classes. JavaScript does not.
Yes, it does. Not in exactly the same way, mind. What do you think
var d = new Date()
is doing there?
> 2. Smalltalk has encapsulation. JavaScript does not.
Yes, it does. It's just harder and pointless.
>> Smalltalk doesn't have first-class functions. It has first class
>> blocks, which are closures.
>
> I won't pretend to comprehend what the difference is, but sure.
A function is a piece of code. A block is a reference to a piece of code
that when evaluated returns a closure. It's the same difference as between
a class and an instance, or a lambda and a closure.
> Erm... no, not really.
>
> function foo(x) {...}
>
> var bar = foo;
>
> var x = bar(5);
>
> No objects here,
Bzzzt. You just don't know javascript very well. What object do you get when
foo or bar references "this"?
> Eiffel has... uh... "agents"? Which are basically GUI callback
> functions, but we wouldn't want to have actual functions, would we?
I don't remember Eiffel well enough to remember that bit.
> Yeah. Databases have been transactional for decades, and many languages
> can access a database. But STM is all internal to the program, and
> implements multi-way blocking and conditional branching and all kinds of
> craziness.
Right. And it has been implemented in database access code. Like, when you
have "cloud" services. I think Google's cloud processing arguably uses STM.
I'm pretty sure Erlang's Mnesia database works that way too.
> Heh. Better not tell that to Galois.com, Well-Typed.com, the authors of
> the 1,000+ packages in the Hackage DB, or the likes of Facebook, AT&T,
> Barclays Analytics or Linspire who all apparently use Haskell internally.
I think you missed "have to" there.
> Sure, Haskell is no Java, C# or PHP. But that's not to say that *nobody*
> is using it...
I didn't say nobody is using it. I said you don't have to support it.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Assume Haskell doesn't have the "0xABC" kind of syntax for hex literals.
> Could you add that with Haskell, or TH?
Haskell supports hex, octal and exponent floats. (0xff, 0o377, 0.255e+3)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Attwood wrote:
>> Assume Haskell doesn't have the "0xABC" kind of syntax for hex
>> literals. Could you add that with Haskell, or TH?
>
> Haskell supports hex, octal and exponent floats. (0xff, 0o377, 0.255e+3)
Pretend it doesn't. Could you add it? Can you make a literal syntax for
"list of exactly two elements" that looks like [[-{ alpha / beta }-]] or
something?
--
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:
> Assume Haskell doesn't have the "0xABC" kind of syntax for hex literals.
> Could you add that with Haskell, or TH?
You could write a function that converts an ASCII hex string into a
number, and then pass the string to that. So you end up saying
if x == hex "0xABC" then...
or similar.
If you use TH instead, you can write a "splice":
if x == $(hex "0xABC") then ...
This is more typing, but the conversion to hex now happens at
compile-time, not runtime. (It's plausible that calling a function with
a constant will get executed at compile-time anyway, but not guaranteed.
TH guarantees it. And if it errors, it errors at compile-time.)
Alternatively you can use the new "quasi-quoting" feature:
if x == [$hex| 0xABC] then ...
Notice the lack of quote marks. Quasi-quoting is really intended for
where you want to write a big long data literal, but it's too wordy. For
example, rather than writing
x = Expr_Define (Expr_Function (Name_Literal "Sinc") [Expr_Var
(Name_Literal "x")]) (Expr_BinOp BinOp_Divide (Expr_Function
(Name_Literal "Sin") [Expr_Var (Name_Literal "x")]) (Expr_Var
(Name_Literal "x")))
(assuming I even nested all those brackets right!), you write an
expression parser, and then do
x = [$parser| Sinc(x) = Sin(x) / x]
and it generates the same thing, at compile-time. As well as generating
expressions, you can also use it to generate patterns for pattern
matching. (Your parser of course has to distinguish between expression
variables and Haskell variables somehow...)
However, there is no way in Haskell to make it so that some arbitrary
new string can be used as a literal, anywhere in the program. You have
to tell the compiler what function to use to parse this stuff, one way
or another.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Just out of curiosity, just how new *is* C#?
>
> Like 7 or 8 years. Newer versions are, of course, younger.
...I feel old now. :-(
>> ...there are statically-typed OO languages which aren't Java? [Or
>> Eiffel, which nobody ever uses.]
>
> You're trolling here, right?
Can you come up with names?
As you can imagine, I don't really follow this stuff very closely, but
as far as I'm aware, there aren't very many "mainstream" languages out
there.
>> All I know is that Eiffel makes it seem like this really exotic
>> feature that you "shouldn't need to use" under normal circumstances,
>> and if you find yourself using it, you've probably designed your
>> program wrong.
>
> I thnk you've misread that, since one of the primary purposes in the
> design of Eiffel was to provide a language where doing this tricky thing
> is right.
>
>> Haskell, on the other hand, makes it trivial.
>
> As long as you don't have inheritance, it *is* pretty trivial.
The synax seemed overly complex and intimidating to me. The actual rules
for type compatibility are fairly complicated, but seem to intuitively
"do what you'd expect", so that's not too much of a problem.
>>> Integers are finite?
>> They are if there fixed-precision. ;-)
>
> Oh. I thought Haskell had bigints. Nevermind.
It does. Currently powered by the GMP. (Apparently they're trying to
change that due to licensing issues or something...)
My point is that even bigints are, technically, finite if executed on a
physical machine. But, like I said, I'm sure that's not what you meant. ;-)
>>> I've never seen it done that way. :-)
>> Oh really? So how would you do it then?
>
> Generally with the same class for nodes regardless of whether they're
> leaves or not.
Right... so if leaves contain a datum and branches don't... Oh, I
suppose you just use a null-pointer instead or something?
Well anyway, I've never seen anyone implement it that way, but I guess
you could.
>> For example, the parse tree of an expression. You are almost never
>> going to add new types of node to that, but you *are* going to be
>> adding new processing passes all the time.
>
> I'd disagree with this, but OK. I get your point. I just think this
> specific example is probably wrong.
I wrote a program to interpret lambda calculus expressions. You know how
many kinds of expression there are? 3. Exactly 3. By the formal
definition of "lambda expression". There is always 3, and there will
never be more than 3.
The list of things I might want to *do* to a lambda expression is of
course huge. I might want to find all its free variables, or rename all
variables to be unique, or reduce it to normal form, or just determine
whether it *is* in normal form, or find the maximum nesting depth, or
convert it into a string for display, or...
>> Are there systems in existence which actually take that long to compile?
>
> Yep. Hell, it takes about 3 hours to compile the toolchain and 3 hours
> to compile Qt on my machine, and that's just C and C++ without anything
> sophisticated going on.
Hmm, interesting.
I've also heard people whine that Darcs is "too slow". Which puzzles me,
given that every operation you perform with it takes, like, 0.02 seconds
or something.
>>> Huh? Javascript is about as OO as Smalltalk is. There's nothing in
>>> Javascript that is *not* an object.
>>
>> 1. Smalltalk has classes. JavaScript does not.
>
> Yes, it does. Not in exactly the same way, mind. What do you think
> var d = new Date()
> is doing there?
It's running a function that fills out a bunch of fields in the object.
You can completely *change* those fields afterwards. Or you can fill out
the fields manually. An object can be given new fields and have its
methods changed at any time. Sure, it's an object. But it does not have
a well-defined class.
>> 2. Smalltalk has encapsulation. JavaScript does not.
>
> Yes, it does. It's just harder and pointless.
In Smalltalk, object fields are accessible only from inside the object.
This is not the case in JavaScript, and AFAIK it is not possible to make
it the case.
>>> Smalltalk doesn't have first-class functions. It has first class
>>> blocks, which are closures.
>>
>> I won't pretend to comprehend what the difference is, but sure.
>
> A function is a piece of code. A block is a reference to a piece of code
> that when evaluated returns a closure. It's the same difference as
> between a class and an instance, or a lambda and a closure.
What's a closure?
>> Erm... no, not really.
>>
>> function foo(x) {...}
>>
>> var bar = foo;
>>
>> var x = bar(5);
>>
>> No objects here,
>
> Bzzzt. You just don't know javascript very well. What object do you get
> when foo or bar references "this"?
I have no idea. (And no obvious way of finding out...)
>> Eiffel has... uh... "agents"? Which are basically GUI callback
>> functions, but we wouldn't want to have actual functions, would we?
>
> I don't remember Eiffel well enough to remember that bit.
It wasn't in the original spec. They added it later, when they figured
out that they didn't want to do the whole Java thing with a bazillion
interfaces. I don't recall off the top of my head how it works.
> I didn't say nobody is using it. I said you don't have to support it.
Ah, right. Well, don't tell that to the Industrial Haskell Group. ;-)
(Does anyone "have to" support Java? Or C for that matter? I can imagine
that some C compiler vendor might have paying customers to support, but
that doesn't stop the designers of C changing the spec...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> if x == hex "0xABC" then...
That doesn't count.
> if x == $(hex "0xABC") then ...
That's getting closer.
> Alternatively you can use the new "quasi-quoting" feature:
> if x == [$hex| 0xABC] then ...
That's fairly close, yes.
> However, there is no way in Haskell to make it so that some arbitrary
> new string can be used as a literal, anywhere in the program.
LISP works it by (IIRC) passing each token to the "read macros" and seeing
if any of them modify it, so it has to be distinguishable somehow. FORTH
works it by literally letting you read the input stream, as well as calling
a specific function when an unparsable word is encountered. So in FORTH, a
literal works mostly like your quasi-quoting scheme, except there's no magic
characters at the front or end to say "hey, this is quoted." You'd just write
blah blah hex 0xABC blah blah
and the "hex" function would run at compile time and read input off stdin to
determine what comes next. So the function to create string literals is the
double-quotes character. Integers are parsed by having nobody know wtf they
are, so you invoke the thing that says "what's this token" and the integer
parser comes back and says "Hey, I know how to compile that!"
Even Erlang has a mechanism to pss the parse tree thru a number of routines
each of which takes a parse tree and returns a new parse tree. It isn't
quite as flexible as LISP or FORTH, but it lets you add parse-time features
pretty easily, like your splice more than anything
> You have
> to tell the compiler what function to use to parse this stuff, one way
> or another.
Yeah, but you shouldn't be putting it inline in the stream. You should be
able to say "anything with < on the front and > at the back should parse as
an XML tag."
--
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 wrote:
> Can you come up with names?
Delphi. Object-C. Ada. D. Simula. C#. Visual Basic.
Hell, even Fortran is OO for the last 10 years.
> As you can imagine, I don't really follow this stuff very closely, but
> as far as I'm aware, there aren't very many "mainstream" languages out
> there.
So you having heard of it is what makes it "mainstream"? ;-)
>> As long as you don't have inheritance, it *is* pretty trivial.
>
> The synax seemed overly complex and intimidating to me.
http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29#Genericity
Seems to be as straightforward as I remember. Pretty much the simplest form
of Generics out there.
>>>> Integers are finite?
>>> They are if there fixed-precision. ;-)
>>
>> Oh. I thought Haskell had bigints. Nevermind.
>
> It does. Currently powered by the GMP. (Apparently they're trying to
> change that due to licensing issues or something...)
>
> My point is that even bigints are, technically, finite if executed on a
> physical machine. But, like I said, I'm sure that's not what you meant. ;-)
But they're not bounded in the language. They aren't fixed precision.
They're just not infinite precision. There's no number you can give me that
says "they work up to this value, but not any higher."
You of all folks here should understand the difference between bounded,
unbounded, and infinite, and the distinction between the language and its
invocation on any one machine.
> Right... so if leaves contain a datum and branches don't... Oh, I
> suppose you just use a null-pointer instead or something?
Or a flag. Or a leaf that inherits from a branch. Or a union-like structure.
Or, for an N-ary tree, a list of children that happens to be empty. (After
all, a binary tree is just an N-ary tree with restrictions on what it can hold.)
> Well anyway, I've never seen anyone implement it that way, but I guess
> you could.
Yeah, but you wouldn't want to in Haskell.
> I wrote a program to interpret lambda calculus expressions. You know how
> many kinds of expression there are? 3. Exactly 3. By the formal
> definition of "lambda expression". There is always 3, and there will
> never be more than 3.
Sure. But that's why lambda expressions were invented in the first place.
That's like looking at a Turing machine and saying "See? No need for
object-oriented features."
http://blogs.msdn.com/ericlippert/archive/2010/02/04/how-many-passes.aspx
Lots of passes, with about half of them being needed only for new features
in the parse tree (compared to V1 of C#, for example). In a real compiler,
it's nowhere near as clearcut. :-)
For example,
"""
Then we run a pass that transforms expression trees into the sequence of
factory method calls necessary to create the expression trees at runtime.
Then we run a pass that rewrites all nullable arithmetic into code that
tests for HasValue, and so on.
"""
Neither of those passes makes sense before you've added the feature to the
parse tree data as well.
> I've also heard people whine that Darcs is "too slow". Which puzzles me,
> given that every operation you perform with it takes, like, 0.02 seconds
> or something.
You're not building real systems.
> It's running a function that fills out a bunch of fields in the object.
> You can completely *change* those fields afterwards. Or you can fill out
> the fields manually. An object can be given new fields and have its
> methods changed at any time. Sure, it's an object. But it does not have
> a well-defined class.
And you can do all that in Smalltalk too. But OK, Javascript has less of a
"class" concept than Smalltalk does. I'd say neither is as "classy" as a
language without code modification like Java or C++.
> In Smalltalk, object fields are accessible only from inside the object.
Not really true. You can use reflection-type stuff to get to them, such as
in the debugger.
> This is not the case in JavaScript, and AFAIK it is not possible to make
> it the case.
Yes, it is. You use closures instead. It's more painful, so nobody bothers.
http://www.devx.com/getHelpOn/10MinuteSolution/16467/0/page/5
Ugly, but if you really need it, you can do it. Basically, you create a new
object within the current object and only let the current object hold a
reference to it.
> 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.
>> Bzzzt. You just don't know javascript very well. What object do you
>> get when foo or bar references "this"?
>
> I have no idea. (And no obvious way of finding out...)
Hint: It's called "window".
function foo() {...}
is the same as
window["foo"] = Function(){...}
> It wasn't in the original spec. They added it later, when they figured
> out that they didn't want to do the whole Java thing with a bazillion
> interfaces.
Oh yeah. They made a big deal of it at the time. I remember.
>> I didn't say nobody is using it. I said you don't have to support it.
> Ah, right. Well, don't tell that to the Industrial Haskell Group. ;-)
OK. But the language designers don't count that as "success" and don't mind
breaking it? I guess if you're using Haskell you just keep the version
you're using around as long as you need it.
> (Does anyone "have to" support Java?
Sure.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> LISP works it by (IIRC) passing each token to the "read macros" and
> seeing if any of them modify it, so it has to be distinguishable
> somehow.
> FORTH works it by literally letting you read the input stream,
> as well as calling a specific function when an unparsable word is
> encountered. So in FORTH, a literal works mostly like your quasi-quoting
> scheme, except there's no magic characters at the front or end to say
> "hey, this is quoted."
> Even Erlang has a mechanism to pss the parse tree thru a number of
> routines each of which takes a parse tree and returns a new parse tree.
> It isn't quite as flexible as LISP or FORTH, but it lets you add
> parse-time features pretty easily, like your splice more than anything
Well, there's no law against you writing a Haskell preprocessor in
Haskell. (Though obviously that's not quite as convinient as the
compiler automatically running it for you.)
>> You have to tell the compiler what function to use to parse this
>> stuff, one way or another.
>
> Yeah, but you shouldn't be putting it inline in the stream. You should
> be able to say "anything with < on the front and > at the back should
> parse as an XML tag."
The way Haskell does it has advantages.
1. You can tell that stuff is quoted, and what quoting rule it's using.
(Pointless for something like a hex number, but damned useful for a
complex program with a dozen kinds of AST which you might want to quote.)
2. You can't accidentally write a quoting rule which changes the meaning
of a valid Haskell fragment.
3. The new stuff can have completely different parsing rules to Haskell.
(Presumably the Lisp, Forth and Erlang methods can't do that.)
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.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Can you come up with names?
>
> Delphi.
I thought that died 10 years ago?
> Object-C.
I thought that died when C++ came along? (Although I hear Apple still
uses it.)
> Ada. D. Simula.
I wasn't aware those were *ever* popular.
> C#. Visual Basic.
VB is OO now?
> Hell, even Fortran is OO for the last 10 years.
People use Fortran? I thought that was only for scientific applications.
(Or am I thinking of Forth?)
> So you having heard of it is what makes it "mainstream"? ;-)
Look at job adverts, or websites which talk about programming. They all
mention C, C++, Java, VB, PHP, Perl, Ruby, Python. A few very new ones
might mention C#. Occasionally you'll hear of Erlang. They don't mention
Fortran or Ada. (Like they don't mention Pascal, Eiffel, Smalltalk or
Haskell.)
>>> As long as you don't have inheritance, it *is* pretty trivial.
>>
>> The synax seemed overly complex and intimidating to me.
>
> http://en.wikipedia.org/wiki/Eiffel_%28programming_language%29#Genericity
>
> Seems to be as straightforward as I remember. Pretty much the simplest
> form of Generics out there.
Not as simple as Haskell, but sure, I guess that is reasonably easy.
>> My point is that even bigints are, technically, finite if executed on
>> a physical machine. But, like I said, I'm sure that's not what you
>> meant. ;-)
>
> But they're not bounded in the language. They aren't fixed precision.
OK, sure. What were we debating again...?
>> Right... so if leaves contain a datum and branches don't... Oh, I
>> suppose you just use a null-pointer instead or something?
>
> Or a flag. Or a leaf that inherits from a branch. Or a union-like
> structure. Or, for an N-ary tree, a list of children that happens to be
> empty. (After all, a binary tree is just an N-ary tree with restrictions
> on what it can hold.)
If you specifically want a binary tree, the simplest and most logical OO
way would be to make leaves and branches different subclasses. (Unless
every node contains a datum, in which case branch should probably be a
subclass of leaf.) But sure, the others are possibilities. (And if you
might want N-ary trees, then presumably you're doing to use a list or
array or something for the children, as you say...)
>> Well anyway, I've never seen anyone implement it that way, but I guess
>> you could.
>
> Yeah, but you wouldn't want to in Haskell.
I meant I've never seen it done like that in an OO language. In Haskell
you'd obviously use an ADT, since this is the intended use case.
> http://blogs.msdn.com/ericlippert/archive/2010/02/04/how-many-passes.aspx
>
> Lots of passes, with about half of them being needed only for new
> features in the parse tree (compared to V1 of C#, for example). In a
> real compiler, it's nowhere near as clearcut. :-)
>
> For example,
>
> """
> Then we run a pass that transforms expression trees into the sequence of
> factory method calls necessary to create the expression trees at runtime.
>
> Then we run a pass that rewrites all nullable arithmetic into code that
> tests for HasValue, and so on.
> """
>
> Neither of those passes makes sense before you've added the feature to
> the parse tree data as well.
I'm not quite comprehending the point you're trying to make.
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.
> You're not building real systems.
That's what SHE said...
> And you can do all that in Smalltalk too. But OK, Javascript has less of
> a "class" concept than Smalltalk does.
We are in agreement.
>> In Smalltalk, object fields are accessible only from inside the object.
>
> Not really true. You can use reflection-type stuff to get to them, such
> as in the debugger.
And you can take a C++ program and use pointer arithmetic to access
private member variables. Does that mean C++ doesn't provide encapsulation?
> http://www.devx.com/getHelpOn/10MinuteSolution/16467/0/page/5
"Omitting the 'this' keyword makes the variables private to the object.
The 'var' keyword makes the property local (each object instance gets
its own copy of the variable)."
Well, that's news to me...
>> 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.
>>> Bzzzt. You just don't know javascript very well.
>>
>
> function foo() {...}
>
> is the same as
>
> window["foo"] = Function(){...}
OK. So in what way does this mean that "functions are not first-class"?
>>> I didn't say nobody is using it. I said you don't have to support it.
>> Ah, right. Well, don't tell that to the Industrial Haskell Group. ;-)
>
> OK. But the language designers don't count that as "success" and don't
> mind breaking it?
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...)
> I guess if you're using Haskell you just keep the
> version you're using around as long as you need it.
Well, there's always that possibility, it's true.
(You could also write a compiler or interpretter yourself too. The spec
is open...)
>> Does anyone "have to" support Java?
>
> Sure.
Oh. Really?
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?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> which is obviously a hell of a lot longer.
>>
>> Yet, oddly enough, will work on things that *aren't lists*. That's the
>> point. :-)
>
> Well, you can pattern match on the size of the container (presuming you
> have a polymorphic "size" function to get this). It won't be quite as
> neat though, obviously.
What was the original?
case list of
[[x], [y,_], [z,_,_]] -> x+y+z
_ -> 0
If you want it to work for other containers, you're going to have to do
something like
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
Which isn't nearly as nice.
> Secondly, there's actually an experimental extension to Haskell called
> "view patterns" which allow you to create sort-of "user defined pattern
> matching". This fixes this exact problem. (And a couple of others.)
No, apparently it doesn't. It just lets me write
case c of
(size -> 3) -> ...
instead of
case size c of
3 -> ...
How dissappointing...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
