Remi Turk | 1 Nov 2004 02:23
Picon
Picon
Favicon

Re: Data.List.partition on infinite lists

On Sun, Oct 31, 2004 at 06:37:20PM +0100, Lemming wrote:
> I encountered that the implementation of 'partition' in GHC 6.2.1 fails
> on infinite lists:
> 
> >partition :: (a -> Bool) -> [a] -> ([a],[a])
> >partition p xs = foldr (select p) ([],[]) xs
> 
> >select p x (ts,fs) | p x       = (x:ts,fs)
> >                   | otherwise = (ts, x:fs)

Ah, IIRC one of my very first haskell-posts was about this :)

Actually, AFAICS this isn't just a could-be-better, but a real
Bug(TM). According to The Report the definition is:

partition p xs = (filter p xs, filter (not . p) xs)

which doesn't have any trouble with infinite lists.

> With the following definition we don't have this problem:
> 
> >partition :: (a -> Bool) -> [a] -> ([a], [a])
> >partition _ [] = ([],[])
> >partition p (x:xs) =
> >   let (y,z) = partition p xs
> >   in  if p x then (x : y, z)
> >              else (y, x : z)

Cheers,
Remi
(Continue reading)

Keith Wansbrough | 1 Nov 2004 11:39
Picon
Picon
Favicon

Re: state of the cabal (preprocessors)

> On 26 October 2004 18:00, Henrik Nilsson wrote:
> 
> > However, at least superficially, it would seem simpler (and more
> > flexible, since normal comments would not interfere) to simply
> > require that all OPTIONS/LANGUAGE pragmas must occur before the
> > keyword "module".
> > 
> > But maybe that is hard to implement, or undesirable for some other
> > reason?
> 
> Well, it's more tricky because you have to ignore comments, and
> therefore understand nested comments, but that's not too hard.  A little
> Alex or parsec parser should do the trick, being careful not to read the
> entire file.

Careful - not all Haskell modules contain the keyword "module".
Perhaps the scan should be up to the first non-comment, non-blank
token?

--KW 8-)
Josef Svenningsson | 1 Nov 2004 11:40
Picon
Picon

RE: Data.List.partition on infinite lists

This mail pretty much sums up the situation:
http://www.haskell.org/pipermail/glasgow-haskell-bugs/2004-October/004389.ht
ml

This will be fixed in GHC 6.4.

	/Josef

> -----Original Message-----
> From: libraries-bounces <at> haskell.org [mailto:libraries-bounces <at> haskell.org]
> On Behalf Of Lemming
> Sent: den 31 oktober 2004 18:37
> To: libraries <at> haskell.org
> Subject: Data.List.partition on infinite lists
> 
> I encountered that the implementation of 'partition' in GHC 6.2.1 fails
> on infinite lists:
> 
> > partition :: (a -> Bool) -> [a] -> ([a],[a])
> > partition p xs = foldr (select p) ([],[]) xs
> 
> > select p x (ts,fs) | p x       = (x:ts,fs)
> >                    | otherwise = (ts, x:fs)
> 
> 
> With the following definition we don't have this problem:
> 
> > partition :: (a -> Bool) -> [a] -> ([a], [a])
> > partition _ [] = ([],[])
> > partition p (x:xs) =
(Continue reading)

Graham Klyne | 1 Nov 2004 17:17

Cabal on Windows, revisited

I'm having another go at Building Cabal for Windows, this time using the 
make utility from mingw.   (HMake doesn't serve, as it's specific to 
compiling Haskell programs.  Mainly, I need to get the preprocessing 
performed for loading into Hugs).

Issues noted.

...

1. The "mkdir -p" command fails:  under Windows, the syntax of this command 
is different.   I realize there are many other Unix shell commands that 
just wont work in a make file under Windows, so I'm going to proceed to 
create a Windows-specific makefile for Hugs.

2. I've replaced the GHC invocations with cpphs, rather like the makefile 
target for creating documentation.

3. I've changed the temporary target directory to dist\tmp\Distribution 
(needs to be the right name to match hierarchical module names with 
Hugs).  Also created subdirectory Simple.  Also copied Setup.lhs to 
dist\tmp, and used that as the Haskell program to be run using RunHugs.

4. I also create a target directory and preprocessing commands for the 
Compat modules: dist\tmp\Compat.

5. At this point, using a batch file to run Setup, I can issue the command 
Setup --help:
[[
E:\HaskellTools\cabal>C:\DEV\Hugs98\runhugs-20040109.exe dist\tmp\Setup.lhs 
--he
(Continue reading)

Isaac Jones | 1 Nov 2004 02:48

Re: state of the cabal (preprocessors)

Hi Henrik,

Your outline of how the Yale build system treats preprocessing made
sense to me, except for the special case of delaying CPP for Hugs
until installation.  I think that's where my confusion came in.  What
advantages is there in delaying CPP until installation time?

> Thus, the same pros and cons would hold for binary versus source
> distribution both for compilers and interpreters. If one wants the
> flexibility of choosing the Haskell system and the operating system
> platform at installation time, then one needs a source distribution.
> If one is interested in installing a library for a particular
> Haskell system on a particular platform with the least amount
> of fuss (and without a complete tool chain), then one can pick a
> "binary" distribution if available.

Cabal almost supports this trade-off now; we don't really have a
binary distribution as-such, though we plan to support it... we build
into a temporary directory and install just moves the built stuff into
place and does the registration.  The only missing part is the
creation of a binary tarball or something.  We don't have a
platform-independent way to do this yet.  For sdist all we do is call
'tar' with the zip option, but this is completely broken on windows so
far.  I'll happily accept patches that'll make this code more generic.
That should make 'bdist' easy to implement.

peace,

  isaac
(Continue reading)

Iavor S. Diatchki | 1 Nov 2004 19:03
Picon

Re: Data.List.partition on infinite lists

hi,
the foldr definition can be fixed by putting a ~ on the pattern in 'select'.
-iavor

Remi Turk wrote:

>On Sun, Oct 31, 2004 at 06:37:20PM +0100, Lemming wrote:
>  
>
>>I encountered that the implementation of 'partition' in GHC 6.2.1 fails
>>on infinite lists:
>>
>>    
>>
>>>partition :: (a -> Bool) -> [a] -> ([a],[a])
>>>partition p xs = foldr (select p) ([],[]) xs
>>>      
>>>
>>>select p x (ts,fs) | p x       = (x:ts,fs)
>>>                  | otherwise = (ts, x:fs)
>>>      
>>>
>
>Ah, IIRC one of my very first haskell-posts was about this :)
>
>Actually, AFAICS this isn't just a could-be-better, but a real
>Bug(TM). According to The Report the definition is:
>
>partition p xs = (filter p xs, filter (not . p) xs)
>
(Continue reading)

Johannes Waldmann | 2 Nov 2004 09:54
Picon
Favicon

Re: Type prefixes vs. qualification (Was: System.FilePath propsal)

Henning Thielemann wrote:

>  I really advise to take a look at Modula-3. There, not only every
> function name omits the information of the type, even more each module has
> the name of the type it describes and the main type has the name T. 

Indeed this is a useful convention.

If we mainly use unqualified imports,
then we probably want  module Foo where data Foo = ...

but indeed larger projects sort of require qualified imports.
but this leads to strange code like  x :: Foo.Foo
Where it really looks better to have
module Foo where data Type = ..
as this allows  import qualified Foo ; x :: Foo.Type

You know where this leads to? Like, Java. There, a module
(class) automaticall contains a data declaration,
and from the outside it is just accesed by module name
(i. e., omitting the ".Type" suffix from the above example).

Not a bad thing, IMHO. It's generally a good idea
to structure the code (functions) according to the structure of data,
and to keep data declarations separate from each other
(i. e., each in their own module).

Best regards,
--

-- 
-- Johannes Waldmann,  Tel/Fax: (0341) 3076 6479 / 6480 --
(Continue reading)

Graham Klyne | 3 Nov 2004 10:32

Re: Cabal on Windows, revisited

Isaac,

I'll do what I can as and when time and other involvements 
permit.  Meanwhile I was trying to provide what I hope was some 
constructive feedback, at this stage being mainly with respect to 
identifying aspects of Hugs that may require different treatment.  I feel 
that before I can seriously make patches to the code repository, I need to 
get a better overall handle on how the Cabal pieces fit together (which I'm 
slowly getting, I think).

You asked for:
> > 1. The "mkdir -p" command fails:  under Windows, the syntax of this
> >    command is different.   I realize there are many other Unix shell
> >    commands that just wont work in a make file under Windows, so I'm
> >    going to proceed to create a Windows-specific makefile for Hugs.
>
>Can you send me this file either as a darcs patch or as an attachment
>in private mail?

Did you notice I included my makefile bits so far at the end of my previous 
message?  For ease of reference, I include it again, below.  Note that 
directories need to be edited for this to work.

Keep up the good work!

#g
--

[[
PREF=E:\Temp\Cabal
(Continue reading)

Isaac Jones | 3 Nov 2004 18:11

Re: Cabal on Windows, revisited

Graham Klyne <GK <at> ninebynine.org> writes:

> Isaac,
>
> I'll do what I can as and when time and other involvements permit.
> Meanwhile I was trying to provide what I hope was some constructive
> feedback, at this stage being mainly with respect to identifying
> aspects of Hugs that may require different treatment.  I feel that
> before I can seriously make patches to the code repository, I need to
> get a better overall handle on how the Cabal pieces fit together
> (which I'm slowly getting, I think).

FYI, I just pushed a version of the cabal (in both darcs and tarball
snapshot) that bootstraps with Hugs.  If you have the hugs-package
tool, you should be able to translate the makefile into a .bat file
that'll work for you on Windows.  It's pretty straightforward.

This also adds CPP as a language extension.  Since we have some basic
hugs support and preprocessors, I'll probably release this as 0.2.

I'm still thinking about my opinions on CPP.  Everyone has an opinion
on it, right? ;)

> Keep up the good work!

Thanks!

peace,

  isaac
(Continue reading)


Gmane