my current scheme system
cr88192
I have recently rewrote my scheme system (mostly this morning, 09-01).
I have a lot more framework type stuff in place, so many things which were
missing before (dynamic-wind, current-input-port, ...) may be implemented.
I have a reasonably simple system for dynamic variables:
defvar name value
defines a dynamic var name being bound to value.
letvar ((var value)...) forms...
works like let but binds dynamic variables. I have done this both for
technical reasons (it would be easier to bind dynamic vars differently),
and because it makes dynamic bindings more obvious.
(defvar x 3)
(define (f y) (* x y))
(f 4) => 12
(letvar ((x 5)) (f 4)) => 20
I still plan on implementing objects as "environment like" structures. a
more conventional system is also possible but I currently do not plan on
implementing it. my idea could be either useful or annoying depending on
how one looks at it, so a different system is likely needed as well...
this will be considered outside the core language.
I will likely keep a similar messaging system to that specified.
a stable ports system is needed, as ports have been continuosly dropped of
during the design process (mostly because they were tied to the system in
somewhat annoying ways). they should be better implemented once I have a
stable object system in place.
I have yet to really think up the relation between ports and sockets,
though I think one should be a specialization of the other.
functional overriding may be implemented as an extension.
comment?
--
<cr88192[at]hotmail[dot]com>
<http://bgb1.hypermart.net/>
cr88192
>
> I have recently rewrote my scheme system (mostly this morning, 09-01).
>
effectivly implement macros. I am currently considering a macro system
based on syntax-case.
at present I have a macro system based on defmacro, but it is kludgily
implemented in some ways... the macros will only work correctly if defined
at top level as well...
>
> I still plan on implementing objects as "environment like" structures. a
> more conventional system is also possible but I currently do not plan on
> implementing it. my idea could be either useful or annoying depending on
> how one looks at it, so a different system is likely needed as well...
>
> this will be considered outside the core language.
>
objects and environments have been done allready now.
> I will likely keep a similar messaging system to that specified.
>
> a stable ports system is needed, as ports have been continuosly dropped of
> during the design process (mostly because they were tied to the system in
> somewhat annoying ways). they should be better implemented once I have a
> stable object system in place.
>
> I have yet to really think up the relation between ports and sockets,
> though I think one should be a specialization of the other.
>
eventually I decided to use conceptual "pipes", where each end may be
operated on individually. on one end it could be a file or socket, or
object, and the other is passed around so that it could be manipulated. the
exact usage on each end is currently considered unimportant.
these will work by sending messages over the pipe and accepting them at the
other end.
ports will likely be derived from this, and will be expected to reassemble
the message stream into a useful buffer...
> functional overriding may be implemented as an extension.
>
partially in place, doesn't work yet though...
currently I have it set up so that both syntaxes can be read from files,
with the syntax being determined based on file extension.
I am considering some repl commands to allow either syntax do be selected,
though currently only s-exprs are supported.
as of yet I have not thought up a good algo to determine which syntax is
being used. one possibility would be to look for comments, and the syntax
used for the comments indicates which to use.
this would require entering at least empty comments to change syntax...
however, this is cruddy.
I had tried a check based on determining if the first thing on a line was a
list, this is more implicit but will fail if an ordinary token is used
(unlikely outside a repl...). it had worked ok for files but failed when
used in the repl...
I am using the convention of postfixing the colon onto a symbol to indicate
keywords (thus "cmd:" is a keyword, but ":cmd" is a symbol, sadly this was
largely influenced by wanting := as an alternative to set!, and that it
looks better in my mind anyways...).
likely I will also need to finish implementing r5rs as well sometime...
cr88192
>> [meant to send last night but internet went down again...]
>>
>> I have recently rewrote my scheme system (mostly this morning, 09-01).
>>
> and now I am thinking I may need to rewrite much of the compile loop to
> effectivly implement macros. I am currently considering a macro system
> based on syntax-case.
>
largely done now.
> at present I have a macro system based on defmacro, but it is kludgily
> implemented in some ways... the macros will only work correctly if defined
> at top level as well...
>
I have reimplemented defmacro in terms of my half-complete syntax case.
syntax currently doesn't really work, and syntax-objects are currently just
s-expressions. hygenic macros are currently not really supported (outside
of gensym), I am considering "hygenic variables" which will flag themselves
as desiring renaming, these will be vars which end in a semicolon.
I had desired keeping variable renaming minimal so that hopefully the
output of macro expansions will still be readable...
>
>> functional overriding may be implemented as an extension.
>>
> partially in place, doesn't work yet though...
>
still planned. my guess is that there is a possible use in multimethods. in
general the same pattern matcher will be used between functions and macros.
at present argument currying is supported (actually it was more
"discovered" based on the way I had implemented binding).
thus:
(define (car (h . t)) h)
(define (cdr (h . t)) t)
are possible.
cr88192
> currently I have it set up so that both syntaxes can be read from files,
> with the syntax being determined based on file extension.
>
other than not being well suited for complex commands on a repl, it also
has a few minor annoyances.
sadly, I ended up implementing a special '^' macro (defmacro ^ (x) x) to
compensate for one of the more annoying cases.
ie:
forms ...
x
would be interpreted as (forms ... (x)), in cases where (forms ... x) was
desired.
the fixed version becomes:
forms ...
^ x
which in many cases can be less annoying and more clear than heavy use of
parenthesis and '\' (continued-on-next-line). in many cases this can reduce
the need to use '\' as well...
neither syntax is really great in my mind, but I am still biased twards
mine. in many cases it looks "better" than s-exprs, and seems more readable
(to me anyways) and saves counting parenthesis (when not using emacs...).
otherwise it is more ridged, and involves occasional hacks to get the same
flexibility of form as is expected with s-exprs.
it is a somewhat thin line as to wether this syntax is actually useful.