Write Yourself a Scheme in 48 Hours

Re:Write Yourself a Scheme in 48 Hours by tel on Friday March 27, 2015 @04:53PM (#9278926)

If you're talking about dynamic scoping then the cheapest way to pull that off is just to store the AST for your lambda, unevaluated, in the Env and evaluate it in the new Env which is available at call time.

It's all about controlling what evaluation occurs at what time. Here's another example: a language with dynamic and lexical bindings. You can see how the time when evaluation of the body of the lambda varies. I'm being very heavy-handed here, though—this only works for a pure language.

    type Name = String
    data Exp
      = Var Name
      | LexLam Name Exp
      | DynLam Name Exp
      | App Exp Exp
      | Base

    eval :: Exp -> Exp
    eval = eval0 emptyEnv where
      eval0 env e = case e of
        Var nm           -> lookup nm env -- throws exception on failure
        Base             -> Base
        LexLam name body -> LexLam name (eval0 (add env name (Var name)) body)
        DynLam _ _       -> e
        App l r -> case (eval0 env l, eval0 env r) of
          (LexLam name body, val) -> eval0 (singletonEnv name val) body
          (DynLam name body, val) -> eval0 (add env name val) body

[ Parent | on HN ]

Re:Write Yourself a Scheme in 48 Hours by tpush on Friday March 27, 2015 @08:10PM (#9279862)

Still not quite my point :-)

What I'm talking about is modeling this aspect of Scheme's behavior:

  (define x 5)
  (define (f y) (+ x y))
  (f 5) => 10
  (set! x 10)
  (f 5) => 15

Scheme's lambda evaluates its body during application, under the environment of its evaluation.

Your LexLam evaluated its body with the right env, but in the wrong time: A subsequent mutation of env would not alter the result of application.

Conversely, DynLam evaluates its body at the right time (during application), but with the wrong env. Given this code:

  (define (f y) (+ x y))
  (let ((x 5)) (f 5)) => Error, x is unbound in f

Your DynLam would incorrectly evaluate to 10, right?

I just don't see how to model this behavior without IORefs :-)

[ Parent | on HN ]

Re:Write Yourself a Scheme in 48 Hours by jerf on Friday March 27, 2015 @10:30PM (#9280242)

It's possible you just need to work with it for a while. IORefs can't do anything the State type can't do in a single-threaded execution context. Nothing prevents any evaluation strategy you propose that makes sense from being adopted by Haskell.

FWIW, I recognize your confusion as something I've had myself. I worked it out in Erlang, not Haskell, but it's the same principles. Again, ignoring threading, functional programming can do anything imperative programming can do with at most a log n penalty because at worst the functional program can simply simulate a raw expanse of memory in a tree and implement mutation on top of that. What you're asking about is ultimately much simpler than that but you may just have to work with it for a while. All I can really do is assure you that no, IORefs are completely unnecessary in this case.

And again let me emphasize my sympathies with your position and that I do not mean this harshly... I am recalling where I myself was in the past. Until I worked with it for long enough for it to click I'm not sure anyone really could have explained it to me. I'd been imperating for a long time.

[ Parent | on HN ]

Re:Write Yourself a Scheme in 48 Hours by tel on Friday March 27, 2015 @11:15PM (#9280362)

I wrote a number of posts pertaining to that log n trick:

http://jspha.com/posts/mutable_algorithms_in_immutable_langu...

[ Parent | on HN ]

Re:Write Yourself a Scheme in 48 Hours by tel on Friday March 27, 2015 @11:14PM (#9280359)

It would, but this can be solved using the same mechanisms by introducing genuine lexical and dynamic environments. My implementation was just a suggestive hack.

[ Parent | on HN ]