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: Re: Non-recursive binding expression (Brent Yorgey)
2. Re: Catching Exceptions in Haskell (Bjoern Brandenburg)
3. Re: Re: Catching Exceptions in Haskell (Peter Verswyvelen)
4. Re: Re: Non-recursive binding expression (j.romi...@gmail.com)
5. Finite State Machine .. (Tom Poliquin)
6. Re: Finite State Machine .. (Andrew Wagner)
7. Re: Re: Catching Exceptions in Haskell (Bjoern Brandenburg)
8. Re: Non-recursive binding expression (Will Ness)
9. Re: Non-recursive binding expression (Will Ness)
----------------------------------------------------------------------
Message: 1
Date: Sat, 28 Feb 2009 19:10:47 -0500
From: Brent Yorgey <byor...@seas.upenn.edu>
Subject: Re: [Haskell-beginners] Re: Non-recursive binding expression
To: beginners@haskell.org
Message-ID: <20090301001047.ga11...@seas.upenn.edu>
Content-Type: text/plain; charset=us-ascii
On Sat, Feb 28, 2009 at 10:31:37PM +0000, Will Ness wrote:
>
> That's what I understood the OP wanted - Scheme's LET, not LETREC, allowing
> for
> shadowing. I was suprised let-statement in do chain didn't work that way. I
> expected it to be equivalent to a kind of code above, since each new line in
> do
> block represents a nested function in explicit bind notation, and nested
> function binding definitely provides for non-recursive let kind of argument
> binding, with shadowing.
>
> I thought the whole point of having special let statement in do notation was
> not to have to write the kind of code above with singleton lists. Since we
> have
> shadowing there, it should've been so in let-statements too. Isn't it?
No, the point of let expressions in do-blocks is to have a convenient
way to make pure bindings, i.e. ones that aren't piped through >>= .
Note that let statements in do-blocks just get desugared into normal
let expressions:
do { let x = y ; stuff }
desugars into
let x = y in do { stuff }
Haskell simply doesn't have anything equivalent to Scheme's LET,
except for actual nested functions.
-Brent
------------------------------
Message: 2
Date: Sat, 28 Feb 2009 19:48:19 -0500
From: Bjoern Brandenburg <bbb....@gmail.com>
Subject: [Haskell-beginners] Re: Catching Exceptions in Haskell
To: beginners@haskell.org
Message-ID:
<7ba288b20902281648k26f27114n832d78684d848...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Ok, so I was able to extract a simpler program with the same symptoms.
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=1900#a1900
Apparently the exception is only triggered when m is used in line 31.
So I guess that evaluate in line 24 is not causing strict evaluation
of the Data.Binary.Get monad, even though it is working for the error
and assert tests.
Why is that? Is that expected? If so, what am I doing wrong?
Thanks,
Bjoern
------------------------------
Message: 3
Date: Sun, 1 Mar 2009 03:16:13 +0100
From: Peter Verswyvelen <bugf...@gmail.com>
Subject: Re: [Haskell-beginners] Re: Catching Exceptions in Haskell
To: Bjoern Brandenburg <bbb....@gmail.com>
Cc: beginners@haskell.org
Message-ID:
<a88790d10902281816p23706918x5fa404c37eb41...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
The 3rd exception is raised when (show m) is computed, since no
exception occurred when evaluating (testGet L.empty) itself.
When you call "evaluate a", it only forces "one level" of evaluation of a.
E.g. if you would run
> evaluate (1:error "2":[]) >>= print . head
this would print 1, and not give an error.
You can maybe understand this better when you change
> (res :: Either SomeException String) <- try $ evaluate (f x)
into
> (res :: Either SomeException String) <- try $ return (f x)
Now the 2nd exception won't be raised either: evaluate digged one
level into assert, and that causes an exception, but return will not
do that, it will just return the unevaluated thunk that wraps the
assert computation, and this thunk will get evaluated when you print
it
You can get the behavior what you expect by using some functions from
Control.Parallel.Strategies.
Change
(res :: Either SomeException String) <- try $ evaluate (f x)
into
(res :: Either SomeException String) <- try $ evaluate (f x `using` rnf)
Now all 3 will throw an exception, as you expected. Why? (a `using`
rnf) reduces its argument (a) to "head normal form", which basically
means it evaluating all sub-expressions at all levels.
So
> evaluate (1:error "2":[] `using` rnf) >>= print . head
will now give an error.
Cheers,
Peter Verswyvelen
On Sun, Mar 1, 2009 at 1:48 AM, Bjoern Brandenburg <bbb....@gmail.com> wrote:
>
> Ok, so I was able to extract a simpler program with the same symptoms.
>
> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=1900#a1900
>
> Apparently the exception is only triggered when m is used in line 31.
> So I guess that evaluate in line 24 is not causing strict evaluation
> of the Data.Binary.Get monad, even though it is working for the error
> and assert tests.
>
> Why is that? Is that expected? If so, what am I doing wrong?
>
> Thanks,
> Bjoern
> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
------------------------------
Message: 4
Date: Sat, 28 Feb 2009 19:02:25 -0300
From: j.romi...@gmail.com
Subject: Re: [Haskell-beginners] Re: Non-recursive binding expression
To: beginners@haskell.org
Message-ID: <20090228220225.ga4...@darling.dhcp-geral>
Content-Type: text/plain; charset=us-ascii
On Sat, Feb 28, 2009 at 01:01:56PM -0500, Brent Yorgey wrote:
> On Sat, Feb 28, 2009 at 05:19:03PM +0000, Will Ness wrote:
> > <j.romildo <at> gmail.com> writes:
> >
> > >
> > > Hello.
> > >
> > > Is there any non-recursive binding expression in Haskell?
> > >
> > > Something that would allow me to write, for instance,
> > >
> > > test = let' xs = [] in
> > > let' xs = 3 : xs in
> > > let' xs = 8 : xs in
> > > let' xs = 7 : xs in
> > > xs
> >
> > Well, it's not a nice thing to do (probably), but you can write
> >
> > test = head $
> > do xs <- [ [] ]
> > xs <- [ 3:xs ]
> > xs <- [ 8:xs ]
> > xs <- [ 7:xs ]
> > return xs
> >
>
> The correct answer is no. Life is pain. Anyone who says otherwise is
> selling something. ;)
>
> Assignment in Haskell is not destructive update---it assigns a name to
> a value, and they become one flesh, until parted by death (i.e. the
> end of their lexical scope). The only reason Will's code works is
> that each line creates a new lexical scope, and each xs shadows the
> previous one.
I am not asking for assignment. What I want is indeed what I already
said: a new lexical scope which introduces a new variable, but the
variable name is being reused. That shadows the previous definition.
What I want is the possibilitiy of a non-recursive binding expression,
like my hypothecial let' construction. Being non-recursive,
let' <var> = <exp1> in <exp2>
any occurrence of <var> in <exp1> does not refer to the new varibale
being introduced, but to some previous defined variable named <var>. If
that does exist, than there is a semantic error in the expression
(unless <var> is not used in <exp1>, of course). So the scope of <var>
is just <exp2>. It does not include <exp1>. If it was a recursive
definition, the scope of <var> would be <exp1> *and* <exp2>.
Romildo
------------------------------
Message: 5
Date: Sat, 28 Feb 2009 18:36:22 -0800
From: Tom Poliquin <poliq...@softcomp.com>
Subject: [Haskell-beginners] Finite State Machine ..
To: beginners@haskell.org
Message-ID: <200902281836.22114.poliq...@softcomp.com>
Content-Type: text/plain; charset="us-ascii"
I'm working on a project (in Haskell) and was
given some old Java code to indicate the required
functionality for a particular function. It's a page of
nested (4 deep) if statements. (That's probably
why they gave me the code, no one could
describe it).
I would normally convert this to an FSM,
..... but this is Haskell!
So,
1) Is there a nice (canonical) way of eliminating
nested evil in Haskell? I thought that perhaps making
a tuple of all the if's conditions and patterm matching
on them might make a bit more comprehensible.
Likely there's a better way.
2) If an FSM is appropriate is there a 'standard'
Haskell FSM implementation?
I looked around and could find very little. One
paper talked about Arrows but that seems like a bit
of overkill ..
It actually seems like a fun problem .. if I
had the time ..
Any thoughts greatly appreciated!
Tom
------------------------------
Message: 6
Date: Sat, 28 Feb 2009 22:17:36 -0500
From: Andrew Wagner <wagner.and...@gmail.com>
Subject: Re: [Haskell-beginners] Finite State Machine ..
To: Tom Poliquin <poliq...@softcomp.com>
Cc: beginners@haskell.org
Message-ID:
<b8a8636e0902281917ie4e1b5fu97075e9fd11b0...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
This does sound interesting. Can you provide (at least some of) the code?
On Sat, Feb 28, 2009 at 9:36 PM, Tom Poliquin <poliq...@softcomp.com> wrote:
>
> I'm working on a project (in Haskell) and was
> given some old Java code to indicate the required
> functionality for a particular function. It's a page of
> nested (4 deep) if statements. (That's probably
> why they gave me the code, no one could
> describe it).
>
> I would normally convert this to an FSM,
> ..... but this is Haskell!
>
> So,
>
> 1) Is there a nice (canonical) way of eliminating
> nested evil in Haskell? I thought that perhaps making
> a tuple of all the if's conditions and patterm matching
> on them might make a bit more comprehensible.
> Likely there's a better way.
>
> 2) If an FSM is appropriate is there a 'standard'
> Haskell FSM implementation?
> I looked around and could find very little. One
> paper talked about Arrows but that seems like a bit
> of overkill ..
>
> It actually seems like a fun problem .. if I
> had the time ..
>
> Any thoughts greatly appreciated!
>
>
> Tom
> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.haskell.org/pipermail/beginners/attachments/20090228/4b918e51/attachment-0001.htm
------------------------------
Message: 7
Date: Sat, 28 Feb 2009 22:17:49 -0500
From: Bjoern Brandenburg <bbb....@gmail.com>
Subject: Re: [Haskell-beginners] Re: Catching Exceptions in Haskell
To: Peter Verswyvelen <bugf...@gmail.com>
Cc: beginners@haskell.org
Message-ID:
<7ba288b20902281917t5cfda8d4of687b68658a33...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Sat, Feb 28, 2009 at 9:16 PM, Peter Verswyvelen <bugf...@gmail.com> wrote:
> When you call "evaluate a", it only forces "one level" of evaluation of a.
I missed this fact when reading the documentation about evaluate.
Thank you for your explanation.
- Bjoern
------------------------------
Message: 8
Date: Sun, 1 Mar 2009 09:17:46 +0000 (UTC)
From: Will Ness <will_...@yahoo.com>
Subject: [Haskell-beginners] Re: Non-recursive binding expression
To: beginners@haskell.org
Message-ID: <loom.20090301t085747-...@post.gmane.org>
Content-Type: text/plain; charset=us-ascii
<j.romildo <at> gmail.com> writes:
>
> On Sat, Feb 28, 2009 at 01:01:56PM -0500, Brent Yorgey wrote:
> > On Sat, Feb 28, 2009 at 05:19:03PM +0000, Will Ness wrote:
> > > <j.romildo <at> gmail.com> writes:
> > >
> > > > Is there any non-recursive binding expression in Haskell?
> > >
> > Assignment in Haskell is not destructive update.
>
> I am not asking for assignment. What I want is indeed what I already
> said: a new lexical scope which introduces a new variable, but the
> variable name is being reused. That shadows the previous definition.
>
> Romildo
The code I posted has exactly these semantics:
When we write
test = head $
do xs <- [ [] ]
xs <- [ 3:xs ]
xs <- [ 8:xs ]
xs <- [ 7:xs ]
return xs
each xs in a singleton generator refers to its previous binding.
------------------------------
Message: 9
Date: Sun, 1 Mar 2009 09:33:39 +0000 (UTC)
From: Will Ness <will_...@yahoo.com>
Subject: [Haskell-beginners] Re: Non-recursive binding expression
To: beginners@haskell.org
Message-ID: <loom.20090301t090831-...@post.gmane.org>
Content-Type: text/plain; charset=us-ascii
Brent Yorgey <byorgey <at> seas.upenn.edu> writes:
>
> On Sat, Feb 28, 2009 at 10:31:37PM +0000, Will Ness wrote:
> >
> > That's what I understood the OP wanted - Scheme's LET, not LETREC, allowing
for
> > shadowing. I was suprised let-statement in do chain didn't work that way. I
> > expected it to be equivalent to a kind of code above, since each new line
in do
> > block represents a nested function in explicit bind notation, and nested
> > function binding definitely provides for non-recursive let kind of argument
> > binding, with shadowing.
> >
>
> No, the point of let expressions in do-blocks is to have a convenient
> way to make pure bindings, i.e. ones that aren't piped through >>= .
> Note that let statements in do-blocks just get desugared into normal
> let expressions:
>
> do { let x = y ; stuff }
>
> desugars into
>
> let x = y in do { stuff }
>
> Haskell simply doesn't have anything equivalent to Scheme's LET,
> except for actual nested functions.
>
> -Brent
>
Shadowing has its legitimate uses, for example when some value is refined while
being propagated through a chain of action-functions, there is no reason for
action-functions further down in the chain to have access to its previous,
outdated version.
Consider generating (i,j,k) triples representing Hamming numbers in some range,
along with their logarithm value, q = i*log 2 + j*log 3 + k*log 5, which gets
partially built as new indices get generated:
do k <- [0..kmax]
q <- [ k*log 5 ]
j <- [0..jmax]
q <- [ q + j*log 3]
i <- [0..imax]
q <- [ q + i*log 2]
return ((i,j,k),q)
Why not have some syntactic adornement in place of ugly-looking singleton
generators? Calling it LET got it confused with the regular LET; calling it SET
doesn't have to confuse anyone to believe it's destructive (it's not).
But if it's a syntactic re-write it ought to follow the semantics of the
original construct.
The possibility of having shadowing definitions got eliminated here with this
LET rewrite. It's not right.
After all, if we really had to have some recursive definition, we could always
use the regular let expression, like
do a <- as
set q = let zs=0:zs in zs
b <- bs
....
could we?
Cheers,
------------------------------
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 9, Issue 1
***************************************
