On Fri, Sep 11, 2009 at 14:24, Vince O'Sullivan wrote:
>
>
>
> On Sep 11, 11:11 am, B Smith-Mannschott wrote:
>> Kids these days think they're so brilliant! We were doing this before
>> their parents were in diapers!
>>
>> - A decent lisp-aware editor (e.g. Emacs)
Yea. Emacs is not for everyone
On Sep 11, 11:11 am, B Smith-Mannschott wrote:
> Kids these days think they're so brilliant! We were doing this before
> their parents were in diapers!
>
> - A decent lisp-aware editor (e.g. Emacs)
I think you just summed up the Lisp community and alienated everyone
born after 1950 in one go!
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 ide
Speaking of AST based editors/languages, has anyone here used Jetbrains MPS
at all? The whole editor is AST based, with extendable, composable
languages.
I keep meaning to give it a bash but never find the time.
--
Pull me down under...
On Fri, Sep 11, 2009 at 10:08 PM, B Smith-Mannschott
wro
On Fri, Sep 11, 2009 at 12:08, B Smith-Mannschott wrote:
> - 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.
>
> -
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 extendin
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, an
Joshua Marinacci wrote:
> Still, I think one day we will move towards this. I can't imagine the
> computer in the Starship Enterprise was coded in text files.
>
Yes, I mean writing has not been around that long compared to
computers. I am sure its just a passing fad.
Alan ;-) ;-) ;-)
--
that's an interesting article. I'm glad to hear I'm not the only one
who's thought of this. That shows it's not crazy, just very hard to do
(for compatibility reasons as he states).
Still, I think one day we will move towards this. I can't imagine the
computer in the Starship Enterprise wa
Thanks Ben, had not heard of this, apparently called "projectional
editing":
http://www.martinfowler.com/bliki/ProjectionalEditing.html
The videos does indeed resemble Stephen Hawking navigating his voice
synthesis software but I'm sure that could be done better than that.
It looks and feels as
> I'm not sure why you'd have to use your mouse. Everything I'm
> imagining would be done in the IDE with keystrokes.
Because the semantic differences achievable by changing just a few
characters is so vast that you will have a hard time coming up with
shortcuts for every one of them. Ultimatel
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 bl
yep. Essentially these are all things which IDEs and addon tools are
trying to do today, but do imperfectly because they are operating on
an array of ascii text (or unicode if it's Java). As always, getting
from here to there is the hard part. :)
On Sep 10, 2009, at 8:42 AM, Casper Bang wr
2009/9/11 Joshua Marinacci
> On Sep 10, 2009, at 8:48 AM, Ben Schulz wrote:
>
> >
> >>> Youv'e got to write IDE support for this. Building this new language
> >>> requires also building an IDE plugin that understands it".
> >>
> >> And that probably explains why it hasn't been done before, a chic
On Sep 10, 2009, at 8:48 AM, Ben Schulz wrote:
>
>>> Youv'e got to write IDE support for this. Building this new language
>>> requires also building an IDE plugin that understands it".
>>
>> And that probably explains why it hasn't been done before, a chicken
>> and egg problem.
>
> Ah, but it h
> > Youv'e got to write IDE support for this. Building this new language
> > requires also building an IDE plugin that understands it".
>
> And that probably explains why it hasn't been done before, a chicken
> and egg problem.
Ah, but it has been done before.
http://lambda-the-ultimate.org/node
It really is just another example of extending the compiler into
"userspace", much like FindBugs and Lombok. Not only should it provide
better error messages, refactoring suggestions and optimizations but
it would index also compile much faster - the compiler would be handed
an AST that can be ass
> 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".
Microsoft already "pioneered" that, a VBA macro in Danish would use
"Hvis" rather then "If". ;)
> Youv'e got
In another thread, the idea of compiler-plugin based literals was
floated. I observed that unless that plugin is available at tokenize
time (which means, before resolving typing info, so that's annoying,
as you'd want to use that to figure out which plugin is responsible),
the compiler can't conti
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
20 matches
Mail list logo
