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

Re: s-exprs + prototypes


Fascinating example!  Thanks for posting this.

Your comment brings up a question that has been nagging at the back of my
head for a while: are some language paradigms "more general" than others?
If so, which are the "most general"?  For instance, I *feel* as if the
lisp/scheme language paradigm (essentially untyped lambda calculus) is
"more general" than the single-dispatch OO paradigm at the heart of
Smalltalk, but obviously both are equally powerful in a strict sense (you
can write mappings between each of them and the other).  So why do I feel
this way?  I guess it has to do with the fact that the receiver has a
privileged status in ST, but one could argue that the first argument in an
s-expression in scheme has a privileged status (it must be a procedure or
special form).  Or else it's that ST sort of locks you in to one object
system, whereas scheme is agnostic.  However, I could see arguments that
(say) the paradigms in prolog or haskell are in some senses more general
than those in scheme as well.

Does this bother anyone else?  Or do I just need to up my medication? ;-)


> From: "Anton van Straaten" <anton@appsolutions.com>
> Date: Fri, 20 Jun 2003 23:44:57 -0400
> Using PLT Scheme, it's very easy to implement a call syntax like this, which
> could be useful for prototyping your language.  For example, it's easy to
> redefine the low-level function application operator, which PLT calls #%app.
> With only 7 lines of code, all the examples in your message can be
> supported, and more.  Here goes:
>   (module reverse-apply mzscheme
>     ; define a "backwards" application operation
>     (define-syntax reverse-apply
>       (syntax-rules ()
>         [(_ fn) (fn)]  ;support zero-arg calls
>         [(_ obj fn arg ...) (fn obj arg ...)]))
>     ; allow this module to be used as a "language" (see below)
>     (provide (all-from-except mzscheme #%app)
>              ; provide reverse-apply, replacing default #%app
>              (rename reverse-apply #%app)))
> Once you set a paradigm for a language, such as that everything will be done
> by sending messages to an object, subsequent decisions have to make sense
> relative to the chosen paradigm.  It may not make sense to question these
> decisions outside that context.
> One issue that arises is whether the chosen paradigm is sufficiently general
> or appropriate to all the intended applications of the language - not to
> mention the unintended applications!  In most cases, the choice of paradigm
> is unlikely to attract users to a language: for example, people don't use
> Javascript because it's prototype-based or because it supports function
> objects and closures, they use it because it's embedded in browsers.  Its
> paradigm is really quite secondary.  A question to ask about a paradigm
> you're choosing for a language, is what problems the paradigm is addressing,
> and whether those problem can or should be addressed in a more
> general-purpose way, without dedicating the entire language to a particular
> way of doing things.
> Anton