c# - custom expression parser

Hey people,

I would like to share a piece of code. I guess it can be useful for others too.
Its useful to pre-parse a string-expression; to extend the GH-internal parser with custom operators and keywords.

string expression = "a + b * Next{a-b} + $foo + Next{a+Next{b-a}*Prev{$HEY}}"

The call for solving requires an (custom) object which is thought to represent a database (a cyclic Dictionary<string,object> in my case).

A custom operator is thought to redirect the current/used database to a nested database, before the evaluation of the enclosed expression occurs.
After the evaluation of the enclosed expression, the operator is "called" again, to prepare the result for the root-operator (TopRoot is "").

An Operator looks like:
-> myOperator{expression}

where expression is either a former expression (can be parsed with GH-internal parser) OR an other custom operator OR a mix of them.

The concept of a keyword is almost the same as for operators, excepting that a keyword can not contain a nested expression.
It is thought as some kind of "constant".

A Keyword look like:
-> $keyword

Any other chars in the expression are parsed GH-internally.
Then all of the cached variable-symbols (strings) are used to ask for an entry in the database.

NOTE: A custom keyword contains only letters! (regex: [a-zA-Z])
NOTE: A custom operator contains only letters! (regex: [a-zA-Z])

The easiest way to use this parser/solver is to implement the abstract class 'ExpressionResolver.ParserBase<T>'

I added an useless example to solve the expression given above.

it may be helpful.

Aloha
Mark

Attachments:

CustomParser.zip, 17 KB

Replies to This Discussion

Permalink Reply by Pieter Segeren on November 19, 2015 at 4:05am

Hi Mark, thanks for sharing this, but I'm afraid I don't understand what it does (at all). Could you explain it a bit more, maybe attach a (or some) simple self-explaining example(s)? The current example is a riddle to me...

Permalink Reply by Ortler Mark on November 19, 2015 at 6:15am

Hey Pieter,

What it does is, parsing an expression, chaching it, and preparing the solver.

At the moment I do not have any time to give an example; I have to learn for an exam. Im going to add one more (more usefull) after monday next week...

aloha
Mark

Permalink Reply by Pieter Segeren on November 19, 2015 at 9:09am

That would be great Mark:) Good luck with your exams and thanks for your reply.

Permalink Reply by Ortler Mark on December 7, 2015 at 7:07am

hey Pieter,
hey people,

sry for the delay but it was time for snowboarding =)

but now I managed to finish a new, more useful example... a (GH-)expression based cellular automate.

With the expression above, the following generations (100) are created; some kind of wave-pattern...

(below a .gif - or a link to the .gif)

In the attachment is a .gha wich provides the used copmonents and some example .gh-files.
For the "input" all kind of data can be used which are supported in GH_Variant (string, double, vector, bool, complex, bool, int)...

The internal expression-parser is expanded with the following custom operators:
- Left
- LowerLeft
- Lower
- LowerRight
- Right
- UpperRight
- Upper
- UpperLeft

(The green square is the current center... the rest should be self-explanatory)
It shows also a nesting: Left{Left{...}} (the nesting can be endless)

For all who want to look closer; a link to the full source... And here is the implemented ExpressionParser...
and the Parser itself...

Greets
Mark

Attachments:

CellularAutomate.zip, 57 KB

Permalink Reply by Pieter Segeren on December 7, 2015 at 10:33am

Hi Mark, can I assume than that your exams went well? Good.
I found a chance to take a quick and diagonal look at the examples you posted (Thanks for these!), now I see what you were doing:)
I'm experiencing some difficulty when trying to use the CAS (sequence) component. Could you include an example of that too please?
I'll attach my futile attempt.

Then some feedback in the form of personal preferences, it's nothing much but I think components that will never produce geometry should always be the mid grey color (IsPreviewCapable = False). I'd like the naming to be consistent (not: "CAEx" vs "expr", or "rk" vs "RK"). Maybe using abbreviations for the operators would keep things a bit more compact, but that would mean you would have to adapt to a more table-like naming convention: Top, Left, Bottom, Right a.s.o. I'm just thinking out load Mark, hoping to contribute.
Thanks again for taking the time to make the examples!

Kind regards,
Pieter

Attachments: