Home » Modeling » TMF (Xtext) » Language Libraries
| Language Libraries [message #42407] |
Wed, 29 April 2009 07:29  |
Eclipse User |
|
|
|
I've seen somewhere that language libraries could be a post galileo xText
feature. I'm very interested. I'd like to know if you refer to modular
grammars and, if this is the case, if this grammar's could be loaded by
the generated editor
|
|
| |
| Re: Language Libraries [message #42575 is a reply to message #42454] |
Thu, 30 April 2009 12:25  |
| Eclipse User |
|
|
|
Sven Efftinge wrote:
> Xtext already supports reusing one library grammar per grammar. Xtext is
> for instance shipped with a library grammar containing the typical
> terminal rules (identifier, integer and string literal, whitespace,
> multi line and single line comments).
> We're thinking about allowing reuse of multiple grammars from one
> grammar post galileo.
means this that it will be possible to define extensible grammars?. (I'm
thinking about appending and extending grammar's productions, beyond
typical terminal rules)
I think this feature could lead xText to the embedded DSL's world.
Language libraries could be seen as extensions (plugins) of a host
language that would act as a kind of language framework.
Perhaps this possibility doesn't contribute to the xText's goals. If this
is the case you could be bored before the end of this post. Else, my so
bad expressed second question, could be interesting
> What exactly do you mean by loading grammar by generated editor?
Let's suppose that a host language exists (with a xText generated eclipse
plugin for it). Let's suppose someone needs an extension for the language
and he or she do it as a xText language library
The question is if he or she will need to apply the extension using xText
(and regenerating the eclipse plugin) or, in a more dynamic way, using
only the capabilities of the xtext generated plugin for the host language.
Obviously this capabilities would need to be extended in order to allow
incremental/modular parsing (with packrat parsers is possible) and,
perhaps, to contribute the workbench with a generated custom type of
project for the host language (besides the generated host language editor).
Well, I think I know the answer. If there are an answer. But, given the
presumably early stage of this feature... I think it's the moment for ideas
Thank's for your first response. This forum is the most friendly i've
found. I hope you will can help me to make my complex things possible. ;)
If you think this is not the place for this type of discussion, feel free
to make me know it at hiebra@hotmail.com (here, of course, you are already
free to do it)
Santiago
|
|
|
| Re: Language Libraries [message #42605 is a reply to message #42575] |
Sat, 02 May 2009 05:06 |
| Eclipse User |
|
|
|
Hi Santiago,
comments inline ...
Santiago schrieb:
>> Xtext already supports reusing one library grammar per grammar. Xtext
>> is for instance shipped with a library grammar containing the typical
>> terminal rules (identifier, integer and string literal, whitespace,
>> multi line and single line comments).
>> We're thinking about allowing reuse of multiple grammars from one
>> grammar post galileo.
>
> means this that it will be possible to define extensible grammars?. (I'm
> thinking about appending and extending grammar's productions, beyond
> typical terminal rules)
Yes, exactly.
>
> I think this feature could lead xText to the embedded DSL's world.
> Language libraries could be seen as extensions (plugins) of a host
> language that would act as a kind of language framework.
We've plans to design a more complete base language in the next release,
which then can be customized / extended by users.
So not everyone has to care about expressions and type systems that much.
>
> Perhaps this possibility doesn't contribute to the xText's goals. If
> this is the case you could be bored before the end of this post. Else,
> my so bad expressed second question, could be interesting
>
>> What exactly do you mean by loading grammar by generated editor?
>
> Let's suppose that a host language exists (with a xText generated
> eclipse plugin for it). Let's suppose someone needs an extension for the
> language and he or she do it as a xText language library
>
> The question is if he or she will need to apply the extension using
> xText (and regenerating the eclipse plugin) or, in a more dynamic way,
> using only the capabilities of the xtext generated plugin for the host
> language.
>
Currently, we use code generation for a couple of aspects (most
important the parser), so that if you extend an exsiting grammar you
have to re-generate things for your specific sub-language.
Anyway, it's of course possible to reuse and extend components (e.g.
code completion. etc.) you've written against the host language.
> Obviously this capabilities would need to be extended in order to allow
> incremental/modular parsing (with packrat parsers is possible) and,
> perhaps, to contribute the workbench with a generated custom type of
> project for the host language (besides the generated host language editor).
>
> Well, I think I know the answer. If there are an answer. But, given the
> presumably early stage of this feature... I think it's the moment for ideas
So does my answer meet your expectations?
>
> Thank's for your first response. This forum is the most friendly i've
> found. I hope you will can help me to make my complex things possible. ;)
This is at least what strife for :-)
>
> If you think this is not the place for this type of discussion, feel
> free to make me know it at hiebra@hotmail.com (here, of course, you are
> already free to do it)
Discussing such things in the newsgroup is perfectly ok.
Cheers,
Sven
|
|
|
| Re: Language Libraries [message #42698 is a reply to message #42605] |
Mon, 04 May 2009 06:40 |
| Eclipse User |
|
|
|
Hi, Sven, thank you for your attention.
>> Let's suppose that a host language exists (with a xText generated
>> eclipse plugin for it). Let's suppose someone needs an extension for the
>> language and he or she do it as a xText language library
>>
>> The question is if he or she will need to apply the extension using
>> xText (and regenerating the eclipse plugin) or, in a more dynamic way,
>> using only the capabilities of the xtext generated plugin for the host
>> language.
>>
> Currently, we use code generation for a couple of aspects (most
> important the parser), so that if you extend an exsiting grammar you
> have to re-generate things for your specific sub-language.
Things needs to be re-generated. But this work could be done by the plugin
that owns the host language editor. The plugin could accept extensions to
the running editor.
Look at the JDT plugin. When a java library is added, the editors
behaviour is "extended" to recognize the entities of the new library. It's
only an example. I know that the extensions i'm talking about are not so
simple to code.
This idea is not only mine. Look at:
http://blog.efftinge.de/2008/09/language-feature-supporting- internal.html
:?
The algorithm for this kind of parser exists (look at
http://www.chrisseaton.com/katahdin/). The editor, I think, could be in
your hands. This is the why of my question:
do you think it would be technically possible to build a modular eclipe
editor where syntax can be extended at editing time?
in other words, are my complex things possible?
If they are... why to celebrate the link between Sven and Scarlet in plain
text?
> So does my answer meet your expectations?
It really does
Greetings from Madrid
Santiago
|
|
| |
| Re: Language Libraries [message #42854 is a reply to message #42761] |
Tue, 05 May 2009 08:17 |
| Eclipse User |
|
|
|
Hi again. I didn't like to bore you (and newsgroup readers). I'll try to
be concise enough to make this post a "final allegation candidate"
>Libraries do not change the language.
>So I'ld say that these problems are not comparable.
Sorry for my fuzzy logic. I was expressing a desire, not comparing
problems.
Libraries (object code libraries) do not change the language. But they,
usually, enclose a domain (or subdomain). This Domain has a Specific
Language Only a small subset of this language can be used to script the
library. GPLs are forced to extract a common factor for all domains. This
common factor is always a form of the function call mechanism
My desire is that a language library, with a DSL definition (and more
things), could be linked to the code library that implements that DSL,
allowing the programmer to script the library in its own language.
The code library would have two interfaces. The low level one (function
calls), allways included with the library and the high level one (DSL of
the library domain), optional.
>>do you think it would be technically possible to build a modular eclipe
>>editor where syntax can be extended at editing time?
>Technically, yes.
>But I neither think it's a low hanging fruit nor think Xtext can help you
>much with this.
If it is possible then I'd like to climb up the tree. I think it's worth it
I'm here, writing, because I think xText is the more closer tool to the
problem. You generate editors, you are going to use language libraries,
you are CPL. You are friendly :-) ...
All of them are advantages from my point of view. But from yours,
something could be added:
xText allows to define DSLs and use them for model generation. I think you
believe in modeling as a way to code generation. MDSD products obtained
with xText are linked to DSLs. My question is that, if that products are
code libraries, why not to allow library users (programmers) to use that
DSL to script the library?
From the point of view of the rest of the world, a new way to programming
could be opened.
These are my complex things. I'm happy to have them posted here and I hope
not to have been too much "off topic".
Thanks for listening
Santiago
|
|
|
| Re: Language Libraries [message #42885 is a reply to message #42854] |
Tue, 05 May 2009 08:51 |
| Eclipse User |
|
|
|
Santiago schrieb:
> Hi again. I didn't like to bore you (and newsgroup readers).
You don't have to apologize. If your posts were boring they would be
ignored automatically :-)
>
> Libraries (object code libraries) do not change the language. But they,
> usually, enclose a domain (or subdomain). This Domain has a Specific
> Language Only a small subset of this language can be used to script the
> library. GPLs are forced to extract a common factor for all domains.
> This common factor is always a form of the function call mechanism
>
> My desire is that a language library, with a DSL definition (and more
> things), could be linked to the code library that implements that DSL,
> allowing the programmer to script the library in its own language.
>
> The code library would have two interfaces. The low level one (function
> calls), allways included with the library and the high level one (DSL of
> the library domain), optional.
>
This sounds pretty much like the stuff from the blog post you've
referenced earlier. ;-)
> All of them are advantages from my point of view. But from yours,
> something could be added:
> xText allows to define DSLs and use them for model generation. I think
> you believe in modeling as a way to code generation.
Compilers and interpreters both have their pros and cons.
It's perfectly ok to use languages designed with Xtext in interpreters.
We don't have a special preference for code generators.
In Xtext we use both, generation as well as runtime interpretation.
> My question is that, if that
> products are code libraries, why not to allow library users
> (programmers) to use that DSL to script the library?
What you are looking for (and I like the idea pretty much) is having
*one* language, where it is possible to come up with domain-specific
syntax for your libraries.
If you're going to start working on something like this we'll of course
be happy to support you implementing it with Xtext.
However, Xtext itself *currently* has a slightly different focus.
Cheers,
Sven
|
|
| | |
| Re: Language Libraries [message #43081 is a reply to message #43062] |
Wed, 06 May 2009 10:02 |
| Eclipse User |
|
|
|
Sven Efftinge wrote:
> Santiago schrieb:
>> Not exactly. I don't want *one language*. I want a product that allows
>> the definition of DSLs and the composition of DSL statements and
>> expressions in the context of an existing GPL (like java) in order to
>> script existing libraries (like sunpkcs11.jar). And I want it with the
>> apropiate IDE support.
>>
>> Perhaps this is not necesary but, here is the model:
>>
>> 1 One library have zero or one DSL
>> 2 One DSL can be used to script one library
>> 3 One DSL is embeddable in one GPL
>> 4 One GPL can embed zero or more DSLs [restriction: The DSL's need to be
>> embeddable (point 3) in the GPL]
>>
>> The DSL code should generate library scripting GPL statements, that
>> should be hidden to the IDE user.
> I ment the same, basically.
The difference is not in technical issues. Only in practical ones:
Writen code has great value. The product I'm thinking about is interesting
in practice because it would be an "added value" to the existing code base.
> I'm unfortunately a bit short of resources.
> I can only provide support if you face any issues with Xtext or need
> someone to reflect your ideas.
My ideas are reflected. Thank you. And these aren't *currently* xText
issues. I hope this dialog is going to be usefull in some way. Remember:
I'm still interested (I think this product will be done in the next
decades). If you change your opinion please make me know it.
Best regards
Santiago
|
|
|
Goto Forum:
Current Time: Tue Jul 22 12:54:14 EDT 2025
Powered by FUDForum. Page generated in 0.08610 seconds |
Home