You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Claus Ibsen <cl...@gmail.com> on 2011/08/29 10:18:29 UTC
[HEADS UP] - A prototype of an improved Simple language for Apache Camel
Hi
The current Simple language in camel-core has reached its potential in
terms of maintenance and how easy it would be, for example to add new
functions and operators. Likewise the current error reporting is not
precise to point out where in the expression String the problem is.
The implementation is using regular expressions, and that is one of
the key problems. I think we have grown to the limit how it is to
maintain.
So I have experimented this weekend to build a prototype based on the
principle of a recursive descent parser
http://en.wikipedia.org/wiki/Recursive_descent_parser
I at first looked into using a parser framework such as JavaCC and
ANTLR. The former would be able to parse the input, but building the
AST nodes would require to use its tree compiler, which was not maven
exposed. Likewise JavaCC is not really maintained anymore. People on
stackoverflow recommended ANTLR. It has more bells ans whistles, but
as far as I could see ANTLR requires JAR files in the runtime.
And frankly I just wanted a fairly simple code, that anybody, would be
able to look into and help with.
So I cracked up some prototype code based on the principle from that
wikipedia article above.
So far I got a working prototype that is much better at parsing and
reporting exactly where the problem is.
For example suppose you do a predicate in a content based router, such as:
<simple>${header.high} = true</simple>
Notice how I have mistyped the == operator, as there is only one = sign.
In the old code, the reg exp parser would not catch this problem, and
the predicate would be evaluated to true, at runtime. There is two
reasons for that. The old parser is not good at detecting errors and
being able to pin point the problem. The grammer is not really defined
that well, as its based on a somewhat complicated regular expression.
The 2nd issues is the old parser would evaluate both predicates and
expressions, as expressions first, and then convert the expression to
a predicate. So in that given example above, it would be rendered as
"someHeaderValue = true" as an expression. And when converted to a
predicate it would be true, as the expression is not empty.
The new parser in the prototype is improved as it
- runs in two modes: predicate or expression
- has a grammer and is able to parse the input, and report precisely
where the problem is.
So for example what you see now is
org.apache.camel.language.simple.SimpleIllegalSyntaxException:
unexpected character symbol at location 15
${header.high} = true
*
And then there is a * sign below where the problem is. Now if you
would show above text using monospaced font, you would see the star
below the = sign.
The exception message can be improved even more, as we could say
something about an unknown operator, etc.
Likewise I decided to let the new simple language be more restrictive
in terms of function placeholders. I decided that you now must always
use ${ } placeholders, as it makes the parsing easier, as well as for
end users, there is no confusion.
header.high == true
Should be written as
${header.high} == true
The prototype is currently in my github at
https://github.com/davsclaus/camel-simple2
There is still some work to do
- implement the remainder binary operators (basically copy code from
old and adjust a little bit)
- add support for "and" and "or" grouping operators, I am inclined to
rename them to "&&" and "||" which is the operators you would use in
Java code etc.
- add support for "++" and "--" unary operators, so people for example
can use that to increment a counter in XML DSL without using any java
code
- possible add support for ( ) groups so you can define precedences
- possible add support for math operators if they would make sense
- refine error messages just a tad
- the parser is currently not thread safe, so we may want to refine
this (it stores some state during parsing)
- after parsing there is a bit logic to prepare the AST before we turn
it into Camel expression/predicates. Especially due to blocks and
binary operators. We may relax this as the binary operators could
potential "whirl through" the whitespace noise and be able to detect
its right and left hand side expressions. Currently I am removing any
in between noise, so the right/left hand side is exactly next-to the
operator.
So if anyone wanna help out, or have ideas for improvements, or have
any grief with the old simple language, that we can fix in the new
code, then fell free to help out.
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: [HEADS UP] - A prototype of an improved Simple language for
Apache Camel
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Aug 29, 2011 at 10:18 AM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> The current Simple language in camel-core has reached its potential in
> terms of maintenance and how easy it would be, for example to add new
> functions and operators. Likewise the current error reporting is not
> precise to point out where in the expression String the problem is.
>
> The implementation is using regular expressions, and that is one of
> the key problems. I think we have grown to the limit how it is to
> maintain.
>
> So I have experimented this weekend to build a prototype based on the
> principle of a recursive descent parser
> http://en.wikipedia.org/wiki/Recursive_descent_parser
>
> I at first looked into using a parser framework such as JavaCC and
> ANTLR. The former would be able to parse the input, but building the
> AST nodes would require to use its tree compiler, which was not maven
> exposed. Likewise JavaCC is not really maintained anymore. People on
> stackoverflow recommended ANTLR. It has more bells ans whistles, but
> as far as I could see ANTLR requires JAR files in the runtime.
>
> And frankly I just wanted a fairly simple code, that anybody, would be
> able to look into and help with.
>
> So I cracked up some prototype code based on the principle from that
> wikipedia article above.
>
> So far I got a working prototype that is much better at parsing and
> reporting exactly where the problem is.
> For example suppose you do a predicate in a content based router, such as:
>
> <simple>${header.high} = true</simple>
>
> Notice how I have mistyped the == operator, as there is only one = sign.
>
> In the old code, the reg exp parser would not catch this problem, and
> the predicate would be evaluated to true, at runtime. There is two
> reasons for that. The old parser is not good at detecting errors and
> being able to pin point the problem. The grammer is not really defined
> that well, as its based on a somewhat complicated regular expression.
> The 2nd issues is the old parser would evaluate both predicates and
> expressions, as expressions first, and then convert the expression to
> a predicate. So in that given example above, it would be rendered as
> "someHeaderValue = true" as an expression. And when converted to a
> predicate it would be true, as the expression is not empty.
>
> The new parser in the prototype is improved as it
> - runs in two modes: predicate or expression
> - has a grammer and is able to parse the input, and report precisely
> where the problem is.
>
> So for example what you see now is
>
> org.apache.camel.language.simple.SimpleIllegalSyntaxException:
> unexpected character symbol at location 15
> ${header.high} = true
> *
>
> And then there is a * sign below where the problem is. Now if you
> would show above text using monospaced font, you would see the star
> below the = sign.
>
> The exception message can be improved even more, as we could say
> something about an unknown operator, etc.
>
> Likewise I decided to let the new simple language be more restrictive
> in terms of function placeholders. I decided that you now must always
> use ${ } placeholders, as it makes the parsing easier, as well as for
> end users, there is no confusion.
>
> header.high == true
> Should be written as
> ${header.high} == true
>
>
> The prototype is currently in my github at
> https://github.com/davsclaus/camel-simple2
>
>
> There is still some work to do
> - implement the remainder binary operators (basically copy code from
> old and adjust a little bit)
All the existing binary operators is now implemented and unit test
from camel-core passes.
> - add support for "and" and "or" grouping operators, I am inclined to
> rename them to "&&" and "||" which is the operators you would use in
The logical operators and|or have been added, but named && and || to
be more inline with other languages.
> Java code etc.
> - add support for "++" and "--" unary operators, so people for example
> can use that to increment a counter in XML DSL without using any java
> code
Unary operators ++ and -- have been implemented. You can also use them
in expressions so you can auto inc a header counter etc.
<setHeader headerName="counter">
<simple>${header.counter}++</simple>
</setHeader>
Which have been requested in the community.
> - possible add support for ( ) groups so you can define precedences
> - possible add support for math operators if they would make sense
> - refine error messages just a tad
> - the parser is currently not thread safe, so we may want to refine
> this (it stores some state during parsing)
> - after parsing there is a bit logic to prepare the AST before we turn
> it into Camel expression/predicates. Especially due to blocks and
> binary operators. We may relax this as the binary operators could
> potential "whirl through" the whitespace noise and be able to detect
> its right and left hand side expressions. Currently I am removing any
> in between noise, so the right/left hand side is exactly next-to the
> operator.
>
>
> So if anyone wanna help out, or have ideas for improvements, or have
> any grief with the old simple language, that we can fix in the new
> code, then fell free to help out.
>
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: [HEADS UP] - A prototype of an improved Simple language for Apache Camel
Posted by Zbarcea Hadrian <hz...@gmail.com>.
The principle of not having *unnecessary* extra dependencies is good. However this looks to me more like reinventing the wheel. If we write all the code in Camel we won't have dependencies, but we get a bloated code base, hard to maintain and taking forever to test. Reusing code (and having dependencies) is a smarter path. I like the xtext idea and that can be externalized, as it was tried by Oisin, iiric, at camel-extra a while ago.
My $0.02,
Hadrian
On Aug 29, 2011, at 5:14 AM, Christian Schneider wrote:
> Hi Claus,
>
> the parser looks quite good as far as I looked into it. In any case much better than regex. Before we replace the old parser we should also think about tooling though. Some longer time ago I thought about using Xtext for the camel DSL and also the languages. The advantage would be that it is quite easy to build real good Editor for the IDE. I guess with the aproach you followed this is not so easy. Of ocurse the initial effort of Xtext would be a lot higher but perhaps it can pay off in the long run.
>
> Christian
>
>
>
> Am 29.08.2011 10:18, schrieb Claus Ibsen:
>> Hi
>>
>> The current Simple language in camel-core has reached its potential in
>> terms of maintenance and how easy it would be, for example to add new
>> functions and operators. Likewise the current error reporting is not
>> precise to point out where in the expression String the problem is.
>>
>> The implementation is using regular expressions, and that is one of
>> the key problems. I think we have grown to the limit how it is to
>> maintain.
>>
>> So I have experimented this weekend to build a prototype based on the
>> principle of a recursive descent parser
>> http://en.wikipedia.org/wiki/Recursive_descent_parser
>>
>> I at first looked into using a parser framework such as JavaCC and
>> ANTLR. The former would be able to parse the input, but building the
>> AST nodes would require to use its tree compiler, which was not maven
>> exposed. Likewise JavaCC is not really maintained anymore. People on
>> stackoverflow recommended ANTLR. It has more bells ans whistles, but
>> as far as I could see ANTLR requires JAR files in the runtime.
>>
>> And frankly I just wanted a fairly simple code, that anybody, would be
>> able to look into and help with.
>>
>> So I cracked up some prototype code based on the principle from that
>> wikipedia article above.
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
Re: [HEADS UP] - A prototype of an improved Simple language for
Apache Camel
Posted by Taariq Levack <ta...@gmail.com>.
Well spotted, I was gonna mention this problem once I understood it better,
a couple of tests I brought over from the main patch were failing.
All tests pass after the update, so it's backwards compatible alright.
Taariq
On Sun, Sep 4, 2011 at 10:10 AM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> Just an update on the status.
>
> I discovered an issue in the scala DSL, which I managed to fix
> yesterday. The problem was the scala DSL would cause all languages to
> be evaluated as Expression, and then converted to Predicate if
> applicable. This was wrong, as the DSL indicate whether it should be a
> Predicate or Expression. This level of indirection would cause an
> issue as first being an Expression and then a Predicate. And also
> cause a slight difference between Scala DSL and Java DSL etc.
>
> The problem was identified due the improved Simple language prototype
> as it parse the input depending on its a Expression or Predicate. The
> latter has all the operators and whatnot. Where as the former is the
> "template style" which was the origin roots of the Simple language - A
> very simple expression language for dynamic templates, eg to say
> "Hello ${body} how are you?".
>
> The old simple language did support a style by which you could be lazy
> and omit the ${ } tokens, and just indicate "body" or "header.foo".
> The new simple language prefers to use "${body}" and "${header.foo}"
> as its consistent and also stands out to the user, that this is a
> function, and not plain text. However the old style is supported using
> a "SimpleBackwardsCompatibleParser" which have been marked as
> @deprecated, and to be removed in Camel 3.0.
>
> I have been running with the simple prototype for a week on my laptop,
> and have identified some minor mistakes in the Camel source code due
> the old simple language. I have corrected them.
>
> So it would be a matter of time before the prototype is ready as a
> donation to Apache and to be included in Camel 2.9.
>
> the prototype is located here
> https://github.com/davsclaus/camel-simple2
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>
Re: [HEADS UP] - A prototype of an improved Simple language for
Apache Camel
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Just an update on the status.
I discovered an issue in the scala DSL, which I managed to fix
yesterday. The problem was the scala DSL would cause all languages to
be evaluated as Expression, and then converted to Predicate if
applicable. This was wrong, as the DSL indicate whether it should be a
Predicate or Expression. This level of indirection would cause an
issue as first being an Expression and then a Predicate. And also
cause a slight difference between Scala DSL and Java DSL etc.
The problem was identified due the improved Simple language prototype
as it parse the input depending on its a Expression or Predicate. The
latter has all the operators and whatnot. Where as the former is the
"template style" which was the origin roots of the Simple language - A
very simple expression language for dynamic templates, eg to say
"Hello ${body} how are you?".
The old simple language did support a style by which you could be lazy
and omit the ${ } tokens, and just indicate "body" or "header.foo".
The new simple language prefers to use "${body}" and "${header.foo}"
as its consistent and also stands out to the user, that this is a
function, and not plain text. However the old style is supported using
a "SimpleBackwardsCompatibleParser" which have been marked as
@deprecated, and to be removed in Camel 3.0.
I have been running with the simple prototype for a week on my laptop,
and have identified some minor mistakes in the Camel source code due
the old simple language. I have corrected them.
So it would be a matter of time before the prototype is ready as a
donation to Apache and to be included in Camel 2.9.
the prototype is located here
https://github.com/davsclaus/camel-simple2
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: [HEADS UP] - A prototype of an improved Simple language for
Apache Camel
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Aug 29, 2011 at 3:52 PM, Willem Jiang <wi...@gmail.com> wrote:
> It could be handy if we leverage the other lib in the other camel-module. If
> the user need the module, it will not be a burden for him to include a third
> part lib.
>
There is already other scripting languages you can use if you want a
more powerful language.
For example camel-groovy, or use camel-script so you can use JavaScript etc.
All these languages have support by IDEs
> On 8/29/11 8:19 PM, Claus Ibsen wrote:
>>
>> On Mon, Aug 29, 2011 at 11:14 AM, Christian Schneider
>> <ch...@die-schneider.net> wrote:
>>>
>>> Hi Claus,
>>>
>>> the parser looks quite good as far as I looked into it. In any case much
>>> better than regex. Before we replace the old parser we should also think
>>> about tooling though. Some longer time ago I thought about using Xtext
>>> for
>>> the camel DSL and also the languages. The advantage would be that it is
>>> quite easy to build real good Editor for the IDE. I guess with the
>>> aproach
>>> you followed this is not so easy. Of ocurse the initial effort of Xtext
>>> would be a lot higher but perhaps it can pay off in the long run.
>>>
>>> Christian
>>>
>>
>> I wanted something that was simple ;). Well in the sense that it does
>> not add any extra JARs to the runtime.
>> So if the tooling can generate plain java source code, then that would be
>> nice.
>> Also the tooling should be active maintained, so we dont end up using
>> a dead end project in camel-core.
>>
>> Another goal is that anyone would be able to understand plain java
>> code, and with a little reading of the code,
>> be able to contribute and, eg. add a new function, or operator etc.
>>
>> I understand that XText is part of Eclipse, and it seems that it uses
>> ANTLR under the covers.
>> I would like to not go down a road to add any runtime deps to camel-core.
>>
>> At camel-extra there is a very old xtext project
>> http://code.google.com/a/apache-extras.org/p/camel-extra/wiki/CamelSpit
>>
>> That said, we could possible add some grammar file to camel-core,
>> which describes the grammer.
>> Then any 3rd party tooling can use the grammar file to generate a
>> parser for its tooling.
>>
>>
>>
>>>
>>>
>>> Am 29.08.2011 10:18, schrieb Claus Ibsen:
>>>>
>>>> Hi
>>>>
>>>> The current Simple language in camel-core has reached its potential in
>>>> terms of maintenance and how easy it would be, for example to add new
>>>> functions and operators. Likewise the current error reporting is not
>>>> precise to point out where in the expression String the problem is.
>>>>
>>>> The implementation is using regular expressions, and that is one of
>>>> the key problems. I think we have grown to the limit how it is to
>>>> maintain.
>>>>
>>>> So I have experimented this weekend to build a prototype based on the
>>>> principle of a recursive descent parser
>>>> http://en.wikipedia.org/wiki/Recursive_descent_parser
>>>>
>>>> I at first looked into using a parser framework such as JavaCC and
>>>> ANTLR. The former would be able to parse the input, but building the
>>>> AST nodes would require to use its tree compiler, which was not maven
>>>> exposed. Likewise JavaCC is not really maintained anymore. People on
>>>> stackoverflow recommended ANTLR. It has more bells ans whistles, but
>>>> as far as I could see ANTLR requires JAR files in the runtime.
>>>>
>>>> And frankly I just wanted a fairly simple code, that anybody, would be
>>>> able to look into and help with.
>>>>
>>>> So I cracked up some prototype code based on the principle from that
>>>> wikipedia article above.
>>>
>>>
>>>
>>> --
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com
>>>
>>>
>>
>>
>>
>
>
> --
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
> Weibo: willemjiang
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: [HEADS UP] - A prototype of an improved Simple language for Apache Camel
Posted by Zbarcea Hadrian <hz...@gmail.com>.
+1, that's what I thought too.
Hadrian
On Aug 29, 2011, at 9:52 AM, Willem Jiang wrote:
> It could be handy if we leverage the other lib in the other camel-module. If the user need the module, it will not be a burden for him to include a third part lib.
>
> On 8/29/11 8:19 PM, Claus Ibsen wrote:
>> On Mon, Aug 29, 2011 at 11:14 AM, Christian Schneider
>> <ch...@die-schneider.net> wrote:
>>> Hi Claus,
>>>
>>> the parser looks quite good as far as I looked into it. In any case much
>>> better than regex. Before we replace the old parser we should also think
>>> about tooling though. Some longer time ago I thought about using Xtext for
>>> the camel DSL and also the languages. The advantage would be that it is
>>> quite easy to build real good Editor for the IDE. I guess with the aproach
>>> you followed this is not so easy. Of ocurse the initial effort of Xtext
>>> would be a lot higher but perhaps it can pay off in the long run.
>>>
>>> Christian
>>>
>>
>> I wanted something that was simple ;). Well in the sense that it does
>> not add any extra JARs to the runtime.
>> So if the tooling can generate plain java source code, then that would be nice.
>> Also the tooling should be active maintained, so we dont end up using
>> a dead end project in camel-core.
>>
>> Another goal is that anyone would be able to understand plain java
>> code, and with a little reading of the code,
>> be able to contribute and, eg. add a new function, or operator etc.
>>
>> I understand that XText is part of Eclipse, and it seems that it uses
>> ANTLR under the covers.
>> I would like to not go down a road to add any runtime deps to camel-core.
>>
>> At camel-extra there is a very old xtext project
>> http://code.google.com/a/apache-extras.org/p/camel-extra/wiki/CamelSpit
>>
>> That said, we could possible add some grammar file to camel-core,
>> which describes the grammer.
>> Then any 3rd party tooling can use the grammar file to generate a
>> parser for its tooling.
>>
>>
>>
>>>
>>>
>>> Am 29.08.2011 10:18, schrieb Claus Ibsen:
>>>>
>>>> Hi
>>>>
>>>> The current Simple language in camel-core has reached its potential in
>>>> terms of maintenance and how easy it would be, for example to add new
>>>> functions and operators. Likewise the current error reporting is not
>>>> precise to point out where in the expression String the problem is.
>>>>
>>>> The implementation is using regular expressions, and that is one of
>>>> the key problems. I think we have grown to the limit how it is to
>>>> maintain.
>>>>
>>>> So I have experimented this weekend to build a prototype based on the
>>>> principle of a recursive descent parser
>>>> http://en.wikipedia.org/wiki/Recursive_descent_parser
>>>>
>>>> I at first looked into using a parser framework such as JavaCC and
>>>> ANTLR. The former would be able to parse the input, but building the
>>>> AST nodes would require to use its tree compiler, which was not maven
>>>> exposed. Likewise JavaCC is not really maintained anymore. People on
>>>> stackoverflow recommended ANTLR. It has more bells ans whistles, but
>>>> as far as I could see ANTLR requires JAR files in the runtime.
>>>>
>>>> And frankly I just wanted a fairly simple code, that anybody, would be
>>>> able to look into and help with.
>>>>
>>>> So I cracked up some prototype code based on the principle from that
>>>> wikipedia article above.
>>>
>>>
>>>
>>> --
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com
>>>
>>>
>>
>>
>>
>
>
> --
> Willem
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.javaeye.com (Chinese)
> Twitter: willemjiang
> Weibo: willemjiang
Re: [HEADS UP] - A prototype of an improved Simple language for Apache
Camel
Posted by Willem Jiang <wi...@gmail.com>.
It could be handy if we leverage the other lib in the other
camel-module. If the user need the module, it will not be a burden for
him to include a third part lib.
On 8/29/11 8:19 PM, Claus Ibsen wrote:
> On Mon, Aug 29, 2011 at 11:14 AM, Christian Schneider
> <ch...@die-schneider.net> wrote:
>> Hi Claus,
>>
>> the parser looks quite good as far as I looked into it. In any case much
>> better than regex. Before we replace the old parser we should also think
>> about tooling though. Some longer time ago I thought about using Xtext for
>> the camel DSL and also the languages. The advantage would be that it is
>> quite easy to build real good Editor for the IDE. I guess with the aproach
>> you followed this is not so easy. Of ocurse the initial effort of Xtext
>> would be a lot higher but perhaps it can pay off in the long run.
>>
>> Christian
>>
>
> I wanted something that was simple ;). Well in the sense that it does
> not add any extra JARs to the runtime.
> So if the tooling can generate plain java source code, then that would be nice.
> Also the tooling should be active maintained, so we dont end up using
> a dead end project in camel-core.
>
> Another goal is that anyone would be able to understand plain java
> code, and with a little reading of the code,
> be able to contribute and, eg. add a new function, or operator etc.
>
> I understand that XText is part of Eclipse, and it seems that it uses
> ANTLR under the covers.
> I would like to not go down a road to add any runtime deps to camel-core.
>
> At camel-extra there is a very old xtext project
> http://code.google.com/a/apache-extras.org/p/camel-extra/wiki/CamelSpit
>
> That said, we could possible add some grammar file to camel-core,
> which describes the grammer.
> Then any 3rd party tooling can use the grammar file to generate a
> parser for its tooling.
>
>
>
>>
>>
>> Am 29.08.2011 10:18, schrieb Claus Ibsen:
>>>
>>> Hi
>>>
>>> The current Simple language in camel-core has reached its potential in
>>> terms of maintenance and how easy it would be, for example to add new
>>> functions and operators. Likewise the current error reporting is not
>>> precise to point out where in the expression String the problem is.
>>>
>>> The implementation is using regular expressions, and that is one of
>>> the key problems. I think we have grown to the limit how it is to
>>> maintain.
>>>
>>> So I have experimented this weekend to build a prototype based on the
>>> principle of a recursive descent parser
>>> http://en.wikipedia.org/wiki/Recursive_descent_parser
>>>
>>> I at first looked into using a parser framework such as JavaCC and
>>> ANTLR. The former would be able to parse the input, but building the
>>> AST nodes would require to use its tree compiler, which was not maven
>>> exposed. Likewise JavaCC is not really maintained anymore. People on
>>> stackoverflow recommended ANTLR. It has more bells ans whistles, but
>>> as far as I could see ANTLR requires JAR files in the runtime.
>>>
>>> And frankly I just wanted a fairly simple code, that anybody, would be
>>> able to look into and help with.
>>>
>>> So I cracked up some prototype code based on the principle from that
>>> wikipedia article above.
>>
>>
>>
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>>
>
>
>
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
Re: [HEADS UP] - A prototype of an improved Simple language for
Apache Camel
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Aug 29, 2011 at 11:14 AM, Christian Schneider
<ch...@die-schneider.net> wrote:
> Hi Claus,
>
> the parser looks quite good as far as I looked into it. In any case much
> better than regex. Before we replace the old parser we should also think
> about tooling though. Some longer time ago I thought about using Xtext for
> the camel DSL and also the languages. The advantage would be that it is
> quite easy to build real good Editor for the IDE. I guess with the aproach
> you followed this is not so easy. Of ocurse the initial effort of Xtext
> would be a lot higher but perhaps it can pay off in the long run.
>
> Christian
>
I wanted something that was simple ;). Well in the sense that it does
not add any extra JARs to the runtime.
So if the tooling can generate plain java source code, then that would be nice.
Also the tooling should be active maintained, so we dont end up using
a dead end project in camel-core.
Another goal is that anyone would be able to understand plain java
code, and with a little reading of the code,
be able to contribute and, eg. add a new function, or operator etc.
I understand that XText is part of Eclipse, and it seems that it uses
ANTLR under the covers.
I would like to not go down a road to add any runtime deps to camel-core.
At camel-extra there is a very old xtext project
http://code.google.com/a/apache-extras.org/p/camel-extra/wiki/CamelSpit
That said, we could possible add some grammar file to camel-core,
which describes the grammer.
Then any 3rd party tooling can use the grammar file to generate a
parser for its tooling.
>
>
> Am 29.08.2011 10:18, schrieb Claus Ibsen:
>>
>> Hi
>>
>> The current Simple language in camel-core has reached its potential in
>> terms of maintenance and how easy it would be, for example to add new
>> functions and operators. Likewise the current error reporting is not
>> precise to point out where in the expression String the problem is.
>>
>> The implementation is using regular expressions, and that is one of
>> the key problems. I think we have grown to the limit how it is to
>> maintain.
>>
>> So I have experimented this weekend to build a prototype based on the
>> principle of a recursive descent parser
>> http://en.wikipedia.org/wiki/Recursive_descent_parser
>>
>> I at first looked into using a parser framework such as JavaCC and
>> ANTLR. The former would be able to parse the input, but building the
>> AST nodes would require to use its tree compiler, which was not maven
>> exposed. Likewise JavaCC is not really maintained anymore. People on
>> stackoverflow recommended ANTLR. It has more bells ans whistles, but
>> as far as I could see ANTLR requires JAR files in the runtime.
>>
>> And frankly I just wanted a fairly simple code, that anybody, would be
>> able to look into and help with.
>>
>> So I cracked up some prototype code based on the principle from that
>> wikipedia article above.
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: [HEADS UP] - A prototype of an improved Simple language for Apache
Camel
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Claus,
the parser looks quite good as far as I looked into it. In any case much
better than regex. Before we replace the old parser we should also think
about tooling though. Some longer time ago I thought about using Xtext
for the camel DSL and also the languages. The advantage would be that it
is quite easy to build real good Editor for the IDE. I guess with the
aproach you followed this is not so easy. Of ocurse the initial effort
of Xtext would be a lot higher but perhaps it can pay off in the long run.
Christian
Am 29.08.2011 10:18, schrieb Claus Ibsen:
> Hi
>
> The current Simple language in camel-core has reached its potential in
> terms of maintenance and how easy it would be, for example to add new
> functions and operators. Likewise the current error reporting is not
> precise to point out where in the expression String the problem is.
>
> The implementation is using regular expressions, and that is one of
> the key problems. I think we have grown to the limit how it is to
> maintain.
>
> So I have experimented this weekend to build a prototype based on the
> principle of a recursive descent parser
> http://en.wikipedia.org/wiki/Recursive_descent_parser
>
> I at first looked into using a parser framework such as JavaCC and
> ANTLR. The former would be able to parse the input, but building the
> AST nodes would require to use its tree compiler, which was not maven
> exposed. Likewise JavaCC is not really maintained anymore. People on
> stackoverflow recommended ANTLR. It has more bells ans whistles, but
> as far as I could see ANTLR requires JAR files in the runtime.
>
> And frankly I just wanted a fairly simple code, that anybody, would be
> able to look into and help with.
>
> So I cracked up some prototype code based on the principle from that
> wikipedia article above.
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com