headers
Mark Carroll | 1 Jan 2004 01:17

Monads

Omitting the typeclass bit, I'm trying to write something like
(s1 -> s2) -> StateT s1 m () -> StateT s2 m a -> StateT s1 m a

That is, it sequences two StateT computations, providing a way to
translate from the first's state to the second to keep the chain
going.

I can easily write something for when s1 and s2 are the same, and my
understanding of much of Control.Monad.* remains tenuous at best, but if
it's easy for anyone to provide me with some tips, then I thought I should
mention that it'd certainly be helpful.

And Happy New Year, everyone!

-- Mark
Permalink | Reply | 3 comments |
headers
Mark Carroll | 1 Jan 2004 01:21

Parsec question

I tried posting this before but, from my point of view, it vanished. My
apologies if it's a duplicate.

In http://www.cs.uu.nl/~daan/download/parsec/parsec.html we read,

> testOr2 =   try (string "(a)")
>         <|> string "(b)"
>
> or an even better version:
>
> testOr3 =   do{ try (string "(a"); char ')'; return "(a)" }
>         <|> string "(b)"

Why is the latter better?

(BTW, I like Parsec. Thanks, Daan. (-:)

-- Mark
Permalink | Reply | 3 comments |
headers
Christopher Milton | 1 Jan 2004 02:42
Picon
Favicon

Re: Monads

Mark,

I'm no expert, but does it help to start from withStateT?

> withStateT :: (s -> s) -> StateT s m a -> StateT s m a
> withStateT f m = StateT $ runStateT m . f

There are some notes about computations and lifting
state transformers in

Modular Denotational Semantics for Compiler Construction
Sheng Liang, Paul Hudak
http://citeseer.nj.nec.com/liang96modular.html

Monad Transformers and Modular Interpreters
Sheng Liang, Paul Hudak, Mark Jones
http://citeseer.nj.nec.com/liang95monad.html

Don't mind me: I just couldn't control the vestiges of
librarianship lurking in my dark, lost soul...

Dobrego Nowego Roku!

Chris Milton (no, not MLton:-)

--- Mark Carroll <mark <at> chaos.x-philes.com> wrote:
> Omitting the typeclass bit, I'm trying to write something like
> (s1 -> s2) -> StateT s1 m () -> StateT s2 m a -> StateT s1 m a
> 
> That is, it sequences two StateT computations, providing a way to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ken Shan | 1 Jan 2004 05:39
Picon

Re: Monads

Mark Carroll <mark <at> chaos.x-philes.com> wrote in article
<Pine.LNX.4.58.0312311841030.15190 <at> niagara.mtbc.internal> in gmane.comp.lang.haskell.cafe:
> Omitting the typeclass bit, I'm trying to write something like
> (s1 -> s2) -> StateT s1 m () -> StateT s2 m a -> StateT s1 m a
> 
> That is, it sequences two StateT computations, providing a way to
> translate from the first's state to the second to keep the chain
> going.

Don't you need a (s2 -> s1) function as well, to translate the final
state back into StateT s1?

--

-- 
Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig
GW Bush: And when leaders make the wise and responsible choice, when they 
renounce terror and weapons of mass destruction, as Col. Ghadafi has 
now done, they serve the interest of their own people and they add to 
the security of all nations.  http://www.tmealf.com/survey_form.htm
Permalink | Reply | 1 comment |
headers
Mark Carroll | 1 Jan 2004 07:47

Re: Monads

On Wed, 31 Dec 2003, Ken Shan wrote:

> Don't you need a (s2 -> s1) function as well, to translate the final
> state back into StateT s1?

Yes, you're right: the thing actually running the stateful computation
presumably expects to start it with a state of type s1 and to be able to
extract from it a state of type s1 when it's done.

-- Mark
Permalink | Reply | 0 comments |
headers
Derek Elkins | 1 Jan 2004 10:27

Re: Parsec question

On Wed, 31 Dec 2003 19:21:54 -0500 (EST)
Mark Carroll <mark <at> chaos.x-philes.com> wrote:

> I tried posting this before but, from my point of view, it vanished.
> My apologies if it's a duplicate.
> 
> In http://www.cs.uu.nl/~daan/download/parsec/parsec.html we read,
> 
> > testOr2 =   try (string "(a)")
> >         <|> string "(b)"
> >
> > or an even better version:
> >
> > testOr3 =   do{ try (string "(a"); char ')'; return "(a)" }
> >         <|> string "(b)"
> 
> Why is the latter better?

As soon as you reach a point where a syntax error means no parse will
succeed you want to commit to that alternative for two reasons.  1) As
long as there appears to be a possibility for an alternative parse the
input needs to be saved and 2) there's no point backtracking if all
other alternatives will fail; it just wastes time.  In the above
example both issues come up.  If we successfully parse the
"(a" then the second alternative "(b)" can't possibly succeed and since
it can't succeed there's no point in saving the input "(a" to be
reparsed when backtracking since there's no point in backtracking. 
Obviously, this example is merely to illustrate the idea as there'd be
little to no inefficiency in this case.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tomasz Zielonka | 1 Jan 2004 10:54
Picon
Picon
Favicon

Re: Parsec question

On Wed, Dec 31, 2003 at 07:21:54PM -0500, Mark Carroll wrote:
> I tried posting this before but, from my point of view, it vanished. My
> apologies if it's a duplicate.
> 
> In http://www.cs.uu.nl/~daan/download/parsec/parsec.html we read,
> 
> > testOr2 =   try (string "(a)")
> >         <|> string "(b)"
> >
> > or an even better version:
> >
> > testOr3 =   do{ try (string "(a"); char ')'; return "(a)" }
> >         <|> string "(b)"
> 
> Why is the latter better?

testOr3 is a bit better at error reporting, for example:

  *> parseTest testOr2 "(a"
  parse error at (line 1, column 1):
  unexpected "a"
  expecting "(b)"

  *> parseTest testOr3 "(a"
  parse error at (line 1, column 3):
  unexpected end of input
  expecting ")"

But it still gives silly error messages in some cases:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Carroll | 1 Jan 2004 15:55

Re: Parsec question

Thanks to Tom for his interesting points. I am still developing an
inuition for how the error reporting goes. (-:

On Thu, 1 Jan 2004, Derek Elkins wrote:

(snip)
> > > testOr3 =   do{ try (string "(a"); char ')'; return "(a)" }
(snip)
> example both issues come up.  If we successfully parse the
> "(a" then the second alternative "(b)" can't possibly succeed and since
> it can't succeed there's no point in saving the input "(a" to be
> reparsed when backtracking since there's no point in backtracking.
(snip)

Ah, that makes sense - thanks! I think part of my problem might have been
the quoted and real brackets and braces - at least a couple of times, I
thought the char and the return were within the try. (-: I will try to
look more carefully next time.

-- Mark
Permalink | Reply | 0 comments |
headers
James Ealing | 2 Jan 2004 00:19
Picon
Favicon

Parsing library

I'm trying to make use of the combinatorial parsing
library to process strings. However, I can't figure
out the correct syntax for the (|||) (^^^) (>>>) (<^^)
and (^^>) functions. Can anyone see how to do it? If
so it'd be really useful if you could put down a
couple of examples of how each is used.
 
Thanks
 
Jim
 
The library:
 
Generic parsing functions
>module Parse (
>  Parse, succeed, token, spot, 
>  (|||), (^^^), (<^^), (^^>), (>>>), 
>  many, listOf, topLevel, 
>  white, ws, parseVar, word, parseNum)
>where

---------------------------------------------------
-- Combinatory parsing library using Maybe types --
--     suitable for non-ambiguous grammars.      --
--         sja4 <at> mcs.le.ac.uk (21/10/96)          --
---------------------------------------------------

>infixr 5 `into`, ^^^, <^^, ^^>
>infixl 4 >>>
>infixr 3 |||
(Continue reading)

Permalink | Reply | 501 comments |
headers
ajb | 2 Jan 2004 03:07
Favicon
Gravatar

Re: Perspectives on learning and using Haskell

G'day all.

Quoting Graham Klyne <gk <at> ninebynine.org>:

> (2) I find that I spend a far greater portion of my time *thinking* about
> what I'm trying to do than actually coding it.  There used to be an adage
> in the software industry that programmer productivity in lines-of-code per
> day was independent of programming language:  with Haskell, I suspect that
> old rule breaks down, because it seems that actually coding has become a
> relatively small part of the overall exercise.

In theory, that's true of other languages too.  Programmers are
*supposed* to spend more time doing non-coding than coding (where I
don't, for example, count writing unit tests as "coding").

I suspect that this is actually an artifact of your level of experience
with Haskell.  I know that I used to spend more time thinking than coding.
When you get familiar enough, you get to the stage where you can think on
your feet.

> (4) I have noticed that it's often very easy to write some inefficient code
> (sometimes *very* inefficient) to do some task in Haskell, and then to
> optimize it.

This, I believe, is one of the most unappreciated (by non-declarative
programmers, anyway) aspects of declarative programming.  It's easy to
write could-be-slow code that works first time, once you've fixed all
the bugs caught by the compiler.  Then, it's straightforward to swap out
implementations and replace them with more efficient ones as the need
arises.
(Continue reading)

Permalink | Reply | 11 comments |

Gmane