Dylan Design Queue w/ William's thoughts on what he consideres ``no-brainers'' > When creating a complex number, if the angle is specified but > not the magnitude, should the magnitude default to 1 rather > than 0? 3 Yes. Magnitude 1 is a much more useful default. In fact, using 0 for the default has 0 use. > doesn't provide a default for fill:, but string> does. These two should be made consistent. 2.9 Agreed. > Is there a reason Dylan doesn't have a difference or set- > difference function? (c.f. intersection and union)? 3.1 It should be added. > Should there be a (setter dimensions) operation for > adjusting an array? (moon) 3.0 Not at the level. If someone wants to introduce an that allows (setter dimensions), then fine, but the default arrays shouldn't have to be adjustable. > Are dotimes, for, etc. specified to create fresh bindings each time through > the loop? (alms) 2.7? They should be. > The manual doesn't say whether the iteration variables in for, for- > each, and dotimes are bound when the result-forms are evaluated. 1.7 for, for-each - the vars should be bound to the same values they had when the end-test evaluated to true. dotimes - whether or not the var is bound, and what it is bound to if it is, should be explicity unspecified. > Should a boolean return value be defined as "#f or #t", rather than as > "#f or anything else"? Should there be a class?*** (moon) Standard predicates should always return either #f or #t (unless someone can make a strong case for a particular predicate to return a particular non-#t truth value). The compiler can trivially optimize away the load of #t when the predicate is used in an ``if'' context. > Should Dylan provide a default-instance generic function, which can > be used for finding a default instance, given a class? 4 No. > Should setter functions take the new value as the first arg? This > simplifies the case where the function takes a rest arg, and allows setter > functions which accept keyword arguments. Another interesting option > would be to make the new value the second argument. 2.6? The new value should be the first argument. And (set! (foo a b c ...) val) should expand into a use of bind to keep the order of evaluation the same: (set! (foo a b c ...) val) => (bind (((t1 t2 t3 ... tn) (values a b c ... val))) ((setter foo) tn t1 t2 t3 ...)) > Are everything besides symbols and pairs literal constants? (moon, gz) yes. > The draft indicates that (quote object ) makes object read-only. Surely it > is not the case that (quote "foo") is a read-only constant but "foo" is a > mutable constant! What are the real rules? I suggest the same as > Common Lisp: no modification of constants is allowed, but the > implementation does not necessarily detect violations. (moon) 1.1 Agreed. > Should all the current defining forms create constants? If so, we > probably need to add define-variable. 1.7 Either that, or add define-constant. > Should set! be allowed on function parameters? (tesler) 3.9 Yes. The compiler can trivially notice when the function parameter is not being set!, so allowing set! on function parameters offers no more optimization opportunities and just adds extra unnecessary restrictions. > What happens if a generic function is called and there is no applicable > method? Should Dylan specify something akin to CLOS's no- > applicable-method? (Moon) 3? No, it should just be an error. If someone wants to add a MOP-like extension that allows the trapping of this error, then fine, let them. But don't require it. > What does applicable-method? return if it isn't or doesn't contain an > applicable method? Probably #f. How about if it is given the wrong > number of arguments? Should it error or return #f? How about if it is > given illegal keyword args? (alms, gsb) 3.1 It should be an error if the wrong number of required arguments or invalid keywords are supplied. > Singleton specializers are insufficient for the relatively common > situation where you want to specialize on a class object or any of its > subclasses. A new kind of specializer to handle this would be relatively > easy to specify. 1.6? And easy to implement. We have it in our initial bootstrap version, and use it in serveral different places.