🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: alt.lang.ml
Article #26

Re: ml questions

#26
From: Jacques Garrigue
Date: Mon, 16 Nov 1992 05:28
49 lines
2882 bytes
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
Technical Details
Message-ID: <1992Nov16.052852.29474@kei.is.s.u-tokyo.ac.jp>
Path: arc1-ca.pugleaf.net!sparky!uunet!europa.asd.contel.com!darwin.sura.net!spool.mu.edu!agate!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!cis.ohio-state.edu!rutgers!sun-barr!sh.wide!wnoc-tyo-news!ccut!s.u-tokyo!is.s.u-tokyo!garrigue
References: <BxrLnJ.A53@csn.org>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!europa.asd.contel.com!darwin.sura.net!spool.mu.edu!agate!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!cis.ohio-state.edu!rutgers!sun-barr!sh.wide!wnoc-tyo-news!ccut!s.u-tokyo!is.s.u-tokyo!garrigue
From: garrigue@is.s.u-tokyo.ac.jp (Jacques Garrigue)
Newsgroups: alt.lang.ml
Subject: Re: ml questions
Message-ID: <1992Nov16.052852.29474@kei.is.s.u-tokyo.ac.jp>
Date: 16 Nov 92 05:28:52 GMT
References: <BxrLnJ.A53@csn.org>
Sender: news@kei.is.s.u-tokyo.ac.jp (Usenet News System)
Organization: Dept. of Information Sc., University of Tokyo.
Lines: 49
In-Reply-To: sullivan@teal.csn.org's message of Sun, 15 Nov 1992 15:57:17 GMT
Nntp-Posting-Host: myriem