🚀 go-pugleaf

In article <SEWARDJ.92Jul26232657@r6.cs.man.ac.uk> sewardj@cs.man.ac.uk (Julian Seward (DRL PhD)) writes:
   | 1. The extra amount of work that has to be done in "forcing" the store.
   |    This bumps up the runtime.

   Hmm ... but not by much.

How can we know this?  All I committed myself to was that the runtime
increased.  I can't say by how much, as without forcing the store it
is either slower or doesn't fit in the available heap.  However,
intiution tells me that doing repeated full equality tests on 7 AVL
trees containing 10,000+ elements each cannot be a cheap operation :-)


   | 2. A simple, one-liner using higher order functions has turned into a
   |    10 line tail recursive loop.  Now being a Schemer at heart, I have
   |    no particular problem with this, but it does seem to go against the
   |    whole idea of "higher order functions are good" which most fp books
   |    espouse.

   I have a couple of comments on this.  Firstly, the problem
   is you are getting 000's of thunks.  The problem is *not*
   the use of a higher-order function.

Ah, but I never said it was.  All I pointed out was that a solution to
the problem involved removing the HOF and replacing with an explicit
loop.  If I hadn't have been a HOF in the first place, the solution
whouldn't have seemed such a drastic change.


   Even if you unfolded the definition of "foldl" at the
   parameterisation shown, the program would behave the same.

Actually it runs out of heap quicker than the foldl version.  I guess
foldl isn't being optimised by the compiler.


   ..., I believe the Haskell committee should
   consider the provision of two built-in functions:

      hyperstrict, whnf :: Eq a => a -> b -> b

   both of which evaluate their first argument (fully or to whnf)
   and return the second.  We can simulate this at the moment using
   Haskell 1.2, but it might be more efficient if compilers could
   regard these as primitive.

Doesn't this move us back into the realms of separate annotations.  I
thought many people don't like as there is too much opportunity for
the user to make a mistake i.e. "hyperstricting" everthing in sight in
the hope of efficiency.  Alternately couldn't you argue that as most
of the time you want strict evaluation, you'd be better off with a
language were that was the default and annotating it with "lazy" at
appropriate points? For example, I have a much better feel for where I'd
want a strict version to be lazy than I do about where I'd want a lazy
version to be strict.  Is this the mark of a novice lazy programmer?

That notwithstanding, if the above proposal means I can remove the
loop and replace it with one hyperstrict/whnf call in the
read_ASCII_Store definition, then I'm all for it (but then what do I
know :-)

bevan