[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Chicken-janitors] Re: #114: Improvements to tinyclos
From: |
Chicken Trac |
Subject: |
[Chicken-janitors] Re: #114: Improvements to tinyclos |
Date: |
Sun, 15 Nov 2009 20:08:24 -0000 |
#114: Improvements to tinyclos
---------------------------+------------------------------------------------
Reporter: tonysidaway | Owner: tonysidaway
Type: task | Status: new
Priority: major | Milestone:
Component: extensions | Version: 4.2.x
Keywords: tinyclos clos |
---------------------------+------------------------------------------------
Comment(by tonysidaway):
I think you're right about my early naive attempts to make tinyclos more
Scheme-like. It needs much more thought to get it right. I invite your
comments on the following.
At the moment I'm inclined to say we could provide two levels of support.
Firstly define-method could make minimal efforts to support CLOS-like
behavior, by defining a generic if necessary, but following the semantics
of Scheme's define when it does so. define-method inside a (begin ...)
may create a top-level definition bound to the result of a call to define-
generic. define-generic inside a block--a lambda or let form--may create
a local definition bound to the same result. To ensure reliable top-level
semantics, define-generic must be used to create the necessary top-level
binding, and this binding must not be lexically shadowed when define-
method is used. The effect of ignoring these strictures is not fatal but
it results in behavior that may be difficult to explain to people who
expect tinyclos to ignore Scheme's strict lexical scope.
Secondly something along the lines of your let-generic, let-method
suggestions could be introduced to provide something Scheme-like. I like
the idea of a let-class, too. A let-generic...let-class block hierarchy
would foster the encapsulation of methods and classes in a way that fits
the block structure of Scheme and the principles of object oriented
design: the methods and classes can be defined computationally within the
block. If top-level bindings are desired, methods for returning values
from the block to the top level are built into Scheme.
(let-generic (IDENTIFIER...) BODY)
(let-class ((CLASSIDENTIFIER (DIRECT-SUPER ...) (SLOT ...)) ...) BODY)
let-method is a very different kettle of fish. That would require a way to
undefine a method (to dissociate it from its generic). This could
probably be done most cleanly by duplicating the generic into another
newly-created generic of the same name (and using an identifier bound to
the same symbol within the define-method block).
Something like this:
(let-method (((IDENTIFIER SPECIFIER...) METHOD-BODY) ...) BODY)
In the form I suggest above, semantics similar to those I have suggested
for define-method would apply. If a generic is already defined with
IDENTIFIER, it is cloned into a new generic bound to the same symbol for
the scope of the block. If no such generic exists (the symbol IDENTIFIER
may not be bound or it may bound to some other object in the enclosing
block or at the top level) then a new blank generic is bound to IDENTIFIER
for the scope of the block.
The cloning of generics like this is a bit odd, but it could be useful.
It's very different from the definition of scope, so perhaps using a let
form isn't the best way to do it.
An alternative would be to use fluid-let semantics. In this scenario the
let-method form would require a pre-existing generic that would be
temporarily altered in such a way that the behavior of any closure over
the same generic would be affected. I still think cloning would be
involved, though I hope it may be possible to do away with that.
I would suggest that the fluid-let form should be clearly named so as to
indicate its underlying semantics.
Thus:
(fluid-let-method (((IDENTIFIER SPECIFIER...) METHOD-BODY) ...) BODY)
--
Ticket URL: <http://www.irp.oist.jp/trac/chicken/ticket/114#comment:4>
Chicken Scheme <http://www.call-with-current-continuation.org/>
Chicken Scheme is a compiler for the Scheme programming language.
- [Chicken-janitors] #114: Improvements to tinyclos, Chicken Trac, 2009/11/10
- [Chicken-janitors] Re: #114: Improvements to tinyclos, Chicken Trac, 2009/11/11
- [Chicken-janitors] Re: #114: Improvements to tinyclos, Chicken Trac, 2009/11/11
- [Chicken-janitors] Re: #114: Improvements to tinyclos, Chicken Trac, 2009/11/12
- [Chicken-janitors] Re: #114: Improvements to tinyclos,
Chicken Trac <=
- [Chicken-janitors] Re: #114: Improvements to tinyclos, Chicken Trac, 2009/11/15
- [Chicken-janitors] Re: #114: Improvements to tinyclos, Chicken Trac, 2009/11/15
- [Chicken-janitors] Re: #114: Improvements to tinyclos, Chicken Trac, 2009/11/18