Re: [Haskell-cafe] Why the Prelude must die

[mgsloan]

On 3/24/07, Vivian McPhail <[EMAIL PROTECTED]> wrote:


I agree with Sven, but...

What I want to push is a 'mathematically sound' numeric prelude.  A proper
numerical prelude should have bona fide mathematical obects like groups,
rings, and fields underlying common numerical classes.  It would be
edifying
to the student who discovered that the particular data type he is using is
an inhabitant of a known class and can thus take advantage of known
properties, presupplied as class methods.  Reasoning and communication
about
programs, data types, and functions would be enhanced.



One problem with that is that the instances are often times not
mathematically sound - Int and Double certainly aren't.

Anyway, I agree with the general gist of this idea. However, I think rather
than the Prelude, we should just be an interface to the internal stuff, a
'Builtin' module. Actually, there could still be a prelude - it would
contain all the common imports (to maintain our decent scores in golf
competitions :) ).

I also like the idea that the addition of a module line would remove the
implicit prelude import - the source code has become 'proper'.  Before the
module line, the programmer is probably in quick-hack/script mode.

Numeric prelude-ness would be good.  This brings up an issue - would the
numeric classes need to be included/imported in Builtin?  To avoid this, I
think a bit of evillness (depending on your perspective, i suppose) is
necessary - builtin functions would be stuff like AddInts and AddDoubles,
not (+). The numeric stuff that provides the classes would also provide
instances to wrap the builtin stuff.

Hmm, just realized that PreludeBuiltin already exists...  Ahwell, I think
the renaming is a good idea - classes should not be involved in the
builtins.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Why the Prelude must die

[Ivan Lazar Miljenovic]

On Sun, 2007-03-25 at 14:14 +1200, Vivian McPhail wrote:
> 
> [Conjecture 1 (2007). Haskell Mathematical Prelude and Mathematicians] If
> Haskell had a mathematically sound prelude then more mathematicians would
> use Haskell.

I agree, even though I've only been using Haskell for a few months.
Especially if matrix functions were included.  Then you can also get
category theorists using a practical implementation of some of their
theories to solve problems ;-)


-- 
Ivan Lazar Miljenovic


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] Why the Prelude must die

[ajb]

G'day all.

Quoting Jason Creighton <[EMAIL PROTECTED]>:

> Wouldn't this be a non-issue if the "map" in Prelude was fmap?

It would be a non-issue if a number of things were different, such
as if Data.Map were a Functor and "map" was the Functor map instead
of the list map.

Either way, it highlights at least two of the original complaints
about the Prelude:

1. It gobbles up names that people want to use.

2. It's not generic enough.

Incidentally, I disagree with one of the sentences in the OP:

"The Prelude was designed by extremely smart people and was
considered close to perfect at the time."

The first half is, at best, partly true.

Don't get me wrong, everyone who has added stuff to the Prelude over
the years was, I have no doubt, individually smart.  But it would be
only partly correct to call it "designed".  Rather, it was originally
consolidated from all of the Miranda-work-alikes of the late 80s, then
gradually added to as features (e.g. constructor classes) were addedto the
language.

As such, the Prelude is not a well-designed coherent whole, but rather
an eclectic mix of Miranda-isms and Gofer-isms.

I understand that we do need a common base language of functions, and
calling it "Prelude" is as good as ny other.  But we don't miss
complex numbers being in the Prelude, and I suspect we wouldn't miss
other stuff getting moved out into modules either.

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

[Haskell-cafe] What ever happened to Haskell 98 as a "stable branch"?

[Stefan O'Rear]

Upon more reflection...

>From the Preface to the Haskell 98 Language and Libraries Report:

> Haskell 98 was conceived as a relatively minor tidy-up of Haskell
> 1.4, making some simplifications, and removing some pitfalls for the
> unwary. It is intended to be a "stable" language in sense the
> implementors are committed to supporting Haskell 98 exactly as
> specified, for the foreseeable future. 

In other words, we already have a stable branch of Haskell.

Why, then, are we so paranoid about introducing breaking changes in
the development branch of haskell?  Why are we stuck without the class
system extension proposal?  Why is Num so still so horribly mangled?
Why can I not 'map' over a Set?  Why must I use lists of characters if
I desire standard sorting?  Why can I not get a good error message
from read? 

(If you answer "because H98 is obsolete", then file this away as a
must-read after H' is released.)

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

Re: [Haskell-cafe] Why the Prelude must die

[Duncan Coutts]

On Sat, 2007-03-24 at 11:53 +, Neil Mitchell wrote:

> > This is a highly non-academic concern.  Many widely used libraries,
> > such as Parsec, operate only on lists and not the newer and more
> > efficient sequence types, such as bytestrings.
> 
> Lists in Haskell are the nicest data structure, they work most
> naturally with the language. There is a reason that lists is the
> default.

In particular lists are often used as a control structure whereas most
other sequence data types are really only data structures.

Duncan

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

Re: [Haskell-cafe] Link error in ALUT "Hello, World"

[Stefan O'Rear]

On Sun, Mar 25, 2007 at 12:24:52PM +0900, Nobuhito Mori wrote:
> I thought "bug report" is more official  than ML. So I wanted to make this 
> problem more clear if possible (in other words, I'm a beginner of Haskell 
> and I was not convinced that this problem is suited to "bug report").
> Now O.K. I'll report a bug.

In general we like people to do homework, including ML queries, if you
aren't sure the behaivor is wrong.  But it's pretty hard to argue for
the correctness of the provided example code failing to compile.  :)

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

Re: [Haskell-cafe] Link error in ALUT "Hello, World"

[Nobuhito Mori]

I thought "bug report" is more official  than ML. So I wanted to make this 
problem more clear if possible (in other words, I'm a beginner of Haskell 
and I was not convinced that this problem is suited to "bug report").

Now O.K. I'll report a bug.


On Sun, Mar 25, 2007 at 11:56:28AM +0900, Nobuhito Mori wrote:
> Thanks for reply. I'll report a bug if there is no new reply in two 
days.


Why do you want to wait?

Reporting a bug is no more disruptive than posting on the ML .. and
it's obviously not your fault, since the code isn't yours.

Also, it's not listed as a bug already.

(We want to know because improving the psychological aspects of the
Haskell experience is very important to us.)

Stefan


_
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


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

Re: [Haskell-cafe] Why the Prelude must die

[Jason Creighton]

On Sat, Mar 24, 2007 at 10:08:48PM -0400, [EMAIL PROTECTED] wrote:
> G'day all.
> 
> Quoting Sven Panne <[EMAIL PROTECTED]>:
> 
> > Even though I think that the current Prelude is far from perfect, one should
> > not forget that is a very solid foundation of a "common language": If one
> > sees e.g. '(.)' or 'map', it is immediately clear to everybody what this
> > means, [...]
> 
> Unless you import Data.Map, of course.

Wouldn't this be a non-issue if the "map" in Prelude was fmap?

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

Re: [Haskell-cafe] Link error in ALUT "Hello, World"

[Stefan O'Rear]

On Sun, Mar 25, 2007 at 11:56:28AM +0900, Nobuhito Mori wrote:
> Thanks for reply. I'll report a bug if there is no new reply in two days.

Why do you want to wait?

Reporting a bug is no more disruptive than posting on the ML .. and
it's obviously not your fault, since the code isn't yours.

Also, it's not listed as a bug already.

(We want to know because improving the psychological aspects of the
Haskell experience is very important to us.)

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

Re: [Haskell-cafe] Link error in ALUT "Hello, World"

[Nobuhito Mori]

Thanks for reply. I'll report a bug if there is no new reply in two days.


Nobuhito



From: Stefan O'Rear <[EMAIL PROTECTED]>
To: Nobuhito Mori <[EMAIL PROTECTED]>
CC: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Link error in ALUT "Hello, World"
Date: Sat, 24 Mar 2007 19:43:18 -0700

On Sun, Mar 25, 2007 at 11:38:56AM +0900, Nobuhito Mori wrote:
> Hi, I installed OpenAL and ALUT bindings downloaded from
> http://hackage.haskell.org/packages/archive/pkg-list.html and tried
> compilation of "HelloWorld.hs" example which I got from
> http://darcs.haskell.org/packages/ALUT/
>
> But it returns errors as follow and I can not get an '.exe' file.
> Though there are clearly "link errors", I can not understand why it
> happens. By option "-package ALUT",  libalut.a (which made by pexports 
and
>  dlltool because I do not know original "alut.lib" can be used by mingw) 
and
> other necessary libraries are automatically linked, I think. What is 
"@8"

> of "[EMAIL PROTECTED]"?
>
> How can I avoid these errors?
> My environment is
> Windows XP SP2, GHC6.6, MinGW/MSYS (so some of mingw tools are 
duplicated.

> one is GHC's, the other is MinGW's)

@8 is name mangling, used by the (Windows-specific) calling convention
for these symbols.  Probably, a convention declaration was omitted in
ALUT, and not noticed because it would only affect windows.  Report a
bug (http://hackage.haskell.org/trac/ghc/newticket?type=bug).
Disclaimer: I haven't used windows in four years.

Stefan


_
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/


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

Re: [Haskell-cafe] Why the Prelude must die

[David Menendez]

Chris Eidhof writes:

> 
> On Mar 24, 2007, at 2:36 AM, Sebastian Sylvan wrote:
> 
> >
> > The solution is simple:
> >
> > * If there is a "module M where" clause in the beginning of the
> > file, then it's a "proper" module and shouldn't import the Prelude.
> > * If there is no module declaration then it's a "quick'n dirty
> > script" and should have the Prelude implicitly imported.
> > * Interactive interpreters should probably import the Prelude.

> So if I'm writing a script, which has been working, then import  
> Control.Monad, it all suddenly stops working?

No, that's an import declaration, not a module declaration.

So far, this is my favorite proposal, but I'm not sure it's better than
leaving things the way they are. There's a lot of useful stuff in the
Prelude, so the typical usage is likely to be "import Prelude hiding
(...)", which you can do right now.

On the other hand, making this like this explicit seems consistent with
Haskell's traditions.
-- 
David Menendez <[EMAIL PROTECTED]> | "In this house, we obey the laws
  |of thermodynamics!"
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Link error in ALUT "Hello, World"

[Stefan O'Rear]

On Sun, Mar 25, 2007 at 11:38:56AM +0900, Nobuhito Mori wrote:
> Hi, I installed OpenAL and ALUT bindings downloaded from 
> http://hackage.haskell.org/packages/archive/pkg-list.html and tried 
> compilation of "HelloWorld.hs" example which I got from  
> http://darcs.haskell.org/packages/ALUT/
> 
> But it returns errors as follow and I can not get an '.exe' file.
> Though there are clearly "link errors", I can not understand why it 
> happens. By option "-package ALUT",  libalut.a (which made by pexports and 
>  dlltool because I do not know original "alut.lib" can be used by mingw) and 
> other necessary libraries are automatically linked, I think. What is "@8" 
> of "[EMAIL PROTECTED]"?
> 
> How can I avoid these errors?
> My environment is
> Windows XP SP2, GHC6.6, MinGW/MSYS (so some of mingw tools are duplicated. 
> one is GHC's, the other is MinGW's)

@8 is name mangling, used by the (Windows-specific) calling convention
for these symbols.  Probably, a convention declaration was omitted in
ALUT, and not noticed because it would only affect windows.  Report a
bug (http://hackage.haskell.org/trac/ghc/newticket?type=bug).
Disclaimer: I haven't used windows in four years. 

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

[Haskell-cafe] Link error in ALUT "Hello, World"

[Nobuhito Mori]

Hi, I installed OpenAL and ALUT bindings downloaded from 
http://hackage.haskell.org/packages/archive/pkg-list.html and tried 
compilation of "HelloWorld.hs" example which I got from  
http://darcs.haskell.org/packages/ALUT/


But it returns errors as follow and I can not get an '.exe' file.
Though there are clearly "link errors", I can not understand why it happens. 
 By option "-package ALUT",  libalut.a (which made by pexports and dlltool 
because I do not know original "alut.lib" can be used by mingw) and other 
necessary libraries are automatically linked, I think. What is "@8" of 
"[EMAIL PROTECTED]"?


How can I avoid these errors?
My environment is
Windows XP SP2, GHC6.6, MinGW/MSYS (so some of mingw tools are duplicated. 
one is GHC's, the other is MinGW's)



---

ghc -package ALUT HelloWorld.hs


C:\Program 
Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+

0x18): undefined reference to [EMAIL PROTECTED]'
C:\Program 
Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+

0xdc): undefined reference to [EMAIL PROTECTED]'
C:\Program 
Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+

0x19d): undefined reference to [EMAIL PROTECTED]'
C:\Program 
Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+

0x1d9): undefined reference to [EMAIL PROTECTED]'
C:\Program 
Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+

0x210): undefined reference to [EMAIL PROTECTED]'
C:\Program 
Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+

0x2b0): undefined reference to [EMAIL PROTECTED]'
C:\Program 
Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+

0x36d): undefined reference to [EMAIL PROTECTED]'
C:\Program 
Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+

0x3f7): undefined reference to [EMAIL PROTECTED]'
C:\Program 
Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+

0x584): undefined reference to [EMAIL PROTECTED]'
C:\Program 
Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+

0x6b8): undefined reference to [EMAIL PROTECTED]'
C:\Program 
Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+

0x7e8): undefined reference to [EMAIL PROTECTED]'
C:\Program 
Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+

0x92f): undefined reference to [EMAIL PROTECTED]'
C:\Program 
Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+

0xb2c): undefined reference to [EMAIL PROTECTED]'
C:\Program 
Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+

0xbc9): undefined reference to [EMAIL PROTECTED]'
C:\Program 
Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+

0xc01): undefined reference to [EMAIL PROTECTED]'
C:\Program 
Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+

0xc55): undefined reference to [EMAIL PROTECTED]'
C:\Program 
Files\Haskell\ALUT-2.0\ghc-6.6/libHSALUT-2.0.a(Config.o):fake:(.text+

0xd89): undefined reference to [EMAIL PROTECTED]'
-


Nobuhito

_
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/


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

Re: [Haskell-cafe] Application of iterate

[ajb]

G'day all.

Quoting Henning Thielemann <[EMAIL PROTECTED]>:

> http://darcs.haskell.org/htam/src/Numerics/ZeroFinder/Newton.hs
>
> with
>   inverse t (\x->(x^2,2*x)) t

The problem with all such solutions was touched on by Longesh:

> > > 20 iterations is a bit arbitrary.

This isn't a one-liner, but there's a straightforward answer to the
"arbitrary" number of iterations: Assuming that the task is to compute a
square root fast, a better solution is to come up with an initial
guess that's good enough such that you only need a fixed number of
iterations.

This one is as accurate as my CPU's built-in sqrt, and unlike every
other solution posted here, it uses no loops:

  http://www.opensubscriber.com/message/haskell-cafe@haskell.org/5135386.html

But, of course, we're now way off-topic from the original question!

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

Re: [Haskell-cafe] Why the Prelude must die

[Vivian McPhail]

I agree with Sven, but...

What I want to push is a 'mathematically sound' numeric prelude.  A proper
numerical prelude should have bona fide mathematical obects like groups,
rings, and fields underlying common numerical classes.  It would be edifying
to the student who discovered that the particular data type he is using is
an inhabitant of a known class and can thus take advantage of known
properties, presupplied as class methods.  Reasoning and communication about
programs, data types, and functions would be enhanced.

[Conjecture 1 (2007). Haskell Mathematical Prelude and Mathematicians] If
Haskell had a mathematically sound prelude then more mathematicians would
use Haskell.

Cheers,

Vivian

> 
> Message: 1
> Date: Sat, 24 Mar 2007 17:56:11 +0100
> From: Sven Panne <[EMAIL PROTECTED]>
> Subject: Re: [Haskell-cafe] Why the Prelude must die
> To: haskell-cafe@haskell.org
> Cc: [EMAIL PROTECTED]
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain;  charset="iso-8859-1"
> 
> On Saturday 24 March 2007 03:48, Stefan O'Rear wrote:
> > 1. Namespace pollution
> >
> > The Prelude uses many simple and obvious names.  Most 
> programs don't 
> > use the whole Prelude, so names that aren't needed take up 
> namespace 
> > with no benefit. [...]
> 
> Even though I think that the current Prelude is far from 
> perfect, one should not forget that is a very solid 
> foundation of a "common language": If one sees e.g. '(.)' or 
> 'map', it is immediately clear to everybody what this means, 
> without having to scan through (perhaps long) import lists. 
> Of course one could hide some parts of the Prelude etc., but 
> I think in the long run this only leads to confusion. 
> Redefining common things, heavy use of tons of self-defined 
> operators etc. all make maintenance much harder.
> 
> Try reading Lisp code with heavy use of macros or C++ code 
> with tons of overloadings. This is more like Sudoku solving 
> than anything else, because there is no "common language" 
> between the author and the reader anymore.
> 
> And taking away the prelude is a little bit like taking away 
> 'int', 'double', 'for', 'while' etc. from the C programmer...
> 
> > 11. Committeeism
> >
> > Because the Prelude has such a wide audience, a strong committee 
> > effect exists on any change to it.  This is the worst kind of 
> > committeeism, and impedes real progress while polluting the Prelude 
> > with little-used features such as fail in Monad (as opposed to
> > MonadZero) and until.
> 
> Depending on your viewpoint, you can see this as a plus. 
> Everybody agrees that finalizers are evil, but propose the 
> removal of that method from java.lang.Object to the Java people. :-)
> 
> My proposal would be to incrementally improve the Prelude, 
> modularize it a bit more, fix the Num hierarchy, but 
> basically leave it as it is.
> 
> Cheers,
>S.
> 
> 

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

Re: [Haskell-cafe] Why the Prelude must die

[ajb]

G'day all.

Quoting Sven Panne <[EMAIL PROTECTED]>:

> Even though I think that the current Prelude is far from perfect, one should
> not forget that is a very solid foundation of a "common language": If one
> sees e.g. '(.)' or 'map', it is immediately clear to everybody what this
> means, [...]

Unless you import Data.Map, of course.

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

Re: [Haskell-cafe] Why the Prelude must die

[Chris Eidhof]

On Mar 24, 2007, at 2:36 AM, Sebastian Sylvan wrote:


On 3/24/07, Chris Eidhof <[EMAIL PROTECTED]> wrote:

> Given all these issues, I consider the only reasonable option is to
> discard the Prelude entirely.  There will be no magic modules.
> Everything will be an ordinary library.  HOFs like (.) are  
available

> from Control.Function.  List ops come from Data.List.  Any general
> abstractions can be added in abstract Sequence, Monad, etc.  
modules.

> Haskell will regain the kind of organic evolution whose lack
> currently causes Haskell to lose its lead over Python et al by the
> day.
I basically agree with a lot of the things you say. The only thing
is: it's so convenient to have the Prelude. I can just start writing
my haskell programs and don't have to worry about all kinds of
imports. And you'll end up being repetitive: you'll import (.) and
stuff like that in _every_ file. Yeah, this will definitely be more
modular, but if we go for it, it's going to be so much more (tedious)
work to create a new program.


The solution is simple:

* If there is a "module M where" clause in the beginning of the file,
then it's a "proper" module and shouldn't import the Prelude.
* If there is no module declaration then it's a "quick'n dirty script"
and should have the Prelude implicitly imported.
* Interactive interpreters should probably import the Prelude.
So if I'm writing a script, which has been working, then import  
Control.Monad, it all suddenly stops working?


I also think that you want to minimize the differences between an  
interpreted (interactive) version and a compiled version. It would be  
very weird for first-time users if their scripts work in ghci but  
break when they compile them.


I'm sorry for being so negative. I like the idea, but I don't like it  
from a newbie-standpoint. The thing is: this is mostly handy for  
power-users, maybe we should do it for power-users only? We can still  
change the prelude to have no more code in there, but make it only a  
bunch of imports?


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

Re: [Haskell-cafe] "runST $ return ()" /= "runST (return ())" ??

[Stefan O'Rear]

On Sat, Mar 24, 2007 at 05:33:55PM -0700, Stefan O'Rear wrote:
> types.  Therefore the application (runST id) is illegal.  (Sadly GHC

This should have been (id runST), oops.

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

Re: [Haskell-cafe] "runST $ return ()" /= "runST (return ())" ??

[Stefan O'Rear]

On Sun, Mar 25, 2007 at 01:28:53AM +0100, Marc A. Ziegert wrote:
> hi!
> 
> i've just discovered this strange behaviour of existential quantifiers with 
> runST:
> 
> ---
> Prelude Control.Monad.ST> :t runST (return ())
> runST (return ()) :: ()
> 
> Prelude Control.Monad.ST> :t runST $ (return ())
> :1:9:
> Couldn't match expected type `forall s. ST s a'
>against inferred type `m ()'
> In the second argument of `($)', namely `(return ())'
> 
> Prelude Control.Monad.ST>
> ---
> 
> 
> the same with "id runST undefined".
> is this a bug or an unsolved problem?
> i'm not sure wheather it is a part of the wanted feature of runST's type 
> definition.
> 
> i did not find any discussions about this.
> can anyone enlighten me, please?

Neither.  The type of id is:

forall a. a -> a

In Haskell, type variables range only over normal types, not rank-two
types.  Therefore the application (runST id) is illegal.  (Sadly GHC
is not able to produce a particularly good error message in this
case.)

(There is a GHC extension in the HEAD that allows this, but you are
adviced not to rely on or even try to understand it.)

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

[Haskell-cafe] "runST $ return ()" /= "runST (return ())" ??

[Marc A. Ziegert]

hi!

i've just discovered this strange behaviour of existential quantifiers with 
runST:

---
Prelude Control.Monad.ST> :t runST (return ())
runST (return ()) :: ()

Prelude Control.Monad.ST> :t runST $ (return ())
:1:9:
Couldn't match expected type `forall s. ST s a'
   against inferred type `m ()'
In the second argument of `($)', namely `(return ())'

Prelude Control.Monad.ST>
---


the same with "id runST undefined".
is this a bug or an unsolved problem?
i'm not sure wheather it is a part of the wanted feature of runST's type 
definition.

i did not find any discussions about this.
can anyone enlighten me, please?

- marc



pgp8AZTMBBLA2.pgp
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] newbie "concatenating" monad question

[Udo Stenzel]

Leandro Penz wrote:
> buildStuff =
>   func1 ++ func2 ++ func3 ++ func4
> 
> My idea is to have a monad with a concatenating >>, so that I can:
> 
> bulidStuff = do
>   func1
>   func2
>   func3
>   func4

buildStuff = concat [
func1,
func2,
func3,
func4 ]

Remember, functional programming was already useful without monads.

 
-Udo
-- 
"It is the mark of an educated mind to be able to entertain a thought
without accepting it." 
-- Aristotle


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

Re: [Haskell-cafe] newbie "concatenating" monad question

[Stefan O'Rear]

On Sat, Mar 24, 2007 at 08:05:25PM +, Paul Johnson wrote:
> strings, are instances of the Monoid class (i.e. they implement mplus in 
> the way you would expect).  You just have to wrap a function around 

Actually they don't.

[EMAIL PROTECTED]:/tmp$ ghc-6.4.2 -v0 -e 'main' X.hs
ABend
[EMAIL PROTECTED]:/tmp$ ghc-6.6 -v0 -e 'main' X.hs
AendBend
[EMAIL PROTECTED]:/tmp$ cat X.hs
import Data.Monoid
main = putStrLn $ (str1 `mappend` str2) "end"
str1 = ("A" ++)
str2 = ("B" ++)
[EMAIL PROTECTED]:/tmp$

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

Re: [Haskell-cafe] newbie "concatenating" monad question

[Paul Johnson]

Leandro Penz wrote:
I have some functions that build big strings by calling other 
functions and appending the result, like


buildStuff =
  func1 ++ func2 ++ func3 ++ func4

The usual idiom is something like

  buildStuff = concat [func1, func2, func3, func4]

Put the list elements on separate lines if it makes life easier.


My idea is to have a monad with a concatenating >>, so that I can:

bulidStuff = do
  func1
  func2
  func3
  func4

I am thinking about using the writer monad, but I would still have to 
use "tell". The list monad is not an option either, as it does not 
concatenate.


Is there a proper way of doing something like this (efficiently) ?
The writer monad is a more complicated way of doing this, and might be 
appropriate if you want to build up a string over a lot of different 
functions.  But its probably easier to use concat.


One thing: beware of the copying overhead.  The naive use of the Writer 
monad is to use ++, but every time you "tell" it a new string the 
accumulated string so far gets copied to have the new one appended.  The 
way around this is to use StringS (which you will find in the Prelude).  
StringS has the type "String -> String", which seems really wierd.  An 
StringS takes a string, prepends something on to it, and then returns 
the resulting string.  The clever thing is that you can take two StringS 
and concatenate them using (.)  function composition in constant time.  
So I can write:


  foo, bar, stop, foobar :: StringS
  foo = ("Hello " ++)  -- A function from a string to a string.
  bar = ("world" ++)
  stop = ('.' :)  -- Also a function from a string to a string: work it 
out.

  foobar = foo . bar . stop -- Function composition: very efficient.
  main = do
 putStrLn (foobar "")  -- Get the final result by applying the 
function to an empty string.


You can do this inside the Writer monad as well because functions, like 
strings, are instances of the Monoid class (i.e. they implement mplus in 
the way you would expect).  You just have to wrap a function around 
"tell" like


  say str = tell (str ++)

and remember that runWriter will then hand you a StringS.

Hope this helps,

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

Re: [Haskell-cafe] newbie "concatenating" monad question

[Bryan Burgers]

My idea is to have a monad with a concatenating >>, so that I can:

bulidStuff = do
  func1
  func2
  func3
  func4



Leandro Penz


I actually did this recently for a project I have been working on.
First, an example:


output label a@(I.Add a1 a2 a3) = do
  comment (show a)
  mov' label eax a1
  add eax a2
  mov a3 eax


My monad in this example has a Writer or a WriterT in it somewhere. I
of course had to include the 'tell' that you mention somewhere, but I
hid it in the 'comment', 'mov', and 'add' functions in an attempt to
make my own personal assembly DSL. Obviously, you would have to either
include 'tell' in your func1, func2, etc., or create wrappers for them
that include a 'tell'.

Just my two cents.

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

Re: [Haskell-cafe] newbie "concatenating" monad question

[Bryan O'Sullivan]

Leandro Penz wrote:


My idea is to have a monad with a concatenating >>, so that I can:

bulidStuff = do
  func1
  func2
  func3
  func4


You could do this, but it's easier to take advantage of the fact that [] 
is an instance of MonadPlus, and just use `mplus`.


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

[Haskell-cafe] newbie "concatenating" monad question

[Leandro Penz]

Hi

I'm new here and this is my first mail to the list, so be gentle :)

I have some functions that build big strings by calling other functions and
appending the result, like

buildStuff =
 func1 ++ func2 ++ func3 ++ func4

My idea is to have a monad with a concatenating >>, so that I can:

bulidStuff = do
 func1
 func2
 func3
 func4

I am thinking about using the writer monad, but I would still have to use
"tell". The list monad is not an option either, as it does not concatenate.

Is there a proper way of doing something like this (efficiently) ?

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

Re: [Haskell-cafe] Why the Prelude must die

[David House]

On 24/03/07, Stefan O'Rear <[EMAIL PROTECTED]> wrote:

This is a ranty request for comments, and the more replies the better.


Without responding to any particular comment, my opinion is that we
should have a minimal Prelude with functions like (.) that couldn't be
reasonably redefined in any function. Most of the list functions
should have to be imported, to encourage people to use a Map or Array
and so on. Read should be in Text.Read to encourage people to use
Parsec and so on.

I wouldn't necessarily be against a minimal Prelude/expanded Prelude
split determined by a 'module M where' declaration, as suggested by
Sebastian.

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

Re: [Haskell-cafe] Why the Prelude must die

[Sven Panne]

On Saturday 24 March 2007 03:48, Stefan O'Rear wrote:
> 1. Namespace pollution
>
> The Prelude uses many simple and obvious names.  Most programs don't
> use the whole Prelude, so names that aren't needed take up namespace
> with no benefit. [...]

Even though I think that the current Prelude is far from perfect, one should 
not forget that is a very solid foundation of a "common language": If one 
sees e.g. '(.)' or 'map', it is immediately clear to everybody what this 
means, without having to scan through (perhaps long) import lists. Of course 
one could hide some parts of the Prelude etc., but I think in the long run 
this only leads to confusion. Redefining common things, heavy use of tons of 
self-defined operators etc. all make maintenance much harder.

Try reading Lisp code with heavy use of macros or C++ code with tons of 
overloadings. This is more like Sudoku solving than anything else, because 
there is no "common language" between the author and the reader anymore.

And taking away the prelude is a little bit like taking 
away 'int', 'double', 'for', 'while' etc. from the C programmer...

> 11. Committeeism
>
> Because the Prelude has such a wide audience, a strong committee
> effect exists on any change to it.  This is the worst kind of
> committeeism, and impedes real progress while polluting the Prelude
> with little-used features such as fail in Monad (as opposed to
> MonadZero) and until.

Depending on your viewpoint, you can see this as a plus. Everybody agrees that 
finalizers are evil, but propose the removal of that method from 
java.lang.Object to the Java people. :-)

My proposal would be to incrementally improve the Prelude, modularize it a bit 
more, fix the Num hierarchy, but basically leave it as it is.

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

Re: [Haskell-cafe] Can we do better than duplicate APIs? [was: Data.CompactString 0.3]

[Robert Dockins]

On Friday 23 March 2007 18:55, Benjamin Franksen wrote:
> [sorry for the somewhat longer rant, you may want to skip to the more
> technical questions at the end of the post]
>
> Twan van Laarhoven wrote:
> > I would like to announce version 0.3 of my Data.CompactString library.
> > Data.CompactString is a wrapper around Data.ByteString that represents a
> > Unicode string. This new version supports different encodings, as can be
> > seen from the data type:
> >
> > [...]
> >
> > Homepage:  http://twan.home.fmf.nl/compact-string/
> > Haddock:   http://twan.home.fmf.nl/compact-string/doc/html/
> > Source:darcs get http://twan.home.fmf.nl/repos/compact-string
>
> After taking a look at the Haddock docs, I was impressed by the amount of
> repetition in the APIs. Not ony does Data.CompactString duplicate the whole
> Data.ByteString interface (~100 functions, adding some more for encoding
> and decoding), the whole interface is again repeated another four times,
> once for each supported encoding.

I'd like to mention that as maintainer of Edison, I face similar difficulties.  
The data structure interfaces have scores of functions and there are about 20 
different concrete implementations of various sorts.  Even minor interface 
changes require a lot of tedious editing to make sure that everything stays 
in sync.

[snip]

> The problems I (for-)see are for maintenance and usability, both of which
> are of course two sides of the same coin. For the library implementer,
> maintenance will become more difficult, as ever more of such 'almost equal'
> interfaces must be maintained and kept in sync.

This is true. For the specific case of Edison, this is not too bad because all 
the implementations are currently in one package and under the control of one 
person (namely, me).  That might, however, change in the future.  Obviously, 
it is a problem _now_ for the ByteString and friends.

> One could use code 
> generation or macro expansion to alleviate this, but IMO the necessity to
> use extra-language pre-processors points to a weakness in the language; it
> be much less complicated and more satisfying to use a language feature that
> avoids the repetition instead of generating code to facilitate it.

I've considered something like this for Edison.  Actually, I've considered 
going even further and building the Edison concrete implementations in a 
theorem prover to prove correctness and then extracting the Haskell source.  
Some sort of in-langauge or extra-language support for mechanicly producing 
the source files for the full API from the optimized "core" API would be 
quite welcome.  Handling export lists, haddock comments, typeclass instances, 
etc, are quite tedious.

I have to admit, I'm not sure what an in-language mechanism for doing 
something like this would look like.  Template Haskell is an option, I 
suppose, but its pretty hard to work with and highly non-portable.  It also 
wouldn't produce Haddock-consumable source files.  ML-style first class 
modules might fit the bill, but I'm not sure anyone is seriously interested 
in bolting that onto Haskell.

[snip]

> Here are some raw ideas:
>
> One reason why I think type classes have not (yet) been used to reduce the
> amount of API repetition is that Haskell doesn't (directly) support
> abstraction over type constraints nor over the number of type parameters
> (polykinded types?). Often such 'almost equal' module APIs differ in
> exactly these aspects, i.e. one has an additional type parameter, while yet
> another one needs slightly different or additional constraints on certain
> types. Oleg K. has shown that some if these limitations can be overcome w/o
> changing or adding features to the language, however these tricks are not
> easy to learn and apply.

I mostly put these kinds of type system tricks in the same category as TH: 
hard to use and non-portable.

[snip]

> Or maybe we have come to the point where Haskell's lack of a 'real' module
> system, like e.g. in SML, actually starts to hurt? Can associated types
> come to the rescue?

I'm not familiar enough with associated types to know if they would help with 
these sorts of problems.  Can someone more knowledgable comment?

> Cheers
> Ben


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

Re: [Haskell-cafe] OpenGL and GLUT in GHC

[Sven Panne]

[ Small note: Library-related questions should better be directed to 
[EMAIL PROTECTED], and for mails regardind the OpenGL/GLUT packages there 
is the [EMAIL PROTECTED] mailing list. ]

On Saturday 24 March 2007 13:37, Ruben Zilibowitz wrote:
> [...] I've encountered a strange bug which I'm having trouble with. If I
> render a sphere and a plane, then the plane is facing the wrong way
> and is shaded on the wrong side. If however I only render the plane
> then it appears to be facing the right way and is shaded on the
> correct side. [...]

I guess the problem is a misunderstanding of what 'autoNormal $= Enabled' 
does. It enables the automatic generation of analytic normals when 2D 
evaluators are used. It doesn't affect the rendering of normal primitives 
like quads. You don't provide any normals for your plane, so the current 
normal is used for all four vertices. The value of the current normal is 
(Vector 0 0 1) initially, so this seems to work if you render the plane 
alone, *but* the GLUT object rendering functions provide normals for all 
their vertices. So the net effect is that the normals for the vertices of 
your plane are set to whichever normal GLUT has specified last. Simple fix: 
Provide normals for your quad, i.e. use

   normal (Normal3 0 0 (1 :: GLfloat))

before specifying any vertex of your quad. In general when lighting is used, 
make sure to provide the correct normals for all vertices. Unit normals 
should be preferred, otherwise you have to tell OpenGL about that and this 
leads to more work (= rescaling/normalization of all normals within OpenGL).

A few more notes:

   * There is no need in your example to use 'normalize $= Enabled' when you 
provide unit normals. GLUT does this, BTW.

   * Setting the material properties could be done only once in the 
initialization function.

   * Use postRedisplay only when something has really changed, e.g. at the end 
of 'motion'. Otherwise you get 100% CPU/GPU load for no good reason.

   * IORefs are StateVars, so you can use get and ($=) instead of readIORef 
and writeIORef, this is more consistent with the OpenGL/GLUT API.

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

Re: [Haskell-cafe] Performance Help

[Ian Lynagh]

On Sat, Mar 24, 2007 at 01:46:33PM +, Dominic Steinitz wrote:
> 
> Thanks. I'm trying to build just SHA1 but I am getting the following linker 
> errors. Do you know what option I should be adding?
> 
> [EMAIL PROTECTED]:~/sha11> ghc -o perfTest 
> perfTest.hs -iIgloo/darcs-unstable/src --make -lz
> Linking perfTest ...
> Igloo/darcs-unstable/src/FastPackedString.o: In function `r4Lk_info':
> (.text+0x34c): undefined reference to `utf8_to_ints'

You need to link with fpstring.o (which in turn you get by compiling
fpstring.c).


Thanks
Ian

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

Re: [Haskell-cafe] Performance Help

[Dominic Steinitz]

On Friday 16 March 2007 21:24, Ian Lynagh wrote:
> On Sun, Mar 11, 2007 at 08:18:44PM +, Dominic Steinitz wrote:
> > I have re-written the sha1 code so that it is (hopefully) easy to see
> > that it faithfully implements the algorithm (see
> > http://www.itl.nist.gov/fipspubs/fip180-1.htm). Having got rid of the
> > space leak, I have been trying to improve performance.
> >
> > Currently, the haskell code is 2 orders of magnitude slower than the
> > sha1sum that ships with my linux.
>
> I don't know if this is useful to you, but darcs has some SHA1 code that
> IIRC is much closer to C's performance. It currently uses darcs' own
> FastPackedString library, but porting it to ByteString should be fairly
> easy.
>
> See SHA1.lhs in http://www.abridgegame.org/repos/darcs-unstable
>
> It might even be able to be made faster still by calling lower-level
> functions than {shift,rotate}{L,R} directly.
>
>
> Thanks
> Ian
Ian,

Thanks. I'm trying to build just SHA1 but I am getting the following linker 
errors. Do you know what option I should be adding?

Dominic.

[EMAIL PROTECTED]:~/sha11> ghc -o perfTest 
perfTest.hs -iIgloo/darcs-unstable/src --make -lz
Linking perfTest ...
Igloo/darcs-unstable/src/FastPackedString.o: In function `r4Lk_info':
(.text+0x34c): undefined reference to `utf8_to_ints'
Igloo/darcs-unstable/src/FastPackedString.o: In function `r4Lm_info':
(.text+0x370): undefined reference to `first_nonwhite'
Igloo/darcs-unstable/src/FastPackedString.o: In function `r4Lo_info':
(.text+0x430): undefined reference to `first_white'
Igloo/darcs-unstable/src/FastPackedString.o: In function `r4Lq_info':
(.text+0x4f0): undefined reference to `has_funky_char'
Igloo/darcs-unstable/src/FastPackedString.o: In function `r4LE_info':
(.text+0x848): undefined reference to `my_mmap'
Igloo/darcs-unstable/src/FastPackedString.o: In function `r4LM_info':
(.text+0x8dc): undefined reference to `conv_to_hex'
Igloo/darcs-unstable/src/FastPackedString.o: In function `r4LO_info':
(.text+0x904): undefined reference to `conv_from_hex'
collect2: ld returned 1 exit status

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

[Haskell-cafe] OpenGL and GLUT in GHC

[Ruben Zilibowitz]

Hi,

I'm experimenting using OpenGL and GLUT in Haskell using GHC. There  
are modules Graphics.Rendering.OpenGL and Graphics.UI.GLUT. I am  
using these.


I've encountered a strange bug which I'm having trouble with. If I  
render a sphere and a plane, then the plane is facing the wrong way  
and is shaded on the wrong side. If however I only render the plane  
then it appears to be facing the right way and is shaded on the  
correct side.


I have made the source file available as a download here:
http://www.cse.unsw.edu.au/~rubenz/stuff/test.hs

It can be built by running: ghc --make test.hs
I am using ghc 6.6

There is a comment in the source file saying: "Commenting out the  
line below here causes the plane to be rendered facing towards the  
camera..."
The bug can be seen by commenting out the line of code that follows  
and recompiling.


If anyone can help me by explaining why I am getting this bug or how  
to fix it that would be great. I'd be very appreciative.


Cheers,

Ruben

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

Re: [Haskell-cafe] Why the Prelude must die

[Neil Mitchell]

Hi

Reducing to just haskell-cafe - since this isn't yet a concrete
proposal - more just a discussion.


1. Namespace pollution


Do you want to overload (.) ? I think its good that some names mean
standard things. Maybe not as many as the prelude, but some standard
things are good.



This is a highly non-academic concern.  Many widely used libraries,
such as Parsec, operate only on lists and not the newer and more
efficient sequence types, such as bytestrings.


Lists in Haskell are the nicest data structure, they work most
naturally with the language. There is a reason that lists is the
default.



3. Supports obsolete programming styles


Niggle: nub isn't in Prelude, it's Data.List


More damagingly, the Prelude encourages programmers to use
backtracking parsers.  Moore's law can save you from nub, but it will
never clarify "Prelude.read: no parse".


This is very bad!


5. Inflexibility

Because of Haskell's early binding, the Prelude always uses the
implementation of modules that exists where the Prelude was compiled.
You cannot replace modules with better ones.


I think this is a good thing - I can imagine people changing map to
also do a reverse, then changing it retroactively in an existing
program/library. They should at least be forced to recompile.



6. Dependency


Could not agree more! If additionally your compiler is written in a
silly way, you can make this problem 100 times worse for yourself.


13. There can be no escape


I still like the Prelude.


14. My future

Given all these issues, I consider the only reasonable option is to
discard the Prelude entirely.  There will be no magic modules.
Everything will be an ordinary library.  HOFs like (.) are available
from Control.Function.  List ops come from Data.List.  Any general
abstractions can be added in abstract Sequence, Monad, etc. modules.
Haskell will regain the kind of organic evolution whose lack
currently causes Haskell to lose its lead over Python et al by the
day.


I would then provide "Common" or something, which just imported and
exported Control.Function/Data.List and the other common modules. This
would probably be better for scripts (I often end up importing
Data.List, System.Directory, System.Process), and would make larger
programs more explicit.

If Common was provided as a replacement, which was more general than
the Prelude, then you could do that easily. With a tiny bit of work I
think you could replicate Prelude and add flags as required.

Of course, I think technically this would be a lot of work - just
fighting with dependencies, bugs, make systems, silly compilers etc.

Thanks

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

[Haskell-cafe] Re: Rank-2-polymorphism problem

[Martin Huschenbett]

Martin Huschenbett schrieb:

My thoughts were that for any class C the types

 > Maybe (forall a. C a => a)  (I will call it T1 for short)

and

 > (forall a. C a => Maybe a)  (I will call it T2 for short)

are isomorphic. Defining the isomorphism from T1 to T2 is quite simple:

iso1 :: Maybe (forall a. C a => a) -> (forall a. C a => Maybe a)
iso1 (Just s) = Just s
iso1 Nothing  = Nothing

But I don't catch how to define the isomorphism of the other direction 
(from T2 to T1). I would guess that defining this isomorphism would also 
solve my problem concerning the SQL stuff.


I found the solution to my problem. I just want to post it for others 
who may come across the same problem.


The trick was simply looking at GHC's error message that tells something 
about ambiguous types. So let T be an arbitrary instance of C then the 
other isomorphism becomes:


> iso2 :: (forall a. C a => Maybe a) -> Maybe (forall a. C a => a)
> iso2 s if isJust (s :: Maybe T) then Just (fromJust s) else Nothing

Regards,

Martin.

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

[Haskell-cafe] Re: Rank-2-polymorphism problem

[Martin Huschenbett]

apfelmus schrieb:

For me, the fourth trial works, at least on

f :: (forall s . Num s => Maybe s) -> Int
f y = case y of
Just x  -> x
Nothing -> 0


This works, because the compiler knows that x has to have type Int. But 
if you want to apply a function g :: (forall a. Num a => a) -> Int to x 
before returning, it doesn't work any more. But I need this function 
application.


However, thanks for your help.

Regards,

Martin.

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

Re: [Haskell-cafe] Why the Prelude must die

[Sebastian Sylvan]

On 3/24/07, Chris Eidhof <[EMAIL PROTECTED]> wrote:

> Given all these issues, I consider the only reasonable option is to
> discard the Prelude entirely.  There will be no magic modules.
> Everything will be an ordinary library.  HOFs like (.) are available
> from Control.Function.  List ops come from Data.List.  Any general
> abstractions can be added in abstract Sequence, Monad, etc. modules.
> Haskell will regain the kind of organic evolution whose lack
> currently causes Haskell to lose its lead over Python et al by the
> day.
I basically agree with a lot of the things you say. The only thing
is: it's so convenient to have the Prelude. I can just start writing
my haskell programs and don't have to worry about all kinds of
imports. And you'll end up being repetitive: you'll import (.) and
stuff like that in _every_ file. Yeah, this will definitely be more
modular, but if we go for it, it's going to be so much more (tedious)
work to create a new program.


The solution is simple:

* If there is a "module M where" clause in the beginning of the file,
then it's a "proper" module and shouldn't import the Prelude.
* If there is no module declaration then it's a "quick'n dirty script"
and should have the Prelude implicitly imported.
* Interactive interpreters should probably import the Prelude.


That should take of most issues.

--
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] Re: Rank-2-polymorphism problem

[Bulat Ziganshin]

Hello Martin,

Friday, March 23, 2007, 11:37:16 PM, you wrote:

>> readValue' :: Field -> Maybe (forall s. SqlBind s => s) -> Value

> Thank you very much, that's exactly what I wanted. After reading in the
> GHC users guide about rank 2 polymorphism I thought that this is not 
> possible. Chapter "7.4.8. Arbitrary-rank polymorphism" says:

"impredicative polymorphism" is new in ghc 6.6. look for this word in
ghc docs and in spj's papers


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

[Haskell-cafe] Re: Rank-2-polymorphism problem

[apfelmus]

Martin Huschenbett wrote:
>
> readValue :: Field -> (forall s. SqlBind s => s) -> Value
> readValue _ = ...
> 
> 
> That works just fine. But now I want a version of readValue that has a
> Maybe wrapped around the second parameter and that shall call readValue
> in the case of a Just and emptyValue in the case of Nothing. But I can't
> figure out how to write this function as I always get compiler errors.
>
> 
> -- The type I want to get.
> readValue' :: Field -> (forall s. SqlBind s => Maybe s) -> Value
> [..]
> -- Fourth trial:
> readValue fld s = case s of
>   Just s' -> readValue fld s'
>   Nothing -> emptyValue fld

For me, the fourth trial works, at least on

f :: (forall s . Num s => Maybe s) -> Int
f y = case y of
Just x  -> x
Nothing -> 0

Your definition has a typo (missing tick '), maybe that's the cause why
it doesn't work?

Furthermore, I guess that let-binding any troublesome rank-2-variables
is beneficial.

Regards,
apfelmus

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