[ ghc-Bugs-669261 ] Shjft+Enter crashes GHCI

2003-01-16 Thread SourceForge.net
Bugs item #669261, was opened at 2003-01-16 20:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=669261group_id=8032 Category: Prelude Group: 5.04.2 Status: Open Resolution: None Priority: 5 Submitted By: Miguel Figueiredo (olliegator) Assigned to:

Re: sockets (ghc-5.04.1)

2003-01-16 Thread Volker Stolz
In local.glasgow-haskell-users, you wrote: I have a program that uses INET sockets and I wanted to change it to use Unix domain sockets. Here is the relevant code: sock - listenOn portID (h, hostname, portnumber) - accept sock I get an error message when running it with portID =

Re: Using --make with -odir and hierarchical modules

2003-01-16 Thread nilsson
Martin Norbäck wrote: What should be done about it? Solution 1: -odir is relative to the source directory (files will end up in Library/Bar/output/Module.o and Library/Foo/output/Module.o). This is a change of semantics from the earlier behaviour of -odir (files are put in another place).

EuroPar 2003, Topic 10 (CfP)

2003-01-16 Thread Ch. A. Herrmann
Apologies if you receive multiple copies of this message. --- ** ****** ***SECOND

avoiding cost of (++)

2003-01-16 Thread Hal Daume III
I have a function which behaves like map, except instead of applying the given function to, say, the element at position 5, it applies it to the entire list *without* the element at position 5. An implementation looks like: mapWithout :: ([a] - b) - [a] - [b] mapWithout f = mapWith' []

Re: avoiding cost of (++)

2003-01-16 Thread Iavor S. Diatchki
hi, just for fun i wrote the function in a different way. it should perform pretty much the same way as your function. i don't think the problem is (++) here, it is just the way this function is. if f is going to use all of its argument, it doesn't matter that you concatenated the two

Re: avoiding cost of (++)

2003-01-16 Thread D. Tweed
On Thu, 16 Jan 2003, Iavor S. Diatchki wrote: hi, just for fun i wrote the function in a different way. it should perform pretty much the same way as your function. i don't think the problem is (++) here, it is just the way this function is. if f is going to use all of its argument, it

Re: avoiding cost of (++)

2003-01-16 Thread Zdenek Dvorak
Hello, I have a function which behaves like map, except instead of applying the given function to, say, the element at position 5, it applies it to the entire list *without* the element at position 5. An implementation looks like: mapWithout :: ([a] - b) - [a] - [b] mapWithout f = mapWith'

Re: avoiding cost of (++)

2003-01-16 Thread Pal-Kristian Engstad
On Thursday 16 January 2003 08:10 am, Hal Daume III wrote: I have a function which behaves like map, except instead of applying the given function to, say, the element at position 5, it applies it to the entire list *without* the element at position 5. An implementation looks like:

Re: avoiding cost of (++)

2003-01-16 Thread Janis Voigtlaender
Hal Daume III wrote: I have a function which behaves like map, except instead of applying the given function to, say, the element at position 5, it applies it to the entire list *without* the element at position 5. An implementation looks like: mapWithout :: ([a] - b) - [a] - [b]

Re: avoiding cost of (++)

2003-01-16 Thread D. Tweed
On Thu, 16 Jan 2003, Pal-Kristian Engstad wrote: It struck me though, if you have a function that calculates something on a list 'lst', and then you calculate something on 'lst ++ [a]', then surely one should be able to cache the results from the previous calculation. I'm not a Haskell