"S. Alexander Jacobson" wrote:
> The python behavior is:
> take n list | length list + n < 0 = []
> drop n list | length list + n < 0 = list
>
> I think this is the correct complement (dual?) of:
> take n list | length list - n < 0 = list
> drop n list | lenght lis
Sven Panne <[EMAIL PROTECTED]> wrote,
> Just a thought: Some compilers for other languages (e.g. Java and
> Eiffel) warn the user about deprecated features, but continue
> compilation. Given the current state of flux in the Haskell libraries,
> this would be a nice thing in Haskell, too. So my su
> Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
>
> > (A) Make them defined for any n. If n < 0, do something reasonable:
> > take: give empty list
> > drop: give whole list
> >
> > (B) Make them defined for n > length xs, but fail for n < 0.
I vote for (B).
'Qrczak' Kowal
On 24-Jan-2000, Sven Panne <[EMAIL PROTECTED]> wrote:
> Just a thought: Some compilers for other languages (e.g. Java and
> Eiffel) warn the user about deprecated features, but continue
> compilation. Given the current state of flux in the Haskell libraries,
> this would be a nice thing in Haskell
On Tue, 25 Jan 2000, BYRNE, Peter wrote:
> (2) If take and drop are to be defined for negative integers, what happens
> to
> take (-n) xs
> when n > len xs? Judging from the definitions proposed:
> take (-5) [1..4] == [1,2,3]
> and things look less useful than confusing.
Th
I'm new to Haskell, but
(1) With regard to the second "law",
(take 1 . take 5) [1..]
does not appear to me to be the same as
take 6 [1..]
(2) If take and drop are to be defined for negative integers, what happens
to
take (-n) xs
when n > len xs? Judging from
> All the proposals break this law as well, so I this argument is weak (if
> not insane :-))
>
> -Alex-
IMHO, a consistency is the most important rule here.
I do not have any problems with any of those proposals,
providing that I can apply similar reasoning to other
Mon, 24 Jan 2000 07:49:30 -0800, Simon Peyton-Jones <[EMAIL PROTECTED]> pisze:
> (A) Make them defined for any n. If n < 0, do something reasonable:
> take: give empty list
> drop: give whole list
>
> (B) Make them defined for n > length xs, but fail for n < 0.
I vote for (
> IMHO, that would be the _insane_ definitions :-) Firstly, nothing
> suggests to me that rationale of such behaviour.
The rationale is:
1. these are useful functions
2. if this is insane, so is python. The corresponding python is:
def take list n: return list[:n]
def drop lis
I would like to take this opportunity to thank Microsoft Outlook Express for
trashing the format of Brian Boutel's message so that I couldn't tell what
part of it was quotation (from Jacobsen) and what part was Boutel's reply.
Of course, I now realize that Brian was pointing out that Jacobsen's
de
Brian Boutel wrote:
> take -2 [1,2,3,4] ++ drop -2 [1,2,3,4] -> [3,4,1,2]
But [1,2,3,4] is NOT the same as [3,4,1,2]. So the equality doesn't hold.
Personally, for reasons I'm not sure I can articulate, I've always strongly
disliked the notion that negative arguments should produce "backwards"
S. Alexander Jacobson writes:
> The correct definitions would be:
>
> take -2 -- drops the last 2 elements from the list
> (takes everything except the last 2 elements)
> drop -2 -- grabs the last 2 elements from the list
> (drops everything except the last 2 eleme
Ok. so I got it backward. The functionality is still useful and belongs
with take and drop.
The correct definitions would be:
take -2 -- drops the last 2 elements from the list
(takes everything except the last 2 elements)
drop -2 -- grabs the last 2 elements from the list
On Tuesday, January 25, 2000 10:00 AM, Joe English [SMTP:[EMAIL PROTECTED]] wrote:
>
> Is the filter/filter definition semantically equivalent to:
>
> partition p xs = foldr select ([],[]) xs
> where
> select x ~(ts,fs) | p x = (x:ts,fs)
> | otherwise = (ts,
On Tuesday, January 25, 2000 8:38 AM, S. Alexander Jacobson [SMTP:[EMAIL PROTECTED]] wrote:
Why not do what python does?
drop -2 -- drops the last 2 elements from the list
take -2 -- grabs the last 2 elements from the list
take n list | n<0 = drop (length list +
> If you worry about nondeterminism, we can imagine that the input value
> of World is evaluated lazily and as a whole is infinite. Some parts of
> it depend on the output of our Haskell program, but it's not unusual
> in a lazy world for a value to be expressed in terms of the result of a
> funct
Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> First, partition is defined in the List library:
>
> partition p xs = foldr select ([],[]) xs
>where
> selet x (ts,fs) | p x = (x:ts,fs)
> | otherwise = (ts,x:fs)
> Several people h
Mon, 24 Jan 2000 11:21:24 -0600, Michael Hobbs <[EMAIL PROTECTED]> pisze:
> When this philosophical impediment was pointed out, someone clarified
> the point by saying that an "IO a" function type is *not* equivalent to
> "World -> (World, a)". The result of an IO function is not an action, or
>
Sven Panne writes:
> [...] So my suggestion is a new pragma DEPRECATED along the
> following lines: [...] Opinions?
I like it. Ideally, tools like HaskellDoc would also be aware of the
DEPRECATED pragma.
Simon Marlow writes:
> All known Haskell compilers implement the IO type as a function type,
> something like (World -> (World, a)).
Mark Jones replies:
> In Hugs, I did actually use a different implementation of the IO
> monad, based on continuation passing
> IO a = (a -> Ans) -> (IOError
Why not do what python does?
drop -2 -- drops the last 2 elements from the list
take -2 -- grabs the last 2 elements from the list
take n list | n<0 = drop (length list + n) list
drop n list | n<0 = take (length list + n) list
If the list is an infinite list, the behavior is equivalent to B.
If
Mark P Jones wrote:
> Simon Marlow writes:
>
> | All known Haskell compilers implement the IO type as a function type,
> | something like (World -> (World, a)). You can think of the monad
> | as just a convenient way to hide the passing around of the world token.
> |
> | And because it is abstra
> Take and drop
> [..]
> I can see three alternatives:
>
> (A) Make them defined for any n. If n < 0, do something reasonable:
> take: give empty list
> drop: give whole list
>
> (B) Make them defined for n > length xs, but fail for n < 0.
>
> (C) Status quo
>
> PROPOSAL: Use al
Simon Marlow writes:
| All known Haskell compilers implement the IO type as a function type,
| something like (World -> (World, a)). You can think of the monad
| as just a convenient way to hide the passing around of the world token.
|
| And because it is abstract, compilers are free to implem
> > Take and drop
> > [..]
> > I can see three alternatives:
> >
> > (A) Make them defined for any n. If n < 0, do something reasonable:
> > take: give empty list
> > drop: give whole list
> >
> > (B) Make them defined for n > length xs, but fail for n < 0.
> >
> > (C) Status quo
> >
Simon Peyton-Jones wrote:
> Take and drop
> ~
> Jan Kort points out that
>
> a) (take n xs) and (drop n xs) are defined for n > length xs
>In that case they do something reasonable and useful
> (take gives back xs, drop gives the empy list)
>
> b) They are both also defin
Simon Marlow wrote:
> > I was recently assured (by a message on this list) that as
> > far as Haskell
> > is concerned a value of type (IO a) is simply an abstract
> > data type, not
> > a world transforming function. But if you do interpret it as
> > such, what
> > you've got is world as value IO
> Probably so, I do have difficulty understanding this. The point I was
> trying to make is that as far as Haskell is concerned, that there is no
> difference between values of type (IO a) and any other values.
Exactly. That is a powerful thing: you treat computations as values and
other guy is
> Probably so, I do have difficulty understanding this. The point I was
> trying to make is that as far as Haskell is concerned, that
> there is no
> difference between values of type (IO a) and any other
> values. The fact
> that once evaluated these values cause IO operations to be
> perform
Simon Peyton-Jones <[EMAIL PROTECTED]>
announces the editor's proposals for the "typos" fix in Haskell-98.
> Partition
> [..]
> The "standard" (lazier) defn should be the one in the H98 report.
>
> PROPOSAL: use the filter/filter defn of partition
I agree.
> Take and drop
> [..]
> I can
On Mon 24 Jan, Pablo E. Martinez Lopez wrote:
> In Haskell you ONLY define a VALUE of an abstract type IO that DESCRIBES
> the changes the World would suffer WHEN that value is operationally
> interpreted. So, saying that Haskell is incapable of describing I/O is,
> at least, a misunderstanding.
Folks
The recent discussion has highlighted three things that I
propose to treat as 'Haskell 98 typos'. Even if you have
not been reading the dicussion, please read this, since
I have my H98 editor's hat on, and I propose some minor
changes to the published H98.
Simon
Partition
~
F
Just a thought: Some compilers for other languages (e.g. Java and
Eiffel) warn the user about deprecated features, but continue
compilation. Given the current state of flux in the Haskell libraries,
this would be a nice thing in Haskell, too. So my suggestion is a new
pragma DEPRECATED along the f
> Haskell position (as I understand it)
> -
> Haskell is incapable of desribing IO, it can only evaluate an expression
> of type IO (). This expression is used by an 'IO monad machine' (which
> is not part of Haskell) to actually execute IO operations. Beca
Say, I was wondering if someone on this list would be willing to help
me track down a space leak in a program I wrote. I don't really have
enough insight into the workings of things to figure out what's causing
it, but people here have seemed helpful in the past. The space leak
occurs under GHC 4.
Apologies if you receive multiple copies.
call for papers
IFIP International Conference on Theoretical Computer Science
IFIP TCS2000
--- Exploring New Frontiers of Theoretical Informatics ---
On Tue 18 Jan, Stefan Karrmann wrote:
> What are the pros and cons of unique typing with multiple environments
> vs. the IO monad?
I don't think anybody else has answered this, so I'll have a go.
In the absence of concurrency, I think there is little to chose between
Cleans unique world as value
> | Can we have extensional products and functions (or at least the means
> | to define them) please?
> Language issues
> ~~~
> A significant difficulty is that seq is essentially un-implementable
> for unlifted products (requires parallelism).
Well, all you need is an evaluation wi
| Can we have extensional products and functions (or at least the means
| to define them) please?
Does anyone want to come up with a concrete language proposal?
Language issues
~~~
A significant difficulty is that seq is essentially un-implementable
for unlifted products (requires pa
| So will the features of Hugs eventually be supported by all
| platforms and integrated into a future version of Haskell or will I have
to
| keep seperate versions of my code?
No one is going to guarantee that. However, the GHC team and the
Hugs team are making a conscious effort to align our
40 matches
Mail list logo
