date:20020408

PThe first release, 0.1, of Object I/O is now
available.
PThe Object I/O for Haskell library is a port of
standard Clean Object I/O library. The general
structure of the Haskell version is inherited from the
original library but there are also few differences
provoked from the languages differences.

PObject I/O allows Haskell programmers to build rich
graphical user interface. This release support only
Windows platform. Features include:

P* Modal and nonmodal dialogs

P* Nonmodal resizeable windows

P* Toolbars and menus

P* Various kind of controls and possibility to build
custom controls

P* Layout manager for controls

P* Timers. The timer simplifies building of little
games. See examples.

P* Support for file opening with drag drop

PQuick reference is available from:
A
href=http://free.top.bg/ka2_mail/objectio-ref.zip;
http://free.top.bg/ka2_mail/objectio-ref.zip/A

PBinary package compiled with GHC-5.02.1
A href=http://free.top.bg/ka2_mail/objectio.zip;
http://free.top.bg/ka2_mail/objectio.zip/A

PExamples
A
href=http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hslibs/object-io/Examples;http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hslibs/object-io/Examples/A

PSource package
A
href=http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hslibs/object-io;http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hslibs/object-io/A

__
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Fundep/Existential Types in 5.03


Ashley

Just leave out the existential in your defn of D!
The (C a b) in the defn of f will do the job.

But your example nevertheless does expose a delicate interaction in the
type checker.  5.02.2 happened not to expose the functional
dependency, so it simply use the (C a b) that f provided.
5.03 does expose the dependency, and so makes the two
b's the same, which is what gives the error message.

It's a problem that some subtlety in the inference algorithm
(I don't even know what it is) changes the behaviour.  I don't
know how to fix this, but perhaps someone else does.

GHC makes all type abstractions and applications explicit,
so the two b's really can't be the same: they don't have the
same scope.

Simon

| -Original Message-
| From: Ashley Yakeley [mailto:[EMAIL PROTECTED]] 
| Sent: 06 April 2002 02:00
| To: GHC List
| Subject: Fundep/Existential Types in 5.03
| 
| 
| Consider this:
| 
|   module Test3 where
| 
|   class C a b | a - b where
|   m :: a - b
| 
|   data D a = forall b. (C a b) = MkD a
| 
|   f :: (C a b) = D a - b
|   f (MkD a) = m a
| 
| This compiles fine under GHC 5.02.2. But under 5.03, it gives 
| an error:
| 
| Model/Test3.hs:9:
| Inferred type is less polymorphic than expected
| Quantified type variable `b' escapes
| When checking an existential match that binds
| and whose type is D a - b1
| In the definition of `f': f (MkD a) = m a
| 
| I consider that the 5.02.2 behaviour is preferable, and that 
| this is a 
| perfectly good program. 'b' does not escape because it is 
| fundep on 'a', 
| which is specified in the type-signature. There can be only one.
| 
| What was changed in 5.03 and why?
| 
| -- 
| Ashley Yakeley, Seattle WA
| 
| ___
| Glasgow-haskell-users mailing list 
| [EMAIL PROTECTED] 
| http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users
| 
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: ANNOUNCE: Object I/O released



--- Simon Peyton-Jones [EMAIL PROTECTED] wrote:
 Well done!
 
 You never responded to my question about MVars...
 
 Simon

   The version that I release is based entirely on LS
version. I think that it is more elegant and more
useful for customer. 

   1) In the MVAR version each event handler must like
this:

eventHandler state = do
   st - takeMVar state
   ...
   ...
   putMVAR state st'

In LS version there isn't need of takeMVar/putMVAR and
the handler is more easy. 

   2) In MVAR version the event handlers in the device
definitions must be defined as curry functions

Example MVAR:
   state - newMVAR (0::Int)
   openWindow (Window NilLS [WindowClose (closeWin
state)])

Example LS:
   openWindow (0::Int) (Window NilLS [WindowClose
closeWin])

   3) Modification of local state doesn't mean
modification of device behaviour. The behaviour of the
device is described with both local state and internal
device data. This means that direct access to the
state isn't a good idea. In the LS version the local
state is encapsulated in the device and I think that
this is more OOP style. Communication between devices
is posible only with message dispatching, that is
better object oriented tehnology.

__
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: ghc 5.02.2 FFI question


Hi Bernie,

 I've been playing with the FFI in GHC 5.02.2
 
 I'm not sure if I'm using it correctly because I get a space leak
 in my program.

I just tried your example and it seems to run in constant space here
with 5.02.2.  The code looks fine - this isn't something we really
envisaged people doing with the RTS API, but there's no real problem
with it except that of course you don't get the benefits of type
checking.  I'm sure you have very good reasons for building Haskell
expressions in C :-)

Can you give us any more clues?  What were the symptoms when you ran it?

Cheers,
Simon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: An answer and a question to GHC implementors [was Re: How to make Claessen's Refs Ord-able?]



 A while back I asked how to make the Ref's from Koen Clasessen's PhD
 thesis Ord-able for the purpose of making them keys for efficient
 finite maps.
 
 Koen quickly responded with a clever implementation which attaches the
 values to the keys.  While I don't rule out eventually making use of
 it, this solution has the drawback of requiring lookups in the finite
 map to be inside the ST or IO monad.
 
 Josef Svenningsson asked if I had tried adding 
   {-# NOINLINE refWInt #-}
 I had (quite hopefully.)  It doesn't work.  After fiddling a bit to
 get a sense of what works and what doesn't, I tried:
   {-# INLINE refWInt #-}
 .  This does the trick!  I've included the working code (which differs
 from that of my original message only by the addition of the INLINE
 directive) below.

 My question to the GHC implementors is: what's going on here?  Can you
 give us (at least Josef and I are confused) any help in predicting how
 unsafePerformIO will behave?

I'm afraid the answer is just unsafePerformIO is called
*unsafe*PerformIO for a reason!  You're using it in an inherently
unsafe way here - the result of the program depends on whether the
compiler duplicates the expression or not, something which it is
normally free to do without affecting the meaning of the program.

However, it is possible to have global top-level references using
unsafePerformIO if you're very careful about it.  In GHC we do something
like this:

{-# NOINLINE global_var #-}
global_var :: IORef Int
global_var = unsafePerformIO (newIORef 42)

the NOINLINE pragma is used to ensure that there is precisely *one* copy
of the right hand side of global_var in the resulting program (NOTE: you
also need to compile the program with -fno-cse to ensure that the
compiler doesn't also common up the RHS of global_var with other similar
top-level definitions).

Cheers,
Simon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: ANNOUNCE: Object I/O released


Krasimir

|The version that I release is based entirely on LS
| version. I think that it is more elegant and more
| useful for customer. 

I'm delighted and impressed that you have completed the Object I/O
port, but I don't think I agree with you about the MVar/LS issue.

A note to other readers: the issue is whether it is better, from
the programmer's point of view, to use MVars to manipulate
state, or to use the state parameterisation that Clean uses.
This issue is discussed in the paper by Peter Achten and mself
  http://research.microsoft.com/~simonpj/Papers/haskellobjectio.htm


My defence of the MVar approach is not because I simply 
think that MVars are best for everything!
It's because I have really struggled to understand the types in the
Clean I/O system, and they become *so* much simpler when the
state parameterisation is left out.  And if I struggle, then I fear that
novice programmers may be in real difficulty.

I think that even Peter Achten thought this too, having done it both
ways (but I should let him speak for himself).

To respond to your points:

|1) In the MVAR version each event handler must like
| this:
| 
| eventHandler state = do
|st - takeMVar state
|...
|...
|putMVAR state st'
| 
| In LS version there isn't need of takeMVar/putMVAR and
| the handler is more easy. 
| 
|2) In MVAR version the event handlers in the device 
| definitions must be defined as curry functions
| 
| Example MVAR:
|state - newMVAR (0::Int)
|openWindow (Window NilLS [WindowClose (closeWin
| state)])
| 
| Example LS:
|openWindow (0::Int) (Window NilLS [WindowClose
| closeWin])

Both are true, but you can easily wrap up the state passing
if that is what you want:

 state - newMVAR (0::Int)
 openWindow (Window NilLS [WindowClose (handle state closeWin)])

handle :: MVar a - (a - IO a) - IO ()
handle m t = do { s - getMVar m; r - t s'; putMVar m s' }

Now you can write closeWin :: WinState - IO WinState
if you want.  

Of course the reference to the state is still explicit, but I do not
think that is a bad thing.  It tells you where that MVar can be modified
(and where it can't!).  There might be two pieces of state for one
component,
one modified by one set of events and one by another, and it would be
nice
to make that apparent.

|3) Modification of local state doesn't mean
| modification of device behaviour. The behaviour of the
| device is described with both local state and internal
| device data. This means that direct access to the
| state isn't a good idea. In the LS version the local
| state is encapsulated in the device and I think that
| this is more OOP style. 

I don't understand this; you can encapsulate the MVars too, in just
the same way:

windowDevice = do { s - newMVar 0;
openWindow ... }

No caller of WindowDevice can see the encapsulated MVar.

Simon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: Fundep/Existential Types in 5.03


I don't know how to make existentials know about functional
dependencies.  In the type system that GHC implements, your
example fails, and I don't see any meaningful way to make it
succeed.  But maybe someone else does.

Simon

| -Original Message-
| From: Ashley Yakeley [mailto:[EMAIL PROTECTED]] 
| Sent: 08 April 2002 10:30
| To: Simon Peyton-Jones; GHC List
| Cc: Mark Shields
| Subject: RE: Fundep/Existential Types in 5.03
| 
| 
| At 2002-04-08 02:15, Simon Peyton-Jones wrote:
| 
| Just leave out the existential in your defn of D!
| The (C a b) in the defn of f will do the job.
| 
| I have another example, but this fails in 5.02.2:
| 
|   class C a b | a - b
| 
|   data D a = forall b. (C a b) = MkD b
| 
|   f :: (C a b) = D a - b
|   f (MkD b) = b
| 
| Should this compile? It looks meaningful to me.
| 
| 
| -- 
| Ashley Yakeley, Seattle WA
| 
| 
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

ANNOUNCE: GHC 5.02.3 released



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

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

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

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

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

http://www.haskell.org/

GHC's Web page lives at

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



 What's new in 5.02.3
==

Some important bugfixes:

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

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

   - fix for excessive recompilation when using --make

   - tryTakeMVar now works

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

and various other minor fixes.

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


 How to get it
===

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

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

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

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



 On-line GHC-related resources
===

Relevant URLs on the World-Wide Web:

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



 System requirements
=

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

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

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

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

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

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



 Mailing lists
===

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

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

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

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

Please report bugs using our SourceForge page at

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

or send them to [EMAIL PROTECTED]

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

RE: ANNOUNCE: Object I/O released


--- Peter Achten [EMAIL PROTECTED] wrote:

 Perhaps there is an interesting alternative that 
 covers all GOOD points and has fewer BAD points.

Some pieces of library can be simplified if redefine:

data WindowLSHandle ls ps
   = WindowLSHandle
{ wlsState:: ls
, wlsHandle   :: WindowHandle ls ps
}

as

data WindowLSHandle ls ps
   = WindowLSHandle
{ wlsState:: MVar ls-- or IORef ls
, wlsHandle   :: WindowHandle ls ps
}

That let Object I/O to manage local state but
simplifies implementation of WindowDevice (see
WindowDevice.hs). There isn't need of fixIO and not
need to use of build function. This also simplifies
creation of modal dialogs and synchronous message
passing. The current implementation uses
unsafeTypeCast function which is not a good idea. 
In this implementation the type system is still
complicated but my decision is just to skip type
declarations and let compiler to resolve function
types for me. In my experience with Object I/O I
notice that type error is usually logical error. So
types for me isn't a trouble.

__
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: ghc-5.02.2-i386-unknown-linux.tar.bz2

2002-04-08 Thread Byron Hale


At 11:40 AM 4/8/2002 +0100, you wrote:

  I downloaded and installed ghc-5.02.2-i386-unknown-linux.tar.bz2 on my
  RedHat Linux 6.2 box (because RPM won't install the relevant RPMs).
  However, when I run ghci, I get  the message ... GHC ...
  5.02.1 ...
 
  What do you think is happening here?

What do you get from 'ghc --version'?

It came from the haskell.org download page.  Version 5.02.1 was previously 
installed, as Serge Mechveliani inquired. I installed it as
the super-user at the root of the file system.

Perhaps I should now consider Version 5.02.3, but the problem may
recur. I got this version of RHL from RH over the Web and finally
realize that I need to register with RH for support. That is the ultimate 
solution, but there may be a delay in executing it. It is at least worth
understanding.

Thanks,

Byron Hale
[EMAIL PROTECTED]


Simon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

GHCi and -O [was: Re: ANNOUNCE: GHC 5.02.3 released]

2002-04-08 Thread Till Doerges


On Mon, Apr 08, 2002 at 01:13:13PM +0100, Simon Marlow wrote:

The (Interactive) Glasgow Haskell Compiler -- version 5.02.3

Nice. :-)

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

This made me think about using *.o-files in GHCi generated w/ 'ghc
-O2'. My GHCi (currently 5.00.2) states:

--- snip ---
warning: -O conflicts with --interactive; -O turned off.
--- snap ---

if I pass -O2 to ghci.

Additionally, I recall some core-dumps or having ghci sometimes report
missing symbols if using some modules compiled w/ optimization.

So, is GHCi supposed to work w/ optimized modules after all? The
documentation merely suggests, this might be possible:

--- snip --- 
Why should we want to run compiled code? Well, compiled code is
roughly 10x faster than interpreted code, but takes about 2x longer to
produce (perhaps longer if optimisation is on). So it pays to compile
the parts of a program that aren't changing very often, and use the
interpreter for the code being actively developed.
--- snap ---

Thanks -- Till
-- 
 e-mail: reverse(net dot doerges at till)   | ENCRYPTED |
pgp/gpg: keys via keyserver or my homepage  |  MAIL IS  |
www: http://www.doerges.net |  WELCOME! |
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

ANNOUNCE: Object I/O released

PObject I/O allows Haskell programmers to build rich
graphical user interface. This release support only
Windows platform. Features include:

P* Modal and nonmodal dialogs

P* Nonmodal resizeable windows

P* Toolbars and menus

P* Various kind of controls and possibility to build
custom controls

P* Layout manager for controls

P* Timers. The timer simplifies building of little
games. See examples.

P* Support for file opening with drag drop

PQuick reference is available from:
A
href=http://free.top.bg/ka2_mail/objectio-ref.zip;
http://free.top.bg/ka2_mail/objectio-ref.zip/A

PBinary package compiled with GHC-5.02.1
A href=http://free.top.bg/ka2_mail/objectio.zip;
http://free.top.bg/ka2_mail/objectio.zip/A

PExamples
A
href=http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hslibs/object-io/Examples;http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hslibs/object-io/Examples/A

PSource package
A
href=http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hslibs/object-io;http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/hslibs/object-io/A

__
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Re: String type in Socket I/O

2002-04-08 Thread dominic . j . steinitz



Having written a Haskell LDAP interface, this is something that worried me
but I never got to the bottom of. I've cross-posted this to haskell
(hopefully the right place). There was some discussion of replacing Char by
a type for raw bytes / octets but I'm not sure what happened to it.

Dominic.




Warrick Gray [EMAIL PROTECTED]@haskell.org on 07/04/2002 13:31:41

Sent by:  [EMAIL PROTECTED]


To:   libraries
cc:
bcc:
Subject:  String type in Socket I/O


Hi all,

I am writing an HTTP client-side library, using the SocketPrim library.
During the implementation of Base64 encode/decode I began to have some
doubts over the use of the Char type for socket I/O.

As far as I can tell, sendTo and recvFrom are simply handles on the
underlying OS calls.  My winsock2.h file tells me the data passed into and
received from these functions are C style chars, 8 bits each.  In unix
these
functions (sys/sockets.h) appear to use a C void pointer.  Finally I notice
that the Haskell98 report defines Haskell Char as a Unicode char (which I
figure isn't guaranteed 8 bits).

So I am curious, what happens when I send these unicode Haskell chars to
the
SocketPrim.sendTo function?  My current guess is that the low 8 bits of
each
Char become a C style char.  My base64 encoding and decoding functions sort
of make this assumption, by ripping out the low 8 bits of chars before
encoding this binary representation (3x8bit chars become 4x6bit base64
chars).

So far everything works fine, but is this approach going to break in the
near future?  What I would like to see are socket functions that do not
introduce this extra level of binary indirection, perhaps using a
ByteArray,
or Word8 (as I see has previously been discussed -
http://www.haskell.org/pipermail/libraries/2001-August/000482.html).  How
realistic is this?

Warrick.



_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

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







  
-

  Save time by using an eTicket and our Self-Service Check-in Kiosks.
  For more information go to http://www.britishairways.com/eservice1


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

do notation and


Folks

Following a good deal of email I now propose to

DO NOTHING

to the rules defining do-notation in the Haskell 98 Report.  
That means that GHC and Hugs, and nhc perhaps, should 
change so that they actually implement the do-notation 
translation rule

  do {e ; stmts}   =   e  do {stmts}

using () and not (=).

From my reading of the email, some people will agree strongly,
and no one will disagree strongly.  I suppose I could be wrong about
this, though.

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

Re: Parsec: No newline after last line and 'many'

2002-04-08 Thread Daan Leijen


Hi Till,

My guess is that you want to break up a text file into
a list of lines with Parsec. (ie. lines functionality).
A text file consists of non-newline characters seperated by
newline characters:

 import Parsec

 plines :: Parser [String]
 plines  = (many (noneOf \n)) `sepBy` newline

You don't need any try or manyTill here. It seems to 
work on my system but I haven't tested it exhaustively.

 TestLine parseTest linep (hi\nTill)
 [hi,Till]
 
 TestLine parseTest linep (hi\nTill\n)
 [hi,Till,]
 
 TestLine parseTest linep (hi\n\nTill\n)
 [hi,,Till,]

I hope this helps, 
All the best,
Daan.


- Original Message - 
From: Till Doerges [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, April 07, 2002 11:04 PM
Subject: Re: Parsec: No newline after last line and 'many'


 On Sun, Apr 07, 2002 at 07:44:42PM +0200, Till Doerges wrote:
 
  Eventually I want to be able to use my parser 'linep' with 'many' on
  no matter which text-files.
 
 'manyTill linep eof' and is what I wanted (looking at my first name, I
 should have gotten that one earlier... ;-)
 
 Bye -- Till
 ___
 Haskell mailing list
 [EMAIL PROTECTED]
 http://www.haskell.org/mailman/listinfo/haskell
 
 


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

ANNOUNCE: GHC 5.02.3 released



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

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

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

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

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

http://www.haskell.org/

GHC's Web page lives at

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



 What's new in 5.02.3
==

Some important bugfixes:

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

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

   - fix for excessive recompilation when using --make

   - tryTakeMVar now works

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

and various other minor fixes.

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


 How to get it
===

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

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

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

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



 On-line GHC-related resources
===

Relevant URLs on the World-Wide Web:

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



 System requirements
=

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

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

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

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

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

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



 Mailing lists
===

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

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

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

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

Please report bugs using our SourceForge page at

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

or send them to [EMAIL PROTECTED]

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

RE: ANNOUNCE: Object I/O released

2002-04-08 Thread Peter Achten


Hello Krasimir,

I am very curious about your implementation of the Object I/O system, but 
unfortunately could not open the .zip files either (same symptoms as Arjan 
van IJzendoorn wrote). Could you check the formats of these files? Thanks 
in advance.

Simon Peyton-Jones wrote:
Krasimir

|The version that I release is based entirely on LS
| version. I think that it is more elegant and more
| useful for customer.

I'm delighted and impressed that you have completed the Object I/O
port, but I don't think I agree with you about the MVar/LS issue.

 A note to other readers: the issue is whether it is better, from
 the programmer's point of view, to use MVars to manipulate
 state, or to use the state parameterisation that Clean uses.
 This issue is discussed in the paper by Peter Achten and mself
   http://research.microsoft.com/~simonpj/Papers/haskellobjectio.htm

My defence of the MVar approach is not because I simply
think that MVars are best for everything!
It's because I have really struggled to understand the types in the
Clean I/O system, and they become *so* much simpler when the
state parameterisation is left out.  And if I struggle, then I fear that
novice programmers may be in real difficulty.

I think that even Peter Achten thought this too, having done it both
ways (but I should let him speak for himself).

This issue was one of the key design issues Simon and I had to resolve when 
porting the Clean Object I/O system to Haskell. The arguments in the above 
mentioned paper are still valid. Briefly, one can summarise them as: MVar-s 
offer many significant advantages (simpler types, simpler implementation, 
more expressive power, programming style similar to handling of identifier 
values) but have one disadvantage (state management is done by the 
programmer).

As it happens, I am about to spend a couple of weeks 
(re)designing/implementing/bug-fixing the Object I/O library, and this 
issue is high on my priority list. I think this is a delicate design 
decision that should be taken with care, as it has impact on all existing 
programs  and all implementations :-).

Regards,
Peter

Additional remarks to those of Simon:
To respond to your points:

|1) In the MVAR version each event handler must like
| this:
|
| eventHandler state = do
|st - takeMVar state
|...
|...
|putMVAR state st'
|
| In LS version there isn't need of takeMVar/putMVAR and
| the handler is more easy.

But the reverse case is also true: in the LS version, an event handler must 
modify local state. So a function that is really not interested in the 
local state is either polymorphic in the local state or uses the local 
state lifting function (noLS and noLS1). In the MVAR version one wouldn't 
be bothered with this.

|
|2) In MVAR version the event handlers in the device
| definitions must be defined as curry functions
|
| Example MVAR:
|state - newMVAR (0::Int)
|openWindow (Window NilLS [WindowClose (closeWin
| state)])
|
| Example LS:
|openWindow (0::Int) (Window NilLS [WindowClose
| closeWin])

Both are true, but you can easily wrap up the state passing
if that is what you want:

  state - newMVAR (0::Int)
  openWindow (Window NilLS [WindowClose (handle state closeWin)])

 handle :: MVar a - (a - IO a) - IO ()
 handle m t = do { s - getMVar m; r - t s'; putMVar m s' }

Now you can write closeWin :: WinState - IO WinState
if you want.

Of course the reference to the state is still explicit, but I do not
think that is a bad thing.  It tells you where that MVar can be modified
(and where it can't!).  There might be two pieces of state for one
component,
one modified by one set of events and one by another, and it would be
nice
to make that apparent.


|   3) Modification of local state doesn't mean
| modification of device behaviour. The behaviour of the
| device is described with both local state and internal
| device data. This means that direct access to the
| state isn't a good idea. In the LS version the local
| state is encapsulated in the device and I think that
| this is more OOP style.

I don't understand this; you can encapsulate the MVars too, in just
the same way:

windowDevice = do { s - newMVar 0;
 openWindow ... }

No caller of WindowDevice can see the encapsulated MVar.

The main point of 'LS advocates' is that encapsulation is guaranteed by 
construction, while it is a program property in the MVAR system. This is of 
course a GOOD thing. However, this characteristic of LS is also its 
weakness: one simply can't (partially) share local state between GUI 
components of different top-level parents (except of course on the highest 
level within the interactive process) even though in practice this would 
make a lot of sense. One also can't easily modify event handlers once a GUI 
structure has been created, even if one would `know' the proper local state 
type because of the strong encapsulation (you can

RE: ANNOUNCE: Object I/O released