ghc-6.0.1 --make -O (linking errors)

2003-07-31 Thread Jan Scheffczyk
Hi all,

I recently switched to ghc 6.0.1 running on a debian linux box.

When compiling a program using
  ghc --make -O
or
  ghc --make -O2
I get lots of errors while linking.
The linker concerns about undefined references to Data.FiniteMap, which I 
frequently use.
For example, the linker says:

../Options.o(.text+0xc0d): In function `s4m5T_ret':
: undefined reference to `DataziFiniteMap_lvl4_closure'

Without optimizing my code, doing a plain
  ghc --make
everything goes fine.
Similarly, compiling the same program with the older ghc 6.0 I do not get any 
linking errors, whether I optimize or not.

Any ideas, how I can get rid of the linking errors, except for switching back 
to ghc 6.0?

Best Regards,
Jan

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


RE: ghc-6.0.1 --make -O (linking errors)

2003-07-31 Thread Simon Marlow
 
 I recently switched to ghc 6.0.1 running on a debian linux box.
 
 When compiling a program using
   ghc --make -O
 or
   ghc --make -O2
 I get lots of errors while linking.
 The linker concerns about undefined references to 
 Data.FiniteMap, which I 
 frequently use.
 For example, the linker says:
 
 ../Options.o(.text+0xc0d): In function `s4m5T_ret':
 : undefined reference to `DataziFiniteMap_lvl4_closure'
 
 Without optimizing my code, doing a plain
   ghc --make
 everything goes fine.
 Similarly, compiling the same program with the older ghc 6.0 
 I do not get any 
 linking errors, whether I optimize or not.
 
 Any ideas, how I can get rid of the linking errors, except 
 for switching back to ghc 6.0?

It could be a problem with your build of ghc-6.0.1.  Where did it come
from?

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


RE: Lost output in multithreaded program

2003-07-31 Thread Simon Marlow
I haven't investigated in detail, but I believe your problem might be
caused by a known bug in the implementation of forkProcess, namely that
when forking from a child thread it doesn't kill the main thread.  The
workaround is to fork (in your case call popen) from the main thread,
not a child thread.

Cheers,
Simon

 I am puzzled by the behaviour of this (stripped-down, 
 uglified) program. 
   It is supposed to run a bunch of shell commands simultaneously, 
 collate their standard output and error, and print their output as 
 though they had run sequentially.
 
  module Main where
 
  import Control.Concurrent
  import Data.Maybe
  import GHC.Handle
  import GHC.IO
  import Posix (popen)
 
  main = do
  cmds- getContents = return.lines
  outCh   - newChan
  mainThr - myThreadId
  forkIO $ do
  mapM_ (startCommand outCh) cmds
  writeChan outCh $ killThread mainThr
  getChanContents outCh = sequence_
 
  startCommand :: Chan (IO ()) - String - IO ()
  startCommand ch cmd = do
  -- Prevent lazy reads after forking
  length cmd `seq` return ()
  (out,err,pid) - popen /bin/sh [-c,cmd] Nothing
  -- Prevent deadlock (waiting to read stdout
  -- while the child waits to write stderr).
  forkIO $ length err `seq` return ()  -- culprit line?
  writeChan ch $ hPutStr stdout out
  writeChan ch $ hFlush stdout
  writeChan ch $ hPutStr stderr err
  writeChan ch $ hFlush stderr
 
 Most of the time it works but every so often a chunk of child output 
 gets lost.  (I'm sure I've seen it duplicating chunks of 
 output too, but 
 I haven't been able to isolate a test case.)  Corruption of 
 stderr seems 
 more common than corruption of stdout.  The corruption 
 doesn't get more 
 predictable if I generate a list of commands with fixed 
 'random' sleeps 
 and use that (so I don't think it's a gross timing issue).  The lost 
 data is not necessarily a prefix of the output string, nor a suffix. 
 The lost data does not reappear later in the program's 
 output.  The lost 
 data *does* appear to correspond to byte sequences that are 
 written in a 
 single write() by the child process.
 
 Example:
 
  $ cat test.sh
  #!/bin/sh
  echo -n std; sleep 1
  echo -n STD2 ; sleep 1
  echo   out ; sleep 1
  echo   ERR 2 ; sleep 1
  $ for i in `seq 100`; do echo sleep $((RANDOM % 10)); 
 ./test.sh; 
 done | ./a.out
snip
  stdout
  STDERR
  stdout
  ERR
  stdout
  STDERR
snip
  stdout
  STDERR
  stdout
  STDstdout
  STDERR
  stdout
  STDERR
snip
 
 If I comment the 'culprit line' above then the program runs without 
 error.  This confounds me: I believe that that line should have no 
 effect except to suck the child's stderr into the program as soon as 
 possible.  (Am I wrong?  And is there a better way of doing this?)
 
 Platform: ghc-6.0-7 / RedHat 8.0 / x86.
 Compilation: ghc -package posix test.hs
 
 Where did my output go?  Have I run into some gotcha like the 'lazy 
 reads after forking' thing?  Can someone tell me what I'm doing wrong?
 
 Hopeful thanks,
 // David
 -- 
 David Hughes
 UNIX sysadmin, Serco SA -+- Tel.: +41 22 767 8997
 Computing Centre, CERN  -+-[EMAIL PROTECTED]
 
 This message expresses my own opinions and should not be construed
 as the opinions of Serco (who employ me) or of CERN (where I work).
 
 ___
 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: Strange Building problem...

2003-07-31 Thread Mark Green
On Wed, 30 Jul 2003 18:01:22 +0100, you wrote:

GHCziBase_True_closure is a symbol that should be coming from the base
package, the GHC.Base module in particular.  You could check that
libraries/base/libHSbase.a looks reasonable: it should be on the order
of 17Mb.  Try 'nm' on it, look for some of the missing symbols.

Hi,

Thanks very much for your reply.

I looked and the libraries/base/libHSbase.a file is there, is the
correct size, and does contain the missing references.  The only
problem is that the compiler doesn't seem to be seeing it.  

I tried looking in the makefile to see if I could insert a path
directive somewhere, but I'm not very experienced with UNIX makefiles
so I couldn't find where I ought to put such a thing.

What is odd is that ghc-inplace is invoked by the make process several
times before this big one (which appears to be the start of stage 2?)
and works fine...

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


RE: Strange Building problem...

2003-07-31 Thread Simon Marlow
 
 On Wed, 30 Jul 2003 18:01:22 +0100, you wrote:
 
 GHCziBase_True_closure is a symbol that should be coming 
 from the base
 package, the GHC.Base module in particular.  You could check that
 libraries/base/libHSbase.a looks reasonable: it should be on 
 the order
 of 17Mb.  Try 'nm' on it, look for some of the missing symbols.
 
 Hi,
 
 Thanks very much for your reply.
 
 I looked and the libraries/base/libHSbase.a file is there, is the
 correct size, and does contain the missing references.  The only
 problem is that the compiler doesn't seem to be seeing it.  
 
 I tried looking in the makefile to see if I could insert a path
 directive somewhere, but I'm not very experienced with UNIX makefiles
 so I couldn't find where I ought to put such a thing.
 
 What is odd is that ghc-inplace is invoked by the make process several
 times before this big one (which appears to be the start of stage 2?)
 and works fine...

Do the errors really refer to GHCziBase_True_Closure, or is it
GHCziBase_True_closure? (with lower-case 'c')?

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


Re: ghc-6.0.1 --make -O (linking errors)

2003-07-31 Thread Ian Lynagh
On Thu, Jul 31, 2003 at 08:55:01AM +0200, Jan Scheffczyk wrote:
 Hi all,
 
 I recently switched to ghc 6.0.1 running on a debian linux box.
 
 When compiling a program using
   ghc --make -O
 or
   ghc --make -O2
 I get lots of errors while linking.
 The linker concerns about undefined references to Data.FiniteMap, which I 
 frequently use.

If you are not already using them then you could try the debs from the
Haskell Experimental repository. Both stable and unstable debs are
available (unfortunately they are awaiting manual intervention before
going into the Debian archive as there are a couple of new package
names):

deb http://www.syntaxpolice.org/haskell-experimental/ stable/
deb http://www.syntaxpolice.org/haskell-experimental/ unstable/

If these suffer from the same problem then please let me know, and if
possible give me some sources that show it.


Thanks
Ian

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


Re: Strange Building problem...

2003-07-31 Thread Mark Green
On Thu, 31 Jul 2003 13:57:02 +0100, you wrote:
 What is odd is that ghc-inplace is invoked by the make process several
 times before this big one (which appears to be the start of stage 2?)
 and works fine...
Do the errors really refer to GHCziBase_True_Closure, or is it
GHCziBase_True_closure? (with lower-case 'c')?

It's a lower-case 'c'.  Sorry - I typed it out by hand as the build is
on a different machine.

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


Re: ghc-6.0.1 --make -O (linking errors)

2003-07-31 Thread Jan Scheffczyk
Hi Ian,

 If you are not already using them then you could try the debs from the
 Haskell Experimental repository. Both stable and unstable debs are
 available (unfortunately they are awaiting manual intervention before
 going into the Debian archive as there are a couple of new package
 names):

Thanks.
We have found the error.
In my Makefile I had added an explicit library search path (via -L) where ghc 
6.0 libs are installed.
Changing the path to the ghc 6.0.1 libs directory made ghc compile my program, 
as expected :-)).

So it was absolutely MY mistake and not ghc's.

Best regards,
Jan

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


Re: ANNOUNCE: GHC version 6.0.1

2003-07-31 Thread Wolfgang Thaller

   =
The (Interactive) Glasgow Haskell Compiler -- version 6.0.1
   =
A Mac OS X package id now available at:

http://www.uni-graz.at/imawww/haskell/GHC.6.0.1.dmg

Cheers,

Wolfgang

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


RE: Ann: HAllInOne bug fix release

2003-07-31 Thread Simon Peyton-Jones
Something very odd is going on.  GHC does not generate programs than run
3x faster between GHC versions.  

If, perhaps, you compiled both without -O, no cross-module inlining
takes place.  That would account for a big slow down when using separate
compilation.  I see you use -O2 this time.

I don't know why the all in one version might go slower though

S

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Hal Daume
| Sent: 31 July 2003 00:23
| To: Wolfgang Jeltsch; The Haskell Mailing List
| Subject: RE: Ann: HAllInOne bug fix release
| 
| Ah, apparently it is not (at least not the Cygwin version).
| 
| I recompiled NHC with GHC -O2, both the separate compilation version
and
| the all-in-over version.  Averaged over five runs, we see that the
| separate compilation version is actually *faster* than the ai1
version:
| 
| standard nhc compiled with ghc:
| 
| real0m27.167s
| user0m9.991s
| sys 0m1.304s
| 
| nhc all-in-one:
| 
| real0m31.411s
| user0m10.007s
| sys 0m1.299s
| 
| 
| 
| i am completely unable to explain this.  someone want to hazard a
guess?
| 
|  - hal, who is a bit disappointed now :(
| 
|  --
|  Hal Daume III   | [EMAIL PROTECTED]
|  Arrest this man, he talks in maths.   | www.isi.edu/~hdaume
| 
| 
|  -Original Message-
|  From: [EMAIL PROTECTED]
|  [mailto:[EMAIL PROTECTED] On Behalf Of Wolfgang Jeltsch
|  Sent: Wednesday, July 30, 2003 2:59 PM
|  To: The Haskell Mailing List
|  Subject: Re: Ann: HAllInOne bug fix release
| 
| 
|  On Wednesday, 2003-07-30, 23:36, CEST, Hal Daume III wrote:
|   [...]
| 
|   A few people have asked me for speed-up results from
|  All-In-One-ifying code,
|   so here's a good one.  We take two versions of NHC.  One is
|  the original
|   binary distribution and the other is the All-In-One-ified
|  version, compiled
|   by GHC.
| 
|  Hi,
| 
|  is the original binary distribution compiled with GHC? If
|  not, the speed-up
|  may also be the result of using a different compiler (i.e., GHC).
| 
|   [...]
| 
|  Wolfgang
| 
|  ___
|  Haskell mailing list
|  [EMAIL PROTECTED]
|  http://www.haskell.org/mailman/listinfo/haskell
| 
| ___
| Haskell mailing list
| [EMAIL PROTECTED]
| http://www.haskell.org/mailman/listinfo/haskell


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


RE: Ann: HAllInOne bug fix release

2003-07-31 Thread Graham Klyne
At 08:44 31/07/03 +0100, Simon Peyton-Jones wrote:
I don't know why the all in one version might go slower though
Virtual memory thrashing?  (Hal did say something about needing lots of RAM.)

#g

---
Graham Klyne
[EMAIL PROTECTED]
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell


RE: Ann: HAllInOne bug fix release

2003-07-31 Thread Koen Claessen
Simon Peyton-Jones wrote:

 | I don't know why the all in one version might go
 | slower though.

How about some (artificial) cut-offs during optimization
phases? Optimizing a hugs module could lead to some kind of
combinatorial explosion (which gets cut off by the
optimizer) which does not happen when you have separate
modules?

Just my 2 öre!

/Koen

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


New Haskell and FP merchandise logos for review

2003-07-31 Thread Fritz K Ruehr
John Peterson recently handed over control of the Haskell Merchandise
area of haskell.org to me and, in celebration, I've created a bunch of
provisional designs for new Haskell, FP and types-related swag.

The logos include the original and new haskell.org logos and about 
15 others, designed around traditional T-shirt logo aesthetics (puns, 
strident dogmatic posturings and mild sexual suggestion). I've tried to 
represent a range of Haskell community viewpoints, from pure/theory to 
systems/hacker. (A couple of the designs will likely appeal to a very
limited audience, for example the catamorphism evaluation law expressed 
with *real* banana brackets ... ).

For now the logos are just graphic files in PNG format, available from
this URL, linked from thumbnails and accompanied by a few comments: 

http://www.willamette.edu/~fruehr/logos/intro.html

My intent is to convert them, as called for, into products on the 
CafePress site and link them in via the Haskell Merchandise page
(see the docs at the URL for more details).

I'm not sure exactly what the protocol for selecting logo/product 
combinations should be, but for now I will just take e-mails from 
people (if this becomes laborious maybe a Wiki page would be better). 
I am open to suggestions for changes or additions, or to other peoples' 
designs. Note that neither I nor haskell.org will make any profit, 
but there is some possibility of using a modest charge to off-set a 
more convenient CafePress set-up (again, go to the URL for details).

  --  Fritz Ruehr
  
PS: replies to haskell-cafe please!

PPS to whomever requested the new haskell.org logo: sorry for the delay, 
I will consider your request as first in the queue and open a new store 
presently. But write me with your specific interest for a product 
(i.e., white t-shirt, grey t-shirt, tank-top, etc.).

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


RE: New Haskell and FP merchandise logos for review

2003-07-31 Thread David Bergman
I seldom post things here, but Fritz, you are a genius!

/David


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


Re: ANNOUNCE: GHC version 6.0.1

2003-07-31 Thread Wolfgang Thaller

   =
The (Interactive) Glasgow Haskell Compiler -- version 6.0.1
   =
A Mac OS X package id now available at:

http://www.uni-graz.at/imawww/haskell/GHC.6.0.1.dmg

Cheers,

Wolfgang

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


a breaking monad

2003-07-31 Thread Hal Daume
i've noticed in a lot of my imperative-looking monadic code, i have lots
of stuff that looks like:

 ... = do
   q - some test
   if q
 then return some constant
 else do
   major code body here

lots of these things embedded makes the code hard to read and introduces
way too much indentation (i'm one of those who doesn't like curly
braces).

one solution to this is to write it as:

 ... = do
   q - some test
   if q then return some constant else do
   major code body here

but this is ugly, IMO :).

my solution was to fashion a monad transformer that supports a break
statement.  basically, it looks like:

 data Break b m a = Break { runBreak :: m (Maybe b, a) }
 
 instance MonadTrans (Break b) where
   lift x = Break $ do a - x; return (Nothing, a)
 
 instance Monad m = Monad (Break b m) where
   return a = Break $ return (Nothing, a)
   b = k  = Break $ runBreak b = \ (broken, a) -
   case broken of
 Nothing - runBreak (k a)
 Just br - return (Just br, undefined)
 
 breakable :: Monad m = Break a m a - m a
 breakable b = runBreak b = \ (broken, a) -
 case broken of
   Nothing - return a
   Just br - return br
 
 break :: Monad m = b - Break b m a
 break b = Break (return (Just b, undefined))

essentially you introduce code blocks with the breakable function and
then can break with the break function.  a useful combinator i've found
is:

 breaksTo :: Monad m = m Bool - b - Break b m ()
 breaksTo k b = lift k = \x - if x then break b else return ()

using this, you can write stuff which looks like:

 test1 :: IO [String]
 test1 = breakable $ do
   lift $ putStrLn Enter something, or nothing to quit:
   l - lift $ getLine
   when (null l) $ break []
   rest - lift test1
   return (l:rest)
 
 test2 :: IO ()
 test2 = breakable $ repeatM $ do 
   x - lift $ getLine = passThrough putStrLn
   when (null x) $ break ()
 
 test3 :: Handle - IO [String]
 test3 h = breakable $ do
   hIsEOF h `breaksTo` []
   lift $ do 
 l - hGetLine h
 rest - test3 h
 return (l:rest)

where passThrough and repeatM are:

 repeatM :: Monad m = m () - m ()
 repeatM x = x  repeatM x
 
 passThrough :: Monad m = (a - m b) - a - m a
 passThrough f a = f a  return a

so, my questions are: does this exist in some other form I'm not aware
of?  is there something fundamentally broken about this (sorry for the
pun)?  any other comments, suggestions?


--
 Hal Daume III   | [EMAIL PROTECTED]
 Arrest this man, he talks in maths.   | www.isi.edu/~hdaume
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell


Re: a breaking monad

2003-07-31 Thread Derek Elkins
On Thu, 31 Jul 2003 13:18:40 -0700
Hal Daume [EMAIL PROTECTED] wrote:

 so, my questions are: does this exist in some other form I'm not aware
 of?  is there something fundamentally broken about this (sorry for the
 pun)?  any other comments, suggestions?

This looks like a bizarre rendition of the Error/Exception monad.

I believe the function breakable would be fairly accurately
represented with '\b - runErrorT b = either return return' and use
throwError for break.

Also, your motivating example is ambiguous.  I think you mainly care
about the case where the test is testing for some exceptional
condition.  I personally wouldn't want to use this style every place I
would use an if.

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


Raw I/O library proposal, second (more pragmatic) draft

2003-07-31 Thread Ben Rudiak-Gould
[Crossposted to Haskell and Libraries. Replies to Libraries.]


-- More comments, please. Bad names? Important missing functionality?
-- Still unimplementable?


module System.RawIOSecondDraft (...) where

data File   -- now essentially a file handle
data InputChannel   -- renamed for less confusing function prefixes
data OutputChannel

-- | A Moniker is a slight generalization of a pathname. In principle this
-- could be extended to support URIs, host:port SSL connections, memory
-- buffers, and so on, though it might be better to give them their own
-- functions.

-- Compatibility refers to compatibility with existing Haskell
-- implementations, which treat Char values like octets. RawPathname is
-- there to avoid an octet - string - octet translation in cases where
-- that's undesirable. This is slightly problematic on Win32, where
-- pathnames really *are* strings.

type Moniker
  = Pathname String
  | CompatibilityPathname String
  | RawPathname [Octet]

{- if supported, maybe:
  | DirectoryEntry Directory String
  | ResourceFork Moniker
  | NamedFork String Moniker
-}


-- * File and channel creation functions

-- I still use lookup rather than open to emphasize that there's an
-- irreversible and time-dependent translation going on here.

lookupFileRO  :: Moniker - IO File
lookupFileRW  :: Moniker - IO File
lookupInputChannel:: Moniker - IO InputChannel
lookupOutputChannelAppend :: Moniker - IO OutputChannel
createOutputChannel   :: Moniker - IO OutputChannel

-- * File access functions

-- | Indicates that a File value will never be used again. Calling
-- fRelease is not mandatory, but it assists the implementation in
-- closing file handles as early as possible. It is an error to use the
-- argument in any way after making this call.

fRelease :: File - IO ()

-- | Returns a new File value which is identical to the argument except
-- that calling fRelease on one does not affect the other.

fDup :: File - IO File

-- | Returns True if fRelease has not been called on the File value.

fIsValid :: File - IO Bool

-- | Reads from a file to a memory buffer. If the read extends beyond the
-- end of the file, the extra buffer space is filled with zeroes and the
-- return value is the number of octets which actually came from the file.
-- Otherwise the return value is the same as the length argument.

fReadBuf :: File - FilePos - BlockLength - Ptr Word8 - IO BlockLength

-- | Writes to a file from a memory buffer.

fWriteBuf:: File - FilePos - BlockLength - Ptr Word8 - IO ()

-- | Returns the current size of the file.

fGetSize :: File - IO FilePos

-- | If the size argument is less than the current file size, the file size
-- is reduced, destroying any octets beyond the new end of the file. If the
-- size argument is greater than the current file size, the file may or may
-- not be increased in length. If it is increased, the contents of the file
-- beyond the old end of file are undefined.

fSetSize :: File - FilePos - IO ()

fIsReadable  :: File - IO Bool
fIsWritable  :: File - IO Bool

-- * Layering channels on files

-- | Opens an input channel (octet source) which reads from the specified
-- file, starting at the specified offset. Effectively fDups the File
-- argument, so the original File value may be released at any later time
-- without affecting the channel.

fInputChannelFrom :: File - FilePos - IO InputChannel

-- | Opens an output channel (octet source) which writes to the specified
-- file, starting at the specified offset. Because input and output
-- channels may be buffered, the result of an fRead call on a file region

fOutputChannelFrom :: File - FilePos - IO OutputChannel

-- | Like fInputChannelFrom, but stops after reading the octet which
-- immediately precedes the second FilePos argument, or at end of file,
-- whichever comes first.

fInputChannelFromTo :: File - FilePos - FilePos - IO InputChannel

-- * Standard channels

stdin :: InputChannel
stdout, stderr :: OutputChannel

-- * Input channel access functions

-- | Indicates that no more octets will be read from the InputChannel.
-- It is not necessary to call this function if all available octets
-- have already been read.

icRelease :: InputChannel - IO ()

icGet :: InputChannel - IO Octet

icGetBuf  :: InputChannel - Ptr a - BlockLength - IO BlockLength

icAtEnd   :: InputChannel - IO Bool

-- | Returns the File associated with its argument, if any. May fail even
-- on a channel created with fInputChannel, since the channel is permitted
-- to release its internal File value on reaching end-of-input. May succeed
-- on a channel not created with fInputChannel, such as stdin. The caller
-- is responsible for releasing the returned File.

icTellFile :: InputChannel - IO Maybe File

-- | Returns the current read offset in the underlying file, if any. May
-- succeed even if icTellFile fails. Always succeeds if the channel was
-- created on top 

RE: a breaking monad

2003-07-31 Thread Hal Daume
 This looks like a bizarre rendition of the Error/Exception monad.

Yes, of course.  *Hal slaps himself*

Thanks.

 Also, your motivating example is ambiguous.  I think you mainly care
 about the case where the test is testing for some exceptional
 condition.  I personally wouldn't want to use this style every place I
 would use an if.

Definitely not!  :)

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


Text I/O library proposal, first draft

2003-07-31 Thread Ben Rudiak-Gould
[Crossposted to Haskell and Libraries. Replies to Libraries.]

{-
Good things about this text library design:

  * Efficient implementation should be straightforward

  * Character coder interface is public, so users can supply their own
encodings, or write coder transformers (there are some in the
proposal)

Bad things:

  * There's no way to implement fgetpos/fsetpos type functionality,
because coders don't expose their internal state. (In fact, there
would need to be a way to explicitly copy the state, since it may
well include IORefs, Ptrs, etc.) Is this a serious problem?
-}


module System.TextIOFirstDraft (...) where

-- A BlockRecoder takes source and destination buffers and does some sort
-- of translation between them. It returns the number of values (not
-- bytes!) consumed and the number of values produced. It does not have to
-- empty the input buffer or fill the output buffer on each call, but it
-- must do something (i.e. it's not acceptable to return (0,0)). Coders
-- will in general have internal state which is updated on each call.

type BlockRecoder from to =
  Ptr from - BlockLength - Ptr to - BlockLength
   - IO (BlockLength,BlockLength)

type TextEncoder = BlockRecoder Word32 Octet
type TextDecoder = BlockRecoder Octet Word32

-- IO TextEncoder and IO TextDecoder below denote coder factories which
-- produce a new coder in its initial state each time they're called.

compatibilityEncoder :: IO TextEncoder  -- mod 256
currentLocaleEncoder :: IO TextEncoder
iso88591Encoder :: IO TextEncoder
latin1Encoder = iso88591Encoder

utf8Encoder, utf16BEEncoder, utf16LEEncoder,
  utf32BEEncoder, utf32LEEncoder :: IO TextEncoder

compatibilityDecoder :: IO TextDecoder
currentLocaleDecoder :: IO TextDecoder
iso88591Decoder :: IO TextDecoder
latin1Decoder = iso88591Decoder

utf8Decoder, utf16BEDecoder, utf16LEDecoder,
  utf32BEDecoder, utf32LEDecoder :: IO TextDecoder

-- An attempt at supporting setlocale-type locale strings.

lookupEncoder :: String - Maybe (IO TextEncoder)
lookupDecoder :: String - Maybe (IO TextDecoder)

-- prependBOM takes an existing UTF encoder and causes it to prepend
-- a BOM (byte-order mark) to its output. autodetectUTF takes an existing
-- decoder and modifies it to check for a BOM, switching to the
-- appropriate type of UTF decoding if one is found.

prependBOM :: IO TextEncoder - IO TextEncoder
autodetectUTF :: IO TextDecoder - IO TextDecoder

-- Attaches a TextInputChannel to the supplied InputChannel. After
-- this operation the InputChannel should be considered owned by the
-- TextInputChannel; any attempt to use it directly will cause
-- unpredictable results. This takes a decoder factory rather than a
-- decoder to prevent the error of attaching the same decoder to more than
-- one channel.

icAttachTextDecoder :: InputChannel - IO TextDecoder - IO TextInputChannel

ticGetChar :: TextInputChannel - IO Char
ticGetLine :: TextInputChannel - IO String
ticLazyGetContents :: TextInputChannel - IO String

ocAttachTextEncoder :: OutputChannel - IO TextEncoder - IO TextOutputChannel

tocPutChar  :: TextOutputChannel - Char - IO ()
tocPutStr   :: TextOutputChannel - String - IO ()
tocPutStrLn :: TextOutputChannel - String - IO ()

-- ... etc ...


-- Ben

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


RE: Text I/O library proposal, first draft

2003-07-31 Thread Hal Daume
Hi Ben,

 Bad things:
 
   * There's no way to implement fgetpos/fsetpos type functionality,
 because coders don't expose their internal state. (In fact, there
 would need to be a way to explicitly copy the state, since it may
 well include IORefs, Ptrs, etc.) Is this a serious problem?

Yes!  This is an enormously serious problem.  At least for me.

It's not a problem for writing files, but I really really really need
this functionality when reading files.  Reason: I'm often tooling around
in very large (1gb or greater) files which happen to be sorted on some
sort of index and I need to do binary search in them.  To load all the
file into Haskell or to do linear search is impossible.

Other than that, I rather like the design.

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


Re: Text I/O library proposal, first draft

2003-07-31 Thread John Meacham
presumably if you are doing random access on the file, it is in a known
nonarbitrary text encoding (like utf8). in which case you can
read/access the file with the binary routines and just use the
appropriate text conversions to get data out. 
John

On Thu, Jul 31, 2003 at 03:55:44PM -0700, Hal Daume wrote:
 Hi Ben,
 
  Bad things:
  
* There's no way to implement fgetpos/fsetpos type functionality,
  because coders don't expose their internal state. (In fact, there
  would need to be a way to explicitly copy the state, since it may
  well include IORefs, Ptrs, etc.) Is this a serious problem?
 
 Yes!  This is an enormously serious problem.  At least for me.
 
 It's not a problem for writing files, but I really really really need
 this functionality when reading files.  Reason: I'm often tooling around
 in very large (1gb or greater) files which happen to be sorted on some
 sort of index and I need to do binary search in them.  To load all the
 file into Haskell or to do linear search is impossible.
 
 Other than that, I rather like the design.
 
  - Hal
 -- 
 Haskell mailing list
 [EMAIL PROTECTED]
 http://www.haskell.org/mailman/listinfo/haskell
 

-- 
---
John Meacham - California Institute of Technology, Alum. - [EMAIL PROTECTED]
---
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell


*safe* coerce, for regular and existential types

2003-07-31 Thread oleg

This message describes functions safeCast and sAFECoerce implemented
in Haskell98 with common, pure extensions. The functions can be used
to 'escape' from or to existential quantification and to make
existentially-quantified datatypes far easier to deal with. Unlike
Dynamic, the present approach is pure, avoids unsafeCoerce and
unsafePerformIO, and permits arbitrary multiple user-defined typeheaps
(finite maps from types to integers and values).

An earlier message [1] introduced finite type maps for
purely-functional conversion of monomorphic types to unique
integers. The solution specifically did not rely on Dynamic and
therefore is free from unsafePerformIO. This message shows that the
type maps can be used for a safe cast, in particular, for laundering
existential types. The code in this message does NOT use
unsafePerformIO or unsafeCoerce. To implement safe casts, we define a
function sAFECoerce -- which works just like its impure
counterpart. However the former is pure and safe. sAFECoerce is a
library function expressed in Haskell with common extension. The
safety of sAFECoerce is guaranteed by the typechecker itself.

This whole message is self-contained, and can be loaded as it is in
GHCi, given the flags
  -fglasgow-exts -fallow-undecidable-instances -fallow-overlapping-instances

This message was inspired by Amr Sabry's problem on existentials.  In
fact, it answers an unstated question in Amr Sabry's original message.


It has been observed on this list that existentially-quantified
datatypes are not easy to deal with [2]. For example, suppose we have
a value of a type

 data EV = forall a. (TypeRep a TI)= EV a

(please disregard the second argument of TypeRep for a moment).

The constructor EV wraps a value. Suppose we can guess that the
wrapped value is actually a boolean. Even if our guess is correct, we
*cannot* pass that value to any function of booleans:

* *Main case (EV False) of (EV x) - not x
*
* interactive:1:
* Inferred type is less polymorphic than expected
* Quantified type variable `a' is unified with `Bool'
* When checking an existential match that binds
* x :: a
* and whose type is EV - Bool
* In a case alternative: (EV x) - not x

A quantified type variable cannot be unified with any regular type --
or with another quantified type variable. Values of existentially
quantified types cannot be passed to monomorphic functions, or to
constrained polymorphic functions (unless all their constrains have
been mentioned in the declaration of the existential). That limitation
guarantees safety -- on the other hand, it significantly limits the
convenience of existential datatypes [2].

To overcome the limitation, it _seemed_ that we had to sacrifice
purity. If we are positive that a particular existentially quantified
value has a specific type (e.g., Bool), we can use unsafeCoerce to
cast the value into the type Bool [3]. This approach is one of the
foundations of the Dynamic library. The other foundation is an ability
to represent a type as a unique run-time value, provided by the
methods of the class like TypeRep. Given an existentially quantified
value and a value of the desired type, Dynamic compares type
representations of the two values. If they are the same, we can
confidently use unsafeCoerce to cast the former into the type of the
latter.

This works, yet leaves the feeling of dissatisfaction. For one thing,
we had to resort to an impure feature. More importantly, we placed our
trust in something like TypeRep and its members, that they give an
accurate and unique representation of types. But what if they lie to
us, due to a subtle bug in their implementation? What if they give the
same representation for two different types? unsafeCoerce will do its
dirty work nevertheless. Using the result would lead to grave
consequences, however.

This message describes sAFECoerce and the corresponding safe cast.
Both functions convert the values of one type into the target type.
One or both of these types may be existentially quantified.  When the
source and the target types are the same, both functions act as the
identity function. The safe cast checks that the type representations
of the source and the target types are the same. If they are, it
invokes sAFECoerce. Otherwise, we monadically fail. The function
sAFECoerce does the conversion without any type checking. It always
returns the value of the target type. If the source type was the same
as the target type, the return value has the same bit pattern as the
argument. If the types differ, the return value is just some default
value of the right type. The user can specify the default value as he
wishes.

Therefore, we can now write

* *Main case (EV False) of (EV x) - not $ sAFECoerce x
* True

We can also try

* *Main case (EV 'a') of (EV x) - not $ sAFECoerce x
* *** Exception: Prelude.undefined

The default value was 'undefined'.

The function safeCast is actually trivial

 safeCast::(Monad m, 

Re: Text I/O library proposal, first draft

2003-07-31 Thread Glynn Clements

Ben Rudiak-Gould wrote:

 module System.TextIOFirstDraft (...) where
 
 -- A BlockRecoder takes source and destination buffers and does some sort
 -- of translation between them. It returns the number of values (not
 -- bytes!) consumed and the number of values produced. It does not have to
 -- empty the input buffer or fill the output buffer on each call, but it
 -- must do something (i.e. it's not acceptable to return (0,0)). Coders
 -- will in general have internal state which is updated on each call.

It would be preferable if this wasn't all within the IO monad. It
shouldn't be necessary, even for stateful encodings.

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


Re: *safe* coerce, for regular and existential types

2003-07-31 Thread Derek Elkins
Throughout this message you imply, if not outright state, that Dynamics
requires unsafeCoerce/unsafePerformIO.  This is simply not the case. 
GHC implements Dynamics with unsafeCoerce, or did last time I checked,
but it can easily be implemented using only existentials. (I presume
that this decision was made either for efficiency, simplicity, and/or
simply that another (readily useable) technique was not known when the
library was made.)

Anyways, as I have often mentioned, A Lightweight Implementation of
Generics and Dynamics has an unsafePerformIO/Coerce free implementation
of Dynamics as well as Generics as the title suggests.


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


Re: Exporting GHC functions.

2003-07-31 Thread Thomas L. Bevan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sorry,

I've worked it out. Didn't read the docs properly as usual.

Tom

On Thu, 31 Jul 2003 04:20 pm, Thomas L. Bevan wrote:
 Here is a copy of all the files I am using to try to export a Haskell
 function.

 This compiles but produces a executable that simply hangs.

 Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/KU6DYha8TWXIQwoRAnxqAJ9160c/d+wZCdaAnutE9bfFYcJAoACbBniT
Faxu2fYxGU3AeAbu33yvd94=
=b+MM
-END PGP SIGNATURE-

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


Re: CSV parser, quotes?

2003-07-31 Thread Keith Wansbrough
 In attempting to improve the CSV parser based on comments, I have the 
 following code that's attached. I'm having a heck of a time getting the 
 double quotes = an escaped quote thing to work. There is some commented out 
 code which was my last attempt. As it stands the code works, minus the 
 escaped quotes. Remove the comments and it just hangs.

I haven't looked at the code, but it occurs to me that the issue may
be to do with lookahead.  If you're in a quoted string, then  means
a quote character in the string, but , or \n or EOF mean end of
cell.  You can't tell which is which until you read the final
character; specifically, you can't tell if the string has ended until
you read the newline or EOF at the end of the line.

Does that help?

--KW 8-)

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


RE: Ann: HAllInOne bug fix release

2003-07-31 Thread Hal Daume
(moved to haskell cafe -- hopefully the other threads will follow)

 I don't know why the all in one version might go slower though
 
 Virtual memory thrashing?  (Hal did say something about 
 needing lots of RAM.)

only to compile.  i haven't measured, but the resulting executable
shouldn't require any more memory.

it only hits about 400mbs max, though, which won't swap on my machine.

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


RE: Ann: HAllInOne bug fix release

2003-07-31 Thread Hal Daume
(haskell-cafe now)

Interesting.  I've stripped them and they are exactly the same size.
diff says they differ though.  pre-stripping, the normal nhc (non ai1)
is marginally larger (6.8m versus 7.0m).

I'll try to measure memory usage if someone tells me how :)

 - Hal

 --
 Hal Daume III   | [EMAIL PROTECTED]
 Arrest this man, he talks in maths.   | www.isi.edu/~hdaume


 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of John Meacham
 Sent: Wednesday, July 30, 2003 5:22 PM
 To: The Haskell Mailing List
 Subject: Re: Ann: HAllInOne bug fix release
 
 
 Another useful thing would be the striped binary sizes of the two
 versions. I am curious how much AllInOneing affects the resultant
 binary. Memory usage would also be interesting.
 John
 
 On Wed, Jul 30, 2003 at 04:22:58PM -0700, Hal Daume wrote:
  Ah, apparently it is not (at least not the Cygwin version).
  
  I recompiled NHC with GHC -O2, both the separate 
 compilation version and
  the all-in-over version.  Averaged over five runs, we see that the
  separate compilation version is actually *faster* than the 
 ai1 version:
  
  standard nhc compiled with ghc:
  
  real0m27.167s
  user0m9.991s
  sys 0m1.304s
  
  nhc all-in-one:
  
  real0m31.411s
  user0m10.007s
  sys 0m1.299s
  
  
  
  i am completely unable to explain this.  someone want to 
 hazard a guess?
  
   - hal, who is a bit disappointed now :(
  
   --
   Hal Daume III   | [EMAIL PROTECTED]
   Arrest this man, he talks in maths.   | 
 www.isi.edu/~hdaume
  
  
   -Original Message-
   From: [EMAIL PROTECTED] 
   [mailto:[EMAIL PROTECTED] On Behalf Of Wolfgang Jeltsch
   Sent: Wednesday, July 30, 2003 2:59 PM
   To: The Haskell Mailing List
   Subject: Re: Ann: HAllInOne bug fix release
   
   
   On Wednesday, 2003-07-30, 23:36, CEST, Hal Daume III wrote:
[...]
   
A few people have asked me for speed-up results from 
   All-In-One-ifying code,
so here's a good one.  We take two versions of NHC.  One is 
   the original
binary distribution and the other is the All-In-One-ified 
   version, compiled
by GHC.
   
   Hi,
   
   is the original binary distribution compiled with GHC? If 
   not, the speed-up 
   may also be the result of using a different compiler (i.e., GHC).
   
[...]
   
   Wolfgang
   
   ___
   Haskell mailing list
   [EMAIL PROTECTED]
   http://www.haskell.org/mailman/listinfo/haskell
   
  -- 
  Haskell mailing list
  [EMAIL PROTECTED]
  http://www.haskell.org/mailman/listinfo/haskell
  
 
 -- 
 --
 -
 John Meacham - California Institute of Technology, Alum. - 
 [EMAIL PROTECTED]
 --
 -
 ___
 Haskell mailing list
 [EMAIL PROTECTED]
 http://www.haskell.org/mailman/listinfo/haskell
 
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe


RE: Ann: HAllInOne bug fix release

2003-07-31 Thread Hal Daume
(cafe)

This seems like a reasonable hypothesis.  Is there a way to get GHC to keep trying, 
despite the enormity of the input file?

Specifically, I expect it to do a better job of (a) inlining and (b) specialization.  
Is there a way to hint to it to try a bit harder?  :)

 - Hal

 --
 Hal Daume III   | [EMAIL PROTECTED]
 Arrest this man, he talks in maths.   | www.isi.edu/~hdaume


 -Original Message-
 From: Koen Claessen [mailto:[EMAIL PROTECTED] 
 Sent: Thursday, July 31, 2003 1:49 AM
 To: Simon Peyton-Jones
 Cc: Hal Daume; Wolfgang Jeltsch; The Haskell Mailing List
 Subject: RE: Ann: HAllInOne bug fix release
 
 
 Simon Peyton-Jones wrote:
 
  | I don't know why the all in one version might go
  | slower though.
 
 How about some (artificial) cut-offs during optimization
 phases? Optimizing a hugs module could lead to some kind of
 combinatorial explosion (which gets cut off by the
 optimizer) which does not happen when you have separate
 modules?
 
 Just my 2 öre!
 
 /Koen
 
 
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe