post on liskell-devel by Jason Miller that implements a macro to give
Liskell better syntactic support for monads. In pure Liskell, programming with monads looks like
(>>= (getEnv "HOME")
(lambda (homepath)
(>>= (readFile (++ homepath "/.foobarrc"))
(lambda (content)
(process content)))))
As you can see the indention level piles up when you have a cuple of
expressions. Jason proposed an alternative syntax,
(do
(<- homepath (getEnv "HOME"))
(<- content (readFile (++ homepath "/.foobarrc")))
(process content))
He also posted the resulting macro code. I'm surprised and glad that
someone obviously can make sense of Liskell, even -- shame on me -- with the
little documentation I have made available.
At the moment, I'm pondering about the future of Liskell. The simple
question how to support 'eval' lead to a series of other questions. I
shouldn't be surprised that an eval/apply mechanism magically
complicates things just as any potentially self referential construct
does. But before I start to chat about trouble with supporting eval, the
benefits from eval are just too obvious from the Lisp world, that
Task #1 is to support eval at compile-time and run-time.
When using eval, you want the expression to evaluate in the current
module's compiler state, otherwise you would only be able to use bare naked
Liskell primitives expression without any syntax backed by parse tree
transformers. My current train of thinking goes into the direction of
modelling a compiler/universe state that pervades the boundary between
compile- and run-time. I might solve this by borrowing from Lisp
again. In the Lisp world, there are rarely object files nor linked
libraries (packages) as we have them in Haskell. The usual way of
conducting business is that you fire up a Lisp process and start to
load Lisp source files until you have all the code in the Lisp process
you need. Usually loading also compiles the code. When done, you dump
the hole process state to disk and reload it whenever you need to
restart the application. So, most Lisp dialects statically link the
code in the process image and -- more important -- there is no
distinction between compilation- and run-time. The state of the Lisp
process next to all the loaded code is also dumped and reloaded, hence
saved.
This method can not be ported to Haskell easily. There is only a
limited state concept in a Haskell compiler. The source code visible
state -- I don't mean compilation/optimization/code generation options
here -- is only the scope or environment. Importing modules and
defining new top-level function/variables modifies the
environment. But we can only extend the environment with more
knowledge and also this knowledge that must not contradict existing
knowledge (redefine functions or give multi-line equations with
different types).
As I was coding my little
toy Scheme compiler, I recognized that I wanted to modify the
compiler state when certain modules were imported. I had in mind that
SchemeCore would bring in the basic Scheme syntax constructs such as
(define-scheme ...). define-scheme defines functions
and variables with Scheme semantics separated in its own Scheme
sub-universe that Liskell code can enter via
runScheme. runScheme runs the SchemeMonad that
supports a global mutable environment, IO and also continuations -- so
callCC should be implementable here. Next to SchemeCore, I wanted to
create modules of Scheme code. When importing these modules, they
should modify the Scheme compiler state (not the Liskell/Haskell
compiler state) so that the Scheme functions compiled become part of
the global mutable environment. To make this vision reality, here is
Task #2: Liskell should feature an extensible mutable compiler
state (LiskellMonad?)
The LiskellMonad -- 'the universe monad' that might replace and embed
IO -- should support another feature I love about Lisp: hot code
swapping or code replacement as the Erlang camp calls it. The
LiskellMonad should support to replace top level definitions with new
code. To keep things tidy, the basic idea is to revert all evaluated
WHNF to thunks that in some way depend on expression changed. This
approach guarantees a consistent universe. Without reverting to
thunks, you might have two top-level expressions (define x (f
3)) and (define y (f 3)) that end up with different WHNF,
for instance whenever x was evaluated before your change to the
function f. Of course, we can't allow that to happen in a
pure universe. Task #3: allow mutable top-level definitions.
What we can't get right (at least not without a bit more work) is
crossing IO monad boundaries with that concept. Whenever you write the
result of (f 3) to a file and change the function f
later on, Liskell does not rerun the code that wrote the file content
(and also the user would be pretty surprised if it would do so). So by
definition, IO is a bit out of reach at the moment, but for a subclass
of IO operations we might be able to do it. These operations must not
have any visible side effects to the 'outside world', such as
putStr. If we exclude those operations, the only operations remain
that affect the 'inside world'. These IO operations could be rerun
quite easily, just think of Prelude.readFile, executing this twice
won't cause unintented behaviour. I'm not sure at the moment whether
this idea makes sense beyond Prelude.readFile, but it would have an
appealing similarity to STM's way of rerunning code.
And last but not least, the packaging issue is not solved for
Liskell. Simon Peyton-Jones suggested to make Liskell a user of GHC
API. GHC API needs to be modified to make a good host for Liskell, and
as we all know, forming good APIs takes time and a fair bit of
discussion. As Liskell is too experimental to flesh out a stable set
of API requirements, I think that it is the best option to distribute
Liskell as a modification to GHC. These modifications are confined to
the 'ghc' package. Creating a fork of this package is the best option
for the moment. Liskell can shared base/rts and all the other core
and auxiliary packages with a GHC installation.
I hope I can work through this task in the next few months. If you
have any reading suggestion with respect to existing design, I would
be happy for a few pointers.
Ah and yes, for the next few days, I will be in Freiburg attending ICFP07.
]]>