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
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
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 (Var v') | v == v'
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.
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
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
libraries
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
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
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
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
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) =
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 indented than
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 between function
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
_ | a0 - 1
| a0 - -1
| otherwise - 0
--
Best regards,
Bulat
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.
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 pattern1
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 matches,
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 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 = ...
| gard2 = ...
foo pattern2
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 = ...
foo pattern2
|
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, my inner
21 matches
Mail list logo
