Well, every closure proposal, including BGGA, are written so that a
prototype can be made (or in the case of BGGA, exists!) that runs on a
plain jane vanilla JVM 1.6. Almost all of the heavy lifting BGGA does
can technically be represented in vanilla java source, though it'll be
unwieldy, ugly, and a lot of boilerplate. However, I imagine such
literalesque plugins are capable of producing bytecode directly.
On Sep 10, 6:12 pm, Joshua Marinacci <jos...@marinacci.org> wrote:
> On Sep 10, 2009, at 8:15 AM, Reinier Zwitserloot wrote:
>
> > In an AST based editing environment, this problem goes away. At write
> > time you must of course have the plugin available to you, at which
>
> Not necessarily. If the AST spec was written correctly you could have
> some sort of extensible block system (plugins, essentially). If you
> are writing a regex block then AST would contain some encoding of the
> regex along with some metadata about the plugin that created it. This
> metadata could include a URL to download the plugin so that it works
> when you are in another IDE. It would also contain some sort of
> compilable representation, meaning you could still compile the code
> even if you don't have that particular plugin available to you. You
> just wouldn't be able to edit it. Photoshop files do this. All text
> layers are vectors but keep rasterized metadata. If you don't have
> the font that the layer was created with then you can't edit it, but
> you can still view it and composite it with other layers. It degrades
> gracefully. Now imagine if Photoshop not only told you the font you
> were missing, but offered to download it as well. AWESOM-O!
>
> > lit:Patt(ctrl+space to autocomplete it to java.util.regexp.Pattern)
> > and then you type a regular expression; the job of marking the end is
> > trivial where in raw character typing mode it's almost unsolvable.
>
> > You can take this same idea even further and add support for macros:
> > foreach could have been implemented as a macro, but this time, the AST
> > node carries its origin with it. This way, I can switch my editor at
> > will, and type/read either in macro syntax, or in the desugared form.
> > Making the IDE extensively pluggable would be so much easier. There
> > would be no closure debate at all - those who like em use a macro
> > plugin that renders closures as Anonymous Inner Class constructs.
>
> I didn't follow the closure debate to closely, but I'm not sure this
> is true. Aren't there things which closures can do (semantically) that
> anonymous inner classes can't? Was it just syntax sugar?
>
> > Because whitespace, import statements, and other ambiguities melt
> > away, in certain ways the canonical textual representation (which ISNT
> > how you're supposed to edit things and would be extremely unwieldy) is
>
> Yes. It would probably be XML just to make life easier for tools (and
> to allow by hand editing in the rare cases when you must fix
> something) but 99% of the time the AST on disk representation is
> simply a black box. You must always use the tools.
>
> > The biggest issue remains that so much of the entirety of the
> > development ecosystem is built around the notion that source lives as
> > raw streams of characters. There would definitely have to be a human-
> > readable canonical representation so you can interop with such tools
> > until they also see the light. There may also be an interesting lesson
> > in how many typical geeks doing professional writing use something
> > like HTML or LaTeX, writing it essentially 'raw', instead of using
> > open office or word. I think there are different reasons for that, but
> > it is nevertheless interesting to see that shiny, graphical tools are
> > losing to raw char streams in some areas.
>
> Yep. Backwards compatibility is a bitch. :)
>
> - J
>
>
>
>
>
> > To the galaxy, and beyond!
>
> > On Sep 10, 4:49 pm, 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.
>
> >> == Advantages ==
>
> >> There are huge advantages to this approach.
>
> >> * tabs vs spaces goes away. You see whatever you wish to see, and it
> >> doesn't affect other developers.
>
> >> * comments could be nicely formatted rich text, including lists,
> >> tables, and diagrams.
>
> >> * Line numbers in stacktraces: Consider the work required to turn
> >> the
> >> location of the bytecode exception back into a line and column
> >> number.
> >> It would be easier to map back to the AST. The compiler / runtime
> >> would emit some sort of AST marker which the IDE would convert back
> >> to
> >> it's visualization of your line / column (assuming you are still
> >> editing in terms of lines and columns). Most likely it would
> >> highlight
> >> the exact problematic branch of the tree, not just a line and column.
>
> >> * refactoring becomes far easier, and could enable far more
> >> interesting refactoring changes than the simple ones we have to day.
>
> >> * since we are using a binary / xml blob for the real storage, we
> >> wouldn't have to worry about files and filenames anymore. What would
> >> matter is modules and compilation units. The actual files it's stored
> >> in become irrelevant.
>
> >> * code analysis: tools which analyze your code should be able to do a
> >> better job when they work at the 'meaning' level rather than the
> >> 'syntax' level.
>
> >> * code visualizers: It should be trivial to build things which draw
> >> UML diagrams of your beans, or show nested structures with darkening
> >> backgrounds. Almost all of the cool things you want to do boil down
> >> to
> >> visualizing a branch of the tree, making possible all sorts of very
> >> interesting visualizations.
>
> >> * many syntax errors go away: since the IDE knows what the valid tree
> >> should look like, it can prevent anything which would create an
> >> invalid tree. rather than scanning the whole file 20 times a second
> >> it
> >> can look at what you've done in the last few seconds that just made
> >> the tree invalid and isolate the error to that. the result is more
> >> accurate error reporting, even before you get to the compiler.
>
> >> * never ever worry about some other developer f**king up your
> >> indentation, line breaks, curly brace scheme, etc.
>
> >> * the potential to use different keywords, line terminators, and
> >> other
> >> syntax of your choosing and have it be completely isolated to your
> >> environment. No other developer is affected.
>
> >> == Cons ==
>
> >> * You've got to use an IDE. Yes, no more blindly editing text files
> >> with vi and emacs. Sorry. It's the 21st century. I edit images in
> >> Photoshop, not the command line. I will now edit programs in a
> >> programming tool.
>
> >> * Youv'e got to write IDE support for this. Building this new
> >> language
> >> requires also building an IDE plugin that understands it.
>
> >> * Text diff tools (and therefore source control systems) would have
> >> to
> >> be updated to understand this binary / xml format. In theory the
> >> diffs
> >> should be better since you'd have a better idea of what semantically
> >> changed (tree diffing, basically), but someone's still go to write
> >> the
> >> tools to do it.
>
> >> * Two developers working on their own machines would see the code
> >> views they expect. One developer trying to help a second developer on
> >> his machine would see a view completely unfamiliar to what they
> >> expect.
>
> >> * Web based code review tools would show a normalized view that is
> >> unfamiliar to all developers, or else code review tools would have to
> >> be a new module inside the IDE to pick up the prefs of the developer
> >> doing the reviewing.
>
> >> Crazy idea, but it's the 21st century. We can handle it. Now if
> >> you'll excuse me I've got to go take my flying car in for repairs
> >> before my weekend trip to Mars.
>
> >> - j
>
> >> On Sep 10, 2009, at 1:28 AM, Peter Becker wrote:
>
> >>> And it alls starts with the language specs still being written at
> >>> the
> >>> abstraction level of a concrete syntax. Chapter 1: Tokenization.
>
> >>> Peter
>
> >>> Joshua Marinacci wrote:
> >>>> RANT!
>
> >>>> Why, in the 21st century, are we still writing code with ascii
> >>>> symbols
> >>>> in text editors, and worried about the exact indentation and
> >>>> whether
> >>>> to use tabs, spaces, etc?!!
>
> >>>> Since the IDE knows the structure of our code, why aren't we just
> >>>> sharing ASTs directly, letting your IDE format it to your desire,
> >>>> and
> >>>> only sharing the underlying AST with your fellow developers.
> >>>> Encoding,
> >>>> spaces, braces, etc. is a detail that only matters when presented
> >>>> to
> >>>> the human.
>
> >>>> What we do today is like editing image files from the commandline!
>
> >>>> On Sep 9,
>
> ...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
