|
![](/i/fill.gif) |
>> Of course, the main one is that it's a 100% functional language
>
> I thought that a 100% functional language has no mutable data structures
> nor functions with side-effects.
Technically, Haskell is such a language. Technically, a Haskell program
itself doesn't produce any side-effects, it just constructs a data
structure and passes it to the Haskell Runtime System. The Haskell
Runtime System is what performs these side-effects.
That may sound like splitting hairs, since any compiled, runnable
Haskell program consists of your source code AND the Runtime System,
running as a single OS entity. In practical terms, you can "in effect"
mutate things in Haskell, and cause other side-effects. (This is of
course quite deliberate.)
Most "functional" languages allow you to perform side-effect anywhere,
any time you like. It is up to you to not screw this up. Haskell is
genuinely different. All side-effects are tightly constrained and
controlled, and the system provides strong guarantees about them. This
is why I feel it is justified to describe Haskell as "purely functional".
(That and the fact that it clearly has no OO features, no relational
features, no logical features, etc. It's definitely not mixed with any
other paradigm.)
>> C++ has templates, and people often compare this to generics. I'm not
>> sure why. As far as I can tell, templates not even remotely similar to
>> generics.
>
> Yeah, templates are a lot more powerful and versatile.
This was my conclusion also.
> Templates are not used only to generate classes, but also functions and
> basic types.
Yes, I was simplifying. (The paragraph was already bigger than I would
have liked, given the simplicity of the basic point I was attempting to
express.)
> In short, templates allow compile-time polymorphism (as opposed to runtime
> polymorphism in most OO and functional languages).
Seems like a nice way to sum it up.
I also forgot to mention Template Haskell. This GHC extension allows you
to run arbitrary Haskell code inside the compiler. It can [in principle]
do anything normal Haskell code does - read files, open network sockets,
etc. But it can also do things to the compiler - most obviously, it can
generate source code and feed it into the compiler.
You could use this to (for example) read a text file containing a BNF
grammer and generate the source code for a parser for it. But then, you
could do that without TH; just save the source code as a text file and
then compile it as a seperate step. The interesting part is that TH can
query the compiler. For example, it can read the description of a
datatype and write some boilerplate code for it. (But hey, if you need
to write boilerplate, doesn't that just mean that your language sucks?)
C has cpp, which (as far as I know) is very primitive and not
Turing-complete. C++ has templates, which are quite sophisticated.
Haskell has TH, which is obviously Turing-complete. I have no idea how
Lisp macros work, so I can't compare. (I believe Lisp macros can
generate code at runtime, however, which TH definitely cannot do.)
Post a reply to this message
|
![](/i/fill.gif) |