RE: s-exprs + prototypes

["Anton van Straaten" <address@hidden>]

James McCartney wrote:
> On Sunday, June 22, 2003, at 12:42 AM, Anton van Straaten wrote:
> > I'd be more impressed if you could expose the function-like
> > constructs used in the implementation of methods, without
> > having to create objects with an apply method.
>
> But functions and methods *are* implemented as objects with an
> apply method.

Perhaps I just need to know more about the specific language(s) you're
talking about.  I'm saying that if you need to e.g. create a class with an
apply method and create instances of that class, in order to get standalone
functions, then the language in question has taken its paradigm to an
extreme which makes it less general, in a sense.  Or less basic, if you
prefer - I don't really care what term is used, only that there's a property
that is lost which has some importance.

If, OTOH, the languages you're talking about have something like the
Javascript situation in the specific respect that standalone functions are
already supported by the language or can be supported without shenanigans
like those described above, then I don't have a problem.

> Functions are objects and objects are functions. What is the difference?

A general-purpose object is "bigger" than a function - it contains more
machinery, whichever way you look at it.  One easy way to see this is to
note that objects (or their classes, depending) essentially contain
collections of functions, which also entails a dispatch mechanism to select
functions from the collection.  A function which happens to implement an
"object" may have to have all this same machinery, but other functions don't
need it.

> Smalltalk has standalone closures provided as a standard part of the
> language.

People don't write programs consisting only of such closures.  Why not?
Answers of the form "why would they want to" are non-responsive: I want to,
and I know others, including ex-Smalltalk users, who feel the same.

> The problem I have with Javascript (and Lua) is that the objects don't
> hide their implementation.
> You can access things as data or method. Objects should just be
> behaviour. Distinguishing between obj.thing and obj.thing() is a non
> starter for me. The feature you argue for is exactly what I don't want.

I think you misunderstood me.  Hiding implementation and the uniform
reference issue you mention to is not what I'm talking about at all, that
was just present in the example I gave because that's how Javascript happens
to work.  Take Javascript and have it expose its slots in a uniform,
encapsulated way that's acceptable to you, and it would still have the
feature I'm interested in, which is that essentially standalone functions
are integrated into the language core, not something that has to be
implemented as an extension which may not integrate as transparently with
the language.

> If I want a language that can implement any paradigm, then I'll choose
> C not Lisp.

C is a useful target language for the compilers of advanced languages,
including multi-paradigm languages.  Writing C by hand is just plain
inefficient.  May as well write assembler by hand.  People used to argue
about that too.

Anton