[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Various Problem Comments

This page is part of the web mail archives of SRFI 20 from before July 7th, 2015. The new archives for SRFI 20 contain all messages, not just those from before July 7th, 2015.

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


(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].


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


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


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)


"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:


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)
	((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)) )


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