[announment] squim, an implementation of kernel in javascript
55 views
Skip to first unread message
Mariano Guerra
Jul 4, 2012, 11:35:24 AM7/4/12
to kl...@googlegroups.com
hi!
I think I said it in some previous mail, if not here it goes/
to try to understand kernel better I wanted to do an implementation of
it, so I started it last week and it's now in a state that can be
called an alpha implementation of kernel, for now it's called squim
and it's hosted on github:
http://github.com/marianoguerra/squim
it has a barebone page with a really basic REPL here:
http://marianoguerra.github.com/squim/
the tests are here:
http://marianoguerra.github.com/squim/test/
about the details:
it's implemented in js using requirejs for modularity and a pattern
that allows to load it like a normal javascript file
(https://github.com/umdjs/umd/blob/master/amdWebGlobal.js)
tested using qunit
parser using jison
for now it doesn't have a numerical tower, just wraps javascript
numbers, I may use one of the following in the future:
* https://github.com/dyoo/js-numbers/
* https://github.com/jtobey/javascript-bignum
from today it's implemented using continuations :)
my objective is to keep developing it into a full implementation of
kernel (another mail will come after this one with some ideas)
if you have any questions or observations just let me know.
PS: thanks all of you for clarifying some things in the last days,
they were all doubts I got while implementing it, expect more doubts
in the future ;)
I would like to add that reading the specification while implementing
it helps to understand it a lot better, the first time I read the
specification was really hard to get the details, so my recommendation
is "to really understand kernel just write an implementation of it" ;)
implemented functions are:
* $lambda
* $define!
* display
* operative?
* applicative?
* environment?
* boolean?
* symbol?
* inert?
* ignore?
* null?
* pair?
* eq?
* equal?
* $if
* $cond
* cons
* list
* make-environment
* get-current-environment
* eval
* $vau
* wrap
* unwrap
* $sequence
* car
* cdr
* apply
I think I said it in some previous mail, if not here it goes/
to try to understand kernel better I wanted to do an implementation of
it, so I started it last week and it's now in a state that can be
called an alpha implementation of kernel, for now it's called squim
and it's hosted on github:
http://github.com/marianoguerra/squim
it has a barebone page with a really basic REPL here:
http://marianoguerra.github.com/squim/
the tests are here:
http://marianoguerra.github.com/squim/test/
about the details:
it's implemented in js using requirejs for modularity and a pattern
that allows to load it like a normal javascript file
(https://github.com/umdjs/umd/blob/master/amdWebGlobal.js)
tested using qunit
parser using jison
for now it doesn't have a numerical tower, just wraps javascript
numbers, I may use one of the following in the future:
* https://github.com/dyoo/js-numbers/
* https://github.com/jtobey/javascript-bignum
from today it's implemented using continuations :)
my objective is to keep developing it into a full implementation of
kernel (another mail will come after this one with some ideas)
if you have any questions or observations just let me know.
PS: thanks all of you for clarifying some things in the last days,
they were all doubts I got while implementing it, expect more doubts
in the future ;)
I would like to add that reading the specification while implementing
it helps to understand it a lot better, the first time I read the
specification was really hard to get the details, so my recommendation
is "to really understand kernel just write an implementation of it" ;)
implemented functions are:
* $lambda
* $define!
* display
* operative?
* applicative?
* environment?
* boolean?
* symbol?
* inert?
* ignore?
* null?
* pair?
* eq?
* equal?
* $if
* $cond
* cons
* list
* make-environment
* get-current-environment
* eval
* $vau
* wrap
* unwrap
* $sequence
* car
* cdr
* apply
Andres Navarro
Jul 4, 2012, 1:35:04 PM7/4/12
to kl...@googlegroups.com
I had a look at it and it's looking pretty good. You should probably speak to Manuel Simoni, who is also writing a Kernel-like language in javascript and see what you are doing different.
A couple of points I think you should add to your TODO are: external representations and error displaying (right now, something resembling JSON seems to be used for external representation and errors just leave the result box as it was with no indication that an error occured).
Also, if you are done converting the interpreter to continuation passing style, it is trivial to add at least continuation?, call/cc and continuation->applicative, even if you still don't support continuation guarding.
Regards,
Andres Navarro
Manuel Simoni
Jul 4, 2012, 2:05:41 PM7/4/12
to kl...@googlegroups.com
I've added it to the "Kernel Underground" page at
http://axisofeval.blogspot.co.at/2011/09/kernel-underground.html
As you can see there are multiple JavaScript implementations of Kernel.
Manuel
Mariano Guerra
Jul 4, 2012, 4:06:43 PM7/4/12
to kl...@googlegroups.com
On Wed, Jul 4, 2012 at 7:35 PM, Andres Navarro <canav...@gmail.com> wrote:
> I had a look at it and it's looking pretty good. You should probably speak
> to Manuel Simoni, who is also writing a Kernel-like language in javascript
> and see what you are doing different.
>
> A couple of points I think you should add to your TODO are: external
> representations and error displaying (right now, something resembling JSON
> seems to be used for external representation and errors just leave the
> result box as it was with no indication that an error occured).
about representation, when I started I did the .toJs call when
> I had a look at it and it's looking pretty good. You should probably speak
> to Manuel Simoni, who is also writing a Kernel-like language in javascript
> and see what you are doing different.
>
> A couple of points I think you should add to your TODO are: external
> representations and error displaying (right now, something resembling JSON
> seems to be used for external representation and errors just leave the
> result box as it was with no indication that an error occured).
displaying, almost types all have an external representation according
to the spec, I will change that tomorrow.
about errors, by now it's working like it was before the
transformation to continuation passing style, that is, throw an
exception which seems to be lost somewhere :)
I will change that to at least having a global error continuation in
the following days.
> Also, if you are done converting the interpreter to continuation passing
> style, it is trivial to add at least continuation?, call/cc and
> continuation->applicative, even if you still don't support continuation
> guarding.
really easy, call/cc should be and I have to reread the
continuation->applicative section
Reply all
Reply to author
Forward
0 new messages