[plt-scheme] PLT-Scheme object system (was re: Image Snip initialization)

	I feel the same as David Richards about the PLT object
system---in particular the redundancy of make-object, new, and
instantiate (I never manage to remember which is which, for one
thing).  But to my mind the problem is not that these facilities
shouldn't be available or are holdovers from previous object systems,
but that mechanisms for specifying named or positional arguments have
nothing to do with object systems per se.  There should be a general
facility in the core of the language that suffices for these things.
I'd like to have the flexibility of specifying things any way I'd
like, but without the complication of three redundant forms to do so.
	Matthias argued that "orthogonal feature composition...[is]
almost a recipe for not succeeding in the market place."  Quite right,
but why?  To me there seems to be a principle of "conservation of
ugliness" at work---a language that is pretty in certain ways is bound
to be ugly in others.  Perl, for instance, has an almost exuberantly
nasty syntax, but enough pragmatic niceties to make it attractive to
many people; Scheme, even PLT Scheme, one might argue, tends to be the
other way around.  I have an intuitive sense as to why this is so (having
myself a great regard for beauty on the line-by-line, syntactic level,
as a result of which I never get anything done...), but perhaps the
present example can point the way to some 'Noetherian' symmetry
underlying Conservation of Ugliness:
	The first thing you notice about Scheme syntax, of course, is
all the parentheses; but in fact parentheses can indicate many
different things: not only execution and function calls, but grouping,
scope, and (within a let or during a named-argument function call)
naming.  This 'symmetry' makes things look nice, but may not be
entirely benign.  In the case of named arguments, since something like
(func (x 2) (y 3)) could be calling functions x and y with arguments 2
and 3 rather than specifying variables named x and y equal to 2 and 3,
we need to have special forms to distinguish one meaning from the
other.  But suppose we break the symmetry---write [x 2] when we mean
variable x with value 2, as we already do (informally) in let
statements.  Then we could write (func [x 2] [y 3]) without ambiguity
to indicate named arguments.  Putting named calls at the beginning of
the argument list, we could call \any function we liked with named
arguments or a mixture of named and positional.  There would be no
need for three ways to instantiate, among other things; we would also
be more inclined overall to use mnemonic variables in functions.
	Of course, we would have done this at the expense of
complicating core Scheme syntax.  You could argue about whether this
modification violates the spirit of the Scheme standard; it certainly
violates the letter, however.
	The moral of the story is that a language with a very pure
core must foist complications out to the periphery where, like
spokes radiating from a single central point, they multiply.  I
realize that PLT's mission does not include modifying Scheme itself.
But preserving standard Scheme presumably has costs, and this might be
an example of one of them.

Nick Chubrich.

On Thu, 3 Aug 2006, Matthias Felleisen wrote:

> 
> On Aug 3, 2006, at 7:02 PM, David Richards wrote:
> 
> > Well it helps a little, thanks.  But using the PLT object system  
> > makes me feel like I'm collecting idioms like a philatelist  
> > collects stamps.   Shouldn't object systems should be designed not  
> > by piling feature on top of feature, but by removing the weaknesses  
> > and restrictions that make additional features appear necessary?
> 
> 
> I have never heard this claimed about an OO language. It's a phrase  
> from the Scheme report.
> 
> OOP requires more syntax than FP but in return, gives you a few more  
> guarantees. It's a trade off. PLT Scheme's OO system is still less  
> notationally heavy than, say, Java.
> 
> One could argue that any _good_ language should be designed via  
> orthogonal feature composition. Then again, it's almost a recipe for  
> not succeeding in the market place. Do you know of a popular language  
> that satisfies this principle (not counting ALgol 60)?
> 
> -- Matthias
> 
> 
> 
> 
> > On Aug 3, 2006, at 6:26 PM, Robby Findler wrote:
> >
> >> In order to make the (old style) positional arguments work with the
> >> (new style) by name arguments, there are some confusing interactions
> >> (and error messages).
> >>
> >> In this case, you have to propagate the arguments from the  
> >> initializer
> >> to Image-Snip% to the arguments to image-snip% via super-make-object,
> >> which means you need to grab onto and re-send the arguments along.
> >>
> >> Maybe this example helps?
> >>
> >> (define Image-Snip%
> >>   (class* image-snip% ()
> >>
> > do i do augments and overrides here?
> >
> >>     (init a b c d)
> >
> > or here?
> >
> >>     (super-make-object a b c d)
> >
> >  or here?
> >
> >> ))
> >>
> >> (define Image (make-object Image-Snip% "/Users/dr/test.jpg" 'jpeg  
> >> #f #t))
> >>
> >> I believe that the reason image-snip% hasn't been converted to use  
> >> the
> >> by-name arguments is the "case-lambda"-like initialization it has
> >> already. In particular, the two argument case is completely different
> >> from the 4 argument case, and that isn't handled well by `new'.
> >
> > I wondered about that.
> >
> > http://www.fotosearch.com/comp/CRT/CRT388/15455-50dg.jpg
> >
> > - dr_________________________________________________
> >   For list-related administrative tasks:
> >   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> 
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>