[Chicken-janitors] Re: #114: Improvements to tinyclos

[Chicken Trac]

#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.