🚀 go-pugleaf

In article <1992Nov12.162725.25836@cs.yale.edu> jones-mark@CS.YALE.EDU (Mark P. Jones) writes:

   |  In general, in a lazy language, you are often at the mercy of the
   |  compiler to prove things about your code in order to obtain decent
   |  performance.

   But in a lazy language, you don't need to do a lot of the standard
   optimisations like tail recursion elimination, moving constants outside
   loops etc.  Laziness gets you those things for free! [...]

   |  Fortunately, in SML, you have better control over
   |  resources than in a lazy language,

   Unfortunately, you will often have to write extra code to control
   those resources...

   Yes, it is true that reasoning about the resources used by a program
   in a lazy language is more difficult than reasoning about a program in
   a strict language like SML.  But sometimes it's nice to be able to write
   code using a list without wondering whether I ought to write it with an
   explicit loop, or whether I should use a stream library instead, or ...
   I'm not criticising SML.  But Haskell (and lazy languages in general)
   have their nice points too.

I completely agree that a lot of the mess in writing programs comes
from orchestrating what gets computed when, and that it would be nice
to leave all that to the compiler. However, resource constraints mean
that I need more control than lazy languages currently give me, and,
as I mentioned before, I somehow remain doubtful that
compilers/runtime systems be able to make the right tradeoffs between
space and time in the near future.

I'd rather see a little more support added to eager languages for
lazyness and caching. In SML, you can already define many lazy
constructs like streams, thunks, and caches. Some improvements that
I would like to see are:

	* eliminate those weak type variables that come from
          the underlying imperative implementations

	* provide versions that use structural equality, hashing,
	  and comparisons (SML has polymorphic "=", but for some
	  obscure reason does not provide polymorphic "<" and
	  polymorphic "hash" to go with it)

	* make the syntax a little nicer; maybe I could declare
	  individual function arguments to be "lazy":

	  fun f(x: 'a lazy) = [x]
	  f(3+4) --> [thunk] : int lazy list

	* provide "dynamic contexts" for caching:

	  fun f(x) = ...

	  fun g() =
	      let
		  (* any call to "f" within this dynamic scope
	          is cached; the cache gets destroyed when this
		  dynamic context exits *)

                  dynamically_cache(f)
                  ...
	      in
		  ...
	      end

Anyway, just some suggestions (actually, you can experiment with such
constructs relatively nicely in CommonLisp or in Scheme with macros).

					Thomas.