From mechvel@math.botik.ru Wed May 2 08:29:38 2001
Date: Wed, 02 May 2001 11:29:38 +0400
From: S.D.Mechveliani mechvel@math.botik.ru
Subject: ghci, -O
I fear there is certain misunderstanding about -O usage with
ghc-5.00 interactive.
Simon Marlow and User's Guide (Section 4.4) say that
> -O does not work with ghci.
> For technical reason, the bytecode compiler doesn't interact
> well with one of the optimization passes
> [..]
What is a bytecode compiler?
The one that prepares a lightly compiled code for the interpreter?
What I meant is something like this:
to compile ghc -c -O Foo.hs
in the batch mode and then run ghci
...
Preude> :load Foo
...
Foo> sm [1..9999000]
I tried this with certain small function Foo.sm, and it works,
and runs better than when compied with -Onot.
Now, as I see that ghci can load and run the code made by -O,
I wonder what the User's Guide means by saying
"-O does not work with GHCi". Maybe ghci -O ?
could be meaningful?
-----------------
Serge Mechveliani
mechvel@botik.ru
From joe@isun.informatik.uni-leipzig.de Wed May 2 10:28:00 2001
Date: Wed, 2 May 2001 11:28:00 +0200 (MET DST)
From: Johannes Waldmann joe@isun.informatik.uni-leipzig.de
Subject: catchAllIO
Dear all, I keep getting problems with expections. In the example
catchAllIO ( action ) $ \ any -> return "foo"
is it guaranteed that *no* exception that is raised in `action'
propagates to the outside?
(This is with ghc-4.08. Should I upgrade? Well, I will upgrade
sometime anyway, but would it help with respect to this problem?)
Regards,
--
-- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ --
-- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --
From joe@isun.informatik.uni-leipzig.de Wed May 2 13:21:05 2001
Date: Wed, 2 May 2001 14:21:05 +0200 (MET DST)
From: Johannes Waldmann joe@isun.informatik.uni-leipzig.de
Subject: Exceptions and sockets
OK now I upgraded to ghc-5.00 but the situation didn't change.
My suspicion is that it's not the fault of `catch'.
I think what happens is this:
I `Socket.accept' a connection and get a handle.
Now, if the connections dies, but I still write to the handle,
the whole thing crashes - without throwing an exception.
(I checked that the RTS thinks `hIsWritable h'
even if `h' does no longer exist in reality.)
How could I work around this? SocketPrim?
--
-- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ --
-- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --
From stolz@I2.Informatik.RWTH-Aachen.DE Wed May 2 14:40:37 2001
Date: Wed, 2 May 2001 15:40:37 +0200
From: Volker Stolz stolz@I2.Informatik.RWTH-Aachen.DE
Subject: Exceptions and sockets
In local.glasgow-haskell-users, you wrote:
>I `Socket.accept' a connection and get a handle.
>Now, if the connections dies, but I still write to the handle,
>the whole thing crashes - without throwing an exception.
>(I checked that the RTS thinks `hIsWritable h'
>even if `h' does no longer exist in reality.)
Looks to me like you're forgetting that the OS will give you a
sigPIPE on (semi-)closed sockets, which translates to a segfault
unless you install a signal handler:
- http://www.haskell.org/ghc/docs/latest/set/socket.html#AEN13989
- socket(2)
--
Abstrakte Syntaxträume.
Volker Stolz * stolz@i2.informatik.rwth-aachen.de * PGP + S/MIME
From simonmar@microsoft.com Wed May 2 16:21:01 2001
Date: Wed, 2 May 2001 16:21:01 +0100
From: Simon Marlow simonmar@microsoft.com
Subject: ghci, -O
> Now, as I see that ghci can load and run the code made by -O,
> I wonder what the User's Guide means by saying=20
> "-O does not work with GHCi". Maybe ghci -O ?
> could be meaningful?
"ghci -O" is exactly the combination that doesn't work.
Cheers,
Simon
From simonmar@microsoft.com Wed May 2 17:28:50 2001
Date: Wed, 2 May 2001 17:28:50 +0100
From: Simon Marlow simonmar@microsoft.com
Subject: catchAllIO
> Dear all, I keep getting problems with expections. In the example
>=20
> catchAllIO ( action ) $ \ any -> return "foo"
>=20
> is it guaranteed that *no* exception that is raised in `action'=20
> propagates to the outside?
Yes.
> (This is with ghc-4.08. Should I upgrade? Well, I will upgrade
> sometime anyway, but would it help with respect to this problem?)
In GHC 5.00, 'catchAllIO' is now called 'Exception.catch', and the
IOError and Exception types are now isomorphic. Various other functions
in the Exception library have had names changes too.
Cheers,
Simon
From pasch@netzGeneration.com Wed May 2 23:02:01 2001
Date: Thu, 03 May 2001 00:02:01 +0200
From: Thomas Pasch pasch@netzGeneration.com
Subject: GHC and the Lazy Functional State Threads Paper
> So you can fix it for example by using a specialized version of
> freezeArr inside accumArray, of type
> (Ix i, IArray a e) => STArray s i e -> ST s (a i e)
> This will give quite general type of accumArray: arbitrary immutable
> array from the IArray class.
freezeArr2:: (Ix i, IArray.IArray a e) => STArray s i e -> ST s (a i e)
freezeArr2 = MArray.freeze
> If the immutable array type used was particularly UArray, it would
> be more efficient to use the corresponding STUArray instead of
> STArray, so freezing could just copy a memory block (there are magic
> specializations in ghc's libraries for such case). But if the element
> type was to remain generic, the type would have to be constrained
> over STUArray
freezeArr3::
(Ix i, MArray.MArray (MArray.STUArray s) e (ST s), IArray.IArray a e)
=> (MArray.STUArray s i e) -> ST s (a i e)
freezeArr3 = MArray.freeze
Is this the way to do it? I wonder a bit if this triggers the
optimization if 'a' is of type STUArray. (By the way I still have
problems to see where unboxed values are a good thing and were
you should better avoid them.)
In addition I wonder why there are so many array types. Are both
STArray and IOArray really necessary and what's the difference
between them? What about DiffArray? I'm still surprised by operations
like 'unsafeFreezeArray' and 'freezeArray'. Shouldn't the
garbage collector juge if there are still other references
to a distinct object?
Regards,
Thomas
From pasch@netzGeneration.com Wed May 2 23:07:26 2001
Date: Thu, 03 May 2001 00:07:26 +0200
From: Thomas Pasch pasch@netzGeneration.com
Subject: Linking vs. shared libs on Unix
Hello,
In the windows version of ghc,
there seems to be the possiblity to compile
the libraries as shared 'dll's. Is the
same possible for the unix version?
The question is because I think the ghc
executables are really blown up. A simple
'Hello, world' has 172 kBytes (358k unstripped)
and the hello example of the GTK+ bindings
is as big as 854 kBytes (2.2 MBytes unstripped),
although it is link dynamically against:
> ldd hello
libgthread-1.2.so.0 => /usr/lib/libgthread-1.2.so.0 (0x40025000)
libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x40028000)
libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x40155000)
libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x4018a000)
libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x4018d000)
libdl.so.2 => /lib/libdl.so.2 (0x401b1000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x401b4000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x401bc000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x401cb000)
libm.so.6 => /lib/libm.so.6 (0x402ae000)
libgmp.so.3 => /usr/lib/libgmp.so.3 (0x402cc000)
libc.so.6 => /lib/libc.so.6 (0x402ed000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40400000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Best regards,
Thomas
From qrczak@knm.org.pl Thu May 3 11:55:26 2001
Date: 3 May 2001 10:55:26 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: GHC and the Lazy Functional State Threads Paper
Thu, 03 May 2001 00:02:01 +0200, Thomas Pasch <pasch@netzGeneration.com> pisze:
>> If the immutable array type used was particularly UArray, it would
>> be more efficient to use the corresponding STUArray instead of
> freezeArr3::
> (Ix i, MArray.MArray (MArray.STUArray s) e (ST s), IArray.IArray a e)
> => (MArray.STUArray s i e) -> ST s (a i e)
> freezeArr3 = MArray.freeze
>
> Is this the way to do it?
Well, yes, although when the immutable array happens to *not* be
UArray (but e.g. Array), it can be less efficient than with STArray,
because elements must be reboxed. And it's less general (the element
type must be "unboxable").
This is why I would use STUArray when it is known that the immutable
array is UArray and nothing else, and STArray in other cases.
> I wonder a bit if this triggers the optimization if 'a' is of
> type STUArray.
UArray. It does when it's statically determined that 'a' is of type
UArray. It doesn't when a function using freeze is so large that
it's not compiled inline and it's not specialized, so the compiler
uses a single generic version in a code compiled out of line. This
optimization is implented as rewrite rule:
freeze:: (Ix i, MArray a e m, IArray b e) => a i e -> m (b i e)
-- Generically implemented in terms of overloaded element access
-- and array construction.
freezeSTUArray:: Ix i => STUArray s i e -> ST s (UArray i e)
-- Uses memcpy.
{-# RULES
"freeze/STUArray" freeze = freezeSTUArray
-- The compiler can replace freeze with freezeSTUArray where types
-- match (if optimization is turned on).
#-}
There is no automatic way of choosing the "best" mutable array type
"corresponding" to the given immutable type. Formally there is no
correspondence here (except that there are some rules for freezing
and thawing for specific combinations of types).
Efficiency of bulk array operations improved since released ghc-5.00:
I eliminated many unnecessary bounds checking, at the cost of turning
IArray and MArray methods into functions (so custom instances of
these classes no longer work - they must define different methods).
> (By the way I still have problems to see where unboxed values are
> a good thing and were you should better avoid them.)
If there could be a universal answer, probably the compiler could do
this automatically all the times :-)
Operations like arithmetic on boxed values are implemented as unboxing,
performing the operation and reboxing. So unboxed values are generally
faster than unboxed values - except that when we perform no operations
at all and just copy values from one place to another (like in freezing
a mutable array), it's cheaper to pass boxed values unmodified than
to unbox or box them.
The compiler is able to optimize away boxing in many cases, e.g.
usually in passing values as arguments to strict functions and
returning results. But it is not able to automatically optimize it
when values are stored in data structures (unless the data structure
itself is optimized away! this sometimes happend to lists), and it's
not able to unbox values of unknown types (so it helps to inline or
specialize critical functions - this sometimes happens automatically).
In any case you can watch what is happening instead of guessing.
There are options which tell ghc to dump intermediate forms of the
program, in not so pretty format (because it's internal: the textual
presentation is defined only for the purpose of dumping). I learned
what ghc is doing from watching the dumps much more than from reading
its source. Some interesting dumps:
ghc -c -no-recomp -O File.hs -ddump-stg
-ddump-realC
-fasm -ddump-asm
> In addition I wonder why there are so many array types. Are both
> STArray and IOArray really necessary and what's the difference
> between them?
Operations on STArray can be safely wrapped in a pure computation
using runST.
Operations on IOArray can be easily mixed with other IO operations.
Embedding them in a pure computation is still possible using
unsafePerformIO, but it's unsafe and slightly less efficient.
You can convert between ST and IO computations using stToIO and
unsafeIOtoST.
> What about DiffArray?
It has immutable interface but computes '//' without copying the
whole array as long as it's used in a single-threaded way. OTOH it has
larger constant overheads than Array (because of more magic inside,
more indirections).
> I'm still surprised by operations like 'unsafeFreezeArray' and
> 'freezeArray'. Shouldn't the garbage collector juge if there are
> still other references to a distinct object?
I don't know how easy it would be, and I guess that in case the
programmer knows that unsafeFreeze can be safely used it's faster than
asking the garbage collection. Unsafe freezing is used everywhere
in implementation of immutable arrays, so it's worth eliminating
unnecessary overheads.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From rrt@dcs.gla.ac.uk Thu May 3 16:22:00 2001
Date: Thu, 3 May 2001 16:22:00 +0100 (BST)
From: Reuben Thomas rrt@dcs.gla.ac.uk
Subject: Windows InstallShield updated
I've just uploaded a better Windows InstallShield for GHC that fixes a
problem with the last one, but more importantly, hides the Cygwin binaries
it installs in ghc-4.08.2/extra-bin, so that they do not interfere with, and
are not intefered with by, any installation of Cygwin you may have on your
system.
Incidentally, I have also fixed a small problem in the Happy InstallShield,
so if you couldn't get it to work, try downloading again.
--
http://sc3d.org/rrt/
"Reality is what refuses to disappear when you stop believing in it" -
Philip K. Dick
From simonpj@microsoft.com Fri May 4 09:19:37 2001
Date: Fri, 4 May 2001 01:19:37 -0700
From: Simon Peyton-Jones simonpj@microsoft.com
Subject: Building nhc98-1.02 with ghc-5.00
I've committed a fix.
Simon
| -----Original Message-----
| From: Simon Marlow=20
| Sent: 27 April 2001 10:19
| To: Wolfhard Bu=DF; nhc-users@cs.york.ac.uk
| Cc: glasgow-haskell-users@haskell.org
| Subject: RE: Building nhc98-1.02 with ghc-5.00
|=20
|=20
| > the building of nhc98-1.02 with ghc-5.00 aborts
| > with the message:
| >=20
| > Main.hs:8:
| > Failed to find interface decl for
| > `PrelGHC.(#,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
| > ,,,,,,,,,,,,,,,,,,,,,,,#)'
| > from module `PrelGHC'
| >=20
| > Any hints for interpretation?
|=20
| Workaround: compile this particular module without -O, or=20
| with -fno-cpr.
|=20
| Cheers,
| Simon
|=20
| _______________________________________________
| Glasgow-haskell-users mailing list=20
| Glasgow-haskell-users@haskell.org=20
| http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users
|=20
From theo@engr.mun.ca Sun May 6 23:56:42 2001
Date: Sun, 06 May 2001 20:26:42 -0230
From: Theodore Norvell theo@engr.mun.ca
Subject: Profiling on Windows.
Hi. I'm using ghc version 4.08.2 on windows NT. I tried compiling my program
with -prof -auto-all. It runs up until input is required (from stdin) and
then crashes claiming "The instruction at 0x0 referenced memory at 0x0. The
memory could not be read". Is there a known problem with profiling on NT
systems?
Cheers,
Theodore Norvell
----------------------------
Dr. Theodore Norvell theo@engr.mun.ca
Electrical and Computer Engineering http://www.engr.mun.ca/~theo
Engineering and Applied Science Phone: (709) 737-8962
Memorial University of Newfoundland Fax: (709) 737-4042
St. John's, NF, Canada, A1B 3X5
From chak@cse.unsw.edu.au Thu May 10 03:05:35 2001
Date: Thu, 10 May 2001 12:05:35 +1000
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: ANNOUNCE: Happy 1.10 released
"Simon Marlow" <simonmar@microsoft.com> wrote,
> ANNOUNCING Happy 1.10 - The LALR(1) Parser Generator for Haskell
> -----------------------------------------------------------------
It seems that the build system does not create a link from
`happy-<version>' to `happy'. Is this intentional?
Cheers,
Manuel
From simonmar@microsoft.com Thu May 10 09:30:56 2001
Date: Thu, 10 May 2001 09:30:56 +0100
From: Simon Marlow simonmar@microsoft.com
Subject: ANNOUNCE: Happy 1.10 released
> "Simon Marlow" <simonmar@microsoft.com> wrote,
>=20
> > ANNOUNCING Happy 1.10 - The LALR(1) Parser Generator for Haskell
> > -----------------------------------------------------------------
>=20
> It seems that the build system does not create a link from
> `happy-<version>' to `happy'. Is this intentional?
No, it's a bug. I just noticed this weekend when I made the FreeBSD
package. It's fixed in the repository now.
Cheers,
Simon
From chak@cse.unsw.edu.au Thu May 10 10:26:59 2001
Date: Thu, 10 May 2001 19:26:59 +1000
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: ANNOUNCE: Happy 1.10 released
"Simon Marlow" <simonmar@microsoft.com> wrote,
> ANNOUNCING Happy 1.10 - The LALR(1) Parser Generator for Haskell
An RPM package for x86 RedHat Linux[1] is now available at
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/happy-1.10-2.i386.rpm
The matching source RPM is at
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/src/happy-1.10-2.src.rpm
Happy LALRing,
Manuel
[1] The binary has been build on RH7.0 with glibc2.2.
From alex@shop.com Thu May 10 15:24:51 2001
Date: Thu, 10 May 2001 10:24:51 -0400 (Eastern Daylight Time)
From: S. Alexander Jacobson alex@shop.com
Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
Combining two threads...
Like macros and preprocessors, Happy generates code.
I assume the justification for this is that hand-coding a parser in
Haskell is presumed to be too difficult or that it is too hard to get the
right level of abstraction (and therefore a macro-like facility is
required).
However, I've also used Hutton & Meijer style monadic parsers and
found them extremely elegant, clean, and easy to use in both Haskell and
Python (though in Python they were too slow for my xml application --
function call overhead is _very_ high in Python).
I am not a parsing expert, but given the recent discussion on macros, I
have to ask: why use happy rather than monadic parsing? Monadic parsing
allows you to avoid a whole additional language/compilation step and work
in Hugs (where you don't have a makefile). What does Happy buy you here?
<goingovermyhead>
And generalizing from the above, since Monads/Arrows are types that
describe a computation declaratively and Macros are functions that
describe a computation procedurally, is it possible that, for any
application of Macros, you can find a suitable Monad/Arrow? Or am I not
understanding either well enough?
</goingovermyhead>
-Alex-
___________________________________________________________________
S. Alexander Jacobson Shop.Com
1-646-638-2300 voice The Easiest Way To Shop (sm)
From simonmar@microsoft.com Thu May 10 15:42:00 2001
Date: Thu, 10 May 2001 15:42:00 +0100
From: Simon Marlow simonmar@microsoft.com
Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
S. Alexander Jacobson writes:
> I am not a parsing expert, but given the recent discussion on=20
> macros, I
> have to ask: why use happy rather than monadic parsing? =20
> Monadic parsing
> allows you to avoid a whole additional language/compilation=20
> step and work
> in Hugs (where you don't have a makefile). What does Happy=20
> buy you here?
It buys you (a) speed, (b) confidence that your grammar is
non-ambiguous, and (c) familiar BNF notation. On the down side, as you
point out, you lose Haskell's abstraction facilities.
I'd be willing to sacrifice (c) in order to write parsers in Haskell,
but I don't think there's a combinator library that matches Happy in
terms of speed (disclaimer: I haven't exhaustively tested them all, but
given the tricks Happy does I'd be surprised). AFAIK none of the
combinator libraries gives you (b).
Cheers,
Simon
From cwitty@newtonlabs.com Thu May 10 18:48:52 2001
Date: 10 May 2001 10:48:52 -0700
From: Carl R. Witty cwitty@newtonlabs.com
Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
"S. Alexander Jacobson" <alex@shop.com> writes:
> I am not a parsing expert, but given the recent discussion on macros, I
> have to ask: why use happy rather than monadic parsing? Monadic parsing
> allows you to avoid a whole additional language/compilation step and work
> in Hugs (where you don't have a makefile). What does Happy buy you here?
I've used Happy instead of parser combinators because I wanted the
additional global error-checking. I believe that the standard
implementations of parser combinators will allow you to specify an
ambiguous grammar, and return one of the multiple possible parses,
without warning.
Carl Witty
From john@foo.net Thu May 10 22:22:04 2001
Date: Thu, 10 May 2001 14:22:04 -0700
From: John Meacham john@foo.net
Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
Just out of curiosity, has anyone done any work at benchmarking the
various parsers? I use Parsec pretty exclusivly since it comes with ghc
and is pretty straightforward and lightweight to use. I am wondering
what I am giving up in terms of speed by going that route, rather than
Happy or the compiler toolkit non-monadic but pure-haskell parser? hmm...
John
On Thu, May 10, 2001 at 03:42:00PM +0100, Simon Marlow wrote:
>
> S. Alexander Jacobson writes:
>
> > I am not a parsing expert, but given the recent discussion on
> > macros, I
> > have to ask: why use happy rather than monadic parsing?
> > Monadic parsing
> > allows you to avoid a whole additional language/compilation
> > step and work
> > in Hugs (where you don't have a makefile). What does Happy
> > buy you here?
>
> It buys you (a) speed, (b) confidence that your grammar is
> non-ambiguous, and (c) familiar BNF notation. On the down side, as you
> point out, you lose Haskell's abstraction facilities.
>
> I'd be willing to sacrifice (c) in order to write parsers in Haskell,
> but I don't think there's a combinator library that matches Happy in
> terms of speed (disclaimer: I haven't exhaustively tested them all, but
> given the tricks Happy does I'd be surprised). AFAIK none of the
> combinator libraries gives you (b).
--
--------------------------------------------------------------
John Meacham http://www.ugcs.caltech.edu/~john/
California Institute of Technology, Alum. john@foo.net
--------------------------------------------------------------
From qrczak@knm.org.pl Thu May 10 22:24:36 2001
Date: 10 May 2001 21:24:36 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: MonadError and fundeps
MonadReader, MonadWriter and MonadState classes have fundeps from the
monad type to the environment / output / state type (I added them
a few months ago).
MonadError doesn't. I thought that it's desirable to make a class with
more than one exception type, such that for example each catchError
would catch the corresponding throwError only, or even with simulation
of some subtyping policy.
Now I'm not sure that it was the right choice. I have an example when
having this fundep would be very helpful:
I am experimenting with building monadic parsing combinators from monad
transformers. In particular I already have a Parsec-like parsing monad
composed from pieces. It would be bad to hardwire the error type.
But without a fundep in MonadError overloaded functions can't be
written with MonadError in the context and without mentioning the
error type in their type (which would be impractical).
My workaround is to have a separate class, similar to MonadError but
with a fundep, with MonadError in its superclass, and with its own
instances. Fortunately this class can be empty, taking implementation
of pushing the error handling through monad transformers from
MonadError. But it would be more straightforward to use MonadError
directly.
I make use of the fundep in MonadState too. So I think that usually
one wants these fundeps.
Other argument for having a fundep in MonadError: monad transformers
provided by modules in package lang don't provide a monad which
could handle multiple errors anyway, and it would be impossible to
do it generically without overlapping instances. An instance would
have to recognize "its" error type, so it must work on a hardwired
type constructor.
If there was a fundep, the behavior of different error types can be
simulated by providing functions defined in terms of throwError and
catchError which throw a specific type or catch only a specific type
(this works only in the case where handling of all errors is done at
the same level of monad transformers, but I doubt that anyone would
make a monad without this property and still wanted to use generic
throwing and catching functions). This can be even done generically in
terms of classes which coerce a specific error type up or recognize
it, without touching all monads, as I am doing in the workaround in
the opposite direction.
What do you think? If nobody answers, I think I will add the fundep...
BTW, another question: should MonadPlus instead of just Monad be
a superclass of MonadError? It has a natural definition in terms
of catchError.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From andrew@bromage.org Fri May 11 05:40:27 2001
Date: Fri, 11 May 2001 14:40:27 +1000
From: Andrew J Bromage andrew@bromage.org
Subject: MonadError and fundeps
G'day all.
On Thu, May 10, 2001 at 09:24:36PM +0000, Marcin 'Qrczak' Kowalczyk wrote:
> BTW, another question: should MonadPlus instead of just Monad be
> a superclass of MonadError? It has a natural definition in terms
> of catchError.
I can see how mplus has a "natural" definition (I can think of one or
two circumstances where it's not semantically "natural", even if it is
operationally "natural", but that's beside the point).
What about mzero, though? What "natural definition" did you have
in mind?
Cheers,
Andrew Bromage
From qrczak@knm.org.pl Fri May 11 07:54:09 2001
Date: 11 May 2001 06:54:09 GMT
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: MonadError and fundeps
Fri, 11 May 2001 14:40:27 +1000, Andrew J Bromage <andrew@bromage.org> pisze:
> What about mzero, though? What "natural definition" did you have
> in mind?
You are right, mzero is not as automatic as mplus. It surely means
'throwError something', but the value of something must be
determined separately.
'fail' belongs here too: I think it's always 'throwError something'
in practice.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From chak@cse.unsw.edu.au Fri May 11 08:09:44 2001
Date: Fri, 11 May 2001 17:09:44 +1000
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
"Simon Marlow" <simonmar@microsoft.com> wrote,
> S. Alexander Jacobson writes:
>
> > I am not a parsing expert, but given the recent discussion on
> > macros, I
> > have to ask: why use happy rather than monadic parsing?
> > Monadic parsing
> > allows you to avoid a whole additional language/compilation
> > step and work
> > in Hugs (where you don't have a makefile). What does Happy
> > buy you here?
>
> It buys you (a) speed, (b) confidence that your grammar is
> non-ambiguous, and (c) familiar BNF notation. On the down side, as you
> point out, you lose Haskell's abstraction facilities.
>
> I'd be willing to sacrifice (c) in order to write parsers in Haskell,
> but I don't think there's a combinator library that matches Happy in
> terms of speed (disclaimer: I haven't exhaustively tested them all, but
> given the tricks Happy does I'd be surprised). AFAIK none of the
> combinator libraries gives you (b).
I don't think, the point is the test for non-ambiguity. At
least, Doitse's and my self-optimising parser combinator
library will detect that a grammar is ambigious when you
parse a sentence involving the ambiguous productions. So,
you can check that by parsing a file involving all grammar
constructs of the language.
The point is much more the level of help that you get if
your grammar happens to be ambiguous. My combinators at the
moment just tell you that the grammar is ambiguous, but
provide no help as to where and why. I think, this is
similar for Doitse's combinators. Happy helps you much more
in this situation.
Cheers,
Manuel
From dongen@cs.ucc.ie Fri May 11 10:52:55 2001
Date: Fri, 11 May 2001 10:52:55 +0100
From: Marc van Dongen dongen@cs.ucc.ie
Subject: Two Times [was Re: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)]
Manuel M. T. Chakravarty (chak@cse.unsw.edu.au) wrote:
[received message twice]
Am I just the only one or does everybody receive
messages posted to haskell@haskell.org and
glasgow-haskell-users@haskell.org twice? I find
it a bit (I know I am exaggerating) annoying.
Is there a way to avoid this?
Regards,
Marc
From la@iki.fi Thu May 10 23:07:52 2001
Date: Fri, 11 May 2001 01:07:52 +0300
From: Lauri Alanko la@iki.fi
Subject: MonadError and fundeps
On Thu, May 10, 2001 at 09:24:36PM +0000, Marcin 'Qrczak' Kowalczyk wrote:
> MonadReader, MonadWriter and MonadState classes have fundeps from the
> monad type to the environment / output / state type (I added them
> a few months ago).
Why? This makes composing and "subtyping" impossible:
instance (MonadTrans t, MonadState s m, Monad (t m))
=> MonadState s (t m) where
get = lift get
put = lift . put
This is really useful, because you can thread multiple states (or read
multiple environments, or write multiple outputs, or whatnot), and
_directly_ use functions that operate on a particular state, without
having to do explicit lifting (to the correct level) all the time.
Fundeps add convenience, yes, but they restrict what you can do with the
monads. A bad tradeoff, IMHO.
Ah well, I'm kind of used to having to use customized versions of all
the common libs...
Lauri Alanko
la@iki.fi
From qrczak@knm.org.pl Fri May 11 13:14:24 2001
Date: Fri, 11 May 2001 14:14:24 +0200 (CEST)
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: MonadError and fundeps
On Fri, 11 May 2001, Lauri Alanko wrote:
> Why? This makes composing and "subtyping" impossible:
>
> instance (MonadTrans t, MonadState s m, Monad (t m))
> => MonadState s (t m) where
> get = lift get
> put = lift . put
This instance is illegal anyway. One of types in the instance head must be
a type constructor applied to something (type variables in Haskell 98,
anything with -fglasgow-exts).
Even if it was legal, it would overlap with
instance Monad m => MonadState s (StateT s m)
Also MonadReader and MonadWriter can't have such generic instances anyway
because their methods have values of type 'm a' as arguments.
OTOH without the fundep there are ambiguities. For example:
class ParsingState s where
stateInput :: s -> String
stateSkip :: Int -> s -> s
instance ParsingState String where ...
instance ParsingState s => ParsingState (s, Pos) where ...
input :: (ParsingState s, MonadState s m) => m String
-- Ambiguous without the fundep.
input = gets stateInput
--
Marcin 'Qrczak' Kowalczyk
From la@iki.fi Fri May 11 13:45:00 2001
Date: Fri, 11 May 2001 15:45:00 +0300
From: Lauri Alanko la@iki.fi
Subject: MonadError and fundeps
On Fri, May 11, 2001 at 02:14:24PM +0200, Marcin 'Qrczak' Kowalczyk wrote:
> On Fri, 11 May 2001, Lauri Alanko wrote:
>
> > Why? This makes composing and "subtyping" impossible:
> >
> > instance (MonadTrans t, MonadState s m, Monad (t m))
> > => MonadState s (t m) where
> > get = lift get
> > put = lift . put
>
> This instance is illegal anyway. One of types in the instance head must be
> a type constructor applied to something (type variables in Haskell 98,
> anything with -fglasgow-exts).
Ah. So it seems. Pardon. It works in Hugs, though.
> Even if it was legal, it would overlap with
> instance Monad m => MonadState s (StateT s m)
Yep, but in hugs +o the latter overrides the first one. Which is quite
convenient.
> Also MonadReader and MonadWriter can't have such generic instances anyway
> because their methods have values of type 'm a' as arguments.
Oh?
translift :: (MonadTrans t, Monad m, Monad (t m))
=> (m a -> m b) -> t m a -> t m b
translift f m = m >>= lift . f . return
instance (MonadTrans t, MonadReader r m, Monad (t m))
=> MonadReader r (t m) where
ask = lift ask
local = translift . local
instance (MonadTrans t, MonadWriter w m, Monad (t m), Monoid w) =>
MonadWriter w (t m) where
tell = lift . tell
listen = translift listen
pass = translift pass
> OTOH without the fundep there are ambiguities. For example:
>
> class ParsingState s where
> stateInput :: s -> String
> stateSkip :: Int -> s -> s
>
> instance ParsingState String where ...
> instance ParsingState s => ParsingState (s, Pos) where ...
>
> input :: (ParsingState s, MonadState s m) => m String
> -- Ambiguous without the fundep.
> input = gets stateInput
So it is, and why not? Is it inconceivable that m might actually have
multiple ParsingStates, and thus you really have to specify which one you
want to use to get the input?
Lauri Alanko
la@iki.fi
From ger@tzi.de Fri May 11 14:22:31 2001
Date: Fri, 11 May 2001 15:22:31 +0200
From: George Russell ger@tzi.de
Subject: GHCi turned upside down?
GHCi allows us to mix fixed compiled and dynamic interpreted code to
be run from what I presume is dynamic interpreted code - the command
prompt. Would it be possible to run dynamic interpreted code from
a compiled program? I'm hoping the answer is "Yes, because this is what
GHCi does", the only problem being to clean up the syntax and document
it.
I'm afraid I haven't been following the FFI debate lately but perhaps we
could steal some of the FFI's syntax for declaring types of imported
entities. The difference (I'm not sure if this is a difference with
the latest with the latest FFI version) would be that the source file/string
(and perhaps function name) need to vary dynamically, which means also that
of course it needs to be done below top level, and invoke an IO action. So
we might try something like
runMain :: FilePath -> IO ()
runMain sourcePath =
do
source <- readFile sourcePath
foreign import ghci source "main" main :: IO ()
main
which would read the file "sourcePath", interpret it as Haskell,
and run the "main" action therein.
This isn't meant to be a polished proposal, just an idea for something
which might be nice to have around in the future.
From qrczak@knm.org.pl Fri May 11 14:30:05 2001
Date: Fri, 11 May 2001 15:30:05 +0200 (CEST)
From: Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
Subject: MonadError and fundeps
On Fri, 11 May 2001, Lauri Alanko wrote:
> Yep, but in hugs +o the latter overrides the first one. Which is quite
> convenient.
I doubt that it works predictably in all cases (when state types are not
known statically). I can try to construct an example if you wish.
> translift :: (MonadTrans t, Monad m, Monad (t m))
> => (m a -> m b) -> t m a -> t m b
>
> translift f m = m >>= lift . f . return
>
> instance (MonadTrans t, MonadReader r m, Monad (t m))
> => MonadReader r (t m) where
> ask = lift ask
> local = translift . local
>
> instance (MonadTrans t, MonadWriter w m, Monad (t m), Monoid w) =>
> MonadWriter w (t m) where
> tell = lift . tell
> listen = translift listen
> pass = translift pass
This gives wrong results (but I haven't checked). For example
listen :: Monoid w
=> ReaderT r (Writer w) a -> ReaderT r (Writer w) (a, w)
doesn't listen what the action tells, but listens to 'return' which always
tells mempty. Similarly 'local' first runs the action in the original
environment and then provides a new environment to 'return' which doesn't
look at it.
I did most monad transformer forwarding instances in ghc-5.00 and hope
that I got them right, but I haven't tested them much. It's not that
mechanical (except MonadState), and some combinations can't be done at
all.
It could be advantageous to put something like translift in an extension
of MonadTrans. AFAIR many liftings of this type are similar (but the
function must be provided separately for each state transformer), so it
would simplify making forwarding instances.
> Is it inconceivable that m might actually have multiple ParsingStates,
> and thus you really have to specify which one you want to use to get
> the input?
The idea is to use a single state and abstract over the way in which
interesting components are contained in it. It has these advantages:
* It works. I doubt that automatic recognition of the state type would work.
* It allows to have multiple components of the same type in the state.
Now I see that my simulation of a fundep without the fundep (an extra
class which generates the dependency, instantiated separately for each
monad transformer, with MonadError as a superclass) doesn't work that
well: throwError would still be ambiguous so it needs a wrapper with a
type which tells how to determine the error type using the new class.
So I'm now convinced that MonadError should have the fundep too.
Some other mechanism could be invented to make it easier to embed various
components in the same type (for MonadReader & MonadState) or various
alternatives (for MonadError). I have a rather heavy proposal for the
first case (a language extension which redesigns records). OCaml has
a dual mechanism for the second (polymorphic variants). If my records
succeed, I will try to cover variants too.
--
Marcin 'Qrczak' Kowalczyk
From simonmar@microsoft.com Fri May 11 15:47:08 2001
Date: Fri, 11 May 2001 15:47:08 +0100
From: Simon Marlow simonmar@microsoft.com
Subject: GHCi turned upside down?
> GHCi allows us to mix fixed compiled and dynamic interpreted code to=20
> be run from what I presume is dynamic interpreted code - the command
> prompt. Would it be possible to run dynamic interpreted code from
> a compiled program? I'm hoping the answer is "Yes, because=20
> this is what
> GHCi does", the only problem being to clean up the syntax and document
> it.
It's certainly possible, but bear in mind that you'd have to link in
essentially the whole of GHCi into your program in order to do it! But
one of the things on our wish list is to have a clearly defined
interface to the underlying compilation/session manager, (i.e. what
we've been calling the HEP, or Haskell Execution Platform). This would
allow you to plug in new user interfaces, make interpreted COM objects,
and in general have Haskell compilation/execution services available
from a Haskell API. There's still work to do in deciding exactly what
this API should look like, though.
Cheers,
Simon
From cwitty@newtonlabs.com Fri May 11 18:13:49 2001
Date: 11 May 2001 10:13:49 -0700
From: Carl R. Witty cwitty@newtonlabs.com
Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
"Manuel M. T. Chakravarty" <chak@cse.unsw.edu.au> writes:
> I don't think, the point is the test for non-ambiguity. At
> least, Doitse's and my self-optimising parser combinator
> library will detect that a grammar is ambigious when you
> parse a sentence involving the ambiguous productions. So,
> you can check that by parsing a file involving all grammar
> constructs of the language.
Sorry, doesn't work. Where do you get this "file involving all
grammar constructs of the language"?
If such an approach worked, you could use it to determine whether an
arbitrary context-free grammar was ambiguous; but this problem is
undecidable.
Carl Witty
From brian@boutel.co.nz Sat May 12 05:57:34 2001
Date: Sat, 12 May 2001 16:57:34 +1200
From: Brian Boutel brian@boutel.co.nz
Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
"Carl R. Witty" wrote:
>
> "Manuel M. T. Chakravarty" <chak@cse.unsw.edu.au> writes:
>
> > I don't think, the point is the test for non-ambiguity. At
> > least, Doitse's and my self-optimising parser combinator
> > library will detect that a grammar is ambigious when you
> > parse a sentence involving the ambiguous productions. So,
> > you can check that by parsing a file involving all grammar
> > constructs of the language.
>
> Sorry, doesn't work. Where do you get this "file involving all
> grammar constructs of the language"?
>
> If such an approach worked, you could use it to determine whether an
> arbitrary context-free grammar was ambiguous; but this problem is
> undecidable.
>
This illustrates the difference between generality and usefulness.
Often, one is less interested in learning that a grammar is ambiguous
than learning that it is not.
If you have a parser generator for a class of grammars, it will tell you
if (and probably why) a candidate grammar you feed to it is not a member
of that class. If it is accepted by, for example, a parser generator for
LR(1) grammars, then it is a DCFG and therefore unambiguous.
If you start with a "natural" grammar for the language, i.e. one that
corresponds to the abstract syntax, and use a generator for a broad
class of grammars (e.g LR(1)) then failure will give a good hint that
the only way to get an unambiguous grammar in that class is to restrict
the language, and you can use that information to make design decisions.
For example, although Haskell has both 'let' and 'where' for introducing
local definitions, thereby reflecting the typical committee decision
when there are varying stylistic preferences, 'where' is not part of the
expression syntax. If you write a grammar which includes the "natural"
productions
exp -> let defs in exp
exp -> exp where defs
and put this through a suitable generator, you will see why not.
Of course, it is possible that an unambiguous grammar will fail to be
LR(1) - by being non-deterministic, so the proper conclusion is that "G
is ambiguous or non-deterministic". But that is close enough for most
purposes.
Early versions of Hope had both 'let' and 'where' as expressions, and
had three different forms of condtional. Most combinations of these
constructs would interract to create ambiguity. The hand-coded parsers
in use had not picked this up. That shows the advantage of using a
generator - you get a constructive proof that the grammar is in the
desired class.
--brian
From michael.weber@post.rwth-aachen.de Sat May 12 10:11:39 2001
Date: Sat, 12 May 2001 11:11:39 +0200
From: Michael Weber michael.weber@post.rwth-aachen.de
Subject: Two Times [was Re: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)]
* Marc van Dongen <dongen@cs.ucc.ie> [2001-05-11T10:52+0100]:
> Manuel M. T. Chakravarty (chak@cse.unsw.edu.au) wrote:
>
> [received message twice]
>
> Am I just the only one or does everybody receive
> messages posted to haskell@haskell.org and
> glasgow-haskell-users@haskell.org twice? I find
> it a bit (I know I am exaggerating) annoying.
> Is there a way to avoid this?
Use procmail to eliminate dups...
.procmailrc:
:0 Whc: msgid.lock
| formail -D 8192 msgid.cache
:0 a:
duplicates
More info: man procmail procmailex procmailrc
Cheers,
Michael
--
() ASCII ribbon campaign | Chair for Computer Science II | GPG: F65C68CD
/\ against HTML mail | RWTH Aachen, Germany | PGP: 1D0DD0B9
But... but.... There's no BLINK tag in LaTeX!
-- seen on /.
From gemi@bluewin.ch Sat May 12 12:28:33 2001
Date: Sat, 12 May 2001 13:28:33 +0200
From: =?ISO-8859-1?Q?G=E9rard_Milmeister?= gemi@bluewin.ch
Subject: Compile problems with ghc-5.0
I use Redhat 6.2.
The binary install is ok, but when I compile ghc-5.0 from source
using ghc-5.0, I get the following error after 'make all':
../../../ghc/utils/hsc2hs/hsc2hs-inplace Directory.hsc
../../../ghc/utils/hsc2hs/hsc2hs-inplace:
/test/v-julsew/Nightly-HEAD/i386-unknown-linux/stage1/ghc/utils/hsc2hs/hsc2hs-bin:
No such file or directory
Furthermore, most available libraries seem to be uncompilable
with ghc-5.0, e.g. c2hs and gtk2hs.
--
Gérard Milmeister
Tannenrauchstr. 35
8038 Zürich
From michael.weber@post.rwth-aachen.de Sat May 12 17:30:17 2001
Date: Sat, 12 May 2001 18:30:17 +0200
From: Michael Weber michael.weber@post.rwth-aachen.de
Subject: Compile problems with ghc-5.0
* Gérard Milmeister <gemi@bluewin.ch> [2001-05-12T13:28+0200]:
> I use Redhat 6.2.
> The binary install is ok, but when I compile ghc-5.0 from source
> using ghc-5.0, I get the following error after 'make all':
>
> ../../../ghc/utils/hsc2hs/hsc2hs-inplace Directory.hsc
> ../../../ghc/utils/hsc2hs/hsc2hs-inplace:
> /test/v-julsew/Nightly-HEAD/i386-unknown-linux/stage1/ghc/utils/hsc2hs/hsc2hs-bin:
> No such file or directory
>
> Furthermore, most available libraries seem to be uncompilable
> with ghc-5.0, e.g. c2hs and gtk2hs.
For c2hs I provided a patch for configure, which made it think it's
dealing with ghc-4.11.
I don't have it at hand, but you can ask Manuel Chakravarty. AFAIK,
he already updated the c2hs CVS repo and provided a Real Solution(tm).
Cheers,
Michael
--
() ASCII ribbon campaign | Chair for Computer Science II | GPG: F65C68CD
/\ against HTML mail | RWTH Aachen, Germany | PGP: 1D0DD0B9
"I WILL NOT SELL MIRACLE CURES"
-- Bart Simpson in 9F16
From chak@cse.unsw.edu.au Sun May 13 07:51:38 2001
Date: Sun, 13 May 2001 16:51:38 +1000
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
cwitty@newtonlabs.com (Carl R. Witty) wrote,
> "Manuel M. T. Chakravarty" <chak@cse.unsw.edu.au> writes:
>
> > I don't think, the point is the test for non-ambiguity. At
> > least, Doitse's and my self-optimising parser combinator
> > library will detect that a grammar is ambigious when you
> > parse a sentence involving the ambiguous productions. So,
> > you can check that by parsing a file involving all grammar
> > constructs of the language.
>
> Sorry, doesn't work. Where do you get this "file involving all
> grammar constructs of the language"?
>
> If such an approach worked, you could use it to determine whether an
> arbitrary context-free grammar was ambiguous; but this problem is
> undecidable.
I didn't say that this works for any kind of parser
combinator, I merely said that it works Doitse's and mine.
Both implement SLL(1) parsers for which - as I am sure, you
know - there exists a decision procedure for testing
ambiguity. More precisely, whenever the library can build
the parse table, the grammar must be non-ambigious. As the
parse table construction is lazy, this covers only the
productions exercised in that particular run, which is why I
said that you need a "file involving all grammar constructs
of the language." Nothing magic here.
Cheers,
Manuel
PS: AFAIK Doitse recently made his combinators a bit more
general, and I am not entirely sure how that affects
the ambiguity check.
From chak@cse.unsw.edu.au Sun May 13 09:20:53 2001
Date: Sun, 13 May 2001 18:20:53 +1000
From: Manuel M. T. Chakravarty chak@cse.unsw.edu.au
Subject: Compile problems with ghc-5.0
michael.weber@post.rwth-aachen.de (Michael Weber) wrote,
> * G=E9rard Milmeister <gemi@bluewin.ch> [2001-05-12T13:28+0200]:
> > I use Redhat 6.2.
> > The binary install is ok, but when I compile ghc-5.0 from source
> > using ghc-5.0, I get the following error after 'make all':
> > =
> > ../../../ghc/utils/hsc2hs/hsc2hs-inplace Directory.hsc
> > ../../../ghc/utils/hsc2hs/hsc2hs-inplace:
> > /test/v-julsew/Nightly-HEAD/i386-unknown-linux/stage1/ghc/utils/hsc2=
hs/hsc2hs-bin:
> > No such file or directory
> > =
> > Furthermore, most available libraries seem to be uncompilable
> > with ghc-5.0, e.g. c2hs and gtk2hs.
> =
> For c2hs I provided a patch for configure, which made it think it's
> dealing with ghc-4.11.
> =
> I don't have it at hand, but you can ask Manuel
> Chakravarty. =
I append the patch.
> AFAIK,
> he already updated the c2hs CVS repo and provided a Real Solution(tm).=
That's right. The CVS version works with 5.00 and has some
more new goodies. I will put out a release (with binaries)
as soon as the new features are sufficiently bug free.
As for Gtk+HS, which was also mentioned, I will take care of
that after c2hs is done. Are you (that is G=E9rard) on the
Gtk+HS mailing list?
http://www.cse.unsw.edu.au/~chak/haskell/gtk/#ml
The list doesn't have much traffic, but carries news
regarding new versions of the library etc.
Cheers,
Manuel
-=3D-
--- c2hs-0.8.2.orig/configure.in
+++ c2hs-0.8.2/configure.in
@@ -113,6 +113,11 @@
dnl set GHC, as this is what the following command inspects
GHC=3D$HC
CTK_GHC_VERSION(hc_maj_vers,hc_min_vers)
+ if test $hc_maj_vers -eq 5; then
+ # HACK HACK HACK
+ hc_maj_vers=3D4
+ hc_min_vers=3D11
+ fi
if test $hc_maj_vers -lt 3 -o $hc_min_vers -lt 2; then
AC_MSG_ERROR([You need version 3.02 or 4.02 upwards of ghc!
** Check \"http://haskell.org/ghc/\". **])
--- c2hs-0.8.2.orig/c2hs/lib/Makefile
+++ c2hs-0.8.2/c2hs/lib/Makefile
@@ -95,7 +95,7 @@
# * The following enables the use of the FFI and sucks in the prototype=
s needed
# by external calls =
#
-EXTRAHCFLAGS =3D -fglasgow-exts $(LIB_HCFLAGS)
+EXTRAHCFLAGS =3D -fglasgow-exts -package lang $(LIB_HCFLAGS)
=
# make all object files
#
From cwitty@newtonlabs.com Mon May 14 20:31:43 2001
From: cwitty@newtonlabs.com (Carl R. Witty)
Date: 14 May 2001 12:31:43 -0700
Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
In-Reply-To: "Manuel M. T. Chakravarty"'s message of "Sun, 13 May 2001 16:51:38 +1000"
References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> <20010511170944K.chak@cse.unsw.edu.au> <20010513165138B.chak@cse.unsw.edu.au>
Message-ID:
"Manuel M. T. Chakravarty" writes:
> I didn't say that this works for any kind of parser
> combinator, I merely said that it works Doitse's and mine.
> Both implement SLL(1) parsers for which - as I am sure, you
> know - there exists a decision procedure for testing
> ambiguity. More precisely, whenever the library can build
> the parse table, the grammar must be non-ambigious. As the
> parse table construction is lazy, this covers only the
> productions exercised in that particular run, which is why I
> said that you need a "file involving all grammar constructs
> of the language." Nothing magic here.
Wow. Clearly I haven't spent enough time looking at your parser
systems. I apologize for my incorrect assumptions and statements.
Carl Witty
From holzmueller@ics-ag.de Wed May 16 08:38:13 2001
From: holzmueller@ics-ag.de (Bernd =?iso-8859-2?Q?Holzm=FCller?=)
Date: Wed, 16 May 2001 09:38:13 +0200
Subject: Windows binary installation for GHC 5.00
Message-ID: <3B022E63.C26CCBDA@ics-ag.de>
Is there any prediction for when the Windows (NT) binary distribution
for GHC 5.00 will be available? I would not want to install GHC5.00 from
the source distribution in case the binary distribution is going to be
released "soon". Anyway, I would expect getting an appropriate note via
the glasgow-haskell-users mailing list.
Bernd Holzmüller
From simonpj@microsoft.com Wed May 16 11:24:54 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Wed, 16 May 2001 03:24:54 -0700
Subject: Windows binary installation for GHC 5.00
Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72F2B@red-msg-09.redmond.corp.microsoft.com>
Yes, it'll be 'soon' (days, or a week or three, but not months)
Simon
| -----Original Message-----
| From: Bernd Holzm=FCller [mailto:holzmueller@ics-ag.de]=20
| Sent: 16 May 2001 08:38
| To: glasgow-haskell-users@haskell.org
| Subject: Windows binary installation for GHC 5.00
|=20
|=20
| Is there any prediction for when the Windows (NT) binary=20
| distribution for GHC 5.00 will be available? I would not want=20
| to install GHC5.00 from the source distribution in case the=20
| binary distribution is going to be released "soon". Anyway, I=20
| would expect getting an appropriate note via the=20
| glasgow-haskell-users mailing list.
|=20
| Bernd Holzm=FCller
|=20
| _______________________________________________
| Glasgow-haskell-users mailing list=20
| Glasgow-haskell-users@haskell.org=20
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-| users
|=20
From awhitford@lucent.com Wed May 16 17:36:01 2001
From: awhitford@lucent.com (Whitford, Alister)
Date: Wed, 16 May 2001 17:36:01 +0100
Subject: Problems building GHC 5.00 on Solaris 2.5.1
Message-ID: <7B405CCAA598D411B52F006008F61B190AD89B@lon-exch1.kenan.com>
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C0DE26.4B412D20
Content-Type: text/plain;
charset="iso-8859-1"
I'm trying to build GHC 5.00 on Solaris 2.5.1.
I've got most of the way there. So far, I've had to:
- Hack glafp-utils/sgmlverb/Makefile because by lex doesn't support the -8
option.
- Hack mk/target.mk in several places because my ld doesn't support the -x
option.
- Hack configure.in to prevent it from trying to build ReadLine (which was
failing.)
(Any comments on the above?)
The compiler and standard libraries have all built. I'm now attempting to
build DrIFT, but I get the following error:
../../../ghc/compiler/ghc-inplace -o DrIFT -ldl -cpp -fglasgow-exts -package
text -O ChaseImports.o CommandP.o DataP.o DigitToInt.o DrIFT.o
Literate.o ParseLib2.o PreludData.o Pretty.o RuleUtils.o StandardRules.o
UserRuleBinary.o UserRuleXml.o UserRules.o
Undefined first referenced
symbol in file
siginterrupt
/tmp/ajw/ghc-5.00-build-from-4.08.2/ghc/driver/../rts/libHSrts.a(Signals.o)
ld: fatal: Symbol referencing errors. No output written to DrIFT
In fact, this occurs whenever I run ghc-inplace to try to create an
executable :-(
It turns out that siginterrupt is defined in /usr/ucblib/libucb.a, so if I
muck about a bit, I can get a working executable like so:
/tmp/ajw/ghc-5.00-build-from-4.08.2/ghc/compiler/ghc-inplace -o test
-L/usr/ucblib -lucb test.lhs
So the question is: how do I get libHSrts.a to link automatically with
/usr/ucblib/libucb.a so that the compiler will work properly?
Many thanks in advance for any help!
Cheers,
Alister.
------_=_NextPart_001_01C0DE26.4B412D20
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Problems building GHC 5.00 on Solaris 2.5.1
I'm trying to build GHC 5.00 on Solaris 2.5.1.
I've got most of the way there. So far, I've =
had to:
- Hack glafp-utils/sgmlverb/Makefile because by lex =
doesn't support the -8 option.
- Hack mk/target.mk in several places because my ld =
doesn't support the -x option.
- Hack configure.in to prevent it from trying to =
build ReadLine (which was failing.)
(Any comments on the above?)
The compiler and standard libraries have all =
built. I'm now attempting to build DrIFT, but I get the following =
error:
../../../ghc/compiler/ghc-inplace -o DrIFT -ldl -cpp =
-fglasgow-exts -package text -O =
ChaseImports.o CommandP.o DataP.o DigitToInt.o DrIFT.o Literate.o =
ParseLib2.o PreludData.o Pretty.o RuleUtils.o StandardRules.o =
UserRuleBinary.o UserRuleXml.o UserRules.o
Undefined =
=
first referenced
symbol &nb=
sp; &nb=
sp; in file
siginterrupt &nb=
sp; &nb=
sp; =
/tmp/ajw/ghc-5.00-build-from-4.08.2/ghc/driver/../rts/libHSrts.a(Signals=
.o)
ld: fatal: Symbol referencing errors. No output =
written to DrIFT
In fact, this occurs whenever I run ghc-inplace to =
try to create an executable :-(
It turns out that siginterrupt is defined in =
/usr/ucblib/libucb.a, so if I muck about a bit, I can get a working =
executable like so:
/tmp/ajw/ghc-5.00-build-from-4.08.2/ghc/compiler/ghc-inplace =
-o test -L/usr/ucblib -lucb test.lhs
So the question is: how do I get libHSrts.a to link =
automatically with /usr/ucblib/libucb.a so that the compiler will work =
properly?
Many thanks in advance for any help!
Cheers,
Alister.
------_=_NextPart_001_01C0DE26.4B412D20--
From simonmar@microsoft.com Wed May 16 17:46:57 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Wed, 16 May 2001 17:46:57 +0100
Subject: Endangered I/O operations
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6115886@TVP-MSG-01.europe.corp.microsoft.com>
I'm currently re-implementing GHC's I/O library, and I'd like to get
people's opinions on the following I/O extensions currently provided by
GHC - should we continue to provide them or not.
1. IOExts.hConnectTo
This was designed to be a way to have one handle automatically flushed
before we flush another handle (eg. outputting to stderr causes stdout
to be flushed first). The current implementation has a number of
problems: errors and blocking arenn't handled properly when doing the
connected flush. If no-one is using it, I'd like to get rid of it.
2. IOExts.withHandleFor
This is a cunning hack to allow you to temporarily redirect one handle
to another, like 2>&1 in shell speak. I'm dubious as to whether it
works consistently - there's certainly not enough error checking in the
implementation, so if no-one is using it I'd like to drop it.
3. IOExts.hGetBuf, IOExts.hPutBuf,=20
IOExts.hGetBufBA, IOExts.hPutBufBA
These are the "non-blocking" versions of hGetBufFull, hPutBufFull etc.
I can't remember why we have both blocking and non-blocking versions,
although I distinctly remember implementing and documenting them :-) If
anyone is using, or knows of a good use for, the non-blocking versions,
then I'll keep them. Otherwise, I'd like to rename hGetBufFull to
hGetBuf, and similarly for the others.
Cheers,
Simon
From awhitford@lucent.com Thu May 17 11:33:30 2001
From: awhitford@lucent.com (Alister Whitford)
Date: Thu, 17 May 2001 11:33:30 +0100 (BST)
Subject: Problems building GHC 5.00 on Solaris 2.5.1
Message-ID: <200105171033.LAA21379@lonsdev3.kenan.com>
I forgot to mention in my first mail that I also got nearly 4000 warnings of the form, "call-clobbered register used for global register variable".
They all occur in ghc/include/Reg.h, on the lines that declare the registers F1, F2, F3, F4, D1 and D2. However, in ghc/include/MachReg.h, we see:
#if sparc_TARGET_ARCH
...
#define CALLER_SAVES_F1
#define CALLER_SAVES_F2
#define CALLER_SAVES_F3
#define CALLER_SAVES_F4
#define CALLER_SAVES_D1
#define CALLER_SAVES_D2
So I am assuming that this warning may safely be ignored - is this correct?
Btw, apologies that my original message was in MIME format. Sadly Outlook sends it like that even if you select plain text as your message format, so I have resorted to composing my messages in vi and using the unix mail command...
From sof@galconn.com Fri May 18 19:12:04 2001
From: sof@galconn.com (Sigbjorn Finne)
Date: Fri, 18 May 2001 11:12:04 -0700
Subject: Endangered I/O operations
References: <9584A4A864BD8548932F2F88EB30D1C6115886@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <01dd01c0dfc6$0b6c9d00$4576fea9@sofbox>
Simon Marlow simonmar@microsoft.com writes:
>
> I'm currently re-implementing GHC's I/O library, and I'd like to get
> people's opinions on the following I/O extensions currently provided by
> GHC - should we continue to provide them or not.
>
> 1. IOExts.hConnectTo
>
> This was designed to be a way to have one handle automatically flushed
> before we flush another handle (eg. outputting to stderr causes stdout
> to be flushed first). The current implementation has a number of
> problems: errors and blocking arenn't handled properly when doing the
> connected flush. If no-one is using it, I'd like to get rid of it.
>
If you handle std{in,out,err} connectedness in other ways, I think you've
covered 99.2% of the uses of hConnectTo. Neat idea borrowed from
Korn & Vo's SFIO, but it hasn't proved to be all that useful.
> 2. IOExts.withHandleFor
>
> This is a cunning hack to allow you to temporarily redirect one handle
> to another, like 2>&1 in shell speak. I'm dubious as to whether it
> works consistently - there's certainly not enough error checking in the
> implementation, so if no-one is using it I'd like to drop it.
>
Don't mind seeing it going.
--sigbjorn
From simonmar@microsoft.com Mon May 21 16:01:11 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Mon, 21 May 2001 16:01:11 +0100
Subject: hTell
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD6DB@TVP-MSG-01.europe.corp.microsoft.com>
Quick question: can anyone tell me why IOExts.hTell returns a
HandlePosition, whereas IO.hSeek takes an Integer?
From qrczak@knm.org.pl Mon May 21 17:29:05 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 21 May 2001 16:29:05 GMT
Subject: hTell
References: <9584A4A864BD8548932F2F88EB30D1C6058DD6DB@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID:
Mon, 21 May 2001 16:01:11 +0100, Simon Marlow pisze:
> Quick question: can anyone tell me why IOExts.hTell returns
> a HandlePosition,
It doesn't. The comment in export list is wrong.
It's wrong because Haskell still lacks a formal way to describe
module interfaces.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From simonmar@microsoft.com Tue May 22 11:30:00 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Tue, 22 May 2001 11:30:00 +0100
Subject: Endangered I/O operations
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD6E0@TVP-MSG-01.europe.corp.microsoft.com>
> If you handle std{in,out,err} connectedness in other ways, I=20
> think you've
> covered 99.2% of the uses of hConnectTo. Neat idea borrowed from
> Korn & Vo's SFIO, but it hasn't proved to be all that useful.
I wasn't planning to handle connectedness at all. Is it important, do
you think? (I'm not against the feature, just trying to avoid feeping
creaturism...)
Cheers,
Simon
From simonmar@microsoft.com Tue May 22 15:43:45 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Tue, 22 May 2001 15:43:45 +0100
Subject: Poll: System.exitWith behaviour
Message-ID: <9584A4A864BD8548932F2F88EB30D1C611588D@TVP-MSG-01.europe.corp.microsoft.com>
The current behaviour of System.exitWith doesn't really make sense in a
concurrent environment. The current semantics is to:
- halt the current thread
- run all finalizers (concurrently with any other
currently running threads)
- stop the system as soon as all finalizers have
finished.
One high-priority problem we also have is that a program which calls
System.exitWith from inside GHCi will shut down the whole system.
Here's my current proposal:
- introduce a new exception constructor:
ExitException ExitCode
- System.exitWith causes (ExitException code) to be
raised in the current thread.
=20
- If this exception propogates to the top of the thread, then
the main thread is also sent (ExitException code). This
only happens for a standalone executable (ie. one which was
started by PrelMain.mainIO).
- If this exception propogates to the top of the main thread,
then the system is shut down as before - all finalizers are
run to completion, then we exit.
For GHCi, we can obviously catch the ExitException exception and
recover, and there is no main thread in this case.
An alternative is just to omit the third point and let the programmer
handle propagation of the ExitException to the main thread. This is
somewhat consistent with our current policy of leaving these kind of
decisions up to the programmer: we currently don't implement any kind of
process hierarchy, and there is no requirement for child threads to
complete before the program exits, for example.
Cheers,
Simon
From plop@redbrick.dcu.ie Tue May 22 17:15:50 2001
From: plop@redbrick.dcu.ie (Smelly Pooh)
Date: Tue, 22 May 2001 17:15:50 +0100
Subject: Poll: System.exitWith behaviour
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611588D@TVP-MSG-01.europe.corp.microsoft.com>; from simonmar@microsoft.com on Tue, May 22, 2001 at 03:43:45PM +0100
References: <9584A4A864BD8548932F2F88EB30D1C611588D@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010522171550.A46611@enigma.redbrick.dcu.ie>
In reply to Simon Marlow,
> - introduce a new exception constructor:
> ExitException ExitCode
>
> - System.exitWith causes (ExitException code) to be
> raised in the current thread.
Not entirely relevant, in fact, barely at all but what are the odds of user
extensible Exceptions (like ML) coming into GHC and having a proper hierarchy
of exceptions integrated in the libraries?
From simonmar@microsoft.com Tue May 22 17:30:39 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Tue, 22 May 2001 17:30:39 +0100
Subject: Poll: System.exitWith behaviour
Message-ID: <9584A4A864BD8548932F2F88EB30D1C611588E@TVP-MSG-01.europe.corp.microsoft.com>
> In reply to Simon Marlow,
> > - introduce a new exception constructor:
> > ExitException ExitCode
> >=20
> > - System.exitWith causes (ExitException code) to be
> > raised in the current thread.
>=20
> Not entirely relevant, in fact, barely at all but what are=20
> the odds of user
> extensible Exceptions (like ML) coming into GHC and having a=20
> proper hierarchy
> of exceptions integrated in the libraries?
Well, we could do a proper job of extensible data types, which probably
isn't hard but is certainly a fair amount of work. Or we could treat
Exception as a special case, like ML. Or we could take the
Dynamic-typed exception stuff and try to use that in a general way to
provide an extensible exception type... I'm open to suggestions.
Cheers,
Simon
From sof@galconn.com Tue May 22 17:46:48 2001
From: sof@galconn.com (Sigbjorn Finne)
Date: Tue, 22 May 2001 09:46:48 -0700
Subject: Endangered I/O operations
References: <9584A4A864BD8548932F2F88EB30D1C6058DD6E0@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <012f01c0e2de$cb7d2f90$4576fea9@sofbox>
----- Original Message -----
From: "Simon Marlow"
To: "Sigbjorn Finne"
Cc: "GHC Users Mailing List (GHC Users Mailing List)"
Sent: Tuesday, May 22, 2001 03:30
Subject: RE: Endangered I/O operations
> > If you handle std{in,out,err} connectedness in other ways, I
> > think you've
> > covered 99.2% of the uses of hConnectTo. Neat idea borrowed from
> > Korn & Vo's SFIO, but it hasn't proved to be all that useful.
>
> I wasn't planning to handle connectedness at all. Is it important, do
> you think? (I'm not against the feature, just trying to avoid feeping
> creaturism...)
>
Yes, crucial I think - if stdout and stderr are connected to the same
device,
don't you want their output to be synchronised, e.g.,
main = putStr "foo" >> hPutStr stderr " bar"
should return "foo bar" on your TTY. Ditto for flushing stdout/stderr when
peeking stdin.
--sigbjorn
From qrczak@knm.org.pl Tue May 22 18:06:02 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 22 May 2001 17:06:02 GMT
Subject: Poll: System.exitWith behaviour
References: <9584A4A864BD8548932F2F88EB30D1C611588D@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID:
Tue, 22 May 2001 15:43:45 +0100, Simon Marlow pisze:
> - If this exception propogates to the top of the thread, then
> the main thread is also sent (ExitException code). This
> only happens for a standalone executable (ie. one which was
> started by PrelMain.mainIO).
This looks like a strange exception for me (i.e. the fact that it
propagates to the main thread). And it's weird to have it as an
asynchronous exception in the main thread.
I would drop this rule and let 'exitWith ExitSuccess' be the way to
commit suicide by a thread, as if it completed, which degenerates to
the Haskell 98 interpretation in a single-threaded program.
BTW, I don't quite like the fact that 'exitFailure' looks simpler than
'exitWith ExitSuccess'.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From qrczak@knm.org.pl Tue May 22 18:57:28 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 22 May 2001 17:57:28 GMT
Subject: Poll: System.exitWith behaviour
References: <9584A4A864BD8548932F2F88EB30D1C611588E@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID:
Tue, 22 May 2001 17:30:39 +0100, Simon Marlow pisze:
> Well, we could do a proper job of extensible data types, which
> probably isn't hard but is certainly a fair amount of work.
This would be IMHO the only right way, but I doubt that it's that
simple. For example it would be irritating that you can't extend
function definitions accepting values of extensible data types as
arguments; even (==) is problematic.
It's a pity that there is no direct translation of the OO style open
polymorphism. You can use an algebraic type, but it casts all variants
in stone; you can store extracted concrete-typed interface in function
closures, but it doesn't allow to cast down (retrieve the original,
more specific type); you can use existential quantification, with the
same limitations; you can use Dynamic, which is not nice to define
instances of, puts everything in one big bag, and doesn't provide
any hierarchy or extraction by partial matches.
I was recently thinking on a similar thing; it would not help
with exceptions though, only with MonadError-based exceptions and
extensible abstract syntax trees. The idea is to dualize my record
proposal by introducing overloaded constructors. It provides views
for free, i.e. allows having pattern matching on abstract types
with programmer-defined semantics.
Details aren't finished yet, but I imagine something like this:
data HsExp e n l p = variant -- I like layout :-)
-- The proposal doesn't eliminate the need to have type parameters
-- here and close the recursion on types later :-(
Var n
Con n
Literal l
App e e
etc.
This introduces overloaded constructors:
HsVar :: (e > Var n) => n -> e
Con :: (e > Con n) => n -> e
Literal :: (e > Literal l) => l -> e
App :: (e > App e1 e2) => e1 -> e2 -> e
and instances:
instance HsExp e n l p > Var n
instance HsExp e n l p > Con n
instance HsExp e n l p > Literal l
instance HsExp e n l p > App e e
A class of the form 't > C t1 t2' allows to create values of type t by
applying the constructor C to values of types t1 and t2, and pattern
match on values of type t using the constructor C with arguments of
types t1 and t2.
In another module you can reuse the same constructor names (they
don't collide as long as the arity is the same). You can also inherit
constructors from other types, similarly as in my records:
data GhcExp e n l p = variant
Haskell98Exp :: HsExp e n l p
Haskell98Exp (Var, Con, Literal, App, etc.)
-- This creates forwarding instances of the appropriate
-- classes, so Var etc. can be used with GhcExp too.
-- Using the constructor Haskell98Exp expresses explicit
-- subtyping/supertyping coercions.
UnboxedTuple [e]
CCall String [e]
And you can define such instances yourself:
instance PackedString > Nil where
-- Construction:
(Nil) = nilPs -- Needs a better syntax. This *defines* Nil.
-- Pattern matching:
s | nullPs -> Nil
-- Matching failure here (because of a failed guard)
-- means that the given value is not considered Nil.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From chak@cse.unsw.edu.au Wed May 23 07:50:42 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Wed, 23 May 2001 16:50:42 +1000
Subject: Poll: System.exitWith behaviour
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611588D@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C611588D@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010523165042H.chak@cse.unsw.edu.au>
"Simon Marlow" wrote,
> The current behaviour of System.exitWith doesn't really make sense in a
> concurrent environment. The current semantics is to:
>
> - halt the current thread
>
> - run all finalizers (concurrently with any other
> currently running threads)
>
> - stop the system as soon as all finalizers have
> finished.
>
> One high-priority problem we also have is that a program which calls
> System.exitWith from inside GHCi will shut down the whole system.
>
> Here's my current proposal:
>
> - introduce a new exception constructor:
> ExitException ExitCode
>
> - System.exitWith causes (ExitException code) to be
> raised in the current thread.
>
> - If this exception propogates to the top of the thread, then
> the main thread is also sent (ExitException code). This
> only happens for a standalone executable (ie. one which was
> started by PrelMain.mainIO).
>
> - If this exception propogates to the top of the main thread,
> then the system is shut down as before - all finalizers are
> run to completion, then we exit.
>
> For GHCi, we can obviously catch the ExitException exception and
> recover, and there is no main thread in this case.
>
> An alternative is just to omit the third point and let the programmer
> handle propagation of the ExitException to the main thread. This is
> somewhat consistent with our current policy of leaving these kind of
> decisions up to the programmer: we currently don't implement any kind of
> process hierarchy, and there is no requirement for child threads to
> complete before the program exits, for example.
I think, having the third point is good, because the Haskell
report requires that
Computation exitWith code terminates the program,
returning code to the program's caller.
Cheers,
Manuel
From simonmar@microsoft.com Wed May 23 10:08:04 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Wed, 23 May 2001 10:08:04 +0100
Subject: Poll: System.exitWith behaviour
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6115890@TVP-MSG-01.europe.corp.microsoft.com>
> I think, having the third point is good, because the Haskell
> report requires that=20
>=20
> Computation exitWith code terminates the program,
> returning code to the program's caller.
Either way we still conform to the report in the case of a single
threaded program (actually, we've already deviated from the report in
allowing you to catch the ExitException and carry on).
For a multi-threaded program, it's not clear to me what exitWith should
do. What should happen if a Haskell callback invokes exitWith? Should
it terminate the Haskell main thread?
I must admit I'm leaning more towards omitting the third point, and
that's what I've implemented for now.
Cheers,=09
Simon
From simonmar@microsoft.com Wed May 23 10:55:39 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Wed, 23 May 2001 10:55:39 +0100
Subject: Endangered I/O operations
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6115891@TVP-MSG-01.europe.corp.microsoft.com>
> > > If you handle std{in,out,err} connectedness in other ways, I
> > > think you've
> > > covered 99.2% of the uses of hConnectTo. Neat idea borrowed from
> > > Korn & Vo's SFIO, but it hasn't proved to be all that useful.
> >
> > I wasn't planning to handle connectedness at all. Is it=20
> important, do
> > you think? (I'm not against the feature, just trying to=20
> avoid feeping
> > creaturism...)
> >
>=20
> Yes, crucial I think - if stdout and stderr are connected to the same
> device,
> don't you want their output to be synchronised, e.g.,
>=20
> main =3D putStr "foo" >> hPutStr stderr " bar"
>=20
> should return "foo bar" on your TTY. Ditto for flushing=20
> stdout/stderr when
> peeking stdin.
You obtain the ordering properties by setting the handle to NoBuffering,
otherwise you get buffered input/output. Wouldn't it be deviating from
the report to do extra flushing in the buffered case? (this is
something of a technicality, actually we already do non-report flushing
in several cases and our line-buffered input isn't line-buffered at
all).
But I'm still not convinced we need to special case this.
Cheers,
Simon
From qrczak@knm.org.pl Wed May 23 08:26:01 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 23 May 2001 07:26:01 GMT
Subject: Poll: System.exitWith behaviour
References: <9584A4A864BD8548932F2F88EB30D1C611588D@TVP-MSG-01.europe.corp.microsoft.com> <20010523165042H.chak@cse.unsw.edu.au>
Message-ID:
Wed, 23 May 2001 16:50:42 +1000, Manuel M. T. Chakravarty pisze:
> I think, having the third point is good, because the Haskell
> report requires that
>
> Computation exitWith code terminates the program,
> returning code to the program's caller.
Well, it says also that
Actions, however, must be ordered in a well-defined manner for
program execution -- and I/O in particular -- to be meaningful.
Haskell 's I/O monad provides the user with a way to specify the
sequential chaining of actions, and an implementation is obliged
to preserve this order.
which is not true in a threaded program.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From sof@galconn.com Wed May 23 18:44:17 2001
From: sof@galconn.com (Sigbjorn Finne)
Date: Wed, 23 May 2001 10:44:17 -0700
Subject: Endangered I/O operations
References: <9584A4A864BD8548932F2F88EB30D1C6115891@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <0ddd01c0e3af$fdbdf300$4576fea9@sofbox>
Simon Marlow writes:
>
....
> You obtain the ordering properties by setting the handle to NoBuffering,
> otherwise you get buffered input/output. Wouldn't it be deviating from
> the report to do extra flushing in the buffered case?
The report is very silent about this, so I guess that reduces the question
to what the end-user would prefer, (a) go non-buffered or make sure you
call hFlush at the right time, or (b) have the IO implementation flush when
required. I prefer (b), which is why I implemented this at the time, as it
is
more useable (and more efficient to boot).
FWIW, notice that stdio implementations diverge on this issue too, all
Win32 impls I've seen does the flushing for you, as did earlier impls of
glibc, I seem to recall.
--sigbjorn
From cwitty@newtonlabs.com Wed May 23 19:35:24 2001
From: cwitty@newtonlabs.com (Carl R. Witty)
Date: 23 May 2001 11:35:24 -0700
Subject: Endangered I/O operations
In-Reply-To: "Simon Marlow"'s message of "Wed, 23 May 2001 10:55:39 +0100"
References: <9584A4A864BD8548932F2F88EB30D1C6115891@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID:
"Simon Marlow" writes:
> You obtain the ordering properties by setting the handle to NoBuffering,
> otherwise you get buffered input/output. Wouldn't it be deviating from
> the report to do extra flushing in the buffered case? (this is
> something of a technicality, actually we already do non-report flushing
> in several cases and our line-buffered input isn't line-buffered at
> all).
If the report does not allow the implementation to flush buffers at
any time, I would call that a bug in the report. I would much rather
use an implementation where stdout and stderr came out in the right
order, and reading from stdin flushed stdout. (As another example, an
implementation might want to flush all buffers before doing a fork(),
to avoid duplicated output.)
The only caveat is that if such flushing is allowed but not required,
it might encourage writing sloppy, nonportable code.
Carl Witty
From kahl@heraklit.informatik.unibw-muenchen.de Wed May 23 20:21:19 2001
From: kahl@heraklit.informatik.unibw-muenchen.de (kahl@heraklit.informatik.unibw-muenchen.de)
Date: 23 May 2001 19:21:19 -0000
Subject: Endangered I/O operations
In-Reply-To: (cwitty@newtonlabs.com)
References: <9584A4A864BD8548932F2F88EB30D1C6115891@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010523192119.3854.qmail@dionysos.informatik.unibw-muenchen.de>
Carl R. Witty writes:
>
> "Simon Marlow" writes:
>
> > You obtain the ordering properties by setting the handle to NoBuffering,
> > otherwise you get buffered input/output. Wouldn't it be deviating from
> > the report to do extra flushing in the buffered case? (this is
> > something of a technicality, actually we already do non-report flushing
> > in several cases and our line-buffered input isn't line-buffered at
> > all).
>
> If the report does not allow the implementation to flush buffers at
> any time, I would call that a bug in the report. I would much rather
> use an implementation where stdout and stderr came out in the right
> order, and reading from stdin flushed stdout. (As another example, an
> implementation might want to flush all buffers before doing a fork(),
> to avoid duplicated output.)
A related wish I have is that a Haskell program receiving a HUP signal
should flush its buffers before terminating.
Or even better, flush on some other signal that does not terminate
the program.
I frequently have long-running (weeks, months ...) applications
that produce data (lists) with decreasing speed.
Since data may be sitting in unflushed buffers for days (weeks, ...),
I currently shy away from using Show instances for lists
and instead use the following ``printList'' function:
> hPutList :: String -> (a -> ShowS) -> Handle -> [a] -> IO ()
> hPutList sep shows h = mapM_ f
> where f x = hPutStr h (shows x sep) >> hFlush h
>
> putList :: String -> (a -> ShowS) -> [a] -> IO ()
> putList sep shows = hPutList sep shows stdout
>
> printList :: Show a => String -> [a] -> IO ()
> printList sep = putList sep shows
It would be really nice to have other possibilities to force the program
to flush buffers!
Cheers,
Wolfram
From qrczak@knm.org.pl Wed May 23 20:55:20 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 23 May 2001 19:55:20 GMT
Subject: Poll: System.exitWith behaviour
References: <9584A4A864BD8548932F2F88EB30D1C6115890@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID:
Here is what I just read on comp.lang.python:
| the docs I have say that a thread can stop ITSELF, by raising
| SystemExit, or calling sys.exit().
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From simonmar@microsoft.com Thu May 24 10:10:15 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Thu, 24 May 2001 10:10:15 +0100
Subject: Endangered I/O operations
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6115894@TVP-MSG-01.europe.corp.microsoft.com>
> A related wish I have is that a Haskell program receiving a HUP signal
> should flush its buffers before terminating.
>=20
> Or even better, flush on some other signal that does not terminate
> the program.
Well, you can catch HUP in the program and initiate a flush. Actually
just doing System.exitWith will cause all the open handles to be flushed
and closed, but note that if you do System.exitWith from a signal
handler it won't terminate the program any more... ;-)
I think we've just found an argument in favour of having System.exitWith
always terminate the program even from a child thread.
If you want to *just* flush all the open handles from a signal handler,
you'll need to keep track of the open handles and flush them by hand
from the signal handler. See the Posix library documentation for
details on setting up a signal handler.
Cheers,
Simon
From v-julsew@microsoft.com Thu May 24 13:57:06 2001
From: v-julsew@microsoft.com (Julian Seward (Intl Vendor))
Date: Thu, 24 May 2001 05:57:06 -0700
Subject: ghc-5.00.1 is available
Message-ID: <68B95AA1648D1840AB0083CC63E57AD60F2323@red-msg-06.redmond.corp.microsoft.com>
The (Interactive) Glasgow Haskell Compiler -- version 5.00.1
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
We are pleased to announce a new patchlevel release of the Glasgow
Haskell Compiler (GHC), version 5.00.1. The source distribution is
freely available via the World-Wide Web and through anon. FTP, under a
BSD-style license. See below for download details. Pre-built
packages for Linux, FreeBSD, and Solaris(sparc) are also available.
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.00.1
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
This is a bug-fix release. Most reported bugs in 5.00 have been
fixed, including a substantial number of show-stopping bugs. The
system should be much more usable for more people. Upgrading to
5.00.1 is recommended. To all those who tried out 5.00 and reported
bugs, we thank you for your feedback and patience.
At the moment there is no Win32 build of 5.00 or 5.00.1 available. We
decided to push Win32 support to the 5.02 release, so as not to delay
5.00.1 any further.
What's new in 5.00
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
5.00 has been majorly revamped since the previous stable version,
4.08.2.
This should be a stable release. Major changes since 4.08.2 are:
- An interactive system, similar in style to Hugs. You can
interactively
load and unload modules, run expressions, ask the types of things.
Module dependencies are tracked and chased automatically.
Combinations of compiled and interpreted modules may be used.
All the GHC libraries are available in interactive mode, as are
most of the Glasgow extensions to Haskell 98. Compilation in
interactive mode (to bytecode) is about three times faster than
compiling to object code.
- Batch compilation of multiple modules at once, with automatic
dependency chasing. For large programs this can halve compilation
times, and removes the need for Makefiles.
- Enhanced package (library) management system. Packages may be
installed and removed from an installation using the ghc-pkg tool.
- Initial Unicode support - the Char type is now 31 bits.
- Sparc native code generator, giving much faster compilation on
sparcs.
(Native code generation for x86s has been available for a while).
- Improved heap profiling - you can restrict heap profiles
by type, closure description, cost centre, and module.
- Support for the latest Foreign Function Interface (FFI)
proposals. Marcin Kowalczyk's hsc2hs tool is included.
- Language extensions: parallel list comprehensions and functional
dependencies.
- The usual huge collection of bug fixes. Most reported bugs have
been fixed.
For full details see the release notes:
http://www.haskell.org/ghc/docs/5.00/set/release-5-00.html
How to get it
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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 .rpm/.deb form for all you Linux junkies
out there, 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
To compile programs with GHC, you need a machine with 32+MB memory, GNU
C
and perl. This release is known to work on the following platforms:
* i386-unknown-{linux,freebsd,mingw32}
* sparc-sun-solaris2
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
* alpha-dec-osf{2,3}
* 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/5.00/building/building-guide.html
Mailing lists
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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 send bug reports about GHC to glasgow-haskell-bugs@haskell.org;
GHC users hang out on glasgow-haskell-users@haskell.org. Bleeding
edge CVS users party on cvs-ghc@haskell.org.
From simonmar@microsoft.com Thu May 24 10:05:59 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Thu, 24 May 2001 10:05:59 +0100
Subject: Endangered I/O operations
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD6F5@TVP-MSG-01.europe.corp.microsoft.com>
> Simon Marlow writes:
> >
> ....
> > You obtain the ordering properties by setting the handle to=20
> NoBuffering,
> > otherwise you get buffered input/output. Wouldn't it be=20
> deviating from
> > the report to do extra flushing in the buffered case?
>=20
> The report is very silent about this, so I guess that reduces=20
> the question
> to what the end-user would prefer, (a) go non-buffered or=20
> make sure you
> call hFlush at the right time, or (b) have the IO=20
> implementation flush when
> required. I prefer (b), which is why I implemented this at=20
> the time, as it
> is
> more useable (and more efficient to boot).
>=20
> FWIW, notice that stdio implementations diverge on this issue too, all
> Win32 impls I've seen does the flushing for you, as did=20
> earlier impls of
> glibc, I seem to recall.
Ok, the concensus seems to be that folk would prefer the flushing to be
done automatically. There's bound to be some overhead, though...
Cheers,
Simon
From Dominic.J.Steinitz@BritishAirways.com Thu May 24 18:47:42 2001
From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J)
Date: 24 May 2001 17:47:42 Z
Subject: ghc-5.00.1 is available
Message-ID: <"04CAB3B0D493E00E*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
Will this
- Initial Unicode support - the Char type is now 31 bit
cause me a problem?
I am sending protocol elements via a socket. I represent these as [Word8]. I had assumed that when I want to send something I do
hPutStr (map (ord .word8ToInt) protocolElement)
essentially doing a type coercion. But this looks like bits actually get changed into something the respondent won't recognise.
Dominic.
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
From Dominic.J.Steinitz@BritishAirways.com Thu May 24 22:48:11 2001
From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J)
Date: 24 May 2001 21:48:11 Z
Subject: ghc-5.00.1 is available
Message-ID: <"046603B0D819B004*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
Of course I meant
hPutStr handle (map (chr .word8ToInt) protocolElement)
Dominic J Steinitz@baexternal
24/05/2001 18:47
To: v-julsew
cc: glasgow-haskell-users
haskell
bcc: Dominic Steinitz
Subject: Re: ghc-5.00.1 is available
Will this
- Initial Unicode support - the Char type is now 31 bit
cause me a problem?
I am sending protocol elements via a socket. I represent these as [Word8]. I had
assumed that when I want to send something I do
hPutStr (map (ord .word8ToInt) protocolElement)
essentially doing a type coercion. But this looks like bits actually get changed
into something the respondent won't recognise.
Dominic.
--------------------------------------------------------------------------------
-----------------
21st century air travel http://www.britishairways.com
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
From chak@cse.unsw.edu.au Fri May 25 01:56:36 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Fri, 25 May 2001 10:56:36 +1000
Subject: Poll: System.exitWith behaviour
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C6115890@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C6115890@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010525105636E.chak@cse.unsw.edu.au>
"Simon Marlow" wrote,
> > I think, having the third point is good, because the Haskell
> > report requires that
> >
> > Computation exitWith code terminates the program,
> > returning code to the program's caller.
>
> Either way we still conform to the report in the case of a single
> threaded program (actually, we've already deviated from the report in
> allowing you to catch the ExitException and carry on).
>
> For a multi-threaded program, it's not clear to me what exitWith should
> do. What should happen if a Haskell callback invokes exitWith? Should
> it terminate the Haskell main thread?
>
> I must admit I'm leaning more towards omitting the third point, and
> that's what I've implemented for now.
If you call exit() in a multi-threaded C program, it is also
gone.
Cheers,
Manuel
From mechvel@math.botik.ru Fri May 25 06:21:25 2001
From: mechvel@math.botik.ru (S.D.Mechveliani)
Date: Fri, 25 May 2001 09:21:25 +0400
Subject: building from source in User's guide
Message-ID:
GHC-5.xxx User's Guide explains binary installation.
But I cannot find there about making from sources.
Am I missing something?
-----------------
Serge Mechveliani
mechvel@botik.ru
From simonmar@microsoft.com Fri May 25 09:50:12 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Fri, 25 May 2001 09:50:12 +0100
Subject: building from source in User's guide
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD701@TVP-MSG-01.europe.corp.microsoft.com>
> GHC-5.xxx User's Guide explains binary installation.
> But I cannot find there about making from sources.=20
> Am I missing something?
The Building Guide is a separate document, available on-line here:
http://www.haskell.org/ghc/docs/latest/building/building-guide.html
Cheers,
Simon
From simonmar@microsoft.com Fri May 25 10:18:02 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Fri, 25 May 2001 10:18:02 +0100
Subject: GHCi 5.00.1: packages can now be loaded at the prompt
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD704@TVP-MSG-01.europe.corp.microsoft.com>
A new feature slipped into 5.00.1, but it looks like the documentation
to go with it didn't get merged (probably my fault, sorry about that).
You can now load packages from the GHCi prompt, like so:
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 5.00.1, For Haskell
98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package std ... linking ... :done.
Prelude> :set -package lang
Loading package lang ... linking ... done.
Prelude> :set -package util
Loading package concurrent ... linking ... done.
Loading package posix ... linking ... done.
Loading package util ... linking ... done.
Prelude>=20
This means you can also load packages from .ghci files too.
Cheers,
Simon
From chak@cse.unsw.edu.au Sat May 26 13:53:43 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Sat, 26 May 2001 22:53:43 +1000
Subject: ghc-5.00.1 is available
In-Reply-To: <68B95AA1648D1840AB0083CC63E57AD60F2323@red-msg-06.redmond.corp.microsoft.com>
References: <68B95AA1648D1840AB0083CC63E57AD60F2323@red-msg-06.redmond.corp.microsoft.com>
Message-ID: <20010526225343M.chak@cse.unsw.edu.au>
"Julian Seward (Intl Vendor)" wrote,
> The (Interactive) Glasgow Haskell Compiler -- version 5.00.1
> ==============================================================
>
> We are pleased to announce a new patchlevel release of the Glasgow
> Haskell Compiler (GHC), version 5.00.1.
There are rpm packages for x86 GNU/Linux now. For glibc 2.2
systems, build on RedHat 7.0, we have
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-5.00.1-1.i386.rpm
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-prof-5.00.1-1.i386.rpm
For RedHat 6.2, we have
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386-rh6.2/ghc-5.00.1-1.i386.rpm
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386-rh6.2/ghc-prof-5.00.1-1.i386.rpm
The matching source rpm is at
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/src/ghc-5.00.1-1.src.rpm
The RedHat 6.2 packages have been kindly contributed by Tom
Moertel.
Cheers,
Manuel
PS: The problems with the documentation in the 5.00 rpms
have been resolved (at least in the RH7.0 packages, I
didn't check the others).
From tom-list-glasgow-haskell-users@moertel.com Sat May 26 17:10:44 2001
From: tom-list-glasgow-haskell-users@moertel.com (Tom Moertel)
Date: Sat, 26 May 2001 12:10:44 -0400
Subject: ghc-5.00.1 is available
References: <68B95AA1648D1840AB0083CC63E57AD60F2323@red-msg-06.redmond.corp.microsoft.com> <20010526225343M.chak@cse.unsw.edu.au>
Message-ID: <3B0FD584.4D1FFF37@moertel.com>
"Manuel M. T. Chakravarty" wrote:
> [...]
> PS: The problems with the documentation in the 5.00 rpms
> have been resolved (at least in the RH7.0 packages, I
> didn't check the others).
The documentation in the Red Hat 6x package looks fine as well.
Cheers,
Tom
From jak97@doc.ic.ac.uk Sun May 27 19:24:12 2001
From: jak97@doc.ic.ac.uk (John Knottenbelt)
Date: Sun, 27 May 2001 19:24:12 +0100
Subject: Evacuated Object
Message-ID: <01052719241200.14101@buffy.home.net>
I'm experimenting with GHC (5.00.1) on RedHat Linux 7.1, it's foreign
function interface (using .hsc files) and the SDL graphics library (v1.2).
The curious thing is that the following code:
main = sdlInit [sdlVideo[
sdlQuit
can be loaded into GHCi and executed as many times as I like, however,
if I then carry on and edit the module containing main, and then perform a
reload (:r), I sometimes get an "EVACUATED object entered!" message and GHC
crashes on me:
TestGraphics> :r
Compiling TestGraphics ( TestGraphics.hs, interpreted )
Ok, modules loaded: TestGraphics, SDL, Rectangle, SDLEvents, SDLKeySyms,
ForeignUtil.
TestGraphics> main
EVACUATED object entered!
make: *** [interactive] Error 1
bash$
What does this error mean, and why is it only triggered when I perform a
reload in GHCi?
Sometimes the reload works fine, and other times I get a segmentation fault.
Thanks
John
From simonpj@microsoft.com Mon May 28 10:07:24 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Mon, 28 May 2001 02:07:24 -0700
Subject: Evacuated Object
Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72FB1@red-msg-09.redmond.corp.microsoft.com>
The error means that GHC's garbage collector has come
across something it doesn't understand.
It's either a bug in the GHC garbage collector, or in GHCi itself
(which plays fast and loose with types in one or two places) or in=20
something to do with the SDL graphics interface. =20
Bugs like this are really hard to find, unless we can reproduce them
here. Can you send us all the code?
Simon
| -----Original Message-----
| From: John Knottenbelt [mailto:jak97@doc.ic.ac.uk]=20
| Sent: 27 May 2001 19:24
| To: glasgow-haskell-users@haskell.org
| Subject: Evacuated Object
|=20
|=20
| I'm experimenting with GHC (5.00.1) on RedHat Linux 7.1, it's foreign=20
| function interface (using .hsc files) and the SDL graphics=20
| library (v1.2).=20
| The curious thing is that the following code:
|=20
| main =3D sdlInit [sdlVideo[
| sdlQuit
|=20
| can be loaded into GHCi and executed as many times as I like,=20
| however, if I then carry on and edit the module containing=20
| main, and then perform a=20
| reload (:r), I sometimes get an "EVACUATED object entered!"=20
| message and GHC=20
| crashes on me:
|=20
| TestGraphics> :r
| Compiling TestGraphics ( TestGraphics.hs, interpreted )
| Ok, modules loaded: TestGraphics, SDL, Rectangle, SDLEvents,=20
| SDLKeySyms,=20
| ForeignUtil.
| TestGraphics> main
| EVACUATED object entered!
| make: *** [interactive] Error 1
| bash$
|=20
| What does this error mean, and why is it only triggered when=20
| I perform a=20
| reload in GHCi?
|=20
| Sometimes the reload works fine, and other times I get a=20
| segmentation fault.
|=20
| Thanks
|=20
| John
|=20
| _______________________________________________
| Glasgow-haskell-users mailing list=20
| Glasgow-haskell-users@haskell.org=20
| http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users
|=20
From jak97@doc.ic.ac.uk Mon May 28 11:45:03 2001
From: jak97@doc.ic.ac.uk (John Knottenbelt)
Date: Mon, 28 May 2001 11:45:03 +0100
Subject: Evacuated Object
In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72FB1@red-msg-09.redmond.corp.microsoft.com>
References: <37DA476A2BC9F64C95379BF66BA26902D72FB1@red-msg-09.redmond.corp.microsoft.com>
Message-ID: <01052811450300.01581@buffy.home.net>
Thanks for having a look at this. The sourcecode is available from
http://www.doc.ic.ac.uk/~jak97/graphics.tgz
Please let me know if you have any difficulties building.
SDL is available from
http://www.libsdl.org
and SDL_image is available from
http://www.devolution.com/~slouken/SDL/projects/SDL_image/
Cheers
John
On Monday 28 May 2001 10:07 am, you wrote:
> The error means that GHC's garbage collector has come
> across something it doesn't understand.
>
> It's either a bug in the GHC garbage collector, or in GHCi itself
> (which plays fast and loose with types in one or two places) or in
> something to do with the SDL graphics interface.
>
> Bugs like this are really hard to find, unless we can reproduce them
> here. Can you send us all the code?
>
> Simon
From mechvel@math.botik.ru Tue May 29 09:44:42 2001
From: mechvel@math.botik.ru (S.D.Mechveliani)
Date: Tue, 29 May 2001 12:44:42 +0400
Subject: creating packages
Message-ID:
Who could, please, consult on the package setting in ghc-5.00.1
?
Let the project foo consist of the files /t/A.hs
/t/t1/B.hs,
B import A,
the user work in /u/ and exploit foo in compiling, linking
and interpreting.
Everything seems to work below, except `ghci -package'
and `ghc -c -package-name foo'
(ghc-5.00.1 compiled from source for Linux, i386-unknown).
What I do:
-------------------------------------------------
* apply ghc --make B;
* move all *.o *.hi files to /t/export/ ;
* command cd /t/export/
ar -q libHSfoo.a *.o (creating a library)
* create a file p.txt containing
Package {name = "foo",
import_dirs = ["/t/export" ],
source_dirs = [],
library_dirs = ["/t/export" ],
hs_libraries = ["HSfoo"],
extra_libraries = [],
include_dirs = [], c_includes = [],
package_deps = [], extra_ghc_opts = [],
extra_cc_opts = [], extra_ld_opts = []
}
and apply ghc-pkg -a < p.txt
adding a package foo to ghc.
-------------------------------------------------
Then, for the user module /u/Main.hs
importing B,
the user commands cd /u; ghc -c -package foo Main.hs
ghc -o run Main.o -package foo
- and it works.
But ghci -package foo
yields
Loading package foo ... can't find .o or .so/.DLL for: HSfoo
(libHSfoo.so: cannot open shared object file: No such file or directory)
Then, I added /t/export/libHSdocon.so,
but it does not help.
Also ghc -c -package-name foo C.hs
does not work.
May ghc -c -package-name
do automatically all this mess with moving .o, .hi files and
archivating?
Thank you in advance for the help.
-----------------
Serge Mechveliani
mechvel@botik.ru
From trb@eastpac.com.au Tue May 29 11:11:47 2001
From: trb@eastpac.com.au (trb@eastpac.com.au)
Date: Tue, 29 May 2001 20:11:47 +1000 (EST)
Subject: building Green Card using ghc-5
Message-ID:
I finally got Green Card 2.01 to build with ghc-5.00 .
There are two changes required:
* replace all uses of -syslib with -package in src/Makefile
* remove src/Pretty.lhs src/FiniteMap.lhs and src/GetOpt.lhs
- the latter (redundant) source files upset ghc when it tries to import the same
modules from packages.
Tim
From trb@eastpac.com.au Tue May 29 12:13:16 2001
From: trb@eastpac.com.au (trb@eastpac.com.au)
Date: Tue, 29 May 2001 21:13:16 +1000 (EST)
Subject: building Green Card using ghc-5 continued
Message-ID:
Oops - there is one more change needed:
add -package lang to HC_OPTS in lib/ghc/Makefile
I have not tried using it with Hugs.
Tim
From simonmar@microsoft.com Tue May 29 11:17:43 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Tue, 29 May 2001 11:17:43 +0100
Subject: creating packages
Message-ID: <9584A4A864BD8548932F2F88EB30D1C61158A4@TVP-MSG-01.europe.corp.microsoft.com>
> Who could, please, consult on the package setting in ghc-5.00.1
> ?
> Let the project foo consist of the files /t/A.hs
> /t/t1/B.hs,
> B import A,
> the user work in /u/ and exploit foo in compiling, linking
> and interpreting.
>=20
> Everything seems to work below, except `ghci -package'=20
> and `ghc -c -package-name foo'
>=20
> (ghc-5.00.1 compiled from source for Linux, i386-unknown).=20
> What I do:
>=20
> -------------------------------------------------
> * apply ghc --make B;
That should be=20
=09
ghc -package-name foo --make B.
because you're building modules for package 'foo'.
> * move all *.o *.hi files to /t/export/ ;
> * command cd /t/export/
> ar -q libHSfoo.a *.o (creating a library)
>=20
> * create a file p.txt containing
>=20
> Package {name =3D "foo",
> import_dirs =3D ["/t/export" ],
> source_dirs =3D [],
> library_dirs =3D ["/t/export" ],
> hs_libraries =3D ["HSfoo"],
> extra_libraries =3D [],
> include_dirs =3D [], c_includes =3D [],
> package_deps =3D [], extra_ghc_opts =3D [],
> extra_cc_opts =3D [], extra_ld_opts =3D []
> }
> and apply ghc-pkg -a < p.txt
> adding a package foo to ghc.
> -------------------------------------------------
>=20
> Then, for the user module /u/Main.hs
> importing B,
> the user commands cd /u; ghc -c -package foo Main.hs
> ghc -o run Main.o -package foo
> - and it works.
> But ghci -package foo
> yields
> Loading package foo ... can't find .o or .so/.DLL for: HSfoo=20
> (libHSfoo.so: cannot open shared object file: No such file=20
> or directory)
GHCi can't load .a files (at the moment). You can build a .o file from
a .a file like so (with GNU ld):
ld --whole-archive libHSfoo.a -o libHSfoo.o
Cheers,
Simon
From electrorb@yahoo.com Wed May 30 05:08:53 2001
From: electrorb@yahoo.com (hooh pxw)
Date: Tue, 29 May 2001 21:08:53 -0700 (PDT)
Subject: ghc-5.00.1 compiling with pw32 for win32.
Message-ID: <20010530040853.51180.qmail@web10005.mail.yahoo.com>
Hi, i am new comer/bie.
--*PW32 the Posix-over-Win32 layer*--
http://sourceforge.net/projects/pw32
PW32 is primarily C runtime library for Win32 aiming
to POSIX compliance. Its main concerns are effeciency
and support even for low-end Win9x systems. Also, PW32
is collection of ported software, aiming to be GNU
(etc.) distribution for Win32. LGPL.
i have no time to test. if this work, tell me.
sorry my lazy cut/paste.
global funny thing? no *.hi file errors.
ignore below message...
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
From mechvel@math.botik.ru Wed May 30 13:00:58 2001
From: mechvel@math.botik.ru (S.D.Mechveliani)
Date: Wed, 30 May 2001 16:00:58 +0400
Subject: package for ghci
Message-ID:
To my questions on the package creation for ghci -package
>> ...
>> How should look a package for this?
Simon Marlow writes
> The "package" consists of libraries, .hi files, and a package
> specification. Which bit did you mean?
I meant all the three + a whole story of its correct arrangement -
to illustrate it on the given example of a single module project.
But as you said, my scheme of action in mainly correct.
So, let us go further.
>> Is it created manually or by ghc -package-name ... ?
>> ...
>> For I have an impression that the ghc-5.00 User's guide cannot
>> help in this situation.
> The user's guide says, about -package-name:
>
> This option is added to the command line when compiling a
> module that is destined to be part of package foo. If this
> flag is omitted then the default package Main is assumed.
>
> seems fairly clear to me... which part are you confused about?
I expected that the user would not need to
(1) move .hi, .o files manually to /t/export,
collecting them from all the project directories
(2) archivate manually *.o to .a library,
(maybe) (3) create manually the structure Package {...}.
Note that the application project forces the user to do all this
manually to install the project.
I hoped -package-name --make
would do (1) and (2).
This fragment of User's Guide does not reject such hope.
> Which parts of the documentation aren't being helpful to you?
> [..]
It looks that a newbie would not find out the needed order of
action:
1. package specification, 2. ghc-pkg ... 3. ghc --make ...,
4. moving files and archivating to library.
Does the Guide specify such order?
Is it clear from the Guide which of these points can be done
automatically?
Where it is explained how to create a library .a from *.o ?
A naive functional programmer would not know this, maybe, this is
a system hacker's territory (?).
I may mistake, this is only my impression.
>> Then, after creating manually /t/export/libHSfoo.a
>> and converting it by
>> ld -r --whole-archive libHSfoo.a -o libHSfoo.o
>> [..]
>>
>> it still does not work. ghci -package foo
>> yields
>> Loading package foo ... can't find .o or .so/.DLL for: HSfoo
>> (libHSfoo.so: cannot open shared object file: No such file
> It looks like there may be a problem with your package spec.
> Could you list the contents of p.txt that you used to create the
> package?
I would reproduce the whole (short) story.
-------------------------------------------------------
/home/mechvel/t/A.hs
contains module A where a = 'a'
and is one file project to build a package foo
to reside in the directory
/home/mechvel/t/export/
/home/mechvel/u/Main.hs
imitates the user work with the package foo. It contains
module Main where import A
main = putStr ['b', a, '\n']
1. Apply ghc-pkg -a < p.txt
with p.txt containing
Package {name = "foo",
import_dirs = ["/home/mechvel/t/export" ],
source_dirs = [],
library_dirs = ["/home/mechvel/t/export" ],
hs_libraries = ["HSfoo"],
extra_libraries = ["HSfoo"],
include_dirs = [], c_includes = [],
package_deps = [], extra_ghc_opts = [],
extra_cc_opts = [], extra_ld_opts = []
}
2. Test it with ghc-pkg -l
3. cd ~/t
ghc -package-name foo --make A
4. mv *.hi *.o export/
cd export
5. ar -q libHSfoo.a *.o
ld -r --whole-archive libHSdocon.a -o libHSdocon.o
-----------------------------------------------------------
cd ~/t
ghci -package foo
...
Loading package std ... linking ... done.
Loading package foo ... ghc-5.00.1: can't find .o or .so/.DLL for:
HSfoo (libHSfoo.so: cannot open shared object file:
No such file or directory)
Regards,
-----------------
Serge Mechveliani
mechvel@botik.ru
From simonmar@microsoft.com Wed May 30 14:22:44 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Wed, 30 May 2001 14:22:44 +0100
Subject: Evacuated Object
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD72F@TVP-MSG-01.europe.corp.microsoft.com>
> I'm experimenting with GHC (5.00.1) on RedHat Linux 7.1, it's foreign=20
> function interface (using .hsc files) and the SDL graphics=20
> library (v1.2).=20
> The curious thing is that the following code:
>=20
> main =3D sdlInit [sdlVideo[
> sdlQuit
>=20
> can be loaded into GHCi and executed as many times as I like, however,
> if I then carry on and edit the module containing main, and=20
> then perform a=20
> reload (:r), I sometimes get an "EVACUATED object entered!"=20
> message and GHC=20
> crashes on me:
Great bug! I managed to reproduce it here (except that I get a plain
seg fault not a GC panic), and it turns out to be an obscure bug in the
native code generator that only shows up with GHCi. Compiling the
program with -fvia-C works around it.
Many thanks for the report.
Cheers,
Simon
From simonmar@microsoft.com Wed May 30 14:01:21 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Wed, 30 May 2001 14:01:21 +0100
Subject: package for ghci
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD72C@TVP-MSG-01.europe.corp.microsoft.com>
> 5. ar -q libHSfoo.a *.o
> ld -r --whole-archive libHSdocon.a -o libHSdocon.o
Here's your problem: you named the output libHSdocon.o, but GHCi is
looking for HSfoo.o (because that's the name you gave in the package
spec).
True, the documentation doesn't give explicit instructions for building
a package from start to finish. I'll add something for a future
release.
Cheers,
Simon
From reid@cs.utah.edu Wed May 30 21:29:32 2001
From: reid@cs.utah.edu (Alastair David Reid)
Date: 30 May 2001 14:29:32 -0600
Subject: Poll: System.exitWith behaviour
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611588D@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C611588D@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID:
"Simon Marlow" writes:
> One high-priority problem we also have is that a program which calls
> System.exitWith from inside GHCi will shut down the whole system.
> [...]
> we currently don't implement any kind of process hierarchy, and
> there is no requirement for child threads to complete before the
> program exits, for example.
The approach we've taken here in Utah (in the context of Java
operating systems) is to apply the following (standard) distinction
between threads and processes:
o Threads provide multiple concurrent streams of execution (and nothing
else).
Threads are not strongly isolated from each other so killing
a thread can fatally wound another thread, redirecting stdout
will affect other threads, etc.
o Processes are sets of threads which are isolated from each other.
In particular, you can kill one process without affecting the
integrity of other processes and you can redirect stdout in one
process independently of other processes.
Processes are usually implemented using memory protection and often
implies separate address spaces in OSs like Unix and Windows but, in
the OS research community, that is viewed as an implementation
technique rather than being part of the definition. (For example,
there are a number of single address space operating systems (SASOS)
and early JavaOSs tried to use strong typechecking in place of
memory protection.)
[Isolation may mean different things in different systems. For
example, you might want to enforce some resource limits to protect
processes against memory, cpu or bandwidth hogs.]
Translating this into the GHCi situation, it seems that you want to
treat GHCi and the user's program as two separate processes and we can
imagine that anyone else writing an interpreter in Haskell would want
to do so too. (e.g., it might be a useful way of structuring my
graphics library too).
When you come to implement this model, another useful concept from
operating systems is the notion of a "red line". This is the border
between "untrusted" user code and "trusted" system code. In a
conventional OS, this line is the user-kernel boundary and is
implemented using system calls, hardware traps, file descriptor
tables, etc. but the concept is useful even if it is implemented using
a combination of type safety, careful programming and exception
handlers. In the current system, most of the IO library should lie
beneath the red line. If a notion of process were added, then some
parts of process creation/killing, running of finalizers, locking,
etc. would lie beneath the red line. The value of this concept is:
1) Having a word for it.
2) As long as you have a clear statement of what level of "isolation"
you want to achieve, you have a clear definition of what you have
to protect against when you cross the red line. This is useful for
answering questions like: Is it enough to add an exception handler?
Should you add a timeout mechanism too? What resources have to be
revocable? What resources need an extra layer of indirection so
that you can implement different namespaces (e.g., file descriptors
in Unix allow different processes to define stdout differently)
Godmar Back (http://www.cs.utah.edu/~gback/) has explored this in
detail (it will form part of his forthcoming PhD thesis):
http://www.cs.utah.edu/flux/papers/redline-hotos7-base.html
http://www.cs.utah.edu/flux/papers/kaffeos-osdi00-base.html
Matthew Flatt (http://www.cs.utah.edu/~mflatt/) has encountered
similar issues in MrEd/DrScheme/MzScheme (which is more or less GHCi
for Scheme):
http://www.cs.rice.edu/CS/PLT/Publications/icfp99-ffkf.pdf
Godmar emphasises the OS side of things whereas Matthew comes at the
same issues from a language point of view.
--
Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
From mechvel@math.botik.ru Thu May 31 06:59:59 2001
From: mechvel@math.botik.ru (S.D.Mechveliani)
Date: Thu, 31 May 2001 09:59:59 +0400
Subject: package for ghci
Message-ID:
To my question on packages for ghci
Simon Marlow responds
>> 5. ar -q libHSfoo.a *.o
>> ld -r --whole-archive libHSdocon.a -o libHSdocon.o
> Here's your problem: you named the output libHSdocon.o, but GHCi is
> looking for HSfoo.o (because that's the name you gave in the package
> spec).
>
> ld -r --whole-archive libHSfoo.a -o libHSfoo.o
>
> [..]
Thank you.
The matter was indeed in the name.
And it was due to the `lib' prefix, not due to `docon'.
Because there was a typo in my letter:
...--whole-archive libHSfdocon.a ...
while in real experiment it was ...--whole-archive libHSfoo.a ...
And I doubt whether the GHC implementation agrees at this point with
the GHC User's guide. Section 4.11.2 says
----------------------------------------------
A package specification looks like this:
Package {name = "mypkg"
hs_libraries = ["HSmypkg"]
...
}
...
hs_libraries
A list of libraries containing Haskell code for this package,
with the .a or .dll suffix omitted.
On Unix, the `lib' prefix is also omitted.
extra_libraries ...
----------------------------------------------
The user (myself) thinks at this:
"HSmypkg" in package specification --> HSmypkg.a
HSmypkg.o
in the library directory.
But " `lib' is also omitted " - similarly as `.a'.
Hence, the library directory should contain
libHSmypkg.a libHSmypkg.o
Now, ghci -package-mypkg
sees "HSmypkg" in package specification but searches for the file
HSmypkg.o.
It adds `.o', but skips `lib'.
On the other hand, `.o' has different status, it is separated by
period. So I wonder.
Regards,
-----------------
Serge Mechveliani
mechvel@botik.ru
From D.Evers@artemis-pharmaceuticals.de Thu May 31 08:45:48 2001
From: D.Evers@artemis-pharmaceuticals.de (Dirk Evers)
Date: Thu, 31 May 2001 09:45:48 +0200
Subject: package for ghci
In-Reply-To:
Message-ID:
Hi,
(second time: Outlook tricked me: wrong email address
I really love this mailer. :-( )
The lib prefix convention is only for .a and .so files,
.o files do not fall under this convention, so:
ld -r --whole-archive libHSfoo.a -o HSfoo.o
is what should work for you.
Cheers
Dirk
> -----Original Message-----
> From: glasgow-haskell-users-admin@haskell.org
> [mailto:glasgow-haskell-users-admin@haskell.org]On Behalf Of
> S.D.Mechveliani
> Sent: Thursday, May 31, 2001 8:00 AM
> To: glasgow-haskell-users@haskell.org
> Cc: simonmar@microsoft.com
> Subject: package for ghci
>=20
>=20
> To my question on packages for ghci
> Simon Marlow responds
>=20
> >> 5. ar -q libHSfoo.a *.o
> >> ld -r --whole-archive libHSdocon.a -o libHSdocon.o
>=20
> > Here's your problem: you named the output libHSdocon.o, but GHCi is
> > looking for HSfoo.o (because that's the name you gave in the package
> > spec).
> >
> > ld -r --whole-archive libHSfoo.a -o libHSfoo.o
> >=20
> > [..]
>=20
>=20
> Thank you.=20
> The matter was indeed in the name.
> And it was due to the `lib' prefix, not due to `docon'.
>=20
> Because there was a typo in my letter:=20
> ...--whole-archive libHSfdocon.a ...
> while in real experiment it was ...--whole-archive libHSfoo.a ...
>=20
> And I doubt whether the GHC implementation agrees at this point with=20
> the GHC User's guide. Section 4.11.2 says
>=20
> ----------------------------------------------
> A package specification looks like this:
>=20
> Package {name =3D "mypkg"
> hs_libraries =3D ["HSmypkg"]
> ...
> }
> ...
> hs_libraries
> A list of libraries containing Haskell code for this package,
> with the .a or .dll suffix omitted.
> On Unix, the `lib' prefix is also omitted.
>=20
> extra_libraries ...=20
> ----------------------------------------------
>=20
> The user (myself) thinks at this:
> "HSmypkg" in package specification --> HSmypkg.a
> HSmypkg.o
> in the library directory.
>=20
> But " `lib' is also omitted " - similarly as `.a'.
> Hence, the library directory should contain
> libHSmypkg.a libHSmypkg.o
> Now, ghci -package-mypkg =20
>=20
> sees "HSmypkg" in package specification but searches for the file =20
> HSmypkg.o. =20
> It adds `.o', but skips `lib'.
> On the other hand, `.o' has different status, it is separated by
> period. So I wonder.
>=20
> Regards,
>=20
> -----------------
> Serge Mechveliani
> mechvel@botik.ru
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
From mechvel@math.botik.ru Thu May 31 09:31:39 2001
From: mechvel@math.botik.ru (S.D.Mechveliani)
Date: Thu, 31 May 2001 12:31:39 +0400
Subject: extending --make
Message-ID:
Hello,
I have a whish for the GHC `making' possibilities.
ghc-5* -package-name --make
is said trying to replace Makefile. But it is half-successful.
* First, it needs -ohi option working
(to move .hi -s to chosen directory).
* Second, could GHC provide options for creating libraries,
adding to library?
Explanation.
With ghc-4, I used Makefile and -odir, -ohi options to provide
the project installation.
Makefile contained
(1)
the project directory tree description,
variables holding the list of names for the .hs, .hi, .o files,
rules to convert .hs --> .o, and such.
Also it contained the library creation part:
(2)
foo: $(objectFiles)
ar -q export/libHSfoo.a `ls export/*.o`
ranlib export/libHSfoo.a
rm -f `ls export/*.o`
-------------------
Now, with ghc-5, I apply
ghc -package-name foo -odir export ... --make ..
The part (1) cancels due to --make.
Further, as ghc-5 observes in the package specification
library_dirs = [".../export"]
hs_libraries = ["libHSfoo"],
then, it can understand what library file is to be created - on
demand.
If ghc -c provided also the options like -addto-lib -a,
-addto-lib -o,
...
then it could `make' for the given package _with_ adding to
library. So, GHC would be able to simplify Makefile to package
setting.
The matter is that Makefile has a strange language, far from
Haskell. Also why the Haskell user has to study library creation
with `ar', `ranlib, `ld'? This, and Makefile look rather like a
system hackering.
Regards,
-----------------
Serge Mechveliani
mechvel@botik.ru
From simonmar@microsoft.com Thu May 31 11:10:55 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Thu, 31 May 2001 11:10:55 +0100
Subject: package for ghci
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD736@TVP-MSG-01.europe.corp.microsoft.com>
> The user (myself) thinks at this:
> "HSmypkg" in package specification --> HSmypkg.a
> HSmypkg.o
> in the library directory.
I've clarified this in the documentation, thanks for the comments.
Cheers,
Simon
From simonmar@microsoft.com Thu May 31 13:53:41 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Thu, 31 May 2001 13:53:41 +0100
Subject: extending --make
Message-ID: <9584A4A864BD8548932F2F88EB30D1C61158AD@TVP-MSG-01.europe.corp.microsoft.com>
> I have a whish for the GHC `making' possibilities.
>=20
> ghc-5* -package-name --make=20
>=20
> is said trying to replace Makefile. But it is half-successful.
> * First, it needs -ohi option working=20
> (to move .hi -s to chosen directory).
I've added a -hidir option which should do the right thing.
> * Second, could GHC provide options for creating libraries,=20
> adding to library?
This might make it easier to build a library from Haskell files, but it
would also be duplicating functionality that is already available. I
don't see it as a priority, I'm afraid.
> Explanation.
> With ghc-4, I used Makefile and -odir, -ohi options to provide
> the project installation.=20
> Makefile contained=20
> (1)
> the project directory tree description,
> variables holding the list of names for the .hs, .hi, .o files,=20
> rules to convert .hs --> .o, and such.
> Also it contained the library creation part:
> (2)
> foo: $(objectFiles)
> ar -q export/libHSfoo.a `ls export/*.o`
> ranlib export/libHSfoo.a
> rm -f `ls export/*.o`
So you can use the same makefile, but you can replace part (1) with a
single rule which uses --make.
Cheers,
Simon
From Dominic.J.Steinitz@BritishAirways.com Thu May 31 15:18:09 2001
From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J)
Date: 31 May 2001 14:18:09 Z
Subject: Socket Behaviour
Message-ID: <"074D83B1652A100D*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
Can anyone tell me why the following code doesn't work as expected? Both the server and client hang. If I run
server 20000 &
and
client 20000
the server logfile produces
[dom@lhrtba8fd85 twotest]$ more log.txt
Thu May 31 14:35:39 BST 2001
Starting logging
Thu May 31 14:36:08 BST 2001
Hello world 48 65 6c 6c 6f 20 77 6f 72 6c 64
so it looks like the hPutStrLn to the socket never completes. On the client side, "Hello world" gets sent but the hGetLine never completes.
Client
do sh <- connectTo host port
hPutStr sh "Hello world"
hFlush sh
x <- hGetLine sh
putStrLn x
Server
socket <- listenOn port
(sh,host,portid) <- accept socket
let loop = do b <- getBuffer sh 16
case b of
Full msg ->
do logMessage ofh (hexedMessage msg)
loop
Partial msg ->
do logMessage ofh (hexedMessage msg)
hPutStrLn sh "Finishing Logging"
hFlush sh
logMessage ofh "Finishing logging"
hClose ofh
in loop
Dominic.
Here's the full code:
module Main (main) where
import System
import IO
import Time
import Socket
import Char
main :: IO ()
main = do prog <- getProgName
args <- getArgs
if (length args /= 1)
then do putStrLn ("Use: " ++ prog ++ " ")
exitWith (ExitFailure (-1))
else return ()
let port = read (args !! 0) :: Int in
server (PortNumber (mkPortNumber port))
-- The server function creates a socket to listen on the port and
-- loops to log messages.
server :: PortID -> IO ()
server port =
do ofh <- openFile "log.txt" WriteMode
logMessage ofh "Starting logging"
socket <- listenOn port
(sh,host,portid) <- accept socket
let loop = do b <- getBuffer sh 16
case b of
Full msg ->
do logMessage ofh (hexedMessage msg)
loop
Partial msg ->
do logMessage ofh (hexedMessage msg)
hPutStrLn sh "Finishing Logging"
hFlush sh
logMessage ofh "Finishing logging"
hClose ofh
in loop
data Buffer = Full String | Partial String
getBuffer :: Handle -> Int -> IO Buffer
getBuffer h n =
if (n <= 0)
then return (Full "")
else do x <- try (hGetChar h)
case x of
Right c ->
do xs <- getBuffer h (n-1)
case xs of
Full cs -> return (Full (c:cs))
Partial cs -> return (Partial (c:cs))
Left e -> if isEOFError e
then return (Partial "")
else ioError e
logMessage :: Handle -> String -> IO ()
logMessage hd msg =
do clock <- getClockTime
calendar <- toCalendarTime clock
hPutStrLn hd ((calendarTimeToString calendar) ++ "\n" ++ msg)
hFlush hd
showHex :: Char -> String
showHex x =
let y = ord x in
hexDigit (y `div` 16):hexDigit (y `mod` 16):[]
hexDigit :: Int -> Char
hexDigit x
| (0 <= x) && (x <= 9) = chr(ord '0' + x)
| (10 <= x) && (x <=16) = chr(ord 'a' + (x-10))
| otherwise = error "Outside hexadecimal range"
hexedMessage :: String -> String
hexedMessage msg =
(map toPrint msg) ++ " " ++ unwords (map showHex msg)
toPrint :: Char -> Char
toPrint x =
if ((isAscii x) && (not (isControl x)))
then x
else '.'
module Main(main) where
import System
import IO
import Socket
main :: IO ()
main = do prog <- getProgName
args <- getArgs
if (length args /= 2)
then do putStrLn ("Use: " ++ prog ++ " ")
exitWith (ExitFailure (-1))
else return ()
let host = args !! 0
port = read (args !! 1) :: Int in
client host (PortNumber (mkPortNumber port))
client :: Hostname -> PortID -> IO ()
client host port =
do sh <- connectTo host port
hPutStr sh "Hello world"
hFlush sh
x <- hGetLine sh
putStrLn x
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
From mechvel@math.botik.ru Wed May 2 08:29:38 2001
From: mechvel@math.botik.ru (S.D.Mechveliani)
Date: Wed, 02 May 2001 11:29:38 +0400
Subject: ghci, -O
Message-ID:
I fear there is certain misunderstanding about -O usage with
ghc-5.00 interactive.
Simon Marlow and User's Guide (Section 4.4) say that
> -O does not work with ghci.
> For technical reason, the bytecode compiler doesn't interact
> well with one of the optimization passes
> [..]
What is a bytecode compiler?
The one that prepares a lightly compiled code for the interpreter?
What I meant is something like this:
to compile ghc -c -O Foo.hs
in the batch mode and then run ghci
...
Preude> :load Foo
...
Foo> sm [1..9999000]
I tried this with certain small function Foo.sm, and it works,
and runs better than when compied with -Onot.
Now, as I see that ghci can load and run the code made by -O,
I wonder what the User's Guide means by saying
"-O does not work with GHCi". Maybe ghci -O ?
could be meaningful?
-----------------
Serge Mechveliani
mechvel@botik.ru
From joe@isun.informatik.uni-leipzig.de Wed May 2 10:28:00 2001
From: joe@isun.informatik.uni-leipzig.de (Johannes Waldmann)
Date: Wed, 2 May 2001 11:28:00 +0200 (MET DST)
Subject: catchAllIO
Message-ID: <200105020928.LAA25808@isun11.informatik.uni-leipzig.de>
Dear all, I keep getting problems with expections. In the example
catchAllIO ( action ) $ \ any -> return "foo"
is it guaranteed that *no* exception that is raised in `action'
propagates to the outside?
(This is with ghc-4.08. Should I upgrade? Well, I will upgrade
sometime anyway, but would it help with respect to this problem?)
Regards,
--
-- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ --
-- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --
From joe@isun.informatik.uni-leipzig.de Wed May 2 13:21:05 2001
From: joe@isun.informatik.uni-leipzig.de (Johannes Waldmann)
Date: Wed, 2 May 2001 14:21:05 +0200 (MET DST)
Subject: Exceptions and sockets
Message-ID: <200105021221.OAA29392@isun11.informatik.uni-leipzig.de>
OK now I upgraded to ghc-5.00 but the situation didn't change.
My suspicion is that it's not the fault of `catch'.
I think what happens is this:
I `Socket.accept' a connection and get a handle.
Now, if the connections dies, but I still write to the handle,
the whole thing crashes - without throwing an exception.
(I checked that the RTS thinks `hIsWritable h'
even if `h' does no longer exist in reality.)
How could I work around this? SocketPrim?
--
-- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ --
-- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/252 --
From stolz@I2.Informatik.RWTH-Aachen.DE Wed May 2 14:40:37 2001
From: stolz@I2.Informatik.RWTH-Aachen.DE (Volker Stolz)
Date: Wed, 2 May 2001 15:40:37 +0200
Subject: Exceptions and sockets
In-Reply-To: <200105021221.OAA29392@isun11.informatik.uni-leipzig.de>
References: <200105021221.OAA29392@isun11.informatik.uni-leipzig.de>
Message-ID: <20010502154037.A12420@i2.informatik.rwth-aachen.de>
In local.glasgow-haskell-users, you wrote:
>I `Socket.accept' a connection and get a handle.
>Now, if the connections dies, but I still write to the handle,
>the whole thing crashes - without throwing an exception.
>(I checked that the RTS thinks `hIsWritable h'
>even if `h' does no longer exist in reality.)
Looks to me like you're forgetting that the OS will give you a
sigPIPE on (semi-)closed sockets, which translates to a segfault
unless you install a signal handler:
- http://www.haskell.org/ghc/docs/latest/set/socket.html#AEN13989
- socket(2)
--
Abstrakte Syntaxträume.
Volker Stolz * stolz@i2.informatik.rwth-aachen.de * PGP + S/MIME
From simonmar@microsoft.com Wed May 2 16:21:01 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Wed, 2 May 2001 16:21:01 +0100
Subject: ghci, -O
Message-ID: <9584A4A864BD8548932F2F88EB30D1C60171F64A@TVP-MSG-01.europe.corp.microsoft.com>
> Now, as I see that ghci can load and run the code made by -O,
> I wonder what the User's Guide means by saying=20
> "-O does not work with GHCi". Maybe ghci -O ?
> could be meaningful?
"ghci -O" is exactly the combination that doesn't work.
Cheers,
Simon
From simonmar@microsoft.com Wed May 2 17:28:50 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Wed, 2 May 2001 17:28:50 +0100
Subject: catchAllIO
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6115868@TVP-MSG-01.europe.corp.microsoft.com>
> Dear all, I keep getting problems with expections. In the example
>=20
> catchAllIO ( action ) $ \ any -> return "foo"
>=20
> is it guaranteed that *no* exception that is raised in `action'=20
> propagates to the outside?
Yes.
> (This is with ghc-4.08. Should I upgrade? Well, I will upgrade
> sometime anyway, but would it help with respect to this problem?)
In GHC 5.00, 'catchAllIO' is now called 'Exception.catch', and the
IOError and Exception types are now isomorphic. Various other functions
in the Exception library have had names changes too.
Cheers,
Simon
From pasch@netzGeneration.com Wed May 2 23:02:01 2001
From: pasch@netzGeneration.com (Thomas Pasch)
Date: Thu, 03 May 2001 00:02:01 +0200
Subject: GHC and the Lazy Functional State Threads Paper
Message-ID: <3AF083D9.A06AFBDE@netzGeneration.com>
> So you can fix it for example by using a specialized version of
> freezeArr inside accumArray, of type
> (Ix i, IArray a e) => STArray s i e -> ST s (a i e)
> This will give quite general type of accumArray: arbitrary immutable
> array from the IArray class.
freezeArr2:: (Ix i, IArray.IArray a e) => STArray s i e -> ST s (a i e)
freezeArr2 = MArray.freeze
> If the immutable array type used was particularly UArray, it would
> be more efficient to use the corresponding STUArray instead of
> STArray, so freezing could just copy a memory block (there are magic
> specializations in ghc's libraries for such case). But if the element
> type was to remain generic, the type would have to be constrained
> over STUArray
freezeArr3::
(Ix i, MArray.MArray (MArray.STUArray s) e (ST s), IArray.IArray a e)
=> (MArray.STUArray s i e) -> ST s (a i e)
freezeArr3 = MArray.freeze
Is this the way to do it? I wonder a bit if this triggers the
optimization if 'a' is of type STUArray. (By the way I still have
problems to see where unboxed values are a good thing and were
you should better avoid them.)
In addition I wonder why there are so many array types. Are both
STArray and IOArray really necessary and what's the difference
between them? What about DiffArray? I'm still surprised by operations
like 'unsafeFreezeArray' and 'freezeArray'. Shouldn't the
garbage collector juge if there are still other references
to a distinct object?
Regards,
Thomas
From pasch@netzGeneration.com Wed May 2 23:07:26 2001
From: pasch@netzGeneration.com (Thomas Pasch)
Date: Thu, 03 May 2001 00:07:26 +0200
Subject: Linking vs. shared libs on Unix
Message-ID: <3AF0851E.CF9CD37B@netzGeneration.com>
Hello,
In the windows version of ghc,
there seems to be the possiblity to compile
the libraries as shared 'dll's. Is the
same possible for the unix version?
The question is because I think the ghc
executables are really blown up. A simple
'Hello, world' has 172 kBytes (358k unstripped)
and the hello example of the GTK+ bindings
is as big as 854 kBytes (2.2 MBytes unstripped),
although it is link dynamically against:
> ldd hello
libgthread-1.2.so.0 => /usr/lib/libgthread-1.2.so.0 (0x40025000)
libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x40028000)
libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x40155000)
libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x4018a000)
libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x4018d000)
libdl.so.2 => /lib/libdl.so.2 (0x401b1000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x401b4000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x401bc000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x401cb000)
libm.so.6 => /lib/libm.so.6 (0x402ae000)
libgmp.so.3 => /usr/lib/libgmp.so.3 (0x402cc000)
libc.so.6 => /lib/libc.so.6 (0x402ed000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40400000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Best regards,
Thomas
From qrczak@knm.org.pl Thu May 3 11:55:26 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 3 May 2001 10:55:26 GMT
Subject: GHC and the Lazy Functional State Threads Paper
References: <3AF083D9.A06AFBDE@netzGeneration.com>
Message-ID:
Thu, 03 May 2001 00:02:01 +0200, Thomas Pasch pisze:
>> If the immutable array type used was particularly UArray, it would
>> be more efficient to use the corresponding STUArray instead of
> freezeArr3::
> (Ix i, MArray.MArray (MArray.STUArray s) e (ST s), IArray.IArray a e)
> => (MArray.STUArray s i e) -> ST s (a i e)
> freezeArr3 = MArray.freeze
>
> Is this the way to do it?
Well, yes, although when the immutable array happens to *not* be
UArray (but e.g. Array), it can be less efficient than with STArray,
because elements must be reboxed. And it's less general (the element
type must be "unboxable").
This is why I would use STUArray when it is known that the immutable
array is UArray and nothing else, and STArray in other cases.
> I wonder a bit if this triggers the optimization if 'a' is of
> type STUArray.
UArray. It does when it's statically determined that 'a' is of type
UArray. It doesn't when a function using freeze is so large that
it's not compiled inline and it's not specialized, so the compiler
uses a single generic version in a code compiled out of line. This
optimization is implented as rewrite rule:
freeze:: (Ix i, MArray a e m, IArray b e) => a i e -> m (b i e)
-- Generically implemented in terms of overloaded element access
-- and array construction.
freezeSTUArray:: Ix i => STUArray s i e -> ST s (UArray i e)
-- Uses memcpy.
{-# RULES
"freeze/STUArray" freeze = freezeSTUArray
-- The compiler can replace freeze with freezeSTUArray where types
-- match (if optimization is turned on).
#-}
There is no automatic way of choosing the "best" mutable array type
"corresponding" to the given immutable type. Formally there is no
correspondence here (except that there are some rules for freezing
and thawing for specific combinations of types).
Efficiency of bulk array operations improved since released ghc-5.00:
I eliminated many unnecessary bounds checking, at the cost of turning
IArray and MArray methods into functions (so custom instances of
these classes no longer work - they must define different methods).
> (By the way I still have problems to see where unboxed values are
> a good thing and were you should better avoid them.)
If there could be a universal answer, probably the compiler could do
this automatically all the times :-)
Operations like arithmetic on boxed values are implemented as unboxing,
performing the operation and reboxing. So unboxed values are generally
faster than unboxed values - except that when we perform no operations
at all and just copy values from one place to another (like in freezing
a mutable array), it's cheaper to pass boxed values unmodified than
to unbox or box them.
The compiler is able to optimize away boxing in many cases, e.g.
usually in passing values as arguments to strict functions and
returning results. But it is not able to automatically optimize it
when values are stored in data structures (unless the data structure
itself is optimized away! this sometimes happend to lists), and it's
not able to unbox values of unknown types (so it helps to inline or
specialize critical functions - this sometimes happens automatically).
In any case you can watch what is happening instead of guessing.
There are options which tell ghc to dump intermediate forms of the
program, in not so pretty format (because it's internal: the textual
presentation is defined only for the purpose of dumping). I learned
what ghc is doing from watching the dumps much more than from reading
its source. Some interesting dumps:
ghc -c -no-recomp -O File.hs -ddump-stg
-ddump-realC
-fasm -ddump-asm
> In addition I wonder why there are so many array types. Are both
> STArray and IOArray really necessary and what's the difference
> between them?
Operations on STArray can be safely wrapped in a pure computation
using runST.
Operations on IOArray can be easily mixed with other IO operations.
Embedding them in a pure computation is still possible using
unsafePerformIO, but it's unsafe and slightly less efficient.
You can convert between ST and IO computations using stToIO and
unsafeIOtoST.
> What about DiffArray?
It has immutable interface but computes '//' without copying the
whole array as long as it's used in a single-threaded way. OTOH it has
larger constant overheads than Array (because of more magic inside,
more indirections).
> I'm still surprised by operations like 'unsafeFreezeArray' and
> 'freezeArray'. Shouldn't the garbage collector juge if there are
> still other references to a distinct object?
I don't know how easy it would be, and I guess that in case the
programmer knows that unsafeFreeze can be safely used it's faster than
asking the garbage collection. Unsafe freezing is used everywhere
in implementation of immutable arrays, so it's worth eliminating
unnecessary overheads.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From rrt@dcs.gla.ac.uk Thu May 3 16:22:00 2001
From: rrt@dcs.gla.ac.uk (Reuben Thomas)
Date: Thu, 3 May 2001 16:22:00 +0100 (BST)
Subject: Windows InstallShield updated
Message-ID:
I've just uploaded a better Windows InstallShield for GHC that fixes a
problem with the last one, but more importantly, hides the Cygwin binaries
it installs in ghc-4.08.2/extra-bin, so that they do not interfere with, and
are not intefered with by, any installation of Cygwin you may have on your
system.
Incidentally, I have also fixed a small problem in the Happy InstallShield,
so if you couldn't get it to work, try downloading again.
--
http://sc3d.org/rrt/
"Reality is what refuses to disappear when you stop believing in it" -
Philip K. Dick
From simonpj@microsoft.com Fri May 4 09:19:37 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Fri, 4 May 2001 01:19:37 -0700
Subject: Building nhc98-1.02 with ghc-5.00
Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72EAD@red-msg-09.redmond.corp.microsoft.com>
I've committed a fix.
Simon
| -----Original Message-----
| From: Simon Marlow=20
| Sent: 27 April 2001 10:19
| To: Wolfhard Bu=DF; nhc-users@cs.york.ac.uk
| Cc: glasgow-haskell-users@haskell.org
| Subject: RE: Building nhc98-1.02 with ghc-5.00
|=20
|=20
| > the building of nhc98-1.02 with ghc-5.00 aborts
| > with the message:
| >=20
| > Main.hs:8:
| > Failed to find interface decl for
| > `PrelGHC.(#,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
| > ,,,,,,,,,,,,,,,,,,,,,,,#)'
| > from module `PrelGHC'
| >=20
| > Any hints for interpretation?
|=20
| Workaround: compile this particular module without -O, or=20
| with -fno-cpr.
|=20
| Cheers,
| Simon
|=20
| _______________________________________________
| Glasgow-haskell-users mailing list=20
| Glasgow-haskell-users@haskell.org=20
| http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users
|=20
From theo@engr.mun.ca Sun May 6 23:56:42 2001
From: theo@engr.mun.ca (Theodore Norvell)
Date: Sun, 06 May 2001 20:26:42 -0230
Subject: Profiling on Windows.
Message-ID: <3AF5D6AA.C4978D88@engr.mun.ca>
Hi. I'm using ghc version 4.08.2 on windows NT. I tried compiling my program
with -prof -auto-all. It runs up until input is required (from stdin) and
then crashes claiming "The instruction at 0x0 referenced memory at 0x0. The
memory could not be read". Is there a known problem with profiling on NT
systems?
Cheers,
Theodore Norvell
----------------------------
Dr. Theodore Norvell theo@engr.mun.ca
Electrical and Computer Engineering http://www.engr.mun.ca/~theo
Engineering and Applied Science Phone: (709) 737-8962
Memorial University of Newfoundland Fax: (709) 737-4042
St. John's, NF, Canada, A1B 3X5
From chak@cse.unsw.edu.au Thu May 10 03:05:35 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Thu, 10 May 2001 12:05:35 +1000
Subject: ANNOUNCE: Happy 1.10 released
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C60171F61F@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C60171F61F@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010510120535H.chak@cse.unsw.edu.au>
"Simon Marlow" wrote,
> ANNOUNCING Happy 1.10 - The LALR(1) Parser Generator for Haskell
> -----------------------------------------------------------------
It seems that the build system does not create a link from
`happy-' to `happy'. Is this intentional?
Cheers,
Manuel
From simonmar@microsoft.com Thu May 10 09:30:56 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Thu, 10 May 2001 09:30:56 +0100
Subject: ANNOUNCE: Happy 1.10 released
Message-ID: <9584A4A864BD8548932F2F88EB30D1C60171F67C@TVP-MSG-01.europe.corp.microsoft.com>
> "Simon Marlow" wrote,
>=20
> > ANNOUNCING Happy 1.10 - The LALR(1) Parser Generator for Haskell
> > -----------------------------------------------------------------
>=20
> It seems that the build system does not create a link from
> `happy-' to `happy'. Is this intentional?
No, it's a bug. I just noticed this weekend when I made the FreeBSD
package. It's fixed in the repository now.
Cheers,
Simon
From chak@cse.unsw.edu.au Thu May 10 10:26:59 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Thu, 10 May 2001 19:26:59 +1000
Subject: ANNOUNCE: Happy 1.10 released
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C60171F61F@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C60171F61F@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010510192659H.chak@cse.unsw.edu.au>
"Simon Marlow" wrote,
> ANNOUNCING Happy 1.10 - The LALR(1) Parser Generator for Haskell
An RPM package for x86 RedHat Linux[1] is now available at
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/happy-1.10-2.i386.rpm
The matching source RPM is at
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/src/happy-1.10-2.src.rpm
Happy LALRing,
Manuel
[1] The binary has been build on RH7.0 with glibc2.2.
From alex@shop.com Thu May 10 15:24:51 2001
From: alex@shop.com (S. Alexander Jacobson)
Date: Thu, 10 May 2001 10:24:51 -0400 (Eastern Daylight Time)
Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
In-Reply-To: <20010510192659H.chak@cse.unsw.edu.au>
Message-ID:
Combining two threads...
Like macros and preprocessors, Happy generates code.
I assume the justification for this is that hand-coding a parser in
Haskell is presumed to be too difficult or that it is too hard to get the
right level of abstraction (and therefore a macro-like facility is
required).
However, I've also used Hutton & Meijer style monadic parsers and
found them extremely elegant, clean, and easy to use in both Haskell and
Python (though in Python they were too slow for my xml application --
function call overhead is _very_ high in Python).
I am not a parsing expert, but given the recent discussion on macros, I
have to ask: why use happy rather than monadic parsing? Monadic parsing
allows you to avoid a whole additional language/compilation step and work
in Hugs (where you don't have a makefile). What does Happy buy you here?
And generalizing from the above, since Monads/Arrows are types that
describe a computation declaratively and Macros are functions that
describe a computation procedurally, is it possible that, for any
application of Macros, you can find a suitable Monad/Arrow? Or am I not
understanding either well enough?
-Alex-
___________________________________________________________________
S. Alexander Jacobson Shop.Com
1-646-638-2300 voice The Easiest Way To Shop (sm)
From simonmar@microsoft.com Thu May 10 15:42:00 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Thu, 10 May 2001 15:42:00 +0100
Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
Message-ID: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com>
S. Alexander Jacobson writes:
> I am not a parsing expert, but given the recent discussion on=20
> macros, I
> have to ask: why use happy rather than monadic parsing? =20
> Monadic parsing
> allows you to avoid a whole additional language/compilation=20
> step and work
> in Hugs (where you don't have a makefile). What does Happy=20
> buy you here?
It buys you (a) speed, (b) confidence that your grammar is
non-ambiguous, and (c) familiar BNF notation. On the down side, as you
point out, you lose Haskell's abstraction facilities.
I'd be willing to sacrifice (c) in order to write parsers in Haskell,
but I don't think there's a combinator library that matches Happy in
terms of speed (disclaimer: I haven't exhaustively tested them all, but
given the tricks Happy does I'd be surprised). AFAIK none of the
combinator libraries gives you (b).
Cheers,
Simon
From cwitty@newtonlabs.com Thu May 10 18:48:52 2001
From: cwitty@newtonlabs.com (Carl R. Witty)
Date: 10 May 2001 10:48:52 -0700
Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
In-Reply-To: "S. Alexander Jacobson"'s message of "Thu, 10 May 2001 10:24:51 -0400 (Eastern Daylight Time)"
References:
Message-ID:
"S. Alexander Jacobson" writes:
> I am not a parsing expert, but given the recent discussion on macros, I
> have to ask: why use happy rather than monadic parsing? Monadic parsing
> allows you to avoid a whole additional language/compilation step and work
> in Hugs (where you don't have a makefile). What does Happy buy you here?
I've used Happy instead of parser combinators because I wanted the
additional global error-checking. I believe that the standard
implementations of parser combinators will allow you to specify an
ambiguous grammar, and return one of the multiple possible parses,
without warning.
Carl Witty
From john@foo.net Thu May 10 22:22:04 2001
From: john@foo.net (John Meacham)
Date: Thu, 10 May 2001 14:22:04 -0700
Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com>; from simonmar@microsoft.com on Thu, May 10, 2001 at 03:42:00PM +0100
References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010510142203.A16027@mark.ugcs.caltech.edu>
Just out of curiosity, has anyone done any work at benchmarking the
various parsers? I use Parsec pretty exclusivly since it comes with ghc
and is pretty straightforward and lightweight to use. I am wondering
what I am giving up in terms of speed by going that route, rather than
Happy or the compiler toolkit non-monadic but pure-haskell parser? hmm...
John
On Thu, May 10, 2001 at 03:42:00PM +0100, Simon Marlow wrote:
>
> S. Alexander Jacobson writes:
>
> > I am not a parsing expert, but given the recent discussion on
> > macros, I
> > have to ask: why use happy rather than monadic parsing?
> > Monadic parsing
> > allows you to avoid a whole additional language/compilation
> > step and work
> > in Hugs (where you don't have a makefile). What does Happy
> > buy you here?
>
> It buys you (a) speed, (b) confidence that your grammar is
> non-ambiguous, and (c) familiar BNF notation. On the down side, as you
> point out, you lose Haskell's abstraction facilities.
>
> I'd be willing to sacrifice (c) in order to write parsers in Haskell,
> but I don't think there's a combinator library that matches Happy in
> terms of speed (disclaimer: I haven't exhaustively tested them all, but
> given the tricks Happy does I'd be surprised). AFAIK none of the
> combinator libraries gives you (b).
--
--------------------------------------------------------------
John Meacham http://www.ugcs.caltech.edu/~john/
California Institute of Technology, Alum. john@foo.net
--------------------------------------------------------------
From qrczak@knm.org.pl Thu May 10 22:24:36 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 10 May 2001 21:24:36 GMT
Subject: MonadError and fundeps
Message-ID:
MonadReader, MonadWriter and MonadState classes have fundeps from the
monad type to the environment / output / state type (I added them
a few months ago).
MonadError doesn't. I thought that it's desirable to make a class with
more than one exception type, such that for example each catchError
would catch the corresponding throwError only, or even with simulation
of some subtyping policy.
Now I'm not sure that it was the right choice. I have an example when
having this fundep would be very helpful:
I am experimenting with building monadic parsing combinators from monad
transformers. In particular I already have a Parsec-like parsing monad
composed from pieces. It would be bad to hardwire the error type.
But without a fundep in MonadError overloaded functions can't be
written with MonadError in the context and without mentioning the
error type in their type (which would be impractical).
My workaround is to have a separate class, similar to MonadError but
with a fundep, with MonadError in its superclass, and with its own
instances. Fortunately this class can be empty, taking implementation
of pushing the error handling through monad transformers from
MonadError. But it would be more straightforward to use MonadError
directly.
I make use of the fundep in MonadState too. So I think that usually
one wants these fundeps.
Other argument for having a fundep in MonadError: monad transformers
provided by modules in package lang don't provide a monad which
could handle multiple errors anyway, and it would be impossible to
do it generically without overlapping instances. An instance would
have to recognize "its" error type, so it must work on a hardwired
type constructor.
If there was a fundep, the behavior of different error types can be
simulated by providing functions defined in terms of throwError and
catchError which throw a specific type or catch only a specific type
(this works only in the case where handling of all errors is done at
the same level of monad transformers, but I doubt that anyone would
make a monad without this property and still wanted to use generic
throwing and catching functions). This can be even done generically in
terms of classes which coerce a specific error type up or recognize
it, without touching all monads, as I am doing in the workaround in
the opposite direction.
What do you think? If nobody answers, I think I will add the fundep...
BTW, another question: should MonadPlus instead of just Monad be
a superclass of MonadError? It has a natural definition in terms
of catchError.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From andrew@bromage.org Fri May 11 05:40:27 2001
From: andrew@bromage.org (Andrew J Bromage)
Date: Fri, 11 May 2001 14:40:27 +1000
Subject: MonadError and fundeps
In-Reply-To: ; from qrczak@knm.org.pl on Thu, May 10, 2001 at 09:24:36PM +0000
References:
Message-ID: <20010511144027.A1660@smtp.alicorna.com>
G'day all.
On Thu, May 10, 2001 at 09:24:36PM +0000, Marcin 'Qrczak' Kowalczyk wrote:
> BTW, another question: should MonadPlus instead of just Monad be
> a superclass of MonadError? It has a natural definition in terms
> of catchError.
I can see how mplus has a "natural" definition (I can think of one or
two circumstances where it's not semantically "natural", even if it is
operationally "natural", but that's beside the point).
What about mzero, though? What "natural definition" did you have
in mind?
Cheers,
Andrew Bromage
From qrczak@knm.org.pl Fri May 11 07:54:09 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 11 May 2001 06:54:09 GMT
Subject: MonadError and fundeps
References: <20010511144027.A1660@smtp.alicorna.com>
Message-ID:
Fri, 11 May 2001 14:40:27 +1000, Andrew J Bromage pisze:
> What about mzero, though? What "natural definition" did you have
> in mind?
You are right, mzero is not as automatic as mplus. It surely means
'throwError something', but the value of something must be
determined separately.
'fail' belongs here too: I think it's always 'throwError something'
in practice.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From chak@cse.unsw.edu.au Fri May 11 08:09:44 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Fri, 11 May 2001 17:09:44 +1000
Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010511170944K.chak@cse.unsw.edu.au>
"Simon Marlow" wrote,
> S. Alexander Jacobson writes:
>
> > I am not a parsing expert, but given the recent discussion on
> > macros, I
> > have to ask: why use happy rather than monadic parsing?
> > Monadic parsing
> > allows you to avoid a whole additional language/compilation
> > step and work
> > in Hugs (where you don't have a makefile). What does Happy
> > buy you here?
>
> It buys you (a) speed, (b) confidence that your grammar is
> non-ambiguous, and (c) familiar BNF notation. On the down side, as you
> point out, you lose Haskell's abstraction facilities.
>
> I'd be willing to sacrifice (c) in order to write parsers in Haskell,
> but I don't think there's a combinator library that matches Happy in
> terms of speed (disclaimer: I haven't exhaustively tested them all, but
> given the tricks Happy does I'd be surprised). AFAIK none of the
> combinator libraries gives you (b).
I don't think, the point is the test for non-ambiguity. At
least, Doitse's and my self-optimising parser combinator
library will detect that a grammar is ambigious when you
parse a sentence involving the ambiguous productions. So,
you can check that by parsing a file involving all grammar
constructs of the language.
The point is much more the level of help that you get if
your grammar happens to be ambiguous. My combinators at the
moment just tell you that the grammar is ambiguous, but
provide no help as to where and why. I think, this is
similar for Doitse's combinators. Happy helps you much more
in this situation.
Cheers,
Manuel
From dongen@cs.ucc.ie Fri May 11 10:52:55 2001
From: dongen@cs.ucc.ie (Marc van Dongen)
Date: Fri, 11 May 2001 10:52:55 +0100
Subject: Two Times [was Re: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)]
In-Reply-To: <20010511170944K.chak@cse.unsw.edu.au>; from chak@cse.unsw.edu.au on Fri, May 11, 2001 at 05:09:44PM +1000
References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> <20010511170944K.chak@cse.unsw.edu.au>
Message-ID: <20010511105255.S12168@cs.ucc.ie>
Manuel M. T. Chakravarty (chak@cse.unsw.edu.au) wrote:
[received message twice]
Am I just the only one or does everybody receive
messages posted to haskell@haskell.org and
glasgow-haskell-users@haskell.org twice? I find
it a bit (I know I am exaggerating) annoying.
Is there a way to avoid this?
Regards,
Marc
From la@iki.fi Thu May 10 23:07:52 2001
From: la@iki.fi (Lauri Alanko)
Date: Fri, 11 May 2001 01:07:52 +0300
Subject: MonadError and fundeps
In-Reply-To: ; from qrczak@knm.org.pl on Thu, May 10, 2001 at 09:24:36PM +0000
References:
Message-ID: <20010511010752.B24992@la.iki.fi>
On Thu, May 10, 2001 at 09:24:36PM +0000, Marcin 'Qrczak' Kowalczyk wrote:
> MonadReader, MonadWriter and MonadState classes have fundeps from the
> monad type to the environment / output / state type (I added them
> a few months ago).
Why? This makes composing and "subtyping" impossible:
instance (MonadTrans t, MonadState s m, Monad (t m))
=> MonadState s (t m) where
get = lift get
put = lift . put
This is really useful, because you can thread multiple states (or read
multiple environments, or write multiple outputs, or whatnot), and
_directly_ use functions that operate on a particular state, without
having to do explicit lifting (to the correct level) all the time.
Fundeps add convenience, yes, but they restrict what you can do with the
monads. A bad tradeoff, IMHO.
Ah well, I'm kind of used to having to use customized versions of all
the common libs...
Lauri Alanko
la@iki.fi
From qrczak@knm.org.pl Fri May 11 13:14:24 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Fri, 11 May 2001 14:14:24 +0200 (CEST)
Subject: MonadError and fundeps
In-Reply-To: <20010511010752.B24992@la.iki.fi>
Message-ID:
On Fri, 11 May 2001, Lauri Alanko wrote:
> Why? This makes composing and "subtyping" impossible:
>
> instance (MonadTrans t, MonadState s m, Monad (t m))
> => MonadState s (t m) where
> get = lift get
> put = lift . put
This instance is illegal anyway. One of types in the instance head must be
a type constructor applied to something (type variables in Haskell 98,
anything with -fglasgow-exts).
Even if it was legal, it would overlap with
instance Monad m => MonadState s (StateT s m)
Also MonadReader and MonadWriter can't have such generic instances anyway
because their methods have values of type 'm a' as arguments.
OTOH without the fundep there are ambiguities. For example:
class ParsingState s where
stateInput :: s -> String
stateSkip :: Int -> s -> s
instance ParsingState String where ...
instance ParsingState s => ParsingState (s, Pos) where ...
input :: (ParsingState s, MonadState s m) => m String
-- Ambiguous without the fundep.
input = gets stateInput
--
Marcin 'Qrczak' Kowalczyk
From la@iki.fi Fri May 11 13:45:00 2001
From: la@iki.fi (Lauri Alanko)
Date: Fri, 11 May 2001 15:45:00 +0300
Subject: MonadError and fundeps
In-Reply-To: ; from qrczak@knm.org.pl on Fri, May 11, 2001 at 02:14:24PM +0200
References: <20010511010752.B24992@la.iki.fi>
Message-ID: <20010511154500.A5894@la.iki.fi>
On Fri, May 11, 2001 at 02:14:24PM +0200, Marcin 'Qrczak' Kowalczyk wrote:
> On Fri, 11 May 2001, Lauri Alanko wrote:
>
> > Why? This makes composing and "subtyping" impossible:
> >
> > instance (MonadTrans t, MonadState s m, Monad (t m))
> > => MonadState s (t m) where
> > get = lift get
> > put = lift . put
>
> This instance is illegal anyway. One of types in the instance head must be
> a type constructor applied to something (type variables in Haskell 98,
> anything with -fglasgow-exts).
Ah. So it seems. Pardon. It works in Hugs, though.
> Even if it was legal, it would overlap with
> instance Monad m => MonadState s (StateT s m)
Yep, but in hugs +o the latter overrides the first one. Which is quite
convenient.
> Also MonadReader and MonadWriter can't have such generic instances anyway
> because their methods have values of type 'm a' as arguments.
Oh?
translift :: (MonadTrans t, Monad m, Monad (t m))
=> (m a -> m b) -> t m a -> t m b
translift f m = m >>= lift . f . return
instance (MonadTrans t, MonadReader r m, Monad (t m))
=> MonadReader r (t m) where
ask = lift ask
local = translift . local
instance (MonadTrans t, MonadWriter w m, Monad (t m), Monoid w) =>
MonadWriter w (t m) where
tell = lift . tell
listen = translift listen
pass = translift pass
> OTOH without the fundep there are ambiguities. For example:
>
> class ParsingState s where
> stateInput :: s -> String
> stateSkip :: Int -> s -> s
>
> instance ParsingState String where ...
> instance ParsingState s => ParsingState (s, Pos) where ...
>
> input :: (ParsingState s, MonadState s m) => m String
> -- Ambiguous without the fundep.
> input = gets stateInput
So it is, and why not? Is it inconceivable that m might actually have
multiple ParsingStates, and thus you really have to specify which one you
want to use to get the input?
Lauri Alanko
la@iki.fi
From ger@tzi.de Fri May 11 14:22:31 2001
From: ger@tzi.de (George Russell)
Date: Fri, 11 May 2001 15:22:31 +0200
Subject: GHCi turned upside down?
Message-ID: <3AFBE797.571DE80@tzi.de>
GHCi allows us to mix fixed compiled and dynamic interpreted code to
be run from what I presume is dynamic interpreted code - the command
prompt. Would it be possible to run dynamic interpreted code from
a compiled program? I'm hoping the answer is "Yes, because this is what
GHCi does", the only problem being to clean up the syntax and document
it.
I'm afraid I haven't been following the FFI debate lately but perhaps we
could steal some of the FFI's syntax for declaring types of imported
entities. The difference (I'm not sure if this is a difference with
the latest with the latest FFI version) would be that the source file/string
(and perhaps function name) need to vary dynamically, which means also that
of course it needs to be done below top level, and invoke an IO action. So
we might try something like
runMain :: FilePath -> IO ()
runMain sourcePath =
do
source <- readFile sourcePath
foreign import ghci source "main" main :: IO ()
main
which would read the file "sourcePath", interpret it as Haskell,
and run the "main" action therein.
This isn't meant to be a polished proposal, just an idea for something
which might be nice to have around in the future.
From qrczak@knm.org.pl Fri May 11 14:30:05 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: Fri, 11 May 2001 15:30:05 +0200 (CEST)
Subject: MonadError and fundeps
In-Reply-To: <20010511154500.A5894@la.iki.fi>
Message-ID:
On Fri, 11 May 2001, Lauri Alanko wrote:
> Yep, but in hugs +o the latter overrides the first one. Which is quite
> convenient.
I doubt that it works predictably in all cases (when state types are not
known statically). I can try to construct an example if you wish.
> translift :: (MonadTrans t, Monad m, Monad (t m))
> => (m a -> m b) -> t m a -> t m b
>
> translift f m = m >>= lift . f . return
>
> instance (MonadTrans t, MonadReader r m, Monad (t m))
> => MonadReader r (t m) where
> ask = lift ask
> local = translift . local
>
> instance (MonadTrans t, MonadWriter w m, Monad (t m), Monoid w) =>
> MonadWriter w (t m) where
> tell = lift . tell
> listen = translift listen
> pass = translift pass
This gives wrong results (but I haven't checked). For example
listen :: Monoid w
=> ReaderT r (Writer w) a -> ReaderT r (Writer w) (a, w)
doesn't listen what the action tells, but listens to 'return' which always
tells mempty. Similarly 'local' first runs the action in the original
environment and then provides a new environment to 'return' which doesn't
look at it.
I did most monad transformer forwarding instances in ghc-5.00 and hope
that I got them right, but I haven't tested them much. It's not that
mechanical (except MonadState), and some combinations can't be done at
all.
It could be advantageous to put something like translift in an extension
of MonadTrans. AFAIR many liftings of this type are similar (but the
function must be provided separately for each state transformer), so it
would simplify making forwarding instances.
> Is it inconceivable that m might actually have multiple ParsingStates,
> and thus you really have to specify which one you want to use to get
> the input?
The idea is to use a single state and abstract over the way in which
interesting components are contained in it. It has these advantages:
* It works. I doubt that automatic recognition of the state type would work.
* It allows to have multiple components of the same type in the state.
Now I see that my simulation of a fundep without the fundep (an extra
class which generates the dependency, instantiated separately for each
monad transformer, with MonadError as a superclass) doesn't work that
well: throwError would still be ambiguous so it needs a wrapper with a
type which tells how to determine the error type using the new class.
So I'm now convinced that MonadError should have the fundep too.
Some other mechanism could be invented to make it easier to embed various
components in the same type (for MonadReader & MonadState) or various
alternatives (for MonadError). I have a rather heavy proposal for the
first case (a language extension which redesigns records). OCaml has
a dual mechanism for the second (polymorphic variants). If my records
succeed, I will try to cover variants too.
--
Marcin 'Qrczak' Kowalczyk
From simonmar@microsoft.com Fri May 11 15:47:08 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Fri, 11 May 2001 15:47:08 +0100
Subject: GHCi turned upside down?
Message-ID: <9584A4A864BD8548932F2F88EB30D1C611587E@TVP-MSG-01.europe.corp.microsoft.com>
> GHCi allows us to mix fixed compiled and dynamic interpreted code to=20
> be run from what I presume is dynamic interpreted code - the command
> prompt. Would it be possible to run dynamic interpreted code from
> a compiled program? I'm hoping the answer is "Yes, because=20
> this is what
> GHCi does", the only problem being to clean up the syntax and document
> it.
It's certainly possible, but bear in mind that you'd have to link in
essentially the whole of GHCi into your program in order to do it! But
one of the things on our wish list is to have a clearly defined
interface to the underlying compilation/session manager, (i.e. what
we've been calling the HEP, or Haskell Execution Platform). This would
allow you to plug in new user interfaces, make interpreted COM objects,
and in general have Haskell compilation/execution services available
from a Haskell API. There's still work to do in deciding exactly what
this API should look like, though.
Cheers,
Simon
From cwitty@newtonlabs.com Fri May 11 18:13:49 2001
From: cwitty@newtonlabs.com (Carl R. Witty)
Date: 11 May 2001 10:13:49 -0700
Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
In-Reply-To: "Manuel M. T. Chakravarty"'s message of "Fri, 11 May 2001 17:09:44 +1000"
References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> <20010511170944K.chak@cse.unsw.edu.au>
Message-ID:
"Manuel M. T. Chakravarty" writes:
> I don't think, the point is the test for non-ambiguity. At
> least, Doitse's and my self-optimising parser combinator
> library will detect that a grammar is ambigious when you
> parse a sentence involving the ambiguous productions. So,
> you can check that by parsing a file involving all grammar
> constructs of the language.
Sorry, doesn't work. Where do you get this "file involving all
grammar constructs of the language"?
If such an approach worked, you could use it to determine whether an
arbitrary context-free grammar was ambiguous; but this problem is
undecidable.
Carl Witty
From brian@boutel.co.nz Sat May 12 05:57:34 2001
From: brian@boutel.co.nz (Brian Boutel)
Date: Sat, 12 May 2001 16:57:34 +1200
Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> <20010511170944K.chak@cse.unsw.edu.au>
Message-ID: <3AFCC2BE.B75CB113@boutel.co.nz>
"Carl R. Witty" wrote:
>
> "Manuel M. T. Chakravarty" writes:
>
> > I don't think, the point is the test for non-ambiguity. At
> > least, Doitse's and my self-optimising parser combinator
> > library will detect that a grammar is ambigious when you
> > parse a sentence involving the ambiguous productions. So,
> > you can check that by parsing a file involving all grammar
> > constructs of the language.
>
> Sorry, doesn't work. Where do you get this "file involving all
> grammar constructs of the language"?
>
> If such an approach worked, you could use it to determine whether an
> arbitrary context-free grammar was ambiguous; but this problem is
> undecidable.
>
This illustrates the difference between generality and usefulness.
Often, one is less interested in learning that a grammar is ambiguous
than learning that it is not.
If you have a parser generator for a class of grammars, it will tell you
if (and probably why) a candidate grammar you feed to it is not a member
of that class. If it is accepted by, for example, a parser generator for
LR(1) grammars, then it is a DCFG and therefore unambiguous.
If you start with a "natural" grammar for the language, i.e. one that
corresponds to the abstract syntax, and use a generator for a broad
class of grammars (e.g LR(1)) then failure will give a good hint that
the only way to get an unambiguous grammar in that class is to restrict
the language, and you can use that information to make design decisions.
For example, although Haskell has both 'let' and 'where' for introducing
local definitions, thereby reflecting the typical committee decision
when there are varying stylistic preferences, 'where' is not part of the
expression syntax. If you write a grammar which includes the "natural"
productions
exp -> let defs in exp
exp -> exp where defs
and put this through a suitable generator, you will see why not.
Of course, it is possible that an unambiguous grammar will fail to be
LR(1) - by being non-deterministic, so the proper conclusion is that "G
is ambiguous or non-deterministic". But that is close enough for most
purposes.
Early versions of Hope had both 'let' and 'where' as expressions, and
had three different forms of condtional. Most combinations of these
constructs would interract to create ambiguity. The hand-coded parsers
in use had not picked this up. That shows the advantage of using a
generator - you get a constructive proof that the grammar is in the
desired class.
--brian
From michael.weber@post.rwth-aachen.de Sat May 12 10:11:39 2001
From: michael.weber@post.rwth-aachen.de (Michael Weber)
Date: Sat, 12 May 2001 11:11:39 +0200
Subject: Two Times [was Re: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)]
In-Reply-To: <20010511105255.S12168@cs.ucc.ie>; from dongen@cs.ucc.ie on Fri, May 11, 2001 at 10:52:55AM +0100
References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> <20010511170944K.chak@cse.unsw.edu.au> <20010511105255.S12168@cs.ucc.ie>
Message-ID: <20010512111139.A992@webnet.de>
* Marc van Dongen [2001-05-11T10:52+0100]:
> Manuel M. T. Chakravarty (chak@cse.unsw.edu.au) wrote:
>
> [received message twice]
>
> Am I just the only one or does everybody receive
> messages posted to haskell@haskell.org and
> glasgow-haskell-users@haskell.org twice? I find
> it a bit (I know I am exaggerating) annoying.
> Is there a way to avoid this?
Use procmail to eliminate dups...
.procmailrc:
:0 Whc: msgid.lock
| formail -D 8192 msgid.cache
:0 a:
duplicates
More info: man procmail procmailex procmailrc
Cheers,
Michael
--
() ASCII ribbon campaign | Chair for Computer Science II | GPG: F65C68CD
/\ against HTML mail | RWTH Aachen, Germany | PGP: 1D0DD0B9
But... but.... There's no BLINK tag in LaTeX!
-- seen on /.
From gemi@bluewin.ch Sat May 12 12:28:33 2001
From: gemi@bluewin.ch (=?ISO-8859-1?Q?G=E9rard_Milmeister?=)
Date: Sat, 12 May 2001 13:28:33 +0200
Subject: Compile problems with ghc-5.0
In-Reply-To: <20010512132421.A17862@scriabin.cablecom.ch>; from gemi@bluewin.ch on Sat, May 12, 2001 at 13:24:21 +0200
References: <20010512132421.A17862@scriabin.cablecom.ch>
Message-ID: <20010512132833.B17862@scriabin.cablecom.ch>
I use Redhat 6.2.
The binary install is ok, but when I compile ghc-5.0 from source
using ghc-5.0, I get the following error after 'make all':
../../../ghc/utils/hsc2hs/hsc2hs-inplace Directory.hsc
../../../ghc/utils/hsc2hs/hsc2hs-inplace:
/test/v-julsew/Nightly-HEAD/i386-unknown-linux/stage1/ghc/utils/hsc2hs/hsc2hs-bin:
No such file or directory
Furthermore, most available libraries seem to be uncompilable
with ghc-5.0, e.g. c2hs and gtk2hs.
--
Gérard Milmeister
Tannenrauchstr. 35
8038 Zürich
From michael.weber@post.rwth-aachen.de Sat May 12 17:30:17 2001
From: michael.weber@post.rwth-aachen.de (Michael Weber)
Date: Sat, 12 May 2001 18:30:17 +0200
Subject: Compile problems with ghc-5.0
In-Reply-To: <20010512132833.B17862@scriabin.cablecom.ch>; from gemi@bluewin.ch on Sat, May 12, 2001 at 01:28:33PM +0200
References: <20010512132421.A17862@scriabin.cablecom.ch> <20010512132833.B17862@scriabin.cablecom.ch>
Message-ID: <20010512183017.A29401@webnet.de>
* Gérard Milmeister [2001-05-12T13:28+0200]:
> I use Redhat 6.2.
> The binary install is ok, but when I compile ghc-5.0 from source
> using ghc-5.0, I get the following error after 'make all':
>
> ../../../ghc/utils/hsc2hs/hsc2hs-inplace Directory.hsc
> ../../../ghc/utils/hsc2hs/hsc2hs-inplace:
> /test/v-julsew/Nightly-HEAD/i386-unknown-linux/stage1/ghc/utils/hsc2hs/hsc2hs-bin:
> No such file or directory
>
> Furthermore, most available libraries seem to be uncompilable
> with ghc-5.0, e.g. c2hs and gtk2hs.
For c2hs I provided a patch for configure, which made it think it's
dealing with ghc-4.11.
I don't have it at hand, but you can ask Manuel Chakravarty. AFAIK,
he already updated the c2hs CVS repo and provided a Real Solution(tm).
Cheers,
Michael
--
() ASCII ribbon campaign | Chair for Computer Science II | GPG: F65C68CD
/\ against HTML mail | RWTH Aachen, Germany | PGP: 1D0DD0B9
"I WILL NOT SELL MIRACLE CURES"
-- Bart Simpson in 9F16
From chak@cse.unsw.edu.au Sun May 13 07:51:38 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Sun, 13 May 2001 16:51:38 +1000
Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
In-Reply-To:
References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com>
<20010511170944K.chak@cse.unsw.edu.au>
Message-ID: <20010513165138B.chak@cse.unsw.edu.au>
cwitty@newtonlabs.com (Carl R. Witty) wrote,
> "Manuel M. T. Chakravarty" writes:
>
> > I don't think, the point is the test for non-ambiguity. At
> > least, Doitse's and my self-optimising parser combinator
> > library will detect that a grammar is ambigious when you
> > parse a sentence involving the ambiguous productions. So,
> > you can check that by parsing a file involving all grammar
> > constructs of the language.
>
> Sorry, doesn't work. Where do you get this "file involving all
> grammar constructs of the language"?
>
> If such an approach worked, you could use it to determine whether an
> arbitrary context-free grammar was ambiguous; but this problem is
> undecidable.
I didn't say that this works for any kind of parser
combinator, I merely said that it works Doitse's and mine.
Both implement SLL(1) parsers for which - as I am sure, you
know - there exists a decision procedure for testing
ambiguity. More precisely, whenever the library can build
the parse table, the grammar must be non-ambigious. As the
parse table construction is lazy, this covers only the
productions exercised in that particular run, which is why I
said that you need a "file involving all grammar constructs
of the language." Nothing magic here.
Cheers,
Manuel
PS: AFAIK Doitse recently made his combinators a bit more
general, and I am not entirely sure how that affects
the ambiguity check.
From chak@cse.unsw.edu.au Sun May 13 09:20:53 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Sun, 13 May 2001 18:20:53 +1000
Subject: Compile problems with ghc-5.0
In-Reply-To: <20010512183017.A29401@webnet.de>
References: <20010512132421.A17862@scriabin.cablecom.ch>
<20010512132833.B17862@scriabin.cablecom.ch>
<20010512183017.A29401@webnet.de>
Message-ID: <20010513182053I.chak@cse.unsw.edu.au>
michael.weber@post.rwth-aachen.de (Michael Weber) wrote,
> * G=E9rard Milmeister [2001-05-12T13:28+0200]:
> > I use Redhat 6.2.
> > The binary install is ok, but when I compile ghc-5.0 from source
> > using ghc-5.0, I get the following error after 'make all':
> > =
> > ../../../ghc/utils/hsc2hs/hsc2hs-inplace Directory.hsc
> > ../../../ghc/utils/hsc2hs/hsc2hs-inplace:
> > /test/v-julsew/Nightly-HEAD/i386-unknown-linux/stage1/ghc/utils/hsc2=
hs/hsc2hs-bin:
> > No such file or directory
> > =
> > Furthermore, most available libraries seem to be uncompilable
> > with ghc-5.0, e.g. c2hs and gtk2hs.
> =
> For c2hs I provided a patch for configure, which made it think it's
> dealing with ghc-4.11.
> =
> I don't have it at hand, but you can ask Manuel
> Chakravarty. =
I append the patch.
> AFAIK,
> he already updated the c2hs CVS repo and provided a Real Solution(tm).=
That's right. The CVS version works with 5.00 and has some
more new goodies. I will put out a release (with binaries)
as soon as the new features are sufficiently bug free.
As for Gtk+HS, which was also mentioned, I will take care of
that after c2hs is done. Are you (that is G=E9rard) on the
Gtk+HS mailing list?
http://www.cse.unsw.edu.au/~chak/haskell/gtk/#ml
The list doesn't have much traffic, but carries news
regarding new versions of the library etc.
Cheers,
Manuel
-=3D-
--- c2hs-0.8.2.orig/configure.in
+++ c2hs-0.8.2/configure.in
@@ -113,6 +113,11 @@
dnl set GHC, as this is what the following command inspects
GHC=3D$HC
CTK_GHC_VERSION(hc_maj_vers,hc_min_vers)
+ if test $hc_maj_vers -eq 5; then
+ # HACK HACK HACK
+ hc_maj_vers=3D4
+ hc_min_vers=3D11
+ fi
if test $hc_maj_vers -lt 3 -o $hc_min_vers -lt 2; then
AC_MSG_ERROR([You need version 3.02 or 4.02 upwards of ghc!
** Check \"http://haskell.org/ghc/\". **])
--- c2hs-0.8.2.orig/c2hs/lib/Makefile
+++ c2hs-0.8.2/c2hs/lib/Makefile
@@ -95,7 +95,7 @@
# * The following enables the use of the FFI and sucks in the prototype=
s needed
# by external calls =
#
-EXTRAHCFLAGS =3D -fglasgow-exts $(LIB_HCFLAGS)
+EXTRAHCFLAGS =3D -fglasgow-exts -package lang $(LIB_HCFLAGS)
=
# make all object files
#
From cwitty@newtonlabs.com Mon May 14 20:31:43 2001
From: cwitty@newtonlabs.com (Carl R. Witty)
Date: 14 May 2001 12:31:43 -0700
Subject: Happy and Macros (was Re: ANNOUNCE: Happy 1.10 released)
In-Reply-To: "Manuel M. T. Chakravarty"'s message of "Sun, 13 May 2001 16:51:38 +1000"
References: <9584A4A864BD8548932F2F88EB30D1C611587C@TVP-MSG-01.europe.corp.microsoft.com> <20010511170944K.chak@cse.unsw.edu.au> <20010513165138B.chak@cse.unsw.edu.au>
Message-ID:
"Manuel M. T. Chakravarty" writes:
> I didn't say that this works for any kind of parser
> combinator, I merely said that it works Doitse's and mine.
> Both implement SLL(1) parsers for which - as I am sure, you
> know - there exists a decision procedure for testing
> ambiguity. More precisely, whenever the library can build
> the parse table, the grammar must be non-ambigious. As the
> parse table construction is lazy, this covers only the
> productions exercised in that particular run, which is why I
> said that you need a "file involving all grammar constructs
> of the language." Nothing magic here.
Wow. Clearly I haven't spent enough time looking at your parser
systems. I apologize for my incorrect assumptions and statements.
Carl Witty
From holzmueller@ics-ag.de Wed May 16 08:38:13 2001
From: holzmueller@ics-ag.de (Bernd =?iso-8859-2?Q?Holzm=FCller?=)
Date: Wed, 16 May 2001 09:38:13 +0200
Subject: Windows binary installation for GHC 5.00
Message-ID: <3B022E63.C26CCBDA@ics-ag.de>
Is there any prediction for when the Windows (NT) binary distribution
for GHC 5.00 will be available? I would not want to install GHC5.00 from
the source distribution in case the binary distribution is going to be
released "soon". Anyway, I would expect getting an appropriate note via
the glasgow-haskell-users mailing list.
Bernd Holzmüller
From simonpj@microsoft.com Wed May 16 11:24:54 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Wed, 16 May 2001 03:24:54 -0700
Subject: Windows binary installation for GHC 5.00
Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72F2B@red-msg-09.redmond.corp.microsoft.com>
Yes, it'll be 'soon' (days, or a week or three, but not months)
Simon
| -----Original Message-----
| From: Bernd Holzm=FCller [mailto:holzmueller@ics-ag.de]=20
| Sent: 16 May 2001 08:38
| To: glasgow-haskell-users@haskell.org
| Subject: Windows binary installation for GHC 5.00
|=20
|=20
| Is there any prediction for when the Windows (NT) binary=20
| distribution for GHC 5.00 will be available? I would not want=20
| to install GHC5.00 from the source distribution in case the=20
| binary distribution is going to be released "soon". Anyway, I=20
| would expect getting an appropriate note via the=20
| glasgow-haskell-users mailing list.
|=20
| Bernd Holzm=FCller
|=20
| _______________________________________________
| Glasgow-haskell-users mailing list=20
| Glasgow-haskell-users@haskell.org=20
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-| users
|=20
From awhitford@lucent.com Wed May 16 17:36:01 2001
From: awhitford@lucent.com (Whitford, Alister)
Date: Wed, 16 May 2001 17:36:01 +0100
Subject: Problems building GHC 5.00 on Solaris 2.5.1
Message-ID: <7B405CCAA598D411B52F006008F61B190AD89B@lon-exch1.kenan.com>
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C0DE26.4B412D20
Content-Type: text/plain;
charset="iso-8859-1"
I'm trying to build GHC 5.00 on Solaris 2.5.1.
I've got most of the way there. So far, I've had to:
- Hack glafp-utils/sgmlverb/Makefile because by lex doesn't support the -8
option.
- Hack mk/target.mk in several places because my ld doesn't support the -x
option.
- Hack configure.in to prevent it from trying to build ReadLine (which was
failing.)
(Any comments on the above?)
The compiler and standard libraries have all built. I'm now attempting to
build DrIFT, but I get the following error:
../../../ghc/compiler/ghc-inplace -o DrIFT -ldl -cpp -fglasgow-exts -package
text -O ChaseImports.o CommandP.o DataP.o DigitToInt.o DrIFT.o
Literate.o ParseLib2.o PreludData.o Pretty.o RuleUtils.o StandardRules.o
UserRuleBinary.o UserRuleXml.o UserRules.o
Undefined first referenced
symbol in file
siginterrupt
/tmp/ajw/ghc-5.00-build-from-4.08.2/ghc/driver/../rts/libHSrts.a(Signals.o)
ld: fatal: Symbol referencing errors. No output written to DrIFT
In fact, this occurs whenever I run ghc-inplace to try to create an
executable :-(
It turns out that siginterrupt is defined in /usr/ucblib/libucb.a, so if I
muck about a bit, I can get a working executable like so:
/tmp/ajw/ghc-5.00-build-from-4.08.2/ghc/compiler/ghc-inplace -o test
-L/usr/ucblib -lucb test.lhs
So the question is: how do I get libHSrts.a to link automatically with
/usr/ucblib/libucb.a so that the compiler will work properly?
Many thanks in advance for any help!
Cheers,
Alister.
------_=_NextPart_001_01C0DE26.4B412D20
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Problems building GHC 5.00 on Solaris 2.5.1
I'm trying to build GHC 5.00 on Solaris 2.5.1.
I've got most of the way there. So far, I've =
had to:
- Hack glafp-utils/sgmlverb/Makefile because by lex =
doesn't support the -8 option.
- Hack mk/target.mk in several places because my ld =
doesn't support the -x option.
- Hack configure.in to prevent it from trying to =
build ReadLine (which was failing.)
(Any comments on the above?)
The compiler and standard libraries have all =
built. I'm now attempting to build DrIFT, but I get the following =
error:
../../../ghc/compiler/ghc-inplace -o DrIFT -ldl -cpp =
-fglasgow-exts -package text -O =
ChaseImports.o CommandP.o DataP.o DigitToInt.o DrIFT.o Literate.o =
ParseLib2.o PreludData.o Pretty.o RuleUtils.o StandardRules.o =
UserRuleBinary.o UserRuleXml.o UserRules.o
Undefined =
=
first referenced
symbol &nb=
sp; &nb=
sp; in file
siginterrupt &nb=
sp; &nb=
sp; =
/tmp/ajw/ghc-5.00-build-from-4.08.2/ghc/driver/../rts/libHSrts.a(Signals=
.o)
ld: fatal: Symbol referencing errors. No output =
written to DrIFT
In fact, this occurs whenever I run ghc-inplace to =
try to create an executable :-(
It turns out that siginterrupt is defined in =
/usr/ucblib/libucb.a, so if I muck about a bit, I can get a working =
executable like so:
/tmp/ajw/ghc-5.00-build-from-4.08.2/ghc/compiler/ghc-inplace =
-o test -L/usr/ucblib -lucb test.lhs
So the question is: how do I get libHSrts.a to link =
automatically with /usr/ucblib/libucb.a so that the compiler will work =
properly?
Many thanks in advance for any help!
Cheers,
Alister.
------_=_NextPart_001_01C0DE26.4B412D20--
From simonmar@microsoft.com Wed May 16 17:46:57 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Wed, 16 May 2001 17:46:57 +0100
Subject: Endangered I/O operations
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6115886@TVP-MSG-01.europe.corp.microsoft.com>
I'm currently re-implementing GHC's I/O library, and I'd like to get
people's opinions on the following I/O extensions currently provided by
GHC - should we continue to provide them or not.
1. IOExts.hConnectTo
This was designed to be a way to have one handle automatically flushed
before we flush another handle (eg. outputting to stderr causes stdout
to be flushed first). The current implementation has a number of
problems: errors and blocking arenn't handled properly when doing the
connected flush. If no-one is using it, I'd like to get rid of it.
2. IOExts.withHandleFor
This is a cunning hack to allow you to temporarily redirect one handle
to another, like 2>&1 in shell speak. I'm dubious as to whether it
works consistently - there's certainly not enough error checking in the
implementation, so if no-one is using it I'd like to drop it.
3. IOExts.hGetBuf, IOExts.hPutBuf,=20
IOExts.hGetBufBA, IOExts.hPutBufBA
These are the "non-blocking" versions of hGetBufFull, hPutBufFull etc.
I can't remember why we have both blocking and non-blocking versions,
although I distinctly remember implementing and documenting them :-) If
anyone is using, or knows of a good use for, the non-blocking versions,
then I'll keep them. Otherwise, I'd like to rename hGetBufFull to
hGetBuf, and similarly for the others.
Cheers,
Simon
From awhitford@lucent.com Thu May 17 11:33:30 2001
From: awhitford@lucent.com (Alister Whitford)
Date: Thu, 17 May 2001 11:33:30 +0100 (BST)
Subject: Problems building GHC 5.00 on Solaris 2.5.1
Message-ID: <200105171033.LAA21379@lonsdev3.kenan.com>
I forgot to mention in my first mail that I also got nearly 4000 warnings of the form, "call-clobbered register used for global register variable".
They all occur in ghc/include/Reg.h, on the lines that declare the registers F1, F2, F3, F4, D1 and D2. However, in ghc/include/MachReg.h, we see:
#if sparc_TARGET_ARCH
...
#define CALLER_SAVES_F1
#define CALLER_SAVES_F2
#define CALLER_SAVES_F3
#define CALLER_SAVES_F4
#define CALLER_SAVES_D1
#define CALLER_SAVES_D2
So I am assuming that this warning may safely be ignored - is this correct?
Btw, apologies that my original message was in MIME format. Sadly Outlook sends it like that even if you select plain text as your message format, so I have resorted to composing my messages in vi and using the unix mail command...
From sof@galconn.com Fri May 18 19:12:04 2001
From: sof@galconn.com (Sigbjorn Finne)
Date: Fri, 18 May 2001 11:12:04 -0700
Subject: Endangered I/O operations
References: <9584A4A864BD8548932F2F88EB30D1C6115886@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <01dd01c0dfc6$0b6c9d00$4576fea9@sofbox>
Simon Marlow simonmar@microsoft.com writes:
>
> I'm currently re-implementing GHC's I/O library, and I'd like to get
> people's opinions on the following I/O extensions currently provided by
> GHC - should we continue to provide them or not.
>
> 1. IOExts.hConnectTo
>
> This was designed to be a way to have one handle automatically flushed
> before we flush another handle (eg. outputting to stderr causes stdout
> to be flushed first). The current implementation has a number of
> problems: errors and blocking arenn't handled properly when doing the
> connected flush. If no-one is using it, I'd like to get rid of it.
>
If you handle std{in,out,err} connectedness in other ways, I think you've
covered 99.2% of the uses of hConnectTo. Neat idea borrowed from
Korn & Vo's SFIO, but it hasn't proved to be all that useful.
> 2. IOExts.withHandleFor
>
> This is a cunning hack to allow you to temporarily redirect one handle
> to another, like 2>&1 in shell speak. I'm dubious as to whether it
> works consistently - there's certainly not enough error checking in the
> implementation, so if no-one is using it I'd like to drop it.
>
Don't mind seeing it going.
--sigbjorn
From simonmar@microsoft.com Mon May 21 16:01:11 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Mon, 21 May 2001 16:01:11 +0100
Subject: hTell
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD6DB@TVP-MSG-01.europe.corp.microsoft.com>
Quick question: can anyone tell me why IOExts.hTell returns a
HandlePosition, whereas IO.hSeek takes an Integer?
From qrczak@knm.org.pl Mon May 21 17:29:05 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 21 May 2001 16:29:05 GMT
Subject: hTell
References: <9584A4A864BD8548932F2F88EB30D1C6058DD6DB@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID:
Mon, 21 May 2001 16:01:11 +0100, Simon Marlow pisze:
> Quick question: can anyone tell me why IOExts.hTell returns
> a HandlePosition,
It doesn't. The comment in export list is wrong.
It's wrong because Haskell still lacks a formal way to describe
module interfaces.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From simonmar@microsoft.com Tue May 22 11:30:00 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Tue, 22 May 2001 11:30:00 +0100
Subject: Endangered I/O operations
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD6E0@TVP-MSG-01.europe.corp.microsoft.com>
> If you handle std{in,out,err} connectedness in other ways, I=20
> think you've
> covered 99.2% of the uses of hConnectTo. Neat idea borrowed from
> Korn & Vo's SFIO, but it hasn't proved to be all that useful.
I wasn't planning to handle connectedness at all. Is it important, do
you think? (I'm not against the feature, just trying to avoid feeping
creaturism...)
Cheers,
Simon
From simonmar@microsoft.com Tue May 22 15:43:45 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Tue, 22 May 2001 15:43:45 +0100
Subject: Poll: System.exitWith behaviour
Message-ID: <9584A4A864BD8548932F2F88EB30D1C611588D@TVP-MSG-01.europe.corp.microsoft.com>
The current behaviour of System.exitWith doesn't really make sense in a
concurrent environment. The current semantics is to:
- halt the current thread
- run all finalizers (concurrently with any other
currently running threads)
- stop the system as soon as all finalizers have
finished.
One high-priority problem we also have is that a program which calls
System.exitWith from inside GHCi will shut down the whole system.
Here's my current proposal:
- introduce a new exception constructor:
ExitException ExitCode
- System.exitWith causes (ExitException code) to be
raised in the current thread.
=20
- If this exception propogates to the top of the thread, then
the main thread is also sent (ExitException code). This
only happens for a standalone executable (ie. one which was
started by PrelMain.mainIO).
- If this exception propogates to the top of the main thread,
then the system is shut down as before - all finalizers are
run to completion, then we exit.
For GHCi, we can obviously catch the ExitException exception and
recover, and there is no main thread in this case.
An alternative is just to omit the third point and let the programmer
handle propagation of the ExitException to the main thread. This is
somewhat consistent with our current policy of leaving these kind of
decisions up to the programmer: we currently don't implement any kind of
process hierarchy, and there is no requirement for child threads to
complete before the program exits, for example.
Cheers,
Simon
From plop@redbrick.dcu.ie Tue May 22 17:15:50 2001
From: plop@redbrick.dcu.ie (Smelly Pooh)
Date: Tue, 22 May 2001 17:15:50 +0100
Subject: Poll: System.exitWith behaviour
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611588D@TVP-MSG-01.europe.corp.microsoft.com>; from simonmar@microsoft.com on Tue, May 22, 2001 at 03:43:45PM +0100
References: <9584A4A864BD8548932F2F88EB30D1C611588D@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010522171550.A46611@enigma.redbrick.dcu.ie>
In reply to Simon Marlow,
> - introduce a new exception constructor:
> ExitException ExitCode
>
> - System.exitWith causes (ExitException code) to be
> raised in the current thread.
Not entirely relevant, in fact, barely at all but what are the odds of user
extensible Exceptions (like ML) coming into GHC and having a proper hierarchy
of exceptions integrated in the libraries?
From simonmar@microsoft.com Tue May 22 17:30:39 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Tue, 22 May 2001 17:30:39 +0100
Subject: Poll: System.exitWith behaviour
Message-ID: <9584A4A864BD8548932F2F88EB30D1C611588E@TVP-MSG-01.europe.corp.microsoft.com>
> In reply to Simon Marlow,
> > - introduce a new exception constructor:
> > ExitException ExitCode
> >=20
> > - System.exitWith causes (ExitException code) to be
> > raised in the current thread.
>=20
> Not entirely relevant, in fact, barely at all but what are=20
> the odds of user
> extensible Exceptions (like ML) coming into GHC and having a=20
> proper hierarchy
> of exceptions integrated in the libraries?
Well, we could do a proper job of extensible data types, which probably
isn't hard but is certainly a fair amount of work. Or we could treat
Exception as a special case, like ML. Or we could take the
Dynamic-typed exception stuff and try to use that in a general way to
provide an extensible exception type... I'm open to suggestions.
Cheers,
Simon
From sof@galconn.com Tue May 22 17:46:48 2001
From: sof@galconn.com (Sigbjorn Finne)
Date: Tue, 22 May 2001 09:46:48 -0700
Subject: Endangered I/O operations
References: <9584A4A864BD8548932F2F88EB30D1C6058DD6E0@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <012f01c0e2de$cb7d2f90$4576fea9@sofbox>
----- Original Message -----
From: "Simon Marlow"
To: "Sigbjorn Finne"
Cc: "GHC Users Mailing List (GHC Users Mailing List)"
Sent: Tuesday, May 22, 2001 03:30
Subject: RE: Endangered I/O operations
> > If you handle std{in,out,err} connectedness in other ways, I
> > think you've
> > covered 99.2% of the uses of hConnectTo. Neat idea borrowed from
> > Korn & Vo's SFIO, but it hasn't proved to be all that useful.
>
> I wasn't planning to handle connectedness at all. Is it important, do
> you think? (I'm not against the feature, just trying to avoid feeping
> creaturism...)
>
Yes, crucial I think - if stdout and stderr are connected to the same
device,
don't you want their output to be synchronised, e.g.,
main = putStr "foo" >> hPutStr stderr " bar"
should return "foo bar" on your TTY. Ditto for flushing stdout/stderr when
peeking stdin.
--sigbjorn
From qrczak@knm.org.pl Tue May 22 18:06:02 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 22 May 2001 17:06:02 GMT
Subject: Poll: System.exitWith behaviour
References: <9584A4A864BD8548932F2F88EB30D1C611588D@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID:
Tue, 22 May 2001 15:43:45 +0100, Simon Marlow pisze:
> - If this exception propogates to the top of the thread, then
> the main thread is also sent (ExitException code). This
> only happens for a standalone executable (ie. one which was
> started by PrelMain.mainIO).
This looks like a strange exception for me (i.e. the fact that it
propagates to the main thread). And it's weird to have it as an
asynchronous exception in the main thread.
I would drop this rule and let 'exitWith ExitSuccess' be the way to
commit suicide by a thread, as if it completed, which degenerates to
the Haskell 98 interpretation in a single-threaded program.
BTW, I don't quite like the fact that 'exitFailure' looks simpler than
'exitWith ExitSuccess'.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From qrczak@knm.org.pl Tue May 22 18:57:28 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 22 May 2001 17:57:28 GMT
Subject: Poll: System.exitWith behaviour
References: <9584A4A864BD8548932F2F88EB30D1C611588E@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID:
Tue, 22 May 2001 17:30:39 +0100, Simon Marlow pisze:
> Well, we could do a proper job of extensible data types, which
> probably isn't hard but is certainly a fair amount of work.
This would be IMHO the only right way, but I doubt that it's that
simple. For example it would be irritating that you can't extend
function definitions accepting values of extensible data types as
arguments; even (==) is problematic.
It's a pity that there is no direct translation of the OO style open
polymorphism. You can use an algebraic type, but it casts all variants
in stone; you can store extracted concrete-typed interface in function
closures, but it doesn't allow to cast down (retrieve the original,
more specific type); you can use existential quantification, with the
same limitations; you can use Dynamic, which is not nice to define
instances of, puts everything in one big bag, and doesn't provide
any hierarchy or extraction by partial matches.
I was recently thinking on a similar thing; it would not help
with exceptions though, only with MonadError-based exceptions and
extensible abstract syntax trees. The idea is to dualize my record
proposal by introducing overloaded constructors. It provides views
for free, i.e. allows having pattern matching on abstract types
with programmer-defined semantics.
Details aren't finished yet, but I imagine something like this:
data HsExp e n l p = variant -- I like layout :-)
-- The proposal doesn't eliminate the need to have type parameters
-- here and close the recursion on types later :-(
Var n
Con n
Literal l
App e e
etc.
This introduces overloaded constructors:
HsVar :: (e > Var n) => n -> e
Con :: (e > Con n) => n -> e
Literal :: (e > Literal l) => l -> e
App :: (e > App e1 e2) => e1 -> e2 -> e
and instances:
instance HsExp e n l p > Var n
instance HsExp e n l p > Con n
instance HsExp e n l p > Literal l
instance HsExp e n l p > App e e
A class of the form 't > C t1 t2' allows to create values of type t by
applying the constructor C to values of types t1 and t2, and pattern
match on values of type t using the constructor C with arguments of
types t1 and t2.
In another module you can reuse the same constructor names (they
don't collide as long as the arity is the same). You can also inherit
constructors from other types, similarly as in my records:
data GhcExp e n l p = variant
Haskell98Exp :: HsExp e n l p
Haskell98Exp (Var, Con, Literal, App, etc.)
-- This creates forwarding instances of the appropriate
-- classes, so Var etc. can be used with GhcExp too.
-- Using the constructor Haskell98Exp expresses explicit
-- subtyping/supertyping coercions.
UnboxedTuple [e]
CCall String [e]
And you can define such instances yourself:
instance PackedString > Nil where
-- Construction:
(Nil) = nilPs -- Needs a better syntax. This *defines* Nil.
-- Pattern matching:
s | nullPs -> Nil
-- Matching failure here (because of a failed guard)
-- means that the given value is not considered Nil.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From chak@cse.unsw.edu.au Wed May 23 07:50:42 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Wed, 23 May 2001 16:50:42 +1000
Subject: Poll: System.exitWith behaviour
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611588D@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C611588D@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010523165042H.chak@cse.unsw.edu.au>
"Simon Marlow" wrote,
> The current behaviour of System.exitWith doesn't really make sense in a
> concurrent environment. The current semantics is to:
>
> - halt the current thread
>
> - run all finalizers (concurrently with any other
> currently running threads)
>
> - stop the system as soon as all finalizers have
> finished.
>
> One high-priority problem we also have is that a program which calls
> System.exitWith from inside GHCi will shut down the whole system.
>
> Here's my current proposal:
>
> - introduce a new exception constructor:
> ExitException ExitCode
>
> - System.exitWith causes (ExitException code) to be
> raised in the current thread.
>
> - If this exception propogates to the top of the thread, then
> the main thread is also sent (ExitException code). This
> only happens for a standalone executable (ie. one which was
> started by PrelMain.mainIO).
>
> - If this exception propogates to the top of the main thread,
> then the system is shut down as before - all finalizers are
> run to completion, then we exit.
>
> For GHCi, we can obviously catch the ExitException exception and
> recover, and there is no main thread in this case.
>
> An alternative is just to omit the third point and let the programmer
> handle propagation of the ExitException to the main thread. This is
> somewhat consistent with our current policy of leaving these kind of
> decisions up to the programmer: we currently don't implement any kind of
> process hierarchy, and there is no requirement for child threads to
> complete before the program exits, for example.
I think, having the third point is good, because the Haskell
report requires that
Computation exitWith code terminates the program,
returning code to the program's caller.
Cheers,
Manuel
From simonmar@microsoft.com Wed May 23 10:08:04 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Wed, 23 May 2001 10:08:04 +0100
Subject: Poll: System.exitWith behaviour
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6115890@TVP-MSG-01.europe.corp.microsoft.com>
> I think, having the third point is good, because the Haskell
> report requires that=20
>=20
> Computation exitWith code terminates the program,
> returning code to the program's caller.
Either way we still conform to the report in the case of a single
threaded program (actually, we've already deviated from the report in
allowing you to catch the ExitException and carry on).
For a multi-threaded program, it's not clear to me what exitWith should
do. What should happen if a Haskell callback invokes exitWith? Should
it terminate the Haskell main thread?
I must admit I'm leaning more towards omitting the third point, and
that's what I've implemented for now.
Cheers,=09
Simon
From simonmar@microsoft.com Wed May 23 10:55:39 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Wed, 23 May 2001 10:55:39 +0100
Subject: Endangered I/O operations
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6115891@TVP-MSG-01.europe.corp.microsoft.com>
> > > If you handle std{in,out,err} connectedness in other ways, I
> > > think you've
> > > covered 99.2% of the uses of hConnectTo. Neat idea borrowed from
> > > Korn & Vo's SFIO, but it hasn't proved to be all that useful.
> >
> > I wasn't planning to handle connectedness at all. Is it=20
> important, do
> > you think? (I'm not against the feature, just trying to=20
> avoid feeping
> > creaturism...)
> >
>=20
> Yes, crucial I think - if stdout and stderr are connected to the same
> device,
> don't you want their output to be synchronised, e.g.,
>=20
> main =3D putStr "foo" >> hPutStr stderr " bar"
>=20
> should return "foo bar" on your TTY. Ditto for flushing=20
> stdout/stderr when
> peeking stdin.
You obtain the ordering properties by setting the handle to NoBuffering,
otherwise you get buffered input/output. Wouldn't it be deviating from
the report to do extra flushing in the buffered case? (this is
something of a technicality, actually we already do non-report flushing
in several cases and our line-buffered input isn't line-buffered at
all).
But I'm still not convinced we need to special case this.
Cheers,
Simon
From qrczak@knm.org.pl Wed May 23 08:26:01 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 23 May 2001 07:26:01 GMT
Subject: Poll: System.exitWith behaviour
References: <9584A4A864BD8548932F2F88EB30D1C611588D@TVP-MSG-01.europe.corp.microsoft.com> <20010523165042H.chak@cse.unsw.edu.au>
Message-ID:
Wed, 23 May 2001 16:50:42 +1000, Manuel M. T. Chakravarty pisze:
> I think, having the third point is good, because the Haskell
> report requires that
>
> Computation exitWith code terminates the program,
> returning code to the program's caller.
Well, it says also that
Actions, however, must be ordered in a well-defined manner for
program execution -- and I/O in particular -- to be meaningful.
Haskell 's I/O monad provides the user with a way to specify the
sequential chaining of actions, and an implementation is obliged
to preserve this order.
which is not true in a threaded program.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From sof@galconn.com Wed May 23 18:44:17 2001
From: sof@galconn.com (Sigbjorn Finne)
Date: Wed, 23 May 2001 10:44:17 -0700
Subject: Endangered I/O operations
References: <9584A4A864BD8548932F2F88EB30D1C6115891@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <0ddd01c0e3af$fdbdf300$4576fea9@sofbox>
Simon Marlow writes:
>
....
> You obtain the ordering properties by setting the handle to NoBuffering,
> otherwise you get buffered input/output. Wouldn't it be deviating from
> the report to do extra flushing in the buffered case?
The report is very silent about this, so I guess that reduces the question
to what the end-user would prefer, (a) go non-buffered or make sure you
call hFlush at the right time, or (b) have the IO implementation flush when
required. I prefer (b), which is why I implemented this at the time, as it
is
more useable (and more efficient to boot).
FWIW, notice that stdio implementations diverge on this issue too, all
Win32 impls I've seen does the flushing for you, as did earlier impls of
glibc, I seem to recall.
--sigbjorn
From cwitty@newtonlabs.com Wed May 23 19:35:24 2001
From: cwitty@newtonlabs.com (Carl R. Witty)
Date: 23 May 2001 11:35:24 -0700
Subject: Endangered I/O operations
In-Reply-To: "Simon Marlow"'s message of "Wed, 23 May 2001 10:55:39 +0100"
References: <9584A4A864BD8548932F2F88EB30D1C6115891@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID:
"Simon Marlow" writes:
> You obtain the ordering properties by setting the handle to NoBuffering,
> otherwise you get buffered input/output. Wouldn't it be deviating from
> the report to do extra flushing in the buffered case? (this is
> something of a technicality, actually we already do non-report flushing
> in several cases and our line-buffered input isn't line-buffered at
> all).
If the report does not allow the implementation to flush buffers at
any time, I would call that a bug in the report. I would much rather
use an implementation where stdout and stderr came out in the right
order, and reading from stdin flushed stdout. (As another example, an
implementation might want to flush all buffers before doing a fork(),
to avoid duplicated output.)
The only caveat is that if such flushing is allowed but not required,
it might encourage writing sloppy, nonportable code.
Carl Witty
From kahl@heraklit.informatik.unibw-muenchen.de Wed May 23 20:21:19 2001
From: kahl@heraklit.informatik.unibw-muenchen.de (kahl@heraklit.informatik.unibw-muenchen.de)
Date: 23 May 2001 19:21:19 -0000
Subject: Endangered I/O operations
In-Reply-To: (cwitty@newtonlabs.com)
References: <9584A4A864BD8548932F2F88EB30D1C6115891@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010523192119.3854.qmail@dionysos.informatik.unibw-muenchen.de>
Carl R. Witty writes:
>
> "Simon Marlow" writes:
>
> > You obtain the ordering properties by setting the handle to NoBuffering,
> > otherwise you get buffered input/output. Wouldn't it be deviating from
> > the report to do extra flushing in the buffered case? (this is
> > something of a technicality, actually we already do non-report flushing
> > in several cases and our line-buffered input isn't line-buffered at
> > all).
>
> If the report does not allow the implementation to flush buffers at
> any time, I would call that a bug in the report. I would much rather
> use an implementation where stdout and stderr came out in the right
> order, and reading from stdin flushed stdout. (As another example, an
> implementation might want to flush all buffers before doing a fork(),
> to avoid duplicated output.)
A related wish I have is that a Haskell program receiving a HUP signal
should flush its buffers before terminating.
Or even better, flush on some other signal that does not terminate
the program.
I frequently have long-running (weeks, months ...) applications
that produce data (lists) with decreasing speed.
Since data may be sitting in unflushed buffers for days (weeks, ...),
I currently shy away from using Show instances for lists
and instead use the following ``printList'' function:
> hPutList :: String -> (a -> ShowS) -> Handle -> [a] -> IO ()
> hPutList sep shows h = mapM_ f
> where f x = hPutStr h (shows x sep) >> hFlush h
>
> putList :: String -> (a -> ShowS) -> [a] -> IO ()
> putList sep shows = hPutList sep shows stdout
>
> printList :: Show a => String -> [a] -> IO ()
> printList sep = putList sep shows
It would be really nice to have other possibilities to force the program
to flush buffers!
Cheers,
Wolfram
From qrczak@knm.org.pl Wed May 23 20:55:20 2001
From: qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)
Date: 23 May 2001 19:55:20 GMT
Subject: Poll: System.exitWith behaviour
References: <9584A4A864BD8548932F2F88EB30D1C6115890@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID:
Here is what I just read on comp.lang.python:
| the docs I have say that a thread can stop ITSELF, by raising
| SystemExit, or calling sys.exit().
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
From simonmar@microsoft.com Thu May 24 10:10:15 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Thu, 24 May 2001 10:10:15 +0100
Subject: Endangered I/O operations
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6115894@TVP-MSG-01.europe.corp.microsoft.com>
> A related wish I have is that a Haskell program receiving a HUP signal
> should flush its buffers before terminating.
>=20
> Or even better, flush on some other signal that does not terminate
> the program.
Well, you can catch HUP in the program and initiate a flush. Actually
just doing System.exitWith will cause all the open handles to be flushed
and closed, but note that if you do System.exitWith from a signal
handler it won't terminate the program any more... ;-)
I think we've just found an argument in favour of having System.exitWith
always terminate the program even from a child thread.
If you want to *just* flush all the open handles from a signal handler,
you'll need to keep track of the open handles and flush them by hand
from the signal handler. See the Posix library documentation for
details on setting up a signal handler.
Cheers,
Simon
From v-julsew@microsoft.com Thu May 24 13:57:06 2001
From: v-julsew@microsoft.com (Julian Seward (Intl Vendor))
Date: Thu, 24 May 2001 05:57:06 -0700
Subject: ghc-5.00.1 is available
Message-ID: <68B95AA1648D1840AB0083CC63E57AD60F2323@red-msg-06.redmond.corp.microsoft.com>
The (Interactive) Glasgow Haskell Compiler -- version 5.00.1
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
We are pleased to announce a new patchlevel release of the Glasgow
Haskell Compiler (GHC), version 5.00.1. The source distribution is
freely available via the World-Wide Web and through anon. FTP, under a
BSD-style license. See below for download details. Pre-built
packages for Linux, FreeBSD, and Solaris(sparc) are also available.
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.00.1
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
This is a bug-fix release. Most reported bugs in 5.00 have been
fixed, including a substantial number of show-stopping bugs. The
system should be much more usable for more people. Upgrading to
5.00.1 is recommended. To all those who tried out 5.00 and reported
bugs, we thank you for your feedback and patience.
At the moment there is no Win32 build of 5.00 or 5.00.1 available. We
decided to push Win32 support to the 5.02 release, so as not to delay
5.00.1 any further.
What's new in 5.00
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
5.00 has been majorly revamped since the previous stable version,
4.08.2.
This should be a stable release. Major changes since 4.08.2 are:
- An interactive system, similar in style to Hugs. You can
interactively
load and unload modules, run expressions, ask the types of things.
Module dependencies are tracked and chased automatically.
Combinations of compiled and interpreted modules may be used.
All the GHC libraries are available in interactive mode, as are
most of the Glasgow extensions to Haskell 98. Compilation in
interactive mode (to bytecode) is about three times faster than
compiling to object code.
- Batch compilation of multiple modules at once, with automatic
dependency chasing. For large programs this can halve compilation
times, and removes the need for Makefiles.
- Enhanced package (library) management system. Packages may be
installed and removed from an installation using the ghc-pkg tool.
- Initial Unicode support - the Char type is now 31 bits.
- Sparc native code generator, giving much faster compilation on
sparcs.
(Native code generation for x86s has been available for a while).
- Improved heap profiling - you can restrict heap profiles
by type, closure description, cost centre, and module.
- Support for the latest Foreign Function Interface (FFI)
proposals. Marcin Kowalczyk's hsc2hs tool is included.
- Language extensions: parallel list comprehensions and functional
dependencies.
- The usual huge collection of bug fixes. Most reported bugs have
been fixed.
For full details see the release notes:
http://www.haskell.org/ghc/docs/5.00/set/release-5-00.html
How to get it
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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 .rpm/.deb form for all you Linux junkies
out there, 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
To compile programs with GHC, you need a machine with 32+MB memory, GNU
C
and perl. This release is known to work on the following platforms:
* i386-unknown-{linux,freebsd,mingw32}
* sparc-sun-solaris2
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
* alpha-dec-osf{2,3}
* 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/5.00/building/building-guide.html
Mailing lists
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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 send bug reports about GHC to glasgow-haskell-bugs@haskell.org;
GHC users hang out on glasgow-haskell-users@haskell.org. Bleeding
edge CVS users party on cvs-ghc@haskell.org.
From simonmar@microsoft.com Thu May 24 10:05:59 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Thu, 24 May 2001 10:05:59 +0100
Subject: Endangered I/O operations
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD6F5@TVP-MSG-01.europe.corp.microsoft.com>
> Simon Marlow writes:
> >
> ....
> > You obtain the ordering properties by setting the handle to=20
> NoBuffering,
> > otherwise you get buffered input/output. Wouldn't it be=20
> deviating from
> > the report to do extra flushing in the buffered case?
>=20
> The report is very silent about this, so I guess that reduces=20
> the question
> to what the end-user would prefer, (a) go non-buffered or=20
> make sure you
> call hFlush at the right time, or (b) have the IO=20
> implementation flush when
> required. I prefer (b), which is why I implemented this at=20
> the time, as it
> is
> more useable (and more efficient to boot).
>=20
> FWIW, notice that stdio implementations diverge on this issue too, all
> Win32 impls I've seen does the flushing for you, as did=20
> earlier impls of
> glibc, I seem to recall.
Ok, the concensus seems to be that folk would prefer the flushing to be
done automatically. There's bound to be some overhead, though...
Cheers,
Simon
From Dominic.J.Steinitz@BritishAirways.com Thu May 24 18:47:42 2001
From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J)
Date: 24 May 2001 17:47:42 Z
Subject: ghc-5.00.1 is available
Message-ID: <"04CAB3B0D493E00E*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
Will this
- Initial Unicode support - the Char type is now 31 bit
cause me a problem?
I am sending protocol elements via a socket. I represent these as [Word8]. I had assumed that when I want to send something I do
hPutStr (map (ord .word8ToInt) protocolElement)
essentially doing a type coercion. But this looks like bits actually get changed into something the respondent won't recognise.
Dominic.
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
From Dominic.J.Steinitz@BritishAirways.com Thu May 24 22:48:11 2001
From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J)
Date: 24 May 2001 21:48:11 Z
Subject: ghc-5.00.1 is available
Message-ID: <"046603B0D819B004*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
Of course I meant
hPutStr handle (map (chr .word8ToInt) protocolElement)
Dominic J Steinitz@baexternal
24/05/2001 18:47
To: v-julsew
cc: glasgow-haskell-users
haskell
bcc: Dominic Steinitz
Subject: Re: ghc-5.00.1 is available
Will this
- Initial Unicode support - the Char type is now 31 bit
cause me a problem?
I am sending protocol elements via a socket. I represent these as [Word8]. I had
assumed that when I want to send something I do
hPutStr (map (ord .word8ToInt) protocolElement)
essentially doing a type coercion. But this looks like bits actually get changed
into something the respondent won't recognise.
Dominic.
--------------------------------------------------------------------------------
-----------------
21st century air travel http://www.britishairways.com
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com
From chak@cse.unsw.edu.au Fri May 25 01:56:36 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Fri, 25 May 2001 10:56:36 +1000
Subject: Poll: System.exitWith behaviour
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C6115890@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C6115890@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID: <20010525105636E.chak@cse.unsw.edu.au>
"Simon Marlow" wrote,
> > I think, having the third point is good, because the Haskell
> > report requires that
> >
> > Computation exitWith code terminates the program,
> > returning code to the program's caller.
>
> Either way we still conform to the report in the case of a single
> threaded program (actually, we've already deviated from the report in
> allowing you to catch the ExitException and carry on).
>
> For a multi-threaded program, it's not clear to me what exitWith should
> do. What should happen if a Haskell callback invokes exitWith? Should
> it terminate the Haskell main thread?
>
> I must admit I'm leaning more towards omitting the third point, and
> that's what I've implemented for now.
If you call exit() in a multi-threaded C program, it is also
gone.
Cheers,
Manuel
From mechvel@math.botik.ru Fri May 25 06:21:25 2001
From: mechvel@math.botik.ru (S.D.Mechveliani)
Date: Fri, 25 May 2001 09:21:25 +0400
Subject: building from source in User's guide
Message-ID:
GHC-5.xxx User's Guide explains binary installation.
But I cannot find there about making from sources.
Am I missing something?
-----------------
Serge Mechveliani
mechvel@botik.ru
From simonmar@microsoft.com Fri May 25 09:50:12 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Fri, 25 May 2001 09:50:12 +0100
Subject: building from source in User's guide
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD701@TVP-MSG-01.europe.corp.microsoft.com>
> GHC-5.xxx User's Guide explains binary installation.
> But I cannot find there about making from sources.=20
> Am I missing something?
The Building Guide is a separate document, available on-line here:
http://www.haskell.org/ghc/docs/latest/building/building-guide.html
Cheers,
Simon
From simonmar@microsoft.com Fri May 25 10:18:02 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Fri, 25 May 2001 10:18:02 +0100
Subject: GHCi 5.00.1: packages can now be loaded at the prompt
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD704@TVP-MSG-01.europe.corp.microsoft.com>
A new feature slipped into 5.00.1, but it looks like the documentation
to go with it didn't get merged (probably my fault, sorry about that).
You can now load packages from the GHCi prompt, like so:
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 5.00.1, For Haskell
98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package std ... linking ... :done.
Prelude> :set -package lang
Loading package lang ... linking ... done.
Prelude> :set -package util
Loading package concurrent ... linking ... done.
Loading package posix ... linking ... done.
Loading package util ... linking ... done.
Prelude>=20
This means you can also load packages from .ghci files too.
Cheers,
Simon
From chak@cse.unsw.edu.au Sat May 26 13:53:43 2001
From: chak@cse.unsw.edu.au (Manuel M. T. Chakravarty)
Date: Sat, 26 May 2001 22:53:43 +1000
Subject: ghc-5.00.1 is available
In-Reply-To: <68B95AA1648D1840AB0083CC63E57AD60F2323@red-msg-06.redmond.corp.microsoft.com>
References: <68B95AA1648D1840AB0083CC63E57AD60F2323@red-msg-06.redmond.corp.microsoft.com>
Message-ID: <20010526225343M.chak@cse.unsw.edu.au>
"Julian Seward (Intl Vendor)" wrote,
> The (Interactive) Glasgow Haskell Compiler -- version 5.00.1
> ==============================================================
>
> We are pleased to announce a new patchlevel release of the Glasgow
> Haskell Compiler (GHC), version 5.00.1.
There are rpm packages for x86 GNU/Linux now. For glibc 2.2
systems, build on RedHat 7.0, we have
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-5.00.1-1.i386.rpm
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-prof-5.00.1-1.i386.rpm
For RedHat 6.2, we have
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386-rh6.2/ghc-5.00.1-1.i386.rpm
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386-rh6.2/ghc-prof-5.00.1-1.i386.rpm
The matching source rpm is at
ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/src/ghc-5.00.1-1.src.rpm
The RedHat 6.2 packages have been kindly contributed by Tom
Moertel.
Cheers,
Manuel
PS: The problems with the documentation in the 5.00 rpms
have been resolved (at least in the RH7.0 packages, I
didn't check the others).
From tom-list-glasgow-haskell-users@moertel.com Sat May 26 17:10:44 2001
From: tom-list-glasgow-haskell-users@moertel.com (Tom Moertel)
Date: Sat, 26 May 2001 12:10:44 -0400
Subject: ghc-5.00.1 is available
References: <68B95AA1648D1840AB0083CC63E57AD60F2323@red-msg-06.redmond.corp.microsoft.com> <20010526225343M.chak@cse.unsw.edu.au>
Message-ID: <3B0FD584.4D1FFF37@moertel.com>
"Manuel M. T. Chakravarty" wrote:
> [...]
> PS: The problems with the documentation in the 5.00 rpms
> have been resolved (at least in the RH7.0 packages, I
> didn't check the others).
The documentation in the Red Hat 6x package looks fine as well.
Cheers,
Tom
From jak97@doc.ic.ac.uk Sun May 27 19:24:12 2001
From: jak97@doc.ic.ac.uk (John Knottenbelt)
Date: Sun, 27 May 2001 19:24:12 +0100
Subject: Evacuated Object
Message-ID: <01052719241200.14101@buffy.home.net>
I'm experimenting with GHC (5.00.1) on RedHat Linux 7.1, it's foreign
function interface (using .hsc files) and the SDL graphics library (v1.2).
The curious thing is that the following code:
main = sdlInit [sdlVideo[
sdlQuit
can be loaded into GHCi and executed as many times as I like, however,
if I then carry on and edit the module containing main, and then perform a
reload (:r), I sometimes get an "EVACUATED object entered!" message and GHC
crashes on me:
TestGraphics> :r
Compiling TestGraphics ( TestGraphics.hs, interpreted )
Ok, modules loaded: TestGraphics, SDL, Rectangle, SDLEvents, SDLKeySyms,
ForeignUtil.
TestGraphics> main
EVACUATED object entered!
make: *** [interactive] Error 1
bash$
What does this error mean, and why is it only triggered when I perform a
reload in GHCi?
Sometimes the reload works fine, and other times I get a segmentation fault.
Thanks
John
From simonpj@microsoft.com Mon May 28 10:07:24 2001
From: simonpj@microsoft.com (Simon Peyton-Jones)
Date: Mon, 28 May 2001 02:07:24 -0700
Subject: Evacuated Object
Message-ID: <37DA476A2BC9F64C95379BF66BA26902D72FB1@red-msg-09.redmond.corp.microsoft.com>
The error means that GHC's garbage collector has come
across something it doesn't understand.
It's either a bug in the GHC garbage collector, or in GHCi itself
(which plays fast and loose with types in one or two places) or in=20
something to do with the SDL graphics interface. =20
Bugs like this are really hard to find, unless we can reproduce them
here. Can you send us all the code?
Simon
| -----Original Message-----
| From: John Knottenbelt [mailto:jak97@doc.ic.ac.uk]=20
| Sent: 27 May 2001 19:24
| To: glasgow-haskell-users@haskell.org
| Subject: Evacuated Object
|=20
|=20
| I'm experimenting with GHC (5.00.1) on RedHat Linux 7.1, it's foreign=20
| function interface (using .hsc files) and the SDL graphics=20
| library (v1.2).=20
| The curious thing is that the following code:
|=20
| main =3D sdlInit [sdlVideo[
| sdlQuit
|=20
| can be loaded into GHCi and executed as many times as I like,=20
| however, if I then carry on and edit the module containing=20
| main, and then perform a=20
| reload (:r), I sometimes get an "EVACUATED object entered!"=20
| message and GHC=20
| crashes on me:
|=20
| TestGraphics> :r
| Compiling TestGraphics ( TestGraphics.hs, interpreted )
| Ok, modules loaded: TestGraphics, SDL, Rectangle, SDLEvents,=20
| SDLKeySyms,=20
| ForeignUtil.
| TestGraphics> main
| EVACUATED object entered!
| make: *** [interactive] Error 1
| bash$
|=20
| What does this error mean, and why is it only triggered when=20
| I perform a=20
| reload in GHCi?
|=20
| Sometimes the reload works fine, and other times I get a=20
| segmentation fault.
|=20
| Thanks
|=20
| John
|=20
| _______________________________________________
| Glasgow-haskell-users mailing list=20
| Glasgow-haskell-users@haskell.org=20
| http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users
|=20
From jak97@doc.ic.ac.uk Mon May 28 11:45:03 2001
From: jak97@doc.ic.ac.uk (John Knottenbelt)
Date: Mon, 28 May 2001 11:45:03 +0100
Subject: Evacuated Object
In-Reply-To: <37DA476A2BC9F64C95379BF66BA26902D72FB1@red-msg-09.redmond.corp.microsoft.com>
References: <37DA476A2BC9F64C95379BF66BA26902D72FB1@red-msg-09.redmond.corp.microsoft.com>
Message-ID: <01052811450300.01581@buffy.home.net>
Thanks for having a look at this. The sourcecode is available from
http://www.doc.ic.ac.uk/~jak97/graphics.tgz
Please let me know if you have any difficulties building.
SDL is available from
http://www.libsdl.org
and SDL_image is available from
http://www.devolution.com/~slouken/SDL/projects/SDL_image/
Cheers
John
On Monday 28 May 2001 10:07 am, you wrote:
> The error means that GHC's garbage collector has come
> across something it doesn't understand.
>
> It's either a bug in the GHC garbage collector, or in GHCi itself
> (which plays fast and loose with types in one or two places) or in
> something to do with the SDL graphics interface.
>
> Bugs like this are really hard to find, unless we can reproduce them
> here. Can you send us all the code?
>
> Simon
From mechvel@math.botik.ru Tue May 29 09:44:42 2001
From: mechvel@math.botik.ru (S.D.Mechveliani)
Date: Tue, 29 May 2001 12:44:42 +0400
Subject: creating packages
Message-ID:
Who could, please, consult on the package setting in ghc-5.00.1
?
Let the project foo consist of the files /t/A.hs
/t/t1/B.hs,
B import A,
the user work in /u/ and exploit foo in compiling, linking
and interpreting.
Everything seems to work below, except `ghci -package'
and `ghc -c -package-name foo'
(ghc-5.00.1 compiled from source for Linux, i386-unknown).
What I do:
-------------------------------------------------
* apply ghc --make B;
* move all *.o *.hi files to /t/export/ ;
* command cd /t/export/
ar -q libHSfoo.a *.o (creating a library)
* create a file p.txt containing
Package {name = "foo",
import_dirs = ["/t/export" ],
source_dirs = [],
library_dirs = ["/t/export" ],
hs_libraries = ["HSfoo"],
extra_libraries = [],
include_dirs = [], c_includes = [],
package_deps = [], extra_ghc_opts = [],
extra_cc_opts = [], extra_ld_opts = []
}
and apply ghc-pkg -a < p.txt
adding a package foo to ghc.
-------------------------------------------------
Then, for the user module /u/Main.hs
importing B,
the user commands cd /u; ghc -c -package foo Main.hs
ghc -o run Main.o -package foo
- and it works.
But ghci -package foo
yields
Loading package foo ... can't find .o or .so/.DLL for: HSfoo
(libHSfoo.so: cannot open shared object file: No such file or directory)
Then, I added /t/export/libHSdocon.so,
but it does not help.
Also ghc -c -package-name foo C.hs
does not work.
May ghc -c -package-name
do automatically all this mess with moving .o, .hi files and
archivating?
Thank you in advance for the help.
-----------------
Serge Mechveliani
mechvel@botik.ru
From trb@eastpac.com.au Tue May 29 11:11:47 2001
From: trb@eastpac.com.au (trb@eastpac.com.au)
Date: Tue, 29 May 2001 20:11:47 +1000 (EST)
Subject: building Green Card using ghc-5
Message-ID:
I finally got Green Card 2.01 to build with ghc-5.00 .
There are two changes required:
* replace all uses of -syslib with -package in src/Makefile
* remove src/Pretty.lhs src/FiniteMap.lhs and src/GetOpt.lhs
- the latter (redundant) source files upset ghc when it tries to import the same
modules from packages.
Tim
From trb@eastpac.com.au Tue May 29 12:13:16 2001
From: trb@eastpac.com.au (trb@eastpac.com.au)
Date: Tue, 29 May 2001 21:13:16 +1000 (EST)
Subject: building Green Card using ghc-5 continued
Message-ID:
Oops - there is one more change needed:
add -package lang to HC_OPTS in lib/ghc/Makefile
I have not tried using it with Hugs.
Tim
From simonmar@microsoft.com Tue May 29 11:17:43 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Tue, 29 May 2001 11:17:43 +0100
Subject: creating packages
Message-ID: <9584A4A864BD8548932F2F88EB30D1C61158A4@TVP-MSG-01.europe.corp.microsoft.com>
> Who could, please, consult on the package setting in ghc-5.00.1
> ?
> Let the project foo consist of the files /t/A.hs
> /t/t1/B.hs,
> B import A,
> the user work in /u/ and exploit foo in compiling, linking
> and interpreting.
>=20
> Everything seems to work below, except `ghci -package'=20
> and `ghc -c -package-name foo'
>=20
> (ghc-5.00.1 compiled from source for Linux, i386-unknown).=20
> What I do:
>=20
> -------------------------------------------------
> * apply ghc --make B;
That should be=20
=09
ghc -package-name foo --make B.
because you're building modules for package 'foo'.
> * move all *.o *.hi files to /t/export/ ;
> * command cd /t/export/
> ar -q libHSfoo.a *.o (creating a library)
>=20
> * create a file p.txt containing
>=20
> Package {name =3D "foo",
> import_dirs =3D ["/t/export" ],
> source_dirs =3D [],
> library_dirs =3D ["/t/export" ],
> hs_libraries =3D ["HSfoo"],
> extra_libraries =3D [],
> include_dirs =3D [], c_includes =3D [],
> package_deps =3D [], extra_ghc_opts =3D [],
> extra_cc_opts =3D [], extra_ld_opts =3D []
> }
> and apply ghc-pkg -a < p.txt
> adding a package foo to ghc.
> -------------------------------------------------
>=20
> Then, for the user module /u/Main.hs
> importing B,
> the user commands cd /u; ghc -c -package foo Main.hs
> ghc -o run Main.o -package foo
> - and it works.
> But ghci -package foo
> yields
> Loading package foo ... can't find .o or .so/.DLL for: HSfoo=20
> (libHSfoo.so: cannot open shared object file: No such file=20
> or directory)
GHCi can't load .a files (at the moment). You can build a .o file from
a .a file like so (with GNU ld):
ld --whole-archive libHSfoo.a -o libHSfoo.o
Cheers,
Simon
From electrorb@yahoo.com Wed May 30 05:08:53 2001
From: electrorb@yahoo.com (hooh pxw)
Date: Tue, 29 May 2001 21:08:53 -0700 (PDT)
Subject: ghc-5.00.1 compiling with pw32 for win32.
Message-ID: <20010530040853.51180.qmail@web10005.mail.yahoo.com>
Hi, i am new comer/bie.
--*PW32 the Posix-over-Win32 layer*--
http://sourceforge.net/projects/pw32
PW32 is primarily C runtime library for Win32 aiming
to POSIX compliance. Its main concerns are effeciency
and support even for low-end Win9x systems. Also, PW32
is collection of ported software, aiming to be GNU
(etc.) distribution for Win32. LGPL.
i have no time to test. if this work, tell me.
sorry my lazy cut/paste.
global funny thing? no *.hi file errors.
ignore below message...
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
From mechvel@math.botik.ru Wed May 30 13:00:58 2001
From: mechvel@math.botik.ru (S.D.Mechveliani)
Date: Wed, 30 May 2001 16:00:58 +0400
Subject: package for ghci
Message-ID:
To my questions on the package creation for ghci -package
>> ...
>> How should look a package for this?
Simon Marlow writes
> The "package" consists of libraries, .hi files, and a package
> specification. Which bit did you mean?
I meant all the three + a whole story of its correct arrangement -
to illustrate it on the given example of a single module project.
But as you said, my scheme of action in mainly correct.
So, let us go further.
>> Is it created manually or by ghc -package-name ... ?
>> ...
>> For I have an impression that the ghc-5.00 User's guide cannot
>> help in this situation.
> The user's guide says, about -package-name:
>
> This option is added to the command line when compiling a
> module that is destined to be part of package foo. If this
> flag is omitted then the default package Main is assumed.
>
> seems fairly clear to me... which part are you confused about?
I expected that the user would not need to
(1) move .hi, .o files manually to /t/export,
collecting them from all the project directories
(2) archivate manually *.o to .a library,
(maybe) (3) create manually the structure Package {...}.
Note that the application project forces the user to do all this
manually to install the project.
I hoped -package-name --make
would do (1) and (2).
This fragment of User's Guide does not reject such hope.
> Which parts of the documentation aren't being helpful to you?
> [..]
It looks that a newbie would not find out the needed order of
action:
1. package specification, 2. ghc-pkg ... 3. ghc --make ...,
4. moving files and archivating to library.
Does the Guide specify such order?
Is it clear from the Guide which of these points can be done
automatically?
Where it is explained how to create a library .a from *.o ?
A naive functional programmer would not know this, maybe, this is
a system hacker's territory (?).
I may mistake, this is only my impression.
>> Then, after creating manually /t/export/libHSfoo.a
>> and converting it by
>> ld -r --whole-archive libHSfoo.a -o libHSfoo.o
>> [..]
>>
>> it still does not work. ghci -package foo
>> yields
>> Loading package foo ... can't find .o or .so/.DLL for: HSfoo
>> (libHSfoo.so: cannot open shared object file: No such file
> It looks like there may be a problem with your package spec.
> Could you list the contents of p.txt that you used to create the
> package?
I would reproduce the whole (short) story.
-------------------------------------------------------
/home/mechvel/t/A.hs
contains module A where a = 'a'
and is one file project to build a package foo
to reside in the directory
/home/mechvel/t/export/
/home/mechvel/u/Main.hs
imitates the user work with the package foo. It contains
module Main where import A
main = putStr ['b', a, '\n']
1. Apply ghc-pkg -a < p.txt
with p.txt containing
Package {name = "foo",
import_dirs = ["/home/mechvel/t/export" ],
source_dirs = [],
library_dirs = ["/home/mechvel/t/export" ],
hs_libraries = ["HSfoo"],
extra_libraries = ["HSfoo"],
include_dirs = [], c_includes = [],
package_deps = [], extra_ghc_opts = [],
extra_cc_opts = [], extra_ld_opts = []
}
2. Test it with ghc-pkg -l
3. cd ~/t
ghc -package-name foo --make A
4. mv *.hi *.o export/
cd export
5. ar -q libHSfoo.a *.o
ld -r --whole-archive libHSdocon.a -o libHSdocon.o
-----------------------------------------------------------
cd ~/t
ghci -package foo
...
Loading package std ... linking ... done.
Loading package foo ... ghc-5.00.1: can't find .o or .so/.DLL for:
HSfoo (libHSfoo.so: cannot open shared object file:
No such file or directory)
Regards,
-----------------
Serge Mechveliani
mechvel@botik.ru
From simonmar@microsoft.com Wed May 30 14:22:44 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Wed, 30 May 2001 14:22:44 +0100
Subject: Evacuated Object
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD72F@TVP-MSG-01.europe.corp.microsoft.com>
> I'm experimenting with GHC (5.00.1) on RedHat Linux 7.1, it's foreign=20
> function interface (using .hsc files) and the SDL graphics=20
> library (v1.2).=20
> The curious thing is that the following code:
>=20
> main =3D sdlInit [sdlVideo[
> sdlQuit
>=20
> can be loaded into GHCi and executed as many times as I like, however,
> if I then carry on and edit the module containing main, and=20
> then perform a=20
> reload (:r), I sometimes get an "EVACUATED object entered!"=20
> message and GHC=20
> crashes on me:
Great bug! I managed to reproduce it here (except that I get a plain
seg fault not a GC panic), and it turns out to be an obscure bug in the
native code generator that only shows up with GHCi. Compiling the
program with -fvia-C works around it.
Many thanks for the report.
Cheers,
Simon
From simonmar@microsoft.com Wed May 30 14:01:21 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Wed, 30 May 2001 14:01:21 +0100
Subject: package for ghci
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD72C@TVP-MSG-01.europe.corp.microsoft.com>
> 5. ar -q libHSfoo.a *.o
> ld -r --whole-archive libHSdocon.a -o libHSdocon.o
Here's your problem: you named the output libHSdocon.o, but GHCi is
looking for HSfoo.o (because that's the name you gave in the package
spec).
True, the documentation doesn't give explicit instructions for building
a package from start to finish. I'll add something for a future
release.
Cheers,
Simon
From reid@cs.utah.edu Wed May 30 21:29:32 2001
From: reid@cs.utah.edu (Alastair David Reid)
Date: 30 May 2001 14:29:32 -0600
Subject: Poll: System.exitWith behaviour
In-Reply-To: <9584A4A864BD8548932F2F88EB30D1C611588D@TVP-MSG-01.europe.corp.microsoft.com>
References: <9584A4A864BD8548932F2F88EB30D1C611588D@TVP-MSG-01.europe.corp.microsoft.com>
Message-ID:
"Simon Marlow" writes:
> One high-priority problem we also have is that a program which calls
> System.exitWith from inside GHCi will shut down the whole system.
> [...]
> we currently don't implement any kind of process hierarchy, and
> there is no requirement for child threads to complete before the
> program exits, for example.
The approach we've taken here in Utah (in the context of Java
operating systems) is to apply the following (standard) distinction
between threads and processes:
o Threads provide multiple concurrent streams of execution (and nothing
else).
Threads are not strongly isolated from each other so killing
a thread can fatally wound another thread, redirecting stdout
will affect other threads, etc.
o Processes are sets of threads which are isolated from each other.
In particular, you can kill one process without affecting the
integrity of other processes and you can redirect stdout in one
process independently of other processes.
Processes are usually implemented using memory protection and often
implies separate address spaces in OSs like Unix and Windows but, in
the OS research community, that is viewed as an implementation
technique rather than being part of the definition. (For example,
there are a number of single address space operating systems (SASOS)
and early JavaOSs tried to use strong typechecking in place of
memory protection.)
[Isolation may mean different things in different systems. For
example, you might want to enforce some resource limits to protect
processes against memory, cpu or bandwidth hogs.]
Translating this into the GHCi situation, it seems that you want to
treat GHCi and the user's program as two separate processes and we can
imagine that anyone else writing an interpreter in Haskell would want
to do so too. (e.g., it might be a useful way of structuring my
graphics library too).
When you come to implement this model, another useful concept from
operating systems is the notion of a "red line". This is the border
between "untrusted" user code and "trusted" system code. In a
conventional OS, this line is the user-kernel boundary and is
implemented using system calls, hardware traps, file descriptor
tables, etc. but the concept is useful even if it is implemented using
a combination of type safety, careful programming and exception
handlers. In the current system, most of the IO library should lie
beneath the red line. If a notion of process were added, then some
parts of process creation/killing, running of finalizers, locking,
etc. would lie beneath the red line. The value of this concept is:
1) Having a word for it.
2) As long as you have a clear statement of what level of "isolation"
you want to achieve, you have a clear definition of what you have
to protect against when you cross the red line. This is useful for
answering questions like: Is it enough to add an exception handler?
Should you add a timeout mechanism too? What resources have to be
revocable? What resources need an extra layer of indirection so
that you can implement different namespaces (e.g., file descriptors
in Unix allow different processes to define stdout differently)
Godmar Back (http://www.cs.utah.edu/~gback/) has explored this in
detail (it will form part of his forthcoming PhD thesis):
http://www.cs.utah.edu/flux/papers/redline-hotos7-base.html
http://www.cs.utah.edu/flux/papers/kaffeos-osdi00-base.html
Matthew Flatt (http://www.cs.utah.edu/~mflatt/) has encountered
similar issues in MrEd/DrScheme/MzScheme (which is more or less GHCi
for Scheme):
http://www.cs.rice.edu/CS/PLT/Publications/icfp99-ffkf.pdf
Godmar emphasises the OS side of things whereas Matthew comes at the
same issues from a language point of view.
--
Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
From mechvel@math.botik.ru Thu May 31 06:59:59 2001
From: mechvel@math.botik.ru (S.D.Mechveliani)
Date: Thu, 31 May 2001 09:59:59 +0400
Subject: package for ghci
Message-ID:
To my question on packages for ghci
Simon Marlow responds
>> 5. ar -q libHSfoo.a *.o
>> ld -r --whole-archive libHSdocon.a -o libHSdocon.o
> Here's your problem: you named the output libHSdocon.o, but GHCi is
> looking for HSfoo.o (because that's the name you gave in the package
> spec).
>
> ld -r --whole-archive libHSfoo.a -o libHSfoo.o
>
> [..]
Thank you.
The matter was indeed in the name.
And it was due to the `lib' prefix, not due to `docon'.
Because there was a typo in my letter:
...--whole-archive libHSfdocon.a ...
while in real experiment it was ...--whole-archive libHSfoo.a ...
And I doubt whether the GHC implementation agrees at this point with
the GHC User's guide. Section 4.11.2 says
----------------------------------------------
A package specification looks like this:
Package {name = "mypkg"
hs_libraries = ["HSmypkg"]
...
}
...
hs_libraries
A list of libraries containing Haskell code for this package,
with the .a or .dll suffix omitted.
On Unix, the `lib' prefix is also omitted.
extra_libraries ...
----------------------------------------------
The user (myself) thinks at this:
"HSmypkg" in package specification --> HSmypkg.a
HSmypkg.o
in the library directory.
But " `lib' is also omitted " - similarly as `.a'.
Hence, the library directory should contain
libHSmypkg.a libHSmypkg.o
Now, ghci -package-mypkg
sees "HSmypkg" in package specification but searches for the file
HSmypkg.o.
It adds `.o', but skips `lib'.
On the other hand, `.o' has different status, it is separated by
period. So I wonder.
Regards,
-----------------
Serge Mechveliani
mechvel@botik.ru
From D.Evers@artemis-pharmaceuticals.de Thu May 31 08:45:48 2001
From: D.Evers@artemis-pharmaceuticals.de (Dirk Evers)
Date: Thu, 31 May 2001 09:45:48 +0200
Subject: package for ghci
In-Reply-To:
Message-ID:
Hi,
(second time: Outlook tricked me: wrong email address
I really love this mailer. :-( )
The lib prefix convention is only for .a and .so files,
.o files do not fall under this convention, so:
ld -r --whole-archive libHSfoo.a -o HSfoo.o
is what should work for you.
Cheers
Dirk
> -----Original Message-----
> From: glasgow-haskell-users-admin@haskell.org
> [mailto:glasgow-haskell-users-admin@haskell.org]On Behalf Of
> S.D.Mechveliani
> Sent: Thursday, May 31, 2001 8:00 AM
> To: glasgow-haskell-users@haskell.org
> Cc: simonmar@microsoft.com
> Subject: package for ghci
>=20
>=20
> To my question on packages for ghci
> Simon Marlow responds
>=20
> >> 5. ar -q libHSfoo.a *.o
> >> ld -r --whole-archive libHSdocon.a -o libHSdocon.o
>=20
> > Here's your problem: you named the output libHSdocon.o, but GHCi is
> > looking for HSfoo.o (because that's the name you gave in the package
> > spec).
> >
> > ld -r --whole-archive libHSfoo.a -o libHSfoo.o
> >=20
> > [..]
>=20
>=20
> Thank you.=20
> The matter was indeed in the name.
> And it was due to the `lib' prefix, not due to `docon'.
>=20
> Because there was a typo in my letter:=20
> ...--whole-archive libHSfdocon.a ...
> while in real experiment it was ...--whole-archive libHSfoo.a ...
>=20
> And I doubt whether the GHC implementation agrees at this point with=20
> the GHC User's guide. Section 4.11.2 says
>=20
> ----------------------------------------------
> A package specification looks like this:
>=20
> Package {name =3D "mypkg"
> hs_libraries =3D ["HSmypkg"]
> ...
> }
> ...
> hs_libraries
> A list of libraries containing Haskell code for this package,
> with the .a or .dll suffix omitted.
> On Unix, the `lib' prefix is also omitted.
>=20
> extra_libraries ...=20
> ----------------------------------------------
>=20
> The user (myself) thinks at this:
> "HSmypkg" in package specification --> HSmypkg.a
> HSmypkg.o
> in the library directory.
>=20
> But " `lib' is also omitted " - similarly as `.a'.
> Hence, the library directory should contain
> libHSmypkg.a libHSmypkg.o
> Now, ghci -package-mypkg =20
>=20
> sees "HSmypkg" in package specification but searches for the file =20
> HSmypkg.o. =20
> It adds `.o', but skips `lib'.
> On the other hand, `.o' has different status, it is separated by
> period. So I wonder.
>=20
> Regards,
>=20
> -----------------
> Serge Mechveliani
> mechvel@botik.ru
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
From mechvel@math.botik.ru Thu May 31 09:31:39 2001
From: mechvel@math.botik.ru (S.D.Mechveliani)
Date: Thu, 31 May 2001 12:31:39 +0400
Subject: extending --make
Message-ID:
Hello,
I have a whish for the GHC `making' possibilities.
ghc-5* -package-name --make
is said trying to replace Makefile. But it is half-successful.
* First, it needs -ohi option working
(to move .hi -s to chosen directory).
* Second, could GHC provide options for creating libraries,
adding to library?
Explanation.
With ghc-4, I used Makefile and -odir, -ohi options to provide
the project installation.
Makefile contained
(1)
the project directory tree description,
variables holding the list of names for the .hs, .hi, .o files,
rules to convert .hs --> .o, and such.
Also it contained the library creation part:
(2)
foo: $(objectFiles)
ar -q export/libHSfoo.a `ls export/*.o`
ranlib export/libHSfoo.a
rm -f `ls export/*.o`
-------------------
Now, with ghc-5, I apply
ghc -package-name foo -odir export ... --make ..
The part (1) cancels due to --make.
Further, as ghc-5 observes in the package specification
library_dirs = [".../export"]
hs_libraries = ["libHSfoo"],
then, it can understand what library file is to be created - on
demand.
If ghc -c provided also the options like -addto-lib -a,
-addto-lib -o,
...
then it could `make' for the given package _with_ adding to
library. So, GHC would be able to simplify Makefile to package
setting.
The matter is that Makefile has a strange language, far from
Haskell. Also why the Haskell user has to study library creation
with `ar', `ranlib, `ld'? This, and Makefile look rather like a
system hackering.
Regards,
-----------------
Serge Mechveliani
mechvel@botik.ru
From simonmar@microsoft.com Thu May 31 11:10:55 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Thu, 31 May 2001 11:10:55 +0100
Subject: package for ghci
Message-ID: <9584A4A864BD8548932F2F88EB30D1C6058DD736@TVP-MSG-01.europe.corp.microsoft.com>
> The user (myself) thinks at this:
> "HSmypkg" in package specification --> HSmypkg.a
> HSmypkg.o
> in the library directory.
I've clarified this in the documentation, thanks for the comments.
Cheers,
Simon
From simonmar@microsoft.com Thu May 31 13:53:41 2001
From: simonmar@microsoft.com (Simon Marlow)
Date: Thu, 31 May 2001 13:53:41 +0100
Subject: extending --make
Message-ID: <9584A4A864BD8548932F2F88EB30D1C61158AD@TVP-MSG-01.europe.corp.microsoft.com>
> I have a whish for the GHC `making' possibilities.
>=20
> ghc-5* -package-name --make=20
>=20
> is said trying to replace Makefile. But it is half-successful.
> * First, it needs -ohi option working=20
> (to move .hi -s to chosen directory).
I've added a -hidir option which should do the right thing.
> * Second, could GHC provide options for creating libraries,=20
> adding to library?
This might make it easier to build a library from Haskell files, but it
would also be duplicating functionality that is already available. I
don't see it as a priority, I'm afraid.
> Explanation.
> With ghc-4, I used Makefile and -odir, -ohi options to provide
> the project installation.=20
> Makefile contained=20
> (1)
> the project directory tree description,
> variables holding the list of names for the .hs, .hi, .o files,=20
> rules to convert .hs --> .o, and such.
> Also it contained the library creation part:
> (2)
> foo: $(objectFiles)
> ar -q export/libHSfoo.a `ls export/*.o`
> ranlib export/libHSfoo.a
> rm -f `ls export/*.o`
So you can use the same makefile, but you can replace part (1) with a
single rule which uses --make.
Cheers,
Simon
From Dominic.J.Steinitz@BritishAirways.com Thu May 31 15:18:09 2001
From: Dominic.J.Steinitz@BritishAirways.com (Steinitz, Dominic J)
Date: 31 May 2001 14:18:09 Z
Subject: Socket Behaviour
Message-ID: <"074D83B1652A100D*/c=GB/admd=ATTMAIL/prmd=BA/o=British Airways PLC/ou=CORPLN1/s=Steinitz/g=Dominic/i=J/"@MHS>
Can anyone tell me why the following code doesn't work as expected? Both the server and client hang. If I run
server 20000 &
and
client 20000
the server logfile produces
[dom@lhrtba8fd85 twotest]$ more log.txt
Thu May 31 14:35:39 BST 2001
Starting logging
Thu May 31 14:36:08 BST 2001
Hello world 48 65 6c 6c 6f 20 77 6f 72 6c 64
so it looks like the hPutStrLn to the socket never completes. On the client side, "Hello world" gets sent but the hGetLine never completes.
Client
do sh <- connectTo host port
hPutStr sh "Hello world"
hFlush sh
x <- hGetLine sh
putStrLn x
Server
socket <- listenOn port
(sh,host,portid) <- accept socket
let loop = do b <- getBuffer sh 16
case b of
Full msg ->
do logMessage ofh (hexedMessage msg)
loop
Partial msg ->
do logMessage ofh (hexedMessage msg)
hPutStrLn sh "Finishing Logging"
hFlush sh
logMessage ofh "Finishing logging"
hClose ofh
in loop
Dominic.
Here's the full code:
module Main (main) where
import System
import IO
import Time
import Socket
import Char
main :: IO ()
main = do prog <- getProgName
args <- getArgs
if (length args /= 1)
then do putStrLn ("Use: " ++ prog ++ " ")
exitWith (ExitFailure (-1))
else return ()
let port = read (args !! 0) :: Int in
server (PortNumber (mkPortNumber port))
-- The server function creates a socket to listen on the port and
-- loops to log messages.
server :: PortID -> IO ()
server port =
do ofh <- openFile "log.txt" WriteMode
logMessage ofh "Starting logging"
socket <- listenOn port
(sh,host,portid) <- accept socket
let loop = do b <- getBuffer sh 16
case b of
Full msg ->
do logMessage ofh (hexedMessage msg)
loop
Partial msg ->
do logMessage ofh (hexedMessage msg)
hPutStrLn sh "Finishing Logging"
hFlush sh
logMessage ofh "Finishing logging"
hClose ofh
in loop
data Buffer = Full String | Partial String
getBuffer :: Handle -> Int -> IO Buffer
getBuffer h n =
if (n <= 0)
then return (Full "")
else do x <- try (hGetChar h)
case x of
Right c ->
do xs <- getBuffer h (n-1)
case xs of
Full cs -> return (Full (c:cs))
Partial cs -> return (Partial (c:cs))
Left e -> if isEOFError e
then return (Partial "")
else ioError e
logMessage :: Handle -> String -> IO ()
logMessage hd msg =
do clock <- getClockTime
calendar <- toCalendarTime clock
hPutStrLn hd ((calendarTimeToString calendar) ++ "\n" ++ msg)
hFlush hd
showHex :: Char -> String
showHex x =
let y = ord x in
hexDigit (y `div` 16):hexDigit (y `mod` 16):[]
hexDigit :: Int -> Char
hexDigit x
| (0 <= x) && (x <= 9) = chr(ord '0' + x)
| (10 <= x) && (x <=16) = chr(ord 'a' + (x-10))
| otherwise = error "Outside hexadecimal range"
hexedMessage :: String -> String
hexedMessage msg =
(map toPrint msg) ++ " " ++ unwords (map showHex msg)
toPrint :: Char -> Char
toPrint x =
if ((isAscii x) && (not (isControl x)))
then x
else '.'
module Main(main) where
import System
import IO
import Socket
main :: IO ()
main = do prog <- getProgName
args <- getArgs
if (length args /= 2)
then do putStrLn ("Use: " ++ prog ++ " ")
exitWith (ExitFailure (-1))
else return ()
let host = args !! 0
port = read (args !! 1) :: Int in
client host (PortNumber (mkPortNumber port))
client :: Hostname -> PortID -> IO ()
client host port =
do sh <- connectTo host port
hPutStr sh "Hello world"
hFlush sh
x <- hGetLine sh
putStrLn x
-------------------------------------------------------------------------------------------------
21st century air travel http://www.britishairways.com