Added strings to the things it understands, although it's just treated
like another Javascript literal, and there's no type checking. Also, tried very hard to write down my inspiration for how closures work, because it's something I'm not "ah-hah"ing about, but rather grinding about.
This commit is contained in:
parent
4089f80770
commit
8d4cb2b74e
|
@ -5,6 +5,7 @@ lispeval = (element, scope) ->
|
|||
|
||||
switch (car element)
|
||||
when 'number' then parseInt (cadr element), 10
|
||||
when 'string' then (cadr element)
|
||||
when 'symbol' then lookup scope, (cadr element)
|
||||
when 'list'
|
||||
proc = lispeval (caadr element), scope
|
||||
|
|
|
@ -23,9 +23,15 @@ module.exports =
|
|||
cmap((cdr cells), (cdr params), nscope))(cells, params, {})
|
||||
|
||||
# Execute and evaluate the body, creating an inner scope that
|
||||
# consists of all the bound variables (the parameters) evaluated
|
||||
# in the context of the function call, and all of free variables
|
||||
# evaluated in the context of the defining scope.
|
||||
# consists of: (1) the bound variables (the parameters)
|
||||
# evaluated in the context of the function call, because that's
|
||||
# where they were encountered (2) the free variables evaluated
|
||||
# in the context of the defining scope, because that's where
|
||||
# *they* were encountered.
|
||||
#
|
||||
# While this inspiration comes from Coglan, the clearest
|
||||
# explanation is from Lisperator's 'make_lambda' paragraph at
|
||||
# http://lisperator.net/pltut/eval1/
|
||||
|
||||
inner_scope = cons(new_scope, defining_scope)
|
||||
(nval = (body, memo) ->
|
||||
|
|
Loading…
Reference in New Issue