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

[Chicken Trac]

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