[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" <email@example.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
> 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.