Very silly

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Very silly

Andrew Coppin
{-# LANGUAGE FlexibleInstances #-}

module Overload where

class Silly s where
  go :: s

instance Silly ([x] -> [x]) where
  go = reverse

instance Silly (Int -> Int) where
  go = (+1)





Don't even ask.

Suffice it to say, you *can* make Haskell support arbitrary overloading
of function names like C++ has, _if_ you abuse the type system violently
enough. Please, won't somebody think of the children?!?

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Very silly

Bulat Ziganshin-2
Hello Andrew,

Monday, October 13, 2008, 10:51:43 PM, you wrote:

> Suffice it to say, you *can* make Haskell support arbitrary overloading
> of function names like C++ has, _if_ you abuse the type system violently
> enough. Please, won't somebody think of the children?!?

people that make critique on haskell type classes, don't take into
account that it's unlike C++ templates, implemented via run-time
dictionaries and other modules may define new instances

just imagine other module defining instance for (a->a) or
(String->String) - how your module should compile calls to `go` that
take into account these possible definitions


--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Very silly

Bugzilla from jonathanccast@fastmail.fm
In reply to this post by Andrew Coppin
On Mon, 2008-10-13 at 19:51 +0100, Andrew Coppin wrote:

> {-# LANGUAGE FlexibleInstances #-}
>
> module Overload where
>
> class Silly s where
>   go :: s
>
> instance Silly ([x] -> [x]) where
>   go = reverse
>
> instance Silly (Int -> Int) where
>   go = (+1)
>
>
>
>
>
> Don't even ask.
>
> Suffice it to say, you *can* make Haskell support arbitrary overloading
> of function names like C++ has, _if_ you abuse the type system violently
> enough. Please, won't somebody think of the children?!?

Flexible instances are extroardinarily useful:

instance Monad m => MonadState s (StateT s m)
instance MonadState t m => MonadState (s, t) (StateT s m)

is a useful and not entirely insane instance scheme.

But yeah, anyone who uses class Silly in real life should be banned from
coming within a 100 feet of any place where math, science, engineering,
or software development is carried out or taught.

I don't know if it's necessary for the good of the Children, but we need
to start thinking of the poor, defenseless computers as well...

jcc


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Very silly

Andrew Coppin
In reply to this post by Bulat Ziganshin-2
Bulat Ziganshin wrote:
> people that make critique on haskell type classes, don't take into
> account that it's unlike C++ templates, implemented via run-time
> dictionaries and other modules may define new instances
>  

Personally, I have no clue how C++ templates work [yet]. (As in, I'm
learning C++, but I haven't got to that chapter yet.)

Some guy told me that templates are "the best feature in the language",
and proceeded to show me a huge chunk of highly complex-looking code
which is approximately equivilent to

  join :: Array x -> Array x -> Array x

I was unimpressed.

Actually, that's a lie. I was impressed that such a low-level language
could manage even that much abstraction. But I still prefer the Haskell
way...

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Very silly

Andrew Coppin
In reply to this post by Bugzilla from jonathanccast@fastmail.fm
Jonathan Cast wrote:
> Flexible instances are extroardinarily useful:
>  

I'm sure the GHC team wouldn't have bothered otherwise. ;-)

AFAIK, "flexible instances" just means that absolutely anything can be a
class instance, right?

> instance Monad m => MonadState s (StateT s m)
> instance MonadState t m => MonadState (s, t) (StateT s m)
>
> is a useful and not entirely insane instance scheme.
>  

I hadn't realised this required FIs. (Although clearly it demands
MPTCs.) Man, so many TLAs...

> But yeah, anyone who uses class Silly in real life should be banned from
> coming within a 100 feet of any place where math, science, engineering,
> or software development is carried out or taught.
>
> I don't know if it's necessary for the good of the Children, but we need
> to start thinking of the poor, defenseless computers as well...
>  

Heh. And I thought *I* was crewl for making my poor PC use Peano
integers rather than the [vastly more efficient] binary numbers...

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re[2]: Very silly

Bulat Ziganshin-2
In reply to this post by Andrew Coppin
Hello Andrew,

Tuesday, October 14, 2008, 12:15:04 AM, you wrote:

>> people that make critique on haskell type classes, don't take into
>> account that it's unlike C++ templates, implemented via run-time
>> dictionaries and other modules may define new instances
>>  

> Personally, I have no clue how C++ templates work [yet]. (As in, I'm

they are known as generics in java/c#


--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Very silly

Andrew Coppin
Bulat Ziganshin wrote:

> Hello Andrew,
>
> Tuesday, October 14, 2008, 12:15:04 AM, you wrote:
>
>  
>>> people that make critique on haskell type classes, don't take into
>>> account that it's unlike C++ templates, implemented via run-time
>>> dictionaries and other modules may define new instances
>>>  
>>>      
>
>  
>> Personally, I have no clue how C++ templates work [yet]. (As in, I'm
>>    
>
> they are known as generics in java/c#
>  

I don't know C#, and when I did Java, generics didn't exist yet. [Eiffel
has a feature of the same name, but I don't think it's related -
certainly not in implementation anyway.]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: Very silly

David Leimbach
In reply to this post by Bulat Ziganshin-2


On Mon, Oct 13, 2008 at 1:31 PM, Bulat Ziganshin <[hidden email]> wrote:
Hello Andrew,

Tuesday, October 14, 2008, 12:15:04 AM, you wrote:

>> people that make critique on haskell type classes, don't take into
>> account that it's unlike C++ templates, implemented via run-time
>> dictionaries and other modules may define new instances
>>

> Personally, I have no clue how C++ templates work [yet]. (As in, I'm

they are known as generics in java/c#

But they don't behave the same way.
 


--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Very silly

Tony Morris
In reply to this post by Bulat Ziganshin-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bulat Ziganshin wrote:

> Hello Andrew,
>
> Tuesday, October 14, 2008, 12:15:04 AM, you wrote:
>
>>> people that make critique on haskell type classes, don't take into
>>> account that it's unlike C++ templates, implemented via run-time
>>> dictionaries and other modules may define new instances
>>>  
>
>> Personally, I have no clue how C++ templates work [yet]. (As in, I'm
>
> they are known as generics in java/c#
>
>
Except they're not. Java Generics are something else altogether.

- --
Tony Morris
http://tmorris.net/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI88ydmnpgrYe6r60RAinKAKCeuK7gQovCyNsdDg9E0j0uBxQymACgrZIW
oVuW1DBpepVxF9sXlKoRIbU=
=jv6U
-----END PGP SIGNATURE-----

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Very silly

Tommy M. McGuire
In reply to this post by Andrew Coppin
Andrew Coppin wrote:

> Bulat Ziganshin wrote:
>> people that make critique on haskell type classes, don't take into
>> account that it's unlike C++ templates, implemented via run-time
>> dictionaries and other modules may define new instances
>
> Personally, I have no clue how C++ templates work [yet]. (As in, I'm
> learning C++, but I haven't got to that chapter yet.)
>
> Some guy told me that templates are "the best feature in the language",
> and proceeded to show me a huge chunk of highly complex-looking code
> which is approximately equivilent to
>
>  join :: Array x -> Array x -> Array x
>
> I was unimpressed.
>
> Actually, that's a lie. I was impressed that such a low-level language
> could manage even that much abstraction. But I still prefer the Haskell
> way...

C++ values have sizes:

   class foo {
     int x;
   };

is half (ahem; make that "different from") the size of

   class bar {
     int x;
     int y;
   };

As a result, doing parametric polymorphism requires duct taping
something suspiciously similar to cpp macros to the type system.  Hence,
how C++ templates work: weirdly.

Java (and presumably C#) "generics" are very much like a weakened
version of normal parametric polymorphism.  C++ templates are an attempt
at the same thing in a completely different landscape.  I'd be willing
to bet that Some Guy's code was very close to exactly equivalent to your
join.

Now, as to what C++ templates have to do with Haskell type classes, I
dunno...

--
Tommy M. McGuire
[hidden email]
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Very silly

Jason Dagit-2


On Mon, Oct 13, 2008 at 8:32 PM, Tommy M. McGuire <[hidden email]> wrote:

Java (and presumably C#) "generics" are very much like a weakened version of normal parametric polymorphism.

I'm curious, in what way are they weakened?

thanks,
Jason


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Very silly

Brad Larsen
In reply to this post by Tommy M. McGuire
On Mon, 13 Oct 2008 23:32:30 -0400, Tommy M. McGuire <[hidden email]> wrote:

> Andrew Coppin wrote:
>> Bulat Ziganshin wrote:
>>> people that make critique on haskell type classes, don't take into
>>> account that it's unlike C++ templates, implemented via run-time
>>> dictionaries and other modules may define new instances
>>
>> Personally, I have no clue how C++ templates work [yet]. (As in, I'm
>> learning C++, but I haven't got to that chapter yet.)
>>
>> Some guy told me that templates are "the best feature in the language",
>> and proceeded to show me a huge chunk of highly complex-looking code
>> which is approximately equivilent to
>>
>>  join :: Array x -> Array x -> Array x
>>
>> I was unimpressed.
>>
>> Actually, that's a lie. I was impressed that such a low-level language
>> could manage even that much abstraction. But I still prefer the Haskell
>> way...
>
> C++ values have sizes:
>
>    class foo {
>      int x;
>    };
>
> is half (ahem; make that "different from") the size of
>
>    class bar {
>      int x;
>      int y;
>    };
>
> As a result, doing parametric polymorphism requires duct taping
> something suspiciously similar to cpp macros to the type system.  Hence,
> how C++ templates work: weirdly.
>
> Java (and presumably C#) "generics" are very much like a weakened
> version of normal parametric polymorphism.  C++ templates are an attempt
> at the same thing in a completely different landscape.  I'd be willing
> to bet that Some Guy's code was very close to exactly equivalent to your
> join.
>
> Now, as to what C++ templates have to do with Haskell type classes, I
> dunno...

In the next C++ standard, type checking capabilities are being added to templates---"concepts" specify a set of operations a templated type must support.  See <http://en.wikipedia.org/wiki/C%2B%2B0x#Concepts>.  Seems somewhat similar to Haskell typeclasses to me, but perhaps the similarity is merely superficial. :-)

Regards,
Brad Larsen
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Very silly

Luke Palmer-2
On Mon, Oct 13, 2008 at 11:31 PM, Brad Larsen <[hidden email]> wrote:
> In the next C++ standard, type checking capabilities are being added to templates---"concepts" specify a set of operations a templated type must support.  See <http://en.wikipedia.org/wiki/C%2B%2B0x#Concepts>.  Seems somewhat similar to Haskell typeclasses to me, but perhaps the similarity is merely superficial. :-)

A professor of mine, Jeremy Siek, was a major proponent of concepts on
the design committee.  If I recall correctly, he mentioned Haskell
typeclasses as a direct inspiration.  Incidentally, Concepts will
flaunt more features than typeclasses to CEOs everywhere because C++
does not have inference to worry about   (and already has an
undecidable compile time, so what would it have to lose?).

Luke
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Very silly

Tommy M. McGuire
In reply to this post by Jason Dagit-2
Jason Dagit wrote:
> On Mon, Oct 13, 2008 at 8:32 PM, Tommy M. McGuire <[hidden email]
> <mailto:[hidden email]>> wrote:
>     Java (and presumably C#) "generics" are very much like a weakened
>     version of normal parametric polymorphism.
>
> I'm curious, in what way are they weakened?

That's a good question. :-)

I picked up the idea while reading Java Generics and Collections, but I
can no longer find the part that *gave* me the impression.  I suspect
that it is due to the type erasure vs. array runtime typing issues.

It may be the case that basic generics are identical to plain parametric
polymorphism, and that the wildcard expressions attempt to serve the
same purpose (with considerable divergence) as type classes and
existential types.  But I don't know since my brains have apparently
turned to oatmeal.

--
Tommy M. McGuire
[hidden email]
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Very silly

Juan Carlos Arevalo Baeza-2
In reply to this post by Andrew Coppin
Andrew Coppin wrote:
> Some guy told me that templates are "the best feature in the
> language", and proceeded to show me a huge chunk of highly
> complex-looking code which is approximately equivilent to
>
>  join :: Array x -> Array x -> Array x
>
> I was unimpressed.

  Now I'm curious to know what chunk of code he showed you. FWIW, that
declaration you put there is done in C++ like so:

template < typename X >
Array<X> join(Array<X> const&, Array<X> const&);

  Nothing more. I like both languages for very different reasons. C++
for its insane amount of flexibility, and Haskell for its
expressiveness. And I've encountered equally harsh roadblocks in both
whenever I try to get "too crazy" while using them.

> Actually, that's a lie. I was impressed that such a low-level language
> could manage even that much abstraction. But I still prefer the
> Haskell way...

  The dynamic range of the C++ language is probably unparalleled. In
particular, templates enable implementing high level abstractions in a
way such that we're still discovering how far it can go. But of course,
it's not just templates: it's templates when united to all other
language features like overloading.

  Maybe I can take a crack at my own comparison of simple polymorphism
between C++ and Haskell.

C++:
   template < typename A > struct B { A m; }; // Polymorphic type
definition
   template <> struct B<bool> { int m; }; // Polymorphic type
specialization
   template < typename A > struct B<B<A> > { A m; }; // Polymorphic type
partial specialization
   template < int N > struct B<int[N]> { int m[N]; }; // Non-type
polymorphic parameters
   template < typename A > struct C { typedef B<B<A> > type; }; //
Polymorphic type aliases (type functions) must use trickery and bad syntax
   B<int> const b = { 8 }; // Declare object of polymorphic type
   template < typename A > A get(B<A> const& b) { return b.m; } //
Polymorphic function using polymorphic type
   int get(B<int> const& b) { return b.m + 1; } // Specialization of
polymorphic function (actually, it is an overload - functions can't be
specialized, but this is nearly equivalent)
Haskell:
   data B a = B { m :: a } -- Polymorphic type definition
   // Polymorphic type specializations not available
   // Non-type polymorphic parameters not available (must emulate using
Peano and such)
   type C a = B (B a) -- Polymorphic type aliases (type functions)
   let b = B 8 :: B Int in -- Declare object of polymorphic type
   get :: B a -> a; get b = m b -- Polymorphic function using
polymorphic type (declaration and definition separate)
   // Specialization of polymorphic function not available without
putting the function in a type class

  C++ templates are clearly more flexible, but they are also a lot
clunkier to use (and both things are very much related). If you look at
the specializations, and understand them, you'll see that it's easy to
make a specialization that is incompatible with the main parametric
(template) type definition. Sometimes, that's a good thing. I've created
main templates that purposefully fail to compile when used, as a means
to detect types that need their own particular specialization. But it's
easy to see how they can have... unexpected consequences. For instance:

B<B<int> > const bint = { 7 };
B<int> const bintresult = get(bint); // Compiler error! Can you see why?
A specialization is to blame.

  But the main hurdle is that a template's definition is partially
untyped. Type-checking of the innards of a template is finalized at the
time the template is invoked, at which point it is too late for the
compiler to root-cause any failures it encounters. Thus, using complex
template-based libraries can be quite inconvenient if you don't get
things right on your first try. For instance:

C++:
   template < typename A > bool compare(B<A> const& b1, B<A> const& b2)
{ return b1.m == b2.m; }; // Another polymorphic function
   B<SomeType> val;
   compare(val, val); // This gives out horrible errors if SomeType
doesn't have the equality operator defined
Haskell:
   compare :: Eq a => B a -> B a -> Bool; compare b1 b2 = m b1 == m b2
-- Another polymorphic function
   let val = ... :: B SomeType in
   compare val val // This Complains if SomeType is not an instance of Eq

  This is a silly example, and the C++ errors you get are not quite so
bad. But they can get really, really bad. The new C++ standard they are
finalizing will "fix" this by adding concepts (akin to type classes) and
concept_maps (akin to instances). It is interesting to realize, though,
that in C++, templates must all be resolved at compile time,  whether
they use concepts or not. There's never any dictionary-passing happening
anywhere, and all polymorphic functions must be specialized for all the
different types that are used with them. For runtime polymorphism, C++
uses OO classes which are completely separate. OO classes are in some
way like Haskell classes, but the dictionaries must be embedded in the
objects themselves, whereas Haskell classes pass the dirctionaries into
polymorphic functions separately. If a class is a salad, and the
dictionary is the dressing, then C++ serves the dressing in the salad,
and Haskell serves it on the side. The main consequence for this is
that, in C++, class instances must be attached at the point of declaring
the type, whereas in Haskell, you can do it after the fact.

  Maybe this is not quite so clear or useful after all. One-liners can
be quite obtuse. And the craziness with templates shines when you
combine them with various other features of the language. You can even
make things like Boost.Proto
(http://boost-sandbox.sourceforge.net/libs/proto/doc/html/index.html),
which is a library for creating arbitrary DSLs in C++.

JCAB


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Very silly

Andrew Coppin
In reply to this post by Andrew Coppin
Juan Carlos Arevalo Baeza wrote:

> Andrew Coppin wrote:
>> Some guy told me that templates are "the best feature in the
>> language", and proceeded to show me a huge chunk of highly
>> complex-looking code which is approximately equivilent to
>>
>>  join :: Array x -> Array x -> Array x
>>
>> I was unimpressed.
>
>   Now I'm curious to know what chunk of code he showed you. FWIW, that
> declaration you put there is done in C++ like so:
>
> template < typename X >
> Array<X> join(Array<X> const&, Array<X> const&);
>
>   Nothing more. I like both languages for very different reasons. C++
> for its insane amount of flexibility, and Haskell for its
> expressiveness. And I've encountered equally harsh roadblocks in both
> whenever I try to get "too crazy" while using them.

Well no, he included the implementation as well as just the signature.

>> Actually, that's a lie. I was impressed that such a low-level
>> language could manage even that much abstraction. But I still prefer
>> the Haskell way...
>
>   The dynamic range of the C++ language is probably unparalleled. In
> particular, templates enable implementing high level abstractions in a
> way such that we're still discovering how far it can go. But of
> course, it's not just templates: it's templates when united to all
> other language features like overloading.

C++ has some interesting ideas. I haven't learned how to use templates
yet, but what I do find interesting is that there is no automatic memory
management, and yet you can still do fairly dynamic programming. I've
never seen any other language that allows this. (I had assumed it's
impossible...) This makes me wonder just now necessary GC really is, and
whether there is some way to avoid it...

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Very silly

Alex Queiroz-2
Hallo,

Andrew Coppin wrote:
>
> C++ has some interesting ideas. I haven't learned how to use templates
> yet, but what I do find interesting is that there is no automatic memory
> management, and yet you can still do fairly dynamic programming. I've
> never seen any other language that allows this. (I had assumed it's
> impossible...) This makes me wonder just now necessary GC really is, and
> whether there is some way to avoid it...
>

     Garbage collection was invented by Lisp implementors because of a
common pattern in functional languages: The sharing of parts of
structures, like lists. In an imperative world this is straightforward,
one allocates a linked list, uses it, and then releases the memory. In a
world full of closures that may have captured parts of your list, manual
memory management is near impossible.

-alex
http://www.ventonegro.org/
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Very silly

Don Stewart-2
asandroq:

> Hallo,
>
> Andrew Coppin wrote:
> >
> > C++ has some interesting ideas. I haven't learned how to use templates
> > yet, but what I do find interesting is that there is no automatic memory
> > management, and yet you can still do fairly dynamic programming. I've
> > never seen any other language that allows this. (I had assumed it's
> > impossible...) This makes me wonder just now necessary GC really is, and
> > whether there is some way to avoid it...
> >
>
>      Garbage collection was invented by Lisp implementors because of a
> common pattern in functional languages: The sharing of parts of
> structures, like lists. In an imperative world this is straightforward,
> one allocates a linked list, uses it, and then releases the memory. In a

This is why memory management is a notoriously trivial problem in C++ ;)

-- Don (who thinks that complicated access patterns aren't unique to FP)
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Very silly

Dan Weston
Not that I want or need to defend C++ on this list, but
reference-counted smart pointers (e.g. boost::shared_ptr<>), embedded
inside copy-on-write proxy classes, largely simulates eager garbage
collection. Targeted overriding of the new operator can make this lazier
for efficiency.

In other words, there are well established idioms in most successful
languages to solve obvious problems. Haskell's strengths are more in
making these idioms simple and robust enough for the average user, not
just the guru, and to make difficult or impossible the misuse of unsafe
idioms.

Dan

Don Stewart wrote:

> asandroq:
>> Hallo,
>>
>> Andrew Coppin wrote:
>>> C++ has some interesting ideas. I haven't learned how to use templates
>>> yet, but what I do find interesting is that there is no automatic memory
>>> management, and yet you can still do fairly dynamic programming. I've
>>> never seen any other language that allows this. (I had assumed it's
>>> impossible...) This makes me wonder just now necessary GC really is, and
>>> whether there is some way to avoid it...
>>>
>>      Garbage collection was invented by Lisp implementors because of a
>> common pattern in functional languages: The sharing of parts of
>> structures, like lists. In an imperative world this is straightforward,
>> one allocates a linked list, uses it, and then releases the memory. In a
>
> This is why memory management is a notoriously trivial problem in C++ ;)
>
> -- Don (who thinks that complicated access patterns aren't unique to FP)
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe