Various Problem Comments

[Kenneth Dickey <kend0@xxxxxxxxxxxxx>]

I find some aspects of this proposal UN-scheme like.

[1]=========

(define-class class-name superclass-name ...
                         ^^^^^^^^^^^^^^^

(instantiate class-name ...
             ^^^^^^^^^^

There are a number of forms where a class name is required but which should accept a class object.

Given multiple top-level namespaces (modules), the use of a single, separate namespace for classes seems very fragile.  [There is no relation of class to lexical or module scope].


[2]=========

(define-generic (generic-name variable ...)
  ;; where variable is
  ;;    symbol                                   ; regular variable
  ;;  | (symbol [ class-name ])                  ; discriminating variable
  [ default-body ] )

I would use the term "name" rather than "symbol" as a symbol is typically quoted but the 'variable' name is apparently not evaluated.


[3]=========

There is no accessor specified to get a Field from a Class by name or the number of fields in a class (nor a for-each-field form).

(Class-field class index)        ; Class * nat -> Field
(Field? value)                   ; anySchemeValue -> boolean
(Field-name field)               ; Field -> symbol


[4]=========

The setter syntax for fields differs from that of other Scheme forms, which take the new value as the last parameter.


(set-field-value! object value field [ index ]) ;; proposed
; Object * value * Field [* nat] -> unspecified


e.g. records:

(record-set! <record> <index> <value>) -> <unspecific>

e.g. generalized setters:

(set! (proc arg ...) value)


[5]=========

"The next method is defined to be the method that would have been invoked if the current method was absent. It is forbidden to define ambiguous multi-method that is a method that will make some signature ambiguous."

I would prefer a definition similar to Dylan's "more specific" multi-method specificity rules.


End of proposal comments..
====================================================================
ASIDE: comments on Meroon V3:

[A]=========

The 'co-instantiate' form has hidden side effects which I find dangerous.  I.e. in the example given 'p' and 'x' are side-effected.

I would prefer:

(define-values (p x)
  (with-co-instantiation
	((a TrucMuche :right x x x)
	 (b Point :x 22 :y (TrucMuche-left p)) )
	(values a b)))

to the example:

(define p 'junk)
(define x 'also-junk)
(co-instantiate   ;; side effects x and p
  ((p TrucMuche :right x x x)
   (x Point :x 22 :y (TrucMuche-left p)) )

[B]=========

I found Meroon to be fairly fragile.  E.g. I mistyped ":initialize" for ":initializer" in a define-class field specification with no error reported; I redefined a class which caused problems (as noted in the documentation).

====================================================================
Cheers,
-KenD