Re: [Haskell-cafe] Re: Beginner: IORef constructor?

[Bernie Pope]

On 05/12/2006, at 1:00 PM, Benjamin Franksen wrote:


Bernie Pope wrote:

If you want a global variable then you can use something like:

import System.IO.Unsafe (unsafePerformIO)

global = unsafePerformIO (newIORef [])

But this is often regarded as bad programming style (depends who you
talk to).


Besides, isn't this example /really/ unsafe? I thought, at least  
the IORef

has to be monomorphic or else type safety is lost?


Perhaps your question is rhetorical, but in case it is not, then yes,
we ought to make it a monomorphic type.

This little example seg-faults on my mac, and no doubt on other  
machines as

well:

   import System.IO.Unsafe (unsafePerformIO)
   import Data.IORef

   global = unsafePerformIO (newIORef [])

   main = do
  modifyIORef global (id :)
  x <- readIORef global
  print ((head x + 1) :: Int)

It writes the identity function onto the front of the global  
variable, and then reads

it back as an int, and tries to do addition on it.

Cheers,
Bernie.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] There's nothing wrong with infinite types!

[ajb]

G'day all.

Quoting Stefan O'Rear <[EMAIL PROTECTED]>:

> I for one took that as a challenge, and have implemented a type
> inference engine for infinite types.

Very nice!  But there's plenty wrong with infinite types...

The fact is that infinite types are almost never what you want.
In the few situations where it is (usually in data structures), using
"newtype" usually isn't a huge imposition.

What you end up with instead is a bunch of programs that are obviously
wrong becoming well-typed.  Consider the following program:

  search p [] = error "not found"
  search p (x:xs)
| p x   = x
| otherwise = search p xs

Let's mutate the "otherwise" case with some common and some not-so-common
bugs:

  search p [] = error "not found"
  search p (x:xs)
| p x   = x
| otherwise = xs

  search p [] = error "not found"
  search p (x:xs)
| p x = x
| otherwise = search p

  search p [] = error "not found"
  search p (x:xs)
| p x = x
| otherwise = search xs

  search p [] = error "not found"
  search p (x:xs)
| p x = x
| otherwise = search

  search p [] = error "not found"
  search p (x:xs)
| p x = x
| otherwise = p

How many of these buggy versions would be type-correct if Haskell allowed
infinite types?

I'll wait while you go and check with your type checked.

...

Are you surprised?  I was.  Just about every dumb change I could think
of making to the "otherwise" case resulted in what would be a type-
correct function, if we allowed infinite types!

It wouldn't be so bad if it were unusual cases, but a lot of common
programmer mistakes (like leaving arguments off a recursive function
call) are only caught because of the occurs check.  Catching programmer
mistakes is one of the reasons why people like Haskell so much.  Given
that we have a servicable workaround (newtype), it would be a mistake to
allow types like this.

Cheers,
Andrew Bromage
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Halp- haskell logic prover

[Dan Mead]

Hey all, I've just finished my logic prover. I've been working on this as an
undergraduate project
with my advisor. Right now it only supports simple first order logic but in
the spring I'll be adding predicates.
Theres also a  simple gui  written in java 5 which is in the darcs
repository. Comments are welcome!


-Dan



http://haskell.org/haskellwiki/Libraries_and_tools/Theorem_provers

http://taz.cs.wcupa.edu/~dmead/code/halp/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] There's nothing wrong with infinite types!

[Stefan O'Rear]

I'm sure anyone who's used Haskell for any significant length of time
has received this error message:

Occurs check: cannot construct the infinite type: t = t -> t1

I for one took that as a challenge, and have implemented a type
inference engine for infinite types.

Expr> s
(a -> b -> c) -> (a -> b) -> a -> c
Expr> skk
a -> a
Expr> s(skk)(skk)
(fix a . (a -> b))
Expr>

Points of interest:

* There are NO error conditions.  it-unifier can assign a type to every
  syntactically valid expression of combinatory logic.

* Typechecking is guaranteed to terminate in a linear number of steps,
  an (apparently) stronger guarantee than that provided by DHM.

* (Mostly theoretical, since it-unify does not yet support sums or
  products): Fixpoint types subsume declared recursive datatypes.
  e.g: type List a = fix l . Either () (a,l)

darcs get http://members.cox.net/stefanor/fixtypes/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] HOgg 0.2.0 Released

[Conrad Parker]

HOgg 0.2.0 Released
---

The HOgg package provides a commandline tool for manipulating Ogg files,
and a corresponding Haskell library.

 http://snapper.kfish.org/~conrad/software/hogg/

This is the initial public release. The focus is on correctness of Ogg
parsing and production. The capabilities of the hogg commandline tool are
roughly on par with those of the oggz* tools[0], although hogg does not
yet provide an equivalent to oggz-validate.

HOgg supports chained and multiplexed Ogg bitstreams conformant with
RFC3533[1]. HOgg can parse headers for CMML, FLAC, OggPCM, Speex, Theora
and Vorbis media codecs, and can read and write Ogg Skeleton bitstreams.

[0] Oggz: http://www.annodex.net/software/liboggz/index.html
[1] RFC3533: http://www.ietf.org/rfc/rfc3533.txt

Installation


I am very interested in hearing about problems with building or installing
the package, particularly from people who are not yet familiar with building
from Haskell source. You need ghc instead of gcc; it compiles to a binary:

   $ ./Setup.hs configure
   $ ./Setup.hs build
   $ sudo ./Setup.hs install

Building of this release has been tested with:
 * GHC versions 6.4 and 6.6 [2]
 * The Haskell build system "Cabal" versions 1.1.3, 1.1.4, 1.1.6, and the
   current development trunk. [3]
 * fps (Data.ByteString.Lazy) version 0.7, and development trunk. [4]

Note that if you are using the recently-released GHC 6.6 then you will not
need separate installs of Cabal or fps. You will however need to remove the
word "fps" from the hogg.cabal file; see the README for details.

The GHC and Cabal versions listed above span the packages available in most
current distributions. I've tested on Debian unstable, Ubuntu Dapper and
Ubuntu Edgy. I'm particularly interested to hear reports of build success or
failure on other distributions or operating systems.

[2] GHC: http://www.haskell.org/ghc/
[3] Cabal: http://www.haskell.org/cabal/
[4] fps: http://www.cse.unsw.edu.au/~dons/fps.html

Usage
-

$ hogg help

Usage: hogg  [options] filename ...

Commands:
 help  Display help for a specific subcommand

Reporting:
 info  Display information about the file and its bitstreams
 dump  Hexdump packets of an Ogg file
 pagedump  Display page structure of an Ogg file
 dumpraw   Dump raw (unparsed) page data

Extraction:
 rip   Rip selected logical bistreams from an Ogg file (default: all)
 reconstruct   Reconstruct an Ogg file by doing a full packet demux

Editing:
 merge Merge, interleaving pages in order of presentation time
 addskel   Write a Skeleton logical bitstream

Source
--

Source code is available from the darcs repository at:

 darcs get http://snapper.kfish.org/~conrad/software/hogg/

cheers,

Conrad.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Download locations for former-base libraries?

[Ross Paterson]

On Tue, Dec 05, 2006 at 02:57:36PM -0600, John Goerzen wrote:
> Ross Paterson wrote:
> > You could direct them to
> > 
> > http://hackage.haskell.org/packages/unstable/
> 
> Is that site guaranteed to have the same packages/versions as the ghc
> extralibs has?

For the extralibs, those version numbers denote the versions bundled
with GHC 6.6.  Later versions will have different numbers.
(And maybe the directory name could change; "unstable" sounds a bit
unsettling for non-Debian users.)

> Oh, and BTW, does cabal-put work with the current cabal in GHC 6.6 these
> days?  I would love to be able to upload my packages to your repo
> automatically, but not at the cost of installing a different Cabal on my
> box.

The old cabal-put is no longer in use -- now there's just a script of
the same name on hackage.haskell.org, which you have to be in group
hackage to use.  Isaac would presumably be happy to add you.

There's no upload tool yet, for lack of someone to write it, but I hope
the new version will be just a password-protected CGI file upload.
That would be less secure than a public key setup, but would avoid
needing special software on the client side.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] state updates and efficiency

[Tim Newsham]

I am writing some code with complex nested state.  I have a question
about performance with respect to the State monad and the Reader monad.

This is somewhat long, so a quick summary of the question up front:
Can the compiler optimize out state updates that dont change the
state?

The question inline with the code:


module Test where
import Control.Monad.State
import Control.Monad.Reader


I have some nested state.  This is a simplified example where
we have one record inside another.  In my real-world example there
is more nesting and there are lists and maps involved as well.


data T1 = T1 { f1 :: Int, f2 :: T2 } deriving(Show)
data T2 = T2 { f3 :: Int, f4 :: Int } deriving(Show)


I want to build generic modifiers and reuse them often.
A good example is modifying a numeric value:


adjNum :: (Num a) => a -> State a ()
adjNum n = modify (+ n)


I'm going to be writing state code for my T1 structure which is my
master structure.  If I'm going to be able to reuse adjNum I am
going to have to run a nested state action inside an enclosing
state monad.  I can build a lifter that does this as long as
I know how to extract the nested state and set it back in the
enclosing state:


withInnerM :: (o -> i) -> (i -> o -> o) -> State i a -> State o a
withInnerM gettor settor act = do
outer <- get
let inner = gettor outer
(ret, inner') = runState act inner
outer' = settor inner' outer
put outer'
return ret


Now we can make lifters for each of the fields:


withF1M = withInnerM f1 (\f r -> r {f1=f})
withF2M = withInnerM f2 (\f r -> r {f2=f})
withF3M = withInnerM f3 (\f r -> r {f3=f})
withF4M = withInnerM f4 (\f r -> r {f4=f})


which lets us write some state code for T1 using building blocks like
adjNum.  For example, the following code will add a value to
f1, add another value to f2's f3 and finally return the value of f2's
f4:


tweakT1 :: Int -> Int -> State T1 Int
tweakT1 v1 v3 = do
  withF1M $ adjNum v1
  withF2M $ withF3M $ adjNum v3
  withF2M $ withF4M $ get


My question here has to do with efficiency.  In order to update
f2's f3 a new T2 had to be constructed and used to construct a
new T1.  There's no way around this (I assume).  But when doing
a mere get of f4, there's no reason why we should have to build a
new T2 and then a new T1 since nothign changed.  But that's how
the code is written.

We could write a different lifter that does not perform a state
put on the return path.  If we did this with the state monad then
someone could accidentally use that non-modify version of the lifter
and lose an update.  So instead I chose to use the Reader monad and
let the type system enforce the difference between lifters that
modify (M) and those that just read (R).  This involved two kinds
of lifters.

The first lifter runs a Reader action inside of a State monad:


withRead :: Reader s a -> State s a
withRead act = do
s <- get
return $ runReader act s


The second lifter runs a nested Reader action inside of an enclosing
Reader monad.  It is similar in spirit to withInnerM:


withInnerR :: (o -> i) -> Reader i a -> Reader o a
withInnerR gettor act = do
i <- asks gettor
return $ runReader act i


again we can generate lifters for each field:


withF1R = withInnerR f1
withF2R = withInnerR f2
withF3R = withInnerR f3
withF4R = withInnerR f4


And finally we can use a reader monad to eliminate the extra state
updates from our previous tweakT1 implementation:


tweakT1' :: Int -> Int -> State T1 Int
tweakT1' v1 v3 = do
  withF1M $ adjNum v1
  withF2M $ withF3M $ adjNum v3
  withRead $ withF2R $ withF4R $ ask

main = do
  let x = T1 1 (T2 3 4)
  print $ runState (tweakT1 5 6) x
  print $ runState (tweakT1' 5 6) x


My question here is: is it worth it?

If I run


v1 = T2 1 1
v2 = v1 {f3 = 1}


is the compiler smart enough to notice that the record update doesn't
result in a change, and avoid constructing an entirely new T2?
If so, then I think the original implementation TweakT1 would be
about as efficient as the more complicated TweakT1'.  Otherwise,
I think the latter would be a lot more efficient when the state is
large and complex.

Tim Newsham
http://www.thenewsh.com/~newsham/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Download locations for former-base libraries?

[John Goerzen]

Ross Paterson wrote:

> 
> You could direct them to
> 
> http://hackage.haskell.org/packages/unstable/

Is that site guaranteed to have the same packages/versions as the ghc
extralibs has?

Oh, and BTW, does cabal-put work with the current cabal in GHC 6.6 these
days?  I would love to be able to upload my packages to your repo
automatically, but not at the cost of installing a different Cabal on my
box.

Thanks,

-- John

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] GADT vs Arrows for parsers/FSMs/etc.

[Neil Mitchell]

Hi


It seems like Haskell has two emerging idioms for parsing and fsms:
GADTs and Arrows.


What about something else? If you limit yourself to the two things
that look "new and cool" (where emerging is another word for new, and
idiom seems to be the current Haskell word for cool), you miss out on
all the tried and tested stuff.


I am thinking about using one of these idioms to represent server
structure in a future version of HAppS but I'm not sure where to
start.  Why would one choose one or the other?


I would pick Arrows (over GADTs) because Arrows are Haskell, and are
supported by multiple Haskell compilers. Other than that (as far as I
was aware) these two things are massively different, so I wouldn't
have thought it was a "one or the other" choice usually.

Thanks

Neil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] GADT vs Arrows for parsers/FSMs/etc.

[S. Alexander Jacobson]

It seems like Haskell has two emerging idioms for parsing and fsms:

GADTs and Arrows.

I am thinking about using one of these idioms to represent server 
structure in a future version of HAppS but I'm not sure where to 
start.  Why would one choose one or the other?


-Alex-


__
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Picking out elements of a heterogenous list

[J. Garrett Morris]

I generally use the Typeable class for this.  In that example, you'd want:

class Typeable a => Shape_ a

instead of just

class Shape_ a

and then your filter predicate would look like:

isSquare :: Shape -> Bool
isSquare (Shape s) = typeOf s == typeOf square
  where square :: Square ; square = undefined

(warning: I didn't try this code.)

That adds a little overhead (particularly in that everything must now
derive Typeable) but is one of the better solutions I've seen.

/g

On 12/5/06, Creighton Hogg <[EMAIL PROTECTED]> wrote:

Hi Haskell-ers,
So I think I understand the idea of creating a heterogenous list using
typeclasses and existentials, but I don't see how to filter the list
to retrieve elements of the list that are of only one type.

More concretely, taking the example here how could we take a list of shapes
[Shape] and pull out all objects that are Squares?
I don't see an obvious way this makes sense.
Is there a way of doing heterogenous lists that would make this possible?

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe






--
It is myself I have never met, whose face is pasted on the underside of my mind.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Download locations for former-base libraries?

[Ross Paterson]

On Tue, Dec 05, 2006 at 12:18:25PM -0600, John Goerzen wrote:
> For each such library, I need to be able to tell users where they can go to
> download the dependency.
> 
> But I'm having a lot of trouble finding canonical download locations.  For
> instance, the homepage of regex-compat, according to
> http://darcs.haskell.org/packages/regex-compat/regex-compat.cabal, is
> http://sourceforge.net/projects/lazy-regex.  But the software available for
> download there doesn't even provide Text.Regex.
> 
> Of course, just saying "download the latest version with darcs" isn't
> useful, either.  People that want to use my package shouldn't have to have
> darcs, and they also shouldn't have to fight with broken development
> software.

You could direct them to

http://hackage.haskell.org/packages/unstable/

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Download locations for former-base libraries?

[Neil Mitchell]

Hi


Of course, just saying "download the latest version with darcs" isn't
useful, either.  People that want to use my package shouldn't have to have
darcs, and they also shouldn't have to fight with broken development
software.

Or should I be telling people to download the GHC 6.6 extralibs source?
That doesn't seem quite right either; it's packaged as a tar.bz2, but what
would a Windows user with HUGS do?  That person probably couldn't even
unpack it.


I started doing some work towards this on windows:

http://www-users.cs.york.ac.uk/~ndm/projects/windows.php

I found that generally working out of the darcs repo's is both
horribly unreliable, but the easiest way to go about it, because its
more consistent.

Thanks

Neil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Download locations for former-base libraries?

[John Goerzen]

Hi,

I am working on updating and splitting things out of MissingH.

MissingH is going to depend on regex-compat, HUnit, QuickCheck, and
FilePath, among others.

For each such library, I need to be able to tell users where they can go to
download the dependency.

But I'm having a lot of trouble finding canonical download locations.  For
instance, the homepage of regex-compat, according to
http://darcs.haskell.org/packages/regex-compat/regex-compat.cabal, is
http://sourceforge.net/projects/lazy-regex.  But the software available for
download there doesn't even provide Text.Regex.

Of course, just saying "download the latest version with darcs" isn't
useful, either.  People that want to use my package shouldn't have to have
darcs, and they also shouldn't have to fight with broken development
software.

Or should I be telling people to download the GHC 6.6 extralibs source? 
That doesn't seem quite right either; it's packaged as a tar.bz2, but what
would a Windows user with HUGS do?  That person probably couldn't even
unpack it.

Thanks,

-- John

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Picking out elements of a heterogenous list

[David Roundy]

On Tue, Dec 05, 2006 at 11:08:07AM -0600, Creighton Hogg wrote:
> Hi Haskell-ers,
> So I think I understand the idea of creating a heterogenous list using
> typeclasses and existentials, but I don't see how to filter the list
> to retrieve elements of the list that are of only one type.
> 
> More concretely, taking the example
> herehow could we take
> a list of shapes [Shape] and pull out all objects that are
> Squares?
> I don't see an obvious way this makes sense.
> Is there a way of doing heterogenous lists that would make this possible?

It's ugly but you could stick converters in the class itself:

class MyClass a where
  isTypeA :: a -> Maybe A
  isTypeA _ = Nothing
  isTypeB :: a -> Maybe B
  isTypeB _ = Nothing
  isTypeC :: a -> Maybe C
  isTypeC _ = Nothing

This limits you to a finite number of specific types, but I suspect that's
unavoidable.  Actually, your list can have any number of types in it, but
you can only extract a fixed set of types.

Another perhaps prettier way to do this would be to use an ADT to hold the
elements of your list, so that the existentials could be
reconstructed by pattern matching:

data FunnyElement = ElemA A | ElemB B | ElemC C

Again, it only works for lists containing a fixed set of types.
-- 
David Roundy
Department of Physics
Oregon State University
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Picking out elements of a heterogenous list

[Steve Schafer]

To: "Creighton Hogg" <[EMAIL PROTECTED]>
Subject: Re: [Haskell-cafe] Picking out elements of a heterogenous list
From: Steve Schafer <[EMAIL PROTECTED]>
Date: Tue, 05 Dec 2006 12:33:16 -0500

On Tue, 5 Dec 2006 11:08:07 -0600, you wrote:

>Hi Haskell-ers,
>So I think I understand the idea of creating a heterogenous list using
>typeclasses and existentials, but I don't see how to filter the list
>to retrieve elements of the list that are of only one type.
>
>More concretely, taking the example
>herehow could we take
>a list of shapes [Shape] and pull out all objects that are
>Squares?
>I don't see an obvious way this makes sense.
>Is there a way of doing heterogenous lists that would make this possible?

Use filter, passing it a predicate that returns True for Squares and
False otherwise:

 isASquare :: Shape -> Bool
 isASquare (Square _) = True
 isASquare _ = False

 filter isASquare myShapes

Steve Schafer
Fenestra Technologies Corp.
http://www.fenestra.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Picking out elements of a heterogenous list

[Creighton Hogg]

Hi Haskell-ers,
So I think I understand the idea of creating a heterogenous list using
typeclasses and existentials, but I don't see how to filter the list
to retrieve elements of the list that are of only one type.

More concretely, taking the example
herehow could we take
a list of shapes [Shape] and pull out all objects that are
Squares?
I don't see an obvious way this makes sense.
Is there a way of doing heterogenous lists that would make this possible?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: haddock not finding base lib docs -- $topdir ?

[Simon Marlow]

[ moving to haskell-cafe@haskell.org ]

Claus Reinke wrote:
This is due to the way GHC is installed on Windows, the package 
database doesn't have hardcoded pathnames, the idea being that you can 
move your GHC anywhere in the filesystem and it will still work.


this is an essential feature (for instance, running GHC from a USB or 
network drive, or just unpacking snapshots without using installers), 
please do not start splicing in absolute paths!


Don't worry, we don't intend to do that.

Unfortunately this means that Haddock can't find the documentation for 
the packages.


this part I do not understand - if GHC and ghc-pkg can find the 
packages, why can't Haddock? wouldn't it just be a case of making 
$topdir be in a fixed relationship to the output of "ghc --print-libdir"?


well yes, but Haddock doesn't invoke 'ghc --print-libdir'.  I think it would be 
better for ghc-pkg to hide $topdir from everyone by replacing it with its value 
in any ghc-pkg output.  After all, $topdir is just a hack to make the GHC tree 
location-independent on Windows, it's not a documented feature of the package 
system.


or should there be a way to query ghc-pkg for the list of package 
location roots? as you say, the main docs will be in a known location 
relative to GHC, but perhaps docs in general should be be in a known 
location relative to their packages, which ghc-pkg (or other tools for 
other implementations) should be able to locate?


One workaround is to specify the paths by hand, using Haddock's 
--read-interface flag.  You're using Haddock via Cabal though, so that 
doesn't work too well. The other workaround is to find GHC's 
package.conf file and replace the string $topdir with the literal path 
("c:/ghc/ghc-6.6" in your case - perhaps you have to append "/doc" for 
the haddock fields, though).


will all docs be moved into "`ghc --print-libdir`\\doc"?


No.  Docs can be installed wherever you like.  Cabal has a policy for 
installation locations on Windows, which you can override if you want.


> what about

local/user package databases?


Same here, you can install things wherever you like.  In fact, installing things 
inside the GHC tree isn't recommended.


Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] unexpected compiler behavior

[Donald Bruce Stewart]

jepalomar23:
> Hi,
> I am newbie in Haskell and do not understand why the interpreted mode
> differs from the compiled program.
> I run this code
> main =  do
>   putStr "line1"
>   x<-getLine
>   putStr "line2"
>   y<-getLine
>   return (x++y)
> 
> either under runhugs or runghc or in a console under ghci and works
> properly, that is, first displays "line1"  and then prompts for the
> corresponding inputs through the keyboard, and so on. However, if I
> compile the code with the command line
> ghc --make Main.hs -o main
> and launch the compiled program main, then at first prompts for the
> input lines through the keyboard and then displays the strings "line1"
> "line2".

> I have read in the tutorials that the command "do" implies an ordered
> execution and this only occurs in interpreted mode.
> Using the monadic notation >> , >>= occurs the same unordered behavior.
> ?How can I avoid the unordered execution of this code in a compiled
> program?

Sounds like the difference in buffering between the interactive
environments and compiled code.

Try:

import System.IO

main =  do
hSetBuffering stdout NoBuffering
putStr "line1 "
x <- getLine
putStr "line2 "
y <- getLine
print (x++y)

Running this:

$ ./a.out 
line1 1
line2 2
"12"

-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] unexpected compiler behavior

[Cale Gibbard]

The problem is most likely that line-buffered (or possibly
block-buffered) IO is turned on, which means that buffers will only
automatically be flushed to the display at the ends of lines. You can
fix it by importing System.IO, and either calling (hFlush stdout)
explicitly, or by calling (hSetBuffering NoBuffering stdout) at the
start of your program.

On 05/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Hi,
I am newbie in Haskell and do not understand why the interpreted mode
differs from the compiled program.
I run this code
main =  do
  putStr "line1"
  x<-getLine
  putStr "line2"
  y<-getLine
  return (x++y)

either under runhugs or runghc or in a console under ghci and works
properly, that is, first displays "line1"  and then prompts for the
corresponding inputs through the keyboard, and so on. However, if I
compile the code with the command line
ghc --make Main.hs -o main
and launch the compiled program main, then at first prompts for the
input lines through the keyboard and then displays the strings "line1"
"line2".
I have read in the tutorials that the command "do" implies an ordered
execution and this only occurs in interpreted mode.
Using the monadic notation >> , >>= occurs the same unordered behavior.
¿How can I avoid the unordered execution of this code in a compiled
program?
Thanks in advance.
jepalomar







___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] unexpected compiler behavior

[jepalomar23]

Hi,
I am newbie in Haskell and do not understand why the interpreted mode
differs from the compiled program.
I run this code
main =  do
  putStr "line1"
  x<-getLine
  putStr "line2"
  y<-getLine
  return (x++y)

either under runhugs or runghc or in a console under ghci and works
properly, that is, first displays "line1"  and then prompts for the
corresponding inputs through the keyboard, and so on. However, if I
compile the code with the command line
ghc --make Main.hs -o main
and launch the compiled program main, then at first prompts for the
input lines through the keyboard and then displays the strings "line1"
"line2".
I have read in the tutorials that the command "do" implies an ordered
execution and this only occurs in interpreted mode.
Using the monadic notation >> , >>= occurs the same unordered behavior.
¿How can I avoid the unordered execution of this code in a compiled
program?
Thanks in advance.
jepalomar







___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] using greencard to write COM in haskell

[Bulat Ziganshin]

Hello Anatoly,

Tuesday, December 5, 2006, 1:32:27 AM, you wrote:

> Also, I would like to have my haskell programs use my implementation
> of realloc which takes a context, is there an easy way to change ghc
> to use it?  I guess I should start looking at the ghc source.

for which operations? if you mean using it for Haskell objects - it's
impossible, because ghc by itself has very sophisticated memory control
strategy 


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe