RE: BeanShell Dialects: proposal for future syntax extension mechanism...

I fully support this proposal.  I believe the syntax plugin interface should
include detailed error reporting methods (line and position, etc.)  The
backend should probably be flexible allowing for emission of BeanShell
snippets, Java source, or bytecode.

Cheers,
Dan

> -----Original Message-----
> From: beanshell-developers-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org [mailto:beanshell-
> developers-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of Patrick Niemeyer
> Sent: Tuesday, February 01, 2005 5:23 PM
> To: BeanShell Developers
> Subject: [Beanshell-dev] BeanShell Dialects: proposal for future syntax
> extension mechanism...
> 
> 
> Since there has been some talk on the list recently of wishlist items
> and new syntax, I would like to throw out a proposal for discussion.
> This is just thinking ahead a bit.  Finalizing the current release and
> addressing known bugs will have top priority before we add any new
> features.  But I'd like to get some early feedback on this idea.
> 
> What I would like to propose is an extensible mechanism for the
> BeanShell language that allows specialized "domain syntax" to be added
> in a way that is aesthetically appealing, Java-like, unambiguous with
> respect to reasonable developments in the Java language, and has almost
> no effect on the language when not used. The syntax mechanism should be
> pluggable, allowing developers to easily import their own syntax
> designs into the language in a way that encourages creativity, but
> still provides tight enough integration with the core language so as to
> be used productively and fluidly.
> 
> Here is a brief write-up:
> 
>     http://beanshell.org/BeanShellDialects.html
> 
> The basic proposal here is to extend the notion of a method invocation
> in Java by allowing one or more arguments to have a "free-form", or
> non-Java syntax. These "domain syntax methods" or "dialects" would be
> responsible for more or less arbitrary parsing of their arguments but
> with certain required semantics that provide for tight integration with
> the surrounding BeanShell script environment. Domain methods would
> extend the concept of the BeanShell eval() method, both providing a
> traditional return value and producing side effects directly in the
> caller's scope. The existing eval() method would become a defacto,
> reflexive, BeanShell dialect.
> 
> Check it out and let me know what you think, on or off the list.   Feel
> free to rip it to shreds if you don't like it.
> 
> 
> thanks,
> Pat
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Beanshell-developers mailing list
> Beanshell-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/beanshell-developers



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl