December 2006 - Hugs-Users

Re: [Hugs-users] Hugs98-plus-Sept2006
by dfeustel＠mindspring.com 10 Dec '06

10 Dec '06

> On Sat, Dec 09, 2006 at 05:23:34PM -0600, Mark Hills wrote: > > [patient explanation of how Hugs finds hierarchical modules] > > > > I only have two files named Prelude.hs, the one under base and the one > > under hugsbase. The one under base simply wraps the one under hugsbase > > (it imports it at the end), I'm assuming to allow the definitions to be > > Hugs-specific (since they use primitives) while still providing a > > standard location for the Prelude, in case you want to run your programs > > using a different Haskell system like GHC. > > Another reason for a separate Hugs.Prelude is that it exports some > extra things. This is because Haskell 98 has the Prelude and some > other library modules import each other, and Hugs does not support > mutually recursive modules, I ran into the mutual recursion error when I attempted to load the GS.hs provided for _The Haskell Road..._. The term generating the error was 'case' although there was no instance of that word in GS.hs. I still have a lot to learn about how Hugs works. Dave > so it simulates it by having the Prelude > and the other modules import another module with the real definitions > (Hugs.Prelude). Also, Prelude.hs is shared code with GHC, except for > the imports (courtesy of cpp).

1 0

Re: [Hugs-users] Hugs98-plus-Sept2006
by dfeustel＠mindspring.com 10 Dec '06

10 Dec '06

> On Sat, Dec 09, 2006 at 11:11:21PM +0000, dfeustel(a)mindspring.com wrote: > > the 'find' command does not find a file by the name of Hugs.Prelude anywhere > > in the Hugs98 tree or in /usr/local/lib/hugs, nor in the default path, as far > > as I can tell. There are, þowever, 5 different instances of Prelude.hs in the > > Hugs98 tree. Why is there more than 1 instance of Prelude.hs (with different > > contents to boot) in Hugs98 source? > > % find /usr/local/lib/hugs -name Prelude.hs | xargs grep ^module > /usr/local/lib/hugs/packages/hugsbase/Hugs/Prelude.hs:module Hugs.Prelude ( > /usr/local/lib/hugs/packages/base/Prelude.hs:module Prelude ( > > They are different modules, with the second (the Prelude, as defined > in Haskell 98) importing the first (Hugs.Prelude, the internal Hugs > implementation). The search path contains /usr/local/lib/hugs/packages/*, > so when asked to load module A.B.C, Hugs looks for As I read more of the Hugs documentation, I am getting the impression that the documentation terms are changing to reflect a change in the software organization. > > (section 2.2 of the Hugs User's Guide) The point is that if the file > thus found does not describe itself as module A.B.C, the load will fail. > Now plug Hugs.Prelude and Prelude into the above, and we get the behaviour > you are seeing. The problem is that you have a file Prelude.hs in your > search path that does not start with "module Prelude". The Prelude.hs in my $HOME is a copy of the Prelude.hs in packages/hugsbase/Hugs/Prelude.hs - the 65355 char version. (Note the difference in file sizes. It looks like the small Prelude.hs is just the Hugs.Prelude module.) find . -name Prelude.hs -ls 65355 Dec 8 18:51 ./packages/hugsbase/Hugs/Prelude.hs 4100 Dec 8 18:51 ./packages/base/Prelude.hs Dave

1 0

Re: [Hugs-users] Hugs98-plus-Sept2006
by dfeustel＠mindspring.com 09 Dec '06

09 Dec '06

> On Sat, Dec 09, 2006 at 09:38:37PM +0000, dfeustel(a)mindspring.com wrote: > > 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>'. > > You have a file called Prelude.hs containing a module Hugs.Prelude in > your current directory. When Hugs starts, it loads Hugs.Prelude, which > it finds in the default path, the 'find' command does not find a file by the name of Hugs.Prelude anywhere in the Hugs98 tree or in /usr/local/lib/hugs, nor in the default path, as far as I can tell. There are, þowever, 5 different instances of Prelude.hs in the Hugs98 tree. Why is there more than 1 instance of Prelude.hs (with different contents to boot) in Hugs98 source? > and then attempts to load Prelude from > Prelude.hs (because . is at the front of the search path). However this > file contains a module Hugs.Prelude, not the Prelude it was expecting, > and initialization fails. Initialization does not fail. Hug terminates when initialization fails. Initialization takes a different path when it encounters Prelude.hs in either $HOME or . directories. The alternate initialization path makes hug work as the Haskell book describes on page 13. Where is the module Hugs.Prelude found during hugs initialization, if not in Prelude.hs? > The error message when Hugs finds a file to contain the wrong module > could be better, though. I agree. Perhaps some standardization of terminology would help too. Dave

3 3

Re: [Hugs-users] Hugs98-plus-Sept2006
by Mark Hills 09 Dec '06

09 Dec '06

> Module names are built reflecting the directory structure, with separate > starting directories for different products. If you start Hugs and type > :set, you will see something like this for the search path: > > Search path : > -P.:{Home}/lib/hugs/packages/*:/usr/local/lib/hugs/packages/*:{Hugs}/packages/* > > So, each directory under lib/hugs/packages is added to the path, > including (for instance) base and hugsbase. The hugsbase directory > contains a Hugs directory, which contains a Prelude.hs file. Looking at > the file, you will see that it says it defines module Hugs.Prelude, > which makes sense since the file name is Hugs/Prelude.hs. Similarly with > Data.Map, which is under the base directory in file Data/Map.hs. > > I only have two files named Prelude.hs, the one under base and the one > under hugsbase. Same for me in /usr. I definitely got confused by the multiple instances of Prelude.hs in /usr and in Hugs98 source. I'm recovering. Thanks for the additional info (below). Dave > The one under base simply wraps the one under hugsbase > (it imports it at the end), I'm assuming to allow the definitions to be > Hugs-specific (since they use primitives) while still providing a > standard location for the Prelude, in case you want to run your programs > using a different Haskell system like GHC. > > Mark > > dfeustel(a)mindspring.com wrote: > >> On Sat, Dec 09, 2006 at 09:38:37PM +0000, dfeustel(a)mindspring.com wrote: > >> > >>> 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>'. > >>> > >> You have a file called Prelude.hs containing a module Hugs.Prelude in > >> your current directory. When Hugs starts, it loads Hugs.Prelude, which > >> it finds in the default path, > >> > > > > the 'find' command does not find a file by the name of Hugs.Prelude anywhere > > in the Hugs98 tree or in /usr/local/lib/hugs, nor in the default path, as far > > as I can tell. There are, þowever, 5 different instances of Prelude.hs in the > > Hugs98 tree. Why is there more than 1 instance of Prelude.hs (with different > > contents to boot) in Hugs98 source? > > > > > >> and then attempts to load Prelude from > >> Prelude.hs (because . is at the front of the search path). However this > >> file contains a module Hugs.Prelude, not the Prelude it was expecting, > >> and initialization fails. > >> > > > > Initialization does not fail. Hug terminates when initialization fails. > > Initialization takes a different path when it encounters Prelude.hs in > > either $HOME or . directories. The alternate initialization path makes hug > > work as the Haskell book describes on page 13. Where is the module Hugs.Prelude > > found during hugs initialization, if not in Prelude.hs? > > > > > >> The error message when Hugs finds a file to contain the wrong module > >> could be better, though. > >> > > > > I agree. Perhaps some standardization of terminology would help too. > > > > Dave > > _______________________________________________ > > Hugs-Users mailing list > > Hugs-Users(a)haskell.org > > http://www.haskell.org/mailman/listinfo/hugs-users > >

1 0

Re: [Hugs-users] Hugs98-plus-Sept2006
by dfeustel＠mindspring.com 09 Dec '06

09 Dec '06

> On Sat, Dec 09, 2006 at 03:32:22PM +0000, Neil Mitchell wrote: > > As for the primitive operations, you shouldn't use them, ever. If you > > want to add two things use (+). They are merely an internal > > implementation detail, which I guess should never have been available > > to the user in the first place, and now isn't. I guess its a shame > > that a book that is only 2 years old is out of date, perhaps you might > > want to contact the authors to give them this information, so they can > > put it on a web page or something and save other people this > > confusion. > > Yes, these were internal details of the Hugs implementation of the > Prelude, and shouldn't have been exposed. They were only ever visible > when the Prelude was the current module, and have been properly hidden > since the November 2002 release. > > But since they existed only to implement Haskell 98, there are always > Haskell 98 alternatives, e.g. minBound::Int for primMinInt, as already > mentioned. 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.) Dave Feustel

3 2

Re: [Hugs-users] Hugs98-plus-Sept2006
by dfeustel＠mindspring.com 09 Dec '06

09 Dec '06

> On Sat, Dec 09, 2006 at 07:20:41PM +0000, dfeustel(a)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.

2 1

Unload Module?
by unknown＠example.com 09 Dec '06

09 Dec '06

Is there any way to unload a module, effectively undoing the loading of that module? Thanks, Dave Feustel

2 1

Hugs98-plus-Sept2006
by unknown＠example.com 09 Dec '06

09 Dec '06

I am learning Haskell by reading the book _The Haskell Road to Logic, Maths and Programming_ and by using Hugs98_plus_sep2006 which I have downloaded, built and installed on my AMD 64-bit OpenBSD system. The books says that Hugs will show the prompt 'Prelude>' initially until a script is loaded. The version of Hugs installed on my system shows initially the prompt 'Hugs>' and invoking several functions (primMinInt, primMaxInt, etc.) generate the error message to be undefined. Does Hugs still exhibit the behavior described in the book, or is there a problem with the newly ported Hugs on my system? /home/daf}hugs __ __ __ __ ____ ___ _________________________________________ || || || || || || ||__ Hugs 98: Based on the Haskell 98 standard ||___|| ||__|| ||__|| __|| Copyright (c) 1994-2005 ||---|| ___|| World Wide Web: http://haskell.org/hugs || || Bugs: http://hackage.haskell.org/trac/hugs || || Version: September 2006 _________________________________________ Haskell 98 mode: Restart with command line option -98 to enable extensions Type :? for help Hugs> primMinInt ERROR - Undefined variable "primMinInt" Hugs> primMaxInt ERROR - Undefined variable "primMaxInt" Hugs> :names *prim*Int Hugs.Prelude.primCharToInt Hugs.Prelude.primCmpInt Hugs.Prelude.primDivInt Hugs.Prelude.primEqInt Hugs.Prelude.primIntegerToInt Hugs.Prelude.primMaxInt Hugs.Prelude.primMinInt Hugs.Prelude.primMinusInt Hugs.Prelude.primModInt Hugs.Prelude.primMulInt Hugs.Prelude.primNegInt Hugs.Prelude.primPlusInt Hugs.Prelude.primPmInt Hugs.Prelude.primQrmInt Hugs.Prelude.primQuotInt Hugs.Prelude.primRemInt Hugs.Prelude.primShowsInt (17 names listed) Hugs> primCharToInt 'a' ERROR - Undefined variable "primCharToInt" Hugs> Thanks, Dave Feustel

5 4

First Call for Papers: TFP 2007, New York
by TFP 2007 01 Dec '06

01 Dec '06

CALL FOR PAPERS Trends in Functional Programming 2007 New York, USA April 2-4, 2007 http://cs.shu.edu/tfp2007/ OR http://tltc.shu.edu/tfp2007/ The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming languages, focusing on providing a broad view of current and future trends in Functional Programming. It aspires to be a lively environment for presenting the latest research results through acceptance by extended abstracts. A formal post-symposium refereeing process then selects the best articles presented at the symposium for publication in a high-profile volume. TFP 2007 is co-hosted by Seton Hall University and The City College of New York (CCNY) and will be held in New York, USA, April 2-4, 2007 at the CCNY campus. SCOPE OF THE SYMPOSIUM The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: Research Articles leading-edge, previously unpublished research work Position Articles on what new trends should or should not be Project Articles descriptions of recently started new projects Evaluation Articles what lessons can be drawn from a finished project Overview Articles summarizing work with respect to a trendy subject Articles must be original and not submitted for simultaneous publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or more experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Articles on the following subject areas are particularly welcomed: o Dependently Typed Functional Programming o Validation and Verification of Functional Programs o Debugging for Functional Languages o Functional Programming and Security o Functional Programming and Mobility o Functional Programming to Animate/Prototype/Implement Systems from Formal or Semi-Formal Specifications o Functional Languages for Telecommunications Applications o Functional Languages for Embedded Systems o Functional Programming Applied to Global Computing o Functional GRIDs o Functional Programming Ideas in Imperative or Object-Oriented Settings (and the converse) o Interoperability with Imperative Programming Languages o Novel Memory Management Techniques o Parallel/Concurrent Functional Languages o Program Transformation Techniques o Empirical Performance Studies o Abstract/Virtual Machines and Compilers for Functional Languages o New Implementation Strategies o any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2007 program chair, Marco T. Morazan, at tfp2007(a)shu.edu. SUBMISSION AND DRAFT PROCEEDINGS Acceptance of articles for presentation at the symposium is based on the review of extended abstracts (6 to 10 pages in length) by the program committee. Accepted abstracts are to be completed to full papers before the symposium for publication in the draft proceedings and on-line. Further details can be found at the TFP 2007 website. POST-SYMPOSIUM REFEREEING AND PUBLICATION In addition to the draft symposium proceedings, we intend to continue the TFP tradition of publishing a high-quality subset of contributions in the Intellect series on Trends in Functional Programming. IMPORTANT DATES Abstract Submission: February 1, 2007 Notification of Acceptance: February 20, 2007 Registration Deadline: March 2, 2007 Camera Ready Full Paper Due: March 9, 2007 TFP Symposium: April 2-4, 2007 PROGRAMME COMMITTEE John Clements California Polytechnic State University, USA Marko van Eekelen Radboud Universiteit Nijmegen, The Netherlands Benjamin Goldberg New York University, USA Kevin Hammond University of St. Andrews, UK Patricia Johann Rutgers University, USA Hans-Wolfgang Loidl Ludwig-Maximilians Universität München, Germany Rita Loogen Philipps-Universität Marburg, Germany Greg Michaelson Heriot-Watt University, UK Marco T. Morazán (Chair) Seton Hall University, USA Henrik Nilsson University of Nottingham, UK Chris Okasaki United States Military Academy at West Point, USA Rex Page University of Oklahoma, USA Ricardo Pena Universidad Complutense de Madrid, Spain Benjamin C. Pierce University of Pennsylvania, USA John Reppy University of Chicago, USA Ulrik P. Schultz University of Southern Denmark, Denmark Clara Segura Universidad Complutense de Madrid, Spain Jocelyn Sérot Université Blaise Pascal, France Zhong Shao Yale University, USA Olin Shivers Georgia Institute of Technology, USA Phil Trinder Heriot-Watt University, UK David Walker Princeton University, USA ORGANIZATION Symposium Chair: Henrik Nilsson, University of Nottingham, UK Programme Chair: Marco T. Morazan, Seton Hall University, USA Treasurer: Greg Michaelson, Heriot-Watt University, UK Local Arrangements: Marco T. Morazan, Seton Hall University, USA ************************************************************************************ Dr. Marco T. Morazan TFP 2007 Program Committee Chair http://tltc.shu.edu/tfp2007/ http://cs.shu.edu/tfp2007/

1 0