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

[Lars Viklund]

On Sun, May 11, 2008 at 02:59:32AM +0100, Eric Stansifer wrote:
> I definitely agree.  After I'd been learning Haskell for 6 months and
> then wrote a program in Java & C++, almost the first thing I did was
> code up a generic Maybe class in each language.  It is so much
> clearer and more obvious to _explicitly_ have no value
> (Maybe.Nothing()) as opposed to _implicitly_ having no value (null).
> Now I find my Java & C++ Maybe class indispensable when I am
> programming in those languages.

You may want to take a peek at the Boost.Optional [1] library in C++, which
provides a lovely Maybe-like class template called "optional".

[1] http://www.boost.org/doc/libs/1_35_0/libs/optional/doc/html/index.html

-- 
Lars Viklund | [EMAIL PROTECTED] | 070-310 47 07
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

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

[Eric Stansifer]

> IME "nullable by default" is one of the biggest
> sources of runtime crashes in high level OOP languages like C#, which is a
> shame because it really isn't that difficult to statically eliminate the
> vast majority of them, especially when you're sort of hand-waving the
> semantics of your language anyway and don't require it to be super
> rigorous...

I definitely agree.  After I'd been learning Haskell for 6 months and
then wrote a program in Java & C++, almost the first thing I did was
code up a generic Maybe class in each language.  It is so much
clearer and more obvious to _explicitly_ have no value
(Maybe.Nothing()) as opposed to _implicitly_ having no value (null).
Now I find my Java & C++ Maybe class indispensable when I am
programming in those languages.

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

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

[Brandon S. Allbery KF8NH]

On 2008 May 10, at 20:41, Philip Weaver wrote:

On Sat, May 10, 2008 at 3:10 PM, PR Stanley <[EMAIL PROTECTED]>  
wrote:


Um, I was encountering and recognizing times when I really needed an
out-of-band "null", and the pain of representing such in C, shortly
after I started serious programming in C (call it 1984-5).  Is this
really difficult?



  Paul: Hmm, I'm not quite sure what you're driving at.


Me neither.


Null pointers, EOF markers, didn't find specified key in some tree, etc.

--
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] Maybe a, The Rationale

[Sebastian Sylvan]

On Sat, May 10, 2008 at 11:36 PM, PR Stanley <[EMAIL PROTECTED]> wrote:

> Hi folks
>
>data Maybe a = Nothing | Just a
>
>What is the underlying rationale for the Maybe data type? is it the
> safe style of programming it encourages/
> Something tells me this is going to start a lengthy discussion. :-)
>Cheers, Paul
>
>
Sometimes you want to express things that can either be a value, or nothing.
In some languages all or most "values" (using that term loosely) can be
"nullable". E.g. in C# any reference can be nullable, so you can just return
null to signify "no value" (e.g. when looking someting up in a dictionary).
The problem with this is that every single dereference can no potentially
cause a runtime error, which pushes a whole lot of problems to the runtime,
when they really could be statically eliminated at compile time. Most
functions, after all, really do need all their parameters to "exist" and
aren't defined for null, and they really do return a result and never null,
so it's useful to know for sure that a "Map Int String" really is a map, and
not "null", while you still have the ability to deal with "optional" values
in the tiny minority of cases that need it.

Also, since it's impossible to actualy use a value without inspecting the
constructors of Maybe, you avoid even more runtime errors (unless you use
things like "fromJust"). IME "nullable by default" is one of the biggest
sources of runtime crashes in high level OOP languages like C#, which is a
shame because it really isn't that difficult to statically eliminate the
vast majority of them, especially when you're sort of hand-waving the
semantics of your language anyway and don't require it to be super
rigorous...


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

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

[Philip Weaver]

On Sat, May 10, 2008 at 3:10 PM, PR Stanley <[EMAIL PROTECTED]> wrote:
>
>   Paul: Hi folks
>
>   data Maybe a = Nothing | Just a
>
>   What is the underlying rationale for the Maybe data type?
> is it the
> safe style of programming it encourages/
> Something tells me this is going to start a lengthy discussion. :-)

   Bob: Pure and simple -- it allows you to represent partial
 functions.
 Looking up a map will only sometimes find a value, so we either
 return
 Nothing, or Just that value.
>>>
>>>   Paul: Would yu like to demonstrate this in an example?
>>
>>
>> Um, I was encountering and recognizing times when I really needed an
>> out-of-band "null", and the pain of representing such in C, shortly
>> after I started serious programming in C (call it 1984-5).  Is this
>> really difficult?
>
>
>Paul: Hmm, I'm not quite sure what you're driving at.
>
Me neither.
>Cheers, Paul
> ___
> 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] seeking advice on my POSIX wrapper

[Galchin, Vasili]

The Linux version of mqueue that I am using is implemented as a Linux
filesystem. I am reading now, Brandon.

V.

On Sat, May 10, 2008 at 4:09 PM, Brandon S. Allbery KF8NH <
[EMAIL PROTECTED]> wrote:

>
> On 2008 May 10, at 16:47, Galchin, Vasili wrote:
>
>  Last night I sent out an announcement about some POSIX work that I
> have been doing. In any case, one of the FFI wrappers is driving me crazy,
> i.e. the one for mq_receive:
> http://opengroup.org/onlinepubs/007908799/xsh/mq_receive.html  . When I
> call this function (mqReceive), I get "message too long". In my test cases I
> am sending and receiving messages that are only 11 bytes! The wrapper seems
> really straightforward. Perhaps  I am looking right at the problem and don't
> see. I need other eyes on the wrapper to help me ;^). Please see below.
>
>
> What's the other end sending?
>
> I suspect most implementations of mq_receive() layer it on top of msgrcv(),
> which can return E2BIG (== EMSGSIZE) if the message to be received is larger
> than the receiving buffer --- a condition which I note mq_receive() does not
> document (unless mq_msgsize means a given queue only supports fixed size
> messages, which seems odd).
>
> --
> 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] seeking advice on my POSIX wrapper

[Galchin, Vasili]

sender ..

main = do
 fd <- mqOpen "/myipc" ReadWrite (Just nullFileMode) (Just
(MQAttributes 0 128 128 0))
 mqSend fd "Hello world" 11 1
 (MQAttributes flags maxMsgNum maxMsgSize curNumMsgs) <-
mqGetAttributes fd
 putStrLn ("attrs flags->" ++ (show flags) ++ "  maxMsgNum -> " ++
(show maxMsgNum) ++ " maxMsgSize -> " ++ (show maxMsgSize) ++ "  curNumMsgs
-> " ++ (show curNumMsgs))
 mqClose fd
 return fd
~

-

receiver


main = do
 fd <- mqOpen "/myipc" ReadWrite (Just nullFileMode)  (Just
(MQAttributes  0 128 128 0))
 (MQAttributes flags maxMsgNum maxMsgSize curNumMsgs) <-
mqGetAttributes fd
 putStrLn ("attrs flags->" ++ (show flags) ++ "  maxMsgNum -> " ++
(show maxMsgNum) ++ " maxMsgSize -> " ++ (show maxMsgSize) ++ "  curNumMsgs
-> " ++ (show curNumMsgs))
 (MQAttributes flags maxMsgNum maxMsgSize curNumMsgs) <-
mqSetAttributes fd (MQAttributes{flags=0, maxMsgNum=127, maxMsgSize=127,
curNumMsgs=7})
 putStrLn ("attrs flags->" ++ (show flags) ++ "  maxMsgNum -> " ++
(show maxMsgNum) ++ " maxMsgSize -> " ++ (show maxMsgSize) ++ "  curNumMsgs
-> " ++ (show curNumMsgs))
 (s, n) <- mqReceive fd 60 Nothing
 putStrLn ("dump " ++ s)
 (s, n) <- mqReceive fd 11 (Just 1)
 putStrLn s
 mqClose fd
-- mqUnlink "/myipc"
 return fd
~

-

Thanks, Vasili



On Sat, May 10, 2008 at 4:09 PM, Brandon S. Allbery KF8NH <
[EMAIL PROTECTED]> wrote:

>
> On 2008 May 10, at 16:47, Galchin, Vasili wrote:
>
>  Last night I sent out an announcement about some POSIX work that I
> have been doing. In any case, one of the FFI wrappers is driving me crazy,
> i.e. the one for mq_receive:
> http://opengroup.org/onlinepubs/007908799/xsh/mq_receive.html  . When I
> call this function (mqReceive), I get "message too long". In my test cases I
> am sending and receiving messages that are only 11 bytes! The wrapper seems
> really straightforward. Perhaps  I am looking right at the problem and don't
> see. I need other eyes on the wrapper to help me ;^). Please see below.
>
>
> What's the other end sending?
>
> I suspect most implementations of mq_receive() layer it on top of msgrcv(),
> which can return E2BIG (== EMSGSIZE) if the message to be received is larger
> than the receiving buffer --- a condition which I note mq_receive() does not
> document (unless mq_msgsize means a given queue only supports fixed size
> messages, which seems odd).
>
> --
> 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] Maybe a, The Rationale

[PR Stanley]

   Paul: Hi folks

   data Maybe a = Nothing | Just a

   What is the underlying rationale for the Maybe data type?
is it the
safe style of programming it encourages/
Something tells me this is going to start a lengthy discussion. :-)


   Bob: Pure and simple -- it allows you to represent partial
functions.
Looking up a map will only sometimes find a value, so we either
return
Nothing, or Just that value.


   Paul: Would yu like to demonstrate this in an example?



Um, I was encountering and recognizing times when I really needed an
out-of-band "null", and the pain of representing such in C, shortly
after I started serious programming in C (call it 1984-5).  Is this
really difficult?



Paul: Hmm, I'm not quite sure what you're driving at.

Cheers, Paul 


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

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

[Brandon S. Allbery KF8NH]

On 2008 May 10, at 18:56, PR Stanley wrote:




   Paul: Hi folks

   data Maybe a = Nothing | Just a

   What is the underlying rationale for the Maybe data type?  
is it the

safe style of programming it encourages/
Something tells me this is going to start a lengthy discussion. :-)


   Bob: Pure and simple -- it allows you to represent partial  
functions.
Looking up a map will only sometimes find a value, so we either  
return

Nothing, or Just that value.


   Paul: Would yu like to demonstrate this in an example?



Um, I was encountering and recognizing times when I really needed an  
out-of-band "null", and the pain of representing such in C, shortly  
after I started serious programming in C (call it 1984-5).  Is this  
really difficult?


--
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] Maybe a, The Rationale

[Philip Weaver]

On Sat, May 10, 2008 at 3:56 PM, PR Stanley <[EMAIL PROTECTED]> wrote:
>
>>>Paul: Hi folks
>>>
>>>data Maybe a = Nothing | Just a
>>>
>>>What is the underlying rationale for the Maybe data type? is it
>>> the
>>> safe style of programming it encourages/
>>> Something tells me this is going to start a lengthy discussion. :-)
>>
>>Bob: Pure and simple -- it allows you to represent partial
>> functions.

Here's one simple example that popped into my head...

maybeHead :: [a] -> Maybe a
maybeHead [] = Nothing
maybeHead (x:xs) = Just x

>> Looking up a map will only sometimes find a value, so we either return
>> Nothing, or Just that value.
>
>Paul: Would yu like to demonstrate this in an example?
>
See the 'lookup' function (
http://haskell.org/ghc/docs/latest/html/libraries/base/Data-List.html#v%3Alookup
) or just abut any other function on Hoogle that uses a Maybe type.


>Cheers, Paul
> ___
> 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] Maybe a, The Rationale

[PR Stanley]

Paul: Hi folks

data Maybe a = Nothing | Just a

What is the underlying rationale for the Maybe data type? 
is it the

safe style of programming it encourages/
Something tells me this is going to start a lengthy discussion. :-)


Bob: Pure and simple -- it allows you to represent partial 
functions.

Looking up a map will only sometimes find a value, so we either return
Nothing, or Just that value.


Paul: Would yu like to demonstrate this in an example?

Cheers, Paul 


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

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

[Thomas Davie]

On 11 May 2008, at 00:36, PR Stanley wrote:


Hi folks

data Maybe a = Nothing | Just a

	What is the underlying rationale for the Maybe data type? is it the  
safe style of programming it encourages/

Something tells me this is going to start a lengthy discussion. :-)


Pure and simple -- it allows you to represent partial functions.   
Looking up a map will only sometimes find a value, so we either return  
Nothing, or Just that value.


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

[Haskell-cafe] Maybe a, The Rationale

[PR Stanley]

Hi folks

data Maybe a = Nothing | Just a

	What is the underlying rationale for the Maybe data type? is it the 
safe style of programming it encourages/

Something tells me this is going to start a lengthy discussion. :-)
Cheers, Paul

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

Re: [Haskell-cafe] haskell compiler on NetBSD amd64

[Don Stewart]

kili:
> http://openbsd.dead-parrot.de/distfiles/ghc-6.6.1-amd64-unknown-openbsd-hc.tar.bz2
> 
> I've to admit that the ghc port for OpenBSD is a little bit weird ;-)
> 
> (but not as weird as my current work on ghc-6.8 for OpenBSD)

What's your plan for the OpenBSD port, Kili?


> > as apparently 6.8 is known to not build from .hc files.  I don't
> > understand `with headers starting to diverge'.
> 
> Nor do I, but I guess Don meant significant differences in system
> libraries (between NetBSD and OpenBSD).


That's what I meant. When you take the .hc files from OpenBSD to NetBSD,
there's going to be some breakages in the C layer.

So better to do the x86 -> amd64 port, staying on NetBSD, I think.

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

Re: [Haskell-cafe] haskell compiler on NetBSD amd64

[Matthias Kilian]

On Sat, May 10, 2008 at 02:36:43PM -0700, Donn Cave wrote:
> > I wonder if it is still possible to use the .hc files already generated 
> > for the OpenBSD/amd64 port, and use those to do the port to
> > NetBSD/amd64.
> > 
> > http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/ghc/
> 
> That sounds fine to me, if I understand you right - I managed
> to install an OpenBSD partition this afternoon, but if I can
> skip that step, that's fine with me.  I don't see any .hc files
> at that link, though.

Here you go:

http://openbsd.dead-parrot.de/distfiles/ghc-6.6.1-amd64-unknown-openbsd-hc.tar.bz2

I've to admit that the ghc port for OpenBSD is a little bit weird ;-)

(but not as weird as my current work on ghc-6.8 for OpenBSD)

> > Actually, with headers starting to diverge, it might make more sense to
> > just generate the amd64/netbsd .hc files from i386/netbsd -- where
> > there's already a working ghc.
> 
> I have ghc 6.4.1 on NetBSD 3.0 i386.  That's the idea, right?

If possible, start with ghc 6.6.1, even if that means to install a
newer version of NetBSD.

> as apparently 6.8 is known to not build from .hc files.  I don't
> understand `with headers starting to diverge'.

Nor do I, but I guess Don meant significant differences in system
libraries (between NetBSD and OpenBSD).

Ciao,
Kili

-- 
Weg mit dieser verfluchten Demokratie wo alles das Wort führen will.
-- Georg Christoph Lichtenberg
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] haskell compiler on NetBSD amd64

[Donn Cave]

On Sat, 10 May 2008 12:13:16 -0700
Don Stewart <[EMAIL PROTECTED]> wrote:

> I wonder if it is still possible to use the .hc files already generated 
> for the OpenBSD/amd64 port, and use those to do the port to
> NetBSD/amd64.
> 
> http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/ghc/

That sounds fine to me, if I understand you right - I managed
to install an OpenBSD partition this afternoon, but if I can
skip that step, that's fine with me.  I don't see any .hc files
at that link, though.

> Actually, with headers starting to diverge, it might make more sense to
> just generate the amd64/netbsd .hc files from i386/netbsd -- where
> there's already a working ghc.

I have ghc 6.4.1 on NetBSD 3.0 i386.  That's the idea, right?  as
apparently 6.8 is known to not build from .hc files.  I don't
understand `with headers starting to diverge'.

Donn Cave, [EMAIL PROTECTED]

-- 
Donn Cave <[EMAIL PROTECTED]>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] seeking advice on my POSIX wrapper

[Brandon S. Allbery KF8NH]

On 2008 May 10, at 16:47, Galchin, Vasili wrote:

 Last night I sent out an announcement about some POSIX work  
that I have been doing. In any case, one of the FFI wrappers is  
driving me crazy, i.e. the one for mq_receive:http://opengroup.org/onlinepubs/007908799/xsh/mq_receive.html 
  . When I call this function (mqReceive), I get "message too long".  
In my test cases I am sending and receiving messages that are only  
11 bytes! The wrapper seems really straightforward. Perhaps  I am  
looking right at the problem and don't see. I need other eyes on the  
wrapper to help me ;^). Please see below.



What's the other end sending?

I suspect most implementations of mq_receive() layer it on top of  
msgrcv(), which can return E2BIG (== EMSGSIZE) if the message to be  
received is larger than the receiving buffer --- a condition which I  
note mq_receive() does not document (unless mq_msgsize means a given  
queue only supports fixed size messages, which seems odd).


--
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] seeking advice on my POSIX wrapper

[Bulat Ziganshin]

Hello Vasili,

Sunday, May 11, 2008, 12:47:52 AM, you wrote:

> . When I call this function (mqReceive), I get "message too long".

you can divide-and-conquer the problem by trying
1) write the C code that calls mq_receive with the same params
2) call your own function instead of mq_receive and printf parameters it
receives


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

[Haskell-cafe] seeking advice on my POSIX wrapper

[Galchin, Vasili]

Hello,

 Last night I sent out an announcement about some POSIX work that I have
been doing. In any case, one of the FFI wrappers is driving me crazy, i.e.
the one for mq_receive:
http://opengroup.org/onlinepubs/007908799/xsh/mq_receive.html  . When I call
this function (mqReceive), I get "message too long". In my test cases I am
sending and receiving messages that are only 11 bytes! The wrapper seems
really straightforward. Perhaps  I am looking right at the problem and don't
see. I need other eyes on the wrapper to help me ;^). Please see below.

Regards, V.

---


--  mqReceive is still being debugged!!

-- | Retrieve a message from mqueue designated by "mqd"
--
mqReceive :: Fd -> ByteCount -> Maybe Int -> IO (String, Int)
mqReceive (Fd mqd) len (Just prio) = do
allocaBytes (fromIntegral len) $ \ p_buffer -> do
  with (fromIntegral prio) $ \ p_prio -> do
rc <- throwErrnoIfMinus1 "mqReceive" (c_mq_receive mqd p_buffer
(fromIntegral len) p_prio)
case fromIntegral rc of
  0 -> ioError (IOError Nothing EOF "mqReceive" "EOF" Nothing)
  n -> do
   s <- peekCStringLen (p_buffer, fromIntegral n)
   return (s, n)
mqReceive (Fd mqd) len Nothing = do
allocaBytes (fromIntegral len) $ \ p_buffer -> do
  rc <- throwErrnoIfMinus1 "mqReceive" (c_mq_receive mqd p_buffer
(fromIntegral len) nullPtr)
  case fromIntegral rc of
0 -> ioError (IOError Nothing EOF "mqReceive" "EOF" Nothing)
n -> do
 s <- peekCStringLen (p_buffer, fromIntegral n)
 return (s, n)

foreign import ccall unsafe "mqueue.h mq_receive"
   c_mq_receive :: CInt -> Ptr CChar -> CSize -> Ptr CInt -> IO CInt
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] haskell compiler on NetBSD amd64

[Matthias Kilian]

On Sat, May 10, 2008 at 12:13:16PM -0700, Don Stewart wrote:
> I wonder if it is still possible to use the .hc files already generated 
> for the OpenBSD/amd64 port, and use those to do the port to
> NetBSD/amd64.
> 
> http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/ghc/

If nobody tries, we'll never know.

Ciao,
Kili

-- 
> Do with this info and this argument what u will - as u always do.
Delete it.
-- Jeffrey Lim and Theo de Raadt in "The famous t-shirt thread"
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] haskell compiler on NetBSD amd64

[Don Stewart]

emil.skoldberg:
> On Fri, May 09, 2008 at 10:21:19PM -0700, Donn Cave wrote:
> > So here I am with 64 bit Athlon hardware, running amd64
> > NetBSD (a.k.a. x86_64), reasonably motivated to compile
> > Haskell.  From what I make of the porting instructions,
> 
> So, we are in the same boat then!
> 
> > my only hope is to install FreeBSD-amd64 on another
> > partition and download the 6.6.1 ghc for that platform,
> > use it to generate .hc files to build 6.6.1 on NetBSD,
> > and then use 6.6.1 to build 6.8 or whatever the current
> > version may be by the time I get there?
> > 
> 
> But what I thought was rather to go with OpenBSD, since I
> figured that it would be closer to NetBSD (You can e.g. build
> ghc on OpenBSD using NetBSD-generated .hc files on i386),
> and generate the .hc files on OpenBSD. I have unfortunately
> not got any further than getting an openbsd partition though,
> have not had the time to get into the actual porting.

I wonder if it is still possible to use the .hc files already generated 
for the OpenBSD/amd64 port, and use those to do the port to
NetBSD/amd64.

http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/ghc/

Actually, with headers starting to diverge, it might make more sense to
just generate the amd64/netbsd .hc files from i386/netbsd -- where
there's already a working ghc.

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

Re: [Haskell-cafe] Old editions of The Monad.Reader lost

[Gwern Branwen]

On 2008.05.10 12:17:45 +0100, Wouter Swierstra <[EMAIL PROTECTED]> scribbled 
0.4K characters:
>> Almost all? Is that why some are missing? eg.
>>  omits
>> "Impure Thoughts 1 - Thtatic Compilathionth (without a lisp) "
>> .
>
> Philippa did not want her articles published under the new license - that's
> why they haven't been added. Hope this clears things up,
>
>   Wouter

I see; that was what I thought, but there was no note explicitly saying so. 
I'll go add them.

--
gwern
SRI d DIA Tangimoana ssor IDP Pesec VIP Schengen timers


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

Re: [Haskell-cafe] Copy on read

[Malcolm Wallace]

If Haskell had uniqueness typing, maybe the compiler could be made  
to infer when values are used in a unique way. And maybe if the  
compiler can detect data being used in a unique way, it could code  
for in-place updates instead of copying, and thereby gain a  
performance advantage.


Uniqueness typing does not lead to in-place update.  If a value is  
only used once, then there is no need to update it at all!  In fact, I  
believe ghc does this analysis, and has a minor optimisation that  
omits the thunk-update.  That is, if an unevaluated thunk is forced,  
but it has a unique usage, the original thunk is not overwritten with  
an indirection to the reduced value (as it normally would be), but the  
reduced value is just used directly.


I believe that rather than _uniqueness_, you are really trying to  
describe _linear_ usage, that is, multiple uses, but in a single non- 
branching sequence.  Single-threaded usage of a data structure might  
permit in-place modification of its parts.  The analysis for linear  
usage is much more difficult than for uniqueness, and David Wakeling's  
PhD Thesis "Linearity and Laziness" (circa 1990) did some experiments,  
but was ultimately pessimistic about the value.


Regards,
   Malcolm

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

Re[2]: [Haskell-cafe] Type unions

[Bulat Ziganshin]

Hello Eric,

Saturday, May 10, 2008, 8:26:27 PM, you wrote:

> Thank you -- looking at Printf was very helpful.  My syntax is much
> happier as a result.

btw, i also recommend to look into HsLua[1] which uses type classes in
very smart and elegant way to automatically convert between Haskell
and Lua data types

[1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hslua


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

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

Re: [Haskell-cafe] Type unions

[Eric Stansifer]

> Try making a type class for the functions.  That will allow you both varargs
> and unions.
> Have a look at Text.Printf.

Thank you -- looking at Printf was very helpful.  My syntax is much
happier as a result.

I also see now that I am approaching the problem from the wrong
direction -- that by writing a whole slew of functions whose behavior
depends arbitrarily upon their argument type, I would need to code the
desired behavior for each function and each argument type;  getting
hung up on making the syntax manageable hid this realization from me.
The solution is for me to try much harder to extract common behavior
across argument types and only code special cases when truly
necessary.

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

Re: [Haskell-cafe] Copy on read

[Neil Mitchell]

Hi

You're not the first:

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.

Like I said to them in private mail - nice idea, but without
benchmarks its only an idea. You have to consider effects of cache,
generational garbage collection, complexity etc. I think they are
going to do the benchmarks at some point, when we'll know if the idea
was a good one.

Thanks

Neil

On Sat, May 10, 2008 at 1:42 PM, Andrew Coppin
<[EMAIL PROTECTED]> wrote:
> I just had a random idea, which I thought I'd share with you all.
>
> I've heard about systems that do "copy on write". That is, all users share a
> single copy of some structure, until somebody tries to write on it. At that
> moment they get a personal copy to modify so they don't upset everybody
> else. This way, you don't have to go to all the expense of copying a
> potentially large structure unless it's actually necessary to do so.
>
> Then I started thinking about Clean's "uniqueness typing". If I'm
> understanding this correctly, it lets you do things like mutate data
> in-place without requiring a monad. The restriction is that the compiler has
> to be satisfied, at compile-time, that you will never try to access the old
> data you just overwrote.
>
> Although I once held more optimistic beliefs, as far as I can tell no
> current, real-world Haskell implementation ever mutates the fields of
> algebraic data types in-place. (Ignoring for a moment the issue of
> overwriting a thunk with it's result.) This strikes me as rather
> pessimistic. I was thinking... If Haskell had uniqueness typing, maybe the
> compiler could be made to infer when values are used in a unique way. And
> maybe if the compiler can detect data being used in a unique way, it could
> code for in-place updates instead of copying, and thereby gain a performance
> advantage.
>
> I don't know how viable this would be - the thing that immediately jumps out
> at me is that in practice there might be comparatively few places where you
> can *guarantee* the transformation is safe, and so it might not get applied
> very much. And considering all this would likely take a fair bit of work on
> the compiler, that wouldn't be a great payoff. Still, the idea of the
> compiler transparently rewriting your pure functional code to efficient
> mutable updates (when safe) is very appealing for performance reasons.
>
> Thoughts, people? [I'd be surprised if I'm the first person ever to have
> this idea...]
>
> ___
> 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] Type unions

[Lennart Augustsson]

Try making a type class for the functions.  That will allow you both varargs
and unions.
Have a look at Text.Printf.

  -- Lennart

On Sat, May 10, 2008 at 1:28 PM, Eric Stansifer <[EMAIL PROTECTED]>
wrote:

> I have been trying to write a DSL for Povray (see www.povray.org) in
> Haskell, using the technique of:
> http://okmij.org/ftp/papers/tagless-final-APLAS.pdf
> with some inspiration taken from
> http://okmij.org/ftp/Haskell/DSLSharing.hs
>
> The Povray Scene Description Language is a very declarative language,
> with few high level constructs (even loops take a bit of work) --
> which is why I'm putting it in Haskell.
>
> At one point, I needed a "varargs" function for the DSL, a function f
> :: b -> a -> b dressed up to take a variable number of 'a's, known at
> compile time.  This was easy enough:
>
> > data Nil a = Nil
> > data Cons b a = a ::: b a
> > infixr 1 :::
> >
> > class VarArgs v where
> >   apply_args :: (s -> a -> s) -> s -> v a -> s
> >
> > instance VarArgs Nil where
> >   apply_args _ start _ = start
> >
> > instance VarArgs b => VarArgs (Cons b) where
> >   apply_args f start (a ::: b) = apply_args f (f start a) b
>
> The solution is quite workable:  I can simply write the following, and
> I believe the summation is expanded out at compile-time:
>
> > apply_args (+) 0 (2 ::: 3 ::: 8 ::: 1 ::: (-3) ::: Nil)
>
> But I found I also needed a function to take a union type -- that is,
> the function would either take an argument of type T1, or of type T2,
> known at compile time.  I tried a similar technique as I tried with
> varargs, and unfortunately ended up with this:
>
> > data LeftOf a b = L a
> > data RightOf a b = R b
> >
> > class Union u where
> >   apply_union :: (a -> c) -> (b -> c) -> (u a b) -> c
> >
> > instance Union LeftOf where
> >   apply_union f _ (L a) = f a
> >
> > instance Union RightOf where
> >   apply_union _ g (R b) = g b
> >
> > type A = Integer
> > type B = String
> > type C = ()
> >
> > type Union_ABC u1 u2 = u1 A (u2 B C)
> >
> > f_A = show . (+ 3)
> > f_B = reverse
> > f_C = const "unit"
> >
> > f :: (Union u1, Union u2) => Union_ABC u1 u2 -> String
> > f = apply_union f_A (apply_union f_B f_C)
> >
> > main = do
> >   putStrLn $ f $ (L 6 :: Union_ABC LeftOne LeftOne)
> >   putStrLn $ f $ R (L "hello, world")
> >   putStrLn $ f $ R (R ())
>
> Notice a lot of ugliness in my example:  e.g., the definition of f,
> the type signature of f (I can't move the context into the
> type-synonym Union_ABC), creating objects of the union type, and the
> unpleasant surprise that I needed to provide the type of 'L 6'.  This
> solution is very not-scalable:  the Povray SDL is a "messy" language,
> and for my DSL I would need approximately 20 or 30 such unions, each a
> union of about 20 types (admittedly with a lot of overlap from union
> to union).
>
> I think the solution is to abandon the lofty ideal of statically
> determining argument types;  instead have a universal type with tags
> to distinguish types dynamically:
>
> > data Universal = UA A | UB B | UC C
> > f :: Universal -> String
> > f (UA a) = f_A a
> > f (UB b) = f_B b
> > f (UC c) = f_C c
> >
> > main2 = do
> >   putStrLn $ f $ UA 6
> >   putStrLn $ f $ UB "hello, world"
> >   putStrLn $ f $ UC ()
>
> ...but I'm not ready to give up hope yet.  Suggestions please?
>
> Eric
> ___
> 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] Order of Evaluation

[Daniil Elovkov]

Hello

You may find this paper useful

http://research.microsoft.com/~simonpj/Papers/spineless-tagless-gmachine.ps.gz

It should give you the general feeling of how things are actually executed.

It's quite old, some things in GHC have changed, but the overall scheme, 
I believe, is the same. The competent people will correct me, if I'm wrong.




PR Stanley wrote:

Hi
 (take 4 . map (>0)) (f s t)
 where
s = 2 : t
t = 3 : s
 f = zipWith (-)
What would be the order of evaluation for the above code? How would I 
illustrate the evaluation step-by-step?
I'm guessing that  the code necessitates lazy evaluation and as such it 
starts with take then it applies f which in turn applies s and t and 
zipWith until the first element satisfies the predicate in map and This 
is repeated 4 times

What does the list think?
Many thanks,
Paul
P.S. I'm not done with induction. I'm just letting it rst for a bit.

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

[Haskell-cafe] Copy on read

[Andrew Coppin]

I just had a random idea, which I thought I'd share with you all.

I've heard about systems that do "copy on write". That is, all users 
share a single copy of some structure, until somebody tries to write on 
it. At that moment they get a personal copy to modify so they don't 
upset everybody else. This way, you don't have to go to all the expense 
of copying a potentially large structure unless it's actually necessary 
to do so.


Then I started thinking about Clean's "uniqueness typing". If I'm 
understanding this correctly, it lets you do things like mutate data 
in-place without requiring a monad. The restriction is that the compiler 
has to be satisfied, at compile-time, that you will never try to access 
the old data you just overwrote.


Although I once held more optimistic beliefs, as far as I can tell no 
current, real-world Haskell implementation ever mutates the fields of 
algebraic data types in-place. (Ignoring for a moment the issue of 
overwriting a thunk with it's result.) This strikes me as rather 
pessimistic. I was thinking... If Haskell had uniqueness typing, maybe 
the compiler could be made to infer when values are used in a unique 
way. And maybe if the compiler can detect data being used in a unique 
way, it could code for in-place updates instead of copying, and thereby 
gain a performance advantage.


I don't know how viable this would be - the thing that immediately jumps 
out at me is that in practice there might be comparatively few places 
where you can *guarantee* the transformation is safe, and so it might 
not get applied very much. And considering all this would likely take a 
fair bit of work on the compiler, that wouldn't be a great payoff. 
Still, the idea of the compiler transparently rewriting your pure 
functional code to efficient mutable updates (when safe) is very 
appealing for performance reasons.


Thoughts, people? [I'd be surprised if I'm the first person ever to have 
this idea...]


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

[Haskell-cafe] Type unions

[Eric Stansifer]

I have been trying to write a DSL for Povray (see www.povray.org) in
Haskell, using the technique of:
http://okmij.org/ftp/papers/tagless-final-APLAS.pdf
with some inspiration taken from
http://okmij.org/ftp/Haskell/DSLSharing.hs

The Povray Scene Description Language is a very declarative language,
with few high level constructs (even loops take a bit of work) --
which is why I'm putting it in Haskell.

At one point, I needed a "varargs" function for the DSL, a function f
:: b -> a -> b dressed up to take a variable number of 'a's, known at
compile time.  This was easy enough:

> data Nil a = Nil
> data Cons b a = a ::: b a
> infixr 1 :::
>
> class VarArgs v where
>   apply_args :: (s -> a -> s) -> s -> v a -> s
>
> instance VarArgs Nil where
>   apply_args _ start _ = start
>
> instance VarArgs b => VarArgs (Cons b) where
>   apply_args f start (a ::: b) = apply_args f (f start a) b

The solution is quite workable:  I can simply write the following, and
I believe the summation is expanded out at compile-time:

> apply_args (+) 0 (2 ::: 3 ::: 8 ::: 1 ::: (-3) ::: Nil)

But I found I also needed a function to take a union type -- that is,
the function would either take an argument of type T1, or of type T2,
known at compile time.  I tried a similar technique as I tried with
varargs, and unfortunately ended up with this:

> data LeftOf a b = L a
> data RightOf a b = R b
>
> class Union u where
>   apply_union :: (a -> c) -> (b -> c) -> (u a b) -> c
>
> instance Union LeftOf where
>   apply_union f _ (L a) = f a
>
> instance Union RightOf where
>   apply_union _ g (R b) = g b
>
> type A = Integer
> type B = String
> type C = ()
>
> type Union_ABC u1 u2 = u1 A (u2 B C)
>
> f_A = show . (+ 3)
> f_B = reverse
> f_C = const "unit"
>
> f :: (Union u1, Union u2) => Union_ABC u1 u2 -> String
> f = apply_union f_A (apply_union f_B f_C)
>
> main = do
>   putStrLn $ f $ (L 6 :: Union_ABC LeftOne LeftOne)
>   putStrLn $ f $ R (L "hello, world")
>   putStrLn $ f $ R (R ())

Notice a lot of ugliness in my example:  e.g., the definition of f,
the type signature of f (I can't move the context into the
type-synonym Union_ABC), creating objects of the union type, and the
unpleasant surprise that I needed to provide the type of 'L 6'.  This
solution is very not-scalable:  the Povray SDL is a "messy" language,
and for my DSL I would need approximately 20 or 30 such unions, each a
union of about 20 types (admittedly with a lot of overlap from union
to union).

I think the solution is to abandon the lofty ideal of statically
determining argument types;  instead have a universal type with tags
to distinguish types dynamically:

> data Universal = UA A | UB B | UC C
> f :: Universal -> String
> f (UA a) = f_A a
> f (UB b) = f_B b
> f (UC c) = f_C c
>
> main2 = do
>   putStrLn $ f $ UA 6
>   putStrLn $ f $ UB "hello, world"
>   putStrLn $ f $ UC ()

...but I'm not ready to give up hope yet.  Suggestions please?

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

Re: [Haskell-cafe] List concat

[Ross Paterson]

On Fri, May 09, 2008 at 11:04:26PM +0100, Lennart Augustsson wrote:
> There are many implementations of such things.  Data.Sequence is one.  You can
> also make an implementation that has O(1) cons, snoc, and append, but that's
> rather tricky and has a large constant factor.

It's also rather difficult to construct a use case that distinguishes
between O(1) and O(log(min(n1,n2))) append.  For example, building a
sequence with either sort of append takes linear time.  The constant
factors are everything.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] List concat

[Andrew Coppin]

Lennart Augustsson wrote:
There are many implementations of such things.  Data.Sequence is one.  
You can also make an implementation that has O(1) cons, snoc, and 
append, but that's rather tricky and has a large constant factor.


Ah. So not only is it possible, but it's already in a standard library. 
I had a feeling this might be the case...


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

Re: Re[2]: [Haskell-cafe] I am new to haskell

[Giorgio Valoti]

On 09/mag/08, at 13:59, Benjamin L. Russell wrote:


[…]


i recommend you to read papers from the
http://haskell.org/haskellwiki/Learning_Haskell
page, in particular those in Advanced tutorials, Monads,
Type classes,
Popular libraries sections


That is one idea.  Also, since The Haskell School of Expression (http://www.haskell.org/soe/ 
), by Paul Hudak, is sometimes regarded as easier to read as a  
second book on Haskell, you could read that, too.


I think I’ll get the book. Thank you for the suggestions!


[…]




Ciao
--
Giorgio Valoti



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

Re: [Haskell-cafe] unsafeInterleaveIO and OpenGL

[Peter Verswyvelen]

Sounds reasonable. 'unsafeInterleaveIO' defers computation of 'vp' 
until it is actually needed. At this time the viewport might have 
changed.
That sound reasonable indeed, but the viewport does not change and the 
values I get are really random. I'll try to make minimal example to 
demonstrate the problem.


Thanks,
Peter

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

Re: [Haskell-cafe] Old editions of The Monad.Reader lost

[Wouter Swierstra]

Almost all? Is that why some are missing? eg.
 omits
"Impure Thoughts 1 - Thtatic Compilathionth (without a lisp) "
.


Philippa did not want her articles published under the new license -  
that's why they haven't been added. Hope this clears things up,


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

[Haskell-cafe] Re: inserting values in a binary tree

[Achim Schneider]

PR Stanley <[EMAIL PROTECTED]> wrote:

> Actually, you've touched an important point there. It's balancing 
> that I'm having difficulty with.
> Paul

http://en.wikipedia.org/wiki/Tree_rotation is the key to all this: It
changes the tree structure without changing the tree ordering.

rotr (Node (Node a p b) q c) = Node a p $ Node b q c

untested, mind you.


> At 23:46 09/05/2008, you wrote:
> >PR Stanley <[EMAIL PROTECTED]> wrote:
> >
> > > Hi
> > > data Ord a => Tree a = Nil | Node (Tree a) a (Tree a)
> > > How would one go about inserting a value in a binary search tree
> > > of the above description?
> > >
> >Using a library ;)
> >
> >Inserting isn't the problem, balancing is where things get
> >interesting: have a look at
> >
> >http://en.wikipedia.org/wiki/AVL_tree
> >
> >--
> >(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


-- 
(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] build version problem?

[Philip Weaver]

Ok, I'll ask the obvious question... did you try to re-configure?

runhaskell Setup.hs configure


2008/5/9 Galchin, Vasili <[EMAIL PROTECTED]>:
> Hello,
>
>  I changed the version # in a cabal file and now I get ...
>
>  runhaskell Setup.hs configure
> Configuring unix-2.4.0.0...
> [EMAIL PROTECTED]:~/FTP/Haskell/unix-2.2.0.0$ runhaskell Setup.hs build
> Setup.hs: unix.cabal has been changed, please re-configure.
>
> Now no matter what I change the version #, e.g. 2.3.0.0, things are not
> happy. ?
>
> Thanks, Vasili
>
> ___
> 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 compiler on NetBSD amd64

[Emil Skoeldberg]

On Fri, May 09, 2008 at 10:21:19PM -0700, Donn Cave wrote:
> So here I am with 64 bit Athlon hardware, running amd64
> NetBSD (a.k.a. x86_64), reasonably motivated to compile
> Haskell.  From what I make of the porting instructions,

So, we are in the same boat then!

> my only hope is to install FreeBSD-amd64 on another
> partition and download the 6.6.1 ghc for that platform,
> use it to generate .hc files to build 6.6.1 on NetBSD,
> and then use 6.6.1 to build 6.8 or whatever the current
> version may be by the time I get there?
> 

But what I thought was rather to go with OpenBSD, since I
figured that it would be closer to NetBSD (You can e.g. build
ghc on OpenBSD using NetBSD-generated .hc files on i386),
and generate the .hc files on OpenBSD. I have unfortunately
not got any further than getting an openbsd partition though,
have not had the time to get into the actual porting.

Emil


> -- 
> Donn Cave <[EMAIL PROTECTED]>

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

Re: [Haskell-cafe] Re: inserting values in a binary tree

[Tomas Andersson]

Den Saturday 10 May 2008 00.55.44 skrev PR Stanley:
> Actually, you've touched an important point there. It's balancing
> that I'm having difficulty with.
> Paul
>

 So what kind of balancing rules does it have to obey? AVL? Red-black? 
Something else?

> At 23:46 09/05/2008, you wrote:
> >PR Stanley <[EMAIL PROTECTED]> wrote:
> > > Hi
> > > data Ord a => Tree a = Nil | Node (Tree a) a (Tree a)
> > > How would one go about inserting a value in a binary search tree of
> > > the above description?
> >
> >Using a library ;)
> >
> >Inserting isn't the problem, balancing is where things get interesting:
> >have a look at
> >
> >http://en.wikipedia.org/wiki/AVL_tree
> >
> >--
> >(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
>
> ___
> 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] Stack vs Heap allocation

[Edsko de Vries]

Hi,

> > > (...(((1+2)+3)+4) ... + 1000)
> > > which requires stack in proportion to the number of nested parentheses
> > 
> > Ah, that makes! So does it make sense to talk about "tail recursive
> > thunks"? Or does the evaluation of thunks always take stack space
> > proportional to the "nesting level"? 
> 
> The key reason why nested additions take stack space, is because (+) on
> Integers is *strict* in both arguments.  If it were somehow non-strict
> instead, then the unevaluated parts of the number would be heap-allocated
> rather than stack-allocated.

I don't understand. Could you elaborate?

Thanks,

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

Re: [Haskell-cafe] [ANN] Twitter Client

[Chris Eidhof]

On 9 mei 2008, at 21:31, Gwern Branwen wrote:
On 2008.05.09 16:23:03 +0200, Chris Eidhof <[EMAIL PROTECTED]>  
scribbled 0.6K characters:

Hey everyone,

I was tired of all those graphical Twitter clients that aren't  
usable from
my Terminal, so I wrote my own. It's still very much alpha, but  
comments or
improvements are more than welcome. You can install it by  
downloading the

twitter-package from hackage.


For those interested, the links is . Hackage reports a build-failure, but I think that particular  
problem is because of Curl's Haddock failure.


That said, I did run into a build problem:

Is GUI.Terminal some special Mac haskell package I wouldn't have on  
Linux?
No, I was a bit sloppy with casing of the directory-names. On my Mac  
it was called Gui, but it should have been called GUI. I uploaded a  
changed package, it should build fine now.


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