Re: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.

[Ross Paterson]

On Wed, Sep 26, 2007 at 11:25:30AM +0100, Tony Finch wrote:
> On Wed, 26 Sep 2007, Aaron Denney wrote:
> > It's true that time-wise there are definite issues in finding character
> > boundaries.
> 
> UTF-16 has no advantage over UTF-8 in this respect, because of surrogate
> pairs and combining characters.

Combining characters are not an issue here, just the surrogate pairs,
because we're discussing representations of sequences of Chars (Unicode
code points).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.

[Aaron Denney]

On 2007-09-27, Deborah Goldsmith <[EMAIL PROTECTED]> wrote:
> On Sep 26, 2007, at 11:06 AM, Aaron Denney wrote:
>>> UTF-16 has no advantage over UTF-8 in this respect, because of  
>>> surrogate
>>> pairs and combining characters.
>>
>> Good point.
>
> Well, not so much. As Duncan mentioned, it's a matter of what the most  
> common case is. UTF-16 is effectively fixed-width for the majority of  
> text in the majority of languages. Combining sequences and surrogate  
> pairs are relatively infrequent.

Infrequent, but they exist, which means you can't seek x/2 bytes ahead
to seek x characters ahead.  All such seeking must be linear for both
UTF-16 *and* UTF-8.

-- 
Aaron Denney
-><-

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

Re: [Haskell-cafe] PROPOSAL: New efficient Unicode string library.

[ok]

On 26 Sep 2007, at 7:05 pm, Johan Tibell wrote:

If UTF-16 is what's used by everyone else (how about Java? Python?) I
think that's a strong reason to use it. I don't know Unicode well
enough to say otherwise.


Java uses 16-bit variables to hold characters.
This is SOLELY for historical reasons, not because it is a good choice.
The history is a bit funny:  the ISO 10646 group were working away
defining a 31-bit character set, and the industry screamed blue murder
about how this was going to ruin the economy, bring back the Dark Ages,
&c, and promptly set up the Unicode consortium to define a 16-bit
character set that could do the same job.  Early versions of Unicode
had only about 30 000 characters, after heroic (and not entirely
appreciated) efforts at unifiying Chinese characters as used in China
with those used in Japan and those used in Korea.  They also lumbered
themselves (so that they would have a fighting chance of getting
Unicode adopted) with a "round trip conversion" policy, namely that it
should be possible to take characters using ANY current encoding
standard, convert them to Unicode, and then convert back to the original
encoding with no loss of information.  This led to failure of  
unification:

there are two versions of Å (one for ordinary use, one for Angstroms),
two versions of mu (one for Greek, one for micron), three complete  
copies

of ASCII, &c).  However, 16 bits really is not enough.

Here's a table from http://www.unicode.org/versions/Unicode5.0.0/

Graphic  98,884
Format  140
Control  65
Private Use 137,468
Surrogate 2,048
Noncharacter 66
Reserved875,441

Excluding Private Use and Reserved, I make that 101,203 currently
defined codes.  That's nearly 1.5* the number that would fit in 16
bits.

Java has had to deal with this, don't think it hasn't.  For example,
where Java had one set of functions referring to characters in strings
by position, it now has two complete sets:  one to use *which 16-bit
code* (which is fast) and one to use *which actual Unicode character*
(which is slow).  The key point is that the second set is *always*
slow even when there are no characters outside the basic multilingual
plane.

One Smalltalk system I sometimes use has three complete string
implementations (all characters fit in a byte, all characters fit
in 16 bits, some characters require more) and dynamically switches
from narrow strings to wide strings behind your back.  In a language
with read-only strings, that makes a lot of sense; it's just a pity
Smalltalk isn't one.

If you want to minimize conversion effort when talking to the operating
system, files, and other programs, UTF-8 is probably the way to go.
(That's on Unix.  For Windows it might be different.)

If you want to minimize the effort of recognising character boundaries
while processing strings, 32-bit characters are the way to go.  If you
want to be able to index into a string efficiently, they are the *only*
way to go.  Solaris bit the bullet many years ago; Sun C compilers
jumped straight from 8-bit wchar_t to 32_bit without ever stopping at  
16.


16-bit characters *used* to be a reasonable compromise, but aren't any
longer.  Unicode keeps on growing.  There were 1,349 new characters
from Unicode 4.1 to Unicode 5.0 (IIRC).  There are lots more scripts
in the pipeline.  (What the heck _is_ Tangut, anyway?)




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

[Haskell-cafe] 'data' syntax - a suggestion

[ok]

I have often found myself wishing for a small extension to the syntax of
Haskell 'data' declarations.  It goes like this:

data 
   = 
   | ...
   | 
+++where type  = 
 type  = 
 ...
   deriving 

Even something like binary search trees would, to me, be clearer as

data BST key val
   = Empty
   | Fork key val bst bst
   where type bst = BST key val

because this establishes an *essential* identity between the 3rd and 4th
Fork argument types, rather than an "accidental" identity.  I can't set
this up using 'type' outside the 'data' declaration, because it has to
refer to the type arguments of BST.

Semantically, this is just an abbreviation mechanism with no  
consequences

of any kind outside the 'data' declaration itself.  The only point would
be to make reading and writing 'data' declarations easier, especially
large ones.

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

Re: [Haskell-cafe] Desugaring of infix operators is (always?) the wrong way round

[ok]

On 26 Sep 2007, at 8:32 am, Brian Hulley wrote:
Aha! but this is using section syntax which is yet another  
complication. Hypothesis: section syntax would not be needed if the  
desugaring order was reversed.


Binary operators have two arguments.  That's why sections are needed.

This is one of the reasons why the combination of
  - sections
  - ordinary names as `operators`
is so nice.  Given a function f :: X -> Y -> Z.
Currying means that we have (f x) :: Y -> Z.
With sections, we also have (`f`y) :: X -> Z.

It doesn't matter *which* argument you put first,
people will sometimes need to partially apply to one of them,
and sometimes to the other.

My old ML library includes

fun ap1 f x = fn y => f (x,y)   (* == (x `f`) *)
fun ap2 f y = fn x => f (x,y)   (* == (`f` y) *)

Both are needed because the SML convention for operators passes a tuple.
The point is that BOTH are needed.

I am a bear of very little brain, and I would find it VERY confusing
if the order of arguments in an operator application did not match
the order of arguments in a function call.  I can live with
x @ y = (op @)(x, y)(* SML *)
x @ y = (@) x y -- Haskell
but making the orders different would guarantee that I would *always*
be in a muddle about which argument was which.  Living with
inconvenient argument orders is vastly easier than with inconsistent  
ones.


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

Re: [Haskell-cafe] Postdoctoral Fellowship in Functional Programming

[Bryan Burgers]

On 9/26/07, Graham Hutton <[EMAIL PROTECTED]> wrote:

> Salary  will be  within the  range 25,134  - 32,796  pounds  per year,
> depending  on qualifications  and experience.   The post  is available
> immediately, and will be offered on a fixed-term contract for 3 years.

I don't mean to diminish the seriousness of your message, but why is
the salary range so exact? Couldn't you have just rounded the upper
bound to 32,768 for the sake of readability?

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

Re: [Haskell-cafe] Haskell Cheat Sheet?

[Derek Elkins]

On Wed, 2007-09-26 at 17:23 -0700, Dan Weston wrote:
> Not to beat a dead horse, but I wasn't suggesting to rename the fix 
> function that everyone knows and loves:
> 
> fix :: (a -> a) -> a
> fix f = let f' = f f' in f'
> 
> I was merely trying to suggest that it would be wise to rename the 
> function in http://haskell.org/haskellwiki/Reference_card that redefined 
>   fix to mean:
> 
>   fix :: Eq x => (x -> x) -> x -> x
>   fix f x = if x == x' then x else fix f x'
>   where x' = f x
> 
> It is this latter function which I suggested to be renamed limit, since 
> it returns the limit (converged value) of f^n x, where n -> inf, and 
> doesn't even have the same type or arity as the standard fix function.
> 
> Somehow this (admittedly minor) point got lost in the heat of battle.

How 'bout just 'fixpoint' or 'fixedpoint' or 'findFixedPoint'.

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

Re: [Haskell-cafe] Re: Very crazy

[Derek Elkins]

On Wed, 2007-09-26 at 18:50 -0400, Steven Fodstad wrote:
> Andrew Coppin wrote:
> > Chaddaï Fouché wrote:
> >> 2007/9/25, Andrew Coppin <[EMAIL PROTECTED]>:
> >>  
> >>> This is why I found it so surprising - and annoying - that you can't
> >>> use
> >>> a 2-argument function in a point-free expression.
> >>>
> >>> For example, "zipWith (*)" expects two arguments, and yet
> >>>
> >>>   sum . zipWith (*)
> >>>
> >>> fails to type-check. You just instead write
> >>>
> >>>   \xs ys -> sum $ zipWith(*) xs ys
> >>>
> >>> 
> >>
> >> (sum . zipWith (*)) xs ys
> >> == (sum (zipWith (*) xs)) ys
> >>
> >> so you try to apply sum :: [a] -> Int to a function (zipWith (*) xs)
> >> :: [a] -> [b], it can't work !
> >>
> >> (sum.) . zipWith (*)
> >> works, but isn't the most pretty expression I have seen.
> >>   
> >
> > I'm still puzzled as to why this breaks with my example, but works
> > perfectly with other people's examples...
> >
> > So you're saying that
> >
> >  (f3 . f2 . f1) x y z ==> f3 (f2 (f1 x) y) z
> >
> > ? In that case, that would mean that
> >
> >  (map . map) f xss ==> map (map f) xss
> >
> > which *just happens* to be what we want. But in the general case where
> > you want
> >
> >  f3 (f2 (f1 x y z))
> >
> > there's nothing you can do except leave point-free.
> Well, there's one thing.  You can change your three argument function
> into a one argument function of a 3-tuple, and then change the composed
> function back again:
> 
> let uncurry3 = \f (x,y,z) -> f x y z
> curry3 = \f x y z -> f (x,y,z)
> in curry3 $ f3 . f2 . uncurry3 f1
> 
> In your earlier example, this would have been:
> curry $ sum . uncurry (zipWith (*))

As a side note, this is essentially how all higher order functions are
handled in category theory (well, in cartesian closed categories.)

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

Re: [Haskell-cafe] Haskell Cheat Sheet?

[Devin Mullins]

On Wed, Sep 26, 2007 at 05:23:58PM -0700, Dan Weston wrote:
> It is this latter function which I suggested to be renamed limit, since 
> it returns the limit (converged value) of f^n x, where n -> inf, and 
> doesn't even have the same type or arity as the standard fix function.
> 
> Somehow this (admittedly minor) point got lost in the heat of battle.

It did? I thought the response was that they /both/ calculated fixed
points. This "limit" seems to look for an attractive fixed point[1] in a
fairly straightforward (and possibly naive) way. As a matter of fact,
its only differences from the standard fix definition seem to be:
  1) A parameterized initial state
  2) A terminating condition (and the necessary type context)

Am I crazy?

Devin
[1] http://en.wikipedia.org/wiki/Fixpoint#Attractive_fixed_points
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.

[Deborah Goldsmith]

On Sep 26, 2007, at 11:06 AM, Aaron Denney wrote:
UTF-16 has no advantage over UTF-8 in this respect, because of  
surrogate

pairs and combining characters.


Good point.


Well, not so much. As Duncan mentioned, it's a matter of what the most  
common case is. UTF-16 is effectively fixed-width for the majority of  
text in the majority of languages. Combining sequences and surrogate  
pairs are relatively infrequent.


Speaking as someone who has done a lot of Unicode implementation, I  
would say UTF-16 represents the best time/space tradeoff for an  
internal representation. As I mentioned, it's what's used in Windows,  
Mac OS X, ICU, and Java.


Deborah

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

Re: [Haskell-cafe] Haskell Cheat Sheet?

[Dan Weston]

Not to beat a dead horse, but I wasn't suggesting to rename the fix 
function that everyone knows and loves:


fix :: (a -> a) -> a
fix f = let f' = f f' in f'

I was merely trying to suggest that it would be wise to rename the 
function in http://haskell.org/haskellwiki/Reference_card that redefined 
 fix to mean:


 fix :: Eq x => (x -> x) -> x -> x
 fix f x = if x == x' then x else fix f x'
 where x' = f x

It is this latter function which I suggested to be renamed limit, since 
it returns the limit (converged value) of f^n x, where n -> inf, and 
doesn't even have the same type or arity as the standard fix function.


Somehow this (admittedly minor) point got lost in the heat of battle.

Dan Weston

Jonathan Cast wrote:

On Wed, 2007-09-26 at 17:09 -0500, Derek Elkins wrote:

On Wed, 2007-09-26 at 14:12 -0700, Jonathan Cast wrote:

On Wed, 2007-09-26 at 11:43 -0700, Dan Weston wrote:
It seems no one liked idea #2. I still think fix is the wrong name for 
this, maybe limit would be better.

It calculates least fixed points.  `fix' is as good a name as any.

`limit' is terrible; the argument to fix, a -> a, is neither a sequence
nor diagram nor net type, and hence its values don't have limits...

jcc

PS Yes, I know fix a = sup_{i=0}^inf f^i(bot).  That sequence is rather
different than the input function...

Actually, f :: a -> a -is- a diagram and its limit -is- fix f.


In what way?  I'm not disputing you, but I don't see how to interpret it
as such.


  That
said, limit is still a horrible name for it.  fix isn't much better, and
Y is even worse.  I'm not sure what an immediately intuitive name would
be, so might as well go with the historical one.


recursive (at least for my usage).

jcc


___
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] Haskell Cheat Sheet?

[Jonathan Cast]

On Wed, 2007-09-26 at 17:09 -0500, Derek Elkins wrote:
> On Wed, 2007-09-26 at 14:12 -0700, Jonathan Cast wrote:
> > On Wed, 2007-09-26 at 11:43 -0700, Dan Weston wrote:
> > > It seems no one liked idea #2. I still think fix is the wrong name for 
> > > this, maybe limit would be better.
> > 
> > It calculates least fixed points.  `fix' is as good a name as any.
> > 
> > `limit' is terrible; the argument to fix, a -> a, is neither a sequence
> > nor diagram nor net type, and hence its values don't have limits...
> > 
> > jcc
> > 
> > PS Yes, I know fix a = sup_{i=0}^inf f^i(bot).  That sequence is rather
> > different than the input function...
> 
> Actually, f :: a -> a -is- a diagram and its limit -is- fix f.

In what way?  I'm not disputing you, but I don't see how to interpret it
as such.

>   That
> said, limit is still a horrible name for it.  fix isn't much better, and
> Y is even worse.  I'm not sure what an immediately intuitive name would
> be, so might as well go with the historical one.

recursive (at least for my usage).

jcc


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

Re: [Haskell-cafe] unsafePerformIO: are we safe?

[Chaddaï Fouché]

2007/9/26, Adrian Hey <[EMAIL PROTECTED]>:
> Chaddaï Fouché wrote:
> > There can't be alternatives, unsafeIO throw by the window most
> > guarantee that Haskell can give you and you have to provide them
> > yourself (with a proof of this part of your program), but it's
> > inherent to the nature of the beast, it's what it do !
>
> What about ..
>
>   http://www.haskell.org/haskellwiki/Top_level_mutable_state
>
> This as unsafe a use of unsafePerformIO as you'll ever find, but
> necessary for real IO libs.
>

I'm not arguing that there aren't specific current usage of
unsafePerformIO that could be better formalized (there are), I'm
saying that you can't design an alternative to unsafePerformIO which
cover all its applications but stay safer. What we can do with
unsafePerformIO is inherently unsafe, even though you can obtain safe
results with it (and in some of those use-case, a restricted version
of unsafePerformIO could be used and would be safer).

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

Re: [Haskell-cafe] Re: Very crazy

[Steven Fodstad]

Andrew Coppin wrote:
> Chaddaï Fouché wrote:
>> 2007/9/25, Andrew Coppin <[EMAIL PROTECTED]>:
>>  
>>> This is why I found it so surprising - and annoying - that you can't
>>> use
>>> a 2-argument function in a point-free expression.
>>>
>>> For example, "zipWith (*)" expects two arguments, and yet
>>>
>>>   sum . zipWith (*)
>>>
>>> fails to type-check. You just instead write
>>>
>>>   \xs ys -> sum $ zipWith(*) xs ys
>>>
>>> 
>>
>> (sum . zipWith (*)) xs ys
>> == (sum (zipWith (*) xs)) ys
>>
>> so you try to apply sum :: [a] -> Int to a function (zipWith (*) xs)
>> :: [a] -> [b], it can't work !
>>
>> (sum.) . zipWith (*)
>> works, but isn't the most pretty expression I have seen.
>>   
>
> I'm still puzzled as to why this breaks with my example, but works
> perfectly with other people's examples...
>
> So you're saying that
>
>  (f3 . f2 . f1) x y z ==> f3 (f2 (f1 x) y) z
>
> ? In that case, that would mean that
>
>  (map . map) f xss ==> map (map f) xss
>
> which *just happens* to be what we want. But in the general case where
> you want
>
>  f3 (f2 (f1 x y z))
>
> there's nothing you can do except leave point-free.
Well, there's one thing.  You can change your three argument function
into a one argument function of a 3-tuple, and then change the composed
function back again:

let uncurry3 = \f (x,y,z) -> f x y z
curry3 = \f x y z -> f (x,y,z)
in curry3 $ f3 . f2 . uncurry3 f1

In your earlier example, this would have been:
curry $ sum . uncurry (zipWith (*))
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Sending email from a Haskell program

[brad clawsie]

> jmuk's HaskellNet project from last year?
> 
> http://darcs.haskell.org/SoC/haskellnet/HaskellNet/IMAP.hs

sweet! was there any documentation created for this? examples?
anything? have people tried to make this work with ssl/tls libs? 

by the way there looks like some other gems in the haskellnet
dir. what exactly was haskellnet - a project to code to the major
network protocols? are these libs stable? how does the HTTP lib stack
up against Network.HTTP? any info on this project would be
appreciated.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] unsafePerformIO: are we safe?

[Lennart Augustsson]

You could do this:

r :: IORef [a]
r = unsafePerformIO $ newIORef []

cast :: a -> b
cast a = unsafePerformIO $ do
writeIORef r [a]
x <- readIORef r
return $ head x


On 9/26/07, Dan Piponi <[EMAIL PROTECTED]> wrote:
>
> On 9/26/07, Lennart Augustsson <[EMAIL PROTECTED]> wrote:
> > Things can go arbitrarily wrong if you misuse unsafePerformIO, you can
> even
> > subvert the type system.
>
> So...if I was in a subversive kind of mood (speaking hypothetically),
> what would I have to do?
> --
> Dan
>
> >
> >
> > On 9/26/07, Jorge Marques Pelizzoni < [EMAIL PROTECTED]> wrote:
> > >
> > > Hi, all!
> > >
> > > This is a newbie question: I sort of understand what unsafePerformIO
> does
> > > but I don't quite get its consequences. In short: how safe can one be
> in
> > > face of it? I mean, conceptually, it allows any Haskell function to
> have
> > > side effects just as in any imperative language, doesn't it? Doesn't
> it
> > > blow up referential transparency for good? Is there anything intrinsic
> to
> > > it that still keeps Haskell "sound" no matter what unsafePerformIO
> users
> > > do (unlikely) or else what are the guidelines we should follow when
> using
> > > it?
> > >
> > > Thanks in advance. Cheers,
> > >
> > > Jorge.
> > >
> > > ___
> > > Haskell-Cafe mailing list
> > > Haskell-Cafe@haskell.org
> > > http://www.haskell.org/mailman/listinfo/haskell-cafe
> > >
> >
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >
> ___
> Haskell-Cafe 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] unsafePerformIO: are we safe?

[Jonathan Cast]

On Wed, 2007-09-26 at 14:28 -0700, Dan Piponi wrote:
> On 9/26/07, Lennart Augustsson <[EMAIL PROTECTED]> wrote:
> > Things can go arbitrarily wrong if you misuse unsafePerformIO, you can even
> > subvert the type system.
> 
> So...if I was in a subversive kind of mood (speaking hypothetically),
> what would I have to do?

unsafeCoerce :: a -> b
unsafeCoerce a = unsafePerformIO $ do
  let ref = unsafePerformIO $ newIORef undefined
  ref `writeIORef` a
  readIORef ref

jcc


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

Re: [Haskell-cafe] unsafePerformIO: are we safe?

[Dan Piponi]

On 9/26/07, Lennart Augustsson <[EMAIL PROTECTED]> wrote:
> Things can go arbitrarily wrong if you misuse unsafePerformIO, you can even
> subvert the type system.

So...if I was in a subversive kind of mood (speaking hypothetically),
what would I have to do?
--
Dan

>
>
> On 9/26/07, Jorge Marques Pelizzoni < [EMAIL PROTECTED]> wrote:
> >
> > Hi, all!
> >
> > This is a newbie question: I sort of understand what unsafePerformIO does
> > but I don't quite get its consequences. In short: how safe can one be in
> > face of it? I mean, conceptually, it allows any Haskell function to have
> > side effects just as in any imperative language, doesn't it? Doesn't it
> > blow up referential transparency for good? Is there anything intrinsic to
> > it that still keeps Haskell "sound" no matter what unsafePerformIO users
> > do (unlikely) or else what are the guidelines we should follow when using
> > it?
> >
> > Thanks in advance. Cheers,
> >
> > Jorge.
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Haskell Cheat Sheet?

[Jonathan Cast]

On Wed, 2007-09-26 at 11:43 -0700, Dan Weston wrote:
> It seems no one liked idea #2. I still think fix is the wrong name for 
> this, maybe limit would be better.

It calculates least fixed points.  `fix' is as good a name as any.

`limit' is terrible; the argument to fix, a -> a, is neither a sequence
nor diagram nor net type, and hence its values don't have limits...

jcc

PS Yes, I know fix a = sup_{i=0}^inf f^i(bot).  That sequence is rather
different than the input function...



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

Re: [Haskell-cafe] unsafePerformIO: are we safe?

[Adrian Hey]

Chaddaï Fouché wrote:

There can't be alternatives, unsafeIO throw by the window most
guarantee that Haskell can give you and you have to provide them
yourself (with a proof of this part of your program), but it's
inherent to the nature of the beast, it's what it do !


What about ..

 http://www.haskell.org/haskellwiki/Top_level_mutable_state

This as unsafe a use of unsafePerformIO as you'll ever find, but
necessary for real IO libs.

Regards
--
Adrian Hey

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

[Haskell-cafe] Re: Troubles understanding memoization in SOE

[ChrisK]

Peter Verswyvelen wrote:
>  Paul L wrote:
> 
>> We recently wrote a paper about the leak problem. The draft is at
>> http://www.cs.yale.edu/~hl293/download/leak.pdf. Comments are welcome!
> I'm trying to understand the following in this paper:
> 
> (A) repeat x = x : repeat x
> or, in lambdas:
> (B) repeat = λx → x : repeat x
> This requires O(n) space. But we can achieve O(1) space by writing instead:
> (C) repeat = λx → let xs = x : xs in xs
> 
> Let me see if I understand this correctly. Since I'm an imperative
> programmer, I'll try a bit of C++ here.
> 
> struct Cell : Value
> {
> Value* head;
> Value* tail;
> };
> 
> So in (A) and (B), a Cell c1 is allocated, and c1->head would be a
> pointer to x, and c1->tail would be a pointer to a newly allocated Cell
> c2, etc etc, hence O(n) space complexity
> In (C) however, a Cell xs is allocated, and xs->head is also a pointer
> to x, but xs->tail is a pointer the cell xs again, creating one circular
> data structure, hence O(1) space complexity.
> 
> Is this more or less correct?

Yes.  Also I believe (A) and (B) are the same as

repeat = fix (\ f -> (\ x -> x : f x ) )

While (C) is

repeat = \x -> fix (\ me -> x : me )
or
repeat x = fix (\me -> x : me )

> 
> I'm also trying to figure out how the "fixed point combinator" works, so
> the fix f = f (fix f), and it's effect on space/time complexity. Any
> good tutorials on that one? Or is this the one
> http://haskell.org/haskellwiki/Recursive_function_theory. Looks a bit
> scary at first sight ;-)
> 
> Thanks again,
> Peter

A good way to think about 'fix' is that it lets us write a definition that talks
about the thing that we are defining.  This is very common in Haskell, since
every recursive definition or mutually recursive set of definitions talks about
itself.  (Every Haskell let is a bit like Scheme's letrec).

This is also common in C++ and Java when an object "talks about" itself while it
is being constructed.

Warning: It is easy for a programming mistake to create a dependency loop (or
"black hole") when using 'fix' improperly.  This is similar to a C++/Java object
calling itself during construction when it is in only a partially constructed
state and causing an error.

Now take the definition from GHC's base package, currently in
http://darcs.haskell.org/packages/base/Data/Function.hs

> -- | @'fix' f@ is the least fixed point of the function @f@,
> -- i.e. the least defined @x@ such that @f x = [EMAIL PROTECTED]
> fix :: (a -> a) -> a
> fix f = let x = f x in x

Consider the type of fix, namely (a->a)->a.
Note that is not the same as a->a->a which is actually a->(a->a).

For (A) and (B) the type 'a' is the type of 'f' which is a function.
If repeat :: q -> [q] then 'a' is 'q->[q]' and the fix is of type
( (q->[q]) -> (q->[q]) ) -> (q->[q])

For (C) the type 'a' is the type of 'me' which is a list, and the fix is of type
( [q] -> [q] ) -> [q]


Expand (C) step by step:

-- Rename x to be q to avoid name collisions
repeat = \q -> fix (\me -> q : me )
-- Now substitute the definition of fix using f = (\me -> q : me)
repeat = \q -> let x = (\me -> q : me) x in x
-- Apply the function with me replaced by x
repeat = \q -> let x = q : x in x
Optionally convert to pointful notation
repeat q = let x = q : x in x

And these are your definition (C)

Expand (A) or (B) step by step:

Rename x to q to avoid name collision later
repeat = fix (\ f -> (\ q -> q : f q ) )
Expand definition of fix replacing f with (\ f -> (\ q -> q : f q ) )
repeat = let x = (\ f -> (\ q -> q : f q ) ) x in x
Apply the function replacing f with x
repeat = let x = (\ q -> q : x q ) ) in x
Simplify by noting that 'x' and 'repeat' name the same thing
repeat = (\q -> q : repeat q)
Optionally convert to pointful notation
repeat q = q : repeat q

-- 
Chris

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

Re: [Haskell-cafe] Sending email from a Haskell program

[Don Stewart]

clawsie:
> an IMAP library might make for a good bounty project...i figure that
> you would indeed need to pay someone to untangle that standard

jmuk's HaskellNet project from last year?

http://darcs.haskell.org/SoC/haskellnet/HaskellNet/IMAP.hs

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

[Haskell-cafe] Postdoctoral Fellowship in Functional Programming

[Graham Hutton]

++

POSTDOCTORAL RESEARCH FELLOW IN FUNCTIONAL PROGRAMMING

  School of Computer Science
 University of Nottingham, UK

Applications are invited for a 3-year postdoctoral research fellowship
in  functional programming,  to  work  with Dr  Graham  Hutton on  the
EPSRC-funded project "Reasoning About Exceptions and Interrupts".

Most  modern  programming   languages  provide  special  features  for
detecting and managing unexpected events, in the form of exception and
interrupt handling primitives.  Despite their importance, the issue of
provable  correctness  for   programs  involving  these  features  has
received  little  attention, but  is  particularly  crucial given  the
difficulty of  writing correct programs  in this setting.  The  aim of
this project is  to address this problem within  the context of modern
functional programming languages such as Haskell and Epigram.

Applicants for this  position will require a PhD  in Computer Science,
and  research   experience  in  functional   programming.   Additional
desirable attributes  include experience in  formal semantics, program
verification, concurrency theory, or theorem provers.

The  successful applicant will  work in  collaboration with  Dr Graham
Hutton  in  the Foundations  of  Programming  group  in Nottingham,  a
leading  centre   for  research  on  formal   approaches  to  software
construction  and  verification.   The  group  currently  comprises  7
academic staff, 5 research staff, and 13 PhD students.

Salary  will be  within the  range 25,134  - 32,796  pounds  per year,
depending  on qualifications  and experience.   The post  is available
immediately, and will be offered on a fixed-term contract for 3 years.

Further details regarding the position  and how to apply are available
from Dr Graham Hutton, http://www.cs.nott.ac.uk/~gmh.

Closing date for applications: 12th October 2007.

++
| Dr Graham HuttonEmail : [EMAIL PROTECTED]  |
| School of Computer Science |
| University of NottinghamWeb   : www.cs.nott.ac.uk/~gmh |
| Jubilee Campus, Wollaton Road  |
| Nottingham NG8 1BB, UK  Phone : +44 (0)115 951 4220|
++

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

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

Re: [Haskell-cafe] Sending email from a Haskell program

[brad clawsie]

an IMAP library might make for a good bounty project...i figure that
you would indeed need to pay someone to untangle that standard
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Troubles understanding memoization in SOE

[Isaac Dupree]

Peter Verswyvelen wrote:
Let me see if I understand this correctly. Since I'm an imperative 
programmer, I'll try a bit of C++ here.


struct Cell : Value
{
Value* head;
Value* tail;
};

So in (A) and (B), a Cell c1 is allocated, and c1->head would be a 
pointer to x, and c1->tail would be a pointer to a newly allocated Cell 
c2, etc etc, hence O(n) space complexity
In (C) however, a Cell xs is allocated, and xs->head is also a pointer 
to x, but xs->tail is a pointer the cell xs again, creating one circular 
data structure, hence O(1) space complexity.


Is this more or less correct?


yes.. I don't think you meant to both derive Cell from Value and have a 
"head" pointer.  Otherwise it's an excellent analogy (ignoring how 
_unevaluated_ thunks are represented, because without those -- with 
strict list evaluation -- O(n) repeat has to be O(infinity) ).



I'm also trying to figure out how the "fixed point combinator" works, so 
the fix f = f (fix f), and it's effect on space/time complexity.


or

fix f = let x = f x in x

which may have different complexity properties?

I don't know... Imagine inlining `fix`, if you have a better intuition 
for explicit (co)recursion than for `fix`.  Oh wait, only my definition 
can be fully inlined, not yours.


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

Re: [Haskell-cafe] Troubles understanding memoization in SOE

[Peter Verswyvelen]

 Paul L wrote:

We recently wrote a paper about the leak problem. The draft is at 
http://www.cs.yale.edu/~hl293/download/leak.pdf. Comments are welcome!

I'm trying to understand the following in this paper:

(A) repeat x = x : repeat x
or, in lambdas:
(B) repeat = λx → x : repeat x
This requires O(n) space. But we can achieve O(1) space by writing instead:
(C) repeat = λx → let xs = x : xs in xs

Let me see if I understand this correctly. Since I'm an imperative 
programmer, I'll try a bit of C++ here.


struct Cell : Value
{
Value* head;
Value* tail;
};

So in (A) and (B), a Cell c1 is allocated, and c1->head would be a 
pointer to x, and c1->tail would be a pointer to a newly allocated Cell 
c2, etc etc, hence O(n) space complexity
In (C) however, a Cell xs is allocated, and xs->head is also a pointer 
to x, but xs->tail is a pointer the cell xs again, creating one circular 
data structure, hence O(1) space complexity.


Is this more or less correct?

I'm also trying to figure out how the "fixed point combinator" works, so 
the fix f = f (fix f), and it's effect on space/time complexity. Any 
good tutorials on that one? Or is this the one 
http://haskell.org/haskellwiki/Recursive_function_theory. Looks a bit 
scary at first sight ;-)


Thanks again,
Peter

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

Re: [Haskell-cafe] unsafePerformIO: are we safe?

[Paul Johnson]

Jorge Marques Pelizzoni wrote:

Hi, all!

This is a newbie question: I sort of understand what unsafePerformIO does
but I don't quite get its consequences. In short: how safe can one be in
face of it? I mean, conceptually, it allows any Haskell function to have
side effects just as in any imperative language, doesn't it? Doesn't it
blow up referential transparency for good? Is there anything intrinsic to
it that still keeps Haskell "sound" no matter what unsafePerformIO users
do (unlikely) or else what are the guidelines we should follow when using
it
unsafePerformIO does indeed lose referential transparency, or to be more 
precise, it fails to guarantee it.  If you call a computation with 
unsafePerformIO twice it may give different answers, depending on the IO 
value it wraps.  Therefore its up to the programmer to make sure that it 
doesn't matter how many times the computation is executed.  The Haskell 
compiler may (or may not) optimise multiple calls into one call.  If the 
result is not required then a lazy computation may mean that the 
computation is never used.  If you have two calls to unsafePerformIO 
then you can't rely on the ordering, and the strictness analyser may 
change the order as part of optimisation.  You get the picture.


So in summary, its up to you to make sure that the computation wrapped 
by unsafePerformIO has no side effects.  For instance if you wanted to 
read a configuration file and make the result look like a pure value 
then that would be a reasonable use for unsafePerformIO: reading the 
file is almost free of side effects (apart from updating the 
last-accessed time in some file systems), and the file isn't likely to 
change while you are reading it.


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

Re: [Haskell-cafe] Haskell Cheat Sheet?

[Dan Weston]

It seems no one liked idea #2. I still think fix is the wrong name for 
this, maybe limit would be better.


Dan Weston wrote:

One suggestion:

Section 3.6 defines a function "fix":

 fix :: Eq x => (x -> x) -> x -> x

 fix f x = if x == x' then x else fix f x'
 where x' = f x

This confusingly differs in both type and meaning from the traditional 
function Control.Monad.Fix.fix and is not even used elsewhere in the 
document.


I suggest that it be removed and the real Control.Monad.Fix.fix function 
be defined in its own section, with an side-by-side comparison with a 
named recursive function. This would be useful because the type


fix :: (a -> a) -> a

is highly confusing, suggesting to newcomers a usage like:

f = fix (+1)

which is undefined (and seems to be "missing an argument"), when 
invariably its type is in practice restricted to:


fix :: ((a -> b) -> (a -> b)) -> (a -> b)

which is much more suggestive (but nowhere to be found in the docs).

Dan Weston

Don Stewart wrote:

evan:

Has anybody made (or have a link to) a Haskell reference cheat sheet?
I'm thinking of a nice LaTeXed PDF in the 1-10 page range (e.g.
something like this http://www.tug.org/texshowcase/cheat.pdf) with the
basics of the language syntax, the type declarations for the common type
classes, the type signatures of the most commonly used functions in the
Prelude and other common modules, and so forth? The Haskell standard
library is very large for a newcomer (even just the Prelude!), and as a
learner of the language I find myself spending a lot of time looking up
Prelude functions and syntax details -- having all of this in a short
PDF document that I could have offline would be very useful.



http://haskell.org/haskellwiki/Reference_card

?
___
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] Sending email from a Haskell program

[Jeremy Shaw]

At Wed, 26 Sep 2007 22:11:12 +0700,
Peter Gammie wrote:
> 
> Hello,
> 
> Does anyone have a library for sending email from a Haskell program?  
> I'd like something portable and cabalised.
> 
> I note there is code in darcs to send email on Windows and UNIX-y  
> systems, and also something in WASH (I know not what). Apparently  
> there is an SMTP server of some kind (?) in HAppS, but I want to re- 
> use the system's MTA.

Another not-quite-there-yet solution is to use this library to create
a mime message:

http://www.n-heptane.com/nhlab/repos/haskell-mime/

In Text.MIME.Compose there is a wrapper for calling sendmail (so,
its not portable yet).

That MIME library is currently undergoing a very slow rewrite. The
next version will have a different API, and will have support for
things like attachments, multipart messages, etc.

If you just want to send basic text emails, the current version might
work for you...

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

Re: [Haskell-cafe] unsafePerformIO: are we safe?

[Lennart Augustsson]

Things can go arbitrarily wrong if you misuse unsafePerformIO, you can even
subvert the type system.

On 9/26/07, Jorge Marques Pelizzoni <[EMAIL PROTECTED]> wrote:
>
>
> Hi, all!
>
> This is a newbie question: I sort of understand what unsafePerformIO does
> but I don't quite get its consequences. In short: how safe can one be in
> face of it? I mean, conceptually, it allows any Haskell function to have
> side effects just as in any imperative language, doesn't it? Doesn't it
> blow up referential transparency for good? Is there anything intrinsic to
> it that still keeps Haskell "sound" no matter what unsafePerformIO users
> do (unlikely) or else what are the guidelines we should follow when using
> it?
>
> Thanks in advance. Cheers,
>
> Jorge.
>
> ___
> 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] Troubles understanding memoization in SOE

[Henning Thielemann]

On Wed, 26 Sep 2007, Don Stewart wrote:


And don't forget these three games that got mentioned during the week.

   Octane Mech:
   
http://berlinbrowndev.blogspot.com/2007/09/octane-mech-opengl-haskell-based-mech.html

   OpenGL Tetris:
   http://myawesomeblag.blogspot.com/2007/03/opengl-tetris-in-haskell.html

   Games in Haskell video:
   http://www.londonhug.net/2007/09/21/games-in-haskell-video-now-available/


Would be great, if announcements were more formalized and could be 
automatically added to the Wiki or some automated overview for non-Hackage 
packages.

 http://haskell.org/haskellwiki/Applications_and_libraries/Games

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

[Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.

[Aaron Denney]

On 2007-09-26, Tony Finch <[EMAIL PROTECTED]> wrote:
> On Wed, 26 Sep 2007, Aaron Denney wrote:
>>
>> It's true that time-wise there are definite issues in finding character
>> boundaries.
>
> UTF-16 has no advantage over UTF-8 in this respect, because of surrogate
> pairs and combining characters.

Good point.

-- 
Aaron Denney
-><-

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

Re: [Haskell-cafe] unsafePerformIO: are we safe?

[Jorge Marques Pelizzoni]

Thanks! That's very clarifying.

Bulat Ziganshin escreveu:
> Hello Jorge,
>
> Wednesday, September 26, 2007, 6:43:15 PM, you wrote:
>
>> This is a newbie question: I sort of understand what unsafePerformIO
>> does
>> but I don't quite get its consequences. In short: how safe can one be in
>> face of it?
>
> i redirect you to http://haskell.org/haskellwiki/IO_inside
> and "Tackling the awkward squad: monadic input/output, concurrency,
> exceptions, and foreign-language calls in Haskell"
> [http://research.microsoft.com/Users/simonpj/papers/marktoberdorf/marktoberdorf.ps.gz]
>
> probably in the last paper i have seen two rules of using
> unsafePerformIO, but i can't recall them
>
>
> --
> Best regards,
>  Bulatmailto:[EMAIL PROTECTED]
>


Jorge M. Pelizzoni
ICMC - Universidade de São Paulo

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

[Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.

[Aaron Denney]

On 2007-09-26, Johan Tibell <[EMAIL PROTECTED]> wrote:
> On 9/26/07, Aaron Denney <[EMAIL PROTECTED]> wrote:
>> On 2007-09-26, Johan Tibell <[EMAIL PROTECTED]> wrote:
>> > If UTF-16 is what's used by everyone else (how about Java? Python?) I
>> > think that's a strong reason to use it. I don't know Unicode well
>> > enough to say otherwise.
>>
>> The internal representations don't matter except in the case of making
>> FFI linkages.  The external representations do, and UTF-8 has won on
>> that front.
>
> It could matter for performance. However, you can encode your
> UnicodeString into any external representation you want for your I/O
> needs, including UTF-8.

Right.  I was trying to say "other languages internal representations
shouldn't affect the choice of those doing a Haskell implementation."

-- 
Aaron Denney
-><-

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

Re: [Haskell-cafe] unsafePerformIO: are we safe?

[Chaddaï Fouché]

2007/9/26, Adrian Hey <[EMAIL PROTECTED]>:
> Sebastian Sylvan wrote:
> > Rule of thumb: If your name isn't Simon*, you shouldn't use unsafePerformIO.
> If this is so, maybe it's time someone (who may or may not be called
> Simon) gave us a realistic alternative.
>
There can't be alternatives, unsafeIO throw by the window most
guarantee that Haskell can give you and you have to provide them
yourself (with a proof of this part of your program), but it's
inherent to the nature of the beast, it's what it do !

And you don't need to be called Simon to use it, but you surely need
to be careful with it's use if you want to write safe code (you won't
need it in most case, only in very specific situations and in writing
some new strange libraries).

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

Re: [Haskell-cafe] PROPOSAL: New efficient Unicode string library.

[Jonathan Cast]

On Wed, 2007-09-26 at 18:46 +0100, Duncan Coutts wrote:
> In message <[EMAIL PROTECTED]> Jonathan Cast <[EMAIL PROTECTED]> writes:
> > On Wed, 2007-09-26 at 09:05 +0200, Johan Tibell wrote:
> 
> > > If UTF-16 is what's used by everyone else (how about Java? Python?) I
> > > think that's a strong reason to use it. I don't know Unicode well
> > > enough to say otherwise.
> > 
> > I disagree.  I realize I'm a dissenter in this regard, but my position
> > is: excellent Unix support first, portability second, excellent support
> > for Win32/MacOS a distant third.  That seems to be the opposite of every
> > language's position.  Unix absolutely needs UTF-8 for backward
> > compatibility.
> 
> I think you're talking about different things, internal vs external 
> representations.
> 
> Certainly we must support UTF-8 as an external representation. The choice of
> internal representation is independent of that. It could be [Char] or some
> memory efficient packed format in a standard encoding like UTF-8,16,32. The
> choice depends mostly on ease of implementation and performance. Some formats
> are easier/faster to process but there are also conversion costs so in some 
> use
> cases there is a performance benefit to the internal representation being the
> same as the external representation.
> 
> So, the obvious choices of internal representation are UTF-8 and UTF-16. UTF-8
> has the advantage of being the same as a common external representation so
> conversion is cheap (only need to validate rather than copy). UTF-8 is more
> compact for western languages but less compact for eastern languages compared 
> to
> UTF-16. UTF-8 is a more complex encoding in the common cases than UTF-16. In 
> the
> common case UTF-16 is effectively fixed width. According to the ICU 
> implementors
> this has speed advantages (probably due to branch prediction and smaller code 
> size).
> 
> One solution is to do both and benchmark them.

OK, right.

jcc

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

Re: [Haskell-cafe] unsafePerformIO: are we safe?

[Bulat Ziganshin]

Hello Jorge,

Wednesday, September 26, 2007, 6:43:15 PM, you wrote:

> This is a newbie question: I sort of understand what unsafePerformIO does
> but I don't quite get its consequences. In short: how safe can one be in
> face of it?

i redirect you to http://haskell.org/haskellwiki/IO_inside
and "Tackling the awkward squad: monadic input/output, concurrency,
exceptions, and foreign-language calls in Haskell"
[http://research.microsoft.com/Users/simonpj/papers/marktoberdorf/marktoberdorf.ps.gz]

probably in the last paper i have seen two rules of using
unsafePerformIO, but i can't recall them


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

Re: [Haskell-cafe] PROPOSAL: New efficient Unicode string library.

[Duncan Coutts]

In message <[EMAIL PROTECTED]> Jonathan Cast <[EMAIL PROTECTED]> writes:
> On Wed, 2007-09-26 at 09:05 +0200, Johan Tibell wrote:

> > If UTF-16 is what's used by everyone else (how about Java? Python?) I
> > think that's a strong reason to use it. I don't know Unicode well
> > enough to say otherwise.
> 
> I disagree.  I realize I'm a dissenter in this regard, but my position
> is: excellent Unix support first, portability second, excellent support
> for Win32/MacOS a distant third.  That seems to be the opposite of every
> language's position.  Unix absolutely needs UTF-8 for backward
> compatibility.

I think you're talking about different things, internal vs external 
representations.

Certainly we must support UTF-8 as an external representation. The choice of
internal representation is independent of that. It could be [Char] or some
memory efficient packed format in a standard encoding like UTF-8,16,32. The
choice depends mostly on ease of implementation and performance. Some formats
are easier/faster to process but there are also conversion costs so in some use
cases there is a performance benefit to the internal representation being the
same as the external representation.

So, the obvious choices of internal representation are UTF-8 and UTF-16. UTF-8
has the advantage of being the same as a common external representation so
conversion is cheap (only need to validate rather than copy). UTF-8 is more
compact for western languages but less compact for eastern languages compared to
UTF-16. UTF-8 is a more complex encoding in the common cases than UTF-16. In the
common case UTF-16 is effectively fixed width. According to the ICU implementors
this has speed advantages (probably due to branch prediction and smaller code 
size).

One solution is to do both and benchmark them.

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

Re: [Haskell-cafe] Troubles understanding memoization in SOE

[Don Stewart]

paul.hudak:
> Henning Thielemann wrote:
> >On Wed, 26 Sep 2007, Peter Verswyvelen wrote:
> >>I hope I won't come to the conclusion that after one year learning 
> >>the cool lazy functional programming language Haskell (which I want 
> >>to use for making simple videogames in a clean way for teaching),
> >I haven't tested it, but know of the existence of "Haskell in Space":
> >  http://www.informatik.uni-bremen.de/~cxl/lehre/pi3.ws01/asteroids/
> 
> Also see these two:
> 
> http://www.haskell.org/haskellwiki/Frag
> http://haskell.org/yale/papers/haskell-workshop03/index.html
> 

And don't forget these three games that got mentioned during the week.

Octane Mech:

http://berlinbrowndev.blogspot.com/2007/09/octane-mech-opengl-haskell-based-mech.html

OpenGL Tetris:
http://myawesomeblag.blogspot.com/2007/03/opengl-tetris-in-haskell.html

Games in Haskell video:
http://www.londonhug.net/2007/09/21/games-in-haskell-video-now-available/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] PROPOSAL: New efficient Unicode string library.

[Jonathan Cast]

On Wed, 2007-09-26 at 09:05 +0200, Johan Tibell wrote:
> > I'll look over the proposal more carefully when I get time, but the
> > most important issue is to not let the storage type leak into the
> > interface.
> 
> Agreed,
> 
> >  From an implementation point of view, UTF-16 is the most efficient
> > representation for processing Unicode. It's the native Unicode
> > representation for Windows, Mac OS X, and the ICU open source i18n
> > library. UTF-8 is not very efficient for anything except English. Its
> > most valuable property is compatibility with software that thinks of
> > character strings as byte arrays, and in fact that's why it was
> > invented.
> 
> If UTF-16 is what's used by everyone else (how about Java? Python?) I
> think that's a strong reason to use it. I don't know Unicode well
> enough to say otherwise.

I disagree.  I realize I'm a dissenter in this regard, but my position
is: excellent Unix support first, portability second, excellent support
for Win32/MacOS a distant third.  That seems to be the opposite of every
language's position.  Unix absolutely needs UTF-8 for backward
compatibility.

jcc


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

Re: [Haskell-cafe] Haskell Cheat Sheet?

[Jonathan Cast]

On Tue, 2007-09-25 at 17:19 -0700, Dan Weston wrote:
> One suggestion:
> 
> Section 3.6 defines a function "fix":
> 
>   fix :: Eq x => (x -> x) -> x -> x
> 
>   fix f x = if x == x' then x else fix f x'
>   where x' = f x
> 
> This confusingly differs in both type and meaning from the traditional 
> function Control.Monad.Fix.fix and is not even used elsewhere in the 
> document.
> 
> I suggest that it be removed and the real Control.Monad.Fix.fix function 
> be defined in its own section, with an side-by-side comparison with a 
> named recursive function. This would be useful because the type
> 
> fix :: (a -> a) -> a
> 
> is highly confusing, suggesting to newcomers a usage like:
> 
> f = fix (+1)
> 
> which is undefined (and seems to be "missing an argument"), when 
> invariably its type is in practice restricted to:
> 
> fix :: ((a -> b) -> (a -> b)) -> (a -> b)
> 
> which is much more suggestive (but nowhere to be found in the docs).

Not invariably.  I frequently use fix at monadic types, sometimes with
an argument but not always.

jcc


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

Re: [Haskell-cafe] unsafePerformIO: are we safe?

[Adrian Hey]

Sebastian Sylvan wrote:

Rule of thumb: If your name isn't Simon*, you shouldn't use unsafePerformIO.


If this is so, maybe it's time someone (who may or may not be called
Simon) gave us a realistic alternative.

:-)

Regards
--
Adrian Hey


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

Re: [Haskell-cafe] unsafePerformIO: are we safe?

[David Roundy]

On Wed, Sep 26, 2007 at 11:43:15AM -0300, Jorge Marques Pelizzoni wrote:
> 
> Hi, all!
> 
> This is a newbie question: I sort of understand what unsafePerformIO does
> but I don't quite get its consequences. In short: how safe can one be in
> face of it? I mean, conceptually, it allows any Haskell function to have
> side effects just as in any imperative language, doesn't it? Doesn't it
> blow up referential transparency for good? Is there anything intrinsic to
> it that still keeps Haskell "sound" no matter what unsafePerformIO users
> do (unlikely) or else what are the guidelines we should follow when using
> it?

unsafePerformIO *is* unsafe, but it can be safely used.

For instance, Data.Bytestring uses unsafePerformIO to access memory in byte
arrays, but since that memory is hidden within a bytestring, so long as
Data.Bytestring itself is bugfree (which I believe it is), referential
transparency is preserved, and everything is fine.  Actually, this is
*almost* true.  There is a function to mmap a file into a bytestring, and
the result is only referentially transparent if that file doesn't change.
But in any case, one can judge the correctness of the code by examining
only Data.Bytestring and its exported API.  Data.Bytestring also exports (I
believe) some unsafe* functions that are also unsafe, but that's generally
considered okay, with the assumption that it's the responsibility of anyone
using an "unsafe" function to determine what criteria are required in order
to preserve referential transparency, and general safety and sanity.

In short, any use of unsafePerformIO should be encapsulated within a
module, with an exported API that preserves safety (with possible exception
of unsafe*-named functions, which ideally should be documented in regard to
precisely what is required to use them safely).

The general rule with unsafe functions is that if you don't understand
what's required to use them safely, you shouldn't use them.
-- 
David Roundy
Department of Physics
Oregon State University
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] unsafePerformIO: are we safe?

[Sebastian Sylvan]

On 26/09/2007, Jorge Marques Pelizzoni <[EMAIL PROTECTED]> wrote:
>
> Hi, all!
>
> This is a newbie question: I sort of understand what unsafePerformIO does
> but I don't quite get its consequences. In short: how safe can one be in
> face of it? I mean, conceptually, it allows any Haskell function to have
> side effects just as in any imperative language, doesn't it? Doesn't it
> blow up referential transparency for good? Is there anything intrinsic to
> it that still keeps Haskell "sound" no matter what unsafePerformIO users
> do (unlikely) or else what are the guidelines we should follow when using
> it?
>

Rule of thumb: If your name isn't Simon*, you shouldn't use unsafePerformIO.


*
http://research.microsoft.com/~simonpj/
https://research.microsoft.com/~simonmar/


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

[Haskell-cafe] Sending email from a Haskell program

[Peter Gammie]

Hello,

Does anyone have a library for sending email from a Haskell program?  
I'd like something portable and cabalised.


I note there is code in darcs to send email on Windows and UNIX-y  
systems, and also something in WASH (I know not what). Apparently  
there is an SMTP server of some kind (?) in HAppS, but I want to re- 
use the system's MTA.


BTW is anyone else looking at the darcs codebase and thinking that  
there are many useful libraries lurking there?


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

[Haskell-cafe] unsafePerformIO: are we safe?

[Jorge Marques Pelizzoni]

Hi, all!

This is a newbie question: I sort of understand what unsafePerformIO does
but I don't quite get its consequences. In short: how safe can one be in
face of it? I mean, conceptually, it allows any Haskell function to have
side effects just as in any imperative language, doesn't it? Doesn't it
blow up referential transparency for good? Is there anything intrinsic to
it that still keeps Haskell "sound" no matter what unsafePerformIO users
do (unlikely) or else what are the guidelines we should follow when using
it?

Thanks in advance. Cheers,

Jorge.

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

RE: [Haskell-cafe] YI on Windows?

[Bayley, Alistair]

> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Peter 
> Verswyvelen
> 
> I retrieved the latest version of YI, but I failed to compile 
> it for Windows (GHC 6.6.1, and I got alex-2.1.0, haddock-0.8, 
> HsColour, GTK, but not VTY)
> 
> Before even pasting the error log, is it supported in Windows? 

Yi uses hs-plugins, and, last time I looked, hs-plugins was broken under
ghc-6.6 (&.1) on Windows.

I'm interested in hs-plugins on Windows (XP); does anyone know what it's
status is? Is it meant to be working? Does it work for others?

Alistair
*
Confidentiality Note: The information contained in this message,
and any attachments, may contain confidential and/or privileged
material. It is intended solely for the person(s) or entity to
which it is addressed. Any review, retransmission, dissemination,
or taking of any action in reliance upon this information by
persons or entities other than the intended recipient(s) is
prohibited. If you received this in error, please contact the
sender and delete the material from any computer.
*
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Does Haddock respect hiding?

[Adrian Hey]

Hello folks,

Using Haddock 0.8, if I use haddock to document a module like this..

module MyModule
( module MyOtherModule
) where

import MyOtherModule hiding (foo)


I still get foo documented in the API for MyModule, despite the
fact that foo is not really made available by importing MyModule.

This looks like a bug to me, or maybe there's something else I
should be doing. Anyone care to comment?

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

[Haskell-cafe] YI on Windows?

[Peter Verswyvelen]

I retrieved the latest version of YI, but I failed to compile it for Windows
(GHC 6.6.1, and I got alex-2.1.0, haddock-0.8, HsColour, GTK, but not VTY)

 

Before even pasting the error log, is it supported in Windows? 

 

I see that "make" gave the error "ghc.exe: unknown package: unix" and some
more errors.

 

"make emacs" worked better, but failed starting "dist/build/yi/yi -B. -fgtk
--as=emacs" with the error "\driver\package.conf.inplaceonf as c:\app\ghc"

 

Thanks,

Peter

 

BTW: I was using MinGW/Msys

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

RE: [Haskell-cafe] Re: GHC 6.7 on Windows / containers-0.1 package?

[Peter Verswyvelen]

Super, really looking forward to GHC 6.8.1 then. Is it ready for primetime
on Windows?

Again, someone should really build an IDE around all these goodies, but yes,
that is a massive undertaking.

Cheers,
Peter

> The debugger in 6.8.1 can also help to track down loops and deadlocks.
Set 
> -fbreak-on-error, run the program using :trace, and hit Control-C when it 
> hangs.  Then :history will give you a list of the most recently-visited 
> points in your program, so you can step back and inspect the values of 
> variables.

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

RE: [Haskell-cafe] Troubles understanding memoization in SOE

[Peter Verswyvelen]

Thanks for the nice feedback. I think I know enough to tackle these papers
now, although I'm sure it will take a while ;)

For a really simple and easy approach that only uses basic Haskell,
http://www.geocities.jp/takascience/haskell/monadius_en.html

This is a remake of the Konami game that was the cause of my videogame
"addiction" :)

Cheers,
Peter

-Original Message-
From: Paul Hudak [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, September 26, 2007 2:39 PM
To: Peter Verswyvelen
Cc: Henning Thielemann; Haskell-Cafe; [EMAIL PROTECTED]
Subject: Re: [Haskell-cafe] Troubles understanding memoization in SOE

Henning Thielemann wrote:
> On Wed, 26 Sep 2007, Peter Verswyvelen wrote:
>> I hope I won't come to the conclusion that after one year learning 
>> the cool lazy functional programming language Haskell (which I want 
>> to use for making simple videogames in a clean way for teaching),
> I haven't tested it, but know of the existence of "Haskell in Space":
>   http://www.informatik.uni-bremen.de/~cxl/lehre/pi3.ws01/asteroids/

Also see these two:

http://www.haskell.org/haskellwiki/Frag
http://haskell.org/yale/papers/haskell-workshop03/index.html

-Paul


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

RE: [Haskell-cafe] Troubles understanding memoization in SOE

[bf3]

Gee you are right, how embarrasing. I mistakenly read the signature of ***
just above &&&, which is

(***) :: Arrow a ⇒ a b c → a b’ c’ → a (b,b’) (c,c’)

Now just to me sure I get it right, *** results in an arrow that has two
inputs (b,b') and two outputs (c,c')?

> (&&&) :: Arrow (~>) => (b ~> c) -> (b ~> c') -> (b ~> (c, c'))

Hey that’s a nice trick, and it is valid Haskell :)

Peter

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
org] On Behalf Of Bertram Felgenhauer
Sent: Wednesday, September 26, 2007 2:06 PM
To: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Troubles understanding memoization in SOE

Peter Verswyvelen wrote:
> Paul L wrote:
> A minor detail in your paper: on page 7, you represent *(d) sf1 &&& sf2
*as
> a big box taking one input and producing two outputs. The input is
> internally split using a Y. This does not seem consistent with the other
> boxes (e.g. *first *or *loop *internally) that show two arrows for an
> incoming/outgoing pair, so I would say the outer box of &&& would also
have
> two inputs and two outputs.

But look at the type of &&&:
  (&&&) :: Arrow a => a b c -> a b c' -> a b (c, c')
or, perhaps more readable,
  (&&&) :: Arrow (~>) => (b ~> c) -> (b ~> c') -> (b ~> (c, c'))

As you can see, the resulting arrow of type (b ~> (c, c')) really has
only one input and produces a pair, i.e. two outputs. Internally it
must duplicate the b input somehow and apply it to both input arrows,
exactly as the box shows.

Bertram
___
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] Troubles understanding memoization in SOE

[Paul Hudak]

Henning Thielemann wrote:

On Wed, 26 Sep 2007, Peter Verswyvelen wrote:
I hope I won't come to the conclusion that after one year learning 
the cool lazy functional programming language Haskell (which I want 
to use for making simple videogames in a clean way for teaching),

I haven't tested it, but know of the existence of "Haskell in Space":
  http://www.informatik.uni-bremen.de/~cxl/lehre/pi3.ws01/asteroids/


Also see these two:

http://www.haskell.org/haskellwiki/Frag
http://haskell.org/yale/papers/haskell-workshop03/index.html

-Paul

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

[Haskell-cafe] Re: GHC 6.7 on Windows / containers-0.1 package?

[Simon Marlow]

Stefan O'Rear wrote:

On Wed, Sep 19, 2007 at 10:24:24PM +0100, Neil Mitchell wrote:

Hi Peter,


 So I grabbed ghc-6.7.20070824 (=the latest one for Windows I could find)
and the "extra-libs", compiled and installed the GLUT package (which I
needed), but when I compile my library, I get

 Could not find module `Data.Map':
   it is a member of package containers-0.1, which is hidden

All dependencies etc. have changed when going to 6.7/6.8 - you are
probably better off using 6.6.1 for now.

I also don't think that the debugger will help you track down infinite
loop style errors. You might be better off posting the code and asking
for help.


You said 0% CPU.  That's *very* important.  It means that you are using
the threaded runtime (GHCi?), and that you triggered a blackhole.  You
should be able to handle this by compiling your program with -prof (do
*not* use -threaded!), and running with +RTS -xc.  With luck, that will
give you a backtrace to the infinite loop.


As Stefan said, when the program hangs using 0% CPU, it probably means you 
have a "black hole".  A black hole is a particular kind of infinite loop; 
one that GHC detects.  In this case it has detected that the program is in 
a loop, but it hasn't managed to detect that the loop is a real deadlock - 
if it did, then you'd also get an exception ("<>").  The failure to 
deliver an exception happens in GHCi for subtle reasons that I've 
forgotten, it might even behave differently in GHC 6.8.1.


The debugger in 6.8.1 can also help to track down loops and deadlocks.  Set 
-fbreak-on-error, run the program using :trace, and hit Control-C when it 
hangs.  Then :history will give you a list of the most recently-visited 
points in your program, so you can step back and inspect the values of 
variables.


Cheers,
Simon

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

Re: [Haskell-cafe] Troubles understanding memoization in SOE

[Bertram Felgenhauer]

Peter Verswyvelen wrote:
> Paul L wrote:
> A minor detail in your paper: on page 7, you represent *(d) sf1 &&& sf2 *as 
> a big box taking one input and producing two outputs. The input is 
> internally split using a Y. This does not seem consistent with the other 
> boxes (e.g. *first *or *loop *internally) that show two arrows for an 
> incoming/outgoing pair, so I would say the outer box of &&& would also have 
> two inputs and two outputs.

But look at the type of &&&:
  (&&&) :: Arrow a => a b c -> a b c' -> a b (c, c')
or, perhaps more readable,
  (&&&) :: Arrow (~>) => (b ~> c) -> (b ~> c') -> (b ~> (c, c'))

As you can see, the resulting arrow of type (b ~> (c, c')) really has
only one input and produces a pair, i.e. two outputs. Internally it
must duplicate the b input somehow and apply it to both input arrows,
exactly as the box shows.

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

[Haskell-cafe] Re: C's fmod in Haskell

[Simon Marlow]

Henning Thielemann wrote:


See also
  
http://www.haskell.org/haskellwiki/Things_to_avoid#Forget_about_quot_and_rem 


OTOH, since quot/rem are the primitives in GHC, and div/mod are implemented 
in terms of them, then you might prefer to use quot/rem all other things 
being equal.


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

RE: [Haskell-cafe] Troubles understanding memoization in SOE

[Peter Verswyvelen]

That looks nice, but HGL does not work on Windows anymore does it?

Thanks,
Peter

-Original Message-
From: Henning Thielemann [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, September 26, 2007 11:44 AM
To: Peter Verswyvelen
Cc: Haskell-Cafe
Subject: Re: [Haskell-cafe] Troubles understanding memoization in SOE


On Wed, 26 Sep 2007, Peter Verswyvelen wrote:

> I hope I won't come to the conclusion that after one year learning the 
> cool lazy functional programming language Haskell (which I want to use 
> for making simple videogames in a clean way for teaching),

I haven't tested it, but know of the existence of "Haskell in Space":
   http://www.informatik.uni-bremen.de/~cxl/lehre/pi3.ws01/asteroids/

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

Re: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.

[Tony Finch]

On Wed, 26 Sep 2007, Aaron Denney wrote:
>
> It's true that time-wise there are definite issues in finding character
> boundaries.

UTF-16 has no advantage over UTF-8 in this respect, because of surrogate
pairs and combining characters. Code points, characters, and glyphs are
all different things, and it's very difficult to represent the latter two
as anything other than a string of code points.

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR
MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Math.Statistics

[Henning Thielemann]

On Wed, 26 Sep 2007, ChrisK wrote:


ok wrote:

There are a number of interesting issues raised by mbeddoe's
Math.Statistics.

data (Floating a, Ord a)
  => Simple_Continuous_Variate a
   = SCV [a] Int a a (Array Int a)

list_to_variate xs = SCV xs n m s o
  where n = length xs
m = sum xs / fromIntegral n
s = sum [(x - m)^2 | x <- xs] / fromIntegral (n - 1)
o = listArray (1,n) (sort xs)

vLength (SCV _ n _ _ _) = n
vMean   (SCV _ _ m _ _) = m
vSd (SCV _ _ _ s _) = s
vMin(SCV _ _ _ _ a) = a ! 1
vMax(SCV _ n _ _ a) = a ! n
vRange   scv= vMax scv - vMin scv
vMedian (SCV _ n _ _ a)
  | odd n   = a ! ((n+1)`div`2)
  | even n  = ((a ! l) + (a ! u))/2
  where l = n `div` 2
u = n - l
.


Math.Statistics eats many good names. I would also suggest offering a type class
interface.  Then you could operate on various containers besides a list:


If it's only about polymorphic list types, a type class for general list 
types may be enough. This works without multi-parameter type class.


http://software.complete.org/listlike/

Maybe it can be generalized to Foldable.

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

Re: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.

[Johan Tibell]

On 9/26/07, Aaron Denney <[EMAIL PROTECTED]> wrote:
> On 2007-09-26, Johan Tibell <[EMAIL PROTECTED]> wrote:
> > If UTF-16 is what's used by everyone else (how about Java? Python?) I
> > think that's a strong reason to use it. I don't know Unicode well
> > enough to say otherwise.
>
> The internal representations don't matter except in the case of making
> FFI linkages.  The external representations do, and UTF-8 has won on
> that front.

It could matter for performance. However, you can encode your
UnicodeString into any external representation you want for your I/O
needs, including UTF-8.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Math.Statistics

[Henning Thielemann]

On Wed, 26 Sep 2007, apfelmus wrote:


ok wrote:


I believe the author may have misunderstood "numerically stable".
The obvious (sum xs)/(fromIntegral $ length $ xs) is fine for
the mean,


That's probably my fault, out of ignorance. Do you know a good online 
resource about numeric stability? (I don't have the Knuth at home. Didn't he 
say something about the mean formula? Or was it the standard derivation?).


"standard deviation"? I expect that indeed variance (thus also standard 
deviation) by incremental computation suffers from cancellation.

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

Re: [Haskell-cafe] Desugaring of infix operators is (always?) the wrong way round

[Henning Thielemann]

On Tue, 25 Sep 2007, Brian Hulley wrote:


Ryan Ingram wrote:


A couple off the top of my head:

(:) :: a -> [a] -> [a]


Yes that's one that had totally slipped my mind ;-)


I like to add 'div' and 'mod' as examples for wrong argument order.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Troubles understanding memoization in SOE

[Henning Thielemann]

On Wed, 26 Sep 2007, Peter Verswyvelen wrote:

I hope I won't come to the conclusion that after one year learning the 
cool lazy functional programming language Haskell (which I want to use 
for making simple videogames in a clean way for teaching),


I haven't tested it, but know of the existence of "Haskell in Space":
  http://www.informatik.uni-bremen.de/~cxl/lehre/pi3.ws01/asteroids/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Desugaring of infix operators is (always?) the wrong way round

[Henning Thielemann]

On Tue, 25 Sep 2007, Brian Hulley wrote:

Of course the problem disappears if you just discard multiple clause syntax 
and use:


 (list :: a List) (f :: a -> b) map :: b List =
  case list of
  Empty -> Empty
  h t PushF -> (h f) (t f map) PushF


This would also have the advantage, that there is a name assigned to each 
parameter, which is nice for documentation purposes. However we would also 
have to assign a name to the parameter of 'f', and the (->) type 
constructor becomes somehow special, at least more special than it is now.



Curried functions like

f :: a -> b -> c

suggest a swapped order of arguments for (->), since 'f' must be called 
this way


b a f

Maybe it should be

f :: c <- b <- a
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ... on type theory and category theory

[jerzy . karczmarczuk]

I wonder why nobody mentioned this (yet; recently): 

Andrea Asperti and Giuseppe Longo 

Categories, Types and Structures. Category Theory for the working computer 
scientist. M.I.T. Press, 1991 

You don't have to buy it. Go here, and fetch the book: 

http://www.di.ens.fr/~longo/download.html 

== 

Jerzy Karczmarczuk 



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

Re: [Haskell-cafe] Troubles understanding memoization in SOE

[Peter Verswyvelen]

Paul L wrote:

We recently wrote a paper about the leak problem. The draft is at
http://www.cs.yale.edu/~hl293/download/leak.pdf. Comments are welcome!
Interesting. Now that I know the "basic Haskell" stuff these arrows make 
much more sense. However, they look *very* similar to a visual 
programming language and IDE my former colleagues and I developed for 
doing realtime particle effects on videogame consoles. This language 
contained special constructs to avoid space/time leaks, like a dedicated 
"feedback loop". I hope I won't come to the conclusion that after one 
year learning the cool lazy functional programming language Haskell 
(which I want to use for making simple videogames in a clean way for 
teaching), I got back from where I started :-) Of course that will not 
be the case, I'm really learning a lot. Even if it turns out Haskell is 
not really suitable for games, I will have learned a lot. However it is 
very important for my goal that the code looks very concise and clean, 
and having to chase hidden space/time leaks would ruin the elegance.


A minor detail in your paper: on page 7, you represent *(d) sf1 &&& sf2 
*as a big box taking one input and producing two outputs. The input is 
internally split using a Y. This does not seem consistent with the other 
boxes (e.g. *first *or *loop *internally) that show two arrows for an 
incoming/outgoing pair, so I would say the outer box of &&& would also 
have two inputs and two outputs.


Best regards,
Peter Verswyvelen





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

Re: [Haskell-cafe] Pierce on type theory and category theory

[Pablo Nogueira]

Another opinion in case you need more:

TAPL is excellent for self-study. There are solutions for most
interesting exercises. And every type system presented comes with a
downloadable implementation. You can practice with it and change it.
Do not hesitate to get it. I also recommend Cardelli's papers on types
which are free to obtain.

The Basic Category Theory book is, as the title says, "basic". It is a
sort of polished study notes (and I recall Pierce saying something
along this line in the introduction). Several examples and exercises
are taken from Goldblatt's "Topoi, the Categorical Analysis of Logic",
whose first chapters are a good starting point in Category theory but
he introduces category-theoretic concepts from set-theoretic ones and
it can be hard to abstract properly from one example.  Pierce's book
is well-written, introductory, there's nice stuff on cartesian closed
categories and F-algebras, and the best thing is its excellent
annotated bibliography which will help you to move on. Given its price
and size, I think its worth.

You'll need more stuff. There are books and tutorials out there.
MacLane I guess is a must, if only for breadth and precision. There's
Steve Awodey's book (Oxford University Press). I found Harold Simmon's
notes "Category Theory in four easy movements" enjoyable and readable,
especially the stuff on limits. Lawere's book mentioned by others is
also fun. Fokkinga has an excellent introduction to category theory
from a calculational standpoint, with notation and concepts used in
the Bananas paper. There is also Barr and Wells's third edition. And
of course, Mitchell's encyclopedic "Foundations for Programming
Languages".

To conclude, there are loads of sources and for self study, I'd
recommend to use several books and several tutorial notes, if only to
contrast approaches, definitions, to have exercises and solutions,
etc. And there's the wikipedia as well.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Math.Statistics

[apfelmus]

ok wrote:


I believe the author may have misunderstood "numerically stable".
The obvious (sum xs)/(fromIntegral $ length $ xs) is fine for
the mean,


That's probably my fault, out of ignorance. Do you know a good online 
resource about numeric stability? (I don't have the Knuth at home. 
Didn't he say something about the mean formula? Or was it the standard 
derivation?).


Regards,
apfelmus

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

Re: [Haskell-cafe] Desugaring of infix operators is (always?) the wrong way round

[Henning Thielemann]

On Tue, 25 Sep 2007, Dan Piponi wrote:


It's not so clear to me what the syntax for types should be in a postfix 
language.


Postfix, of course! So you'd write

data a Tree = Leaf | a a Tree

Confusingly, ocaml does something like this, with postfix notation for
types and prefix notation for function application.


I have seen the same mixing in Isabelle proof assistant.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Desugaring of infix operators is (always?) the wrong way round

[Henning Thielemann]

On Tue, 25 Sep 2007, Brian Hulley wrote:

To be consistent this would also have to apply to the use of (->) in types to 
get:


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


Since there are many type class instances for the Reader Monad, in this 
case the order of argument seems to be appropriate.


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

Re: [Haskell-cafe] Desugaring of infix operators is (always?) the wrong way round

[Henning Thielemann]

On Tue, 25 Sep 2007, Brian Hulley wrote:


Jonathan Cast wrote:


Of course, this is all a consequence of the well-known failure of
natural language: verbs come before their objects.  It is thus natural
to write f(x), when in fact it is the object that should come first, not
the function.  Switching to a (natural) language where (finite) verbs
come at the end of sentences, where they belong, should fix this issue
in time.  Doing the same in a functional language would be ideal as
well, but might limit its use among those who speak inferior natural
languages.

Thanks, I must look into using postfix notation. It's used in Forth and 
Postscript and I seem to dimly recall that there is a natural language 
somewhere that also uses it but I can't remember which one.


Reverse Polish! Ah no, it's only the Reverse Polish Notation which is in 
this style. ;-)


Yes, PostScript is nice, does also allow higher order functions and 
partial application.

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

[Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.

[Aaron Denney]

On 2007-09-26, Johan Tibell <[EMAIL PROTECTED]> wrote:
> If UTF-16 is what's used by everyone else (how about Java? Python?) I
> think that's a strong reason to use it. I don't know Unicode well
> enough to say otherwise.

The internal representations don't matter except in the case of making
FFI linkages.  The external representations do, and UTF-8 has won on
that front.

-- 
Aaron Denney
-><-

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

Re: [Haskell-cafe] C's fmod in Haskell

[Henning Thielemann]

On Wed, 26 Sep 2007, ok wrote:


[Concerning the fact that fmod(x,y) = -fmod(-x,y)]
I wrote:

Interesting, perhaps.  Surprising, no.  fmod() is basically there for
the sake of sin(), cos(), and tan() (or any other periodic and
either symmetric or antisymmetric function).


On 25 Sep 2007, at 8:58 pm, Henning Thielemann wrote:
Why is this particular behaviour useful in connection with trigonometric 
functions?


Range reduction.
sin(x) = sin(fmod(x, M_TWOPI)).

Whether that is the *best* way to handle range reduction is another
matter.


This would work with any reasonable definition of fmod, not only with the 
one, where fmod(-1, M_TWOPI) = -1. I still think that this particular 
definition is disadvantageous. Say, you want to implement a periodic 
function and you want to implement the core computation only for the 
smallest necessary range (say because of fast convergence), then with 
fmod(x, M_TWOPI) you have to add another case splitting, or you must 
implement it for the range (-M_TWOPI, M_TWOPI). If fmod(x,y) would 
generate the same sign as y, you had 0 <= fmod(x, M_TWOPI) < M_TWOPI.

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

Re: [Haskell-cafe] PROPOSAL: New efficient Unicode string library.

[Johan Tibell]

> I'll look over the proposal more carefully when I get time, but the
> most important issue is to not let the storage type leak into the
> interface.

Agreed,

>  From an implementation point of view, UTF-16 is the most efficient
> representation for processing Unicode. It's the native Unicode
> representation for Windows, Mac OS X, and the ICU open source i18n
> library. UTF-8 is not very efficient for anything except English. Its
> most valuable property is compatibility with software that thinks of
> character strings as byte arrays, and in fact that's why it was
> invented.

If UTF-16 is what's used by everyone else (how about Java? Python?) I
think that's a strong reason to use it. I don't know Unicode well
enough to say otherwise.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe