Time to push for a macros facility for Java 8/9/10? B Smith-Mannschott wrote: > 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 <[email protected]> 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 > > >
-- Weiqi Gao [email protected] http://www.weiqigao.com/blog/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
