- Hugs-Users - Haskell.org

ANNOUNCE: Hugs interim release
by ross＠soi.city.ac.uk 12 Mar '05

12 Mar '05

Chasing the Jones's, we are pleased to announce an interim release of Hugs98, primarily targeted at Unix systems to gain experience with new features, especially Cabal. It is available from the Hugs web page: http://www.haskell.org/hugs/ The new Cabal-based library build system has the potential to make building on Windows easier, but it's not there yet. Volunteers welcome. Feature highlights of this new release are: - The default current module is now the empty module Hugs.Base instead of the Prelude. - The Char type and the Char module now support Unicode as specified in the Haskell 98 Report (contributed by Dmitry Golubovsky). - The new -X option groups several options into one argument. - The syntax of the ffihugs command has changed: the +G and +L options are gone, and a new +i option can be used to specify include files. - Hugs now has basic support for Cabal. - Numerous bug fixes since the previous major release in Nov 2003. The home page for Hugs is at http://haskell.org/hugs. Send email to hugs-users-request(a)haskell.org to join the hugs-users mailing list. Bug reports should be sent to hugs-bugs(a)haskell.org. Send email to hugs-bugs-request(a)haskell.org to subscribe to the hugs-bugs list. ------------------------------------------------------------------------------ The Hugs 98 system is Copyright (c) Mark P Jones, Alastair Reid, the Yale Haskell Group, and the OGI School of Science & Engineering at OHSU, 1994-2005, All rights reserved. It is distributed as free software under the license in the file "License", which is included in the distribution. ------------------------------------------------------------------------------

1 0

isDigit problem
by Nicola Whitehead 09 Mar '05

09 Mar '05

Hi, I've got a problem with parser primitives using Hugs. I have the standard code to define parsers for digits etc sat :: (Char -> Bool) -> Parser Char sat p = do x <- item if p x then return x else failure digit :: Parser Char digit = sat isDigit but when I try to run it I get the error Undefined variable "isDigit" It does the same for any of the isXXXX predicates. I´m completely flummoxed, so any help would be greatly appreciated. :( Thanks, Nik Dr Nik Freydís Whitehead University of Akureyri, Iceland ********************************************************************* Having the moral high ground is good. Having the moral high ground and an FGMP-15 is better. *********************************************************************

2 1

hugs, xterm and cygwin
by Doug McIlroy 01 Jan '05

01 Jan '05

Does anyone know a trick for exiting hugs when it's running in an xterm window in cygwin? Winhugs doesn't respond to Unix-style eof (ctl-D) and xterm doesn't support DOS-style eof (ctl-Z). A few stty hacks that I tried didn't help. Why xterm? Because it has screen-editing capability, which plain cygwin windows lack. Not being able to quit is a small, yet nuisancy, price for this benefit. Doug McIlroy

1 0

Avoiding use of the stack
by eoin.mcdonnell＠lineone.net 22 Nov '04

22 Nov '04

Hi, This is probably a simple question, but I sure don't know the answer. I'm dabbling with haskell at the moment and have hit a problem. I remember something from undergraduate school about how to write recursive functions so that they don't eat up stack space, and instead behave more like while loops (I think you had to convert them to tail-recursive forms?). I've tried different variations, and it appears that they're all using the stack and cause overflows when I expect that they wouldn't. All of these are okay on standard Hugs for n = 13000, but all except testR5 cause Control stack overflows for n = 14000. I thought that at least one of the forms of testR2, testR3 and testR4 would be recognised as tail-recursive, and executed as loops without using the stack. The stack overflow for n = 14000 appears to show me to be wrong. (For example, testR2 13000 works, but testR2 14000 gives a Control stack overflow). Can anyone help with this? I'd like to be able to process lists with over 14000 elements, so need some help. Thanks, Eoin module Test where import Numeric testR1 :: Integer -> Integer testR1 0 = 0 testR1 n = n + (testR1 (n-1)) testR2 :: Integer -> Integer testR2 n = testR2' 0 n testR2' :: Integer -> Integer -> Integer testR2' a 0 = a testR2' a n = testR2' (a+n) (n-1) testR3 :: Integer -> Integer testR3 n = testR3' n 0 testR3' :: Integer -> Integer -> Integer testR3' 0 a = a testR3' n a = testR2' (a+n) (n-1) testR4 :: Integer -> Integer testR4 n = testR4' (0,n) testR4' :: (Integer, Integer) -> Integer testR4' (a,0) = a testR4' (a,n) = testR4' (a+n,n-1) testR5 :: Integer -> Integer testR5 0 = 0 testR5 n = testR5 (n-1) -- end of module Test __________________________________________________________________ INTRODUCTORY OFFER! Tiscali Business Broadband for £15.99! http://www.tiscali-business.co.uk/broadband/?code=ZZ-MS-12KC

4 5

RE: [Hugs-users] Avoiding use of the stack
by eoin.mcdonnell＠lineone.net 18 Nov '04

18 Nov '04

Hi Scott, Thanks for your insight on this one. My test routines now work, and I now have a better understanding of this aspect of Haskell. Best regards, Eoin -----Original Message----- From: Scott Turner [mailto:p.turner@computer.org] Sent: 18 November 2004 16:32 To: hugs-users(a)haskell.org Cc: eoin.mcdonnell(a)lineone.net Subject: Re: [Hugs-users] Avoiding use of the stack On 2004 November 18 Thursday 06:15, eoin.mcdonnell(a)lineone.net wrote: > how to write recursive functions > so that they don't eat up stack space, and instead behave more like while > loops (I think you had to convert them to tail-recursive forms?). > testR2 :: Integer -> Integer > testR2 n = testR2' 0 n > testR2' :: Integer -> Integer -> Integer > testR2' a 0 = a > testR2' a n = testR2' (a+n) (n-1) You're on the right track. This is properly tail recursive. The remaining problem is that the argument (a+n) does not get evaluated during the processing of testR2'. So each successive call to testR2' is passed a larger expression such as testR2' (((((0+10)+9)+8)+7)+6) (6-1) Pattern matching causes the second argument to be evaluated. To ensure that the first argument is processed, you can use the $! operator. testR2' a n = (testR2' $! (a+n)) (n-1) which evaluates (a+n) before passing it to testR2'. Where you see stack overflow, it's actually a stack of + opeations rather than a stack of testR2' calls. __________________________________________________________________ INTRODUCTORY OFFER! Tiscali Business Broadband for £15.99! http://www.tiscali-business.co.uk/broadband/?code=ZZ-MS-12KC

1 0

Enquiry about Hugs Server API
by David Lo 28 Oct '04

28 Oct '04

Dear all, I'm new in Haskell. I need to port a haskell application written by someone else to be called by a .Net C# application. I read from Reid's website that Hugs Server API can be used to let C++ application to call Haskell. Are this solution still viable for latest version of Hugs ? Does anyone know how can I download this Hugs Server API dll's ? Any help will really be appreciated. Best Regards, David

1 0

Hugs prompt and definitions
by Per Johansson 04 Oct '04

04 Oct '04

Hello. Is it possible to make definitions such as x=1 at the Hugs prompt? -- Mr Per Johansson mail: Oljekvarnsgatan 14B, SE-414 65 Göteborg, Suede mobile phone: int +46 70 796 08 48 uri: http://per.johansson.name/ "it's a great idea, but possibly not, and I'm not being indecisive"

2 1

Hugs Extension Proposed: Introspection Patch (p. 2)
by Dimitry Golubovsky 26 Sep '04

26 Sep '04

This message has been split into two because of 5 kb message size limitations. (continued) interns.c anso has undergone serious changes. Most of the introspection primitives return values of certain fields of Hugs' storage objects wrapped as Integers, and the rest of processing is done in Interns.hs. In storage.[ch] along with new fields in Hugs object structures I changed the way internal variables are named. I implemented per-module internal variables counters, and now names of those variables are stored in the same way as regular variables' names. This is the most unfortunate part because strings table size grew significantly: I had to increase the setting in prelude.h for NUM_TEXT 10 times to be able to compile fptools. The reason for this change: I need those internal variables' names to be independent of the order modules are compiled, and of the number of modules compiled. I do not see the immediate solution of this problem. One possible solution might be to use the old way for variables that are not exported, and the new way for those exported (like implementations of instance methods and instance builders, but not every lifted lambda or supercombinator). Here are things I have not done yet or do not exactly understand how to implement them. These include kinds (I only use them to get arity), functional dependencies (I do not understand how the graph is structured), RANK2 (same reason). My final goals are to make it possible for a Haskell program to access information sufficient: a) externalize the Hugs' compilation results to be able to use them with alternative runtime b) create an external format for Hugs compilation results, so they might be loaded into Hugs and simulate the situation as Hugs has just compiled the source (i. e. how it is done in Java or Python). I would like to get feedback form the Hugs users community whether there is any interest in such an extension. PS As an example of using these primitives, I have written an experimental web-based application, "Hugs Insider": http://www.golubovsky.org/software/hugs-insider/article.html which allows to enter some Haskell code, and then runs a cross reference generator over bytecodes and other parts of Hugs storage (written in Haskell). Dimitry Golubovsky South Lyon, MI

1 0

Hugs Extension Proposed: Introspection Patch (p. 1)
by Dimitry Golubovsky 26 Sep '04

26 Sep '04

This message has been split into two because of 5 kb message size limitations. Dear list members, I am suggesting one more extension to Hugs: a set of introspection primitives. These primitives extend the existing Hugs.Internals module allowing a Haskell program see the internal structure of Hugs' compilation results. This may be used for various purposes such as externalization of Hugs' compilation results in some format and using them with alternative runtime. With the primitives proposed, such an externalization may be performed by a Haskell program, and the native part of Hugs does not need to be modified. Also Hugs may be further extended to be able to load precompiled functions/modules thus increasing the startup speed. URL of the diff file: http://www.golubovsky.org/software/hugs-insider/hugs98-intro.diff I have been working on these extensions since June 2004, and the diff file is against the July 11 CVS snapshot, but as I can see from cvs-hugs, there have not been any significant updates in the repository that might conflict with this patch. These extensions work only if enabled with --enable-internal-prims configure options. Here is the summary of what has been done so far. Internals.hs: added primitives to access almost all fields of Hugs' storage objects (classes, instances, tycons, etc.) Also some upper-level wrappers are provided to represent Hugs internal structures in a more convenient way. I followed the same pattern which was used for the Name type already present in Hugs.Internals. I extended the CellKind type definition adding more data constructors to represent not only Names, but also classes, instances, type expressions, etc. I added the whatIs primitive which does not require an IO monad (unlike classifyCell), but it operates with restricted set of cell kinds which I suppose do not vary over time, therefore IO monad is not needed. whatIs also does not have side effects because it never evaluates the cell whose kind it retrieves. I also fixed the Haskell representation of bytecode instructions (it looks like some Gofer stuff still was there) and added the DIGIT bytecode (same as CELL, used for BIGNUMs because I needed to distinguish between numbers that may go with the CELL instruction, and numbers that make up big integers). I improved the representation of the TABLE instruction: now it captures the names of tycon's variants. The FLOAT instruction was removed as it seems to no longer exist in Hugs. The TEST instruction now has a Cell as its operand rather than a Name (which is not sufficient to cover all the variants of TEST). Data types representing Module, Class, Instance, Tycon are made in the same way as the data type for Name - "opaque integers". Also toplevel functions were added providing convenient representation of Hugs' storage contents and improved printer for bytecodes. I added some fields to Hugs storage objects, including name.endCode which caused changes in the prototype and implementation of codeGen. (to be continued)

1 0

HaXML and winhugs
by Tom Spencer 23 Aug '04

23 Aug '04

Has anyone successfully installed HaXML for winhugs? I am having great difficulty at the moment. I think it may be because there is C++ code in some of the .hs file eg. parse.hs. I anyone has managed successfully an explanation would be very helpful. Thanks Tom Spencer

1 0