Re: [Haskell-cafe] Binary IO

[Donald Bruce Stewart]

m4d.skills:
> 
>Greetings,
>I am considering writing -in Haskell of course - a small
>program to translate binary files to human readable text.
>The trouble is that I can find no easily digestible tutorial
>style info on how to do binary IO in Haskell.
>I have read about some of the libraries that people have
>created to do binary IO, but the documentation wasn't
>sufficient to get me started (perhaps because I'm a bit
>dense, and also relatively new to Haskell).
>What I would like is to see a short example showing some
>code that reads from a binary file.  I would also
>like to know what the most widely used library for doing
>binary IO in Haskell is.
>I would greatly appreciate it if someone could post a small
>example or two illustrating how to do
>binary IO in Haskell using the most widely used binary IO
>lib (if there is such a thing).  Failing that, I would
>appreciate a link to some Haskell code that does binary IO
>that I could study.
>Lastly, if there is a good tutorial on doing binary IO in
>Haskell then I would appreciate a link to that as well.
>Thanks in advance,
>Jeff Lasslett

Here's a howto:
http://www.haskell.org/hawiki/BinaryIo

Look for the instance Binary  code. That's where you set up your binary
parsers for each Haskell type. lso, these day,s you can do a fair bit of
binary hacking with Data.ByteString, without the Binary class layer over
the top.  Hope that helps.

-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] newbie - IO issues (of course)

[Stepan Golosunov]

On Sat, Jun 24, 2006 at 02:38:31PM +1000, Geoffrey King wrote:
> I have been work my way through "Haskell The Craft of Functional 
> Programming", all was fine until IO (chapter 18). That is causing me 
> bafflement.
> 
> I am trying to write a totally trivial program that reads a series of 
> integers from the console until it gets a zero, then returns the series 
> of integers as a list.
> 
> I am down to randomly editing my code, never a good sign. Any clues 
> would be appreciated, My code so far, which clear doesn't work, is:
> getInt :: IO Int
> getInt = do
>putStr "Enter number (zero to quit)"
>line <- getLine
>return (read line :: Int)
> 
> anIntList :: [Int]

anIntList is an IO action which reads a list, and as such has type
IO [Int], not [Int].

> anIntList =
>do
>let n = getInt

You should use "n <- getInt" to perform getInt and read integer into n.
"let n = getInt" just says that n is an IO action which reads integer,
not that integer itself.

>if n == 0
>then return []
>else return (n : anIntList)

As anIntList is not a list this won't work. You should perform anIntList
and then use its result:
   do
 list <- anIntList
 return (n : list)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Binary IO

[jeff lasslett]

Greetings,I am considering writing -in Haskell of course - a small program to translate binary files to human readable text.The trouble is that I can find no easily digestible tutorial style info on how to do binary IO in Haskell.
I have read about some of the libraries that people have created to do binary IO, but the documentation wasn'tsufficient to get me started (perhaps because I'm a bit dense, and also relatively new to Haskell).
What I would like is to see a short example showing some code that reads from a binary file.  I would also like to know what the most widely used library for doing binary IO in Haskell is.I would greatly appreciate it if someone could post a small example or two illustrating how to do
binary IO in Haskell using the most widely used binary IO lib (if there is such a thing).  Failing that, I wouldappreciate a link to some Haskell code that does binary IO that I could study.Lastly, if there is a good tutorial on doing binary IO in Haskell then I would appreciate a link to that as well.
Thanks in advance,Jeff Lasslett
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] newbie - IO issues (of course)

[Bulat Ziganshin]

Hello Geoffrey,

Saturday, June 24, 2006, 8:38:31 AM, you wrote:

> getInt :: IO Int
> getInt = do
> putStr "Enter number (zero to quit)"
> line <- getLine
> return (read line :: Int)

this procedure is fine, although there is specific function to read
data of any type, which is just equivalent to getLine+read. using it,
we can make routine even smaller:

getInt :: IO Int
getInt = do
putStr "Enter number (zero to quit)"
readLn

> anIntList :: [Int]
> anIntList =
> do
> let n = getInt
> if n == 0
> then return []
> else return (n : anIntList)

IO monad cannot escape, so you can't use inside non-IO function
(anIntList) an IO function (getInt)

this have very simple explanation - Haskell is pure language, that
meant that functions allways return the same results with same
arguments. your anIntList don't have arguments, so it should return
the same data on each call, really it's type signature meant that it
just a constant!

on the other side, return type "IO a" means that function can be
called in IO monad context (such as inside "main") and may return
different results even with the same arguments

as conclusion, anIntList should have type "IO [Int]". try to write it
yourself, i will help if you need it


ps: i definitely will write wiki "introduction to monads and i/o" next
week, it is so frequent source of beginner's troubles!


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] newbie - IO issues (of course)

[Jason Dagit]

On 6/23/06, Geoffrey King <[EMAIL PROTECTED]> wrote:

I have been work my way through "Haskell The Craft of Functional
Programming", all was fine until IO (chapter 18). That is causing me
bafflement.

I am trying to write a totally trivial program that reads a series of
integers from the console until it gets a zero, then returns the series
of integers as a list.

I am down to randomly editing my code, never a good sign. Any clues
would be appreciated, My code so far, which clear doesn't work, is:
getInt :: IO Int
getInt = do
putStr "Enter number (zero to quit)"
line <- getLine
return (read line :: Int)


I haven't tested your code or my proposed changes, but let me step
through what you have and offer up explanations of what I think is
going wrong.

So here, things look pretty good with getInt.  getInt has type IO Int,
which makes sense because you do some work in the IO monad construct a
value and return it.  Since you can't escape the IO monad, getInt
returns an Int which is wrapped up in the IO monad.



anIntList :: [Int]
anIntList =
do
let n = getInt
if n == 0
then return []
else return (n : anIntList)


Okay, so lets start with the let.  What is the type of n?  Well, it's
IO Int because that's the type of getInt.  But, IO Int isn't a number
so you can't do the test in the if.  Otherwise, your code looks pretty
good.




ps: even a simple version that returns an Int i can't get to work.
anInt :: Int
anInt = do
n <- getInt
return n


Now you're getting closer.  But, you do work in the IO monad and
construct a value and return it, so your type signature must be wrong.
It must be the case that anInt :: IO Int.  I see here that you know
how to grab 'unwrap' a value in the IO monad and work with it (the
line, n <- getInt), you should try doing this above where you have
'let n = getInt'.

You may also want to read these fine web pages:
http://www.haskell.org/hawiki/MonadsAsContainers
http://www.nomaware.com/monads/html/index.html

You're so close, I expect you'll have it figured out before I can hit send :)

HTH,
Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] newbie - IO issues (of course)

[Geoffrey King]

I have been work my way through "Haskell The Craft of Functional 
Programming", all was fine until IO (chapter 18). That is causing me 
bafflement.


I am trying to write a totally trivial program that reads a series of 
integers from the console until it gets a zero, then returns the series 
of integers as a list.


I am down to randomly editing my code, never a good sign. Any clues 
would be appreciated, My code so far, which clear doesn't work, is:

getInt :: IO Int
getInt = do
   putStr "Enter number (zero to quit)"
   line <- getLine
   return (read line :: Int)

anIntList :: [Int]
anIntList =
   do
   let n = getInt
   if n == 0
   then return []
   else return (n : anIntList)


ps: even a simple version that returns an Int i can't get to work.
anInt :: Int
anInt = do
   n <- getInt
   return n   


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Functional progr., infinity, and the Universe

[Stepan Golosunov]

On Fri, Jun 23, 2006 at 03:30:18PM -0400, Paul Hudak wrote:
> Stepan Golosunov wrote:
> >On Fri, Jun 23, 2006 at 10:57:48AM -0400, Paul Hudak wrote:
> >
> >>[EMAIL PROTECTED] wrote:
> >>>I think quite
> >>>a few people would agree that a finite list is one ending in []. So 1:_|_
> >>>is a partial list, but not a finite one. 1:[] is a finite list.
> >>
> >>1:_|_ is certainly finite.  In what sense is it not?
> >
> >And what is length _|_ ?
> 
> _|_, of course!! :-)
> 
> The point being, length is well-defined only for total lists; it is 
> undefined for partial lists.  But this doesn't mean that a partial list 
> isn't finite.

What is "finite list" then?
Is ones = 1:ones also finite?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ReadP and MonadFix

[Levent Erkok]

Gracjan:To declare "ReadP" an instance of MonadFix; you'll first have to make the P monad into a MonadFix instance. That can be done using existing techniques in the literature.ReadP is essentially the continuation monad transformer wrapped around P. It's well known in the value-recursion literature that continuation monad is too "strong" to have a value-recursion operator. I am not aware of any "simple" solutions in that space. Hence, ReadP is beyond the realm of current theories of value recursion.
Having said that, I'd also like to point out that Amr Sabry and Eugenio Moggi, and independently  Magnus Carlsson has done some interesting work to extend value recursion to the world of continuations; which might help with your particular problem. Essentially, you end up adding some extra infrastructure to your monad, and then forgo some of the basic axioms of value recursion. But you can get running examples!
Maybe all you'll need is a MonadFix instance of P; which is definitely doable with the current techniques. Anything further would actually make a nice research paper...-Levent. (I could provide references to above work if needed; all is available on the net freely, anyhow.)
On 6/23/06, Gracjan Polak <[EMAIL PROTECTED]> wrote:
Hi all,A question for hot summer day: Text.ParserCombinators.ReadP.ReadP isan instance of Monad. Could it be an instance of MonadFix too?I'm not that sharp in Haskell to write it myself, but it seems I could
make use of such a beast. :) Anybody willing to share?This will also present the advantage of Lazy over Eager ParserCombinators, mentioned in some other thread.--Gracjan___
Haskell-Cafe mailing listHaskell-Cafe@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Lambda abstraction analogous to imperative pseudo-code?

[Jason Dagit]

On 6/10/06, Robert Dockins <[EMAIL PROTECTED]> wrote:

On Saturday 10 June 2006 04:35 pm, Clifford Beshers wrote:
> The Wikipedia article on lambda abstractions
> (http://en.wikipedia.org/wiki/Lambda_abstraction) has a statement that
> does not resonate with me:
>
> A lambda abstraction is to a functional programming
>  language such
> as Scheme 
> what pseudo-code  is to an
> imperative programming
>  language.
>
> Does anyone else find this to be a peculiar statement?  If you think it
> is accurate, could you provide an alternate explanation and/or example
> to the one in the article?

I agree; The article is questionable at best.  I've never seen the term
"lambda abstraction" used in the way it is in the article.  I'd go so far as
to say it's downright wrong.


On a related note, is anyone willing to fix wikipedia's page on CPS?
While I don't think it's wrong per se, it confuses me and I *almost*
understand CPS.  I can only imagine what their explanation does to
someone who is new to the topic.  I'd fix it myself but I don't feel
that my understanding of CPS is strong enough to go mucking about.

http://en.wikipedia.org/wiki/Continuation_passing_style

Thanks,
Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] parsec, how to feed single tokens?

[Marc Weber]

Hi. 
I want to write a haskellquickfind app to get a list of files using
human readable hash values (eg the first character of
directory/filenames)

Eg hquickfind vtl
should print /var/tmp/local
My implementation should look like this:

Every folder/file is token and I want to run a parser. to consume /var
Then I want to run it with all subdirs in var where it should fail on
anything but t.* ...
My Problem : I can't access runP directly to feed the parser with one
token and get the result (failure, need more tokens)..

Have I missed a function or isn't parsec meant to be used this way?

Would you recommend writing your own small parser for this?

Another question: Can you use another SourcePos state than SourcePos?

Marc
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Functional progr., infinity, and the Universe

[Paul Hudak]

Stepan Golosunov wrote:

On Fri, Jun 23, 2006 at 10:57:48AM -0400, Paul Hudak wrote:


[EMAIL PROTECTED] wrote:

I think quite
a few people would agree that a finite list is one ending in []. So 1:_|_
is a partial list, but not a finite one. 1:[] is a finite list.


1:_|_ is certainly finite.  In what sense is it not?


And what is length _|_ ?


_|_, of course!! :-)

The point being, length is well-defined only for total lists; it is 
undefined for partial lists.  But this doesn't mean that a partial list 
isn't finite.


-Paul
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Functional progr., infinity, and the Universe

[Stefan Holdermans]

Stepan,


And what is length _|_ ?


_|_

Regards,

  Stefan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Functional progr., infinity, and the Universe

[Stepan Golosunov]

On Fri, Jun 23, 2006 at 10:57:48AM -0400, Paul Hudak wrote:
> [EMAIL PROTECTED] wrote:
> >>Well, each partial list is finite. 
> >
> >I think quite
> >a few people would agree that a finite list is one ending in []. So 1:_|_
> >is a partial list, but not a finite one. 1:[] is a finite list.
> 
> 1:_|_ is certainly finite.  In what sense is it not?

And what is length _|_ ?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Functional progr., images, laziness and all therest

[Ross Paterson]

On Thu, Jun 22, 2006 at 05:44:58PM +0100, I wrote:
> It works because Haskell 'data' definitions yield both an initial fixed
> point (with respect to strict functions) and a terminal fixed point (with
> respect to arbitrary functions), and moreover these are usually the same.
> The former is inductive, the latter co-inductive.  They differ only when
> the definition is strict in the recursive type, as in
> 
>   data Nat = Zero | Succ !Nat

On second thoughts, I think the fixed points coincide in these cases
too.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Functional progr., infinity, and the Universe

[voigt . 16734551]

--- [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
> 1:_|_
is certainly finite.  In what sense is it not?

I see that point. I have
been using "finite" as, by convention, equal to "total and finite". And so
have others. As always with convention, one can argue. I won't, of course.


> Sorry, see my reply to Bill Wood. 

Yes, saw that later.

> distinguishes
what are called "interesting" elements from other elements 
> (if I recall
the terminology correctly).

Interesting ;-)

Ciao, Janis.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Functional progr., infinity, and the Universe

[Paul Hudak]

[EMAIL PROTECTED] wrote:
Well, each partial list is finite. 


I think quite
a few people would agree that a finite list is one ending in []. So 1:_|_
is a partial list, but not a finite one. 1:[] is a finite list.


1:_|_ is certainly finite.  In what sense is it not?


That doesn't quite make sense,
IMHO. The chain _|_, 1:_|_, 1:1:_|_, 1:1:1:_|_, ... has the limit (or upper
bound) "ones", but "ones" does not appear in the chain. An upper bound of
a set may not appear in the set. But the maximal element of a set by definition
("element of") necessarily is in the set. So you cannot use the two notions
interchangably. BTW, if the limit of a chain would always appear in the chain
(by virtue of being the  maximal element of the set of all elements comprising
the chain), then every chain would be stationary eventually. That would quite
simplify denotational semantics, wouldn't it?


Sorry, see my reply to Bill Wood.  I should have said that the LUB is 
indeed not in the set.  If it WERE in the set, then you simply wouldn't 
have an infinite object.  (In the flat domain of integers, for example, 
every chain consists of exactly two elements: _|_ and n, for each n.) 
But this characteristic is common in domain theory, and is what 
distinguishes what are called "interesting" elements from other elements 
(if I recall the terminology correctly).



And come to the conclusion, in a later mail, that both:

A. "the list [0,1,2,3,4,5,..] is longer than [1,2,3,4,5,..]"
and 
B. "ie [0,1,2,3,4,..] is the same length as [1,2,3,4,5,..]"


I think not. Obviously not. I know that this conclusion was qualified by
"assuming that they all grow at the same rate", which of course has no 
counterpart
in the denotational semantics setting discussed above. So it's not a wrong
statement, just one that cannot really be formulated.


My email didn't comment on this issue.  I agree that "growth rate" is 
not relevant when we're talking about "values".  The answer here has to 
do with the cardinality of infinite sets.



Well, anyway, didn't
want to be nitpicking. But I think it's important that if we want to think
about Haskell's semantics denotationally (which in itself is somewhat 
problematic),
we should at least be careful not to blur concepts. And asserting that the
limit of a chain is always an element of that chain is a dangerous 
oversimplification
that does not work out.


I agree; sorry about that.

  -Paul


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Functional progr., infinity, and the Universe

[Paul Hudak]

Bill Wood wrote:

On Fri, 2006-06-23 at 09:38 -0400, Paul Hudak wrote:
But the limit of a chain IS the maximal element of the set of all 
elements comprising the chain, since the LUB, in the case of a chain, is 
unique, and thus we don't have to worry about choosing the "least" 
element (i.e. it reduces to the upper bound, or maximal element).


There must be something additional going on, since in general the fact
that an ordered subset of a set has a LUB in the set does not imply that
the LUB is in the subset.  For example, the subset {1 - 1/n : n in N+}
of Q has LUB = 1, but 1 is not an element of the subset.  It would seem
that while the infinite list is the LUB of the chain of finite lists, it
is not itself a member of the chain of finite lists.  So, what am I
missing?


I don't think you missed anything, just provided more detail than I 
thought was needed.  As the LUB is indeed an infinite object, it is not 
in the set of finite, partial lists.  But that's pretty common in domain 
theory, and is analogous to the example that you gave.


  -Paul
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Functional progr., infinity, and the Universe

[voigt . 16734551]

--- [EMAIL PROTECTED] wrote:
Jerzy Karczmarczuk wrote:
> > OK, I think
that this subject matured enough to rest in peace...
> 
> I would have to
agree with that, although...

Since the subject is not going to rest, why
not also jump in?
 
> Well, each partial list is finite. 

I think quite
a few people would agree that a finite list is one ending in []. So 1:_|_
is a partial list, but not a finite one. 1:[] is a finite list.

> But the
limit of a chain IS the maximal element of the set of all 
> elements comprising
the chain, since the LUB, in the case of a chain, is 
> unique, and thus
we don't have to worry about choosing the "least" 
> element (i.e. it reduces
to the upper bound, or maximal element).

That doesn't quite make sense,
IMHO. The chain _|_, 1:_|_, 1:1:_|_, 1:1:1:_|_, ... has the limit (or upper
bound) "ones", but "ones" does not appear in the chain. An upper bound of
a set may not appear in the set. But the maximal element of a set by definition
("element of") necessarily is in the set. So you cannot use the two notions
interchangably. BTW, if the limit of a chain would always appear in the chain
(by virtue of being the  maximal element of the set of all elements comprising
the chain), then every chain would be stationary eventually. That would quite
simplify denotational semantics, wouldn't it?
 
> So I'd say that Brian
has at least come close to discovering God :-)

And come to the conclusion,
in a later mail, that both:

A. "the list [0,1,2,3,4,5,..] is longer than
[1,2,3,4,5,..]"

and 

B. "ie [0,1,2,3,4,..] is the same length as
[1,2,3,4,5,..]"


I think not. Obviously not. I know that this conclusion was qualified by
"assuming that they all grow at the same rate", which of course has no 
counterpart
in the denotational semantics setting discussed above. So it's not a wrong
statement, just one that cannot really be formulated.

Well, anyway, didn't
want to be nitpicking. But I think it's important that if we want to think
about Haskell's semantics denotationally (which in itself is somewhat 
problematic),
we should at least be careful not to blur concepts. And asserting that the
limit of a chain is always an element of that chain is a dangerous 
oversimplification
that does not work out.

Ciao,
Janis Voigtlaender.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Functional progr., infinity, and the Universe

[Bill Wood]

On Fri, 2006-06-23 at 09:38 -0400, Paul Hudak wrote:
   . . .
> But the limit of a chain IS the maximal element of the set of all 
> elements comprising the chain, since the LUB, in the case of a chain, is 
> unique, and thus we don't have to worry about choosing the "least" 
> element (i.e. it reduces to the upper bound, or maximal element).

There must be something additional going on, since in general the fact
that an ordered subset of a set has a LUB in the set does not imply that
the LUB is in the subset.  For example, the subset {1 - 1/n : n in N+}
of Q has LUB = 1, but 1 is not an element of the subset.  It would seem
that while the infinite list is the LUB of the chain of finite lists, it
is not itself a member of the chain of finite lists.  So, what am I
missing?

 -- Bill Wood


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Functional progr., infinity, and the Universe

[Paul Hudak]

Jerzy Karczmarczuk wrote:

OK, I think that this subject matured enough to rest in peace...


I would have to agree with that, although...

Couldn't an infinite list just be regarded as the maximum element of 
the (infinite) set of all finite lists?


Perhaps his intuition is right, but there are fundamental differences -
A. Between the chain of partial lists and the set of finite lists


Well, each partial list is finite.  Of course it isn't the set of ALL 
finite lists, but it is the set of all those finite lists that 
approximate the given infinite list.



B. Between a limit and the maximum element of a set.


But the limit of a chain IS the maximal element of the set of all 
elements comprising the chain, since the LUB, in the case of a chain, is 
unique, and thus we don't have to worry about choosing the "least" 
element (i.e. it reduces to the upper bound, or maximal element).


So I'd say that Brian has at least come close to discovering God :-)

  -Paul
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] sortBy2 for List library

[Serge D. Mechveliani]

Consider the following suggestions for the standard Haskell library
`List'.


import List (intersprerse, insertBy)

compose :: [a -> a] -> a -> a -- just appropriate name
compose =  foldr (.) id

insertBy2 :: (a -> b) -> Comparison b -> a -> [a] -> [a]
insertBy2f   cp  axs  =

  map fst $ insertBy (\ p p' -> cp (snd p) (snd p'))
   (a, f a) [(x, f x) | x <- xs]

Similar are  mergeBy2, sortBy2.

type ComparisonValue = LT | GT | Eq  deriving ... 
  -- better name than `Ordering'

type Comparison a= a -> a -> ComparisonValue 



Motivation example for `compose':

  myShowsList :: Show a => [a] -> String -> String
  myShowsList  xs  =
  compose $ intersperse (",  "++) $ map shows xs

  myShowsList (";  "++) [1,2,3] -->  "1;  2;  3"


Motivation example for  insertBy2:
Consider the program 
insertBy (\ n m -> compare (f n) (f m)) 100 [0 .. 1000],

where  f :: Integer -> Integer  is expensive to compute.
We see that the program
insertBy2 f compare 100 [1 .. 1000]

spends 2 times less of `f' invocations, and looks natural.

-
Serge Mechveliani
[EMAIL PROTECTED]

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Functional progr., infinity, and the Universe

[Jerzy Karczmarczuk]

Paul Hudak wrote:

Actually Brian's intuition is right on target.  One way to define an 
infinite list is as the limit of an infinite chain of partial lists 
(which, in domain theory, is essentially how all elements are defined). 


as the answer to Brian Hulley conjecture criticized by myself:

Couldn't an infinite list just be regarded as the maximum element of 
the (infinite) set of all finite lists?



If you are right, then YOU JUST PROVED THE EXISTENCE OF GOD.


Perhaps his intuition is right, but there are fundamental differences -

A. Between the chain of partial lists and the set of finite lists
B. Between a limit and the maximum element of a set.

OK, I think that this subject matured enough to rest in peace...


Jerzy Karczmarczuk
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Scoped data declarations

[Christophe Poucet]

Dear,Yesterday, while discussing with Cale and SamB on I suddenly came up with the crazy idea of scoped data declarations.  After some brief discussion to check the validity, I finally came to the conclusion that they should be feasible. In addition, I don't think that they would require a high amount of changes in current compilers.
Basically if you have something like:module Main wherefoo = let data Foo = Foo deriving Show in Foo\main :: IO ()main = print fooOne can see this as having an extra hidden module that defines Foo but that does not export it.  The only change that is then required is that while compiling Foo, the hidden-ness of Foo must be removed.
For instance, if one were to load this into, say, ghci (this is fictive of course):# ghci Main.hs> :t foofoo :: Codeloc2.FooThere were initially some objections to this, because it is no longer feasible to actually write the type of the function foo.  But if one looks at current GHC, this objection is already there:
module A(foo) wheredata Foo = Foo deriving Showfoo = Foomodule Main whereimport Amain = print fooAs Excedrin then pointed out, importing this Main into ghci, givesfoo :: Foo.Foo
And this notation can not be written in Main either, because Foo is hidden in A.Therefore, I would like to note that scoped data declarations are just like hidden data-declarations with two extra requirements:
1) Generate source-location-based submodule names2) Add an extra import rule for those hidden modules in the subexpressions of where the data-declaration is being originally defined.Comments are welcome, of course :)
Cheers!Christophe (vincenz)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ReadP and MonadFix

[Gracjan Polak]

Hi all,

A question for hot summer day: Text.ParserCombinators.ReadP.ReadP is
an instance of Monad. Could it be an instance of MonadFix too?

I'm not that sharp in Haskell to write it myself, but it seems I could
make use of such a beast. :) Anybody willing to share?

This will also present the advantage of Lazy over Eager Parser
Combinators, mentioned in some other thread.

--
Gracjan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Functional progr., images, laziness and alltherest

[Chris Kuklewicz]

Brian Hulley wrote:

Piotr Kalinowski wrote:

On 22/06/06, Brian Hulley <[EMAIL PROTECTED]> wrote:



For example, why do people accept that infinity == infinity + 1 ?
Surely this expression is just ill-typed. infinity can't be a number.


This equation is just a shortcut, so I can't see how can it be
ill-typed. It means something like: if you add one element to an
infinite list, will it be longer?


What does your intuition say about this?




Well, Archimedes thought: "..in the palimpsest we found Archimedes doing just 
that. He compared two infinitely large sets and stated that they have an equal 
number of members. No other extant source for Greek mathematics has that."


http://news-service.stanford.edu/news/2002/november6/archimedes-116.html

--
Chris
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Functional progr., images, laziness and all therest

[Ketil Malde]

"Brian Hulley" <[EMAIL PROTECTED]> writes:

>>> But how does this change the fact that y still has 1 more element
>>> than yq? yq is after all, not a circular list.

>> infinity+1 = infinity

> Surely this is just a mathematical convention, not reality! :-)

Not even that.  Infinity isn't a number, and it doesn't really make
sense to add one to it.

> Couldn't an infinite list just be regarded as the maximum element of
> the (infinite) set of all finite lists?

The point of infinity is that there is no maximum :-)

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Functional programming for processing of large raster images

[minh thu]

2006/6/23, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:

G'day all.


hey,

Quoting [EMAIL PROTECTED]:

> Recently Vo Minh Thu wondered if Haskell (or, I generalize, functional
> programming) can be of much use for computer graphics programming.

As others have pointed out, it's Haskell (and its laziness) that he
perceived to be the problem.

However, I'd like to take the discussion up one more level.


actually, i think my problem was at that upper level.


I hope that Thu doesn't mind me saying this, but off-list, I got a
better idea of the program that he was trying to write.  He's not
interested writing an image processing system.  In that sense, raster
images are actually not a central data structure.


no probs at all.

[snip remaining]

thank you for sharing that !

vo minh thu
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe