Brandon S. Allbery KF8NH wrote:
On 2008 Sep 3, at 14:34, Andrew Coppin wrote:
The amusing (?) part is that the interpretter itself is essentially
quite simple. I've implemented it several times before now. But what
I'm trying to do it make it print out elaborately formatted execution
traces
Ryan Ingram wrote:
It's pretty simple, I think.
type ExpGen = ReaderT [String] Gen
arbExp :: ExpGen Expression
-- exercise for the reader
instance Arbitrary Expression where
arbitrary = runReaderT arbExp []
coarbitrary = coarbExp
coarbExp (Var s) = variant 0 . coarbitrary s
On Thu, 2008-09-04 at 18:41 +0100, Andrew Coppin wrote:
Ryan Ingram wrote:
It's pretty simple, I think.
type ExpGen = ReaderT [String] Gen
arbExp :: ExpGen Expression
-- exercise for the reader
instance Arbitrary Expression where
arbitrary = runReaderT arbExp []
On Sep 4, 2008, at 13:41 , Andrew Coppin wrote:
Ryan Ingram wrote:
It's pretty simple, I think.
type ExpGen = ReaderT [String] Gen
arbExp :: ExpGen Expression
-- exercise for the reader
instance Arbitrary Expression where
arbitrary = runReaderT arbExp []
coarbitrary = coarbExp
On Thu, Sep 4, 2008 at 10:41 AM, Andrew Coppin
[EMAIL PROTECTED] wrote:
I love the way other people have wildly different ideas of simple than me.
I'm staring at this and completely failing to comprehend it. (But then,
anything with co in the name generally makes little sense to me...) Why on
Brandon S. Allbery KF8NH wrote:
You can define a set of valid transformations, have the interpreter
log each transformation, and verify that all are correct (that is,
that both the transformation and the logged result are correct.
This assumes the interpreter can be resolved down to a
Brandon S. Allbery KF8NH wrote:
On 2008 Sep 1, at 14:47, Andrew Coppin wrote:
I wonder - how do the GHC developers check that GHC works properly?
(I guess by compiling stuff and running it... It's a bit harder to
check that a lambda interpretter is working right.)
GHC has a comprehensive
On Wed, Sep 3, 2008 at 11:34 AM, Andrew Coppin
[EMAIL PROTECTED] wrote:
data Expression = Var String | Apply Expression Expression | Lambda String
Expression
How would you go about building random expression trees?
It's pretty simple, I think. Keep an environment of variable names
that are
On 2008 Sep 3, at 14:34, Andrew Coppin wrote:
Brandon S. Allbery KF8NH wrote:
You can define a set of valid transformations, have the interpreter
log each transformation, and verify that all are correct (that is,
that both the transformation and the logged result are correct.
This assumes
Jeremy Apthorp wrote:
2008/9/1 Andrew Coppin [EMAIL PROTECTED]:
Trouble is, as soon as you allow let-bindings, some clever person is going
to start writing recursive ones. And actually, that's a useful thing to be
able to do, but it makes figuring out the technical details... rather
Here is a *much* bigger problem: How do you check that an interpretter
is correct??
You can't very easily write a QuickCheck property that will generate
every possible valid expression and then check that the output of the
interpretter is formally equivilent. The QuickCheck property would be
On 2008 Sep 1, at 14:47, Andrew Coppin wrote:
I wonder - how do the GHC developers check that GHC works properly?
(I guess by compiling stuff and running it... It's a bit harder to
check that a lambda interpretter is working right.)
GHC has a comprehensive test suite (not included in the
Andrew Coppin wrote:
Here is a *much* bigger problem: How do you check that an interpretter
is correct??
Before checking for correctness, you have to define correctness. What is
the specification of your interpreter?
You can't very easily write a QuickCheck property that will generate
On 2008 Sep 1, at 20:06, Tillmann Rendel wrote:
Andrew Coppin wrote:
Any hints? Just how *do* you check something large like this?
You could write a lot of test cases, calculating the correct answers
by hand.
You could check that during evaluation, you have always wellformed
terms (e.g.
Jonathan Cast wrote:
On Fri, 2008-08-29 at 20:56 +0100, Andrew Coppin wrote:
I've been playing with this today, and no matter what rules I come up
with, it seems to be ridiculously easy to put the interpretter into an
infinite loop from which it will never escape. Is there any way to know
On Sun, Aug 31, 2008 at 12:46 AM, Andrew Coppin
[EMAIL PROTECTED] wrote:
Right. So if I have, say, the factorial function defined using the Y
combinator, there's no way to stop the interpretter expanding an infinite
number of copies of Y, even though in theory the factorial function should
Ryan Ingram wrote:
On Sun, Aug 31, 2008 at 12:46 AM, Andrew Coppin
[EMAIL PROTECTED] wrote:
Right. So if I have, say, the factorial function defined using the Y
combinator, there's no way to stop the interpretter expanding an infinite
number of copies of Y, even though in theory the
On Sun, 2008-08-31 at 17:29 +0100, Andrew Coppin wrote:
Ryan Ingram wrote:
On Sun, Aug 31, 2008 at 12:46 AM, Andrew Coppin
[EMAIL PROTECTED] wrote:
Right. So if I have, say, the factorial function defined using the Y
combinator, there's no way to stop the interpretter expanding an
On Sun, Aug 31, 2008 at 9:29 AM, Andrew Coppin
[EMAIL PROTECTED] wrote:
All of this strongly suggests that if you execute things in the correct
order, you can arrange it so that expressions that have a normal form will
be evaluated to it. But how to decide the correct evaluation order? For the
Ryan Ingram wrote:
What are you trying to get from the let binding? Sharing?
Convinience.
let x = foo in bar
is so much easier to write than
(\x - bar) foo
when foo and/or bar is large.
Trouble is, as soon as you allow let-bindings, some clever person is
going to start writing
2008/9/1 Andrew Coppin [EMAIL PROTECTED]:
Ryan Ingram wrote:
What are you trying to get from the let binding? Sharing?
Convinience.
let x = foo in bar
is so much easier to write than
(\x - bar) foo
when foo and/or bar is large.
Trouble is, as soon as you allow let-bindings, some
Neil Mitchell wrote:
Hi
I'm writing a simple interpretter for a small extended-lambda-calculus sort
of language. And I'd just like to say... RECURSIVE LET-BINDS! GH!!! _
Agreed :-)
I'm glad it's not just me! ;-)
(Oleg cat sez: see, yr type problum not so hard.)
To
On Fri, 2008-08-29 at 20:56 +0100, Andrew Coppin wrote:
Neil Mitchell wrote:
Hi
I'm writing a simple interpretter for a small extended-lambda-calculus sort
of language. And I'd just like to say... RECURSIVE LET-BINDS! GH!!! _
Agreed :-)
I'm glad it's not just
Hi
On 29 Aug 2008, at 21:12, Jonathan Cast wrote:
If you want to avoid infinite normal forms (or just plain lack of
normal
forms, as in let x = x in x or (\x - x x) (\ x - x x)), you need to
follow three rules:
1) Static typing
With you there.
2) No value recursion
Mostly with you:
On Fri, 2008-08-29 at 21:48 +0100, Conor McBride wrote:
Hi
On 29 Aug 2008, at 21:12, Jonathan Cast wrote:
If you want to avoid infinite normal forms (or just plain lack of
normal
forms, as in let x = x in x or (\x - x x) (\ x - x x)), you need to
follow three rules:
1) Static
Hi guys.
I'm writing a simple interpretter for a small extended-lambda-calculus
sort of language. And I'd just like to say... RECURSIVE LET-BINDS!
GH!!! _
No other part of the program has consumed nearly as much brain power as
me trying to figure out when it is and isn't safe to replace
Hi
I'm writing a simple interpretter for a small extended-lambda-calculus sort
of language. And I'd just like to say... RECURSIVE LET-BINDS! GH!!! _
Agreed :-)
To illustrate:
let x = f x; y = 5 in x y
A simple-minded interpretter might try to replace every occurrance of x
with f x.
On Wed, Aug 27, 2008 at 08:59:28PM +0100, Andrew Coppin wrote:
let y = 5 in (f x) y
...and x is now a free variable. OOPS!
Trying to tease out exactly under which conditions you can and cannot
perform the substitution is utterly maddening. Since this is a Haskell
mailing list and as
You can get rid of all recursive bindings by transforming them into a
use of a fixpoint combinator.
And then you can use a non-recursive definition of the fixpoint
combinator, and never worry about recursive bindings again.
-- Lennart
On Wed, Aug 27, 2008 at 8:59 PM, Andrew Coppin
[EMAIL
2008/8/28 Lennart Augustsson [EMAIL PROTECTED]:
You can get rid of all recursive bindings by transforming them into a
use of a fixpoint combinator.
And then you can use a non-recursive definition of the fixpoint
combinator, and never worry about recursive bindings again.
This[1] might be a
30 matches
Mail list logo
