twilightsentry

16 lat temudiscuss

You might want to look at Garnet and Amulet, which used a number of neat techniques with prototype-style objects to build user interfaces. There's a good summary of their work at:

  http://www.cs.cmu.edu/~amulet/papers/amuletappframe.pdf

On the FP side of things, I'd _very_ highly recommend "The Structure and Interpretation of Computer Programs," by Abelson and Sussman.

twilightsentry

17 lat temudiscuss

No, not really, unless you're running the code in a metacircular interpreter.

Imagine encoding the pair ('hello . 'world) into a function. You might say:

  (lambda (msg)
    (if (eq msg 'car) 'hello 'world))

You could get 'hello by applying that function to the 'car symbol, or 'world by applying it to anything else. Wrapping that in another function lets us generalise to any CAR/CDR.

  (lambda (car-value cdr-value)
    (lambda (msg)
      (if (eq msg 'car) car-value cdr-value)))

twilightsentry

17 lat temudiscuss

Oops; I meant to write those in CL, but I forgot about functions having their own namespace (been playing too long in a lisp-1). It should work in CL if you use FUNCALL.

If mquander's explanation isn't enough, you might look at it using terms from the OO world: CAR takes a pair object and calls its 'car method.

twilightsentry

17 lat temudiscuss

Well, you can define pairs like this (as long as you've got lexical scope):

  (setq cons (lambda (x xs)
               (lambda (msg)
                 (if (eq msg 'car) x xs)))

  (setq car (lambda (xs) (xs 'car)))
  (setq cdr (lambda (xs) (xs 'cdr)))

That only uses 'setq, 'lambda, 'if, 'eq, and quoted symbols. That pretty much gives you the untyped lambda calculus, plus some side effects. Throw in the appropriate macros and you've got the core of Scheme and Arc, without any I/O or efficient data representations.

You can take this pretty far. Essentially, you just need 'lambda and application. You could use church numerals for numbers, monads for side effects, the y-combinator for recursion, etc.

twilightsentry

17 lat temudiscuss

> Isn't light always going to move C faster then you?

Yes.

> Isn't it impossible to move "near speed of light"?

From your perspective, you'll always be slower than light by C. Your speed relative to another observer, however, can be arbitrarily close to C.

In classical mechanics, your speed relative to the other observer could add to C, resulting in "your" light, from her point of view, traveling faster than C. To avoid that discrepancy, special relativity postulates that her (or your, depending on the POV) movement through time is slowed until you both agree that light is moving at precisely C.

comments