Send Beginners mailing list submissions to
beginners@haskell.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
beginners-requ...@haskell.org
You can reach the person managing the list at
beginners-ow...@haskell.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: Defining custom parser using Parsec (Jimmy Wylie)
2. Re: Defining custom parser using Parsec (Brent Yorgey)
3. Re: Defining custom parser using Parsec (Antoine Latter)
4. Re: Defining custom parser using Parsec (Magnus Therning)
5. Re: Defining custom parser using Parsec (Stephen Tetley)
6. Re: GHC-generated executables size (David Virebayre)
7. Re: GHC-generated executables size (Daniel Fischer)
8. small question (Mohamed)
----------------------------------------------------------------------
Message: 1
Date: Mon, 18 Oct 2010 16:58:42 -0500
From: Jimmy Wylie <jwy...@uno.edu>
Subject: Re: [Haskell-beginners] Defining custom parser using Parsec
To: Magnus Therning <mag...@therning.org>
Cc: "beginners@haskell.org" <beginners@haskell.org>
Message-ID: <4cbcc312.1090...@uno.edu>
Content-Type: text/plain; charset="UTF-8"; format=flowed
> This sounds awfully lot like a premature optimisation, which as we all
> know, is the root of evil :-)
>
> Why do you think that using Parsec will result in fewer
> transformations? (It will most likely result in fewer transformations
> *that you see*, but that doesn't mean much.)
>
I think you're right. I misunderstood the way the parsec library
worked, and was trying to run before I could walk.
However, it is a priority that I make this tool as fast as possible (as
close to drive speed as I can). I wanted to take an "incremental"
approach to optimization: writing small pieces, optimizing them, and
then putting them together. I am also facing faculty skeptical that I
can make things "fast" in haskell. (Currently, most DF applications are
written in Python and C).
> http://therning.org/magnus/archives/289
> http://therning.org/magnus/archives/290
> http://therning.org/magnus/archives/295
> http://therning.org/magnus/archives/296
>
> /M
>
> [1]: http://hackage.haskell.org/package/attoparsec-0.8.1.1
>
Thanks for the references. They're great blog posts, very easy to
follow. I didn't realize how simple Parsec was to use, at least in the
Monadic form. For some reason, I thought it was more complex.
I do have one question though. Do you always have to define your own
Applicative instance for GenParser when trying to use the Applicative
form? I noticed that both you and also RWH defined your own when
explaining this form of Parsec. Is there no standard Parsec.Applicative
in the library.
Thanks again for your help,
Jimmy
------------------------------
Message: 2
Date: Mon, 18 Oct 2010 18:31:14 -0400
From: Brent Yorgey <byor...@seas.upenn.edu>
Subject: Re: [Haskell-beginners] Defining custom parser using Parsec
To: beginners@haskell.org
Message-ID: <20101018223113.ga5...@seas.upenn.edu>
Content-Type: text/plain; charset=us-ascii
On Mon, Oct 18, 2010 at 04:58:42PM -0500, Jimmy Wylie wrote:
>
> I do have one question though. Do you always have to define your own
> Applicative instance for GenParser when trying to use the Applicative
> form? I noticed that both you and also RWH defined your own when
> explaining this form of Parsec. Is there no standard
> Parsec.Applicative in the library.
I believe Parsec exports an Applicative instance in version 3.0 and
later, but previous versions of Parsec did not include it. After all,
the first few versions of Parsec were written before Applicative was
invented. =)
-Brent
------------------------------
Message: 3
Date: Mon, 18 Oct 2010 21:28:30 -0500
From: Antoine Latter <aslat...@gmail.com>
Subject: Re: [Haskell-beginners] Defining custom parser using Parsec
To: Jimmy Wylie <jwy...@uno.edu>
Cc: Magnus Therning <mag...@therning.org>, "beginners@haskell.org"
<beginners@haskell.org>
Message-ID:
<aanlktikn0fsraq6wt_jvfco+cwkrpda0yc+v2xmny...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Mon, Oct 18, 2010 at 4:58 PM, Jimmy Wylie <jwy...@uno.edu> wrote:
>
>> This sounds awfully lot like a premature optimisation, which as we all
>> know, is the root of evil :-)
>>
>> Why do you think that using Parsec will result in fewer
>> transformations? Â (It will most likely result in fewer transformations
>> *that you see*, but that doesn't mean much.)
>>
> I think you're right. Â I misunderstood the way the parsec library worked,
> and was trying to run before I could walk.
> However, it is a priority that I make this tool as fast as possible (as
> close to drive speed as I can). Â I wanted to take an "incremental" approach
> to optimization: writing small pieces, optimizing them, and then putting
> them together. I am also facing faculty skeptical that I can make things
> "fast" in haskell. (Currently, most DF applications are written in Python
> and C).
>
If parsec turn out to not be fast enough for you, the attoparsec[1]
library has a very similar interface to parsec but is expressly
written for parsing data from bytestrings. I don't know what its
backtracking strategy is, however.
The cereal[2] library also supports the Alternative operations in the
Control.Applicative, and is written for decoding low-level binary
streams, so it presumably also support some form of backtracking. It
doesn't ship with a "manyTill' function, which is what I would want to
use for your data, but it doesn't look hard to write. I have no idea
how well it would perform, though.
Let us know how parsec works for you.
Antoine
[1] http://hackage.haskell.org/package/attoparsec
[2]
http://hackage.haskell.org/packages/archive/cereal/0.3.0.0/doc/html/Data-Serialize-Get.html
------------------------------
Message: 4
Date: Tue, 19 Oct 2010 07:43:47 +0100
From: Magnus Therning <mag...@therning.org>
Subject: Re: [Haskell-beginners] Defining custom parser using Parsec
To: "beginners@haskell.org" <beginners@haskell.org>
Message-ID: <4cbd3e23.5090...@therning.org>
Content-Type: text/plain; charset="utf-8"
On 18/10/10 22:58, Jimmy Wylie wrote:
>
>> This sounds awfully lot like a premature optimisation, which as we all
>> know, is the root of evil :-)
>>
>> Why do you think that using Parsec will result in fewer transformations?
>> (It will most likely result in fewer transformations *that you see*, but
>> that doesn't mean much.)
>>
> I think you're right. I misunderstood the way the parsec library worked,
> and was trying to run before I could walk.
> However, it is a priority that I make this tool as fast as possible (as
> close to drive speed as I can). I wanted to take an "incremental" approach
> to optimization: writing small pieces, optimizing them, and then putting
> them together. I am also facing faculty skeptical that I can make things
> "fast" in haskell. (Currently, most DF applications are written in Python
> and C).
Well, I wouldn't say Python is *fast*, but as they say, it's often *fast
enough*. I don't see any reason for Haskell to do worse than that.
Profile stuff, both tools in C and Python that others have written, and your
own code. My experience is that many people, if not most, are guided not by
actual numbers but by some vague idea that low-level control somehow always
result in faster code.
>> http://therning.org/magnus/archives/289
>> http://therning.org/magnus/archives/290
>> http://therning.org/magnus/archives/295
>> http://therning.org/magnus/archives/296
>>
>> /M
>>
>> [1]: http://hackage.haskell.org/package/attoparsec-0.8.1.1
>>
> Thanks for the references. They're great blog posts, very easy to follow. I
> didn't realize how simple Parsec was to use, at least in the Monadic form.
> For some reason, I thought it was more complex.
Yeah, it's surprising isn't it? :-)
> I do have one question though. Do you always have to define your own
> Applicative instance for GenParser when trying to use the Applicative form?
> I noticed that both you and also RWH defined your own when explaining this
> form of Parsec. Is there no standard Parsec.Applicative in the library.
Those blog posts were written using Parsec 2.
As others have said, Parsec 3 is better equipped. Apparently both with
support for ByteString (which I didn't know) and an implementation for
Applicative (that I did know).
/M
--
Magnus Therning (OpenPGP: 0xAB4DFBA4)
magnusï¼ therningï¼org Jabber: magnusï¼ therningï¼org
http://therning.org/magnus identi.ca|twitter: magthe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url :
http://www.haskell.org/pipermail/beginners/attachments/20101019/6156a294/signature-0001.bin
------------------------------
Message: 5
Date: Tue, 19 Oct 2010 08:25:57 +0100
From: Stephen Tetley <stephen.tet...@gmail.com>
Subject: Re: [Haskell-beginners] Defining custom parser using Parsec
Cc: "beginners@haskell.org" <beginners@haskell.org>
Message-ID:
<aanlktinzqmy3fvrb_arqbcj6gblbuhed9qpvhyf_n...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 19 October 2010 03:28, Antoine Latter <aslat...@gmail.com> wrote:
> The cereal[2] library also supports the Alternative operations in the
> Control.Applicative, and is written for decoding low-level binary
> streams, so it presumably also support some form of backtracking. It
> doesn't ship with a "manyTill' function, which is what I would want to
> use for your data, but it doesn't look hard to write. I have no idea
> how well it would perform, though.
Well thought out "serialization" formats shouldn't need a backtracking
parser, as backtracking introduces a substantial performance penalty.
Where binary data formats have alternatives the choice to take is
typically flagged with a tag byte first. I haven't looked much at
recent textual serialization formats like JSON - if they need
backtracking it would be my opinion that they're not very well
designed.
If you want speed for deserializing with a combinator parser avoiding
backtracking choice (i.e. Alternative) is the way to go.
------------------------------
Message: 6
Date: Tue, 19 Oct 2010 13:23:40 +0200
From: David Virebayre <dav.vire+hask...@gmail.com>
Subject: Re: [Haskell-beginners] GHC-generated executables size
Cc: beginners@haskell.org
Message-ID:
<aanlktim+8q5eaxvqs7jrytfq34teahufoj0cbdboc...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
2010/10/17 Daniel Fischer <daniel.is.fisc...@web.de>:
> $ cat helloWorld.hs
> module Main (main) where
>
> main :: IO ()
> main = putStrLn "Hello, World!"
> $ ghc --make helloWorld.hs
> [1 of 1] Compiling Main       ( helloWorld.hs, helloWorld.o )
> Linking helloWorld ...
> $ ls -l helloWorld
> -rwxr-xr-x 1 dafis users 618581 17. Okt 13:53 helloWorld
jhc makes remarkably small executables, this example takes 11268
bytes, 5756 when stripped.
Sad that many libraries, and gtk2hs don't work with it.
David.
------------------------------
Message: 7
Date: Tue, 19 Oct 2010 14:01:25 +0200
From: Daniel Fischer <daniel.is.fisc...@web.de>
Subject: Re: [Haskell-beginners] GHC-generated executables size
To: beginners@haskell.org
Message-ID: <201010191401.25449.daniel.is.fisc...@web.de>
Content-Type: text/plain; charset="utf-8"
On Tuesday 19 October 2010 13:23:40, David Virebayre wrote:
> 2010/10/17 Daniel Fischer <daniel.is.fisc...@web.de>:
> > $ cat helloWorld.hs
> > module Main (main) where
> >
> > main :: IO ()
> > main = putStrLn "Hello, World!"
> > $ ghc --make helloWorld.hs
> > [1 of 1] Compiling Main       ( helloWorld.hs, helloWorld.o )
> > Linking helloWorld ...
> > $ ls -l helloWorld
> > -rwxr-xr-x 1 dafis users 618581 17. Okt 13:53 helloWorld
>
> jhc makes remarkably small executables, this example takes 11268
> bytes, 5756 when stripped.
Yes, JHC doesn't put a large runtime into the executables (and, as a whole
programme compiler can remove more dead code than GHC can).
Stripping GHC's helloWorld:
-rwxr-xr-x 1 dafis users 377240 19. Okt 13:55 helloWorld
>
> Sad that many libraries, and gtk2hs don't work with it.
What makes in unusable for me is that it doesn't yet have arbitrary
precision integers (if that changes, the library problem might step in).
I hope it gets proper Integers and better library support soon, it's quite
an exciting project.
>
> David.
Cheers,
Daniel
------------------------------
Message: 8
Date: Tue, 19 Oct 2010 07:13:05 -0700 (PDT)
From: Mohamed <bish...@yahoo.com>
Subject: [Haskell-beginners] small question
To: beginners@haskell.org
Message-ID: <804326.50168...@web62407.mail.re1.yahoo.com>
Content-Type: text/plain; charset="us-ascii"
Hello folks,
just a quickie here and would appreciate any help...
In this expression:
instance OBSERVATIONS Drinkability WaterWell Volunteer where
observe (Drinkability waterWell) volunteer = volunteer {vReport =
if (odorQuale (perceive (Odor waterWell) volunteer) == True &&
clarityQuale (perceive (Clarity waterWell) volunteer) == True && fullnessQuale
(perceive (Fullness waterWell) volunteer) == True) then (if (honesty) then
"drinkable" else "undrinkable") else (if (honesty) then "undrinkable" else
"drinkable")}
I get the following error:
Couldn't match expected type `Bool'
against inferred type `Volunteer -> Bool'
In the expression: honesty
In the expression: (if honesty then "drinkable" else "undrinkable")
In the `vReport' field of a record
It is worth mention that Volunteer id defined as follows:
data Volunteer = Volunteer {vid:: Id, vloc:: Id, odorQuale:: Bool,
clarityQuale:: Bool, fullnessQuale:: Bool, vQuale:: Bool, vReputation:: Float,
honesty:: Bool, vReport:: Report} deriving Show
Where Report is defined as:
type Report = String
I understand that the vReport field is not receiving a String as it should, but
I have completely failed in knowing why! I just think the nesting of the if
statements is correct but wonder why is it not working. What is the correct
code
to do what I intend from the abofe nonfunctioning if statements?
cheers,
m
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/beginners/attachments/20101019/8995e7ad/attachment.html
------------------------------
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 28, Issue 30
*****************************************
