I was feeling bored/in need of a challenge one day and cat seemed like
an
interesting programming language so I decided to implement it in
python.
It's turned out surprisingly well so I thought I'd share the result;
http://www.triv.org.uk/~nelis/python/catlang.py
(Simply run the script to bring up an interactive session).
A few notes/thoughts;
1) Not all the functions are implemented yet, but enough to go through
the tutorial
page with. (it's very easy to add new ones though, and I may get round
to it).
2) There's no type annotation yet.
3) It feels a bit more lisp-like - at the moment there's not a lot of
distinction
between lists and functions - functions are simply lists of
instructions, defined
functions are simply lists associated with a name.
4) "define" feels a bit backwards - unlike the other instructions
(unless I missed
one), it needs it's two arguments above it on the list rather than take
arguments
already on the stack. Why is this?
Cheers,
Andy.
I like yours better than what I'd done, though. Nice work!
James
- Christopher
> 1) Not all the functions are implemented yet, but enough to go through
> the tutorial
> page with. (it's very easy to add new ones though, and I may get round
> to it).
I plan on grouping the primitives according to different levels of
support for the core language. I want there to be a way for people to
specify clearly what part of the library they implement. Not all Cat
implementations are going to want to include the regular expression
library for instance (and it may in fact go away).
> 2) There's no type annotation yet.
If you haven't seen the article on CodeProject.com (
http://www.codeproject.com/useritems/cat.asp ) it references a plan I
have of actually on making a specification for Cat without type
checking called "Kitten". In Kitten the type annotations would be
legal, but would be ignored.
> 3) It feels a bit more lisp-like - at the moment there's not a lot of
> distinction
> between lists and functions - functions are simply lists of
> instructions, defined
> functions are simply lists associated with a name.
This is more or less how I implemented functions in the C# interpreter.
> 4) "define" feels a bit backwards - unlike the other instructions
> (unless I missed
> one), it needs it's two arguments above it on the list rather than take
> arguments
> already on the stack. Why is this?
I do not view define as an instruction, but rather a built in
construct for associating names with functions. The challenge of
leaving define as a function, means that a quotation can contain a
definition. If this is the case you need to manage the names
dynamically on the stack. This is not neccessarily a bad thing, but it
does complicate matters for compilers and translator because the
interpretation of a user defined name suddently depends on the runtime
context.
I hope this helps,
keep up the great work!
Christopher
Random!
> I like yours better than what I'd done, though. Nice work!
Thanks, I'd like to see your version at some point too though - perhaps
we could combine efforts or I could simply steal the bits I fancy ;-)
Cheers,
Andy.