🚀 go-pugleaf

I'd like to add a few extra comments on Steve Sullivan's questions.

> 2.  How can I get a function to remember state?

The generic answer, which Jacques didn't explicitly state, is to use
a ref (or array) declared in a scope wider than the function -- so it
can outlive individual function calls.

> 3. Why not allow nonlinear patterns?  They wouldn't have to cover
> the whole general matching problem - just allow, for example,
>    fun (x,x) = ...
> to bind the first x, and then fail if the second x doesn't match.

I've never felt that there's a good answer to this question.  Unlike
Jacques, I am quite happy to generalise to curried functions and view
    fun f x x = ...
as distinct from
    fun f x = fn x => ...
or anything else.  In essence, there is an implicit scope running across
the pattern.

Obviously it introduces implicit equality tests.  This is a very good
thing in my view & far clearer and more concise than explicit conditional
tests.  In addition, I'd like SML to have included "guards" on clauses in
the style of Miranda.

> 4. Why not lazy functions?  Seems lazy and strict evaluation
> could be mixed, with functions being lazy by default, and 
> strict if:
>   - they used any imperative features
>   - they used any function which is strict

It is difficult to get good quality performance out of fully lazy systems.
Hybrid systems (such as HOPE) haven't met with much interest since they
omit the kind of capabilities that makes laziness interesting.  Furthermore,
lazy systems have hard-to-follow dynamic properties.  This makes debugging
very difficult and giving bounds on space and time very hard.

These considerations mean that the decision to go "fully lazy" or not
is a big and mostly irrevocable one.  The partially lazy solution you 
suggest would be vile to work with when you wanted to move from functional
to imperative implementations (even more than in SML!) because the
laziness property would vanish.  

The second part of the suggestion isn't
properly thought out -- the strict function might be protected by a 
conditional or a lambda form, to name the most obvious cases -- and would
lead to bizarre and undesirable results.  The extensive work on strictness
analysis takes the idea behind this suggestion and analyses it deeply.
You may like to follow this research thread up if you are interested in
getting good performance out of fully lazy systems.

Steve