2007/7/1, Andrew Coppin <[EMAIL PROTECTED]>:
I'm going to have to take some time to bend my mind around that one too...
(Does anybody else on this list frequently get the feeling their IQ is
just too low for Haskell??)
I do. Sometimes when I find myself doing some type hackery.
And that's a
Felipe Almeida Lessa wrote:
On 7/1/07, Andrew Coppin <[EMAIL PROTECTED]> wrote:
(Does anybody else on this list frequently get the feeling their IQ is
just too low for Haskell??)
That's the best part of learning Haskell. You're always in touch with
the very best people --- directly or indirect
Mark T.B. Carroll wrote:
Andrew Coppin <[EMAIL PROTECTED]> writes:
(snip)
(Does anybody else on this list frequently get the feeling their IQ is
just too low for Haskell??)
I do. But then, when I finally understand something, it seems easy and
simple and I'm not sure why it wasn't obvi
On 7/1/07, Andrew Coppin <[EMAIL PROTECTED]> wrote:
(Does anybody else on this list frequently get the feeling their IQ is
just too low for Haskell??)
That's the best part of learning Haskell. You're always in touch with
the very best people --- directly or indirectly (i.e. using their
librarie
Andrew Coppin <[EMAIL PROTECTED]> writes:
(snip)
> (Does anybody else on this list frequently get the feeling their IQ is
> just too low for Haskell??)
I do. But then, when I finally understand something, it seems easy and
simple and I'm not sure why it wasn't obvious all along.
-- Mark
___
Stefan O'Rear wrote:
On Sun, Jul 01, 2007 at 05:06:10PM +0100, Andrew Coppin wrote:
Um... shouldn't that read
abstract v (a :@ b) = S :@ (transform (abstract v) a) :@: (transform
(abstract v) b)
No, because the whole point of transform is that it handles recursion
for you.
OK. Well
On Sun, Jul 01, 2007 at 05:06:10PM +0100, Andrew Coppin wrote:
> Stefan O'Rear wrote:
> >This is *much* easier expressed as a bottom-up traversal.
> >
> >compile = transform optimize . transform eliminate
> >
> >eliminate (Lam v e) = transform (abstract v) e
> >eliminate x = x
> >
> >abstract v (Va
Stefan O'Rear wrote:
This is *much* easier expressed as a bottom-up traversal.
compile = transform optimize . transform eliminate
eliminate (Lam v e) = transform (abstract v) e
eliminate x = x
abstract v (Var v') | v == v' = I
abstract v (a :@ b) = S :@ a :@ b
abstract v x = x
optimize (S :
Hi
> What's Uniplate?
http://www-users.cs.york.ac.uk/~ndm/uniplate/ may help to answer that
question. I haven't even finished understanding SYB, yet, though; I'm
still mystified by how to use Data.Generics.Twins.gzipWithQ. So, I'm
not at a stage where I can usefully contrast Uniplate with the
D
On Friday 29 June 2007, Andrew Coppin wrote:
> Jon Cast wrote:
> > On Wednesday 27 June 2007, Andrew Coppin wrote:
> >> Wow, wait a sec - case expressions are allowed to have guards too??
> >
> > Yes. I guess I assumed you knew that, sorry.
> >
> > The only syntactic (or semantic) difference betwe
Andrew Coppin writes:
> I wonder what the layout for that is... something like this?
>
> case foo of
> patter1
> | guard1 -> ...
> | guard2 -> ...
> pattern2
> | guard3 -> ...
> | guard4 -> ...
Something like that should work. If the patterns are more in
Andrew Coppin <[EMAIL PROTECTED]> writes:
(snip)
> Woah... Let me sit down and grok that for an hour or two. o_o
The Haskell learning curve - including the wonderful range of useful
generic stuff you can do with it - extends way higher than for many
other languages, I think, though you can write l
Stefan O'Rear wrote:
On Fri, Jun 29, 2007 at 07:18:00PM +0100, Andrew Coppin wrote:
Well, let me show you the code - somebody will probably recognise this
stuff...
convert1 :: Expression -> Expression
convert1 S = S
convert1 K = K
convert1 I = I
convert1 (Var v) = Var v
convert1 (x :@: y) =
On Fri, Jun 29, 2007 at 07:18:00PM +0100, Andrew Coppin wrote:
> Dan Mead wrote:
> >Andrew: Try using catchalls in your guards
> >
> >
> >pattern1
> >| guard1 =
> >| guard2 =
> >| otherwise =
> >
> >This makes it much easier to use pattern guards.
> >"otherwise" is a reserved word used for this stu
Dan Mead wrote:
Andrew: Try using catchalls in your guards
pattern1
| guard1 =
| guard2 =
| otherwise =
This makes it much easier to use pattern guards.
"otherwise" is a reserved word used for this stuff in ghc.
Yeah, it's good practice to include an explicit otherwise clause - but
in this
Jon Cast wrote:
On Wednesday 27 June 2007, Andrew Coppin wrote:
Wow, wait a sec - case expressions are allowed to have guards too??
Yes. I guess I assumed you knew that, sorry.
The only syntactic (or semantic) difference between function equations and
case expressions (aside from th
Jon Cast wrote:
Anyway, the second tutorial is correct: if all guards on pattern1 fail,
pattern2 will be tried next. See Section 3.17.3 in the Haskell Report [1].
Btw., which was the first tutorial?
Unfortunately, I cannot remember.
___
Haskell
Hello Andrew,
Thursday, June 28, 2007, 1:28:05 AM, you wrote:
> Wow, wait a sec - case expressions are allowed to have guards too??
btw, it's used to implement boolean switches:
case () of
_ | a>0 -> 1
| a<0 -> -1
| otherwise -> 0
--
Best regards,
Bulat
On Wednesday 27 June 2007, you wrote:
> Andrew: Try using catchalls in your guards
>
>
> pattern1
>
> | guard1 =
> | guard2 =
> | otherwise =
>
> This makes it much easier to use pattern guards.
> "otherwise" is a reserved word used for this stuff in ghc.
Since we're quoting the standard and all,
Andrew: Try using catchalls in your guards
pattern1
| guard1 =
| guard2 =
| otherwise =
This makes it much easier to use pattern guards.
"otherwise" is a reserved word used for this stuff in ghc.
-Dan
On 6/27/07, Jon Cast <[EMAIL PROTECTED]> wrote:
On Wednesday 27 June 2007, Andrew Coppin
On Wednesday 27 June 2007, Andrew Coppin wrote:
> Stefan O'Rear wrote:
> > On Wed, Jun 27, 2007 at 09:46:41PM +0100, Andrew Coppin wrote:
> >> I have a tricky little question...
> >>
> >> Suppose I write a function like this:
> >>
> >> foo pattern1
> >>
> >>| gard1 = ...
> >>| gard2 = ...
On Wed, Jun 27, 2007 at 10:28:05PM +0100, Andrew Coppin wrote:
> Stefan O'Rear wrote:
> >On Wed, Jun 27, 2007 at 09:46:41PM +0100, Andrew Coppin wrote:
> >
> >>I have a tricky little question...
> >>
> >>Suppose I write a function like this:
> >>
> >> foo pattern1
> >> | gard1 = ...
> >> | ga
Stefan O'Rear wrote:
On Wed, Jun 27, 2007 at 09:46:41PM +0100, Andrew Coppin wrote:
I have a tricky little question...
Suppose I write a function like this:
foo pattern1
| gard1 = ...
| gard2 = ...
foo pattern2
| gard3 = ...
| gard4 = ...
According to one tutorial I read, if
On Wednesday 27 June 2007, Andrew Coppin wrote:
> I have a tricky little question...
>
> Suppose I write a function like this:
>
> foo pattern1
>
> | gard1 = ...
> | gard2 = ...
>
> foo pattern2
>
> | gard3 = ...
> | gard4 = ...
>
> According to one tutorial I read, if pattern1
On Wed, Jun 27, 2007 at 09:46:41PM +0100, Andrew Coppin wrote:
> I have a tricky little question...
>
> Suppose I write a function like this:
>
> foo pattern1
>| gard1 = ...
>| gard2 = ...
> foo pattern2
>| gard3 = ...
>| gard4 = ...
>
> According to one tutorial I read, if pat
I have a tricky little question...
Suppose I write a function like this:
foo pattern1
| gard1 = ...
| gard2 = ...
foo pattern2
| gard3 = ...
| gard4 = ...
According to one tutorial I read, if pattern1 matches, pattern2 will
never be tried, even if both guard1 and guard2 fail.
A
26 matches
Mail list logo
