Re: [Haskell-cafe] Re: Monad for HOAS?

[Edsko de Vries]

On Wed, May 14, 2008 at 06:01:37PM -0400, Chung-chieh Shan wrote:
> Conal Elliott <[EMAIL PROTECTED]> wrote in article <[EMAIL PROTECTED]> in 
> gmane.comp.lang.haskell.cafe:
> > I share your perspective, Edsko.  If foo and (Let foo id) are
> > indistinguishable to clients of your module and are equal with respect to
> > your intended semantics of Exp, then I'd say at least this one monad law
> > holds.  - Conal
> 
> I am at least sympathetic to this perspective, but the Expr constructors
> are not as polymorphic as the monad operations: if in
> 
> do a <- foo
>return a
> 
> foo has type "ExprM String" (perhaps foo is equal to "return []"), then
> we want to generate the DSL expression "Let [] id", but "[]" is not of
> type "Expr".  Because whenever foo's type is not "ExprM Expr" the above
> code using do notation must be exactly equal to foo, by parametricity
> even when foo's type is "ExprM Expr" we cannot generate Let.

Yes, absolutely. This is the core difficulty in designing the monad, and
the reason why I started experimenting with adding a type constructor to
Expr

data Expr a = One 
| Add (Expr a) (Expr a) 
| Let (Expr a) (Expr a -> Expr a) 
| Place a

This is useful regardless, because we can now define catamorphisms over
Expr. Nevertheless, I still can't see how to define my monad properly
(other than using Lauri's suggestion, which has already improved the
readability of my code). 

Return is now easy (return = Place), and it should be relatively easy to
define a join operation 

  Expr (Expr a) -> Expr a

*but* since Expr uses HOAS, it is not an instance of Functor and so we
cannot use the join operator to define return. Actually, I think this
approach is a dead end too, but I'm not 100% sure. 

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

Re: [Haskell-cafe] Re: Endianess

[Bill]

On Wed, 2008-05-14 at 20:59 +0200, Henning Thielemann wrote:
   . . .
> Interesting to know what jokes are told about Germans. 8-] So, do English 
> professors save their prepositions for the end of a lecture?
This seems peculiarly apropos:

I lately lost a preposition.
It hid, I thought, beneath my chair,
And angrily I cried "Perdition!
Up from out of in under there!"

Correctness is my vade mecum
And straggling phrases I abhor.
Still, I wonder, what should he come
Up from out of in under for?

 - Morris Bishop

 -- Bill Wood


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

Re: [Haskell-cafe] Richer (than ascii) notation for haskell source?

[Brandon S. Allbery KF8NH]

On 2008 May 14, at 22:57, Derek Elkins wrote:


On Thu, 2008-05-15 at 14:40 +1200, Richard A. O'Keefe wrote:

I suspect that "λ is the lambda-symbol iff it is not preceded by any
identifier character and is not followed by a Greek letter" might  
work.


λω. ...
λα. ...
λδ ε. ...



Come to think of it, if you're after math notation, enough Greek  
letters are used as symbols that it might be necessary to just exclude  
them from use as letters.  (Symbols would be fair game.)


--
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] Re: Endianess

[Albert Y. C. Lai]

Claus Reinke wrote:

Germans have no problems with sentences which though started at
the beginning when observed closely and in the light of day (none of
which adds anything to the content of the sentence in which the very
parenthetical remark you -dear reader- are reading at this very moment
while wondering whether the writer -dear me- is ever going to reach
his point -if, in fact, there is a point (of which one cannot always be
entirely sure until one has stored and processed the whole construct
from beginning to end and thought it over carefully at least once more
because who knows, sense appears here and there, now and then,
to this one and that one, and how are you, Mr. Wilson?


Unmatched open parentheses.


you mean as in returning from a different context than the one
we decended into? we'd never do such a thing, honestly!-)

then again, Jane Austen was happy enough writing about her
characters not being "one and twenty", so perhaps that is just a
lost art?-)


Oh, I see the matching closing parentheses now. Perfect... 72MB freed by 
GC in 2.3ms.

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

Re: [Haskell-cafe] Richer (than ascii) notation for haskell source?

[Derek Elkins]

On Thu, 2008-05-15 at 14:40 +1200, Richard A. O'Keefe wrote:
> On 15 May 2008, at 2:34 pm, Brandon S. Allbery KF8NH wrote:
> > Hm.  Newer Unicode standard than the version supported by OSX and  
> > GNOME, I take it?  That's not so helpful if nobody actually supports  
> > the characters in question.  (My Mac claims 166CC is in an  
> > unassigned area, and no supplied font has the others.  It does at  
> > least acknowledge that the others should exist and are "letters".)
> 
> Whoops.  Sorry, typo.  166CC should have been 1D6CC.
> 
> I was actually looking at the Unicode 5.1 character data base,
> but the copy I keep on my own machine is the 4.0.0 version,
> and those mathematical symbols were there back in 4.0.0.
> 
> > I still suspect it would not be outside the pale to make λ a  
> > keyword.  We already have several, after all.
> 
> I'd rather not have to write \x as λ x with a space required after the  
> λ.
> I suspect that "λ is the lambda-symbol iff it is not preceded by any
> identifier character and is not followed by a Greek letter" might work.

λω. ...
λα. ...
λδ ε. ...


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

Re: [Haskell-cafe] Richer (than ascii) notation for haskell source?

[Brandon S. Allbery KF8NH]

On 2008 May 14, at 22:40, Richard A. O'Keefe wrote:

I still suspect it would not be outside the pale to make λ a  
keyword.  We already have several, after all.


I'd rather not have to write \x as λ x with a space required after  
the λ.

I suspect that "λ is the lambda-symbol iff it is not preceded by any
identifier character and is not followed by a Greek letter" might  
work.


Adjacent different scripts in general is probably a reasonable token  
discriminator.  A "token" combining LTR and RTL, for example, is just  
confusing.  (Japanese might need to be an exception; I don't know if  
ideographs and romanji are ever mixed at the word level.)


--
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] Richer (than ascii) notation for haskell source?

[Richard A. O'Keefe]

On 15 May 2008, at 2:34 pm, Brandon S. Allbery KF8NH wrote:
Hm.  Newer Unicode standard than the version supported by OSX and  
GNOME, I take it?  That's not so helpful if nobody actually supports  
the characters in question.  (My Mac claims 166CC is in an  
unassigned area, and no supplied font has the others.  It does at  
least acknowledge that the others should exist and are "letters".)


Whoops.  Sorry, typo.  166CC should have been 1D6CC.

I was actually looking at the Unicode 5.1 character data base,
but the copy I keep on my own machine is the 4.0.0 version,
and those mathematical symbols were there back in 4.0.0.

I still suspect it would not be outside the pale to make λ a  
keyword.  We already have several, after all.


I'd rather not have to write \x as λ x with a space required after the  
λ.

I suspect that "λ is the lambda-symbol iff it is not preceded by any
identifier character and is not followed by a Greek letter" might work.

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

Re: [Haskell-cafe] Re: Richer (than ascii) notation for haskell source?

[Brandon S. Allbery KF8NH]

On 2008 May 14, at 22:23, Patrick Surry wrote:

So maybe what I really want is to essentially write my source in  
(la)tex

and be able to both compile and render to dvi at the same time?  I
suppose word's crazy equation editor or mathml is another option but  
it

makes the source itself either less portable or less readable?


Someone already pointed to a way to do that, IIRC.

--
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] Richer (than ascii) notation for haskell source?

[Brandon S. Allbery KF8NH]

On 2008 May 14, at 22:07, Richard A. O'Keefe wrote:


On 15 May 2008, at 7:19 am, Brandon S. Allbery KF8NH wrote:
Unfortunately, while I thought there was a distinct lambda sign  
that wasn't the lowercase Greek letter, there isn't.  (That said, I  
don't see why it couldn't be a keyword.  You'd need a space after  
it.)


There are three lambda letters: lower and upper case Greek, and  
Ugaritic (U+1038D).

But there are also mathematical symbols:

U+166CC mathematical bold small lamda (sic.)
U+1D706 mathematical italic small lamda (sic.)
U+1D740 mathematical bold italic small lamda (sic.)
U+1D77A mathematical sans-serif bold small lamda (sic.)
U+1D7B4 mathematical sans-serif bold italic small lamda (sic.)


Hm.  Newer Unicode standard than the version supported by OSX and  
GNOME, I take it?  That's not so helpful if nobody actually supports  
the characters in question.  (My Mac claims 166CC is in an unassigned  
area, and no supplied font has the others.  It does at least  
acknowledge that the others should exist and are "letters".)


Hm, U+2144 as an approximation?

I still suspect it would not be outside the pale to make λ a keyword.   
We already have several, after all.


At least to give editors a fighting chance of matching their concept  
of a

"word" with Haskell tokens, it might be better to use nabla instead of
lambda.  Other old APL fans may understand why (:-).  Alternatively,  
didn't
Church really want to use a character rather like a down tack, and  
have to
squish it to get a letter his printer was happy with?  Nah, nabla  
for 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

[Haskell-cafe] RE: Richer (than ascii) notation for haskell source?

[Patrick Surry]

Sorry, missed a mail digest: LyX and lhs2tex sound more like what I
mean.

Patrick

-Original Message-
From: Patrick Surry 
Sent: Wednesday, May 14, 2008 10:24 PM
To: 'haskell-cafe@haskell.org'
Subject: Re: Richer (than ascii) notation for haskell source?

Lots of folk have suggested writing code with Unicode symbols, but that
doesn't really get me where I'm thinking of.  Back in the day, I spent
many happy hours writing math(s) in amstex style, peppered with latex
backslash references/macros for greek symbols, set operators as well as
character attributes like underline, bold, goth, italic and so on.  With
the magic of (la)tex and dvips you get a rich intuitive representation
of your equations - where you can 'see' types by character attributes
(bold vectors, gothic sets or whatever) and have easily readable
operators, functions, etc.  Similarly to display alternative pattern
cases as a display equation?  

So maybe what I really want is to essentially write my source in (la)tex
and be able to both compile and render to dvi at the same time?  I
suppose word's crazy equation editor or mathml is another option but it
makes the source itself either less portable or less readable?

I think Knuth talks about literate programming as this ability to
intermingle 'beautified' human-readable representation along with code,
and it seems like Haskell is close to delivering that.  (Tho I think
"literate Haskell" is not the same thing.)

Perhaps a pipe dream tho.

Patrick


DISCLAIMER: This e-mail is intended only for the addressee named above. As this 
e-mail may contain confidential or privileged information, if you are not the 
named addressee, you are not authorised to retain, read, copy or disseminate 
this message or any part of it. If you received this email in error, please 
notify the sender and delete the message from your computer.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Richer (than ascii) notation for haskell source?

[Patrick Surry]

Lots of folk have suggested writing code with Unicode symbols, but that
doesn't really get me where I'm thinking of.  Back in the day, I spent
many happy hours writing math(s) in amstex style, peppered with latex
backslash references/macros for greek symbols, set operators as well as
character attributes like underline, bold, goth, italic and so on.  With
the magic of (la)tex and dvips you get a rich intuitive representation
of your equations - where you can 'see' types by character attributes
(bold vectors, gothic sets or whatever) and have easily readable
operators, functions, etc.  Similarly to display alternative pattern
cases as a display equation?  

So maybe what I really want is to essentially write my source in (la)tex
and be able to both compile and render to dvi at the same time?  I
suppose word's crazy equation editor or mathml is another option but it
makes the source itself either less portable or less readable?

I think Knuth talks about literate programming as this ability to
intermingle 'beautified' human-readable representation along with code,
and it seems like Haskell is close to delivering that.  (Tho I think
"literate Haskell" is not the same thing.)

Perhaps a pipe dream tho.

Patrick


DISCLAIMER: This e-mail is intended only for the addressee named above. As this 
e-mail may contain confidential or privileged information, if you are not the 
named addressee, you are not authorised to retain, read, copy or disseminate 
this message or any part of it. If you received this email in error, please 
notify the sender and delete the message from your computer.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Richer (than ascii) notation for haskell source?

[Dan Weston]

Richard A. O'Keefe wrote:

At least to give editors a fighting chance of matching their concept of a
"word" with Haskell tokens, it might be better to use nabla instead of
lambda.  Other old APL fans may understand why (:-).  Alternatively, didn't
Church really want to use a character rather like a down tack, and have to
squish it to get a letter his printer was happy with?  Nah, nabla for me.


nablabot anyone? Nabla calculus? (But wait, in differential calculus 
nabla is a gradient operator, so let's rename that lambda).


And people misspelling nabla as nambla will find a surprise when they 
google it...


Better use a Unihan character instead.

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

Re: [Haskell-cafe] Richer (than ascii) notation for haskell source?

[Richard A. O'Keefe]

On 15 May 2008, at 7:19 am, Brandon S. Allbery KF8NH wrote:
Unfortunately, while I thought there was a distinct lambda sign that  
wasn't the lowercase Greek letter, there isn't.  (That said, I don't  
see why it couldn't be a keyword.  You'd need a space after it.)


There are three lambda letters: lower and upper case Greek, and  
Ugaritic (U+1038D).

But there are also mathematical symbols:

U+166CC mathematical bold small lamda (sic.)
U+1D706 mathematical italic small lamda (sic.)
U+1D740 mathematical bold italic small lamda (sic.)
U+1D77A mathematical sans-serif bold small lamda (sic.)
U+1D7B4 mathematical sans-serif bold italic small lamda (sic.)

These things are visually letters, but as mathematical symbols
they should not combine into words.  Except that to my surprise, nay,  
to my
utter astonishment, the Unicode 5.1 character data base classifies  
them as

letters just like the letter "e".

At least to give editors a fighting chance of matching their concept  
of a

"word" with Haskell tokens, it might be better to use nabla instead of
lambda.  Other old APL fans may understand why (:-).  Alternatively,  
didn't
Church really want to use a character rather like a down tack, and  
have to
squish it to get a letter his printer was happy with?  Nah, nabla for  
me.


--
"I don't want to discuss evidence." -- Richard Dawkins, in an
interview with Rupert Sheldrake.  (Fortean times 232, p55.)






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

Re: [Haskell-cafe] Re: Endianess

[Eric Stansifer]

> So I've always wondered, if you are writing down a number being dictated
> (slowly) by someone else, like 234, do you write the 2, then leave space and
> write the 4, then go back and fill in with 3? Or do you push the 4 onto the
> stack until the 3 arrives, and write 34 at once.

My German professor told us a story, set in WWII:  Two British pilots
shot down behind enemy lines, who had received very thorough training
on German culture, current sports, etc., successfully blended in with
the native Germans for some time until someone noticed them in a cafe
writing down the sum on their bill in left-to-right order.  They were
summarily shot.

Not that I have any idea whether this is based on truth or not, or
whether Germans, in fact, write the last two digits in reverse order.

Also, Claus's reply gives me a headache.

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

Re: [Haskell-cafe] Re: Endianess

[Jonathan Cast]

On 14 May 2008, at 2:13 PM, Claus Reinke wrote:

It's not that simple with bits.  They lack consistency just  
like the

usual US date format and the way Germans read numbers.

So you claim that you pronounce 14 tenty-four? In German  
pronunciation

is completely uniform from 13 to 99.

http://www.verein-zwanzigeins.de/
So I've always wondered, if you are writing down a number being  
dictated (slowly) by someone else, like 234, do you write the 2,  
then leave space and write the 4, then go back and fill in with 3?  
Or do you push the 4 onto the stack until the 3 arrives, and write  
34 at once.


Germans have no problems with sentences which though started at
the beginning when observed closely and in the light of day (none of
which adds anything to the content of the sentence in which the very
parenthetical remark you -dear reader- are reading at this very moment
while wondering whether the writer -dear me- is ever going to reach
his point -if, in fact, there is a point (of which one cannot  
always be

entirely sure until one has stored and processed the whole construct
from beginning to end and thought it over carefully at least once more
because who knows, sense appears here and there, now and then,
to this one and that one, and how are you, Mr. Wilson?
If the latter, does this imply that Germans have a harder time  
with tail recursion?


you mean as in returning from a different context than the one
we decended into? we'd never do such a thing, honestly!-)

then again, Jane Austen was happy enough writing about her
characters not being "one and twenty", so perhaps that is just a
lost art?-)


Murthered, by the same revolutionaries who destroyed the rest of the  
world Jane Austen wrote about.


jcc

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

Re: [Haskell-cafe] Re: GHC predictability

[Don Stewart]

derek.a.elkins:
> On Mon, 2008-05-12 at 19:30 -0700, Don Stewart wrote:
> > > I offer up the following example:
> > >
> > >  mean xs = sum xs / length xs
> > >
> > > Now try, say, "mean [1.. 1e9]", and watch GHC eat several GB of RAM. (!!)
> > 
> > But you know why, don't you?
> > 
> > >  sat down and spent the best part of a day writing an MD5 
> > > implementation. Eventually I got it so that all the test vectors work 
> > > right. (Stupid little-endian nonsense... mutter mutter...) When I tried 
> > > it on a file containing more than 1 MB of data... o dear...
> > 
> > Did you use Data.Binary or the other libraries for efficient access to 
> > gigabytes of data?
> > 
> > > Of course, the first step in any serious attempt at performance 
> > > improvement
> > > is to actually profile the code to figure out where the time 
> > > is being spent. 
> > 
> > Well, actually, for our 'mean()' case, it means just using the right 
> > structures.
> > Arrays for example:
> > 
> > import Data.Array.Vector
> > import Text.Printf
> > 
> > mean :: UArr Double -> Double
> > mean arr = b / fromIntegral a
> >   where
> > k (n :*: s) a = n+1 :*: s+a
> > a :*: b = foldlU k (0 :*: 0) arr :: (Int :*: Double)
> > 
> > main = printf "%f\n" . mean $ enumFromToFracU 1 1e9
> > 
> > For example,
> > 
> > $ time ./A
> > 5.067109e8
> > ./A  3.53s user 0.00s system 99% cpu 3.532 total
> > 
> > Try allocating an array of doubles in C, and getting similar results.
> > (The compiler is optimising this to:
> > 
> > Main_zdszdwfold_info:
> >   leaq32(%r12), %rax
> >   cmpq%r15, %rax
> >   movq%rax, %r12
> >   ja  .L10
> >   movsd   .LC0(%rip), %xmm0
> >   ucomisd %xmm5, %xmm0
> >   jae .L12
> >   movq%rsi, (%rax)
> >   movq$base_GHCziFloat_Dzh_con_info, -24(%rax)
> >   movsd   %xmm6, -16(%rax)
> >   movq$base_GHCziBase_Izh_con_info, -8(%rax)
> >   leaq-7(%rax), %rbx
> >   leaq-23(%rax), %rsi
> >   jmp *(%rbp)
> > .L12:
> >   movapd  %xmm6, %xmm0
> >   addq$1, %rsi
> >   subq$32, %r12
> >   addsd   %xmm5, %xmm0
> >   addsd   .LC2(%rip), %xmm5
> >   movapd  %xmm0, %xmm6
> >   jmp Main_zdszdwfold_info
> > 
> > Note even any garbage collection. This should be pretty much the same
> > performance-wise as unoptimised C.
> > 
> > > almost any nontrivial program you write 
> > > spends 60% or more of its time doing GC rather than actual work. 
> > 
> > Ok, you're doing something very wrong. GC time is typically less than 15% 
> > of the running
> > time of typical work programs I hack on.
> > 
> > I bet you're using lists inappropriately?
> > 
> > > I find it completely impossibly to write code that doesn't crawl along at 
> > > a
> > > snail's pace.  Even when I manage to make it faster, I usually have no 
> > > clue
> > > why.
> > 
> > I think there is a problem that few people are taking the time to understand
> > the compilation model of Haskell, while they've had the C runtime behaviour
> > drilled into their brains since college.
> > 
> > Until you sit down and understand what your Haskell code means, it will be 
> > very
> > hard to reason about optimisations, unfortunately.
> > 
> > GHC does what it does well, and its predictable. As long as you understand 
> > the operations your trying to make predictions about.
> > 
> > I suggest installing ghc-core, and looking at how your code is compiled.
> > Try many examples, and have a good knowledge of the STG paper.
> 
> My experience has been that simply understanding lazy/normal order
> evaluation is enough to catch most of the "big performance problems"
> beginners complain about.  If you can't evaluate Haskell by hand at the
> source level, you have no hope of understanding performance issues.
> 
> For going more for C-like speed, your advice seems more appropriate.
> 

Yes, I agree. You must first be able to reason about the evaluation
strategy on paper. If you want to get C like speed, you should
understand Core. Thankfully, the knowledge of how to do this, and tools
to help, are improving.

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

Re: [Haskell-cafe] Re: GHC predictability

[Derek Elkins]

On Mon, 2008-05-12 at 19:30 -0700, Don Stewart wrote:
> > I offer up the following example:
> >
> >  mean xs = sum xs / length xs
> >
> > Now try, say, "mean [1.. 1e9]", and watch GHC eat several GB of RAM. (!!)
> 
> But you know why, don't you?
> 
> >  sat down and spent the best part of a day writing an MD5 
> > implementation. Eventually I got it so that all the test vectors work 
> > right. (Stupid little-endian nonsense... mutter mutter...) When I tried 
> > it on a file containing more than 1 MB of data... o dear...
> 
> Did you use Data.Binary or the other libraries for efficient access to 
> gigabytes of data?
> 
> > Of course, the first step in any serious attempt at performance improvement
> > is to actually profile the code to figure out where the time 
> > is being spent. 
> 
> Well, actually, for our 'mean()' case, it means just using the right 
> structures.
> Arrays for example:
> 
> import Data.Array.Vector
> import Text.Printf
> 
> mean :: UArr Double -> Double
> mean arr = b / fromIntegral a
>   where
> k (n :*: s) a = n+1 :*: s+a
> a :*: b = foldlU k (0 :*: 0) arr :: (Int :*: Double)
> 
> main = printf "%f\n" . mean $ enumFromToFracU 1 1e9
> 
> For example,
> 
> $ time ./A
> 5.067109e8
> ./A  3.53s user 0.00s system 99% cpu 3.532 total
> 
> Try allocating an array of doubles in C, and getting similar results.
> (The compiler is optimising this to:
> 
> Main_zdszdwfold_info:
>   leaq32(%r12), %rax
>   cmpq%r15, %rax
>   movq%rax, %r12
>   ja  .L10
>   movsd   .LC0(%rip), %xmm0
>   ucomisd %xmm5, %xmm0
>   jae .L12
>   movq%rsi, (%rax)
>   movq$base_GHCziFloat_Dzh_con_info, -24(%rax)
>   movsd   %xmm6, -16(%rax)
>   movq$base_GHCziBase_Izh_con_info, -8(%rax)
>   leaq-7(%rax), %rbx
>   leaq-23(%rax), %rsi
>   jmp *(%rbp)
> .L12:
>   movapd  %xmm6, %xmm0
>   addq$1, %rsi
>   subq$32, %r12
>   addsd   %xmm5, %xmm0
>   addsd   .LC2(%rip), %xmm5
>   movapd  %xmm0, %xmm6
>   jmp Main_zdszdwfold_info
> 
> Note even any garbage collection. This should be pretty much the same
> performance-wise as unoptimised C.
> 
> > almost any nontrivial program you write 
> > spends 60% or more of its time doing GC rather than actual work. 
> 
> Ok, you're doing something very wrong. GC time is typically less than 15% of 
> the running
> time of typical work programs I hack on.
> 
> I bet you're using lists inappropriately?
> 
> > I find it completely impossibly to write code that doesn't crawl along at a
> > snail's pace.  Even when I manage to make it faster, I usually have no clue
> > why.
> 
> I think there is a problem that few people are taking the time to understand
> the compilation model of Haskell, while they've had the C runtime behaviour
> drilled into their brains since college.
> 
> Until you sit down and understand what your Haskell code means, it will be 
> very
> hard to reason about optimisations, unfortunately.
> 
> GHC does what it does well, and its predictable. As long as you understand 
> the operations your trying to make predictions about.
> 
> I suggest installing ghc-core, and looking at how your code is compiled.
> Try many examples, and have a good knowledge of the STG paper.

My experience has been that simply understanding lazy/normal order
evaluation is enough to catch most of the "big performance problems"
beginners complain about.  If you can't evaluate Haskell by hand at the
source level, you have no hope of understanding performance issues.

For going more for C-like speed, your advice seems more appropriate.

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

Re: [Haskell-cafe] GHC API GSoc project (was: ANN: Haddock version 2.1.0)

[Chaddaï Fouché]

2008/5/15 Claus Reinke <[EMAIL PROTECTED]>:
>  Feel free to CC me or the ticket with things like that.  I'll be
>  IMHO, trying to support a semantics- and comment-preserving
>  roundtrip in (pretty . parse) would be a good way to start (David
>  says he's going to look at the extracting comments/pragmas part,
>  but they still need to be put back in during pretty printing). It sounds
>  simple, and if it is, it will enable a lot more usage of the GHC API;
>  and if it turns out not to be simple, you'll have a first sign of what
>  you're up against, and can adjust your expectations!-)
>
>  I also hope you are in touch with Chaddaï - the port of HaRe
>  to the GHC API did not make it as a GSoC project, but I
>  understand he is going to do some work in this direction
>  anyway.
>
>  - http://hackage.haskell.org/trac/ghc/ticket/1886
>(GHC API should preserve and provide access to comments)

Well not in touch until now, I was waiting a little bit to see in
which direction this project is going to evolve. There's plenty of
interesting improvement that one could bring to GHC API. For my
project of course, I'm very interested in the preserving comment part.
I intended to make it independantly, like Haddock do now, but if the
GHC API was to get native support for it, it would be great (for all
kind of others applications too).

I'll keep in touch.

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

Re: [Haskell-cafe] Monad vs ArrowChoice

[Twan van Laarhoven]

Ronald Guida wrote:

I have read that Monad is stronger than Idiom because Monad lets me
use the results of a computation to choose between the side effects of
alternative future computations, while Idiom does not have this
feature.  Arrow does not have this feature either.

ArrowChoice has the feature that the sum type, Either, can be used to
choose between alternative computations, including their side effects.
 I know that Monad is supposed to be stronger than ArrowChoice, but I
have to ask, what exactly can Monad do that ArrowChoice can't do?


Monads are equivalent to ArrowApply, they allow you to use a computed *action*. 
For example:


getMissileLauncher :: IO (String -> IO ())

notWithArrows = do
 launchMissiles <- getMissleLauncher
 launchMissiles "Russia"

ArrowChoice is not enough to implement this function. But it is possible with 
ArrowApply, of which Kleisli IO is an instance.


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

Re: [Haskell-cafe] Short circuiting and the Maybe monad

[Derek Elkins]

On Wed, 2008-05-14 at 12:42 -0700, Dan Piponi wrote:
> On Wed, May 14, 2008 at 12:03 PM, Andrew Coppin
> <[EMAIL PROTECTED]> wrote:
> 
> > "It is well-known that trees with substitution form a monad."
> 
> Now that's funny. Compare with the first line of this paper:
> http://citeseer.ist.psu.edu/510658.html

Well, it's well-known.

Further, not only do they form a monad, but they are a free monad.

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

Re: [Haskell-cafe] FFI: newbie linking problem

[Olivier Boudry]

On Wed, May 14, 2008 at 5:46 PM, Bulat Ziganshin <[EMAIL PROTECTED]>
wrote:

> use stdcall instead of ccall in Haskell too. afair, depending on
> calling conventions, different prefixes/suffixes are used when
> translating C function name into assembler (dll) name
>

Oops, sorry I copied the wrong line in my e-mail. I'm using stdcall in the
foreign import. I first tried with ccall and then realized the header was
defining the stdcall convention when built on windows. The link error occurs
when I use stdcall. When I use ccall it links but gives segmentation faults
when I run the program.

Here is the last import I used.
foreign import stdcall unsafe "sapnwrfc.h RfcUTF8ToSAPUC"
  f_RfcUTF8ToSAPUC :: RfcBytePtr -> CUInt -> SapUCPtr -> Ptr CUInt -> Ptr
CUInt -> RfcErrorInfoPtr -> IO RfcRetCodeType

Thanks,

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

[Haskell-cafe] Re: Monad for HOAS?

[Chung-chieh Shan]

Conal Elliott <[EMAIL PROTECTED]> wrote in article <[EMAIL PROTECTED]> in 
gmane.comp.lang.haskell.cafe:
> I share your perspective, Edsko.  If foo and (Let foo id) are
> indistinguishable to clients of your module and are equal with respect to
> your intended semantics of Exp, then I'd say at least this one monad law
> holds.  - Conal

I am at least sympathetic to this perspective, but the Expr constructors
are not as polymorphic as the monad operations: if in

do a <- foo
   return a

foo has type "ExprM String" (perhaps foo is equal to "return []"), then
we want to generate the DSL expression "Let [] id", but "[]" is not of
type "Expr".  Because whenever foo's type is not "ExprM Expr" the above
code using do notation must be exactly equal to foo, by parametricity
even when foo's type is "ExprM Expr" we cannot generate Let.

-- 
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
The pomotarians have nothing to lose but their value chains.

Call the Thermodynamics Police!

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

[Haskell-cafe] Monad vs ArrowChoice

[Ronald Guida]

I have read that Monad is stronger than Idiom because Monad lets me
use the results of a computation to choose between the side effects of
alternative future computations, while Idiom does not have this
feature.  Arrow does not have this feature either.

ArrowChoice has the feature that the sum type, Either, can be used to
choose between alternative computations, including their side effects.
 I know that Monad is supposed to be stronger than ArrowChoice, but I
have to ask, what exactly can Monad do that ArrowChoice can't do?

Let me set up an example to illustrate where I'm coming from.

> import Control.Monad.Writer
> import Control.Applicative
> import Control.Arrow hiding (pure)

The missileControl function accepts a flag to determine whether
missiles actually get launched, and it returns the number of
casualties.

> missileControl :: Bool -> IO Integer
> missileControl b = do
>  showFlag b
>  casualties <- if b
>  then launchMissiles
>  else doNotLaunch
>  return casualties

> showFlag :: Bool -> IO Bool
> showFlag b = (putStrLn $ "Launch flag = " ++ show b) >> return b

> launchMissiles :: IO Integer
> launchMissiles = do
>   putStrLn "Missiles have been launched."
>   putStrLn "Casualties = 6,700,000,000."
>   return 67

> doNotLaunch :: IO Integer
> doNotLaunch = putStrLn "Missiles not launched." >> return 0

If I try to use an Idiom, or even an Arrow, instead of a Monad, then I
don't get to choose between the alternative side effects, and the
results will be similar to this:

> missileControl' :: Bool -> IO Integer
> missileControl' b = do
>   showFlag b
>   casualties <- launchMissiles
>   casualties' <- doNotLaunch
>   if b
> then return casualties
> else return casualties'

If I use ArrowChoice, then I can do this:

> missileControl2 :: Bool -> IO Integer
> missileControl2 b = runKleisli a b
> where a = (Kleisli $ showFlag) >>> (arr boolToEither) >>>
>   ((Kleisli $ const launchMissiles) |||
>(Kleisli $ const doNotLaunch))

> boolToEither :: Bool -> Either () ()
> boolToEither True = Left ()
> boolToEither False = Right ()

GHCi> missileControl2 True
Launch flag = True
Missiles have been launched.
Casualties = 6,700,000,000.
67

GHCi> missileControl2 False
Launch flag = False
Missiles not launched.
0
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] GHC API GSoc project (was: ANN: Haddock version 2.1.0)

[Claus Reinke]

Feel free to CC me or the ticket with things like that.  I'll be
working on this for this year's GSoC and it'd be helpful to find out
what I should tackle first.


Hi Thomas,

thanks, I was wondering about your project. Is there a project
page documenting the issues/tickets you look at, and particularly
the plan of attack as it changes in the face of reality?-) I've found

http://code.google.com/soc/2008/haskell/appinfo.html?csaid=4189AF2C8AE5E25A

which covers a lot of ground, and some interesting issues, but
is so general (and design- rather than application-driven) that I've
been worried about how much of it you'll manage (and with which
priorities), given that the GHC API is indeed exposed rather than
designed and may thus interfere with your good intentions in
unexpected ways.

Also, there are very different user needs out there, some want
just analysis or some information extraction, some want source
transformation capabilities, some want a stable portable hs-plugins
replacement, some want to work with backends, etc. . you can't
please everyone, but until your focus is known, people can't
easily complain about your priorities.

IMHO, trying to support a semantics- and comment-preserving
roundtrip in (pretty . parse) would be a good way to start (David
says he's going to look at the extracting comments/pragmas part,
but they still need to be put back in during pretty printing). It sounds
simple, and if it is, it will enable a lot more usage of the GHC API;
and if it turns out not to be simple, you'll have a first sign of what
you're up against, and can adjust your expectations!-)

Making yourself available as you've done here "I'm here; I'm going
to work on this now; please cc me if you want to express your
priorities" sounds like a good way to pull together the many strands
of interests relating to the GHC API. Now we all have to dust off
our old "wouldn't it be nice if the API could do this and that"s.

Perhaps something similar to what the type family folks are doing
would help: use the ticket tracker for individual issues, have test
cases that demonstrate the issues and their resolution, have more
detailed documents online elsewhere, and a single wiki page to
tie everything together (making it easier to find relevant tickets
and the state of the art).

[cf http://hackage.haskell.org/trac/ghc/wiki/TypeFunctionsStatus ]

over the years, quite a few issues have been raised as tickets/
email/source comments, so collecting them would be a good
way to get an idea of what is needed, deciding which of those
issues would take how much effort would be a first useful
contribution, and seeing which of these you intend to tackle
would give the community at large a better chance to comment
on your priorities in relation to their needs.

I also hope you are in touch with Chaddaï - the port of HaRe
to the GHC API did not make it as a GSoC project, but I
understand he is going to do some work in this direction
anyway.

Looking forward to an improved GHC API!-)
Claus

ps. here are some first entries for your list, and for other
   interested parties following along (I'd be very interested
   to hear about your progress):

- http://code.google.com/soc/2008/haskell/appinfo.html?csaid=4189AF2C8AE5E25A
   (project outline)

- http://hackage.haskell.org/trac/ghc/ticket/1467
   (GHC API: expose separate compilation stages;
   your main ticket so far?)

- concerning exposed phases, it would also be useful if
   the interface was more uniform (eg., AST, typed AST,..)

- search for NOTE in ghc/compiler/main/GHC.hs for some
   related notes from an earlier GHC/HaRe meeting

- is it possible to use standalone deriving to get a generic
   programming framework over the ASTs without blowing
   up GHC's code for its own use (deriving Data, etc.)?

- http://www.haskell.org/pipermail/haskell-cafe/2008-May/042616.html
   (GHC API: how to get the typechecked AST?)

- http://hackage.haskell.org/trac/ghc/ticket/1886
   (GHC API should preserve and provide access to comments)

- dynamic loading of Haskell code, ala hs-plugins, but without
   the version/platform issues (GHCi has to be able to do this
   anyway, but it would be nice to have the ugly bits hidden,
   such as unsafeCast#, or whatever it was). that might require
   a standard for typeReps, if I recall correctly..

- is there a way to reduce version-skew for clients of the GHC
   API (currently, there is no stability guaranteed at all, so if you
   don't want to live with lots of #ifdefs and breakage, you keep
   delaying your fantastic GHC API-base projects "until the dust
   settles")

- I'm sure there have been many more, but that's the problem:
   not all these issues have been collected as they were raised;
   even if you don't tackle all of them, it would be nice if you
   could collect all of them


On Fri, May 9, 2008 at 8:30 PM, Claus Reinke <[EMAIL PROTECTED]> wrote:



> Ah, I didn't think about the GHC options that change the lexical
> syntax. You're right, usin

Re: [Haskell-cafe] FFI: newbie linking problem

[Bulat Ziganshin]

Hello Olivier,

Thursday, May 15, 2008, 1:26:28 AM, you wrote:

>     RFC_RC _stdcall RfcUTF8ToSAPUC(const RFC_BYTE *utf8, unsigned 
> utf8Length,  SAP_UC *sapuc,
>   unsigned *sapucSize, unsigned *resultLength, RFC_ERROR_INFO *info)

>     foreign import ccall unsafe "sapnwrfc.h RfcUTF8ToSAPUC"
>       f_RfcUTF8ToSAPUC :: RfcBytePtr -> CUInt -> SapUCPtr -> Ptr

use stdcall instead of ccall in Haskell too. afair, depending on
calling conventions, different prefixes/suffixes are used when
translating C function name into assembler (dll) name

-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

Re: [Haskell-cafe] Copy on read

[Stefan Holdermans]

Dan,

Let me first apologize for this late reply.

Neil pointed you to


Jurriaan Hage and Stefan Holdermans. Heap recycling for lazy
languages. In John Hatcliff, Robert Glück, and Oege de Moor, editors,
_Proceedings of the 2008 ACM SIGPLAN Symposium on Partial Evaluation
and Semantics-Based Program Manipulation_, PEPM'08, San Francisco,
California, USA, January 7--8, 2008, pages 189--197. ACM Press, 2008.
http://doi.acm.org/10.1145/1328408.1328436.


and you commented:


If I'm reading it aright, it works by tagging the types of values as
unique or not but keeps that annotation secret from the programmer.
The typing rules are incredibly complicated so to make things less
scary, they are also hidden from the user. As a result, this idea
makes it impossible for a developer to reason about whether their code
will compile. That doesn't seem like a viable solution. Have I read
this correctly?


Well, let me first out point out that the paper by no means describes  
a complete solution. When we wrote it, we were mainly interested in  
the static semantics of pure nonstrict functional languages featuring  
a means to perform in-place updates explicitly. We use uniqueness  
types to ensure that such updates are safe, i.e., do not violate  
referential transparency, so that we can keep on enjoying the benefits  
of purity---equational reasoning being the most obvious example of  
such benefits.


Our choice for denoting in-place updates in the source program  
explicitly is a very conscious one. Of course, having opportunities  
for in-place updates inferred by the compiler is highly desirable, but  
there's always a chance that the compiler does not find all the  
locations in the source program in which an update can be inserted. A  
programmer, having specific knowledge of the behaviour of the program  
and the opportunities for in-place updates that arise, may then expect  
updates to be inserted only to find out, when profiling the memory  
behaviour of the program, that certain updates where not inferred.  
What to do then? Restructuring the program, hoping that the  
optimization can be found if some pieces of code are altered, seems  
particularly undesirable; we then rather insert the updates by hand.  
Thus, explicit updates, at the very least, can be a valuable addition  
to a system that tries to infer updates automatically.


As of now, the material in the paper is merely an exercise in static  
semantics: we have not implemented the system in a full-scale  
compiler. But to do so, ranks high on our wish list. Maybe it makes an  
interesting student project. By all means, we would like to get our  
hands on a mature set of benchmark results.


As mentioned in the paper, the viability of a system of explicit  
updates may well depend on the particularities of the underlying  
memory model. This may further complicate the semantics and, worse,  
make the semantics backend-dependent. Note, that backend consideration  
also play a role in a system in which all updates are implicit, i.e,  
inferred. The Clean language, for example, features uniqueness typing  
as a means to deal with side-effects in general and the Clean compiler  
uses uniqueness information to insert in-place updates of memory  
cells. Opportunities for in-place updates, however, do not solely  
depend on the uniqueness of values but, indeed, also on the details of  
the backend involved as illustrated by a recent thread on the Clean  
Discussions mailing list:


  http://mailman.science.ru.nl/pipermail/clean-list/2008/003794.html

(in particular: http://mailman.science.ru.nl/pipermail/clean-list/2008/003795.html) 
.


With regard to your concerns: in a system with explicit updates  
there's always a chance that a programmer uses updates in an unsafe  
fashion, i.e., in such a way that referential transparency can no  
longer be guaranteed. Simply issuing a type-error message that  
involves richly annotates types may be a bit harsh then as these types  
tend to grow rather complex. We do not as much suggest to hide these  
types from the programmer altogether, but we think it's at the very  
least useful to come up with an error message that does a good job  
explaining what went wrong. (What comes to mind almost immediately is  
the PhD work of Bastiaan Heeren: http://people.cs.uu.nl/bastiaan/phdthesis/.) 
 An interesting point here is that there are always at least two  
program points that are "to blame" here: the location of the actual  
explicit update and the point (or points) at the which the flow of the  
value to update may fork.


So, in short: as far as we are concerned, there's no definite story on  
this subject yet. For those attending Fun in the Afternoon tomorrow at  
the University of Herfordshire: Jur will give a talk about this  
material, roughly based on the stuff we presented at PEPM in January.


Then, Malcolm remarked:

Uniqueness typing does not lead to in-place update.  If a value is  
only used once, then the

[Haskell-cafe] FFI: newbie linking problem

[Olivier Boudry]

Hi all,

I'm trying to call the following C function.

RFC_RC _stdcall RfcUTF8ToSAPUC(const RFC_BYTE *utf8, unsigned
utf8Length,  SAP_UC *sapuc,
  unsigned *sapucSize, unsigned *resultLength, RFC_ERROR_INFO *info)

I wrote a foreign import for this function:

foreign import ccall unsafe "sapnwrfc.h RfcUTF8ToSAPUC"
  f_RfcUTF8ToSAPUC :: RfcBytePtr -> CUInt -> SapUCPtr -> Ptr CUInt ->
Ptr CUInt -> RfcErrorInfoPtr -> IO RfcRetCodeType

But when compiling I keep getting this error:

C:\Temp\Haskell\HSAP>ghc --make -LC:/Temp/nwrfcsdk/lib -lsapnwrfc
SAP/Types.hs Test.hs
[1 of 2] Compiling SAP.Types( SAP/Types.hs, SAP/Types.o )
Linking Test.exe ...
SAP/Types.o(.text+0x91c):fake: undefined reference to [EMAIL PROTECTED]'
collect2: ld returned 1 exit status

I ran nm.exe on the sapnwrfc.lib to see the exports and got this list:

SAPNWRFC.dll:
 I .idata$4
 I .idata$5
 I .idata$6
 T .text
 T [EMAIL PROTECTED]
 U __IMPORT_DESCRIPTOR_SAPNWRFC
 I [EMAIL PROTECTED]

It looks like [EMAIL PROTECTED] exists. I tried prepending a _ but it
doesn't change anything.

GHC tries to link directly to the .dll file and not to the .lib file. Is
this a problem? Should I convert the .lib to a .a and link the .a?

Is there a way to list the exports directly from the dll file?

Thanks,

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

Re: [Haskell-cafe] Data.Dynamic over the wire

[Gökhan San]

Hi,

> {-# LANGUAGE ExistentialQuantification, ScopedTypeVariables #-}

Following the related discussion on #haskell, I ended up writing the below
code (thanks to the suggestions). This is for a genetic programming 
library, but the usage would be similar. It also (de)serializes
TypeRep.

I'm a haskell newbie, so feel free to report any awkwardness. :-)

> module Main (main) where

> import Data.Typeable

Dyn holds either the data or the serialized version of it.
This is for performance reasons. Local functions will return 'D x' 
values, deserializing any 'S t s' they encounter in the process. 
When Dyn is shown and read (transmitted?), it becomes a string again.

Function names can be stored in the string version, and a lookup table
could be used to map to actual functions.

> data Dyn = forall a. (Typeable a, Show a) => D a | S TypeRep String

> dynTypeRep :: Dyn -> TypeRep
> dynTypeRep (D x)   = typeOf x
> dynTypeRep (S t _) = t

> fromDyn :: forall a. (Typeable a, Read a) => Dyn -> Maybe a
> fromDyn (D x)   = cast x
> fromDyn (S t s) = if typeOf (undefined :: a) == t 
>   then Just (read s)
>   else Nothing

The above version would be more useful, but 'S t s' can't be cast
into a type other than the one represented by t. (We don't need this
anyway.)

> fromDyn' :: (Typeable a, Read a) => Dyn -> a
> fromDyn' (D x)   = case xa of Nothing -> error "Typecast failed!"
>   Just a  -> a
> where xa = cast x
> fromDyn' (S t s) = read s

Rep is the intermediate type used while (de)serializing Typeable. I couldn't
think of a way for reading TypeRep with the current implementation of show.

> newtype Rep = R (String, [Rep]) deriving (Read, Show)

> toRep   :: TypeRep -> Rep
> toRep t = R (show con, map toRep args)
>   where (con, args) = splitTyConApp t

> fromRep :: Rep -> TypeRep
> fromRep (R (con, args)) = mkTyConApp (mkTyCon con) $ map fromRep args

> instance Show Dyn where
> show (D x)   = show (toRep (typeOf x), show x)
> show (S t s) = show (toRep t, s)

> instance Read Dyn where
> readsPrec d= (map toS) . rP
> where toS ((rep, str), s') = (S (fromRep rep) str, s')
>   rP   = (readsPrec d) :: ReadS (Rep, String)

Below are some examples. I'm looking for a practical way to define functions
that work over several types more easily. The functionality should be like
type classes for runtime.

> add5 :: Dyn -> Dyn
> add5 dx | dynTypeRep dx == typeOf (undefined :: Int) =
> D (fromDyn' dx + 5 :: Int)
> | dynTypeRep dx == typeOf (undefined :: Double) =
> D (fromDyn' dx + 5 :: Double)

> main :: IO ()
> main = do 
>   let dd = D ([(1 :: Int, "test")])
>   ds = (read $ show dd) :: Dyn
>   di = D (2 :: Int)
>   df = D (2 :: Double)
>   daf = add5 df
>   dai = add5 di
>   print dd
>   print ds -- Should be identical
>   print (daf, dynTypeRep daf) -- 7.0
>   print (dai, dynTypeRep dai) -- 7


On Tuesday May 13 2008, Jules Bean wrote:
> You can't finish it off because you can't derive a 'Read' instance for
> SD, because there is no read instance for TypeRep. Off-hand I can't

-- 

Gokhan San
[EMAIL PROTECTED]
http://www.stillpsycho.net

... Real programs don't eat cache.


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] Re: Endianess

[Claus Reinke]

It's not that simple with bits.  They lack consistency just like the
usual US date format and the way Germans read numbers.


So you claim that you pronounce 14 tenty-four? In German pronunciation
is completely uniform from 13 to 99.


http://www.verein-zwanzigeins.de/


So I've always wondered, if you are writing down a number being dictated 
(slowly) by someone else, like 234, do you write the 2, then leave space 
and write the 4, then go back and fill in with 3? Or do you push the 4 
onto the stack until the 3 arrives, and write 34 at once.


Germans have no problems with sentences which though started at
the beginning when observed closely and in the light of day (none of
which adds anything to the content of the sentence in which the very
parenthetical remark you -dear reader- are reading at this very moment
while wondering whether the writer -dear me- is ever going to reach
his point -if, in fact, there is a point (of which one cannot always be
entirely sure until one has stored and processed the whole construct
from beginning to end and thought it over carefully at least once more
because who knows, sense appears here and there, now and then,
to this one and that one, and how are you, Mr. Wilson?

If the latter, does this imply that Germans have a harder time with tail 
recursion?


you mean as in returning from a different context than the one
we decended into? we'd never do such a thing, honestly!-)

then again, Jane Austen was happy enough writing about her
characters not being "one and twenty", so perhaps that is just a
lost art?-)

claus


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

[Haskell-cafe] Re: Endianess

[Achim Schneider]

Henning Thielemann <[EMAIL PROTECTED]> wrote:

> Of course, we write down 243, realize the mistake and rewrite the
> number. :-) Actually, many pupils have problems with the mixed order
> of digits and give solutions like this one in examinations:
>8 * 8 = 46
>   because they write the digits as they speak them. That's one of the 
> reasons the mentioned assocation was founded for.
>
Funny enough you never hear stories about pupils writing

7 + 7 = 41

-- 
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthorised copying,
hiring, renting, public performance and/or broadcasting of this
signature prohibited. 

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

Re[2]: [Haskell-cafe] Fun with Darcs

[Bulat Ziganshin]

Hello Andrew,

Thursday, May 15, 2008, 12:49:32 AM, you wrote:

> touch. Now, let's see what this IDE actually looks li-- oh you have GOT
> to be KIDDING me! It can't find the right GTK DLL?!?

gtk2hs includes *developer* gtk2 environment. while it should work
fine (as far as it's in your path), you may try to install *runtime*
gtk2 environment from
http://sourceforge.net/project/showfiles.php?group_id=71914&package_id=255391


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

Re: [Haskell-cafe] Fun with Darcs

[Andrew Coppin]

David Roundy wrote:

On Wed, May 14, 2008 at 08:37:53PM +0100, Andrew Coppin wrote:
  

Andrew Coppin wrote:

I've recently reinstalled Windows, so I decided to go download the 
latest Darcs and set that up. Now it's complaining that I don't have 
curl or wget. (Never used to do that before.) The WindowsConfiguration 
file doesn't mention anything about it. [And the link back to the Darcs 
wiki is 404 by the way. "darcs.net" rather than "wiki.darcs.net". Nice 
touch...] Presumably this change is new in Darcs 2. I don't recall 
seeing anything about it when I read the announcement, and I'm now 
searching the wiki and I still don't see anything about it.


Presumably I just need to discover a Windows binary for wget and put it 
in my search path somewhere? Would be nice if this were documented... 
Darcs used to just work by itself without any additional tools.



It's just that the guy who built the windows binary didn't have libcurl
installed.  Since there don't seem to be many windows developers, we have
to live with those few people willing to compile darcs on windows...
  


Well, it seems that simply adding wget.exe to my search path did in fact 
fix the issue. It hasn't hard to find with Google, but a small note to 
that effect somewhere in the documentation would be quite nice.


Seriously, you have literally *no idea* how much trouble I've just had 
trying to achieve the simple task of getting Leksah to work. Every 
imaginable thing has gone wrong. Each impediment is fairly trivial in 
itself, but the sheer volume of them is... straining my patience!


- Darcs now needs wget in order to work. [Easy to fix once you work out 
how.]
- Leksah needs Gtk2hs, but I have GHC 6.8.2. [Thank the Maker for gname 
- I've have never found the URL for the unofficial Gtk2hs build to fix 
this!]
- Leksah needs something called "binary". [Once you figure out that 
that's a package and you're supposed to get it from Hackage, it's quite 
easy to find. Figuring out what to do with a tarball on Windows isn't 
that amusing. However, for once, Cabal did actually build and install it 
without issue.]
- When I try to install Leksah, it complains that a PNG file doesn't 
exist. [My guess is the author's Darcs repo contains it, but they forgot 
to tell Darcs.] So I _manually edit_ the Cabal file. [Eeek!] Obviously 
Cabal now makes me reconfigure and rebuild, but the program now installs 
just fine.
- Gee, now I wonder *where* exactly Cabal installed it? Oh well, it 
seems to have put the binary in my search path anyway - that's a nice 
touch. Now, let's see what this IDE actually looks li-- oh you have GOT 
to be KIDDING me! It can't find the right GTK DLL?!?


By now, I've been trying to "try out Leksah" for about an hour. As you 
can see, each problem is pretty small [although the "manually edit Cabal 
file" bit was scary]. However, add together enough small problems and 
you end up with a very frustrating experience. When it takes you 10 
minutes or so to fix each problem, 6 small problems = 1 hour of your 
life. It adds up rather fast. :-(


At this point, my best guess is that the unofficial Gtk2hs binary is 
broken somehow. [Although I don't recall hearing anybody yelling about 
it...] Maybe tomorrow I'll try again on my other box that has an older 
GHC on it and see how that goes. For tonight, I'm just too frustrated to 
continue.


[I hope nobody takes my frustration *too* seriously. I'm just a little 
bit exasperated right now. I'll get over it. By tomorrow, this will 
probably seem very amusing... but right now it's quite late, and I'm 
sleepy.]


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

Re: [Haskell-cafe] Fun with Darcs

[David Roundy]

On Wed, May 14, 2008 at 08:37:53PM +0100, Andrew Coppin wrote:
> Andrew Coppin wrote:
> >Henning Thielemann wrote:
> >>
> >>As said, the IDE Leksah can display code exactly like this ...
> >>
> >
> >I noticed the first time. Clearly this is another toy I'm going to 
> >have to try out sometime...
> 
> ...and then he discovers that Darcs isn't working any more. :-(
> 
> I've recently reinstalled Windows, so I decided to go download the 
> latest Darcs and set that up. Now it's complaining that I don't have 
> curl or wget. (Never used to do that before.) The WindowsConfiguration 
> file doesn't mention anything about it. [And the link back to the Darcs 
> wiki is 404 by the way. "darcs.net" rather than "wiki.darcs.net". Nice 
> touch...] Presumably this change is new in Darcs 2. I don't recall 
> seeing anything about it when I read the announcement, and I'm now 
> searching the wiki and I still don't see anything about it.
> 
> Presumably I just need to discover a Windows binary for wget and put it 
> in my search path somewhere? Would be nice if this were documented... 
> Darcs used to just work by itself without any additional tools.

It's just that the guy who built the windows binary didn't have libcurl
installed.  Since there don't seem to be many windows developers, we have
to live with those few people willing to compile darcs on windows...

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

Re: [Haskell-cafe] Short circuiting and the Maybe monad

[Dan Piponi]

On Wed, May 14, 2008 at 12:03 PM, Andrew Coppin
<[EMAIL PROTECTED]> wrote:

> "It is well-known that trees with substitution form a monad."

Now that's funny. Compare with the first line of this paper:
http://citeseer.ist.psu.edu/510658.html

Anyway, I worked through an elementary example of this with usable
source code here:
http://sigfpe.blogspot.com/2006/11/variable-substitution-gives.html
--
Dan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Richer (than ascii) notation for haskell source?

[Brandon S. Allbery KF8NH]

On 2008 May 14, at 15:00, Andrew Coppin wrote:

Brandon S. Allbery KF8NH wrote:


On 2008 May 14, at 14:32, Andrew Coppin wrote:
Personally, I'd just like to be able to get rid of "->", "\" and  
other such hacks. Would it be possible to amend GHC so that it  
accepts "->" and [whatever the Unicode codepoint for "left arrow"  
is] and treats both the same?


Both of those are already there, along with some others.  It's been  
discussed here but I can't find it in the 6.8.2 manual  (boo,  
hiss)  -XUnicodeSyntax


Mmm, I can see I'm going to have to test this... [That is, just as  
soon as I figure out how to even type in obscure Unicode symbols...]



And, for future reference:


#if __GLASGOW_HASKELL__ >= 605
   ,("?\x88?",   ITdcolon, unicodeSyntaxEnabled)
   ,("?\x87\x92",   ITdarrow, unicodeSyntaxEnabled)
   ,("?\x88\x80",   ITforall, \i -> unicodeSyntaxEnabled i &&
explicitForallEnabled i)
   ,("?\x86\x92",   ITrarrow, unicodeSyntaxEnabled)
   ,("?\x86\x90",   ITlarrow, unicodeSyntaxEnabled)
   ,("?\x8b?",   ITdotdot, unicodeSyntaxEnabled)
-- ToDo: ideally, ?\x86\x92 and ?\x88? should be "specials",  
so that the

y cannot
-- form part of a large operator.  This would let us have a  
better
-- syntax for kinds: ?\x91?\x88?*?\x86\x92* would be a legal  
kind signat

ure. (maybe).
#endif


So ∷, ⇒, ∀, →, ←, ‥ currently supported.  Others clearly  
could be, but probably not as built-in syntax (Prelude.Unicode: let ×  
= *, anyone?).


--
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

[Haskell-cafe] Fun with Darcs

[Andrew Coppin]

Andrew Coppin wrote:

Henning Thielemann wrote:


As said, the IDE Leksah can display code exactly like this ...



I noticed the first time. Clearly this is another toy I'm going to 
have to try out sometime...


...and then he discovers that Darcs isn't working any more. :-(

I've recently reinstalled Windows, so I decided to go download the 
latest Darcs and set that up. Now it's complaining that I don't have 
curl or wget. (Never used to do that before.) The WindowsConfiguration 
file doesn't mention anything about it. [And the link back to the Darcs 
wiki is 404 by the way. "darcs.net" rather than "wiki.darcs.net". Nice 
touch...] Presumably this change is new in Darcs 2. I don't recall 
seeing anything about it when I read the announcement, and I'm now 
searching the wiki and I still don't see anything about it.


Presumably I just need to discover a Windows binary for wget and put it 
in my search path somewhere? Would be nice if this were documented... 
Darcs used to just work by itself without any additional tools.


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

Re: [Haskell-cafe] Richer (than ascii) notation for haskell source?

[Brandon S. Allbery KF8NH]

On 2008 May 14, at 15:00, Andrew Coppin wrote:


Brandon S. Allbery KF8NH wrote:


On 2008 May 14, at 14:32, Andrew Coppin wrote:

Personally, I'd just like to be able to get rid of "->", "\" and  
other such hacks. Would it be possible to amend GHC so that it  
accepts "->" and [whatever the Unicode codepoint for "left arrow"  
is] and treats both the same?


Both of those are already there, along with some others.  It's been  
discussed here but I can't find it in the 6.8.2 manual  (boo,  
hiss)  -XUnicodeSyntax



Mmm, I can see I'm going to have to test this... [That is, just as  
soon as I figure out how to even type in obscure Unicode symbols...]



Unfortunately, while I thought there was a distinct lambda sign that  
wasn't the lowercase Greek letter, there isn't.  (That said, I don't  
see why it couldn't be a keyword.  You'd need a space after it.)


--
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] Using Template Haskell to make type-safe database access

[Mads Lindstrøm]

Hi

Bjorn Bringert wrote:

> Mads: Preparing the statement and asking the DB about the type at
> compile is a great idea! I've never thought of that. Please consider
> completing this and packaging it as a library.

Thanks for the nice remark. And I will begin completing the idea, as
soon I have packaged up and wrote a little tutorial about my other
project (SybWidget). I already started that about three weeks ago, so it
should be finished soon. 


Greetings,

Mads Lindstrøm



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

Re: [Haskell-cafe] Richer (than ascii) notation for haskell source?

[Andrew Coppin]

Henning Thielemann wrote:


On Wed, 14 May 2008, Andrew Coppin wrote:

Personally, I'd just like to be able to get rid of "->", "\" and 
other such hacks. Would it be possible to amend GHC so that it 
accepts "->" and [whatever the Unicode codepoint for "left arrow" is] 
and treats both the same?


As said, the IDE Leksah can display code exactly like this ...



I noticed the first time. Clearly this is another toy I'm going to have 
to try out sometime...


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

Re: [Haskell-cafe] Short circuiting and the Maybe monad

[Andrew Coppin]

Janis Voigtlaender wrote:

http://wwwtcs.inf.tu-dresden.de/~voigt/mpc08.pdf


"It is well-known that trees with substitution form a monad."

...OK, I just learned something new. Hanging around Haskell Cafe can be 
so illuminating! :-)


Now, if only I could actually comprehend the rest of the paper... o_O

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

Re: [Haskell-cafe] Richer (than ascii) notation for haskell source?

[Henning Thielemann]

On Wed, 14 May 2008, Andrew Coppin wrote:

Personally, I'd just like to be able to get rid of "->", "\" and other such 
hacks. Would it be possible to amend GHC so that it accepts "->" and 
[whatever the Unicode codepoint for "left arrow" is] and treats both the 
same?


As said, the IDE Leksah can display code exactly like this ...
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Richer (than ascii) notation for haskell source?

[Andrew Coppin]

Brandon S. Allbery KF8NH wrote:


On 2008 May 14, at 14:32, Andrew Coppin wrote:

Personally, I'd just like to be able to get rid of "->", "\" and 
other such hacks. Would it be possible to amend GHC so that it 
accepts "->" and [whatever the Unicode codepoint for "left arrow" is] 
and treats both the same?



Both of those are already there, along with some others.  It's been 
discussed here but I can't find it in the 6.8.2 manual  (boo, 
hiss)  -XUnicodeSyntax



Mmm, I can see I'm going to have to test this... [That is, just as soon 
as I figure out how to even type in obscure Unicode symbols...]


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

Re: [Haskell-cafe] Re: Endianess

[Henning Thielemann]

On Wed, 14 May 2008, Brandon S. Allbery KF8NH wrote:



On 2008 May 14, at 14:34, Dan Weston wrote:

So I've always wondered, if you are writing down a number being dictated 
(slowly) by someone else, like 234, do you write the 2, then leave space 
and write the 4, then go back and fill in with 3? Or do you push the 4 onto 
the stack until the 3 arrives, and write 34 at once.


If the latter, does this imply that Germans have a harder time with tail 
recursion?



Stacking, surely:  recall the joke about the German professor who saved all 
his verbs for the end of the lecture.  :)


Interesting to know what jokes are told about Germans. 8-] So, do English 
professors save their prepositions for the end of a lecture?

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

[Haskell-cafe] Re: Endianess

[Henning Thielemann]

On Wed, 14 May 2008, Dan Weston wrote:


Henning Thielemann wrote:


http://www.verein-zwanzigeins.de/


So I've always wondered, if you are writing down a number being dictated 
(slowly) by someone else, like 234, do you write the 2, then leave space and 
write the 4, then go back and fill in with 3? Or do you push the 4 onto the 
stack until the 3 arrives, and write 34 at once.


Of course, we write down 243, realize the mistake and rewrite the number. 
:-) Actually, many pupils have problems with the mixed order of digits and 
give solutions like this one in examinations:

  8 * 8 = 46
 because they write the digits as they speak them. That's one of the 
reasons the mentioned assocation was founded for.

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

Re: [Haskell-cafe] Two-iteration optimisation (was: GHC Predictability)

[Andrew Coppin]

Albert Y. C. Lai wrote:
If you worry that the sum thread and the length thread are not 
synchronized and therefore there is still no bound on the list prefix 
kept in memory, I'm sure you can improve it by one of the chunking 
strategies.


I'm more worried that data now has to go through tiny CPU <--> RAM 
busses rather than zipping along at the CPU's core frequency as it would 
if only 1 CPU were involved. I would think the cache issues make the 
sequential version a fair bit faster. (Not to mention that no GC is 
required.)


As our hardware grows more cores but not more gigahertz, it may become 
detrimal to fuse. Fusion implies entangling, an anti-thesis to 
parallelism. One day we may call this an optimisation: unfuse code 
hand-fused by programmers, then parallelize. Optimisation people on 
the imperative side are already doing this (they have more hand-fused 
code than we do), though targetting at older hardware like vector 
machines and SIMD, not yet multiple cores.


The key to parallel processing is splitting a task into *independent* 
tasks so you can do them in parallel. If they're still interdependent 
[like the above], I suspect you're not gaining much.


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

Re: [Haskell-cafe] Richer (than ascii) notation for haskell source?

[Andrew Coppin]

Reinier Lamers wrote:


Op 14-mei-2008, om 20:32 heeft Andrew Coppin het volgende geschreven:
Personally, I'd just like to be able to get rid of "->", "\" and 
other such hacks. Would it be possible to amend GHC so that it 
accepts "->" and [whatever the Unicode codepoint for "left arrow" is] 
and treats both the same?
I believe GHC already accepts "∀" instead of "forall", and some other 
Unicode neatness. However, you can't use "λ" for "\" because "λ" is a 
lowercase letter and thus valid in identifiers. So getting rid of "\" 
might be impossible even with Unicode.


Ooo... well spotted on that subtly edge case with lambda... Damn, that's 
just too bad. Using a backslash makes it look like a character escape or 
something. It's really quite ugly...


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

Re: [Haskell-cafe] Two-iteration optimisation (was: GHC Predictability)

[Albert Y. C. Lai]

Paul Johnson wrote:
The solution is for the programmer to rewrite "mean" to accumulate a 
pair containing the running total and count together, then do the 
division.  This makes me wonder: could there be a compiler optimisation 
rule for this, collapsing two iterations over a list into one.


Do not forget:

http://www.haskell.org/tmrwiki/WhyAttributeGrammarsMatter

Though not a compiler optimisation, it's a thinker optimisation.


I have another thought. It is now time to investigate the viability of

mean x = s `par` l `par` (s/l) where
  s = sum x
  l = length x

If you worry that the sum thread and the length thread are not 
synchronized and therefore there is still no bound on the list prefix 
kept in memory, I'm sure you can improve it by one of the chunking 
strategies.


As our hardware grows more cores but not more gigahertz, it may become 
detrimal to fuse. Fusion implies entangling, an anti-thesis to 
parallelism. One day we may call this an optimisation: unfuse code 
hand-fused by programmers, then parallelize. Optimisation people on the 
imperative side are already doing this (they have more hand-fused code 
than we do), though targetting at older hardware like vector machines 
and SIMD, not yet multiple cores.

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

Re: [Haskell-cafe] Re: Endianess

[Brandon S. Allbery KF8NH]

On 2008 May 14, at 14:34, Dan Weston wrote:

So I've always wondered, if you are writing down a number being  
dictated (slowly) by someone else, like 234, do you write the 2,  
then leave space and write the 4, then go back and fill in with 3?  
Or do you push the 4 onto the stack until the 3 arrives, and write  
34 at once.


If the latter, does this imply that Germans have a harder time with  
tail recursion?



Stacking, surely:  recall the joke about the German professor who  
saved all his verbs for the end of the lecture.  :)


--
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] Richer (than ascii) notation for haskell source?

[Brandon S. Allbery KF8NH]

On 2008 May 14, at 14:32, Andrew Coppin wrote:

Personally, I'd just like to be able to get rid of "->", "\" and  
other such hacks. Would it be possible to amend GHC so that it  
accepts "->" and [whatever the Unicode codepoint for "left arrow"  
is] and treats both the same?



Both of those are already there, along with some others.  It's been  
discussed here but I can't find it in the 6.8.2 manual  (boo,  
hiss)  -XUnicodeSyntax


--
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] Two-iteration optimisation

[Andrew Coppin]

Don Stewart wrote:

You'd want a general fusion framework for this, and other accumulators,
that's let's you treat 'f' as a zip of some kind that pulls items from
its two arguments. And then require only a single rewrite rule for all
your loop forms.

Stream fusion (see "Lists to Streams to Nothing at All") at least does this for 
zips,

zip (foldl .. )
(foldl .. )

Will end up with a single loop, but for an arbitrary 'f' instead of zip,
seems harder.
  


It seems the thing to do would be to expose a top-level function for 
explicitly specifying that this is what you want to do:


 foo :: (x' -> y' -> z') -> ([x] -> x') -> ([y] -> y') -> [x] -> [y] -> z'

You could then say

 mean xs = foo (/) sum length

which is pretty declarative, and gives the compiler an easy time with 
optimising.


Of course, if nobody chooses to *use* this function... it won't help you 
any.


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

Re: [Haskell-cafe] Re: Endianess

[Dan Weston]

Henning Thielemann wrote:


On Tue, 13 May 2008, Achim Schneider wrote:


Jed Brown <[EMAIL PROTECTED]> wrote:


It's not that simple with bits.  They lack consistency just like the
usual US date format and the way Germans read numbers.


So you claim that you pronounce 14 tenty-four? In German pronunciation
is completely uniform from 13 to 99.


http://www.verein-zwanzigeins.de/


So I've always wondered, if you are writing down a number being dictated 
(slowly) by someone else, like 234, do you write the 2, then leave space 
and write the 4, then go back and fill in with 3? Or do you push the 4 
onto the stack until the 3 arrives, and write 34 at once.


If the latter, does this imply that Germans have a harder time with tail 
recursion?


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

Re: [Haskell-cafe] Richer (than ascii) notation for haskell source?

[Andrew Coppin]

Patrick Surry wrote:


Probably a silly question, but for me one of the nice things about 
Haskell is that it's a lot like just writing math(s). But in contrast 
to math you lose a lot of notational flexibility being limited to the 
ascii character set in your source code.


It would be nice to be able to use a richer set of symbols in your 
source code for operators and functions (e.g. integral, sum, dot and 
cross-product, …), as well as variables (the standard upper and 
lower-case greek for example, along with things like super- and 
sub-scripting, bold/italic and what-not). You could imagine ending up 
with source code that reads just like a mathematical paper.


Don't know how I'd actually then write/maintain the source-code - some 
WYSIWYG editor or effectively writing it in '(la)tex'? Maybe that's 
what Knuth is on about with his 'literate programming' weave/tangle 
stuff which I don't know much about - does that translate to Haskell?




Personally, I'd just like to be able to get rid of "->", "\" and other 
such hacks. Would it be possible to amend GHC so that it accepts "->" 
and [whatever the Unicode codepoint for "left arrow" is] and treats both 
the same?


IIRC, GHC already accepts Unicode input. I seem to recall some people 
debating what to do about languages that don't have a concept of 
"uppercase" and "lowercase" - the Haskell language critically hinges on 
that distinction. But then, if you wanted to write your Haskell programs 
in arabic or something, I would think the fact that all the language 
keywords and every library ever written are in English, so...


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

Re: [Haskell-cafe] Re: GHC predictability

[Brandon S. Allbery KF8NH]

On 2008 May 14, at 14:23, Andrew Coppin wrote:


Neil Mitchell wrote:


1. What is "ghc-core"?


You actually answer this question as part of question 2. Think of it
as simple Haskell with some additional bits.


I rephrase: I know what GHC's Core language is. But Dons said "I  
suggest you install ghc-core", which suggests the existence of an  
item of software named "ghc-core". This I know nothing about...


Any time someone mentions something that sounds like a Haskell  
package, http://hackage.haskell.org is your friend.


And there I find, in the Development category:


ghc-core program: Display GHC's core and assembly output in a pager



IIRC it's just a prettyprinter/colorizer to make it easier to follow  
and understand GHC Core.


--
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] Re: GHC predictability

[Andrew Coppin]

Richard A. O'Keefe wrote:


On 14 May 2008, at 8:58 am, Andrew Coppin wrote:
What I'm trying to say [and saying very badly] is that Haskell is an 
almost terrifyingly subtle language.


Name me a useful programming language that isn't.
Simply interchanging two for-loops, from
for (i = 0; i < N; i++) for (j = 0; j < N; j++)
tofor (j = 0; j < N; j++) for (i = 0; i < N; i++)
when marching over an array, can easily slow you down
by nearly two orders of magnitude in C.
[Hint: read "What every computer scientist needs to know
about memory".] 


OK, well *that* is news... :-o

I would suggest that for heap-allocated data that isn't an array, both 
cases will be equally unperformant. I can't prove that though...



"Unexpectedly slow" is better than "inexplicably buggy".


+184   o_O

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

Re: [Haskell-cafe] GHC predictability

[Don Stewart]

andrewcoppin:
> Brandon S. Allbery KF8NH wrote:
> >
> >On 2008 May 13, at 17:01, Andrew Coppin wrote:
> >
> >>That definition of mean is wrong because it traverses the list twice. 
> >>(Curiosity: would traversing it twice in parallel work any better?) 
> >>As for the folds - I always *always* mix up

Yes, using parallelism does work. It turns the naive definition into
one which traverses the list on two cores at the same time, so the
garbage collector does get clean up the list as each core races along
it.

mean ls = count `par` (total/count)
  where count = fromIntegral (length ls)
total = foldl' (+) 0 ls

It is kind of amazing how parallelism and laziness enable the naive
definition to fall out as much the same as the explicitly recursive
version.

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

Re: [Haskell-cafe] Endianess

[Andrew Coppin]

Brandon S. Allbery KF8NH wrote:


On 2008 May 13, at 17:12, Andrew Coppin wrote:


[Oh GOD I hope I didn't just start a Holy War...]



Er, I'd say it's already well in progress.  :/



Oh dear.

Appologies to everybody who doesn't actually _care_ about which endian 
mode their computer uses...


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

Re: [Haskell-cafe] GHC predictability

[Andrew Coppin]

Brandon S. Allbery KF8NH wrote:


On 2008 May 13, at 17:01, Andrew Coppin wrote:

That definition of mean is wrong because it traverses the list twice. 
(Curiosity: would traversing it twice in parallel work any better?) 
As for the folds - I always *always* mix up


It might work "better" but you're still wasting a core that could be 
put to better use doing something more sensible.  It's pretty much 
always best to do all the calculations that require traversing a given 
list in a single traversal.


Yeah, you're probably right there. I mean, with sufficient inlining, 
maybe you would end up with a loop that doesn't even construct any 
heap-allocated list nodes, just adds up the integers as fast as it can 
generate them.


On the other hand, N(N+1)/2N is probably even faster! ;-) So I guess 
it's kinda of a daft example...


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

Re: [Haskell-cafe] Re: GHC predictability

[Andrew Coppin]

Neil Mitchell wrote:

Hi

  

 1. What is "ghc-core"?



You actually answer this question as part of question 2. Think of it
as simple Haskell with some additional bits.
  


I rephrase: I know what GHC's Core language is. But Dons said "I suggest 
you install ghc-core", which suggests the existence of an item of 
software named "ghc-core". This I know nothing about...


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

Re: [Haskell-cafe] Re: GHC predictability

[Andrew Coppin]

Don Stewart wrote:

ndmitchell:
  

 2. Does anybody know how to actually read GHC's Core output anyway?
  

There is one different from standard Haskell I am aware of. In Core,
case x of _ -> 1 will evaluate x, in Haskell it won't. Other than
that, its just Haskell, but without pattern matching and only cases -
hence the rather high number of cases.



Well, 'let's too, which bind either unlifted or lifted values.

If they're binding lifted things, that's a thunk being allocated.
  


See, somebody needs to write all this down - in language comprehensible 
to people who don't already know what an "unlifed value" is. ;-)


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

Re: [Haskell-cafe] Commutative monads vs Applicative functors

[Ronald Guida]

David Menendez wrote:
> To summarize: some applicative functors are commutative, some
> applicative functors are monads, and the ones that are both are
> commutative monads.

OK, so commutativity is orthogonal to "idiom vs monad".  Commutativity
depends on whether or not the order of side effects is important.
Being a monad or just an idiom depends on whether or not "join" is
supported.  Examples can be constructed for all 4 possibilities of
{idiom,  monad} (x) {non-commutative, commutative}.

Thank you all for clearing this up for me.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Two-iteration optimisation (was: GHC Predictability)

[Henning Thielemann]

On Wed, 14 May 2008, Paul Johnson wrote:


We've had a big debate over


mean xs = foldl' (+) 0 xs / fromIntegral (length xs)


For anyone who didn't follow it, the problem is that "mean" needs to traverse 
its argument twice, so the entire list has to be held in memory.  So if "xs = 
[1..10]" then "mean xs" uses all your memory, but "foldl' (+) 0 xs" 
and "length xs" by themselves do not.


I also wondered how to solve that problem. It also occurs in 
implementations of "wc", that is counting lines, words and characters of a 
text in parallel.


The solution is for the programmer to rewrite "mean" to accumulate a pair 
containing the running total and count together, then do the division.  This 
makes me wonder: could there be a compiler optimisation rule for this, 
collapsing two iterations over a list into one.  I've never tried writing GHC 
rules, but something like:



 f (foldl' g x) (foldl' h x) = (uncurry f) (foldl' (\i (gt,ht) -> (g i gt,  h i 
ht)))


The left hand sides of GHC rules must have a definite function as 
top-level construct, whereas 'f' is a variable. You may define a function 
which points the optimizer to the places where something shall be 
replaced. Say


fuseFold :: (a -> b -> c) -> a -> b -> c
fuseFold f x y = f x y

{-# RULES
   forall f g h x y.
  fuseFold f (foldl' g x) (foldl' h x) = ...
  #-}


However, instead of writing library functions which use foldl', it might 
be better to implement and export the accumulating functions separately. 
They can be used with 'foldl's of arbitrary data structures and they can 
be fused explicitly without GHC rules. However, I suspect you cannot 
rewrite say (length (words str)) or (length (lines str)) in that manner in 
an elegant way.



The first problem that occurs to me is the number of permutations of fold and 
map functions.


foldl' could be merged with 'map' to a foldl', however the existing fusion 
frameworks use different primitives, like foldr/build.

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

Re: [Haskell-cafe] Two-iteration optimisation (was: GHC Predictability)

[Don Stewart]

paul:
> We've had a big debate over
> 
> > mean xs = foldl' (+) 0 xs / fromIntegral (length xs)
> 
> For anyone who didn't follow it, the problem is that "mean" needs to 
> traverse its argument twice, so the entire list has to be held in 
> memory.  So if "xs = [1..10]" then "mean xs" uses all your 
> memory, but "foldl' (+) 0 xs" and "length xs" by themselves do not.
> 
> The solution is for the programmer to rewrite "mean" to accumulate a 
> pair containing the running total and count together, then do the 
> division.  This makes me wonder: could there be a compiler optimisation 
> rule for this, collapsing two iterations over a list into one.  I've 
> never tried writing GHC rules, but something like:
> 
> >  f (foldl' g x) (foldl' h x) = (uncurry f) (foldl' (\i (gt,ht) -> (g 
> i gt, h i ht)))
> 
> The first problem that occurs to me is the number of permutations of 
> fold and map functions.

You'd want a general fusion framework for this, and other accumulators,
that's let's you treat 'f' as a zip of some kind that pulls items from
its two arguments. And then require only a single rewrite rule for all
your loop forms.

Stream fusion (see "Lists to Streams to Nothing at All") at least does this for 
zips,

zip (foldl .. )
(foldl .. )

Will end up with a single loop, but for an arbitrary 'f' instead of zip,
seems harder.

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

Re: [Haskell-cafe] Richer (than ascii) notation for haskell source?

[Reinier Lamers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Op 14-mei-2008, om 15:43 heeft Patrick Surry het volgende geschreven:
It would be nice to be able to use a richer set of symbols in your  
source code for operators and functions (e.g. integral, sum, dot  
and cross-product, …),  as well as variables (the standard upper  
and lower-case greek for example, along with things like super- and  
sub-scripting, bold/italic and what-not).  You could imagine ending  
up with source code that reads just like a mathematical paper.


People have already thought about this, and it partly works already  
in GHC. See http://hackage.haskell.org/trac/haskell-prime/wiki/ 
UnicodeInHaskellSource.


I don't like, however, the tendency of many Haskell authors to use  
math-like variable names. There are far to many Haskell programs  
where you rarely find a variable name of more than three letters, and  
all those variables that have more than one letter are English names  
for Greek letters like 'phi' or 'mu'.


It makes a difference for your style whether you are just talking to  
humans (a math paper) or to humans and compilers at the same time (a  
computer program). When talking to a compiler, the compiler is not  
interested in the semantical explanations, so programmers mostly  
leave them out. But when you do that, you must make sure that the  
formal language is still comprehensible to humans - I'd say by using  
descriptive variable names.


Regards,
Reinier

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkgrH04ACgkQR3bgBiWODBfrBQCeLVEIiYDbXdCFJbTI4HZkJr7e
qysAn2M3XDynT/NAINsVaeH23XVre1Kf
=Zv7j
-END PGP SIGNATURE-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Two-iteration optimisation (was: GHC Predictability)

[Paul Johnson]

We've had a big debate over

> mean xs = foldl' (+) 0 xs / fromIntegral (length xs)

For anyone who didn't follow it, the problem is that "mean" needs to 
traverse its argument twice, so the entire list has to be held in 
memory.  So if "xs = [1..10]" then "mean xs" uses all your 
memory, but "foldl' (+) 0 xs" and "length xs" by themselves do not.


The solution is for the programmer to rewrite "mean" to accumulate a 
pair containing the running total and count together, then do the 
division.  This makes me wonder: could there be a compiler optimisation 
rule for this, collapsing two iterations over a list into one.  I've 
never tried writing GHC rules, but something like:


>  f (foldl' g x) (foldl' h x) = (uncurry f) (foldl' (\i (gt,ht) -> (g 
i gt, h i ht)))


The first problem that occurs to me is the number of permutations of 
fold and map functions.


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

Re: [Haskell-cafe] Commutative monads vs Applicative functors

[David Menendez]

On Tue, May 13, 2008 at 9:06 PM, Ronald Guida <[EMAIL PROTECTED]> wrote:
> I have a few questions about commutative monads and applicative functors.
>
>  >From what I have read about applicative functors, they are weaker than
>  monads because with a monad, I can use the results of a computation to
>  select between alternative future computations and their side effects,
>  whereas with an applicative functor, I can only select between the
>  results of computations, while the structure of those computations and
>  their side effects are fixed in advance.
>
>  But then there are commutative monads.  I'm not exactly sure what a
>  commutative monad is, but my understanding is that in a commutative
>  monad the order of side effects does not matter.
>
>  This leads me to wonder, are commutative monads still stronger than
>  applicative functors, or are they equivalent?
>
>  And by the way, what exactly is a commutative monad?

A monad is commutative if the expression "a >>= \x -> b >>= \y -> f x
y" is equivalent to "b >>= \y -> a >>= \x -> f x y". The identity,
state reader, and maybe monads are commutative, for example.

To put it another way, a monad is commutative if

liftM2 f a b = liftM2 (flip f) b a

Since liftA2 generalizes liftM2, we can also say that an applicative
functor is commutative if

liftA2 f a b = liftA2 (flip f) b a

Or, put another way, if

a <*> b = flip ($) <$> b <*> a

If w is a commutative monoid (that is, if mappend w1 w2 == mappend w2
w1), then Const w is a commutative applicative functor.

To summarize: some applicative functors are commutative, some
applicative functors are monads, and the ones that are both are
commutative monads.

-- 
Dave Menendez <[EMAIL PROTECTED]>

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

Re: [Haskell-cafe] Monad for HOAS?

[Conal Elliott]

I share your perspective, Edsko.  If foo and (Let foo id) are
indistinguishable to clients of your module and are equal with respect to
your intended semantics of Exp, then I'd say at least this one monad law
holds.  - Conal

On Wed, May 14, 2008 at 7:59 AM, Edsko de Vries <[EMAIL PROTECTED]> wrote:

> Hi,
>
> On Wed, May 14, 2008 at 03:59:58PM +0300, Lauri Alanko wrote:
> > On Wed, May 14, 2008 at 10:11:17AM +0100, Edsko de Vries wrote:
> > > Suppose we have some data structure that uses HOAS; typically, a DSL
> > > with explicit sharing. For example:
> > >
> > > > data Expr = One | Add Expr Expr | Let Expr (Expr -> Expr)
> > >
> > > When I use such a data structure, I find myself writing expressions
> such
> > > as
> > >
> > > > Let foo $ \a ->
> > > > Let bar $ \b ->
> > > > Add a b
> > >
> > > It seems to me that there should be a monad here somewhere, so that I
> > > can write this approximately like
> > >
> > > do a <- foo
> > >b <- bar
> > > return (Add a b)
> >
> > Neat idea, but the monad can't work exactly as you propose, because
> > it'd break the monad laws: do { a <- foo; return a } should be equal
> > to foo, but in your example it'd result in Let foo id.
> >
> > However, with an explicit binding marker the continuation monad does
> > what you want:
> >
> > import Control.Monad.Cont
> >
> > data Expr = One | Add Expr Expr | Let Expr (Expr -> Expr)
> >
> > type ExprM = Cont Expr
> >
> > bind :: Expr -> ExprM Expr
> > bind e = Cont (Let e)
> >
> > runExprM :: ExprM Expr -> Expr
> > runExprM e = runCont e id
> >
> > Now you'd write your example as
> >
> > do a <- bind foo
> >b <- bind bar
> >return (Add a b)
>
> Nice. That's certainly a step towards what I was looking for, although
> it requires slightly more "tags" than I was hoping for :) But I've
> incorporated it into my code and it's much better already :)
>
> You mention that a "direct" implementation of what I suggested would
> break the monad laws, as (foo) and (Let foo id) are not equal. But one
> might argue that they are in fact, in a sense, equivalent. Do you reckon
> that if it is acceptable that foo and do { a <- foo; return a } don't
> return equal terms (but equivalent terms), we can do still better?
>
> Thanks again,
>
> Edsko
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] printing a list of directories which don't exist

[Daniel Fischer]

Am Mittwoch, 14. Mai 2008 17:47 schrieb Mike Jarmy:
> Newbie question:  Given a list of type '[FilePath]', how do I create a list
> of all those directories which do not actually exist, and then print the
> list?  I've figured out how to extract the ones which *do* exist, like so:
>
> module Main where
>
> import Control.Monad (filterM)
> import System.Directory (doesDirectoryExist)
> import System.Environment (getArgs)
>
> main :: IO ()
> main = do
> dirs <- getArgs
> let existing = filterM doesDirectoryExist dirs
> ..
>
> which gives me a list of type 'IO [FilePath]'.  However, because of the
> 'IO' tag, I cannot figure out how to do any of the following 3 things
> (noted in comments):

What you want is 'fmap' (from the Functor class) or 'liftM' (from the Monad 
class).

bogusDirs <- filterM (fmap not . doesDirectoryExist) dirs

should work, same with liftM in place of fmap.

>
> -- filter via composition
> let bogusDirs = filterM (not . doesDirectoryExist) dirs
>
> -- test for emptiness
> if bogusDirs /= []
>-- print the list
>then putStrLn $ "bogus: " ++ show bogusDirs
>else putStrLn "OK"
>
> Can anyone set me straight?  How do I make the IO tag go away, or am I
> going about this all wrong?  E.g. the 'filterM (not . doesDirectoryExist)
> dirs' expression gives the following compilation error:
>
> ~/code/haskell$ ghc -o newbie newbie.hs
>
> newbie.hs:16:35:
> Couldn't match expected type `Bool' against inferred type `IO Bool'
>   Expected type: FilePath -> Bool
>   Inferred type: FilePath -> IO Bool
> In the second argument of `(.)', namely `doesDirectoryExist'
> In the first argument of `filterM', namely
> `(not . doesDirectoryExist)'

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

Re: [Haskell-cafe] printing a list of directories which don't exist

[Henning Thielemann]

On Wed, 14 May 2008, Mike Jarmy wrote:


Newbie question:  Given a list of type '[FilePath]', how do I create a list
of all those directories which do not actually exist, and then print the
list?  I've figured out how to extract the ones which *do* exist, like so:

module Main where

import Control.Monad (filterM)
import System.Directory (doesDirectoryExist)
import System.Environment (getArgs)

main :: IO ()
main = do
   dirs <- getArgs
   let existing = filterM doesDirectoryExist dirs


should be


   existing <- filterM doesDirectoryExist dirs


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

[Haskell-cafe] printing a list of directories which don't exist

[Mike Jarmy]

Newbie question:  Given a list of type '[FilePath]', how do I create a list
of all those directories which do not actually exist, and then print the
list?  I've figured out how to extract the ones which *do* exist, like so:

module Main where

import Control.Monad (filterM)
import System.Directory (doesDirectoryExist)
import System.Environment (getArgs)

main :: IO ()
main = do
dirs <- getArgs
let existing = filterM doesDirectoryExist dirs
..

which gives me a list of type 'IO [FilePath]'.  However, because of the 'IO'
tag, I cannot figure out how to do any of the following 3 things (noted in
comments):

-- filter via composition
let bogusDirs = filterM (not . doesDirectoryExist) dirs

-- test for emptiness
if bogusDirs /= []
   -- print the list
   then putStrLn $ "bogus: " ++ show bogusDirs
   else putStrLn "OK"

Can anyone set me straight?  How do I make the IO tag go away, or am I going
about this all wrong?  E.g. the 'filterM (not . doesDirectoryExist) dirs'
expression gives the following compilation error:

~/code/haskell$ ghc -o newbie newbie.hs

newbie.hs:16:35:
Couldn't match expected type `Bool' against inferred type `IO Bool'
  Expected type: FilePath -> Bool
  Inferred type: FilePath -> IO Bool
In the second argument of `(.)', namely `doesDirectoryExist'
In the first argument of `filterM', namely
`(not . doesDirectoryExist)'
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Endianess

[Achim Schneider]

Henning Thielemann <[EMAIL PROTECTED]> wrote:

> 
> On Tue, 13 May 2008, Achim Schneider wrote:
> 
> > Jed Brown <[EMAIL PROTECTED]> wrote:
> >
> >> It's not that simple with bits.  They lack consistency just like
> >> the usual US date format and the way Germans read numbers.
> >>
> > So you claim that you pronounce 14 tenty-four? In German
> > pronunciation is completely uniform from 13 to 99.
> 
> http://www.verein-zwanzigeins.de/
>
Dammit! Don't affirm the stereotype that any group of like-minded
Germans forms an association to affirm importance and ultimately
get drowned by the "well I don't care at all" mentality of the rest.

-- 
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthorised copying,
hiring, renting, public performance and/or broadcasting of this
signature prohibited. 

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

Re: [Haskell-cafe] Monad for HOAS?

[Lauri Alanko]

On Wed, May 14, 2008 at 03:59:23PM +0100, Edsko de Vries wrote:
> You mention that a "direct" implementation of what I suggested would
> break the monad laws, as (foo) and (Let foo id) are not equal. But one
> might argue that they are in fact, in a sense, equivalent. Do you reckon
> that if it is acceptable that foo and do { a <- foo; return a } don't
> return equal terms (but equivalent terms), we can do still better?

If you just want the syntactic sugar and don't care about monads, in
GHC you can use plain do-notation:

{-# OPTIONS -fno-implicit-prelude #-}

import Prelude hiding ((>>=), fail)

data Expr = One | Add Expr Expr | Let Expr (Expr -> Expr)

(>>=) = Let

fail = error

t :: Expr
t = do a <- One
   b <- Add a a
   Add b b

That's generally pretty icky, though.


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

Re: [Haskell-cafe] Richer (than ascii) notation for haskell source?

[Henning Thielemann]

On Wed, 14 May 2008, Patrick Surry wrote:


Probably a silly question, but for me one of the nice things about
Haskell is that it's a lot like just writing math(s).  But in contrast
to math you lose a lot of notational flexibility being limited to the
ascii character set in your source code.


Leksah supports visualizing keywords as fancy symbols:
  http://www.leksah.org/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad for HOAS?

[Edsko de Vries]

Hi,

On Wed, May 14, 2008 at 03:59:58PM +0300, Lauri Alanko wrote:
> On Wed, May 14, 2008 at 10:11:17AM +0100, Edsko de Vries wrote:
> > Suppose we have some data structure that uses HOAS; typically, a DSL
> > with explicit sharing. For example:
> > 
> > > data Expr = One | Add Expr Expr | Let Expr (Expr -> Expr)
> > 
> > When I use such a data structure, I find myself writing expressions such
> > as
> > 
> > > Let foo $ \a -> 
> > > Let bar $ \b ->
> > > Add a b
> > 
> > It seems to me that there should be a monad here somewhere, so that I
> > can write this approximately like
> > 
> > do a <- foo
> >b <- bar
> > return (Add a b)
> 
> Neat idea, but the monad can't work exactly as you propose, because
> it'd break the monad laws: do { a <- foo; return a } should be equal
> to foo, but in your example it'd result in Let foo id.
> 
> However, with an explicit binding marker the continuation monad does
> what you want:
> 
> import Control.Monad.Cont
> 
> data Expr = One | Add Expr Expr | Let Expr (Expr -> Expr)
> 
> type ExprM = Cont Expr
> 
> bind :: Expr -> ExprM Expr
> bind e = Cont (Let e)
> 
> runExprM :: ExprM Expr -> Expr
> runExprM e = runCont e id
> 
> Now you'd write your example as
> 
> do a <- bind foo
>b <- bind bar
>return (Add a b)

Nice. That's certainly a step towards what I was looking for, although
it requires slightly more "tags" than I was hoping for :) But I've
incorporated it into my code and it's much better already :)

You mention that a "direct" implementation of what I suggested would
break the monad laws, as (foo) and (Let foo id) are not equal. But one
might argue that they are in fact, in a sense, equivalent. Do you reckon
that if it is acceptable that foo and do { a <- foo; return a } don't
return equal terms (but equivalent terms), we can do still better?

Thanks again,

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

Re: [Haskell-cafe] Richer (than ascii) notation for haskell source?

[Neil Mitchell]

Hi

> It would be nice to be able to use a richer set of symbols in your source
> code for operators and functions (e.g. integral, sum, dot and cross-product,
> …),  as well as variables (the standard upper and lower-case greek for
> example, along with things like super- and sub-scripting, bold/italic and
> what-not).  You could imagine ending up with source code that reads just
> like a mathematical paper.

You probably still want to write in ASCII, as keyboards have buttons
for each of the letters in the alphabet, so its much easier. However,
you can format your code nicely using lhs2tex - I use it for all my
papers. I have things like:

%subst alpha = "{\alpha}"

Which means I can write: id :: alpha -> alpha

The code is valid Haskell, and looks super-pretty in papers.

Lhs2tex: http://people.cs.uu.nl/andres/lhs2tex/

Thanks

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

Re: [Haskell-cafe] Re: Endianess

[Henning Thielemann]

On Tue, 13 May 2008, Achim Schneider wrote:


Jed Brown <[EMAIL PROTECTED]> wrote:


It's not that simple with bits.  They lack consistency just like the
usual US date format and the way Germans read numbers.


So you claim that you pronounce 14 tenty-four? In German pronunciation
is completely uniform from 13 to 99.


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

Re: [Haskell-cafe] Richer (than ascii) notation for haskell source?

[Alec Berryman]

Patrick Surry on 2008-05-14 09:43:44 -0400:

> Probably a silly question, but for me one of the nice things about
> Haskell is that it's a lot like just writing math(s).  But in contrast
> to math you lose a lot of notational flexibility being limited to the
> ascii character set in your source code.

If you use emacs, there's some code that will display arbitrary
words/symbols as Greek letters or math symbols:

http://www.emacswiki.org/cgi-bin/wiki/PrettyLambda

It's cute.  It won't replace the actual text, just what's displayed, so
if you need to share your code with someone else, they'll still be able
to use it.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Richer (than ascii) notation for haskell source?

[Achim Schneider]

"Patrick Surry" <[EMAIL PROTECTED]> wrote:

> Probably a silly question, but for me one of the nice things about
> Haskell is that it's a lot like just writing math(s).  But in contrast
> to math you lose a lot of notational flexibility being limited to the
> ascii character set in your source code.   
> 
> Don't know how I'd actually then write/maintain the source-code - some
> WYSIWYG editor or effectively writing it in '(la)tex'?  
>
Feel free to extend literal Haskell and e.g. LyX to support this.
Shouldn't be too much of work, translating math formulae into plain
Haskell code to keep it executable.

-- 
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthorised copying,
hiring, renting, public performance and/or broadcasting of this
signature prohibited. 

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

Re: [Haskell-cafe] Maybe a, The Rationale

[Jules Bean]

PR Stanley wrote:



Paul:   What is the underlying rationale for the Maybe data type?

It is the equivalent of a database field that can be NULL.


Paul: shock, horror! the null value or the absence of any value 
denoted by null is not really in harmony with the relational model.


Ketil should have said:

It is the equivalent of the extremely common way of misusing NULL.

It doesn't bring in all the unpleasant baggage of three valued logic, 
but simple indicates an exceptional value. This use of NULL, very common 
in practical databases, frowned on by DB designers who understand about 
relational theory and normalisation, is prevalent precisely because 
common SQL dialects really make it a pain to invent your own datatypes, 
so it's hard to "add an exceptional value".


Practical programming needs a particular exceptional value very often 
indeed, to model things like optional parameters.


If common SQL dialects supported types like 'Maybe Int' natively, then 
NULL could be used much less.


Jules

PS Students of NULL and 3-valued logic will note that some of the 
problem therein can be studied in Haskell by comparing (==) and liftM2 
(==) as functions on Maybe Bool, or (>) vs liftM2 (>) on Maybe Int.


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

Re: [Haskell-cafe] Richer (than ascii) notation for haskell source?

[Bulat Ziganshin]

Hello Patrick,

Wednesday, May 14, 2008, 5:43:44 PM, you wrote:

> It would be nice to be able to use a richer set of symbols in your

ghc supports UTF-8 encoded haskell sources and there are lots of utf-8
enabled editors available

-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

[Haskell-cafe] Richer (than ascii) notation for haskell source?

[Patrick Surry]

Probably a silly question, but for me one of the nice things about
Haskell is that it's a lot like just writing math(s).  But in contrast
to math you lose a lot of notational flexibility being limited to the
ascii character set in your source code.   

 

It would be nice to be able to use a richer set of symbols in your
source code for operators and functions (e.g. integral, sum, dot and
cross-product, ...),  as well as variables (the standard upper and
lower-case greek for example, along with things like super- and
sub-scripting, bold/italic and what-not).  You could imagine ending up
with source code that reads just like a mathematical paper.

 

Don't know how I'd actually then write/maintain the source-code - some
WYSIWYG editor or effectively writing it in '(la)tex'?  Maybe that's
what Knuth is on about with his 'literate programming' weave/tangle
stuff which I don't know much about - does that translate to Haskell?

 

Patrick

 

[EMAIL PROTECTED]
 , VP Technology 

Tel: (617) 457 5230 Mob: (857) 919 1700 Fax: (617) 457 5299 Map
  

 

Portrait Software introduces Portrait Campaign Manager
 :

Easy, integrated campaign management for automated and highly targeted
outbound marketing

http://supportcentre.portraitsoftware.com/Vmail/emailfooter/balloon.gif
 

http://supportcentre.portraitsoftware.com/Vmail/emailfooter/portrait_sof
tware_logo.gif  

www.portraitsoftware.com  

 

 



DISCLAIMER: This e-mail is intended only for the addressee named above. As this 
e-mail may contain confidential or privileged information, if you are not the 
named addressee, you are not authorised to retain, read, copy or disseminate 
this message or any part of it. If you received this email in error, please 
notify the sender and delete the message from your computer.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Monad for HOAS?

[Lauri Alanko]

On Wed, May 14, 2008 at 10:11:17AM +0100, Edsko de Vries wrote:
> Suppose we have some data structure that uses HOAS; typically, a DSL
> with explicit sharing. For example:
> 
> > data Expr = One | Add Expr Expr | Let Expr (Expr -> Expr)
> 
> When I use such a data structure, I find myself writing expressions such
> as
> 
> > Let foo $ \a -> 
> > Let bar $ \b ->
> > Add a b
> 
> It seems to me that there should be a monad here somewhere, so that I
> can write this approximately like
> 
> do a <- foo
>b <- bar
>   return (Add a b)

Neat idea, but the monad can't work exactly as you propose, because
it'd break the monad laws: do { a <- foo; return a } should be equal
to foo, but in your example it'd result in Let foo id.

However, with an explicit binding marker the continuation monad does
what you want:

import Control.Monad.Cont

data Expr = One | Add Expr Expr | Let Expr (Expr -> Expr)

type ExprM = Cont Expr

bind :: Expr -> ExprM Expr
bind e = Cont (Let e)

runExprM :: ExprM Expr -> Expr
runExprM e = runCont e id

Now you'd write your example as

do a <- bind foo
   b <- bind bar
   return (Add a b)

HTH.


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

Re: [Haskell-cafe] Commutative monads vs Applicative functors

[Janis Voigtlaender]

Ronald Guida wrote:

From what I have read about applicative functors, they are weaker than
monads because with a monad, I can use the results of a computation to
select between alternative future computations and their side effects,
whereas with an applicative functor, I can only select between the
results of computations, while the structure of those computations and
their side effects are fixed in advance.


If you are not already aware of them, you might be interested in the 
following two papers:


http://homepages.inf.ed.ac.uk/wadler/papers/arrows-and-idioms/arrows-and-idioms.pdf

http://homepages.inf.ed.ac.uk/wadler/papers/arrows/arrows.pdf

("idioms" is a synonym for "applicative functors", and both papers also 
discuss the relation to monads.)


Ciao, Janis.

--
Dr. Janis Voigtlaender
http://wwwtcs.inf.tu-dresden.de/~voigt/
mailto:[EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Trying to avoid duplicate instances

[Eric Stansifer]

Thanks for your detailed input -- I appreciate seeing these rather
abstract techniques being applied to specific problems.

Tom Nielsen pointed me in the direction of the solution you've
supplied, so I should have replied to the list that my question had
been addressed.  Anyhow, I now have code that looks a little like:

> class DummySolidObject flag o
> class SolidObject o
>
> instance FiniteSolidObject o => DummySolidObject Dummy1 o
> instance InfiniteSolidObject o => DummySolidObject Dummy2 o
> instance DummySolidObject d o => SolidObject o
>
> data Dummy1
> data Dummy2

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

[Haskell-cafe] Monad for HOAS?

[Edsko de Vries]

Hi,

Suppose we have some data structure that uses HOAS; typically, a DSL
with explicit sharing. For example:

> data Expr = One | Add Expr Expr | Let Expr (Expr -> Expr)

When I use such a data structure, I find myself writing expressions such
as

> Let foo $ \a -> 
> Let bar $ \b ->
> Add a b

It seems to me that there should be a monad here somewhere, so that I
can write this approximately like

do a <- foo
   b <- bar
return (Add a b)

or something along those lines. It is however not at all clear to me
what this monad should look like. I have experimented with adding a type
parameter to Expr, something like

> data Expr a = One 
> | Add (Expr a) (Expr a) 
> | Let (Expr a) (Expr a -> Expr a) 
> | Place a

which has the additional benefit of supporting catamorphisms; I have
also experimented with defining various variations on

> Let a b = Let a (a -> b)

and making Let an instance of Monad rather than Expr; but none of my
experiments wered satisfactory.  

Am I missing something obvious, or is there a good reason this cannot be
done?

Thanks,

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

Re: [Haskell-cafe] Commutative monads vs Applicative functors

[Bruno Oliveira]

Hello,


On 14 May 2008, at 02:06, Ronald Guida wrote:

I have a few questions about commutative monads and applicative  
functors.


From what I have read about applicative functors, they are weaker  
than

monads because with a monad, I can use the results of a computation to
select between alternative future computations and their side effects,
whereas with an applicative functor, I can only select between the
results of computations, while the structure of those computations and
their side effects are fixed in advance.

But then there are commutative monads.  I'm not exactly sure what a
commutative monad is, but my understanding is that in a commutative
monad the order of side effects does not matter.

This leads me to wonder, are commutative monads still stronger than
applicative functors, or are they equivalent?



I would say that they are stronger because they still support:

concat :: Monad m => m (m a) -> m a

or

(>>=) :: Monad m => m a -> (a -> m b) -> m b

which are not supported, in general, by applicative functors.

In fact, I would probably risk to say that they are even stronger  
than monads

(as there are less commutative monads than regular monads).


And by the way, what exactly is a commutative monad?



Here is a possible characterization:

The monad m is commutative if, for all mx and my:

do {x <- mx; y <- my; return (x,y)} = do {y <- my; x <- mx; return  
(x,y)}


As you mentioned above, the basic idea is that the order of the side  
effects

does not matter. This law is not true in general for monads.

I am not sure if you know about the paper entitled "The essence of the
Iterator Pattern" (by Jeremy Gibbons and myself):

http://www.comlab.ox.ac.uk/people/Bruno.Oliveira/iterator-jfp.pdf

But, you may be interested to read it as it discusses related ideas. In
particular you may want to take a look at Section 5.4.

Cheers,

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