Re: s-exprs + prototypes

[James McCartney <address@hidden>]

On Saturday, June 21, 2003, at 02:22 PM, Anton van Straaten wrote:

> The generality I was referring to has to do with the degree to which a
> language dictates aspects of a program design.  If a language is 
> designed,
> for example, such that all values are objects which respond to 
> messages via
> a single-dispatch mechanism, then program designs that might benefit 
> from
> some other approach may not as easily or practically expressible in 
> that
> language.
>
> Of course, for any given program design, it's quite feasible and 
> usually
> easy to come up with an equivalent design that suits the paradigm of 
> the
> language being used - but then the language is dictating aspects of the
> design of the program.  All languages do this to some extent, but if a
> language requires you to express everything in terms of class-based 
> objects,
> or prototype-based objects, that's less general than a language which 
> makes
> fewer assumptions about what types of objects (or other construct) you 
> want
> to use, and how they should work.
>
> Another way to put this is in terms of the atomicity of core, 
> independent
> constructs in a language.  To use the current example, all useful 
> languages
> have some notion equivalent to a function.  In some OO languages, 
> though,
> functions are inextricably bound up with larger packages of 
> functionality,
> i.e. objects, which include a collection of functions.  There's an 
> internal
> notion of a function in these languages, i.e. a named behavior which
> operates on a set of arguments, but that internal construct can't be 
> used,
> independently of objects, by a user of the language.  Also, these 
> languages
> dictate the way in which the collections of functions can be accessed, 
> e.g.
> via single-dispatch.  There's a set of assumptions and decisions about 
> how
> programs should be written, related to which the language user has 
> little or
> no choice, and that's less general than a language in which fewer such
> assumptions are made.

Consider that an object is a function and the selector is its argument.
It is possible in my virtual machine to write a program like this, 
since I allow selectors to be anything, not just symbols, and by 
implementing only the 'doesNotUnderstand' message of an object you 
essentially have a function and you can write your program just as if 
it were Lisp in prefix syntax. You could write a + object that 
responded to all numbers as its selectors. You could even write a macro 
to do this.

So basically Lisp is no more general in this respect since I can map 
lisp onto an object system with a macro. I think the code to do this 
would be shorter than the code to implement my object system in Lisp 
would be.

>
> There's no reason why languages can't offer good support for specific
> paradigms as a layer or library above the core language, though.  Lisp 
> does
> this with CLOS, for example.  That gives you the best of both worlds, 
> in
> many ways,

Lisp+CLOS doesn't give you the best of OO because not everything is an 
object, so you have to work around the fact that your methods can't be 
as general as in a system where everything has the same flexibility.

-- 
--- james mccartney   james@audiosynth.com   <http://www.audiosynth.com>
SuperCollider - a real time audio synthesis programming language for 
MacOS X.