🚀 go-pugleaf

response to Wolfgang Grieskamp's shot across the bows of lazy languages:-

I guess there'll be plenty of other responses, so I'm not going into the
whole lazy versus eager thing.  Three points though:-

1)  WG's BOTTOM should of course be TOP, there isn't an absence of information
    (or a nonterminating construct), there's an excess of information (the
    function's type requires the argument to have type non-nil-list, the
    argument type is nil-list, the inferred type would have to have both
    pieces of information which pushes it straight to the top of the type
    lattice).  Mostly, I prefer to call this sort of thing ERROR rather
    than TOP or BOTTOM  but BOTTOM is just plain wrong.

2)  Almost all the code I've ever written has been splattered with "if you
    ever get here, generate an error". Hope+ even had the type ERROR 
   added to it to permit this style of programming. The flagship machine
   design included tag bits with every value, one of which indicated that
   the value had type "ERROR" and our parallel emulators implemented it.
    Most large software systems have this sort of programming, and we're
   quite happy when no errors are generated because those bits don't get
   executed.  Lazy languages allow this style of programming, just as
   imperative languages did, but eager languages effectively prevent it

3)  Why should it be assumed that the presence of a construct which, if
   evaluated, leads to an error or a nonterminating computation is a bug?
   I don't much like the original program, but if it's what the programmer
   intended there's no bug in it. For nice examples of bottom, some of us
   program with infinite lists all the time (and intentionally write
   non-terminating loops in imperative languages too). 

Tom Thomson