Re: [Haskell-cafe] monomorphism restriction

[Rafal Kolanski]

Ryan Ingram wrote:

sumns 0 = 0
sumns x = sumns (x-1) + n

Without the monomorphism restriction, computing n is a function call;
it is evaluated each time it is asked for.


I'm relatively new to Haskell, and since this topic already came up, I
was wondering if anyone could explain to me how this ties into implicit
parameters which "escape" from their respective functions?

For instance, if I just state:
maxLength = maxLengthParameter ?config
without providing a type signature and then use it, I get warned that
?config "escapes" from maxLength and that I should provide a type
signature or turn off the monomorphism restriction.

I find implicit parameters are a really nice way to pass a configuration
to a whole tree of functions (in this case an LZSS compressor) without
having to explicitly add it as a parameter to every single one of the
functions.

What are the performance implications of turning off the restriction and
allowing implicit parameters to "escape"? Are there general performance
implications of implicit parameters I am not aware of?

Yours Sincerely,

Rafal Kolanski.


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

Re: [Haskell-cafe] cabal-install failure

[Duncan Coutts]

On Fri, 2008-06-13 at 22:10 -0400, Gwern Branwen wrote:

> I think this may be Cabal's fault anyway. The yi.cabal includes the line:
>  build-tools:   alex >= 2.0.1 && < 3
> 
> in the 'executable yi' section, right after the build-depends, so Yi
> is being straightforward and upfront about its needs. Now, Cabal is
> obviously checking that the build-depends is satisfied first, but why
> isn't it checking that alex is available when it has the information
> it needs to check, presumably anything in build-tools is *required*,
> and the field name suggests that it would be checked?

Yes, you're right. This is the ticket you filed last time:

http://hackage.haskell.org/trac/hackage/ticket/227

and my comment:

One problem is that not all build-tools correspond to haskell
packages. Some do some don't. We have a hard coded list of them
at the moment (which can be extended in Setup.hs files) so we
could extend that with what haskell package if any the tools
correspond to. Any better suggestions to make it a tad more
generic?

If anyone has a godd suggestion I'm happy to hear it. Otherwise we can
just add a Maybe Dependency to the Program type to indicate that some
build tools have a corresponding haskell package.

Duncan

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

Re: [Haskell-cafe] cabal-install failure

[Claus Reinke]

http://hackage.haskell.org/trac/hackage/ticket/227

   One problem is that not all build-tools correspond to haskell
   packages. Some do some don't. We have a hard coded list of them
   at the moment (which can be extended in Setup.hs files) so we
   could extend that with what haskell package if any the tools
   correspond to. Any better suggestions to make it a tad more
   generic?


That list seems to be in Distribution/Simple/Program.hs, in case 
anyone else is looking for it. Encoded information includes: 
dependency name, program name (if different from dependency),

option to get version info and code to extract it (with one apparently
very special case being hsc2hs).

Btw, most of the version extraction code looks like a regular 
expression match - wouldn't that make the specification easier

(and turn the comments into part of the spec)?


If anyone has a godd suggestion I'm happy to hear it. Otherwise we can
just add a Maybe Dependency to the Program type to indicate that some
build tools have a corresponding haskell package.


I'm not sure what you're suggesting there (currently even those
tools that can be built with Cabal do not register with Cabal), but 
here are my suggestions:


1. Haskell tools should register with Cabal, whether built with it
   (such as Alex, Happy, ..) or not (such as GHC, ..). That 
   registration should include any build-relevant information

   (versions/variants, ..).

2. When checking a build-tools dependency, Cabal checks
   (a) whether the tool is registered with Cabal
   (b) whether the tool is registered with the system installation manager
   (c) whether the tool can be found by other means (configure,
   built-in rules, ..)

In other words, make tools look like packages (lifetime dependency
management, not just build support), and make system packages look 
like Cabal packages (Cabal as the interface to native managers), using 
special treatment only if absolutely necessary. I thought those suggestions

were clear from my earlier messages?-)

Claus

http://www.haskell.org/pipermail/haskell-cafe/2008-May/043368.html
http://www.haskell.org/pipermail/haskell-cafe/2008-June/043977.html
http://www.haskell.org/pipermail/haskell-cafe/2008-June/043910.html


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

[Haskell-cafe] Re: working with Random.randoms

[Jon Fairbairn]

Stephen Howard <[EMAIL PROTECTED]> writes:

> I am a newcomer doing my obligatory struggling with
> Haskell's type system, 

That's your mistake. Don't struggle with the type system,
the type system is your friend; when it tells you you are
doing something wrong, it's usually right.

> and I've got a nut I've not been able to crack.  Given:
>
> import Random
>
> random_test :: Int -> String
> random_test n = do
>g <- getStdGen
>take n (randoms g)::String

My immediate reaction on seeing this is that "do" is for
manipulating monads, but the only monad you've indicated in
the type is [] (from String = [Char]), and that's probably
an accident.

In GHCi:

Prelude> :t Random.getStdGen
Random.getStdGen :: IO System.Random.StdGen

What this says is that getStdGen isn't a function, which is
to say it doesn't always return the same value (ie it isn't
pure -- it wouldn't be much use if it were!). In effect it
uses the real world to get a new value, and such things are
kept safely in the IO monad. In C, everything is in the IO
monad; there's no way of telling from the type whether
something is pure or not¹. In Haskell (apart from some
ugliness that's supposed to stay hidden) you have to
distinguish between pure and impure, and the type checker
keeps track of all this for you.

> And yet, when I run these lines in GHCI by hand,

The top level of GHCi is IO (which shouldn't come as a
surprise!)

> things seem to work (though the string is the same set of
> random characters each time, another bit that I need to
> solve

That's a somewhat obscure aspect of GHCi, I think, to do
with "not reverting top-level expressions".  If you do this:

Prelude> :set +r
Prelude> g <- Random.getStdGen -- what's the type?
1954047482 7573
Prelude> g <- Random.getStdGen -- what's the type?
1626678354 7697
Prelude> 

you see that you get a different StdGen each time.

> I'm guessing that randoms is returning an IO type but I'm
> not sure how to go about extracting the String to return to
> the calling action.  Changing the type signature to Int ->
> IO  String only gives me a different error.

If you do any IO, you've done some IO! So you need to lift
out the StdGen and pass that to the functions that you want
to use it.

main :: IO()
   do gen <- getStdGen
  the_list <- real_programme gen
  print the_list

You should be able to deduce from the fact that the first
argument of real_programme here is of type StdGen (not IO
anything) and its result type is [something] that
real_programme is pure, and gen has only one value
throughout. So if you want more than one random list out of
it, you either need to use Random.split or pass more than
one gen in.


[1] Were you truly perverse, you could define your own
libraries in Haskell so that YourInt = IO Int; YourDouble =
IO Double etc, and make appropriate classes in place of Num
&c (hiding the proper ones), so that

+ :: YourInt -> YourInt -> YourInt

and so on (you'd have to define your own Bool and if, too,
but Haskell can do that). Then the type checker would
overlook all sorts of mistakes that it could otherwise have
caught.


-- 
Jón Fairbairn [EMAIL PROTECTED]
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html  (updated 2008-04-26)

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

[Haskell-cafe] ANN: Topkata

[Christoph Bauer]

Hi All,

Topkata is a simple OpenGL Game written in Haskell. It's not very
advanced. Goal so far is to guide a ball trough an labyrinth to the
opposite corner.  The web page shows an screenshot. It's only tested
under Linux.

http://home.arcor.de/chr_bauer/topkata.html

Feedback&Patches are welcome. BTW, I had a lot of support in #haskell!

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

Re: [Haskell-cafe] ANN: Topkata

[Neil Mitchell]

Hi Christoph,

>  opposite corner.  The web page shows an screenshot. It's only tested
>  under Linux.

Looks cool! Could you upload it to hackage?

http://hackage.haskell.org/

Once its on hackage, using cabal install, it should be possible to get
your game going with as little as:

cabal install topkata && topkata

That would be awsome for trying it out!

Thanks

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

[Haskell-cafe] ANN: Mueval 0.21

[Gwern Branwen]

Hiya everyone. I'd like to announce the release of a little CLI program I 
whipped up. It's called mueval 
.

WHAT:
Mueval grew out of my discontent with Lambdabot: it's really neat to be able to 
run expressions like this:

07:53 < ivanm> > filter (\ x -> isLetter x || x == '\t') "asdf$#$ dfs"
07:55 < lambdabot>  "asdfdfs"

But lambdabot is crufty and very difficult to install or run. IMO, we need a 
replacement or rewrite, but one of the things that make this difficult is that 
lambdabot uses hs-plugins to get that sort of evaluation functionality, and 
hs-plugins is half the problem. We want some sort of standalone executable 
which provides that functionality. Now, 'ghc -e' is obviously unsuited because 
there is no sandboxing, so what I've done is basically marry the GHC API (as 
rendered less sharp-edged by Hint) with a bunch of resource limits and 
sandboxing (as largely stolen from lambdabot).

EXAMPLES:
The end result is an adorable little program, which you can use like this:

 bash-3.2$ mueval --expression '1*100+1'
 Expression type: (Num t) => t
 result: "101"

 bash-3.2$ mueval --expression "filter (\`notElem\` ['A'..'Z']) \"abcXsdzWEE\""
 Expression type: [Char]
 result: "\"abcsdz\""

Note that mueval will avoid all the attacks I've been able to test on it:

 bash-3.2$ mueval --expression 'let x = x in x'
 Expression type: t
 result: "mueval: Time limit exceeded

 bash-3.2$ mueval --expression "let foo = readFile \"/etc/passwd\" >>= print in 
foo"
 Expression type: IO ()
 result: ""

 bash-3.2$ mueval --module System.IO.Unsafe --expression "let foo = 
unsafePerformIO readFile \"/etc/passwd\" in foo"
 mueval: Unknown or untrusted module supplied! Aborting.


SUMMARY:
Anyway, it's my hope that this will be useful as an example or useful in itself 
for people endeavouring to fix the lambdabot situation or just in safely 
running code period.

GETTING:
You can download mueval at the usual place: 
. (There 
will probably be a darcs repository at some point.)

-
TODO:
Mueval isn't feature-complete yet. The last thing I want to add is an ability 
to change the current user to 'mubot', which presumably the user will have set 
up to have access to next to nothing much like is already often done with 
daemons, but I haven't been able to figure out how to do this - the only 
suitable function I've found is 'setUID', and that requires one to be root...

--
gwern
SHA Fetish Ceridian Eurosat munitions MCI spies 26 M.P.R.I. ISN


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

[Haskell-cafe] Hoogle totally broken?

[Richard]

It'd seem that (at least the online version of) Hoogle is totally broken
and useless. See, for example, the output when looking for:
Monad m => m a -> (a -> m b) -> m b (i.e. (>>=)'s type)
over at:
http://haskell.org/hoogle/?q=Monad+m+%3D>+m+a+->+(a+->+m+b)+->+m+b

Data.Generics.Sche...   everywhere  :: (a -> a) -> a -> a
Data.Generics.Sche...   everywhere' :: (a -> a) -> a -> a
Prelude.($) :: (a -> b) -> a -> b
Prelude.($!):: (a -> b) -> a -> b
Data.Function.  ($) :: (a -> b) -> a -> b
Prelude.maybe   :: b -> (a -> b) -> Maybe a -> b
Data.Maybe. maybe   :: b -> (a -> b) -> Maybe a -> b

... and so on. (>>=) isn't there at all!?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Hoogle totally broken?

[Brent Yorgey]

On Sat, Jun 14, 2008 at 9:10 AM, Richard <[EMAIL PROTECTED]>
wrote:

> It'd seem that (at least the online version of) Hoogle is totally broken
> and useless. See, for example, the output when looking for:
>Monad m => m a -> (a -> m b) -> m b (i.e. (>>=)'s type)
> over at:
> http://haskell.org/hoogle/?q=Monad+m+%3D>+m+a+->+(a+->+m+b)+->+m+b
>
> Data.Generics.Sche...   everywhere  :: (a -> a) -> a -> a
> Data.Generics.Sche...   everywhere' :: (a -> a) -> a -> a
> Prelude.($) :: (a -> b) -> a -> b
> Prelude.($!):: (a -> b) -> a -> b
> Data.Function.  ($) :: (a -> b) -> a -> b
> Prelude.maybe   :: b -> (a -> b) -> Maybe a -> b
> Data.Maybe. maybe   :: b -> (a -> b) -> Maybe a -> b
>
> ... and so on. (>>=) isn't there at all!?
>

It's well-known that the current version of Hoogle doesn't deal well with
type constructors, like the 'm' in your type above.  However, you're (we're
all) in luck, since Neil Mitchell is working on a new version of Hoogle for
GSoC as we speak! =)

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

Re: [Haskell-cafe] working with Random.randoms

[Henning Thielemann]

On Fri, 13 Jun 2008, Stephen Howard wrote:


Hi List,

I am a newcomer doing my obligatory struggling with Haskell's type system, 
and I've got a nut I've not been able to crack.  Given:


import Random

random_test :: Int -> String
random_test n = do
  g <- getStdGen
  take n (randoms g)::String

I'm expecting that I ought to be able to pass this action an integer and get 
back a random string that long (given, not all characters may be printable).


If you only need an arbitrary sequence and it is ok for you to get always 
the same one, you can construct a random generator using mkStdGen.

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

Re: [Haskell-cafe] ANN: Topkata

[Thomas Davie]

On 14 Jun 2008, at 12:45, Christoph Bauer wrote:


Hi All,

Topkata is a simple OpenGL Game written in Haskell. It's not very
advanced. Goal so far is to guide a ball trough an labyrinth to the
opposite corner.  The web page shows an screenshot. It's only tested
under Linux.

http://home.arcor.de/chr_bauer/topkata.html

Feedback&Patches are welcome. BTW, I had a lot of support in #haskell!


Looks awesome, and I completely agree with Niel -- hackage it up!

In the mean time -- who knows enough to make ghc target ARM, and get  
this to link against the iPhone libraries?  This would be quite a coup  
if it could be made to run there!


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

Re: [Haskell-cafe] Hoogle totally broken?

[Daniel Fischer]

Am Samstag, 14. Juni 2008 15:10 schrieb Richard:
> It'd seem that (at least the online version of) Hoogle is totally broken
> and useless. See, for example, the output when looking for:
>   Monad m => m a -> (a -> m b) -> m b (i.e. (>>=)'s type)
> over at:
> http://haskell.org/hoogle/?q=Monad+m+%3D>+m+a+->+(a+->+m+b)+->+m+b
>
> Data.Generics.Sche... everywhere  :: (a -> a) -> a -> a
> Data.Generics.Sche... everywhere' :: (a -> a) -> a -> a
> Prelude.  ($) :: (a -> b) -> a -> b
> Prelude.  ($!):: (a -> b) -> a -> b
> Data.Function.($) :: (a -> b) -> a -> b
> Prelude.  maybe   :: b -> (a -> b) -> Maybe a -> b
> Data.Maybe.   maybe   :: b -> (a -> b) -> Maybe a -> b
>
> ... and so on. (>>=) isn't there at all!?

It's near the bottom of page 4 of the results.
hoogle doesn't do an exact search, it reports all "close enough matches", 
which sometimes is less useful than other times. One great thing about 
hoogle's notion of 'close enough' is that it includes permutations of 
parameters, one less good thing is that it's not particularly faithful to 
type constructors. 
I think Neil's in the process of writing hoogle 4, which supposedly will be 
better with such things. However, in spite of hoogle's quirks and 
shortcomings, if you get used to them, it's a very useful tool already.

Cheers,
Daniel

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

Re: [Haskell-cafe] Hoogle totally broken?

[Neil Mitchell]

Hi Richard,

> It'd seem that (at least the online version of) Hoogle is totally broken
>  and useless.

To finish your sentance: "when searching for types with higher-kinded
type classes". In practice, this usually means Monad and occasionally
Functor.

>  ... and so on. (>>=) isn't there at all!?

It is, but its on page 4. That's clearly a bug, and a well known one.

I am currently writing Hoogle 4, details can be found here:
http://neilmitchell.blogspot.com/2008/04/summer-of-code-2008.html

To quote from that page:


# Removal of all bugs

Hoogle 3 has a number of embarrassing bugs, some of which are not
easily fixed. The nastiest of these is to do with monads, which are
horribly mistreated. Since I now know the underlying issues which have
caused a problem with Hoogle 3, things like higher-kinded type classes
can be solved in a more principled manner.


So try again in 3 months, and the issue will be gone :-)

Thanks

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

Re: [Haskell-cafe] Design your modules for qualified import

[Henning Thielemann]

On Mon, 9 Jun 2008, Sebastian Sylvan wrote:


Another BIG reason: It's impossible to export a whole hierarchy qualified.
I.e it would be neat if the user could write:

import Graphics.UI.Gtk

And then have Gtk re-export sub-modules qualified, so you could write
"Button.new", "Window.new" etc. etc. As it stands you have two options:
prefix all the "new" functions with the kind of widget they create
(buttonNew, windowNew), or force the user to add a gazillion qualified
imports.


The problem would be again that no one knows, where "Window" comes from. 
Better would be


import Graphics.UI.Gtk (Window, Button, )

Don't know if this extension would be worth the trouble.

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

Re: [Haskell-cafe] Design your modules for qualified import

[Henning Thielemann]

On Mon, 9 Jun 2008, Duncan Coutts wrote:


On Mon, 2008-06-09 at 16:04 +0200, Ketil Malde wrote:


And - is there a way to make GHCi use aliased qualification?  I find
my self typing detailed taxonomies all the time there.


The ghci syntax currently is:
:m Data.Set
wouldn't it be much nicer as:
import Data.Set
then we could have the obvious:
import Data.Set as Set


This would be nice! Feature request?

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

[Haskell-cafe] External query interface to HackageDB?

[Dimitry Golubovsky]

Hi,

Is there any way to query the latest version of a particular package
stored on Hackage, that was successfully built?

I mean, not _how_ to do that (I have some ideas that I have to
download directory listings, looking for failure logs, etc.), but is
there any tool or interface already available that does similar
things?

Unfortunately, tarfiles provided on Hackage (like 00-index.tar.gz) do
not help, e. g. BerkeleyDB failed to build in all three versions, yet
its all cabal files are included in the tarball:

tar tvf 00-index.tar.gz
...
-rw-r--r-- www-data/www-data  1055 2007-04-06 13:03
./BerkeleyDB/0.1/BerkeleyDB.cabal
-rw-r--r-- www-data/www-data  1061 2007-04-06 16:59
./BerkeleyDB/0.2/BerkeleyDB.cabal
-rw-rw-r-- www-data/www-data  1236 2008-01-11 14:42
./BerkeleyDB/0.3/BerkeleyDB.cabal

I remember, in the past, HackageDB was expected to become a database
of some sort: is there any database-like backend that would accept
queries, other than just parsing Apache dir listings?

My final goal, given some master-list of package names, to be able to
retrieve latest succesfully built (not just uploaded) releases from
Hackage

Thanks.

-- 
Dimitry Golubovsky

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

Re: [Haskell-cafe] Design your modules for qualified import

[Sebastian Sylvan]

On 6/14/08, Henning Thielemann <[EMAIL PROTECTED]> wrote:
>
>
> On Mon, 9 Jun 2008, Sebastian Sylvan wrote:
>
>  Another BIG reason: It's impossible to export a whole hierarchy qualified.
>> I.e it would be neat if the user could write:
>>
>> import Graphics.UI.Gtk
>>
>> And then have Gtk re-export sub-modules qualified, so you could write
>> "Button.new", "Window.new" etc. etc. As it stands you have two options:
>> prefix all the "new" functions with the kind of widget they create
>> (buttonNew, windowNew), or force the user to add a gazillion qualified
>> imports.
>>
>
> The problem would be again that no one knows, where "Window" comes from.
> Better would be
>
I really don't see how this is a big problem. Lots of languages do
hierarchical import (e.g. .Net languages) and I don't think I've ever heard
anyone complain about this particular aspect of it. The worst case scenario
is that you need a little bit of tool support to help you sort it out. Plus,
it's not like you can't just qualify the import to make it easier to see
where it comes from if you really think it's a problem:

import qualified Graphics.UI.GTK as GTK

and then use GTK.Button.new etc.


-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Design your modules for qualified import

[Henning Thielemann]

On Sat, 14 Jun 2008, Sebastian Sylvan wrote:


On 6/14/08, Henning Thielemann <[EMAIL PROTECTED]> wrote:


The problem would be again that no one knows, where "Window" comes from.
Better would be


I really don't see how this is a big problem. Lots of languages do
hierarchical import (e.g. .Net languages) and I don't think I've ever heard
anyone complain about this particular aspect of it.


It's not a problem for you and thus you do not pay attention to these 
complaints, I suspect. Maybe the people who would complain about the 
importing style, simply don't use the mentioned languages.


The worst case scenario is that you need a little bit of tool support to 
help you sort it out. Plus, it's not like you can't just qualify the 
import to make it easier to see where it comes from if you really think 
it's a problem:


Cf.
  http://www.haskell.org/haskellwiki/Import_modules_properly

 Haskell can re-export modules, which makes tracing identifiers more 
difficult. I want to be able to read modules without using a tool.

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

Re: [Haskell-cafe] ANN: Topkata

[Christoph Bauer]

Hello Neil,

> Looks cool! Could you upload it to hackage?

Thank you. Ok, I uploaded the current version. At the moment you have
to run topkata in the topkata-0.0 directory with
./dist/build/topkata/topkata, because it has to find its texture/sound
files. Furthermore I encounter problems (i.e. segmentation faults) on Gentoo
with the openal package. But openal-soft-1.4.272 works fine.

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

[Haskell-cafe] ANN: Topkata

[Brent Yorgey]

On Sat, Jun 14, 2008 at 10:53 AM, Christoph Bauer <
[EMAIL PROTECTED]> wrote:

> Hello Neil,
>
> > Looks cool! Could you upload it to hackage?
>
> Thank you. Ok, I uploaded the current version. At the moment you have
> to run topkata in the topkata-0.0 directory with
> ./dist/build/topkata/topkata, because it has to find its texture/sound
> files.


There's a way to put something in the .cabal file about extra data files,
and have it install them in a certain location that you can then find
programmatically.  I forget the details, but I think it's pretty easy to set
up.  Maybe take a look through the Cabal documentation.  Or maybe Duncan
will jump in and explain. =)

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

Re: [Haskell-cafe] ANN: Topkata

[Neil Mitchell]

Hi

> > > Looks cool! Could you upload it to hackage?
> >
> > Thank you. Ok, I uploaded the current version. At the moment you have
> > to run topkata in the topkata-0.0 directory with
> > ./dist/build/topkata/topkata, because it has to find its texture/sound
> > files.
>
> There's a way to put something in the .cabal file about extra data files,
> and have it install them in a certain location that you can then find
> programmatically.  I forget the details, but I think it's pretty easy to set

http://neilmitchell.blogspot.com/2008/02/adding-data-files-using-cabal.html

Thanks

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

[Haskell-cafe] const is question

[odtaa48]

hello
could someone explain the following differing results 
const id 0   5 -> 5 -- ie. 'takes' the 'last' one

const (id 0) 5 -> 0 -- ie. 'takes' the 'first' one

Thanks


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

[Haskell-cafe] Lazy IO.

[Sebastiaan Visser]

Hi,

I've got a question about lazy IO in Haskell. The most well known
function to do lazy IO is the `hGetContents', which lazily reads all the
contents from a handle and returns this as a regular [Char].

The thing with hGetContents is that is puts the Handle in a semi-closed
state, no one can use the handle anymore. This behaviour is
understandable from the point of safety; it is not yet determined when
the result of hGetContents will actually be computed, using the handle
in the meantime is undesirable.

The point is, I think I really have a situation in which I want to use
the handle again `after' a call to hGetContents. I think I can best
explain this using a code example.

  readHttpMessage :: IO (Headers, Data.ByteString.Lazy.ByteString)
  readHttpMessage = do
myStream <- 
request <- hGetContents myStream
header <- parseHttpHeader request
bs <- Data.ByteString.Lazy.hGetContents myStream
return (header, body)

The Data.ByteString.Lazy.hGetContents in the example above obviously
fails because the handle is semi-closed.

So, what I am trying to do here is apply a parser (on that consumes
Char's) to the input stream until it has succeeded. After this I want to
collect the remainings of the stream in a lazy ByteString, or maybe even
something else.

I tried to open the handler again using some internal handle hackery,
but this failed (luckily). In the module GHC.IO there is a function
`lazyRead' that more or less seems to do what I want. But I'll guess
there is a good reason for not exporting it.

Does anyone know a pattern in which I can do this easily?

Thanks,

--
Sebastiaan

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

Re: [Haskell-cafe] const is question

[Jake Mcarthur]

On Jun 14, 2008, at 11:14 AM, odtaa48 wrote:


const id 0   5 -> 5 -- ie. 'takes' the 'last' one


The type of const is a -> b -> a. The first argument to const here is  
id and the second is 0, so the evaluation of const id 0 is going to  
result in id. Then we apply id to 5, yielding 5. Perhaps it would be  
more clear to write the expression is (const id 0) 5.



const (id 0) 5 -> 0 -- ie. 'takes' the 'first' one


Here the two arguments to const are (id 0) and 5. Since the effect of  
const is to toss out the second argument, this evaluates to id 0,  
which evaluates to simply 0.


Does that help?

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

Re: [Haskell-cafe] const is question

[Sebastiaan Visser]

On Jun 14, 2008, at 6:14 PM, odtaa48 wrote:

hello
could someone explain the following differing results const id 0
5 -> 5 -- ie. 'takes' the 'last' one

const (id 0) 5 -> 0 -- ie. 'takes' the 'first' one

Thanks


You can easily see what is happening by rewriting the equations step  
by step. Remember that the const function is (\x y -> x) and the id  
function is (\x -> x).


Example 1:

   const id 0 5
== (const id 0) 5
== id 5
== 5

Example 2:

   const (id 0) 5
== const 0 5
== 0

So, in both cases const takes the first.

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

Re: [Haskell-cafe] Lazy IO.

[Felipe Lessa]

(Sorry, Sebastiaan, I hit send accidentally)

On Sat, Jun 14, 2008 at 1:18 PM, Sebastiaan Visser <[EMAIL PROTECTED]> wrote:
>  readHttpMessage :: IO (Headers, Data.ByteString.Lazy.ByteString)
>  readHttpMessage = do
>myStream <- 
>request <- hGetContents myStream
>header <- parseHttpHeader request
>bs <- Data.ByteString.Lazy.hGetContents myStream
>return (header, body)

Why not

readHttpMessage = do
  myStream <- 
  data <- Data.ByteString.Lazy.hGetContents myStream
  (header, rest) <- parseHttpHeader data
  return (header, rest)

i.e. make parseHttpHeader return the rest of the string it didn't parse?

In fact, may I ask why parseHttpHeader is not a pure function?

HTH,

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

Re: [Haskell-cafe] Lazy IO.

[Isaac Dupree]

Sebastiaan Visser wrote:

Hi,

I've got a question about lazy IO in Haskell. The most well known
function to do lazy IO is the `hGetContents', which lazily reads all the
contents from a handle and returns this as a regular [Char].

The thing with hGetContents is that is puts the Handle in a semi-closed
state, no one can use the handle anymore. This behaviour is
understandable from the point of safety; it is not yet determined when
the result of hGetContents will actually be computed, using the handle
in the meantime is undesirable.

The point is, I think I really have a situation in which I want to use
the handle again `after' a call to hGetContents. I think I can best
explain this using a code example.

  readHttpMessage :: IO (Headers, Data.ByteString.Lazy.ByteString)
  readHttpMessage = do
myStream <- 
request <- hGetContents myStream
header <- parseHttpHeader request
bs <- Data.ByteString.Lazy.hGetContents myStream
return (header, body)


that's impure because parseHttpHeader doesn't return anything telling 
you how much of the stream it's looked at.  Maybe it looked ahead more 
than it needed to, thus deleting part of the body.  I was going to 
suggest, if you can't change parseHttpHeader to use ByteStrings,


> bs <- Data.ByteString.Lazy.hGetContents myStream
> header <- parseHttpHeader (Data.ByteString.Lazy.unpack bs)

but you still have to get parseHttpHeader (or perhaps if it has similar 
friends) to tell you how much of the string it consumed!  I don't know 
what parsing functions you have available to work with, so I can't tell 
you whether it's possible.


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

Re: [Haskell-cafe] Lazy IO.

[Sebastiaan Visser]

On Jun 14, 2008, at 6:45 PM, Felipe Lessa wrote:

(Sorry, Sebastiaan, I hit send accidentally)

On Sat, Jun 14, 2008 at 1:18 PM, Sebastiaan Visser  
<[EMAIL PROTECTED]> wrote:

 readHttpMessage :: IO (Headers, Data.ByteString.Lazy.ByteString)
 readHttpMessage = do
   myStream <- 
   request <- hGetContents myStream
   header <- parseHttpHeader request
   bs <- Data.ByteString.Lazy.hGetContents myStream
   return (header, body)


Why not

readHttpMessage = do
  myStream <- 
  data <- Data.ByteString.Lazy.hGetContents myStream
  (header, rest) <- parseHttpHeader data
  return (header, rest)

i.e. make parseHttpHeader return the rest of the string it didn't  
parse?


Doesn't this imply that the parseHttpHeader must work on ByteStrings  
instead of regular Strings? Maybe this works for HTTP headers, but  
sometimes ByteStrings are not appropriate. Especially when you are  
not using the regular `System.IO.hGetContents' but the  
`System.IO.UTF8.hGetContents'.



In fact, may I ask why parseHttpHeader is not a pure function?


This is not a real-life example. It might as well be a pure function.


HTH,

-- Felipe.


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

Re: [Haskell-cafe] Lazy IO.

[Sebastiaan Visser]

On Jun 14, 2008, at 6:49 PM, Isaac Dupree wrote:


Sebastiaan Visser wrote:

Hi,
I've got a question about lazy IO in Haskell. The most well known
function to do lazy IO is the `hGetContents', which lazily reads  
all the

contents from a handle and returns this as a regular [Char].
The thing with hGetContents is that is puts the Handle in a semi- 
closed

state, no one can use the handle anymore. This behaviour is
understandable from the point of safety; it is not yet determined  
when
the result of hGetContents will actually be computed, using the  
handle

in the meantime is undesirable.
The point is, I think I really have a situation in which I want to  
use

the handle again `after' a call to hGetContents. I think I can best
explain this using a code example.
  readHttpMessage :: IO (Headers, Data.ByteString.Lazy.ByteString)
  readHttpMessage = do
myStream <- 
request <- hGetContents myStream
header <- parseHttpHeader request
bs <- Data.ByteString.Lazy.hGetContents myStream
return (header, body)


that's impure because parseHttpHeader doesn't return anything  
telling you how much of the stream it's looked at.  Maybe it looked  
ahead more than it needed to, thus deleting part of the body.  I  
was going to suggest, if you can't change parseHttpHeader to use  
ByteStrings,


> bs <- Data.ByteString.Lazy.hGetContents myStream
> header <- parseHttpHeader (Data.ByteString.Lazy.unpack bs)

but you still have to get parseHttpHeader (or perhaps if it has  
similar friends) to tell you how much of the string it consumed!  I  
don't know what parsing functions you have available to work with,  
so I can't tell you whether it's possible.


It is a regular Parsec parser and I am pretty sure it does not  
consume anything other than the header itself. Maybe I could rewrite  
my parser to work on Word8's instead of Char's, I don't think HTTP  
even allows Unicode characters within HTTP headers.


Thanks. I think I'll try this.

But I'm still curious about how to lazily parse messages with  
arbitrary size Unicode headers and plain (possibly) binary bodies.



-Isaac


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

Re: [Haskell-cafe] Lazy IO.

[Felipe Lessa]

On Sat, Jun 14, 2008 at 1:50 PM, Sebastiaan Visser <[EMAIL PROTECTED]> wrote:
> Doesn't this imply that the parseHttpHeader must work on ByteStrings instead
> of regular Strings?

I made the change because it's easier and faster to go from ByteString
to String than the converse.

> Maybe this works for HTTP headers, but sometimes
> ByteStrings are not appropriate. Especially when you are not using the
> regular `System.IO.hGetContents' but the `System.IO.UTF8.hGetContents'.

You may use the package encoding instead, take a look at [1]. It will
decode a lazy ByteString into a String. In your HTTP parsing example,
you could break the ByteString on "\r\n\r\n" and then decodeLazy only
the first part, while returning the second without modifying it.

[1] 
http://hackage.haskell.org/packages/archive/encoding/0.4.1/doc/html/Data-Encoding.html#v%3AdecodeLazy

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

Re: [Haskell-cafe] Lazy IO.

[Brandon S. Allbery KF8NH]

On 2008 Jun 14, at 12:59, Sebastiaan Visser wrote:

But I'm still curious about how to lazily parse messages with  
arbitrary size Unicode headers and plain (possibly) binary bodies.



Sounds like Data.Binary (see hackage) to me.

--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH


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

Re: [Haskell-cafe] Lazy IO.

[Sebastiaan Visser]

On Jun 14, 2008, at 7:16 PM, Felipe Lessa wrote:

On Sat, Jun 14, 2008 at 1:50 PM, Sebastiaan Visser  
<[EMAIL PROTECTED]> wrote:
Doesn't this imply that the parseHttpHeader must work on  
ByteStrings instead

of regular Strings?


I made the change because it's easier and faster to go from ByteString
to String than the converse.


Maybe this works for HTTP headers, but sometimes
ByteStrings are not appropriate. Especially when you are not using  
the
regular `System.IO.hGetContents' but the  
`System.IO.UTF8.hGetContents'.


You may use the package encoding instead, take a look at [1]. It will
decode a lazy ByteString into a String. In your HTTP parsing example,
you could break the ByteString on "\r\n\r\n" and then decodeLazy only
the first part, while returning the second without modifying it.


Sounds interesting. This could indeed solve (a part of) my problem.

The thing is, when decoding the header - in my web server  
architecture - it is not yet clear what should be done be the body.  
Some `handlers' may want to have it as a String, UTF8 String,  
ByteString or may not even need it at all.


[1] http://hackage.haskell.org/packages/archive/encoding/0.4.1/doc/ 
html/Data-Encoding.html#v%3AdecodeLazy



Because HTTP headers are line based and the parser does not need any  
look ahead - the first "\r\n\r\n" is the header delimiter - it might  
be possible to use the hGetLine for the headers. After this I am  
still `free' to decide what to do for the body:  
System.IO.hGetContents, System.IO.UTF8.hGetContents,  
Data.ByteString.Lazy.hGetContents, hClose, etc...



-- Felipe.


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

Re: [Haskell-cafe] Design your modules for qualified import

[Sebastian Sylvan]

On 6/14/08, Henning Thielemann <[EMAIL PROTECTED]> wrote:
>
>
> On Sat, 14 Jun 2008, Sebastian Sylvan wrote:
>
>  On 6/14/08, Henning Thielemann <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> The problem would be again that no one knows, where "Window" comes from.
>>> Better would be
>>>
>>>  I really don't see how this is a big problem. Lots of languages do
>> hierarchical import (e.g. .Net languages) and I don't think I've ever
>> heard
>> anyone complain about this particular aspect of it.
>>
>
> It's not a problem for you and thus you do not pay attention to these
> complaints, I suspect. Maybe the people who would complain about the
> importing style, simply don't use the mentioned languages.
>
>> The worst case scenario is that you need a little bit of tool support to
>> help you sort it out. Plus, it's not like you can't just qualify the import
>> to make it easier to see where it comes from if you really think it's a
>> problem:
>>
>
> Cf.
>  http://www.haskell.org/haskellwiki/Import_modules_properly
>
>  Haskell can re-export modules, which makes tracing identifiers more
> difficult. I want to be able to read modules without using a tool.
>

I'm not sure I understand you point. You're so opposed to the *option* of
allowing hierarchical exports (even though you can still import it qualified
if you personally like having to specify at each callsite exactly where some
identifier is coming from), that you'd rather any library making use of a
module hierarchy is forced to either make the user add dozens of boilerplate
import statements (with "qualified" and "as") or the more common strategy of
prefixing each function call with the module name (buttonNew)? To me a
module system that requires the latter in practice is horribly broken, and
I'm suggesting a low-impact way of fixing it. It may not be the best system
available, but it's a tiny extension of the current.

I really don't see why adding this option hurts you, when it clearly helps
enable doing what this thread advocates (use qualified modules to
distinguish between functions of the same name, rather than adding a bunch
of prefixes/suffixes to the functions).

-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Design your modules for qualified import

[Henning Thielemann]

On Sat, 14 Jun 2008, Sebastian Sylvan wrote:


On 6/14/08, Henning Thielemann <[EMAIL PROTECTED]> wrote:



On Sat, 14 Jun 2008, Sebastian Sylvan wrote:

 On 6/14/08, Henning Thielemann <[EMAIL PROTECTED]> wrote:




The problem would be again that no one knows, where "Window" comes from.
Better would be

 I really don't see how this is a big problem. Lots of languages do

hierarchical import (e.g. .Net languages) and I don't think I've ever
heard
anyone complain about this particular aspect of it.



It's not a problem for you and thus you do not pay attention to these
complaints, I suspect. Maybe the people who would complain about the
importing style, simply don't use the mentioned languages.


The worst case scenario is that you need a little bit of tool support to
help you sort it out. Plus, it's not like you can't just qualify the import
to make it easier to see where it comes from if you really think it's a
problem:



Cf.
 http://www.haskell.org/haskellwiki/Import_modules_properly

 Haskell can re-export modules, which makes tracing identifiers more
difficult. I want to be able to read modules without using a tool.



I'm not sure I understand you point. You're so opposed to the *option* of
allowing hierarchical exports (even though you can still import it qualified
if you personally like having to specify at each callsite exactly where some
identifier is coming from),


I was concerned with the _import_ part of your proposal. (I haven't 
thought about the export part so far.)


that you'd rather any library making use of a module hierarchy is forced 
to either make the user add dozens of boilerplate import statements 
(with "qualified" and "as") or the more common strategy of prefixing 
each function call with the module name (buttonNew)? To me a module 
system that requires the latter in practice is horribly broken, and I'm 
suggesting a low-impact way of fixing it. It may not be the best system 
available, but it's a tiny extension of the current.


I really don't see why adding this option hurts you, when it clearly helps
enable doing what this thread advocates (use qualified modules to
distinguish between functions of the same name, rather than adding a bunch
of prefixes/suffixes to the functions).


Button.new is my favorite, because with current import variants I can 
easily lookup, what Button and Button.new refer to. I understand your 
proposal in that way that


import Graphics.UI.Gtk

brings module qualifications Window and Button into scope although they 
are not explicitly mentioned. Thus I could no longer find out easily what 
Butten.new means.

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

[Haskell-cafe] ANN: Printf-TH

[Marc Weber]

Igloo (Ian Lynagh) allowed me kindly taking over maintainance on his
printf library using template haskell written in 2003. I've updated it
so that it compiles with ghc-6.8.2.
You can get it from hackage:
 http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Printf-TH

usage looks like this:

{-# OPTIONS_GHC -XTemplateHaskell #-}
...
import Language.Haskell.TH.Syntax
import Text.Printf.TH (printf)

...
putStrLn $ $(printf "Foo %H bar") (Just 5)
putStrLn $ $(printf "%6d") 1
putStrLn $ $(printf "%6d") (-1)

Short Explanation:
$(printf "%d") will be replaced by a auto generated function taking an int etc

Benefit:
Wrong arg types or wrong printf arg count will result in compile time
errors.

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

Re: [Haskell-cafe] Design your modules for qualified import

[Sebastian Sylvan]

On 6/14/08, Henning Thielemann <[EMAIL PROTECTED]> wrote:
>
>
> On Sat, 14 Jun 2008, Sebastian Sylvan wrote:
>
>  On 6/14/08, Henning Thielemann <[EMAIL PROTECTED]> wrote:
>>
>>>
>>>
>>> On Sat, 14 Jun 2008, Sebastian Sylvan wrote:
>>>
>>>  On 6/14/08, Henning Thielemann <[EMAIL PROTECTED]> wrote:
>>>


> The problem would be again that no one knows, where "Window" comes
> from.
> Better would be
>
>  I really don't see how this is a big problem. Lots of languages do
>
 hierarchical import (e.g. .Net languages) and I don't think I've ever
 heard
 anyone complain about this particular aspect of it.


>>> It's not a problem for you and thus you do not pay attention to these
>>> complaints, I suspect. Maybe the people who would complain about the
>>> importing style, simply don't use the mentioned languages.
>>>
>>>  The worst case scenario is that you need a little bit of tool support to
 help you sort it out. Plus, it's not like you can't just qualify the
 import
 to make it easier to see where it comes from if you really think it's a
 problem:


>>> Cf.
>>>  http://www.haskell.org/haskellwiki/Import_modules_properly
>>>
>>>  Haskell can re-export modules, which makes tracing identifiers more
>>> difficult. I want to be able to read modules without using a tool.
>>>
>>>
>> I'm not sure I understand you point. You're so opposed to the *option* of
>> allowing hierarchical exports (even though you can still import it
>> qualified
>> if you personally like having to specify at each callsite exactly where
>> some
>> identifier is coming from),
>>
>
> I was concerned with the _import_ part of your proposal. (I haven't thought
> about the export part so far.)
>
>  that you'd rather any library making use of a module hierarchy is forced
>> to either make the user add dozens of boilerplate import statements (with
>> "qualified" and "as") or the more common strategy of prefixing each function
>> call with the module name (buttonNew)? To me a module system that requires
>> the latter in practice is horribly broken, and I'm suggesting a low-impact
>> way of fixing it. It may not be the best system available, but it's a tiny
>> extension of the current.
>>
>> I really don't see why adding this option hurts you, when it clearly helps
>> enable doing what this thread advocates (use qualified modules to
>> distinguish between functions of the same name, rather than adding a bunch
>> of prefixes/suffixes to the functions).
>>
>
> Button.new is my favorite, because with current import variants I can
> easily lookup, what Button and Button.new refer to. I understand your
> proposal in that way that
>
> import Graphics.UI.Gtk
>
> brings module qualifications Window and Button into scope although they are
> not explicitly mentioned. Thus I could no longer find out easily what
> Butten.new means.
>
I don't see why this is so bad when it's exactly what we have for other
identifiers? E.g. if you import Control.Monad you get mapM, but you can't
really say for sure where this identifier comes from, which is no better
than not knowing where "Button.new" comes from. In both cases you have the
option to qualify the module import so you have to say "Monad.mapM" or
"GTK.Button.new" which makes it more apparent.

I suppose you would make the "hiding" clause and the "import list" thing
work with modules too for consistency, so if you really wanted to you could
list the modules/identifiers that you bring in.

Are you saying that you prefer the situation where to use GTK the user would
have to explicitly import every single sub-module in the hierarchy ("import
qualified Graphics.UI.GTK.X as X" where X = {Button,Window, ... etc})? I
don't think that's very nice at all, and I certainly don't like having to
add the module name to the functions... I think lots of libraries are like
that, and we need some mechanism of importing lots of related modules
together so that they come in qualified, without forcing the user to write a
gazillion lines of boilerplate import statements..

I think that if GTK did use this system (rather than append the module name
to the function and export them "flatly") a lot of people would resort to
ugly hacks like putting the import statements in a file somewhere and using
the C preprocessor to include it, yuck! (OTOH this may be just what's
required to convince everyone that we need to improve the module system)...

-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Documenting the impossible

[Andrew Coppin]

I have a small idea. I'm curios if anybody else thinks it's a good idea...

How about a {-# IMPOSSIBLE #-} pragma that documents the fact that a 
particular point in the program *should* be unreachable?


For example, you look up a key in a Map. You know the key is there, 
because you just put it there yourself two seconds ago. But, 
theoretically, lookup returns a Maybe x so - theoretically - it's 
possible it might return Nothing. No matter what you do, GHC will insert 
code to check whether we have Just x or Nothing, and in the Nothing case 
throw an exception.


Obviously there is no way in hell this code path can ever be executed. 
At least, assuming your code isn't broken... This is where the pragma 
comes in. The idea is that you write something like


 case lookup k m of
   Just v -> process v
   Nothing -> {-# IMPOSSIBLE "lookup in step 3" #-}

When compiled without optimisations, the pragma just causes an exception 
to be thrown, rather like "error" does. When compiled with 
optimisations, the whole case alternative is removed, and no code is 
generated for it. (And if the impossible somehow happens... behaviour is 
undefined.) So you test your program with your code compiled 
unoptimised, and when you're "sure" the impossible can't happen, you 
tell the compiler to remove the check for it. (Actually, it would 
possibly be a good idea to have a switch to turn this on and off 
seperately if needed...)


Does anybody think this is a useful idea? If so I'll add a feature 
request ticket to the GHC Trac. But I want to see if folks like the idea 
first...


(I was thinking the message in the pragma would be what gets displayed 
on screen, along with some auto-generated location info. Just a module 
name and line number ought to be sufficient...)


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

Re: [Haskell-cafe] Documenting the impossible

[Derek Elkins]

On Sat, 2008-06-14 at 19:58 +0100, Andrew Coppin wrote:
> I have a small idea. I'm curios if anybody else thinks it's a good idea...
> 
> How about a {-# IMPOSSIBLE #-} pragma that documents the fact that a 
> particular point in the program *should* be unreachable?
> 
> For example, you look up a key in a Map. You know the key is there, 
> because you just put it there yourself two seconds ago. But, 
> theoretically, lookup returns a Maybe x so - theoretically - it's 
> possible it might return Nothing. No matter what you do, GHC will insert 
> code to check whether we have Just x or Nothing, and in the Nothing case 
> throw an exception.
> 
> Obviously there is no way in hell this code path can ever be executed. 
> At least, assuming your code isn't broken... This is where the pragma 
> comes in. The idea is that you write something like
> 
>   case lookup k m of
> Just v -> process v
> Nothing -> {-# IMPOSSIBLE "lookup in step 3" #-}
> 
> When compiled without optimisations, the pragma just causes an exception 
> to be thrown, rather like "error" does. When compiled with 
> optimisations, the whole case alternative is removed, and no code is 
> generated for it. (And if the impossible somehow happens... behaviour is 
> undefined.) So you test your program with your code compiled 
> unoptimised, and when you're "sure" the impossible can't happen, you 
> tell the compiler to remove the check for it. (Actually, it would 
> possibly be a good idea to have a switch to turn this on and off 
> seperately if needed...)
> 
> Does anybody think this is a useful idea? If so I'll add a feature 
> request ticket to the GHC Trac. But I want to see if folks like the idea 
> first...
> 
I think it's a horrible idea.

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

Re: [Haskell-cafe] Documenting the impossible

[Henning Thielemann]

On Sat, 14 Jun 2008, Andrew Coppin wrote:

How about a {-# IMPOSSIBLE #-} pragma that documents the fact that a 
particular point in the program *should* be unreachable?

...
When compiled without optimisations, the pragma just causes an exception to 
be thrown, rather like "error" does. When compiled with optimisations, the 
whole case alternative is removed, and no code is generated for it. (And if 
the impossible somehow happens... behaviour is undefined.) So you test your 
program with your code compiled unoptimised, and when you're "sure" the 
impossible can't happen, you tell the compiler to remove the check for it. 
(Actually, it would possibly be a good idea to have a switch to turn this on 
and off seperately if needed...)


I think it is another instance of mixing up errors and exceptions (you 
know the haskellwiki pages ...)


Since an 'error' marks a programming error (which should never occur) it 
would not hurt the program if all 'error's are replaced by 'undefined', an 
illegal memory access or any other misbehaviour. So 'error' is exactly 
what you propose as IMPOSSIBLE pragma. A compiler option for replacing all 
'error's by nops would do want you want.

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

Re: [Haskell-cafe] Documenting the impossible

[Thomas M. DuBuisson]

I think when Andy made HPC he added a way to mark code unreachable so it
wouldn't "harm" your test coverage report.


On Sat, 2008-06-14 at 19:58 +0100, Andrew Coppin wrote:
> I have a small idea. I'm curios if anybody else thinks it's a good idea...
> 
> How about a {-# IMPOSSIBLE #-} pragma that documents the fact that a 
> particular point in the program *should* be unreachable?
> 
> For example, you look up a key in a Map. You know the key is there, 
> because you just put it there yourself two seconds ago. But, 
> theoretically, lookup returns a Maybe x so - theoretically - it's 
> possible it might return Nothing. No matter what you do, GHC will insert 
> code to check whether we have Just x or Nothing, and in the Nothing case 
> throw an exception.
> 
> Obviously there is no way in hell this code path can ever be executed. 
> At least, assuming your code isn't broken... This is where the pragma 
> comes in. The idea is that you write something like
> 
>   case lookup k m of
> Just v -> process v
> Nothing -> {-# IMPOSSIBLE "lookup in step 3" #-}
> 
> When compiled without optimisations, the pragma just causes an exception 
> to be thrown, rather like "error" does. When compiled with 
> optimisations, the whole case alternative is removed, and no code is 
> generated for it. (And if the impossible somehow happens... behaviour is 
> undefined.) So you test your program with your code compiled 
> unoptimised, and when you're "sure" the impossible can't happen, you 
> tell the compiler to remove the check for it. (Actually, it would 
> possibly be a good idea to have a switch to turn this on and off 
> seperately if needed...)
> 
> Does anybody think this is a useful idea? If so I'll add a feature 
> request ticket to the GHC Trac. But I want to see if folks like the idea 
> first...
> 
> (I was thinking the message in the pragma would be what gets displayed 
> on screen, along with some auto-generated location info. Just a module 
> name and line number ought to be sufficient...)
> 
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe


signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Documenting the impossible

[Don Stewart]

andrewcoppin:
> I have a small idea. I'm curios if anybody else thinks it's a good idea...
> 
> How about a {-# IMPOSSIBLE #-} pragma that documents the fact that a 
> particular point in the program *should* be unreachable?
> 
> For example, you look up a key in a Map. You know the key is there, 
> because you just put it there yourself two seconds ago. But, 
> theoretically, lookup returns a Maybe x so - theoretically - it's 
> possible it might return Nothing. No matter what you do, GHC will insert 
> code to check whether we have Just x or Nothing, and in the Nothing case 
> throw an exception.
> 
> Obviously there is no way in hell this code path can ever be executed. 
> At least, assuming your code isn't broken... This is where the pragma 
> comes in. The idea is that you write something like
> 
>  case lookup k m of
>Just v -> process v
>Nothing -> {-# IMPOSSIBLE "lookup in step 3" #-}

You could try using an 'assert' , which has the property of being
compiled out at higher optimisation levels. And you can use 'error' or
'undefined' for undefined behaviour.

http://www.haskell.org/ghc/docs/latest/html/users_guide/assertions.html

Not very Haskelly though.

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

Re: [Haskell-cafe] ANN: Topkata

[Don Stewart]

tom.davie:
> On 14 Jun 2008, at 12:45, Christoph Bauer wrote:
> 
> >Hi All,
> >
> >Topkata is a simple OpenGL Game written in Haskell. It's not very
> >advanced. Goal so far is to guide a ball trough an labyrinth to the
> >opposite corner.  The web page shows an screenshot. It's only tested
> >under Linux.
> >
> >http://home.arcor.de/chr_bauer/topkata.html
> >
> >Feedback&Patches are welcome. BTW, I had a lot of support in #haskell!
> 
> Looks awesome, and I completely agree with Niel -- hackage it up!
> 
> In the mean time -- who knows enough to make ghc target ARM, and get  
> this to link against the iPhone libraries?  This would be quite a coup  
> if it could be made to run there!

I'd be interested. We should start a wiki page for Haskell on the
iphone..

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

Re: [Haskell-cafe] Documenting the impossible

[Neil Mitchell]

Hi

>  How about a {-# IMPOSSIBLE #-} pragma that documents the fact that a
> particular point in the program *should* be unreachable?

Why not make it a function taking a string and returning a value of
any type. Then we can keep our language and not break various
parsing/type checking properties and rules on pragmas. We can even
define it:

impossible = error

Now you can use tools like Catch and Reach to ensure it is impossible.

I think it would be nice to distinguish between:

* error - inserted by the compiler
* impossible - the programmer knows this can't occur
* abort - deliberate aborting because the user made some mistake.

The safe library provides abort already.

Thanks

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

Re: [Haskell-cafe] Documenting the impossible

[Marc Weber]

>  Does anybody think this is a useful idea? If so I'll add a feature request 
>  ticket to the GHC Trac. But I want to see if folks like the idea first...

Mmmh.. dont' know. Even Java folks don't allow this kind of creeping
bug and I guess they know why. You never want undefined behaviour at
least when using haskell. Because if that error occurs it's hard to
debug, no I don't like that at all.

May I look at your proposal from another view?
Am I right that you ask for not having to run the "fromJust" code to
save some cpu cycles?

Very simple example : 
let list = [ (a,a*a) | a <- [1..10] ]
in ..

Now getting the square of 4 (standard)
fromJust $ lookup 4 list

Removing the fromJust code thingy leads to:

lookupGoodFaith key ((x,v):xs) | key == x = v
   | otherwise = lookupGoodFaith xs
lookupGoodFaith _ (_,v) = v

Where is the difference? I don't even compare the key of the last list
item, because it must match. So you safe some additional cpu cycles..
The same can be implemented for Data.Map etc..

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

Re: [Haskell-cafe] Documenting the impossible

[Henning Thielemann]

On Sat, 14 Jun 2008, Neil Mitchell wrote:


Hi


 How about a {-# IMPOSSIBLE #-} pragma that documents the fact that a
particular point in the program *should* be unreachable?


Why not make it a function taking a string and returning a value of
any type. Then we can keep our language and not break various
parsing/type checking properties and rules on pragmas. We can even
define it:

impossible = error

Now you can use tools like Catch and Reach to ensure it is impossible.

I think it would be nice to distinguish between:

* error - inserted by the compiler


Example?


* impossible - the programmer knows this can't occur


This is an error. However the programmer adds a message because he might 
be wrong.



* abort - deliberate aborting because the user made some mistake.


This is an exception. The signature of a function must reflect this by a 
Maybe, Either type etc.



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

[Haskell-cafe] Template Haskell sugar / spliceing in automatically ?

[Marc Weber]

Hi, I've been thinking about template haskell sugar lately.

Some cool libraries are there such as metaHDBC or the template haskell
printf library.

However they all have one thing in common:

$(printf "...") a b c

$(runStmt "INSERT INTO ( ) VALUES ( ?, ?, ? )" ) 2 3 4


Would it make sense to automatically splice those functions?

{-# auto-splice: runStmt, printf #-}

So that you can just use
printf "..." a b c
and
runStmt "INSERT INTO ( ) VALUES ( ?, ?, ? )" 2 3 4
without $() ?

Would this be convinient?

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

Re: [Haskell-cafe] Documenting the impossible

[Neil Mitchell]

Hi

> > * error - inserted by the compiler
>
>  Example?

Pattern-match errors.

> > * abort - deliberate aborting because the user made some mistake.
>
>  This is an exception. The signature of a function must reflect this by a
> Maybe, Either type etc.

Disagree. I mean more like:

when (Delete `elem` flags && Keep `elem` flags) $
   abort "User cannot pick both keep and delete on the command line"

Think "die" in Perl world.

Thanks

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

Re: [Haskell-cafe] Documenting the impossible

[Henning Thielemann]

On Sat, 14 Jun 2008, Neil Mitchell wrote:


Hi


* error - inserted by the compiler


 Example?


Pattern-match errors.


Calling a function with patterns it cannot process is a programming error.


* abort - deliberate aborting because the user made some mistake.


 This is an exception. The signature of a function must reflect this by a
Maybe, Either type etc.


Disagree. I mean more like:

when (Delete `elem` flags && Keep `elem` flags) $
  abort "User cannot pick both keep and delete on the command line"

Think "die" in Perl world.


I wouldn't use such a function, because it does not scale. E.g. I cannot 
code a loop which lets the user enter flags until they match the 
conditions. Thus instead of 'abort' I would throw an exception - which is 
equivalent to the use of an exceptional value like Nothing or Left in 
Haskell (maybe wrapped in ErrorT).

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

[Haskell-cafe] Re: Documenting the impossible

[Peter Hercek]

Andrew Coppin wrote:
<-- cut -->
When compiled without optimisations, the pragma just causes an exception 
to be thrown, rather like "error" does. When compiled with 
optimisations, the whole case alternative is removed, and no code is 
generated for it. (And if the impossible somehow happens... behaviour is 
undefined.)


So if the compiler optimizes otherwise well you save how much? Something like:
 * one load from cache (since the next is the pointer which will be needed
   anyway later and moreover it was created just few insturctions before);
   almost always should be in L1; so lets say 2 or 3 ticks; moreover this
   applies only when you do not tag pointers (which can be done for Maybe)
 * run test instruction on it; 1 tick
 * conditional jump; should be doable so that it is predicted correctly by
   default - so you get 1 tick here probably too

So you want to save somewhere about 2 to 5 ticks (which with a bit of luck
 can be shared with other instructions) but you get unsafe execution.
 Does not sound right to me. There should be other optimizations which can
 be done and which save more.
If it is ever done I hope it will be possible to switch it off. Or the
 compiler must prove that what I think is impossible is really impossible
 and then it can do it :-D

Peter.

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

Re: [Haskell-cafe] Template Haskell sugar / spliceing in automatically ?

[Derek Elkins]

On Sat, 2008-06-14 at 23:06 +0200, Marc Weber wrote:
> Hi, I've been thinking about template haskell sugar lately.
> 
> Some cool libraries are there such as metaHDBC or the template haskell
> printf library.
> 
> However they all have one thing in common:
> 
> $(printf "...") a b c
> 
> $(runStmt "INSERT INTO ( ) VALUES ( ?, ?, ? )" ) 2 3 4
> 
> 
> Would it make sense to automatically splice those functions?
> 
> {-# auto-splice: runStmt, printf #-}
> 
> So that you can just use
> printf "..." a b c
> and
> runStmt "INSERT INTO ( ) VALUES ( ?, ?, ? )" 2 3 4
> without $() ?
> 
> Would this be convinient?

I've been iffy about this since TH was first created.  It would
certainly be more convenient, but it starts running into some unpleasant
issues.  Admittedly, most of these issues are issues of expectations,
but still.

One example from the CL/Scheme world, is that these macros wouldn't be
proper functions, so e.g. 'map printf' wouldn't work or wouldn't mean
the same thing, 'let formatString = "%s" in printf formatString'
wouldn't work or wouldn't mean the same thing (thus being a violation of
referential transparency, at least at a superficial level).

Let's say we have a function 'mydo' that turns an applicative expression
into one using monadic style.  Then something like
foo = runState (mydo (inc + inc)) 0
brings back some of the issues of programming in an impure language.

Currently, I'm still leaning toward the more explicit syntax.

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

Re: [Haskell-cafe] Design your modules for qualified import

[Isaac Dupree]

Sebastian Sylvan wrote:

On 6/14/08, Henning Thielemann <[EMAIL PROTECTED]> wrote:


On Sat, 14 Jun 2008, Sebastian Sylvan wrote:

 On 6/14/08, Henning Thielemann <[EMAIL PROTECTED]> wrote:


On Sat, 14 Jun 2008, Sebastian Sylvan wrote:

 On 6/14/08, Henning Thielemann <[EMAIL PROTECTED]> wrote:




The problem would be again that no one knows, where "Window" comes
from.
Better would be

 I really don't see how this is a big problem. Lots of languages do


hierarchical import (e.g. .Net languages) and I don't think I've ever
heard
anyone complain about this particular aspect of it.



It's not a problem for you and thus you do not pay attention to these
complaints, I suspect. Maybe the people who would complain about the
importing style, simply don't use the mentioned languages.

 The worst case scenario is that you need a little bit of tool support to

help you sort it out. Plus, it's not like you can't just qualify the
import
to make it easier to see where it comes from if you really think it's a
problem:



Cf.
 http://www.haskell.org/haskellwiki/Import_modules_properly

 Haskell can re-export modules, which makes tracing identifiers more
difficult. I want to be able to read modules without using a tool.



I'm not sure I understand you point. You're so opposed to the *option* of
allowing hierarchical exports (even though you can still import it
qualified
if you personally like having to specify at each callsite exactly where
some
identifier is coming from),


I was concerned with the _import_ part of your proposal. (I haven't thought
about the export part so far.)

 that you'd rather any library making use of a module hierarchy is forced

to either make the user add dozens of boilerplate import statements (with
"qualified" and "as") or the more common strategy of prefixing each function
call with the module name (buttonNew)? To me a module system that requires
the latter in practice is horribly broken, and I'm suggesting a low-impact
way of fixing it. It may not be the best system available, but it's a tiny
extension of the current.

I really don't see why adding this option hurts you, when it clearly helps
enable doing what this thread advocates (use qualified modules to
distinguish between functions of the same name, rather than adding a bunch
of prefixes/suffixes to the functions).


Button.new is my favorite, because with current import variants I can
easily lookup, what Button and Button.new refer to. I understand your
proposal in that way that

import Graphics.UI.Gtk

brings module qualifications Window and Button into scope although they are
not explicitly mentioned. Thus I could no longer find out easily what
Butten.new means.


I don't see why this is so bad when it's exactly what we have for other
identifiers? E.g. if you import Control.Monad you get mapM, but you can't
really say for sure where this identifier comes from, which is no better
than not knowing where "Button.new" comes from. In both cases you have the
option to qualify the module import so you have to say "Monad.mapM" or
"GTK.Button.new" which makes it more apparent.

I suppose you would make the "hiding" clause and the "import list" thing
work with modules too for consistency, so if you really wanted to you could
list the modules/identifiers that you bring in.


yeah, we could come up with a syntax. one that gives privileged meaning 
to hierarchy.  If used according to "design your modules for qualified 
import", it would still allow fairly easy use and looking up function uses.


import Graphics.UI.GTK (import qualified Button, import qualified Window)

then you get Button.f (because Graphics.UI.GTK wasn't imported 
qualified), Graphics.UI.GTK.Button.f, (not f or Graphics.UI.GTK.f 
because of qualified Button)  ... they're normal import statements 
inside.  What it saves is the duplication of Graphics.UI.GTK and 
"Button as Button".  Not sure I like how long "import qualified" is, 
repeated there, but it seemed much less confusing than anything shorter.


import Data (import qualified Map, Map.Map)
or
import Data (import qualified Map, import Map(Map))
or a shortcut for that common pattern of importing a few things unqualified
import Data (import qualified Map and (Map))
aka. import qualified Data.Map as Map and (Map)
aka. import qualified Data.Map as Map (empty,singleton,...) and (Map)
or perhaps "unqualifying" rather than "and"

personally I would like it if we could also import (f as g) if we wanted 
to rename an "f" we were importing, to "g" in the module and re-exports, 
without having to be concerned about (for lowercase) monomorphism 
restriction, (for types) whether a synonym will work properly everywhere 
(not without extensions!), (for constructor, record fields, and classes) 
simple *impossibility*.  That wish is only related in that it's a 
related generalization, though.


hmm.

-Isaac


Are you saying that you prefer the situation where to use GTK the user would
have to explicitly import every single sub-mod

Re: [Haskell-cafe] Documenting the impossible

[Isaac Dupree]

Neil Mitchell wrote:

* abort - deliberate aborting because the user made some mistake.

 This is an exception. The signature of a function must reflect this by a
Maybe, Either type etc.


Disagree. I mean more like:

when (Delete `elem` flags && Keep `elem` flags) $
   abort "User cannot pick both keep and delete on the command line"

Think "die" in Perl world.


in that case should use abort :: String -> IO a, not abort :: String -> 
a.  "abort" as "pure function" is just for messy scripting convenience 
a-la Perl.  (Which is not to say that's never useful, of course -- I 
would just try my hardest to avoid it in my code, probably.)


On the other hand, Control.Exception.throw, if it's ever useful, 
obviously isn't meant to indicate a programmer error, but to throw an 
exception (that will probably be caught somewhere in the program's IO). 
 So there's a reason for _|_ besides programmer error (well, there's 
also user-driven nontermination such as when an interpreter is told to 
execute an infinite loop :-)


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

Re: [Haskell-cafe] monomorphism restriction

[Jonathan Cast]

On Sat, 2008-06-14 at 17:19 +1000, Rafal Kolanski wrote:
> Ryan Ingram wrote:
> > sumns 0 = 0
> > sumns x = sumns (x-1) + n
> > 
> > Without the monomorphism restriction, computing n is a function call;
> > it is evaluated each time it is asked for.
> 
> I'm relatively new to Haskell, and since this topic already came up, I
> was wondering if anyone could explain to me how this ties into implicit
> parameters which "escape" from their respective functions?
> 
> For instance, if I just state:
> maxLength = maxLengthParameter ?config
> without providing a type signature and then use it, I get warned that
> ?config "escapes" from maxLength and that I should provide a type
> signature or turn off the monomorphism restriction.

Which means you have to declare ?config at top level and then maxLength
has that value baked into it.

> I find implicit parameters are a really nice way to pass a configuration
> to a whole tree of functions (in this case an LZSS compressor) without
> having to explicitly add it as a parameter to every single one of the
> functions.
> 
> What are the performance implications of turning off the restriction and
> allowing implicit parameters to "escape"? Are there general performance
> implications of implicit parameters I am not aware of?

Implicit parameters get turned into real parameters under the hood.
Turning off the monomorphism restriction (e.g., giving a type signature)
just leaves the implicit parameter in place, so maxLength is a function,
not a value.  You probably /want/ maxLength to be computed from
whatever ?config happens to be in scope, so you won't mind in this case.
But Haskell wants to be sure you know that it is a function, and
laziness's automatic memoization doesn't work for it, before it will
proceed.  That's all that's going on here.

jcc


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

Re: [Haskell-cafe] ANN: Topkata

[Deborah Goldsmith]

On Jun 14, 2008, at 1:06 PM, Don Stewart wrote:

tom.davie:

In the mean time -- who knows enough to make ghc target ARM, and get
this to link against the iPhone libraries?  This would be quite a  
coup

if it could be made to run there!


I'd be interested. We should start a wiki page for Haskell on the
iphone..


It's an interesting idea, but I think it would need to be a cross- 
compiler. Does ghc support cross-compilation?


Deborah

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

[Haskell-cafe] OT: Paper on increasing entropy in software systems

[Magnus Therning]

This is wildly off topic, but since the Haskell community is a rather
academic one I thought there might be a good chance to find someone who
can point me in the right direction.

I was just listening to Brooks' talk at OOPSLA 2007 and in the Q&A part
at the end he mentions a paper on increasing entropy in software
systems.  He mentions the authors' names but I can't quite make it out
and Google hasn't been very helpful either.  He says the paper “must be
30 years old” and it sounds like he says it's by Les Bellati and Manny
Leimann (Lehmann?).  As I said, I can't quite make out the names, and
the names ring no bells for me.  Does anyone on the list know what paper
he's referring to?

/M

-- 
Magnus Therning (OpenPGP: 0xAB4DFBA4)
magnus＠therning．org Jabber: magnus．therning＠gmail．com
http://therning.org/magnus

What if I don't want to obey the laws? Do they throw me in jail with
the other bad monads?
 -- Daveman




signature.asc
Description: OpenPGP digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe