>> 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