- Haskell - Haskell.org

Forthcoming GHC 6.2 release
by Graham Klyne 09 Dec '03

09 Dec '03

I noticed your comment about the forthcoming GHC 6.2 release... Some time ago there was discussion of allowing alternative module names for containing the "main" function of a program, which I'm hoping to see in 6.2, per [1]. Are you expecting to release very soon? #g -- [1] http://www.haskell.org/pipermail/haskell/2003-June/012153.html ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

RE: Why are strings linked lists?
by Simon Marlow 09 Dec '03

09 Dec '03

> > GHC 6.2 (shortly to be released) also supports toUpper, toLower, and > the > > character predicates isUpper, isLower etc. on the full Unicode > character > > set. > > > > There is one caveat: the implementation is based on the C library's > > towupper() and so on, so the support is only as good as the > C library > > provides, and it relies on wchar_t being equivalent to Unicode (the > > sensible choice, but not all libcs do this). > > Now, why would one want to base this on C's wchar_t and its > "w" routines? Because it's easy, and it's still an improvement over what we had before. > wchar_t is sometimes (isolated) UTF-32 code units, > including in Linux, sometimes it is (isolated) UTF-16 code units, > including in Windows, and sometimes something utterly useless. Yes, I mentioned this above. > Please instead use ICU's UChar32, Thanks, I didn't know about ICU - it looks nice. I did briefly investigate libunicode, which turned out to be worse than the C library. Cheers, Simon

1 0

How do I sleep in Ghc?
by Ben_Yu＠asc.aon.com 09 Dec '03

09 Dec '03

Hi there, In Ghc, how do I sleep for say, 1 minute? I'm trying to write a simple file arrival listener and could not find the sleep api. Can haskell do it at all? Thanks. Ben. This message is intended only for the addressee and may contain information that is confidential or privileged. Unauthorized use is strictly prohibited and may be unlawful. If you are not the intended recipient, or the person responsible for delivering to the intended recipient, you should not read, copy, disclose or otherwise use this message, except for the purpose of delivery to the addressee. If you have received this email in error, please delete and advise us immediately.

5 4

show function question
by rui yang 09 Dec '03

09 Dec '03

Hi,everyone Suppose I have a function: compFix :: (F1,F2)->(F1,F2) which have functions as it's arguments and returns functions as it's results,here two arguments have types for example: type F1 = Int -> Bool type F2 = Int ->[Int] How should I define the instance declaration of Show class for my function type variables so that I can print the list of argument-result pairs out? Thanks Rui ---------------------------------------- This mail sent through www.mywaterloo.ca

1 0

RE: Why are strings linked lists?
by Simon Marlow 08 Dec '03

08 Dec '03

> Unless I'm missing something, the only "support" that GHC provides is > that Char is 4 bytes. GHC 6.2 (shortly to be released) also supports toUpper, toLower, and the character predicates isUpper, isLower etc. on the full Unicode character set. There is one caveat: the implementation is based on the C library's towupper() and so on, so the support is only as good as the C library provides, and it relies on wchar_t being equivalent to Unicode (the sensible choice, but not all libcs do this). Proper support for character set conversions in the I/O library has been talked about for some time, and there are a couple of implementations out there. I think ultimately this should be part of a complete redesign of the I/O library based around streams (see recent discussion on the libraries list). Cheers, Simon

2 1

RE: Why are strings linked lists?
by Simon Marlow 08 Dec '03

08 Dec '03

> But then... what trick does GHC use to prevent CAF leaks? No tricks really, the garbage collector traces references from code as well as references from the heap to find all the live data. Of course, it doesn't actually examine the code; each code segment comes with a list of top-level closures that it references, called an SRT (static reference table). In a standalone program, we know that only CAFs which are referenced by code which is reachable from the current machine state (i.e. the stack) will ever be used again. In an interpreted system it is more difficult: we don't know what expressions will be typed at the prompt in the future. Cheers, Simon

1 0

RE: Why are strings linked lists?
by Simon Marlow 08 Dec '03

08 Dec '03

> Even in unoptimized, byte-code compiled code? > > Take this module: > > module A where > > t :: IO () > t = sequence_ (repeat (return ())) > > If I :load it into ghci as interpreted, or if I compile it without > optimisation options, and I run t, then the process grows, and grows, > and grows, ... True, GHC does not garbage-collect CAFs when interpreting. This is partly intentional; we provide an option to turn off the behaviour (:set +r) although GHC is currently not capable of garbage collecting CAFs *during* evaluation when interpreting. > Of course, when I first compile it with -O2 option then it runs in > constant space. > > When I compiled Wojtek's code with -O2, the problem disappeared, so I > guess he was loading the module without compiling it with -O2 first. > > Shouldn't you rather say: GHC doesn't have CAF leaks in code compiled > with [insert the relevand optimisation option here] option? Just compiling the code (instead of running it in GHCi) is enough to prevent CAFs from leaking. You might get better space behaviour by optimising, however (or you might get worse space behaviour, but that's unlikely). Cheers, Simon

2 1

pattern-matching extension?
by Abraham Egnor 08 Dec '03

08 Dec '03

I've occasionally wanted some sort of equivalent of an instanceOf function in haskell, i.e. one that would let me define a function that could dispatch on the type of its argument as well as the value. One option I've seen for this is "http://okmij.org/ftp/Haskell/class-based-dispatch.lhs", but that unfortunately has the downside of requiring you to write both a constructor for PACK and an instance of Packable for each type you'd like to dispatch on. The thought occurred to me that it is (intuitively) natural to do this via extending the pattern-matching facility to include types as well as literal values, i.e. something like: f :: a -> String f (a :: Int) = "got an int, incremented: "++(show (a+1)) f (a :: Show q => q) = "got a showable: "++(show a) f _ = "got something else" This has a couple of nice features - it's a simple extension of the syntax, and acts as a sort of type-safe typecast. However, I have zero knowledge of how hard it would be to implement this, and there may be theoretical difficulties I haven't seen. Thoughts? Abe

5 5

incompatible signatur syntax within instance definition
by Christian Maeder 08 Dec '03

08 Dec '03

Hi, if I try to supply a signatur for the local function "showsl" below, then ghc rejects a constraint (Show a) whereas hugs (and nhc98) needs this constraint. What should be the correct notation? (apart from omitting any signature) Cheers Christian (BTW, I would appreciate if the (instantiated) signature of a class function could be given/repeated in an instance, but that's another matter.) hugs error message for "showsl :: List a -> ShowS" ERROR "MyList.hs":11 - Cannot justify constraints in explicitly typed binding *** Expression : showsl *** Type : List a -> ShowS *** Given context : () *** Constraints : Show a ghc error message for "showsl :: Show a => List a -> ShowS" ...../MyList.hs:10: All of the type variables in the constraint `Show a' are already in scope (at least one must be universally quantified here) In the type: (Show a) => List a -> String -> String While checking the type signature for `showsl' In the definition of `showsPrec': showsPrec _ l = (showString "[") . ((showsl l) . (showString "]")) where showsl :: forall. (Show a) => List a -> ShowS showsl (Cons x Nil) = shows x showsl (Cons x xs) = (shows x) . ((showString ",") . (showsl xs)) In the definition for method `showsPrec' Failed, modules loaded: none. module MyList where data List a = Nil | Cons a (List a) instance Show a => Show (List a) where showsPrec _ Nil = showString "[]" showsPrec _ l = showString "[" . showsl l . showString "]" where -- showsl :: List a -> ShowS -- for ghc -- showsl :: Show a => List a -> ShowS -- for hugs showsl (Cons x Nil) = shows x showsl (Cons x xs) = shows x . showString "," . showsl xs -- undefined for Nil module MyList where data List a = Nil | Cons a (List a) instance Show a => Show (List a) where showsPrec _ Nil = showString "[]" showsPrec _ l = showString "[" . showsl l . showString "]" where showsl :: List a -> ShowS -- for ghc -- showsl :: Show a => List a -> ShowS -- for hugs, nhc98 showsl (Cons x Nil) = shows x showsl (Cons x xs) = shows x . showString "," . showsl xs -- undefined for Nil

2 2

CFP --- FOAL 2004: Foundations of Aspect-Oriented Languages
by Ralf Laemmel 05 Dec '03

05 Dec '03

(* This field has meanwhile seen a number of contributions from the functional programming community. So it is fair to assume that the present announcement is of interest for subscribers of this list. *) FOAL: Foundations of Aspect-Oriented Languages A one day workshop affiliated with AOSD 2004 in Lancaster, UK, on March 23, 2003. Themes and Goals FOAL is a forum for research in foundations of aspect-oriented programming languages. Areas of interest include but are not limited to: * Semantics of aspect-oriented languages * Specification and verification for such languages * Type systems * Static analysis * Theory of testing * Theory of aspect composition * Theory of aspect translation (compilation) and rewriting The workshop aims to foster work in foundations, including formal studies, promote the exchange of ideas, and encourage workers in the semantics and formal methods communities to do research in the area of aspect-oriented programming languages. All theoretical and foundational studies of this topic are welcome. The goals of FOAL are to: * Make progress on the foundations of aspect-oriented programming languages. * Exchange ideas about semantics and formal methods for aspect-oriented programming languages. * Foster interest within the programming language theory and types communities in aspect-oriented programming languages. * Foster interest within the formal methods community in aspect-oriented programming and the problems of reasoning about aspect-oriented programs. Workshop Format The planned workshop format is primarily presentation of papers and group discussion. Talks will come in three categories: long (30 minutes plus 15 minutes of discussion), short (20 minutes plus 5 minutes of discussion) and very short (7 minutes plus 3 minutes of discussion). The very short talks will allow for short presentations of topics for which results are not yet available, perhaps for researchers who are seeking feedback on ideas or seek collaborations. We also plan to ensure sufficient time for discussion of each presentation by limiting the number of long talks and having only a few short talks. Submissions Invitation to the workshop will be based on papers selected by the program committee; those wishing to attend but not having a paper to submit should contact the organizers directly to see if there is sufficient space in the workshop. FOAL solicits papers on all areas of formal foundations of AOP languages. Submissions will be read by the program committee and designated reviewers. Papers will be selected for long, short, and very short presentation at the workshop based on their length, scientific merit, innovation, readability and relevance. Papers previously published or already being reviewed by another conference are not eligible. We will limit the length of paper presentations and the number of papers presented to make sure that there is enough time for discussion. Papers presented at the workshop will be included in a technical report (from Iowa State University). Authors will retain their own copyright to the papers. Publication of papers at other venues will thus remain possible. We will also investigate having a special issue of a journal for revisions of selected papers after the workshop. Authors should note the following details: * Submissions are due no later than 23:00 GMT, Monday, 19 January 2004. (This is a firm deadline.) * Authors must indicate whether they wish to be considered for a long, short, or very short presentation. * Papers for long presentations must not exceed 10 pages in length; those for short presentations must not exceed 5 pages in length, and those for very short presentations must not exceed 3 pages in length. * Some papers may not be selected for presentation, and some may be selected for presentation in shorter talks than requested. * We encourage use of the ACM Conference format for submissions, as this will be required for accepted papers. You must add page numbers (which are not part of the standard format) to your submissions, to make adding comments easier. * Submissions are to be sent as PDF (preferred) or postscript attachments in an email to Curtis Clifton, cclifton -at- cs -dot- iastate -dot- edu. We will notify the corresponding author of papers that are selected for presentation at the workshop by 9 February 2004. The early registration deadline for AOSD is 13 February 2004. FOAL attendees must be registered for AOSD. Final versions of papers for the proceedings will be due on 1 March 2004. For more information, visit the FOAL Workshop home page at http://www.cs.iastate.edu/FOAL. Important Dates Submission Deadline 23:00 GMT, 19 January 2004 Notification of Acceptance 9 February 2004 Final Versions of Papers Due 1 March 2004 Workshop 23 March 2004

1 0