[I originally posted this yesterday but it doesn't appear to have gone
through. I apologize if anyone is seeing this for the second time].
Hello all,
I just discovered the list. Its nice to see that Joy seems to be of
interest to a number of people. I've also
been inspired by Joy and have in fact been working on a Joy
implementation for some time now. Anyway, I'll just jump
into the current discussion with my 2 cents ...
> From: Mark van Gulik [mailto:ghoul6@h...]
> > wtanksley@b... said:
> > Forth includes a different construct which is useful for forming other
> > languages: the ability for a word to parse ahead of itself in the source
> > where it occurs. This ability is unique to concatenative languages (it's
> > completely unresonable in a language which has to be parsed before it's
> > executed).
>
> This may be true at the moment, but my short term plans (within the next
> year or so) for Avail involve something similar. In order to allow
> arbitrary language syntaxes to be supported directly in Avail, I want to
> support an unusual implementation of macros. Like the (multi)methods of
> Avail, these constructs will be strongly typed. The difference is that
> instead of taking values as arguments at runtime, the macros take parse
> trees at compile time. It will be horrendously difficult to get the parser
> to work this way (although the current parser was already horrendously
> difficult to write).
>
> [..]
Do you really think that having a totally extensible language syntax is
a Good Thing? It adds a lot of conceptual mass to the language
(syntactic macro systems tend to be complex) and it makes the
distinction between core syntax and extended syntax blurry. If I really
needed to embed another language I would rather just parse strings, eg:
"For x in <10,20,30> do Print x;" mylang_call
=> 10 20 30
Here, the mylang_call function takes a string, compiles it into a
program and executes it. There is a clear separation between the core
language and the embedded syntax thanks to the quotes. Moreover, at
least in my version of Joy which will support partial evaluation, the
mylang_call function will get executed at compile time since all its
inputs are available; so there is no additional runtime cost.
> > Why not? You don't even have to use the list operators if you don't want
> > to.
>
> Yes, but can one then *implement* some list-processing program without using
> a built-in notion of lists? In Smalltalk I would say yes. In Joy, I think
> the answer is no.
But Smalltalk has a built-in notion of objects which are at least as
complex as lists so thats not a fair comparison. In any language you
need some kind of association primitive. For example pairs, pointers,
closures, lists or objects. Moreover, once you have any one of these as
a primitive, you then have a basis for constructing any other kind of
aggregate type.
Having said that, I do believe that Joy implements too much at the
primitive level (lists, sets, strings, etc) though. In my Joy-like
language, the fundamental association primitive is the dynamic function
(aka updatable, variable or mutable functions, a notion from Abstract
State Machine
theory - see
http://www.eecs.umich.edu/gasm and in particular take a
look at Martin Odersky's paper "Programming with variable functions" at
http://www.eecs.umich.edu/gasm/papers.html#varfun).
Joy already has functions ofcourse and as such there is already a way of
doing association: from inputs to outputs (ie. a function is a map). The
catch is that the association is static so therefore you can't build
aggregates incrementally. A dynamic function solves this by allowing
updates at points in its domain (ie. a mutable map). In fact, not only
does this solve the association problem, but it provides an elegant way
to introduce stateful computation into a functional language (there is
already a derivative of Haskell that does this - see
http://www.uni-ulm.de/~s_jschmi/AsmGofer).
> >>Since "meta" in this context means "unusual" or
> >>"atypical" (often with
> >>circularity as the triggering criterion), is it "a good thing" for a
> >>language to rely on metaprogramming for the simplest of tasks?
> >
> > "meta" has never, to my knowledge, meant that. "meta" means "above" or
> > "beyond". When you metaprogram, you're writing programs which manipulate
> > and create other programs.
>
> Actually, the boundary of metaprogramming is very fuzzy. Metaprogramming
> can mean writing programs that (1) create programs, (2) look at other
> programs as data, (3) look at types as data, (4) look at variables as
> objects, (5) look at running processes and coroutines as data, (6) allow
> extension of base syntax via macros, (7) provide tools to reason about
> programs.
>
> You may disagree that some of these uses of the term are truly
> metaprogramming, but I'm sure some of them take you a while to classify.
> That's an indication of a fuzzy boundary. In your description of
> metaprogramming as "...writing programswhich manipulate...other programs",
> the circularity I mentioned is obvious, but sometimes it's more subtle. In
> essence every compiler, interpreter, and even IDE is a metaprogram.
I agree, therefore metaprogramming hardly qualifies as "unusual". The
fact that Joy supports it so transparently is one of the things that
attracts me to it.
--
Louis.