Subject prefixes (was: RE: suggestion)

[Simon Marlow]

  What do you all think about activating the mechanism that 
  automatically includes the name of the list before the subject
  of a mailing list email?
  For example:
  [hugs-users] Installation problems or [haskell] newbie 
  question.
 
 I don't like the extra prefixes, but if most folk would 
 prefer them then
 I can turn them on.  Let me know if you have a preference one 
 way or the
 other (don't mail to the list).

Thanks to all those who replied.  The results were: 9 in favour of
adding a '[haskell]' prefix, and 15 against.  So I won't make any
changes this time.

For those who were in favour of adding the prefix, the preferred
solution is to have your mail reader automatically sort Haskell mail
into a separate folder.  There are plenty of useful headers in the
messages from haskell.org which make it possible to do just that - eg.
List-Id is a good one.

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Asynchronous Exceptions

[Simon Marlow]

 Can someone help me understand how this works? I've been 
 reading the paper Asynchronous Exceptions in Haskell. This 
 gives a combinator
 
 finally :: IO a - IO b - IO s
 
 finally a b = 
block (do {
   r - catch (unblock a) (\e - do { b; throw e });
   b;
   return r; })
 
 Now suppose we have
 
 finally (putStrLn Test Started) (putStrLn Test Terminated)
 
 then looking at the semantics, putStrLn can become stuck and 
 therefore can be interrupted. So the interrupt could occur 
 whilst Test Terminated is being output and we could end up with
 
 Test Started
 Test Term
 
 Is this what could happen? If so, is there a way of making 
 sure that Test Terminated is output?

Yes, that's correct.  putStrLn is interruptible, so you can't force it
to run to completion - to do so would introduce a possible deadlock.  

However, I agree that sometimes you really want to be able to do this,
so perhaps we need another form of 'block' which doesn't allow *any*
exceptions to be delivered, for those times when you know that the time
spent waiting in an interruptible operation is going to be bounded.

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: GUI Library Task Force

[Simon Marlow]

 I don't think this is compatible with things like adding support
 for the library hierarchy with multiple dots to Haskell 98 as you
 will then be able to write a program that is valid Haskell 98 by
 todays definition but not yesterdays. OTOH if what you mean is
 adding support incrementally to todays *tools* and declaring H98
 with a set of the new features to be Haskell 2 at some point in
 the future then I don't have a problem with that.

I don't think anyone is suggesting that we change the meaning of the
term Haskell 98: it is, and always will be, defined by the Haskell 98
report.  The idea behind addenda to the report is to define a family
of new languages, eg. Haskell 98 + FFI, Haskell 98 + FFI + Exceptions,
and so on.  

These languages may be incompatible with pure Haskell 98, but compilers
will generally give you the choice between pure Haskell 98 and whatever
extensions are supported.

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Cash Prizes Win!

[Simon Marlow]

[ Ketil Malde asks about recent spam on Haskell mailing lists... ]
 How about disallowing non-subscribers from posting?  This list is my
 main source of spam these days.  (Effective filtering is your friend)

My apologies for this spam that got through.  Mailman's automatic
filtering catches *most* of the spam bound for the list - there are
usually a few messages per day.  The ones that get through are very much
the exception, but it does occasionally happen.

I could turn on subscriber-only posting if there's a consensus to do
that.  It might be inconvenient in that you have to post from the same
account that you read Haskell mail from though, and I know some people
have separate email accounts just for receiving Haskell mail.  What do
people think?

Also, what do people think about the volume of Conference-related
announcements sent to the list ([EMAIL PROTECTED] in particular)?
Most of these get caught by the filter, and I tend to disallow only
those that have no connection to programming language research at all.
This could be tightened to Haskell-related or functional
programming-related conferences only.

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Possible bug/omission in Numeric library?

[Simon Marlow]

 There is something strange about the Haskell'98 Numeric library,
 which I think could be considered a bug of sorts.  There are functions
 
 readDec, readOct, readHex :: (Integral a) = ReadS a
 
 which read an integer from a string in base 10, 8, or 16, but there
 are no corresponding show functions to convert an integer to a string
 using base 8 or 16.  The sole function given is
 
 showInt :: (Integral a) = a - ShowS
 
 which shows a number in base 10 only.  I think you'll agree that it
 is odd that you can read a certain number format but cannot show it?

Yes indeed. GHC and Hugs have showHex, showOct, showBin and
showIntAtBase in NumExts:

http://www.haskell.org/ghc/docs/latest/set/sec-numexts.html

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: IO errors

[Simon Marlow]

 A quick look at the source looks like both GHC and NHC will 
 simply pass
 on errors from the OS, so for example with
 
 module Main where
 
 import IO
 import Directory
 
 main :: IO()
 main = do catch (createDirectory this/does/not/exist/foo)
 (\e - putStrLn $ show $ map (flip ($) e) errors)
 
 errors :: [(IOError - Bool)]
 errors = [isDoesNotExistError,
   isIllegalOperation,
   isPermissionError,
   isAlreadyExistsError]
 
 both GHC and NHC give [True,False,False,False] (I don't seem to have a
 hugs Directory.hs) while the library report only allows
 isIllegalOperation, isPermissionError and isAlreadyExistsError. I
 haven't looked for other cases of this.

Two possibilities: either createDirectory should act like 'mkdir -p' and
make the whole path, or the library report should document
isDoesNotExistError as a possible error thrown by createDirectory.  I'd
vote for the latter.

No doubt there are many other cases of this, we should really do a full
audit of the I/O library specs.

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Harmful spammers

[Simon Marlow]

 There are a couple things to do that can at least cut down on spam.
 
 1) Make sure that your mail gateway, or (in this case) the mailing 
list host is not an open relay site.

It isn't.

 2) Every time you get spam, locate all the hosts it came through
in the header.

Or alternatively just report it using Spamcop (http://spamcop.net) or
some other reporting tool.  Life is just too short to do this by hand
every time you get spam.

On the Haskell mailing list we have a good compromise at the moment: the
mailing list software's auto-filtering catches most of the spam (not
allowing Bcc's to the list is a good one), and for any spam that gets
through I just add it to the list of disallowed addresses.  I asked
recently if we should move to allowing subscriber-only posting, and I
got a small number of responses, which were split roughly 50/50 so no
action was taken.

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Another question about sharing

[Simon Marlow]

 I'm curious, how does GHC determine that the CAF is no longer required
 if it is referenced by code (somehow)? If code was also some kind of
 heap allocated data structure I guess this would be possible, but I
 thought this wasn't so with GHC.

GHC actually tracks references to top-level entities from code, so that
the GC can trace the transitive closure of live code and hence find all
the reachable CAFs.  It's a real pain, but worth it.

 But in any case, I'm not sure this really helps me. I don't really
 mind if the unreduced form of the CAF is garbage collected or not
 (it's only going to be a few words of memory). The effect I'm trying
 to get is to ensure that the (partially) reduced form of the CAF only
 lives as long as any (non code) heap object which references it.
 Does that make sense? (probably not:-)

If I understand correctly, that's the behaviour you'll get with GHC, and
(I think) nhc98.

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Another question about sharing

[Simon Marlow]

 Well, how about the following little circular program?
 
 paths :: () - [Path]
   paths () = let r = T : branch r in r
 
 As far as I can understand what you are looking for, I think 
 this meets
 the bill.  Every use of the expression `paths ()' will re-evaluate
 the infinite structure to the extent its context requires it, and the
 expanded value will be thrown away as soon as the value of this
 instance of `paths ()' is no longer required.

You can't rely on adding dummy arguments to cause re-evaluation:
full-laziness (enabled when optimisation is on in GHC) will do the
opposite transformation.

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Another question about sharing

[Simon Marlow]

  You can't rely on adding dummy arguments to cause re-evaluation:
  full-laziness (enabled when optimisation is on in GHC) will do the
  opposite transformation.
 
 Well in this case, you may find it harder to claim that the full
 laziness transformation constitutes an `optimisation'.  Maybe the
 GHC manual should have a section on Flags for worsening the space
 behaviour of programs.  :-)
 
 Seriously, would it be difficult to detect when performing this
 `optimisation' would introduce a CAF and perhaps back it out
 appropriately?

The problem isn't restricted to CAFs - full laziness always trades space
for time.  We found that it can be a large win in some cases: if
repeated computation is replaced by sharing in an inner loop, then the
gains can be dramatic.  We didn't meet any cases where it caused space
problems, so you get it by default[1] when optimisation is turned on in
GHC.  You can always disable it with -fno-full-laziness.

Cheers,
Simon

[1] Actually what you get is almost-full-laziness: GHC won't split
adjacent lambda abstractions if it finds it can float an expression past
some of the lambdas but not all.

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: unsafePerformIO to give warnings

[Simon Marlow]

Ian Lynagh writes:
 Sorry, I meant hugs and ghci only seem to print the warning the first
 time I run the program, e.g. with
 
 module Main where
 
 import IOExts
 
 main :: IO()
 main = trace foo (putStrLn bar)
 
 in hugs:
 
 [...]
 Type :? for help
 Main main
 foobar
 
 Main main
 bar
[snip]
 and in ghci:
 
 Skipping  Main ( q.lhs, ./q.o )
 Main main
 foo
 bar
 Main main
 bar
[snip]

This is because 'main' is a CAF: the act of reducing it to normal form
the first time forces the warning to be printed, but thereafter the
evaluated version is returned immediately.

To subvert this behaviour, in GHCi you can say ':set +r' which causes
all CAFs to be reverted between evaluations.

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: #s causing errors when -cpp not given

[Simon Marlow]

 I've just been looking at using cpp in Haskell scripts and I am rather
 confused. I can't see anything in the report which gives 
 special meaning
 to # in the surrounding text of literate scripts, yet if I put such
 things in (both cpp directives and random things) both nhc98 and ghc
 give me errors:
 
 $ rm Foo.{o,hi}; nhc98 -c Foo.lhs -o Foo.o 
 Unknown preprocessor directive at line 4 in file ./Foo.lhs
 ifdef QQ
 
 $ rm Foo.{o,hi}; ghc -c Foo.lhs -o Foo.o 
 Foo.lhs:4: parse error on input `#'
 
 Are ghc and nhc98 being incompatible with Haskell 98?

GHC has one small extension to Haskell 98 in this area: the lexical
analyser interprets directives line '# 99 Foo.hs' at the beginning of
a line in order to get line number and file clues when it is parsing the
output from CPP.  Apart from this, '#' should be interpreted exactly as
per the report (when -fglasgow-exts is off).

Could you send us the source?

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: H98 Report: expression syntax glitch

[Simon Marlow]

 In the table of precedence in the original Report (now deleted in
 the revised Report), it makes it clear that a rightward-extending
 let, if, or lambda has a lower precedence than an infix operator,
 so for instance the parse
 
   h = (let op x y = y in (3 `op`))
 
 is correct and
 
   h = ((let op x y = y in 3) `op`)
 
 is not.

Actually the table claims that 'let' has a higher precedence than infix operators, so 
your second example above would be the correct parse according to the table.  This may 
be one of the reasons it was removed, I can't remember now.

Also, the table wasn't supposed to contain any extra information that isn't already in 
the grammar (Section 3: As an aid to undertanding the grammar, Table 1 shows the 
relative precedences...), so if the table is required to understand a particular 
parse, it would indicate a deficiency or ambiguity in the grammar.

On the other hand, one way to fix this problem *is* to specify the relative precedence 
of 'let'  co. as compared to infix operators (namely that 'let' should have a lower 
precedence).  That would be a reasonable fix for the H98 report, IMO.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: H98 Report: expression syntax glitch

[Simon Marlow]

 On Mon, Feb 25, 2002 at 05:07:35PM -, Simon Marlow wrote:
  On the other hand, one way to fix this problem *is* to specify the
  relative precedence of 'let'  co. as compared to infix operators
  (namely that 'let' should have a lower precedence).  That would be a
  reasonable fix for the H98 report, IMO.
 
 Except that it would break programs containing expressions like
 
   1 + let x = 2 in e
 
 or (if you do the same for lambda)
 
   f $ \x - e
 
 The old table had let (and if and lambda) in two places, which is
 more less what GHC/Hugs do, but not a mere clarification.

Yes *sigh* I hadn't noticed that the table had one precedence for leftwards and a 
different one for rightwards.  Nevertheless, the report needs clarifying on this 
point.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Why is this function type-correct

[Simon Marlow]

 Recently, I wrote a function similar to
 
 x :: a
 x = x 42
 
 which is type-correct (Hugs, Ghc, THIH).
 Still, from the expression it is clear
 that the type shoud have a function type.
 The definition
 
 x :: a - b
 x = x 42
 
 is equally well accepted, though I can't
 see why this type would be correct. (I'd
 expect it to be too general.)

In two words: polymorphic recursion.  You'll find that the compiler
won't be able to derive a type for 'x' in either of the two examples you
gave, but x has several types the most general of which is 'forall a. a'
(ie. your first example).

The fact that x has type 'forall a. a' is also a useful hint as to its
behaviour - the only value that has such a type is bottom.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Isn't this tail recursive?

[Simon Marlow]

 On 10 Mar 2002, Jyrinx wrote:
 
  In the case expression at the end of countAll, each of the 
 values looks
  to me like a recursive tail call - I should think (hope?) 
 that it would
  be optimized by GHC into a goto statement (a la Scheme). Instead, my
  program eats up memory (I've got 256 MB) until the RTS 
 whines about a
  stack overflow.
 
 It is tail recusive. unfortunately, that's not the problem.
 apparently ghc is not smart enough to realize that countAll' should
 really be strict in basically all arguments.  (hell, I'm not 
 quite sure I
 can claim to be smart enough to say that!)

The function as written is only strict in its list argument, and its
usage site only demands the 'l' argument strictly.  So unless the
compiler were to make use of the can't fail property of '+' on Int
(which might not even hold if overflow checking is used), the compiler
can't possibly evaluate the accumulating parameters of countAll'
strictly.

It would be possible to do strict evaluation in the case that the
suspended computation is known to take a small bounded amount of time
and space and can't fail - GHC doesn't do this, but we've wondered about
it from time to time.

I do wonder how often similar patterns crop up in practice - I've
certainly encountered this pattern in my own code several times, and
solved it using seq or strict constructor fields.

 Never fear,
 -fall-strict is here!

I had no idea this flag still worked.  As I recall, it was an experiment
that turned out to be a bad idea - you're probably just better off using
seq.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: HGL ang GHC on Win32

[Simon Marlow]

 I'm hoping that a GHC honcho will say 
 
   Well of course that happens with 5.02.2 - you should 
 upgrade to 5.03 right away.
 
 or some such.

I'm afraid not :-)  But there *is* a bug in the native code generator in
5.02.2, namly in the FFI support for passing floating point arguments to
ccalls, which I fixed yesterday and could potentially cause this kind of
problem.  Make sure the graphics library has been compiled with -fvia-C
or -O to work around it (and if this helps, please let us know).

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: un-layout program

[Simon Marlow]

 does there exist a program that'll take a layed out haskell 
 program and
 output one that uses braces and semis to delimit?

You can use GHC's hssource package to parse  then pretty-print the
source code - the pretty printer can generate output with explicit
layout tokens if you ask for it.  The documentation is a bit lacking
(well, there isn't any), so grab the source or browse it on the web
here:

   http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hslibs/hssource/

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: HGL ang GHC on Win32

[Simon Marlow]

 That is a shame.  I tried both suggestions (specifying 
 position explicitly
 and recompiling with fvia-c -- i had been using O all along) 
 and neither
 worked :(.
 
 I also tried using 5.03, and got the following warnings:
[ message deleted ]

It looks like there are some prototypes missing:

 C:\DOCUME~1\hdaume\LOCALS~1\Temp\ghc920.hc:59: warning: implicit
 declaration of function `prim_rgb'

GHC might not generate correct calls to these functions unless there is
a visible prototype.  In fact, taking this example, the definition of
prim_rgb is

   DWORD prim_rgb(BYTE arg1,BYTE arg2,BYTE arg3)

but its FFI declaration says

   foreign import  ccall prim_rgb unsafe
 prim_rgb :: Word32 - Word32 - Word32 - IO (Word32)

this looks a bit strange - is there a green-card expert out there to
explain what's going on?  Why have the BYTEs been turned into Word32s?

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: question about concurrency implementation

[Simon Marlow]

 I'm curious about the implementation of Concurrent Haskell in GHC and
 Hugs.  Does access to values possibly shared among threads 
 cost the same
 in Concurrent Haskell as in regular Haskell?  I'm guessing 
 the answer is
 yes, because Concurrent Haskell is provided by default in 
 GHC.

yes

 If the costs are the same, does that rely on there being no true 
 concurrency in
 the current implementations?

It depends what you mean by true concurrency: from the point of view of
the Haskell programmer, GHC's implementation of concurrency is almost
preemptive, because we can context-switch at any allocation.  Most
computation does some allocation, but it's possible to write functions
that don't (although these tend to be on the trivial side - an optimised
nfib won't allocate, for example).  We could artificially cause all
computation to do some allocation to avoid this problem, but we haven't
found it necessary so far.

But I suspect by true concurrency you're referring at the kind of
concurrent processes that can be executed on multiple CPUs
simultaneously.  We did investigate doing this a while back, and found
that the locking required on thunks was very expensive (slowed down the
program by at least 2x on the bog-standard SMP machine we had here).
However there are some clever techniques that can be used to reduce the
cost - giving each process its own private allocation area and only
degrading to full locking for access to the shared portion of the heap
is one such technique we experimented with briefly but I don't have any
concrete benchmarks I'm afraid.  Also you really need a multithreaded
garbage collector, which is a lot of work.

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: handling errors in Happy

[Simon Marlow]

 Is it possible to get the result of function happyError, in 
 the main module
 of my program (which imports the module generated by Happy)?

Sure.  You need to use Happy's %monad feature, the documentation
describes how to turn parse errors into something you can handle in the
program:

   http://www.haskell.org/happy/doc/html/sec-monads.html#SEC-EXCEPTION

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

ANNOUNCE: GHC 5.02.3 released

[Simon Marlow]

   The (Interactive) Glasgow Haskell Compiler -- version 5.02.3
  ==

We are pleased to announce a new patchlevel release of the Glasgow
Haskell Compiler (GHC), version 5.02.3.  The source distribution is
freely available via the World-Wide Web, under a BSD-style license.
See below for download details.  Pre-built packages for Linux,
FreeBSD, Solaris and Win32 are also available (or will appear
shortly).

Haskell is a standard lazy functional programming language; the
current language version is Haskell 98, agreed in December 1998.

GHC is a state-of-the-art programming suite for Haskell.  Included is
an optimising compiler generating good code for a variety of
platforms, together with an interactive system for convenient, quick
development.  The distribution includes space and time profiling
facilities, a large collection of libraries, and support for various
language extensions, including concurrency, exceptions, and foreign
language interfaces (C, C++, whatever).

A wide variety of Haskell related resources (tutorials, libraries,
specifications, documentation, compilers, interpreters, references,
contact information, links to research groups) are available from the
Haskell home page at

http://www.haskell.org/

GHC's Web page lives at

http://www.haskell.org/ghc/



 What's new in 5.02.3
==

Some important bugfixes:

   - now works with gcc 3.x
 
   - works with newer glibc releases on Linux

   - loading parsers generated by Happy with the -ag flags
 into GHCi now works

   - fix for excessive recompilation when using --make

   - tryTakeMVar now works

   - fix some problems with the dynamic linker when loading
 C libraries into GHCi (using Gtk+HS from GHCi should now
 work).

and various other minor fixes.

NOTE: object files created by this vesrion of GHC may be incompatible
with object files created by older versions of GHC, so be sure to
recompile any pre-compiled libraries you may have lying around.


 How to get it
===

The easy way is to go to the WWW page, which should be
self-explanatory:

http://www.haskell.org/ghc/

We supply binary builds in the native package format for various
flavours of Linux and BSD, and in InstallShield form for Windows
folks.  Everybody else gets a .tar.gz which can be installed where you
want.

Once you have the distribution, please follow the pointers in the
README file to find all of the documentation about this release.



 On-line GHC-related resources
===

Relevant URLs on the World-Wide Web:

GHC home page http://www.haskell.org/ghc/
Haskell home page http://www.haskell.org/
comp.lang.functional FAQ  http://www.cs.nott.ac.uk/~gmh/faq.html



 System requirements
=

To compile programs with GHC, you need a machine with 64+MB memory, GNU
C
and perl. This release is known to work on the following platforms:

  * i386-unknown-{linux,freebsd,mingw32}
  * sparc-sun-solaris2
  * alpha-dec-osf3

Ports to the following platforms should be relatively easy (for a
wunderhacker), but haven't been tested due to lack of time/hardware:

  * hppa1.1-hp-hpux{9,10}
  * i386-unknown-solaris2
  * mips-sgi-irix{5,6}
  * {rs6000,powerpc}-ibm-aix

The builder's guide included in distribution gives a complete
run-down of what ports work; an on-line version can be found at

   http://www.haskell.org/ghc/docs/latest/building/building-guide.html



 Mailing lists
===

We run mailing lists for GHC users and bug reports; to subscribe, use
the web interfaces at

http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

There are several other haskell and ghc-related mailing lists on
www.haskell.org; for the full list, see

http://www.haskell.org/mailman/listinfo/

Please report bugs using our SourceForge page at

http://sourceforge.net/projects/ghc/

or send them to [EMAIL PROTECTED]

GHC users hang out on [EMAIL PROTECTED]  Bleeding
edge CVS users party on [EMAIL PROTECTED]
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: semi-private exports

[Simon Marlow]

 In my NLP.Prelude file, I define:
 
  newtype Token = Token [Word8]
 
 and I export only the type, not the constructor because I 
 don't users of
 my package to be able to inspect/modify the list directly.  
 However, in my
 NLP.IO module, in which I define IO for some of my data 
 types, I need to
 be able to access it directly.
 
 In Java/C#, I would make Token public and the constructor 
 protected (i.e.,
 public for the current package but private for other people).  I would
 really like to be able to do something similar.  Any ideas?

Define the type in a private module, say DLP.Prelude.Private, which is
used by NLP.IO, and re-export it abstractly from NLP.Prelude.  You don't
get the benefit of language support for enforcing that
NLP.Prelude.Private isn't nefariously imported by the client, but at
least now with hierarchical modules the private module name isn't
polluting the client's module namespace.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: do notation and

[Simon Marlow]

  I don't believe that it will break many programs. How many programs
  produce large *input independent* output, that is not already
  literally in the source, in a caf with a long life-time?
 
 That sounds like a description of all the animation programs in Paul
 Hudak's School of Expression book and there's plenty more examples
 like that.
 
 [I haven't tested whether these programs do leak space with the
 modified compiler - my point is that there is a large class of
 programs with exactly the characteristics you describe.]
 
 --
 Alastair Reid
 
 ps I think your CAF restriction is a bit of a red herring - Koen's
 modification to make his example leak in GHC (which GCs CAFs) shows
 that the leak happens as long as the relevant thunk isn't collected.

This whole discussion is a red herring.  The Haskell report doesn't say
anything about sharing - it doesn't even mandate laziness (look in the
index - you won't find the term lazy :-).  Different compilers will
behave differently, GHC in particular will probably share expr2 in
Koen's example

  f = do expr1
 expr2

regardless of whether the translation uses  or =, because GHC
implements full laziness (when -O is turned on).

So you might reasonably argue that Haskell should provide more control
over such things, and I might well agree.  But there's no point in
discussing whether using = or  in the translation of do-notation is
better: they're both equivalent as far as the current language
specification is concerned.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Syntax of functional dependencies

[Simon Marlow]

 I errorneously specified categories as
 
 class (Eq object, Eq morphism) = 
   Category id object morphism | id -, id - morphism
   where  o :: id - morphism - morphism - Maybe morphism
  dom, cod :: id - morphism - object
 
 it should have been
 
 class (Eq object, Eq morphism) = 
   Category id object morphism | id - object, id - morphism
   ... ^^
 
 - but ghci 5.02.2 does not complain. Why?

The syntax of a functional dependency is (from GHC's parser):

   fd : varids0 '-' varids0

   varids0 
: {- empty -}
| varids0 tyvar

so the list of tyvars on either side of the '-' can be empty.
Functional dependency experts can correct me if I'm wrong, but I imagine
though that 'a -' is not a very useful functional dependency (isn't it
the same as giving no functional dependency at all?), and '- a' means
that there can only ever be one instantiation for 'a' in the whole
program.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

ANNOUNCE: Haddock version 0.1, a Haskell documentation tool

[Simon Marlow]

I'm pleased to announce version 0.1 of Haddock, a documentation
generation tool for Haskell source code.  It's available from

http://www.haskell.org/haddock/

Here's the README:

Haddock, a Haskell Documentation Tool
=

This is Haddock, a tool for automatically generating documentation
from annotated Haskell source code.  It is primary intended for
documenting libraries, but it should be useful for any kind of Haskell
code.

Like other systems ([1],[2]), Haddock lets you write documentation
annotations next to the definitions of functions and types in the
source code, in a syntax that is easy on the eye when writing the
source code (no heavyweight mark-up).  The documentation generated by
Haddock is fully hyperlinked - click on a type name in a type
signature to go straight to the definition, and documentation, for
that type.

Haddock understands Haskell's module system, so you can structure your
code however you like without worrying that internal structure will be
exposed in the generated documentation.  For example, it is common to
implement a library in several modules, but define the external API by
having a single module which re-exports parts of these implementation
modules.  Using Haddock, you can still write documentation annotations
next to the actual definitions of the functions and types in the
library, but the documentation annotations from the implementation
will be propagated to the external API when the documentation is
generated.  Abstract types and classes are handled correctly.  In
fact, even without any documentation annotations, Haddock can generate
useful documentation from your source code.

Haddock can generate documentation in multiple formats; currently HTML
is implemented, and there is partial support for generating DocBook.
The generated HTML uses stylesheets, so you need a fairly up-to-date
browser to view it properly (Mozilla, Konqueror, Opera, and IE 6
should all be ok).

Full documentation can be found in the doc/ subdirectory, in DocBook
format.

Please send questions and suggestions to me:

Simon Marlow [EMAIL PROTECTED]


[1] IDoc - A No Frills Haskell Interface Documentation System
http://www.cse.unsw.edu.au/~chak/haskell/idoc/

[2] HDoc http://www.fmi.uni-passau.de/~groessli/hdoc/
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Haddock

[Simon Marlow]

 I just tried haddock-0.1. Good thing! Two quibbles, though:
 * the parser chokes on CVS headers like -- $Id ...$ 
   ( but -- -- $Id ..$ is OK)

Yes, because '-- $' has a special meaning in Haddock (it's a named
documentation comment).

 * is there support for hierarchical namespaces?
   ( with module Foo.Bar in file Foo/Bar.hs, and so on )

Yes, hierarchical modules are supported.  You must pass the full
filenames of each of the modules to be processed to Haddock, though.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

ANNOUNCE: Haddock version 0.2, a Haskell documentation tool

[Simon Marlow]

I'm pleased to announce version 0.2 of Haddock, a documentation
generation tool for Haskell source code.  It's available from

http://www.haskell.org/haddock/

The changes relative to version 0.1 are listed here:

http://www.haskell.org/haddock/CHANGES.txt

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Dependent Types

[Simon Marlow]

 However, if I now comment out the functional dependency
 
 class Encode a b {- | a - b -} where
encode :: a - b
 
 and include the expressions
 
 x = encode TimeExceeded ExcTTL
 
 main = putStrLn x
 
 then Hugs complains
 
 ERROR codes.hs (line 37): Unresolved top-level overloading
 *** Binding : x
 *** Outstanding context : Encode TimeExceeded 
 (ICMPCodeTimeExceeded - b)
 
 whereas GHC doesn't complain.
 
 Which is right?

I think you're running into a well-known(*) problem with Hugs's
implementation of the monomorphism restriction.  According to the
Haskell report, as long as a restricted binding is used monomorphically
in the body of the module, it is ok.  In this case, the constraint
'Encode TimeExceeded (ICMPCodeTimeExceeded - b)' is resolved by the use
of 'x' in the declaration for 'main', which forces the type variable b
to String.

Hugs applies the monomorphism restriction at the binding site, and
complains if the binding isn't monomorphic without checking the rest of
the module.  It also applies defaulting at this point, which means that

f = (+42)
main = print (f 3 :: Int)

also elicits an error in Hugs, but not in GHC.

(*) actually I thought this was a well-known problem, but it doesn't
seem to be mentioned in the Hugs documentation as far as I can see.

Cheers, 
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Dependent Types

[Simon Marlow]

 I think you're running into a well-known(*) problem with Hugs's
 implementation of the monomorphism restriction.

 (*) actually I thought this was a well-known problem, but it doesn't
 seem to be mentioned in the Hugs documentation as far as I can see.

Here's a bit of background I managed to dig up:

   http://www.mail-archive.com/haskell@haskell.org/msg05160.html

It appears that a change to the monomorphism restriction to match Hugs's
behaviour was considered for Haskell 98, but it looks like it never made
it into the report (for what reason I'm not sure - the arguments in
favour of the change look fairly compelling).

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

State monads don't respect the monad laws in Haskell

[Simon Marlow]

An interesting revelation just occurred to Simon P.J. and myself while
wondering about issues to do with exceptions in the IO monad (see
discussion on [EMAIL PROTECTED] if you're interested).

The question we were considering was whether the following should hold
in the IO monad:

(return () = \_ - undefined) `seq` 42   ==  undefined

as we understand the IO monad it certainly shouldn't be the case.  But
according to the monad laws:

(law)  return a = k  ==  k a
so (return () = \_ - undefined) `seq` 42
  = ((\_ - undefined) ()) `seq` 42
  = undefined `seq` 42
= undefined

So the IO monad in Haskell, at least as we understand it, doesn't
satisfy the monad laws (or, depending on your point of view, seq breaks
the monad laws).  

This discrepancy applies to any state monad.  Suppose we define

return a = \s - (s, a)
m = k = \s - case m s of (s', a) - k a s'

now
   return a = k
  = \s - case (return a) s of (s', a') - k a' s'
= \s - case (s, a) of (s', a') - k a' s'
= \s - k a s

but (\s - k a s) /= (k a) in Haskell, because seq can
tell the difference.

What should the report say about this?

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Negative literals and the meaning of case -2 of -2 - True

[Simon Marlow]

 To find out how Haskell implementations treat negated 
 literals, I tested 
 the following program:
 
 
 main = print (minusTwo,trueOrFalse)
 
 minusTwo = -2::N
 
 trueOrFalse =
 case minusTwo of
   -2 - True
   _ - False
 
 data N = Negate N | FromInteger Integer deriving (Eq,Show)
 
 instance Num N where
   negate = Negate
   fromInteger = FromInteger
 -
 
 The result is:
 
 * ghc 5.02.2: main outputs: (FromInteger (-2),True)

GHC has two bugs in this area, one of which has been fixed recently.
The current output is (Negate (FromInteger 2),False) (i.e. the same as
hbc).  We were being a little too eager to replace 'negate (fromInteger
N)' by 'fromInteger (-N)'.  There is also a bug in the pattern handling,
however.

Thanks for a nice test case...

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

ANNOUNCE: Haddock version 0.3

[Simon Marlow]

I'm pleased to announce version 0.3 of Haddock, a documentation
generation tool for Haskell source code.  It's available from

http://www.haskell.org/haddock/

The changes relative to version 0.2 are listed here:

http://www.haskell.org/haddock/CHANGES.txt

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: [ADMINISTRIVIA]: Change list submission policy please?

[Simon Marlow]

 Ralf Hinze [EMAIL PROTECTED] writes:
 
  The haskell mailing list is getting an increasing amount of
  spam, viruses, and virus warnings.  Would it be possible
  to change the list policy to only allow submissions from
  subscribed members?  Please?
 
  I'd like to second this. The amount of spam etc is becoming
  more and more annoying ...
 
 Thirded!  While we won't easily get rid of Outlook-viruses (since the
 list may appear in people's address books), at least we can get rid of
 the loads of warnings from misconfigured mail servers following them.

The problem with this (and the reason it hasn't been done before) is that several 
people subscribe to the list under a different address than the one they use to post - 
for example, some institutions gateway the list to a local newsgroup.  We could work 
around this, but it would undoubtedly cause a non-zero amount of hassle.

The haskell.org crew are looking into installing some spam filtering at the moment.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

ANNOUNCE: GHC version 5.04 released

[Simon Marlow]

   
The (Interactive) Glasgow Haskell Compiler -- version 5.04
   

We are pleased to announce a new major release of the Glasgow Haskell
Compiler (GHC), version 5.04.

Highlights include:

  * Hierarchical libraries, with documentation produced by Haddock.

  * New type system extensions: full rank-N types and kind
annotations.
 
  * New heap profiling facilities (retainer profiling, biographical
profiling).

  * MacOS X support

See the release notes for a full list of the changes:

 
http://www.haskell.org/ghc/docs/latest/html/users_guide/release-5-04.htm
l


How to get it
~
The easy way is to go to the WWW page, which should be self-explanatory:

http://www.haskell.org/ghc/

We supply binary builds in the native package format for various
flavours of Linux and BSD, and in InstallShield form for Windows
folks.  Binary builds for other platforms are available as a .tar.bz2
which can be installed wherever you want.  The source distribution is
also available from the same place.

Packages will appear as they are built - if the package for your system
isn't available yet, come back later.


Background
~~
Haskell is a standard lazy functional programming language; the
current language version is Haskell 98, agreed in December 1998.

GHC is a state-of-the-art programming suite for Haskell.  Included is
an optimising compiler generating good code for a variety of
platforms, together with an interactive system for convenient, quick
development.  The distribution includes space and time profiling
facilities, a large collection of libraries, and support for various
language extensions, including concurrency, exceptions, and foreign
language interfaces (C, whatever).  GHC is distributed under a
BSD-style open source license.

A wide variety of Haskell related resources (tutorials, libraries,
specifications, documentation, compilers, interpreters, references,
contact information, links to research groups) are available from the
Haskell home page (see below).


On-line GHC-related resources
~~

Relevant URLs on the World-Wide Web:

GHC home page http://www.haskell.org/ghc/
Haskell home page http://www.haskell.org/
comp.lang.functional FAQ  http://www.cs.nott.ac.uk/~gmh/faq.html



System requirements
~~~
To compile programs with GHC, you need a machine with 64+MB memory, GCC
and perl. This release is known to work on the following platforms:

  * i386-unknown-{linux,*bsd,mingw32}
  * sparc-sun-solaris2
  * alpha-dec-osf3
  * powerpc-apple-darwin (MacOS/X)

Ports to the following platforms should be relatively easy (for a
wunderhacker), but haven't been tested due to lack of time/hardware:

  * hppa1.1-hp-hpux{9,10}
  * i386-unknown-solaris2
  * mips-sgi-irix{5,6}
  * {rs6000,powerpc}-ibm-aix

The builder's guide on the web site gives a complete run-down of what
ports work; it can be found at

 
http://www.haskell.org/ghc/docs/latest/html/building/building-guide.html


Mailing lists
~
We run mailing lists for GHC users and bug reports; to subscribe, use
the web interfaces at

http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

There are several other haskell and ghc-related mailing lists on
www.haskell.org; for the full list, see

http://www.haskell.org/mailman/listinfo/

Please report bugs using our SourceForge page at

http://sourceforge.net/projects/ghc/

or send them to [EMAIL PROTECTED]

GHC users hang out on [EMAIL PROTECTED]  Bleeding
edge CVS users party on [EMAIL PROTECTED]
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

ANNOUNCE: Haddock version 0.4

[Simon Marlow]

I'm pleased to announce version 0.4 of Haddock, a documentation
generation tool for Haskell source code.  It's available from

http://www.haskell.org/haddock/

The changes relative to version 0.3 are listed here:

http://www.haskell.org/haddock/CHANGES.txt

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: unsafePerformIO around FFI calls

[Simon Marlow]

 If this is true, then is it equivalently safe to wrap the following
 Haskell action in unsafePerformIO:
 
   myFunc i =
 do arr - newArray (0,255) 0
mapM_ (\j - writeArray arr j (i+j)) [0..255]
foo - newIORef 0
mapM_ (\j - readArray arr j = modifyIORef foo (+j)) [0..255]
readIORef foo = return
 
 ? (don't call me on syntax errors -- i haven't checked this 
 at all, but you should get the idea)

Yes, but for this particular case you would use the ST monad instead
(with STArray and STRef).  That way you get to avoid mentioning anything
with 'unsafe' in its name, and the compiler does the safety proof for
you.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Text in Haskell: a second proposal

[Simon Marlow]

Here's my take on the Unicode issue.  Summary: unless there's a very
good reason, I don't think we should decouple encoding/decoding from
I/O, at least for the standard I/O library.

Firstly, types.  We already have all the necessary types:

  - Char, a Unicode code point
  - Word8, an octet
  - CChar, a type representing the C 'char' type

The latter two are defined by the FFI addendum.

Taking hGetChar as an example:

hGetChar :: Handle - IO Char

This combines, IMO, two operations: reading some data from the file, and
decoding enough of it to yield a Char.  Underneath the hood, the Handle
has a particular encoding associated with it.  In GHC, currently we have
two encodings, ISO8859 (aka binary, but we shouldn't use that term
because the I/O library works in terms of Char) and MS-DOS text.  We
could easily extend the set of encodings to include UTF-8 and others.  

Seeking only works on Handles with a 1-1 correspondence between handle
positions and characters (i.e. in the ISO encoding).

Why combine I/O and {en,de}coding?  Firstly, efficiency.  Secondly,
because it's convenient: if we were to express encodings as stream
transformers, eg:

decodeUTF8 :: [Word8] - [Char]

Then we would have to do all our I/O using lazy streams.  You can't
write hGetChar in terms of hGetWord8 using this: you need the non-stream
version which in general looks something like

decode :: Word8 - DecodingState 
- (Maybe [Char], DecodingState)

for UTF-8 you can get away with something simpler, but AFAIK that's not
true in general.  You might want to use compression as an encoding, for
example.  So in general you need to store not only the DecodingState but
also some cached characters between invocations of hGetChar.  It's
highly unlikely that automatic optimisations will be able to do anything
useful with code written using the above interface, but we can write
efficient code if the encoder/decoder can work on the I/O buffer
directly.

There's no reason why we shouldn't provide encoders/decoders as a
separate library *as well*, and we should definitely also provide
low-level I/O that works with Word8.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Yet more text pedantry

[Simon Marlow]

 Can't we make a mailing list for these issues?
 
 [EMAIL PROTECTED] is my proposal, who can create such a list?

I'll set up the list.  Anyone wish to volunteer to moderate it?

Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Yet more text pedantry

[Simon Marlow]

 tis 2002-08-13 klockan 11.57 skrev Simon Marlow:
   Can't we make a mailing list for these issues?
   
   [EMAIL PROTECTED] is my proposal, who can create 
 such a list?
  
  I'll set up the list.  Anyone wish to volunteer to moderate it?
 
 Does it have to be moderated? This will make things progress more
 slowly.

Not necessarily fully moderated, but there needs to be a list admin 
([EMAIL PROTECTED]) who is responsible for dealing with the messages that 
Mailman flags for auto-moderation, and user queries, etc.   I'm already the admin for 
way too many lists on haskell.org, otherwise I'd volunteer myself :-)

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: difference between (evaluate . runST) and stToIO

[Simon Marlow]

 I can't seem to figure out what the difference is between using
 
   evaluate (runST action)
 
 and
 
   stToIO action
 
 when in the IO monad and running something in ST...they seem to behave
 identically...are they?
 
 If they are, why do they have different type signatures (one is ST
 RealWorld a - IO a, while the other is (forall s. ST s a) - IO a)?

With stToIO, you can do this:

   do r - stToIO newSTRef
  stToIO $ writeSTRef r 42
  ...

the types prevent you doing that with runST, but runST is safe to use in
pure code whereas stToIO must be used in the IO monad.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

New mailing list: haskell-i18n (was: RE: Yet more text pedantry)

[Simon Marlow]

  tis 2002-08-13 klockan 11.57 skrev Simon Marlow:
Can't we make a mailing list for these issues?

[EMAIL PROTECTED] is my proposal, who can create 
  such a list?
   
   I'll set up the list.  Anyone wish to volunteer to moderate it?
  
  Does it have to be moderated? This will make things progress more
  slowly.
 
 Not necessarily fully moderated, but there needs to be a list 
 admin ([EMAIL PROTECTED]) who is responsible for 
 dealing with the messages that Mailman flags for 
 auto-moderation, and user queries, etc.   I'm already the 
 admin for way too many lists on haskell.org, otherwise I'd 
 volunteer myself :-)

Thanks everyone who volunteered to admin the list.  We now have an admin, and the 
haskell-i18n list has been created.  Please go to 

http://www.haskell.org/mailman/listinfo/haskell-i18n

to join.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: listen/bind socket problem in GHC 5.04

[Simon Marlow]

 I understand that GHC 5.04 has reoganized the network modules, 
 but somehow my code broke over GHC 5.04... 
 
 prepareSocket addr port = do
 s - socket AF_INET Stream 6
 setSocketOption s ReuseAddr 1
 let port' = PortNum port
 addr' - case addr of
 Just str - inet_addr str = (\x - return 
 (SockAddrInet port' x))
 Nothing  - return (SockAddrInet port' iNADDR_ANY)
 bindSocket s addr'
 listen s 2
 return s

instead of 

let port' = PortNum port

use
let port' = fromIntegral port

The PortNumber type should really be abstract.  Internally, it is stored
in network byte order, but you bypassed the conversion to network byte
order by constructing a value of type PortNumber directly.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Spam

[Simon Marlow]

 Sorry to bother you with a message about spam.
 
 I have noticed two things about this mailing list:
 
 * Every once in a while, we get messages like your e-mail
   is under consideration for sending to the list. This
   suggests that the mailing list is moderated, and that
   there is some person deciding on what can and what cannot
   be sent to the list.
 
   (One could discuss wether it is a good idea to send these
   messages to the whole list rather than just to the person
   who sent them, but let us not discuss that here.)

The list is partly moderated: any message over a certain size, or with
too many destination addresses, or with certain keywords, gets held for
moderation.

The moderation messages you're seeing are caused by viruses (primarily
Win32.Klez) which spoof the sender address.  The virus messages are
always caught by the auto moderation, but sometimes the sender address
has been spoofed to be one of the other Haskell lists, so the moderation
message gets sent there.  Unfortunately causing these messages to be
caught by the moderator would lead to an infinite loop...

 * Very often, we get spam e-mail. This suggests that nobody
   is moderating the list.

Spam is supposed to be caught by SpamAssassin on haskell.org.  It's
doing a pretty good job so far - I get far fewer messages to moderate,
but the occasional one does get through.

 These two observations are in contradiction with each other.
 
 Couldn't we allow list subscribers to submit to the list
 without problems, whereas non-list subscribers have to be
 approved by a list moderator?

I've resisted doing that because (a) I'm lazy and (b) lots of people are
subscribed to the list using addresses which are different from the ones
they post with, so we'd have to gradually build up a list of those
addresses which are allowed.

Well, maybe I'll give it a go for a while.  If it's too much hassle
expect an advertisment for the moderator's job soon...

Cheers, 
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

ANNOUNCE: GHC version 5.04.1 released

[Simon Marlow]

   ==
The (Interactive) Glasgow Haskell Compiler -- version 5.04.1
   ==

We are pleased to announce a new patchlevel release of the Glasgow
Haskell Compiler (GHC), version 5.04.1.  This is a bugfix-only
release.  For all the changes since 5.02.3, see the release notes:

   http://www.haskell.org/ghc/docs/latest/users_guide/release-5-04.html


How to get it
~
The easy way is to go to the WWW page, which should be self-explanatory:

http://www.haskell.org/ghc/

We supply binary builds in the native package format for various
flavours of Linux and BSD, and in InstallShield form for Windows
folks.  Binary builds for other platforms are available as a .tar.gz
which can be installed wherever you want.  The source distribution is
also available from the same place.

Once you have the distribution, please follow the pointers in the
README file to find all of the documentation about this release.


Background
~~
Haskell is a standard lazy functional programming language; the
current language version is Haskell 98, agreed in December 1998.

GHC is a state-of-the-art programming suite for Haskell.  Included is
an optimising compiler generating good code for a variety of
platforms, together with an interactive system for convenient, quick
development.  The distribution includes space and time profiling
facilities, a large collection of libraries, and support for various
language extensions, including concurrency, exceptions, and foreign
language interfaces (C, whatever).  GHC is distributed under a
BSD-style open source license.

A wide variety of Haskell related resources (tutorials, libraries,
specifications, documentation, compilers, interpreters, references,
contact information, links to research groups) are available from the
Haskell home page (see below).


On-line GHC-related resources
~~

Relevant URLs on the World-Wide Web:

GHC home page http://www.haskell.org/ghc/
Haskell home page http://www.haskell.org/
comp.lang.functional FAQ  http://www.cs.nott.ac.uk/~gmh/faq.html



System requirements
~~~
To compile programs with GHC, you need a machine with 64+MB memory, GCC
and perl. This release is known to work on the following platforms:

  * i386-unknown-{linux,*bsd,mingw32}
  * sparc-sun-solaris2
  * alpha-dec-osf3
  * powerpc-apple-darwin (MacOS/X)

Ports to the following platforms should be relatively easy (for a
wunderhacker), but haven't been tested due to lack of time/hardware:

  * hppa1.1-hp-hpux{9,10}
  * i386-unknown-solaris2
  * mips-sgi-irix{5,6}
  * {rs6000,powerpc}-ibm-aix

The builder's guide on the web site gives a complete run-down of what
ports work; it can be found at

   http://www.haskell.org/ghc/docs/latest/building/building-guide.html


Mailing lists
~
We run mailing lists for GHC users and bug reports; to subscribe, use
the web interfaces at

http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

There are several other haskell and ghc-related mailing lists on
www.haskell.org; for the full list, see

http://www.haskell.org/mailman/listinfo/

Please report bugs using our SourceForge page at

http://sourceforge.net/projects/ghc/

or send them to [EMAIL PROTECTED]

GHC users hang out on [EMAIL PROTECTED]  Bleeding
edge CVS users party on [EMAIL PROTECTED]

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Q: Forcing repeated evaluation

[Simon Marlow]

 From: D. Tweed [mailto:[EMAIL PROTECTED]] 

 Note that (assuming that I'm not missing something) you can 
 prevent the
 moving of expressions involving l in a very ugly way by 
 noting that these
 `dummy argument functions' are polymorphic so that you could write
 
 x1 = f1 (l 1)
 x2 = f2 x1 (l 2)
 x3 = f3 x2 (l 3)

Please don't encourage this sort of thing.  If two expressions are
semantically equivalent, there's always a chance that the compiler will
replace one by the other or common them up. 

In this case, I believe GHC's worker-wrapper transformation will do it.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Behaviour of div mod with negative arguments?

[Simon Marlow]

 Does Haskell specify how div and mod should behave when
 given one or both arguments negative?
 
 Eg, in hugs we get:
 
 div   13  = 0
 div (-1)   3  = -1
 div   1  (-3) = -1
 div (-1) (-3) = 0
 
 and so on.

We usually describe div as the version of division that truncates
towards negative infinity.  What this actually means is that when there
are two solutions to

a `divMod` b = (d,m)  
  such that  d*b + m == a 
  andabs m  b

div picks the one where d is the closest to minus infinity, and quot
picks the one where d is closer to zero.

  eg.  (-1) `divMod` 3  = (-1, 2)   or  (0, -1)

divMod gives you (-1,2), whereas quotRem gives you (0,-1).

Hope this helps.

Cheers,
SImon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Bug? 'Storable' and 'with'

[Simon Marlow]

 I am using ghc-5.04 and a code like:
 
 with c ( \c' - hPutBuf h c' (sizeOf c))
 
 fails with Fail: Prelude.undefined when c is a user defined type,
 such as a pair:
 
 instance (Storable at,Storable bt) = Storable (at,bt) where
sizeOf (a,b) = sizeOf a + sizeOf b
alignment (a,b) = max (alignment a) (alignment b)
peek p = do a - peek ((castPtr p):: Ptr at) 
b - peekByteOff ((castPtr p):: Ptr bt) (sizeOf a)
return (a,b)
poke p (a,b) = do poke ((castPtr p):: Ptr at) a
  pokeByteOff ((castPtr p):: Ptr bt) 
 (sizeOf a) b

sizeOf and alignment are not supposed to evaluate their arguments.  You
might try making the definitions in your instance above a little lazier:

sizeOf z = sizeOf a + sizeOf b where (a,b) = z
alignment z = max (alignment a) (alignment b) where (a,b) = z

(feel free to use '~' if you prefer).

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Using Bison as Haskell parser generator

[Simon Marlow]

 (I am currently not on this list, so replies, please cc me.)
 
 The later versions of the GNU parser generator Bison, like
   ftp://ftp.gnu.org/gnu/bison/bison-1.75.tar.gz   (959 KB)
   ftp://ftp.gnu.org/gnu/bison/bison-1.75.tar.bz2  (759 KB)
 use the macro processing program M4 to produce the source code output.
 
 This should make it real easy to write parser generator 
 (skeleton) files
 designed for special languages.
 
 So I wonder if somebody may want to make an attempt to produce such
 skeleton files for Haskell. Bison has now not only an LALR(1) parser
 algorithm, but also a GLR parser, and more is to come.

Note that Happy has support for some Haskellish things which you won't
get if you use bison to generate Haskell.  For example: type signatures
on productions, and support for threading a monad around the parser.

Nevertheless, doing this sounds entirely feasible.  The parser tables
generated by bison are very similar to those generated by Happy (I
peeked at bison's source when I wrote the table-generation code in
Happy), so looking at Happy's LALR(1) machine might be a good place to
start.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Best recursion choice for penultimax

[Simon Marlow]

 Some quick tests with Hugs +s on a example list that I constructed
 with 576 elements give food for thought:
 
   reductions cells
my one liner  403511483
tournament705312288
your penultimax  1671520180
your penultimax2  746610344
your penultimax3  860513782

And with GHC -O, the results are quite different:

Mark's one liner 0.60s
tournament   0.25s
your penultimax  0.26s
your penultimax2 0.25s
your penultimax3 0.25s

the tests were with random numbers (different seed each time), but there
was only a little little fluctuation from run to run.  I specialised all
the algorithms to Int.

Hugs doesn't do much optimisation, so the reductions/cells counts tend
to vary quite a bit between programs which GHC will optimise to the same
or similar code.  The moral, as usual, is YMMV...

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

ANNOUNCE: GHC version 5.04.2 released

[Simon Marlow]

   ==
The (Interactive) Glasgow Haskell Compiler -- version 5.04.2
   ==

We are pleased to announce a new patchlevel release of the Glasgow
Haskell Compiler (GHC), version 5.04.2.  This is a bugfix-only
release.  For all the changes since 5.02.3, see the release notes:

   http://www.haskell.org/ghc/docs/latest/users_guide/release-5-04.html


How to get it
~
The easy way is to go to the WWW page, which should be self-explanatory:

http://www.haskell.org/ghc/

We supply binary builds in the native package format for various
flavours of Linux and BSD, and in InstallShield form for Windows
folks.  Binary builds for other platforms are available as a .tar.gz
which can be installed wherever you want.  The source distribution is
also available from the same place.

Once you have the distribution, please follow the pointers in the
README file to find all of the documentation about this release.


Background
~~
Haskell is a standard lazy functional programming language; the
current language version is Haskell 98, agreed in December 1998.

GHC is a state-of-the-art programming suite for Haskell.  Included is
an optimising compiler generating good code for a variety of
platforms, together with an interactive system for convenient, quick
development.  The distribution includes space and time profiling
facilities, a large collection of libraries, and support for various
language extensions, including concurrency, exceptions, and foreign
language interfaces (C, whatever).  GHC is distributed under a
BSD-style open source license.

A wide variety of Haskell related resources (tutorials, libraries,
specifications, documentation, compilers, interpreters, references,
contact information, links to research groups) are available from the
Haskell home page (see below).


On-line GHC-related resources
~~

Relevant URLs on the World-Wide Web:

GHC home page http://www.haskell.org/ghc/
Haskell home page http://www.haskell.org/
comp.lang.functional FAQ  http://www.cs.nott.ac.uk/~gmh/faq.html



System requirements
~~~
To compile programs with GHC, you need a machine with 64+MB memory, GCC
and perl. This release is known to work on the following platforms:

  * i386-unknown-{linux,*bsd,mingw32}
  * sparc-sun-solaris2
  * alpha-dec-osf3
  * powerpc-apple-darwin (MacOS/X)

Ports to the following platforms should be relatively easy (for a
wunderhacker), but haven't been tested due to lack of time/hardware:

  * hppa1.1-hp-hpux{9,10}
  * i386-unknown-solaris2
  * mips-sgi-irix{5,6}
  * {rs6000,powerpc}-ibm-aix

The builder's guide on the web site gives a complete run-down of what
ports work; it can be found at

   http://www.haskell.org/ghc/docs/latest/building/building-guide.html


Mailing lists
~
We run mailing lists for GHC users and bug reports; to subscribe, use
the web interfaces at

http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

There are several other haskell and ghc-related mailing lists on
www.haskell.org; for the full list, see

http://www.haskell.org/mailman/listinfo/

Please report bugs using our SourceForge page at

http://sourceforge.net/projects/ghc/

or send them to [EMAIL PROTECTED]

GHC users hang out on [EMAIL PROTECTED]  Bleeding
edge CVS users party on [EMAIL PROTECTED]

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: ANNOUNCE: GHC version 5.04.2 released

[Simon Marlow]

==
 The (Interactive) Glasgow Haskell Compiler -- version 5.04.2
==
 
 We are pleased to announce a new patchlevel release of the Glasgow
 Haskell Compiler (GHC), version 5.04.2.  This is a bugfix-only
 release.  For all the changes since 5.02.3, see the release notes:
 

 http://www.haskell.org/ghc/docs/latest/users_guide/release-5-04.html

Oops, that URL should be 

 
http://www.haskell.org/ghc/docs/latest/html/users_guide/release-5-04.htm
l

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: stupid strictness question

[Simon Marlow]

 Now, we define:
 
  data SMaybe a = SNothing | SJust !a  deriving Show
 
 Now, we run:
 
 *Strict Just (undefined::Int)
 Just *** Exception: Prelude.undefined
 *Strict Just $! (undefined::Int)
 *** Exception: Prelude.undefined
 *Strict SJust $! (undefined::Int)
 *** Exception: Prelude.undefined
 *Strict SJust (undefined::Int)
 SJust *** Exception: Prelude.undefined

 I can't figure out why this last one is different from the 
 one before it, or the one before that.

This one is a GHCi (not GHC) bug.  You may have seen this message while
loading the source containing the strict constructor definition:

WARNING: ignoring polymorphic case in interpreted mode.
   Possibly due to strict polymorphic/functional constructor args.
   Your program may leak space unexpectedly.

which means that GHCi essentially ignored the strictness flag on the
polymorphic field of the SJust constructor.  To work around the bug, you
can compile that module with GHC.

The good news is that this bug will be fixed in the next major release.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Running out of memory in a simple monad

[Simon Marlow]

Alastair Reid writes:

 The workaround is simple enough: add a dummy argument to the CAF (so
 that it is not a CAF any more):
 
main _ = loop 5
 
 and then specify the extra argument when invoking it:
 
main ()
 
 (This is a pretty standard optimisation technique: we're trading time
 to recompute a result for the space taken to store the result.  Coming
 from other languages where actions (i.e., monadic computations) are
 not first class values, this is a bit surprising but, from a Haskell
 perspective, it is completely uniform.)

Careful: this isn't guaranteed to turn a CAF into a function.  In
particular, GHC will optimise away this trick when optimisation is
turned on (and perhaps even when it isn't).  The point is that adding
dummy arguments isn't really a technique that should be relied upon.

You might well argue that there ought to be a way to control the
operational behaviour of the program w.r.t. CAFs (and in fact sharing in
general), and I'd be inclined to agree.

Also, GHCi retains CAFs in the same way as Hugs, the difference is that
GHCi can be configured to throw away the results after evaluation (:set
+r).

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Running out of memory in a simple monad

[Simon Marlow]

 Simon Marlow [EMAIL PROTECTED] writes:
  Also, GHCi retains CAFs in the same way as Hugs, the difference is
  that GHCi can be configured to throw away the results after
  evaluation (:set +r).
 
 If I set this flag, does GHCi discard CAFs during evaluation or at the
 end of evaluation?  Or, to put it another way, do classic 
 examples like
 
   module Main(main,primes) where
 
   main = print primes
   primes = ...
 
 leak space?

Actually CAF reverting only applies to CAFs in compiled code at the
moment, and it happens after evaluation, not during it.  The primes
example will leak in GHCi (not in plain GHC, though).

I guess the right thing to do is to revert them as soon as they're found
to be unreferenced, but that's hard - the compiler's symbol table refers
to all the top-level bindings, so it would probably have to use weak
pointers.

The CAF reverting feature was added mainly so that you can recover from
doing hGetContents on stdout.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: IO confusion

[Simon Marlow]

 With Foo in the file c.out and the module
 
 \begin{code}
 module Main (main) where
 
 import IO (openFile, hGetContents, hClose, IOMode(ReadMode))
 import System (getArgs)
 import Monad (when)
 
 main :: IO ()
 main = do [x] - getArgs
   let you_want_it_to_work = read x
   cout - openFile c.out ReadMode
   s - hGetContents cout
   putStrLn 
   when you_want_it_to_work $ putStrLn $ Got this:  ++ s
   putStrLn 
   hClose cout
   putStrLn $ The answer is:  ++ s
 \end{code}
 
 I expected The answer is: Foo to be printed whether the argument was
 True or False. When it is False, however, GHC (5.02.2, 5.04 and recent
 CVS HEAD) think s is the empty string and nhc98 (1.10 and a 1.11
 from about a year ago) produces a binary that segfaults. At first I
 thought it was a GHC bug, but now nhc98 also exhibits it I am 
 wondering if it is a bug in my understanding?

Lazy I/O strikes again :-)

When the argument is True, you should get

   Got this: Foo

   The answer is: Foo

and when the argument is False, one possible correct output is:

   The answer is:

which GHC (5.04.2 and CVS HEAD) does indeed produce.  Another correct
output would be

   The answer is: Foo

in fact, any prefix of Foo, including the empty string, would be
correct.  See section 21.2.2 in the (revised) Haskell 98 report.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Urgent Help: URI parser

[Simon Marlow]

 I wonder what happens to the port when URI parses http URL 
 string. Is it
 possible to check for : and use the stated port instead of port 80?
 Anyone has experience doing it before?
 Thanks in advance.
 Cheers,
 Gek

The Network.URI library will extract the host:port:

 authority (fromJust (parseURI http://www.haskell.org:80/;))
www.haskell.org:80

You have to split this string into the separate host and port parts
yourself.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Interpret haskell within haskell.

[Simon Marlow]

 I was wondering if there is any project that aims to
 interpret haskell within haskell.
 
 Is it feasable that a program can import a user's .hs
 file that has something like:
 
 greeting :: String
 greeting = Something
 
 port :: Int
 port = 32 + 33
 
 And the program can parse and execute the user's
 function.
 
 I'm looking for something similar to the eval command
 in Python.

You could potentially do this with GHCi, but we haven't tried.  The idea
is that you would need to expose parts of GHCi itself as a library which
can be used from the program.  Linking is a bit tricky (you don't want
to load another copy of GHCi), but we know one way to get around that:
the --export-dynamic flag to ld.

If you're interested in having a go, come on over to
[EMAIL PROTECTED] and we'll help out with any problems
you run into.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Evaluation Question

[Simon Marlow]

 For each call, I believe.  An exception might be if the call to nco is
 inlined into the calling function, but this is unlikely as nco is
 recursive.
 
 So, you're probably better off with:
 
  nco wn = nco'
  where wn'  = cis wn
nco' = 1 : map (wn'*) nco'
 
 In which case it will only be evaluated once.

The original version should also evaluate the expression 'cis wn' only
once:

 nco:: RealFloat a = a - [ Complex a ]
 nco wn = 1 : map ((*) (cis wn)) (nco wn)

You can verify this using an appropriate semantics for lazy evaluation.
However, another way to think about it is to consider the expression

(*) (cis wn)

as

(let x = cis wn in (*) x)

which when first evaluated will create a suspension for x in the heap,
and return

\y - (*) y x

as its value.  So x only gets allocated/evaluated once.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: time since the epoch

[Simon Marlow]

[snip]
 It is always a problem to lump things with different semantics into
 the same type :-) What I'm arguing is that there should be only one
 fixed-duration offset datatype and it should be in terms of (seconds,
 picoseconds).
 Other fixed durations can be easily defined in terms of this
 datatype. 
 I'm still not sure that you actually want base-dependent offsets, but
 again they can be easily defined on top of the fixed duration
 datatype. And they should be specified separately from the base
 functionality.
[snip]

I wrote a reply, but I don't really have anything new to say over what's
been said already, so I'll keep it brief instead.  The copy of ISO8601
that I looked at is here:
http://www.astroclark.freeserve.co.uk/iso8601/index.htm, but from what
you said I'm guessing you're looking at a different version.

Anyway, to sum up: 

  - I agree that there should be a constant-duration time offset type.
However, TimeDiff does actually fuction perfectly well as one at
the moment, since diffClockTimes only fills in the seconds and
picoseconds fields.

  - I believe a reasonable interpretation of the other fields of
TimeDiff is as base-dependent offsets.  The current implementation 
in GHC doesn't do this, but you can use TimeExts which does.

  - Our implementation of ClockTime uses C's gettimeofday(), which
apparently is based a broken definition of the epoch.  Oh well :-)

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Yet another weakly defined bug report

[Simon Marlow]

 The following code runs out of file handles, so I am seeking
 enlightenment as to why.
 
  -- | add data from a file to the histogram
  addFile :: FiniteMap String Int - String - IO (FiniteMap 
 String Int)
  addFile fm name = do
x - readFile name
return (addHist fm x)
  
  -- | add data from all files in a directory to the histogram
  addDir :: FiniteMap String Int - String - IO (FiniteMap 
 String Int)
  addDir fm dir = do
  dc - getDirectoryContents dir
  fs - filterM doesFileExist (map ((dir++/)++) dc)
  foldM addFile fm fs
 
 Running addDir on a directory with few hundred files trigs it.
 Shouldn't all of each file's contents be consumed by each addFile, and
 thus the handle be released? 

It's not possible to tell from this code whether the readFiles will be
fully evaluated or not: it depends on how much evaluation addHist does,
and to what extend the result FiniteMap is demanded, amongst other
things.

These things are always tricky to understand, which is why I recommend
not using lazy I/O.  File reading is not a pure operation: running out
of file descriptors is a good counter-example.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Yet another weakly defined bug report

[Simon Marlow]

 What is the limit on open files, and why?  I think it'd be nice to
 just schedule a huge amount of IO operations, and have them all be
 performed when required (i.e. when the FM is first accessed).
 Apparently, my addDir took the trouble to open the files, but not
 generate the FMs -- any idea why?

The limit is imposed by the OS, and is usally tunable.  Try 'ulimit -a'
on a Unix box (the command might be different depending on your shell;
check the manpage).

readFile must *open* the file strictly, because it has to raise an
exception if any errors occur.  But thereafter, all reading is done
lazilly.  If you also want the open to be lazy, then use
unsafePerformIO.  It's Your Funeral, as we say in GHC land ;-)

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Yet another weakly defined bug report

[Simon Marlow]

 You should do the counting strictly:
 
 Just n - case n+1 of n1 - addToFM f w n1

Careful - that case expression doesn't actually force n to be evaluated.
It's exactly equivalent to

   let n1 = n+1 in addToFM f w n1

You need to use seq to force evaluation.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Happy Alex

[Simon Marlow]

 I have successfully used the the excellent haskell tools 
 Happy and Alex in a 
 couple of parsing projects, but I have failed when trying to  
 combine a 
 monadic Happy grammar (using the %monad and %lexer 
 directives) together with 
 an Alex generated okenizer, nor are there any such examples 
 in the Happy and 
 Alex distributions. Have anyone tried this combination and 
 can give me some 
 advice or a simple example?

I've been doing some work on Alex recently, and getting it to work
smoothly with Happy's monadic scheme is one of the goals.  I'll post
something when it's done, but if you want to have a look at the
work-in-progress look in the CVS tree, under fptools/happy/alex on the
branch simonm-hackery-branch.

The other things I'm doing include making Alex's syntax more lex-like
and Happy-like (mostly done), making the generated code more efficient
in terms of both space and time (mostly done), and adding support for
Unicode (not done, I'm still thinking about how best to do this - I have
some ideas but suggestions are welcome).

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: HTTP protocol libraries

[Simon Marlow]

 From: Bayley, Alistair [mailto:[EMAIL PROTECTED] 
 
 On a related note, what happened to the source code for the 
 Haskell Web
 Server?
 
 http://research.microsoft.com/~simonmar/hws.tar.gz
 
 Is it no longer suitable for public consumption? (I have a 
 copy at home somewhere, though).

It's in GHC's CVS repository, under fptools/hws. 

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: URI handling code in Haskell available

[Simon Marlow]

 Oops.  I didn't find that.  Thanks for the pointer.  (Thinks: 
  does it work with HUGS?)

It works with the latest hugs, November 2002 (use hugs +N to get the
hierarchical libraries).

 A significant amount of my work went into the test cases and 
 matching the 
 parsing code against the (revised work-in-progress) URI spec, 
 so maybe 
 there's some residual value there...?

When I wrote Network.URI I took the grammar from the RFC, and also a
bunch of test cases, which are in GHC's testsuite
(fptools/testsuite/tests/ghc-regress/lib/net/uri001.hs).  It might not
be up to date with the latest rev of the spec, however.  Any extra
testing you can do and/or comments you have on the API would be
appreciated.

One thing I know is questionable is that parseURI returns a Maybe URI,
when in fact there are no strings for which it can return Nothing
(*everything* is a valid URI, it seems!).

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Persistant (as in on disk) data

[Simon Marlow]

 a recent post reminded me of a feature i'd like.
 for all i know it is already implemenetd in GHC so pointers 
 are welcome.
 
 i'd like to be able to dump data structures to disk, and later load 
 them.

A Binary library was discussed recently on the libraries list.  The
thread starts here:

http://www.haskell.org/pipermail/libraries/2002-November/000691.html

It's currently stalled.  There are several implementations of Binary:
one that comes with NHC and is described in a paper (sorry, don't have a
link to hand), a port of this library to GHC by Sven Panne (suffers from
bitrot), a derived/simplified version used in GHC which is heavily
hacked for speed, and a further derived version of this library by Hal
Daume who is adapting it to support bit-by-bit serialisation.

I think the outstanding issues are

  (a) is the API for GHC's Binary library acceptable, or do we need
  the extra bells and whistles that the NHC version has?

  (b) can we make a version of Binary that uses a bit-by-bit
  rather than byte-by-byte serialisation of the data that is
  as fast (or nearly as fast) as the current byte-by-byte
  implementation?  Perhaps performance isn't that important
  to the majority of people: please comment if you have
  an opinion.

  (c) how do we derive instances of Binary?

IMHO: something is better than nothing, so I'd be in favour of just
plugging in the Binary library from GHC, and marking it experimental.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

ANNOUNCE: GHC vesrion 5.04.3 released

[Simon Marlow]

   ==
The (Interactive) Glasgow Haskell Compiler -- version 5.04.3
   ==

We are pleased to announce a new patchlevel release of the Glasgow
Haskell Compiler (GHC), version 5.04.3.  This is a bugfix-only
release.  For all the changes since 5.02.3, see the release notes:

 
http://www.haskell.org/ghc/docs/latest/html/users_guide/release-5-04.htm
l


How to get it
~
The easy way is to go to the WWW page, which should be self-explanatory:

http://www.haskell.org/ghc/

We supply binary builds in the native package format for various
flavours of Linux and BSD, and in InstallShield form for Windows
folks.  Binary builds for other platforms are available as a .tar.gz
which can be installed wherever you want.  The source distribution is
also available from the same place.

Once you have the distribution, please follow the pointers in the
README file to find all of the documentation about this release.


Background
~~
Haskell is a standard lazy functional programming language; the
current language version is Haskell 98, agreed in December 1998.

GHC is a state-of-the-art programming suite for Haskell.  Included is
an optimising compiler generating good code for a variety of
platforms, together with an interactive system for convenient, quick
development.  The distribution includes space and time profiling
facilities, a large collection of libraries, and support for various
language extensions, including concurrency, exceptions, and foreign
language interfaces (C, whatever).  GHC is distributed under a
BSD-style open source license.

A wide variety of Haskell related resources (tutorials, libraries,
specifications, documentation, compilers, interpreters, references,
contact information, links to research groups) are available from the
Haskell home page (see below).


On-line GHC-related resources
~~

Relevant URLs on the World-Wide Web:

GHC home page http://www.haskell.org/ghc/
Haskell home page http://www.haskell.org/
comp.lang.functional FAQ  http://www.cs.nott.ac.uk/~gmh/faq.html



System requirements
~~~
To compile programs with GHC, you need a machine with 64+MB memory, GCC
and perl. This release is known to work on the following platforms:

  * i386-unknown-{linux,*bsd,mingw32}
  * sparc-sun-solaris2
  * alpha-dec-osf3
  * powerpc-apple-darwin (MacOS/X)

Ports to the following platforms should be relatively easy (for a
wunderhacker), but haven't been tested due to lack of time/hardware:

  * hppa1.1-hp-hpux{9,10}
  * i386-unknown-solaris2
  * mips-sgi-irix{5,6}
  * {rs6000,powerpc}-ibm-aix

The builder's guide on the web site gives a complete run-down of what
ports work; it can be found at

   http://www.haskell.org/ghc/docs/latest/building/building-guide.html


Mailing lists
~
We run mailing lists for GHC users and bug reports; to subscribe, use
the web interfaces at

http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

There are several other haskell and ghc-related mailing lists on
www.haskell.org; for the full list, see

http://www.haskell.org/mailman/listinfo/

Please report bugs using our SourceForge page at

http://sourceforge.net/projects/ghc/

or send them to [EMAIL PROTECTED]

GHC users hang out on [EMAIL PROTECTED]  Bleeding
edge CVS users party on [EMAIL PROTECTED]

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Problem with hierarchical libraries.

[Simon Marlow]

  IIRC, something very similar was suggested a while back on 
 the libraries
  list, except that the form beginning with a dot was the 
 relative module
  name (actually I think I prefer it that way).

 this seems exactly the opposite of what all file systems do.  i know 
 lateral thinking is great, but why do we have to be backwards 
 all the time?

Because it seems strange to have to add the prefix dot to all of our
existing imports ('import Prelude' becomes 'import .Prelude').  Besides,
I like the idea that the prefix dot is an indication that the current
module name has been omitted.

  Personally, I've been using the hierarchical module names 
 for a while
  and I really don't mind writing out the whole name each 
 time.  It means
  you have less context to think about when reading the source.
 oh come on :-)   most of the time you don't get to see the 
 module name 
 at all -- you have to keep scrolling to the top of the file.  
 virtually 
 every editor can tell you what is the name of the file you are 
 editing... (:f in vim).  and tools like haddoc can display 
 the name of 
 the module anyways.

I think you misunderstand me - my point was that currently, an import
declaration means the same regardless of what the current module name
is.  With relative imports, that's not true any more (but you're right
that the editor usually helps by showing the filename).  It's a minor
point I grant you, but simplicity at the expense of a bit of extra
typing is sometimes a good thing.

  This arises because the meaning of a module is defined 
 independently of
  the mapping between modules and filenames.

 the meaning of modules can still be independent of the 
 mapping between 
 modules and filesnames.   all that has to be specified is how 
 to compute this mapping.

And that's exactly what we don't want to do (IMO).  Filesystems are too
different - what about filesystems that don't have directories?  What if
I want to store my source code in a database or on the web?  What about
non-case-sensitive filesystems, or ones with restrictions on the length
of filenames?

 and one has to do that anyways, even if the haskell 
 report pretends that this can be ommited. 

Yes, but the point is that it is done by the compiler, not the language
specification, so compilers are free to implement different policies,
and the spec doesn't have to acquire any platform-specific warts.

The mapping between filenames and module names in GHC is rather
complicated, see recent discussions on
[EMAIL PROTECTED]  The mapping in Hugs is different -
more liberal in some ways, but less complicated because of the lack of
interface files.

[snip]
 in fact if one decides to ignore this mapping, 
 all that the hirarchical modules proposal does is allow one 
 to write . in a module name.

Bingo :-)

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: flock and sockets

[Simon Marlow]

 I am planning a Haskell project and I need to access files. Since the
 program will be automatically started whenever a mail comes 
 in I will need
 to be able to lock the access to files. Is there any support 
 for this in some library?

Yes, the Posix library distributed with GHC has support for file
locking.  See

  http://www.haskell.org/ghc/docs/latest/html/hslibs/sec-posix.html

This library is currently undergoing a rewrite - the functionality will
be available under System.Posix in future releases of GHC (and possibly
Hugs  NHC).

 The second option that I have is to use a daemon and let the 
 programs that
 get started by mail connect via some sort of socket. Is there 
 any socket support in Haskell?

Yes:

  http://www.haskell.org/ghc/docs/latest/html/network/index.html

(currently only available with GHC).

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Web server code in Haskell by Simon Marlow?

[Simon Marlow]

 I am very interested in writing server programs in haskell.
 
 There is a link to a paper and code of haskell web server
 in the following page.
 
 http://www.haskell.org/practice.html

 I can see the case study paper, but there is no code at
 the link location. I think inspecting through code might be
 very helpful, even if it does not compiling in the recent
 version of GHC.

The link is out of date.  The code is now in the CVS repository, and it
has a proper license.  You can browse it on the web, here:

http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hws/

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Performance Timing

[Simon Marlow]

 timer f a = do
   t1 - get current time
   evaluate (f a)
   t2 - get current time
   return (different in t2 and t1)
 
 where evaluate is from Control.Exception.  could someone tell me how
 evaluate compares to seq and deepSeq?

The documentation explains the difference, but it's a bit cryptic.

Informally: 'evaluate e' is an IO action that, when performed, forces e
to weak-head normal form.  It's a kind of seq that you can use in the IO
monad.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Two minor reports concerning GHC

[Simon Marlow]

 
 (1) unhelpful error message from GHCi:
 
 [[
 Compiling ParsecPrim   ( F:\Haskell\Lib/ParsecPrim.hs, 
 interpreted )
 WARNING: ignoring polymorphic case in interpreted mode.
 Possibly due to strict polymorphic/functional constructor args.
 Your program may leak space unexpectedly.
 ]]
 I don't understand what this is trying to say, and the lack 
 of a source 
 code line number doesn't give me any chance to study the code for 
 clues.  This warning is GHCi only.

It is warning you about a bug in GHC.  Fortunately, the bug has been
fixed in the forthcoming 6.0 release.

 (2) Strange behaviour of GHCs Time.diffClockTimes function:
 
 This code fragment:
 [[
 runTest t =
  do  { st - Time.getClockTime
  ; putStr $ Test started:  ++show st++\n
  ; runTestTT t
  ; ft - Time.getClockTime
  ; putStr $ Test finished: ++show ft++\n
  ; let et = Time.diffClockTimes ft st
  ; putStr $ Test duration: ++show et++\n
  }
 ]]
 
 yields this output:
 [[
 Test duration: TimeDiff {tdYear = 0, tdMonth = 0, tdDay = 0, 
 tdHour = 0, 
 tdMin = 0, tdSec = 9, tdPicosec = -4370}
 ]]

This is reasonable, as far as I can tell.  The only requirement on a
TimeDiff is that:

  t1 `addToClockTime` (t1 `diffClockTimes` t2) == t2

and the TimeDiff above does just that.  It *could* be normalised so that
the signs of the two components are the same, but the current
implementation doesn't do that.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: ANNOUNCE: GHC version 6.0

[Simon Marlow]

 
 Congratulations on the new release. But out of curiosity, I've got to
 ask...
 
   Why is the test suite now driven by a python script? Is this a
   niche where a 'scripting' language was deemed more suitable than
   haskell?

The test driver makes use of 'eval'-style scripting, which none of the
existing Haskell systems has.  

Template Haskell does provide a kind of 'eval', but it is compile-time
rather than run-time.  That's interesting though: I hadn't thought about
it, but it might be possible to implement the test framework as a
Haskell library which uses Template Haskell.

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Typesafe MRef with a regular monad

[Simon Marlow]

Simon P.J. writes:

 ... So it's reasonable that there should be some language extension. 
 I'm just looking for the minimal such extension.

unsafeCoerce# is quite a minimal extension :-)

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Problems with working with Handles (PS)

[Simon Marlow]

 
 (moderator, can you please include this mail at the bottom of my 
 previous mail?)
 
 PS: I think the next example shows pretty well what goes wrong when 
 you're not closing the read-handle:
 
 ---
 test = do writeFile' 123.txt blaat
 
  appendFile' 123.txt  1
  z - readFile' 123.txt
 
  appendFile' 123.txt  2
  s - readFile' 123.txt
  appendFile' 123.txt  3
  t - readFile' 123.txt
  putStr (\n\n)
  putStr (z ++ \n ++ s ++ \n ++ t)
 
 ---
 
 Instead of blaat 1
 blaat 1 2
  blaat 1 2 3
 
 three lines of blaat 1 2 3 are outputted.

Note that on a conforming Haskell 98 system, the above program (with the
primes deleted) will fail.  For example, GHC responds:

Fail: resource busy
Action: openFile
Reason: file is locked
File: 123.txt

This is because Haskell 98 specifies that the IO system should implement
multiple-reader/single-writer locks on a per-file basis.

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

ANNOUNCE: GHC version 6.0

[Simon Marlow]

   
The (Interactive) Glasgow Haskell Compiler -- version 6.0
   

We are pleased to announce a new major release of the Glasgow Haskell
Compiler (GHC), version 6.0.

As with all .0 releases, this release should be considered
beta-quality; if you want real stability, then stick with 5.04.3 for
the time being.

Highlights of this release include:

  * Template Haskell, a new metaprogramming extension.

  * More hierarchical libraries.

  * Conformance with the latest FFI specification.

  * Sweeping internal changes to switch the evaluation model from
push/enter to eval/apply.

See the release notes for a full list of the changes:

 
http://www.haskell.org/ghc/docs/latest/html/users_guide/release-6-0.html


How to get it
~
The easy way is to go to the WWW page, which should be self-explanatory:

http://www.haskell.org/ghc/

We supply binary builds in the native package format for various
flavours of Linux and BSD, and in Windows Installer (MSI) form
for Windows folks.  Binary builds for other platforms are available
as a .tar.gz which can be installed wherever you want.  The source
distribution is also available from the same place.

Packages will appear as they are built - if the package for your
system isn't available yet, please try again later.

Background
~~
Haskell is a standard lazy functional programming language; the
current language version is Haskell 98, agreed in December 1998, and
revised in December 2002.

GHC is a state-of-the-art programming suite for Haskell.  Included is
an optimising compiler generating good code for a variety of
platforms, together with an interactive system for convenient, quick
development.  The distribution includes space and time profiling
facilities, a large collection of libraries, and support for various
language extensions, including concurrency, exceptions, and foreign
language interfaces (C, whatever).  GHC is distributed under a
BSD-style open source license.

A wide variety of Haskell related resources (tutorials, libraries,
specifications, documentation, compilers, interpreters, references,
contact information, links to research groups) are available from the
Haskell home page (see below).


On-line GHC-related resources
~~

Relevant URLs on the World-Wide Web:

GHC home page http://www.haskell.org/ghc/
Haskell home page http://www.haskell.org/
comp.lang.functional FAQ  http://www.cs.nott.ac.uk/~gmh/faq.html



System requirements
~~~
To compile programs with GHC, you need a machine with 64+MB memory, GCC
and perl. This release is known to work on the following platforms:

  * i386-unknown-{linux,*bsd,mingw32}
  * sparc-sun-solaris2
  * alpha-dec-osf3
  * powerpc-apple-darwin (MacOS/X)

Ports to the following platforms should be relatively easy (for a
wunderhacker), but haven't been tested due to lack of time/hardware:

  * hppa1.1-hp-hpux{9,10}
  * i386-unknown-solaris2
  * mips-sgi-irix{5,6}
  * {rs6000,powerpc}-ibm-aix

The builder's guide on the web site gives a complete run-down of what
ports work; it can be found at

 
http://www.haskell.org/ghc/docs/latest/html/building/building-guide.html


Mailing lists
~
We run mailing lists for GHC users and bug reports; to subscribe, use
the web interfaces at

http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

There are several other haskell and ghc-related mailing lists on
www.haskell.org; for the full list, see

http://www.haskell.org/mailman/listinfo/

Please report bugs using our SourceForge page at

http://sourceforge.net/projects/ghc/

or send them to [EMAIL PROTECTED]

GHC users hang out on [EMAIL PROTECTED]  Bleeding
edge CVS users party on [EMAIL PROTECTED]

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Proposal for a new I/O library design

[Simon Marlow]

[ replies to [EMAIL PROTECTED] ]

On the whole, I think this is a good direction to explore.  I like the
separation of Files from Streams: indeed it would remove much of the
complication in the existing system caused by having Handles which can
be both read and written.  Also, it gives a nice way to integrate other
objects such as Sockets into the I/O system, which can also have streams
layered on top of them.

I'm concerned about one implementation difficulty.  Your File type is
independent of the filesystem.  That is, on Unix it corresponds to an
inode.  Creating a File must correspond to opening it (in Unix speak).
Creating a stream corresponds to duplicating the file descriptor (you
could probably avoid too many unnecessary dups by being clever).
There's a potential implementation difficulty, though:
lookupFileByPathname must open the file, without knowing whether the
file will be used for reading or writing in the future.  So I would
suggest that operations which create a value of type File take a
read/write flag too.

  type FilePos = Word64
  type BlockLength = Int

FilePos should be Integer.

  fCheckRead  :: File - FilePos - BlockLength - IO Bool
  fCheckWrite :: File - FilePos - BlockLength - IO Bool

What do these do?  If they're supposed to return True if the required
data can be read/written without blocking, then I suspect that they are
not useful.

 Fundamental operations on streams. Maybe Octet is supposed 
 to represent
 Octet or EOS, though I'm not sure this is enough for proper EOS
 handling.

I'd use the traditional 'isEOF' way of detecting end of file.

On naming: it's probably not a good idea to use the 'is' prefix, since
it is already used for predicates (meaning literally 'is' rather than an
abbreviation for 'InputStream').

  isGet  :: InputStream - IO (Maybe Octet)
  isPeek :: InputStream - IO (Maybe Octet)
  isGetBlock :: InputStream - BlockLength - XXX - IO BlockLength
  -- efficiency hack
 
  osPut  :: OutputStream - Octet - IO ()
  osPuts :: OutputStream - [Octet] - IO ()
  osPutBlock :: OutputStream - BlockLength - XXX - IO ()
  osFlush:: OutputStream - IO ()

You need operations to control buffering, too.  Something like
h{Set,Get}Buffering would be fine.

You will also want a way to get back from an InputStream to the
underlying object, eg. the (File,FilePos) pair if one exists.

It's not pretty, but you certainly want a way to close a stream.
Finalizers aren't reliable enough.

How did you intend text encodings to work?  I see several possibilities:

   textDecode :: TextEncoding - [Octet] - [Char]

or
  
   decodeInputStream :: TextEncoding - InputStream - TextInputStream
   getChar :: TextInputStream - IO Char
   etc.

or
  
   setInputStreamCoding :: InputStream - TextEncoding - IO ()
   getChar :: InputStream - IO Char

The first one is nice, but hard to optimise, and it will get complicated
for encodings which have state.  The second one is probably the best
compromise.

  data Directory  -- abstract

I don't see a reason for changing the existing Directory support
(System.Directory).  Could you give some motivation here?  Is the idea
to abstract away from the syntax of pathnames on the platform (eg.
directory separator characters)?  If so, I'm not sure it's worthwhile.
There are lots of differences between pathname conventions: case
sensitivity, arbitrary limits on the lengh of filenames, filename
extensions, and so on.

 Convenient shortcuts for common cases.
 
  lookupFileByPathname :: String - IO File

Here, I suggest we need

  lookupFileByPathname :: FilePath - IOMode - IO File

  lookupInputStreamByPathname :: String - IO InputStream
  -- at least as likely to succeed as lookupFileByPathname

and similarly

  createFileOutputStream :: FilePath - IO OutputStream
  appendFile :: FilePath - IO OutputStream

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

ANNOUNCE: Haddock version 0.5

[Simon Marlow]

Haddock version 0.5 is released.  Get it from here:

   http://www.haskell.org/haddock

Not a great deal has changed from version 0.4, but you need the new
version if you want to build it using recent versions of GHC.  Also,
several bugs have been fixed.  This is the version of Haddock that we
are using to generate docs for the hierarchical libraries that come with
GHC.

Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: exceptions

[Simon Marlow]

 
 just out of curiosity, which is the proper idiom?
 
 trace a  = r - catch a (\e - putStr exceptional\n  throw e)
 trace a  = r - catch a (\e - putStr exceptional\n  ioError e)
 
 I am worried that one might subtly change the semantics of an 
 execption
 depending on how it was originally thrown... but i am uncertain how.
 probably some obscure case involving bottoms. But to be on the safe
 side, thought I'd ask.

The second is more correct, if you're using Prelude.catch.  If you're
using Control.Exception.catch, then you want throwIO instead of ioError.

The difference between throw and ioError is this:

  seq (throw e)   E  ==  throw e
  seq (ioError e) E  ==  E

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

ANNOUNCE: GHC version 6.0.1

[Simon Marlow]

   =
The (Interactive) Glasgow Haskell Compiler -- version 6.0.1
   =

We are pleased to announce a new patchlevel release of the Glasgow
Haskell Compiler (GHC), version 6.0.1.

This is a bug-fix release relative to 6.0.  The most important bugfixes
are:

   * Fixes to make GHC work with GCC 3.3

   * Fix for the GHC deletes source files bug

   * :cd now unloads any loaded modules in GHCi.

   * -mk-dll should work better on Windows.

in addition to various other bugfixes.

The release notes lists the changes in the 6.0 line relative to 5.04:

 
http://www.haskell.org/ghc/docs/latest/html/users_guide/release-6-0.html


How to get it
~
The easy way is to go to the WWW page, which should be self-explanatory:

http://www.haskell.org/ghc/

We supply binary builds in the native package format for various
flavours of Linux and BSD, and in Windows Installer (MSI) form
for Windows folks.  Binary builds for other platforms are available
as a .tar.gz which can be installed wherever you want.  The source
distribution is also available from the same place.

Packages will appear as they are built - if the package for your
system isn't available yet, please try again later.

Background
~~
Haskell is a standard lazy functional programming language; the
current language version is Haskell 98, agreed in December 1998, and
revised in December 2002.

GHC is a state-of-the-art programming suite for Haskell.  Included is
an optimising compiler generating good code for a variety of
platforms, together with an interactive system for convenient, quick
development.  The distribution includes space and time profiling
facilities, a large collection of libraries, and support for various
language extensions, including concurrency, exceptions, and foreign
language interfaces (C, whatever).  GHC is distributed under a
BSD-style open source license.

A wide variety of Haskell related resources (tutorials, libraries,
specifications, documentation, compilers, interpreters, references,
contact information, links to research groups) are available from the
Haskell home page (see below).


On-line GHC-related resources
~~

Relevant URLs on the World-Wide Web:

GHC home page http://www.haskell.org/ghc/
Haskell home page http://www.haskell.org/
comp.lang.functional FAQ  http://www.cs.nott.ac.uk/~gmh/faq.html



System requirements
~~~
To compile programs with GHC, you need a machine with 64+MB memory, GCC
and perl. This release is known to work on the following platforms:

  * i386-unknown-{linux,*bsd,mingw32}
  * sparc-sun-solaris2
  * alpha-dec-osf3
  * powerpc-apple-darwin (Mac OS X)

Ports to the following platforms should be relatively easy (for a
wunderhacker), but haven't been tested due to lack of time/hardware:

  * hppa1.1-hp-hpux{9,10}
  * i386-unknown-solaris2
  * mips-sgi-irix{5,6}
  * {rs6000,powerpc}-ibm-aix

The builder's guide on the web site gives a complete run-down of what
ports work; it can be found at

 
http://www.haskell.org/ghc/docs/latest/html/building/building-guide.html


Mailing lists
~
We run mailing lists for GHC users and bug reports; to subscribe, use
the web interfaces at

http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

There are several other haskell and ghc-related mailing lists on
www.haskell.org; for the full list, see

http://www.haskell.org/mailman/listinfo/

Please report bugs using our SourceForge page at

http://sourceforge.net/projects/ghc/

or send them to [EMAIL PROTECTED]

GHC users hang out on [EMAIL PROTECTED]  Bleeding
edge CVS users party on [EMAIL PROTECTED]

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: literate scripts.

[Simon Marlow]

 
 Ghc should not accept this code, because, no matter how the 
 unliterating
 is achieved, it is illegal for a literal string to contain a 
 literal newline character.

Known bug in GHC.  In the testsuite, but unfortunately not documented.

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

ANNOUNCE: Alex version 2.0

[Simon Marlow]

I am pleased to announce version 2.0 of Alex, the lexical analyser
generator for Haskell.

Based on Chris Dornan's original version of Alex, this new version
contains some significant changes:

  - A revised syntax, more closely matching that of lex and Happy.

  - A rewritten back-end, producing smaller, faster, lexers.

  - A more flexible programmer interface, allowing simple
tokenisers to be produced with very little code, and allowing
monads to be threaded through the lexer.

Read the release notes for the full story:

  http://www.haskell.org/alex/doc/html/about.html#RELNOTES

This version has been tested on GHC: I have a development version of
GHC using an Alex lexer, which beats the orignal hand-optimised lexer.

Distributions can be obtained from Alex's new home:

  http://www.haskell.org/alex/

Alex is now distributed under a BSD-style license.

Share and enjoy,

Simon Marlow:  [EMAIL PROTECTED]
Chris Dornan:  [EMAIL PROTECTED]
Isaac Jones:   [EMAIL PROTECTED]
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: more unsafePerformIO questions (is it safe to use with ReadMode Handles)?

[Simon Marlow]

 
 I'm finishing up my Haskell interface to WordNet
 (http://www.cogsci.princeton.edu/~wn/) and have a standard
 unsafePerformIO question :).
 
 Basically, the interface functions by first calling an initialization
 function, 'initializeWordNet :: IO WordNetEnv'.  WordNetEnv is
 essentially just a record of a lot of Handles which we will be reading
 from and doing binary search in.
 
 All the functions which use the WordNetEnv (i.e., every other function
 in the interface) basically do the following:
 
   - take one handle from the WordNetEnv and do binary search 
 in it, read a line.
 
   - use that line to read another line from another of the handles
 
   - parse that last one
 
 of course, therefore, all of these functions have type '... - IO
 something'.
 
 However, one of the rules of thumb for using unsafePerformIO is when
 you can imagine a functional interface doing the same thing.  I can:
 simply read in all the databases in initializeWordNet and then do
 Data.List.lookup on the results.  Does this mean it's safe to wrap all
 these functions in unsafePerformIO?

It sounds like your interface is pure, as long as you don't expect the
contents of any of the databases to change during the run of your
program.  That is, it doesn't matter whether you do all the IO at the
start or lazilly on demand.

If the databases *do* change over time, then there are two
possibilities:

  1. the contents change due to external factors only
  2. the contents change because this program doing the writing

in (1), you can still pretend the interface is pure, by imagining that
all the changes happened earlier.  This works as long as you only read
the external data once.  In (2), you have a truly impure interface, so
using unsafePerformIO would be wrong.

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: more unsafePerformIO questions (is it safe to use with ReadMode Handles)?

[Simon Marlow]

 
 If the databases *do* change over time, then there are two
 possibilities:
 
   1. the contents change due to external factors only
   2. the contents change because this program doing the writing
 
 in (1), you can still pretend the interface is pure, by 
 imagining that
 all the changes happened earlier.  This works as long as you 
 only read
 the external data once.
 
 Isn't there the possibility of inlining causing a read to 
 happen twice even if it only appears to happen once?

In theory that would be a valid transformation, but in practice no
compiler would duplicate arbitrary computations.  GHC certainly doesn't.

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: more unsafePerformIO questions (is it safe to use with ReadMode Handles)?

[Simon Marlow]

 
  Isn't there the possibility of inlining causing a read to 
  happen twice even if it only appears to happen once?
 
 In theory that would be a valid transformation, but in practice no
 compiler would duplicate arbitrary computations.  GHC 
 certainly doesn't.
 
 I was thinking of a situation like 
 
 let x = unsafePerformIO readFooFromDB in x+x
 
 I see from your Secrets of the GHC inliner paper that x wouldn't be
 inlined by GHC, but it seems to me like a serious abuse of 
 the principle of
 referential transparency to write programs that _assume_ that.

Yes, I agree that one shouldn't rely on the no duplication of work
property.  However, folloing this argument we arrive at the conclusion
that hGetContents is an invalid use of unsafePerformIO.  (which is
something I've been saying for a while now :-).

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: more unsafePerformIO questions ([...])

[Simon Marlow]

 
 On Tuesday, 2003-08-19, 13:18, Simon Marlow wrote:
  [...]
 
  Yes, I agree that one shouldn't rely on the no duplication of work
  property.  However, folloing this argument we arrive at the 
 conclusion that
  hGetContents is an invalid use of unsafePerformIO.  (which 
 is something I've
  been saying for a while now :-).
 
 Can't hGetContents be implemented without unsafePerformIO but with 
 unsafeInterleaveIO? Wouldn't this be valid? Am I'm missing 
 something here?

unsafeInterleaveIO = return . unsafePerformIO

Well, almost.  unsafeInterleaveIO should also give you the guarantee
that the IO in its argument can't be performed *before* the
unsafeInterleaveIO is executed, but I don't think this distinction is
important to the present discussion.

Actually I dislike unsafeInterleaveIO even more than unsafePerformIO,
because it has an implicit laziness assumption.  The only purpose of
unsafeInterleaveIO is to delay some IO until it is demanded.  But
Haskell lacks a precise definition of demand, prefering to leave the
evaluation order up to the implementation.  Hence, unsafeInterleaveIO is
left in limbo - it might do something useful, but that depends entirely
on your implementation.  GHC doesn't guarantee much about
unsafeInterleaveIO at all.

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Exhaustive Pattern-Matching

[Simon Marlow]

 
 I have a question about pattern-matching. In the Haskell-report it is 
 not postulated, that
 pattern matching has to be exhaustive. Would it be possible at all to 
 implement an
 algorithm, which checks Haskell-style patterns for 
 exhaustiveness? What 
 kinds of
 complication can be expected? Maybe you have some pointers to other 
 resources about
 this topic.

GHC tries to do so, but sometimes gets it wrong.  See the
-fwarn-incomplete-patterns flag.  We'd appreciate it if someone could
overhaul this code - it's been on the wish list for a long time.

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Haskell-report, chapter 3 - Expressions

[Simon Marlow]

 
 I do not completely understand the first part of chapter 3 of the 
 Haskell-report.
 Concretely I am stumbling about the notation of nonterminals 
 indexed by 
 their precedence
 level. This should be a number ranging from 0 to 9. But what 
 about this exp^{10} production rule?

The grammar is written using a kind of macro syntax, such that you can
obtain the full grammar by expanding each of the rules for nonterminals
with a superscript 'i' for each 'i' in the range 0 to 9.  These rules
then cover the grammar for expressions containing infix operators with
precedences between 0 and 9.

The '10' in the 'exp10' nonterminal doesn't refer to the precedence of
an operator, it is there purely as a clue to to the reader that these
expressions bind tighter than all the infix operators.  Hope this helps.

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Haskell for non-Haskell's sake

[Simon Marlow]

 
 I implemented a trivial database, stored in ordinary files, 
 and had to
 ensure mutual exclusion of database access between 
 simultaneously running
 CGI scripts. Since each CGI run is short, I simply locked the entire
 database for the entire run. Claiming a lock on a file is 
 easy in C (well,
 it takes 18 lines...), but there's nothing in the standard Haskell
 libraries that can do it. So I borrowed a little C code from 
 the net, and
 called it via the FFI.

Locking support is available in the unix package distributed with GHC.
See:

http://www.haskell.org/ghc/docs/latest/html/unix/System.Posix.IO.html#7


Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Syntax extensions (was: RE: The Future of Haskell discussion at the Haskell Workshop)

[Simon Marlow]

Mark Jones writes: 
 As a solution to that problem, the many-command-line-options
 scheme described seems quite poor!  It's far too tool specific,
 not particularly scalable, and somewhat troublesome from a software
 engineering perspective.  We're not talking about a choice between
 two points any more; there's a whole lattice of options, which, by
 the proposal above might be controlled through a slew of tool-specific
 and either cryptic or verbose command line switches.  Will you
 remember which switches you need to give to compile your code for
 the first time in two months?  How easy will it be to translate
 those settings if you want to run your code through a different
 compiler?  How much help will the compiler give you in tracking
 down a problem if you forget to include all the necessary switches?
 And how will you figure out what options you need to use when you
 try to combine code from library X with code from library Y, each
 of which uses its own interesting slice through the feature set?
 
 I know that some of these problems can be addressed, at least in
 part, by careful use of Makefiles, {-# custom pragmas #-}, and perhaps
 by committing to a single tool solution.  But I'd like to propose
 a new approach that eliminates some of the command line complexities
 by integrating the selection of language extensions more tightly
 with the rest of the language.

Initially I liked the idea, but now I'm not so sure (more about that
later). But first I'll point out that the situation isn't nearly as bad
as you make out.  In GHC, the approved way to add these flags is by
using a pragma to the source code, for example:

  {-# OPTIONS -fth -fffi #-}
  module Foo where
  ...

this in itself addresses most of your complaints.  Using a
compiler-independent syntax would address another one.  We're left with:

 How much help will the compiler give you in tracking
 down a problem if you forget to include all the necessary
 switches?

We don't make any attempt to address this, but there are various ways we
could be more helpful: eg. finding a stray 'forall' in a type when
rank-N is not turned on is a clear indication.  Nevertheless, this seems
orthogonal to the issue of how to specify the language flavour in the
first place.

 And how will you figure out what options you need to use when you
 try to combine code from library X with code from library Y, each
 of which uses its own interesting slice through the feature set?

Interesting point.  Our take on this is that the extension-flags specify
the language variant in which the source code *in this module* is
written.  For example, if I define a multi-parameter type class C in
module A, then it is completely legal to import A into any other module
regardless of the settings of the flags, but I will only be able to
write an instance of C if multi-parameter type classes are enabled.

This is a consistent position which has the benefit of being easy to
understand.

 The main idea is to use the module system to capture information
 about which language features are needed in a particular program.
 For example, if you have a module that needs implicit parameters
 Template Haskell, and TREX, then you'll indicate this by including
 something like the following imports at the top of your code:
 
   import Extensions.Types.ImplicitParams
   import Extensions.Language.TemplateHaskell
   import Extensions.Records.TREX

How do I enable hierarchical modules using this scheme? ;-)

Can any of these extensions affect the syntax of the export list?  If
so, how do I parse the module?  (perhaps I have to use a most-general
syntax for the export list, parse up to and including the imports, then
re-parse the export list).

[snip]
 Of course, code that does:
 
   import Extensions.Types.Multiparam
 
 is not standard Haskell 98 because there's no such library in the
 standard.  This is a good thing; our code is clearly annotated as
 relying on a particular extension, without relying on the command
 line syntax for a particular tool.  Moreover, if the implementers
 of different tools can agree on the names they use, then code that
 imports Extensions.Types.Multiparam will work on any compiler that
 supports multiple parameter classes, even if the underlying
 mechanisms for enabling/disabling those features are different.
 When somebody tries to compile that same piece of code using a
 tool that doesn't support the feature, they'll get an error
 message about a missing import with a (hopefully) suggestive
 name/description, instead of a cryptic Syntax error in constraint
 or similar.

This complaint is also addressed by using a compiler-independent pragma,
except the error message would be unsupported extension.

 Also, when you come back to compile your code after some
 time away, you won't need to remember which command line options you
 need because it's all there, built in to the source in a readable and
 perhaps even portable notation. You just invoke the compiler (without
 

RE: lexer puzzle

[Simon Marlow]

Iavor Diatchki writes:
 
 what do people think should be the tokens produced by a haskell lexer
 when applied to the following input:
 
A...

This has been discussed before (a while back, admittedly). See:

  http://www.mail-archive.com/[EMAIL PROTECTED]/msg04054.html

GHC (still) gets this wrong.  It's a documented bug though.

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: lexer puzzle

[Simon Marlow]

 
 I agree with Marcin,
 
 A... should be split into A.. and .
 
 As I read the (on-line) report the maximal munch rule says that you 
 should read the longest lexeme. It does not say that two 
 operators have 
 to be separated by whitespace.
 
 Because A... is not a lexeme, the longest lexeme you can read from 
 A... is A.. (qualified dot-operator).

Wow!  I hadn't noticed that before.  This means that for example,

   'M.where '

must be interpreted as the two tokens

   'M.wher' 'e'

This is bound to keep the Obfuscated Haskell programmers happy :-)

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Syntax extensions (was: RE: The Future of Haskell discussionat the Haskell Workshop)

[Simon Marlow]

 
{-# LANGUAGE specification #-}
 
 where specification is one or more (if compatible) of keywords like
 
 Haskell98 Pure Haskell 98, no extensions.
 SharedExtenisons (Haskell02???)   A set of agreed-upon extensions
   implemented by all major
   Haskell systems.
 RecursiveDo
 ArrowSyntax
 TemplateHaskell
 OverlappingInstances
 UndecidableInstances
 FFI   Foreign Function
Interface
 MPTC  Multi-parameter Type Classes

Looks fine to me.  A few things to think about:

  - Some of the keywords specify an entire language (eg. Haskell98),
whereas some are language modifiers (eg. FFI).  We might want
to make a distinction.  Currently GHC supports only Haskell98 +
modifiers.

  - Are extensions always additive?  Are there any extensions
which are incompatible?

  - There are features you might want to *disable*.  eg.
GHC lets you turn off the monomorphism restriction.

Perhaps something like this:

  {-# LANGUAGE Haskell98 +FFI -MonomorphismRestriction #-}


 (abbreviations used when three or more words).
 
 The OPTION pragma would be used for compiler-specific 
 options, although,
 in the interest of supporting portable code without having to 
 resort to
 preprocessing using CPP, maybe it would make sense to provide
 
OPTIONS-GHC
OPTIONS-Hugs
OPTIONS-NHC
...
 
 as well, the idea being that a compiler/interpreter then only 
 would look at options pertinent to itself.

Yes, I've been meaning to rename GHC's version of the pragma to
GHC_OPTIONS for some time.

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: echoing of getChar, getLine, getContents

[Simon Marlow]

 
 The report states about getChar, getLine, and getContents:
 
 By default, these input functions echo to standard output.
 
 In version 1.3 of the report, it used to continue
 Functions in the I/O library provide full control over echoing. 
 
 Apparently, this has been removed and the I/O library contains
 neither facilities to control echoing nor a specification of what the
 h-cousins hGetChar, hGetLine, and hGetContents are supposed to do wrt
 echoing. Can I rely on them not to echo their inputs?

Clearly the report is vague here, so I'll just comment on what GHC does.
By default, input from a terminal will echo.  The following functions
are provided by System.IO (GHC only, not Hugs or NHC), and control
terminal echoing:

  hSetEcho :: Handle - Bool - IO ()
  hGetEcho :: Handle - IO Bool

Input from a non-terminal will not echo.  GHC's IO library never does
any actual echoing itself, it simply gives hints to the OS's terminal
API to turn echoing on or off.

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Library Infrastructure Proposal Home Page

[Simon Marlow]

I think the proposal is great.  Here's some random comments:

It might be worth saying earlier on that the library infrastructure is
expected to be a layer underneath the platform's native package support
(if such support exists).  For example, I've never used Python's
Distutils, but I have a bunch of Python packages on my system that were
installed using the native package system on top of Distutils (I
presume).

FreeBSD's ports is both a source and binary package system.  A FreeBSD
system functions perfectly well using only binary packages.  To a
certain extent Gentoo is the same, although they place far less emphasis
on binary packages.

FreeBSD (in source or binary mode), and Gentoo, have no support for
recompiling packages when something they depend on has changed.  This is
the biggest failing of these systems IMHO.  The 3rd paragraph of 2.1
therefore isn't correct - there's still a big problem for source-based
distributions. However, this is not *our* problem, it's theirs - when a
dependency is updated, everything that depends on it should be
recompiled.

./Setup.lhs bdist:  wouldn't it be better to create a source RPM than a
binary RPM?  Once you have a source RPM the RPM tools can be used to
build a binary RPM.  Similarly for FreeBSD and Gentoo - I'd expect
Setup.lhs to produce a port skeleton/ebuild for me, not a binary
package.

The PackageConfig file:  I'd leave out 'provides' and 'isDefault' unless
we have a convincing example which needs them.  Possibly add:
'haddock_html_root :: String' and 'haddock_interface :: String' for
documentation.  I'm thinking about removing 'extra_ghc_opts' - it's
highly dodgy when combined with 'auto'.

I agree with Ross's comments about data vs. code.  Let's abstract as
much as possible as data.

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: interact behaves oddly if used interactively

[Simon Marlow]

Malcolm Wallace writes:
 But the whole purpose of 'interact' is to use its argument as the
 demanding function which drives lazy consumption of the input.  It is
 *designed* to reveal the evaluation behaviour, by hoisting it into
 the I/O monad.

This is why interact is bad, IMO: it forces you to think about the
evaluation order.  The evaluation order for Haskell is not part of the
language definition - it is normally up to the implementation to pick a
strategy.

Except when you get to lazy I/O.  The commonly accepted meaning for the
lazy I/O operations forces the implementation to adopt a lazy evaluation
strategy for values which require lazy I/O.  For example, eager
evaluation would be a completely valid implementation strategy for
Haskell if it were not for lazy I/O.

This has been swept under the carpet for far too long!

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: interact behaves oddly if used interactively

[Simon Marlow]

 
 Pardon? Haskell is a non-strict language. Using 'interact' is one of
 numerous situations where one takes advantage of non-strict semantics.
 (Keith just gave a different example.)

 Non-strict semantics does not prescribe the evaluation order, although
 usually lazy evaluation is used. I suppose you are talking about
 optimistic evaluation, which is a mixture of eager and lazy 
 evaluation.

Yes sorry, I meant optimistic evaluation.

 That is fine and should work well with 'interact', otherwise there is
 something wrong with optimistic evaluation.

No, optimistic evaluation does not work well with interact, because it
causes the input stream to be evaluated (and therefore demanded) earlier
than you would expect.  This is the problem: interact exposes more than
just non-strictness, it exposes laziness.

In Robert Ennals' implementation of optimistic evaluation he has to fall
back to lazy evaluation for lazy I/O, precisely because of this problem.

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: IO behaves oddly if used nested

[Simon Marlow]

Alastair Reid writes:
 ... Thus, we have Show instances for - and IO ...

Actually, you have to explicitly import Text.Show.Functions to get the
Show instance for (-).

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: About Haskell Thread Model

[Simon Marlow]

 
 On Mon, Oct 13, 2003 at 11:13:56AM +0200, Wolfgang Thaller wrote:
  The reason why we currently do not take advantage of SMP is 
 that the 
  Haskell Heap is a shared data structure which is modified 
 whenever a 
  thunk (an unevaluated expression) is evaluated. Using 
 synchronisation 
  primitives like pthread_mutex_lock for every evaluation of a thunk 
  would be deadly for performance.
  There is some old (1999) code in the GHC RTS that attempts 
 this (using 
  intel cmpxchg instructions for synchronisation), but it's currently 
  bitrotted and I don't know how successful it was.
 
 cmpxchg and then taking a blocking lock sounds like the 2-tier locking
 supported with Linux' new futex system calls. I wonder how they chose
 to block in the older GHC RTS.

It was a spinlock.  There was also an attempt to avoid having to lock
every thunk entry and update by partitioning the allocation area
per-thread, taking advantage of the fact that most thunk entries and
updates are to objects created recently by the current thread.  This is
about where the experiment stalled - it was interesting, but even if the
heap partitioning turned out to be effective, the gains weren't really
going to be there without tackling multithreaded GC too (as Jan-Willem
already pointed out).

Cheers,
Simon

___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell