🚀 go-pugleaf

In article <BxrLnJ.A53@csn.org> sullivan@teal.csn.org (Steve Sullivan) writes:

 > 2.  How can I get a function to remember state?
 > 
 > In particular, I want to write a random number
 > generator that remembers it's last seed,
 > so the caller doesn't have to provide it.  Many modern
 > generators require hundreds of bytes of state info, so passing
 > that in and out on each call is very inefficient.
 > 
 > Simple example - how to get sml to do something like:
 > 
 > fun rand 1 = let val seed = ref 1 in !seed end   (* initialize and return 1 *)
 >   | rand 2 = (seed := (xx*seed) mod yy; !seed;)  (* update seed, return it *)
  That is just a problem of scoping. You need to have seed defined in
your two parts. This way it works.

	val rand = let val seed = ref 1 in
		fn 1 => (seed := 1; !seed)
		 | 2 => (seed := (xx*(!seed)) mod yy; !seed)
		end;

 > 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.
  That might be a good idea. However there might be some difficulties.
	1) You can't extend it to curried functions, like
		fun eq x x = true | eq _ _ = false;
	   because you risk incoherences : (fn x x => true) becomes
	   different from (fn x => fn x => true).
	2) You are hiding an equality test. It will often be clearer
	to have it explicit.

 > 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
   That could be interesting. But you need a totally different
compilation scheme. Some MLs (Caml for instance) have data lazyness.
That is, some data structures are calculated only when looked for. It
is not as strong as what you describe, but can be useful.

Regards,	Jacques
--
---------------------------------------------------------------------------
Jacques Garrigue	University of Tokyo	garrigue@is.s.u-tokyo.ac.jp
	Inf. Sc.	Ecole Normale Superieure,Paris  garrigue@dmi.ens.fr

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