[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: |
Wed, 18 Nov 2009 07:43:44 -0000 |
#114: Improvements to tinyclos
---------------------------+------------------------------------------------
Reporter: tonysidaway | Owner: tonysidaway
Type: task | Status: accepted
Priority: major | Milestone:
Component: extensions | Version: 4.2.x
Keywords: tinyclos clos |
---------------------------+------------------------------------------------
Comment(by felix):
Replying to [comment:4 tonysidaway]:
>
> 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.
I always found the automatic definition of a generic (in case it doesn't
exist yet) somewhat arbitrary (even though it is convenient). The
implementation is also crude and needs to test whether the symbol has a
toplevel binding or not. Simply requiring the `define-generic` is in the
end more intuitive and simpler to understand and implement.
>
> 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).
Correct. AFAIK, there is no method-removal in the moment, right?
>
> 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.
Wouldn't that mean we have to figure out whether IDENTIFIER is bound? That
can't be done for local bindings, I think.
>
> 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.
The more I think about it, the more I like the simple approach as it is
currently implemented.
>
> 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)
Yes, that is better. Still, it would have to remove the method from the
generic after leaving the body.
--
Ticket URL: <http://www.irp.oist.jp/trac/chicken/ticket/114#comment:7>
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, 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/15
- [Chicken-janitors] Re: #114: Improvements to tinyclos,
Chicken Trac <=