### Re: [Haskell-cafe] Splitting a list

This is a classic greedy algorithm, much like the text-wrapping problem. My main suggestion would be that you're not making use of some standard list functions that would simplify things. For example, your runningSum is just scanl1 (+) . Similarly, splitAll should use unfoldr. Another thing is

### Re: [Haskell-cafe] Splitting a list

On 2004.04.22 15:02, I wrote: splitAll :: (Real a) = a - [a] - [[a]] splitAll = unfoldr . split where split _ [] = Nothing split n xs = let (ys,zs) = break (( n) . snd) (zip xs (scanl1 (+) xs))

### Re: Hugs/GHC incompatibility

On 2004.01.21 15:03, Iavor S. Diatchki wrote: hi, not that it matters, but i think commonly when specifications say that something is undefined, that means that the behaviour can be whatever, i.e. the implementors can do what they like. this is not to be confused with the entity undefined

### Re: Hugs/GHC incompatibility

On 2004.01.21 15:03, Iavor S. Diatchki wrote: hi, not that it matters, but i think commonly when specifications say that something is undefined, that means that the behaviour can be whatever, i.e. the implementors can do what they like. this is not to be confused with the entity undefined

### Re: drop take [was: fixing typos in Haskell-98]

Phil Wadler writes: | I'm with Jon Fairbairn on this. Negative arguments are an error | because the domain of take and drop is the naturals. The problem | is that we use Int to represent naturals. -- P | | For the people that share this sentiment, can you please | explain why ints that are

### Re: drop take [was: fixing typos in Haskell-98]

Chris Okasaki writes: | But if the type *says* Int, then it should have reasonable behavior | for ints. I look at the negative case as being equivalent to | standard mathematical treatment of ranges such as i..j, where the | range is considered to be empty if j i. Allowing take/drop to |

### Re: `partition'

S.D.Mechveliani [EMAIL PROTECTED] writes | Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] writes | partition _ [] = ([], []) | partition p (x:xs) = if p x then (x:ys, zs) else (ys, x:zs) | where (ys, zs) = partition p xs | | runs your example in constant space. | | | Probably,

### partition and lifted products

Folks, I claimed that these are different functions: partition1 p xs = (filter p xs, filter (not . p) xs) partition2 p = foldr (\x (ys, zs) - if p x then (x:ys,zs) else (ys,x:zs)) ([],[]) I was correct, but not for the reason I thought. Nota bene: partition1 p

### Re: Sisal (was: RE: Cryptarithm solver - Haskell vs. C++)

Olivier LeFevre wrote, | "R.S. Nikhil" [EMAIL PROTECTED] wrote, | | Sisal researchers [...] deliberatly chose to avoid higher-order functions, | polymorphism, laziness, etc. | | In a first release, yes, but I believe higher-order functions were included in | Sisal 2.0, which was almost

### Re: Non-strictness vs. laziness (was RE: Sisal)

Frank Christoph wrote, | Ah, right. Someone mentioned just recently (I forget who---sorry) that | nothing in the Report forces a Haskell implementation to use call-by-need. I | guess this is a manifestation of the change of direction, from laziness to | non-strictness...? My point was meant to

### Re: Plea for Change #1: Why, O why, `Main'?

Tommy Thorn writes | Jens' question gave my a perfect opportunity to open my a pet peeve of | mine: the ditatorship of `Main'. | | In Haskell, the `main' function must reside in the `Main' module. | Add to this that the `Main' module must reside in a `Main' file and | you have an unfortunate

| I think using monads, and specially a powerful one like IO, everywhere is | a mistake. I can't see the need for most uses of random numbers. | | -- Lennart Besides that, isn't the name "randomIO" a bit unfortunate? It sounds like it contrasts with "sequentialIO". --Joe Joseph H.

### Re: Maybe type

It looks like a mistake to me, too. --Joe | The definition of Maybe (at least in the Hugs prelude) is: | | data Maybe a = Just a | Nothing |deriving (Eq, Ord, Read, Show) | | The (to me) unfortunate consequence of this is that "Nothing" is the upper | bound of the type (as

### Re: Making argv a constant

I think Fergus's efficiency argument may be a red herring. Here is an excerpt from a compiler I wrote recently: data JvlArgs = JvlArgs {optNoLink :: Bool, optVerbose :: Bool, jvlClassNames :: [String]} deriving Show

### Re: Making argv a constant

Fergus, Quite right. I used "error" because I was lazy. In fact, the lazy evaluation of the arguments is also a red herring, because the compiler is in fact strict in argv. (How else does it know what to compile?) All the flag arguments must be scanned in order to retrieve "jvlClassNames

### Re: Lifted Tuples

Paul writes | It has occurred to me that unlifted tuples achieved via a special | "newtype" decl are not the same as those achieved with strictness | annotations. This is because with "newtype" it seems that people want | a situation where (_|_,_|_) = _|_. But with strictness annotations on |

### Re: Laws

Just a small addendum to Mark's response to Warren: Overloading (even just polymorphism, as Mark says) does compromise equational reasoning, in much the same way that lexical scoping does. That is x = y |- f x = f y , provided it's the same x and the same y. Cheers, --Joe

### Re: Lifted functions

Simon writes | I have never, never been tripped up by the liftedness of tuples, but the | argument that ``we are prepared to pay for laziness so why not this too'' | has a certain masochistic charm. I'll try the effect on performance of | making all tuple-matching lazy in the nofib suite. Good

### Re: Strictness

Paul writes: | Like Ian, I would like to suggest that we lift functions in Haskell. | Originally there was a good reason not to: there was no need (and | indeed no way) to distinguish _|_ from \x-_|_. But now there are | some compelling reasons to make the distinction: I would say that there

### More on strictness

I wrote: |Thus, it would indeed be reasonable for the type of seq to determine |that f x `seq` y is all right, whereas f `seq` y is not permissible. |Similarly, I think it would be consistent to have unlifted products, |but not give them data instances, so that (x,y) `seq` z is not allowed,

### Re: re. Arrays and Assoc

Nikhil says, | Thomas Johnsson says: | | If I recall correctly, the := to be used in array comprehensions was a | consession to the FORTRAN/Id/Sisal community, so that array comprehensions | would look more like they were used to. | | Both Arvind and I think this is notation is

### Re: Arrays and Assoc

John Launchbury says, | Here are three comments directed particularly at Haskell 1.3 people, but | obviously open to general feedback. | | 1. We should get rid of Assoc. | | When explaining my programs to other people I find this is a point of | confusion. Imagine exaplaining array construction,

### Re: Polymorphic recursive calls possible via type classes

Phil Writes: |However, for the extended type system that allows polymorphism in |recursion, this is no longer the case -- my thanks to Lennart |Augustsson for pointing this out. The counter-example (similar |to one of Mark's) is: | |g :: a - Bool |g x = g [x] | |This function

### Re: Polymorphic recursive calls possible via type classes

Phil writes: | Joe writes: | | | Phil Writes: | | | | | The closest one can come is | | | | | |class G a where | | |g :: a - Bool | | |g x = g [x] | | | | | |instance G Int | | |instance G [Int] | | |instance G [[Int]] | | |

### Re: Prefix negation

| From: [EMAIL PROTECTED] | | I'm puzzled by a detail in the Report, which seems to contradict itself. | | On page 13 it says: | | The special form -e denotes prefix negation, [...] and is simply | syntax for negate (e), where negate is as defined in the standard |

### Re: + and -: syntax wars!

John Peterson Lennart Augustsson Joe Fasel | This whole issue regarding redefinition of + and - is getting confused | unnecessarily. Both of these are in PreludeCore and cannot be renamed | or hidden. Because of this their fixities cannot be changed. It is | possible to locally

### Re: Successor patterns in bindings and n+k patterns

e the feature of n+k-patterns to simulate | n*k+k' patterns? [I am talking about weird user-defined | instances of Num.] quite possibly. | Stefan Kahrs --Joe Fasel

### Re: n+k patterns

|Another question along the same lines: What if (+) has been rebound? |Are n+k patterns still allowed? | |-- Lennart The answer should be that n+k patterns are still allowed, but (+), (-), and (=) from PreludeCore are used in the translation. --Joe