
First Class Statements - tel
http://blog.jle.im/entry/first-class-statements
======
shasta
This isn't exactly true. For example, the article names declaration and
assignment as among "statements", but such statements are not first class in
Haskell. Nor are type, data, type class statements, etc. It is true that
Haskell manages to accomplish many things with expressions that you'd use
statements for in other languages.

~~~
tel
Agreed, but there's a pretty straightforward distinction between statements
amenable to becoming values and those that aren't. Essentially, those which
control and define the type theory are out of scope as well as those which
introduce bindings.

~~~
dllthomas
I hope that "not amenable to becoming values" is a transient state...

~~~
tel
I'm not sure how I feel about it honestly. I suppose in a dependently typed
language there'd be some allowance for `IO Type`.

------
amelius
Somehow this doesn't seem correct. If statements were truly "first class", one
should be able to programmatically put statements together and execute them
(without using the loophole of simply calling the compiler).

~~~
wyager
> one should be able to programmatically put statements together and execute
> them

I'm not sure I understand. In Haskell, you _can_ programmatically put
statements together. You can't execute them willy-nilly just like how you
can't try to execute an integer in python. You just create make a statement
called "main" and the program is compiled so as to execute that statement.

~~~
comex
Apparently Haskell does have a plugin that lets you eval expressions at
runtime... from a string, though; is there a way to build an AST? (And what's
the performance like?) Lisp of course would let you do something like

    
    
        (do-something-with '(+ a b))
    

and do-something-with could do any arbitrary transformation on the AST,
possibly ending up passing it to eval, possibly optimizing it and compiling it
to some other language... while Haskell's a leap in this regard compared to
imperative languages, I think only something like Lisp can call its code truly
first-class.

~~~
dllthomas
There's two ways in which I'd like to address your questions here.

First, directly addressing the question you asked:

There are a number of libraries for assembling and manipulating a Haskell AST
- I would recommend looking at haskell-src-exts and Template Haskell.
Unfortunately, there doesn't seem to be a way to exec any of these directly
(at runtime). You could obviously pretty-print and then eval that, which may
or may not be a good fit depending on your problem space.

Separately, I would like to suggest a different perspective, in line with the
thesis of the article.

(Pardon me if this gets a bit rambly, and feel more than free to ask questions
if it gets confusing - I've been meaning to expand on this in a blog post...)

Haskellers are fond of monads. Lispers are fond of S-expressions. Lisp
programs are S-expressions. S-expressions are either an atom, or a list of
S-expressions - a structure also known as a "rose tree".

It turns out, a rose tree is a monad. In particular, a "free monad", which
means there's a unique function turning a rose tree into any other monad in a
way that preserves structure (in math terms, a "monad homomorphism"). Getting
slightly speculative, I think the homomorphism from Free to IO has to be
Lisp's eval.

So in a senes, when Haskellers write functions that operate on "Monad m", they
are writing functions that can operate on Lisp programs, and also on many
"partial interpretations" or "restricted forms" of Lisp programs. This is why
Haskell programmers get about as excited about monads as Lisp programmers do
about macros - there's a deep connection.

The big thing that Haskell lacks, in this context, is a mutable global
namespace - which keeps a few things compile-time only (and hence the need for
Template Haskell for fuller coverage of metaprogramming).

