On Sat, Dec 09, 2006 at 07:20:41PM +0000, dfeustel@mindspring.com wrote:
I have now determined to my satisfaction that Hugs98-plus-Sept2006 has initialization problems concerning Prelude.hs and the use of the -P option. These problems may be peculiar to the port of Hugs to OpenBSD. In any event I have started poking around with gdb to try to figure out what's going on. (I actually can induce hugs to recognize the various prim functions that I initially had trouble with, but it's clear that Prelude processing does not work exactly as documented.)
I guess that you're trying to add /usr/lib/hugs/packages/hugsbase/Hugs to the search path.
The path above is part of the default search path for Prelude.hs. What I have discovered is that þugs, invoked with no arguments, initializes itself differently depending upon the presence or absence of Prelude.hs in the $HOME directory. With Prelude.hs *not* present in $HOME, I get the behavior described in the original post. When Prelude.hs *is* present in $HOME, then an error re loading Prelude.hs is reported, and primMinInt/primMaxInt/primMaxChar all work and the prompt is 'Hugs.Prelude>'.
This isn't supposed to work, because that directory isn't the root of a module hierarchy: each file X.hs in there contains a module Hugs.X, not X. It's the parent of that directory that is a module hierarchy, and it's already in the search path.
If you're determined to use these prim* functions (though you shouldn't because they're internal, and there are Haskell 98 equivalents of each of them), you can approximate the pre-2002 Hugs Prelude with
Hugs> :m Hugs.Prelude Hugs.Prelude> primMaxInt 2147483647
There are no guarantees that it will work in the future, though.