Re: [Haskell-cafe] Splitting a list

2004-04-22 Thread Joe Fasel
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

2004-04-22 Thread Joe Fasel
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

2004-01-21 Thread Joe Fasel
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

2004-01-21 Thread Joe Fasel
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]

2000-01-25 Thread Joe Fasel
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]

2000-01-25 Thread Joe Fasel
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'

2000-01-19 Thread Joe Fasel
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

2000-01-19 Thread Joe Fasel
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++)

1999-09-24 Thread Joe Fasel
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)

1999-09-24 Thread Joe Fasel
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'?

1999-03-29 Thread Joe Fasel
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

Re: Random comments

1998-12-03 Thread Joe Fasel
| 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

1997-07-08 Thread Joe Fasel
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

1997-01-17 Thread Joe Fasel
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

1997-01-17 Thread Joe Fasel
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

1993-11-07 Thread Joe Fasel
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

1993-11-04 Thread Joe Fasel
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

1993-11-04 Thread Joe Fasel
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

1993-11-01 Thread Joe Fasel
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

1993-11-01 Thread Joe Fasel
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

1993-10-05 Thread Joe Fasel
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

1993-10-05 Thread Joe Fasel
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

1993-07-28 Thread Joe Fasel
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

1993-07-28 Thread Joe Fasel
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

1993-07-28 Thread Joe Fasel
| 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!

1993-05-26 Thread Joe Fasel
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

1993-05-19 Thread Joe Fasel
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

1993-05-18 Thread Joe Fasel
|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