The whole Lombok discussion has been fascinating. I really like it and
I think it's a clever hack. The discussion of how it works (by
rewriting java parse trees) has given people lots of ideas about how
this idea could be taken farther. But...
Any such discussion of syntax rewriting, and extending programming
languages, can not be complete without a Lisp hacker piping up to say:
Kids these days think they're so brilliant! We were doing this before
their parents were in diapers!
Now, I'm not, as it happens, a grizzled Lisp hacker, but I'll pretend
for your sake. ;-)
On Thu, Sep 10, 2009 at 16:49, Joshua Marinacci <jos...@marinacci.org> wrote:
> I suspect you are right. I've asked this question of many people and
> gotten a variety of reasons why it won't work. They reasons are always
> valid, but they always boil down to the same thing: compatibility
> with existing systems. If we could start over fresh *for everything*,
> then I think a AST based language would quite well, and enable lots of
> very interesting things. I've changed the subject line since this is
> really getting off topic now. My goal is to just think meta for a
> second.
>
> If we could design a language, and all of it's tools, from scratch
> today; then how would we do things differently?
>
> == Proposal ==
>
> Consider a language that is defined not in terms of tokens but in
> terms of it's abstract syntax tree (I'm not a compiler guy so I hope
> I'm using the right terms here). Instead of saying:
>
> conditional is defined by 'if' + '(' + mathematical expression + ')'
> plus optional '{' then a clause etc.
>
> what if it was defined as:
>
> conditional is defined by a boolean expression followed by two blocks
>
> The details such as the 'if' keyword, requiring braces, using
> parenthesis, etc. would all be up to the individual developer (or at
> least defined by their tools) rather than defined by the language.
> Some sort of neutral binary or XML format would be the true storage
> mechanism and everything else we think of as "the language" would be
> defined at a higher level on a per developer basis. The neutral
> format would be semantically equivalent to the code that the developer
> sees on screen, but specific entirely to them.
There's a 50-year-old language family of languages that does much of
this: Lisp. It's not quite what you are proposing later in your
message, but consider:
- A Lisp program is just the written form of a data structure.
- The semantics of the language are defined not in terms of what the
syntax means, but in terms of what a particular arrangement of those
data structures means.
- Because of the close correspondence between the written syntax and
resulting data structure (parse tree), it's easy to think about and
write syntax-transforming macros.
- This means you can do more than just write libraries: you can extend
the language and compiler itself.
Here, a nano-tutorial (in Clojure, a Lisp dialect that runs on the JVM
and interoperates with Java):
(1 2 3) ;;; this is a list of three numbers (think "linked list")
[a b c] ;;; this is a vector (think "array") of three symbols. symbols
are basically names for things
(defn add [a b] (+ a b))
This is a list containing two symbols: defn and add followed by a
vector containing the symbols a and b and ending with a list
containing three symbols + a b.
That's the data as understood by the clojure Reader (think parser),
but to Clojure, this data is a program:
defn: Is a convenience for defining named functions. It is the name of
a macro. Macros run at compile time. defn runs and produces this:
(def add (fn [a b] (+ a b))
Which the compiler then works on.
def is a built-in form for defining a variable. The first symbol
following def is the name of the variable: add. The value of the
variable is the next expression:
fn is a built-in form for defining a function. fn expects a vector of
symbols. These name the arguments of the function. They are named a
and b.
The body of the function is the list (+ a b). When the compiler sees a
list like this, it takes it as function application: the function +
(the addition operator) is applied to the values of a and b given by
the caller of the function.
Now you can type
(add 1 2) ;;; and clojure will produce the answer: 3
http://clojure.org
// Ben
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
