|
Like in Coco/R, the parser needs be to able to give control up to a user defined function which has access to a a lookahead buffer of tokens, and returns a boolean value.
The job of the function is to traverse that lookahead buffer looking for patterns in it that tell it how to resolve a grammar conflict.
It's called a syntactic predicate, and it will at least need a while loop of some sort (or a for loop or any kind of iteration statement) and those aren't an expression AFAIK. I mean, I guess i could sort of set up a thing where it called your SP in a loop but i still don't see how that would help.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Expression Trees have iterations and code blocks since .Net 4.
So, yes. I believe it can be done.
I've done similar stuff. (For performance reasons though)
But I have to admit that the more I work with Expressions, the more I appreciate the work the compiler do for us. It's really tedious work.
|
|
|
|
|
I'll look into it but i don't know if i can limit the kinds of queries i need to support to those that can be represented with only expression trees. Although I would certainly prefer that.
But if i did that I'd just go completely declarative anyway
so my grammar construct would look something like
production= identifer [ "<" attributes ">" ] "=" expressions ";" => myexpression
although the => above is NOT a lambda expression. But it's a syntactic predicate in a grammar. I'd probably just use it since it makes sense in this context, but maybe ?? would make more sense. I don't know. Something like that though. =)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
In case you decide to go down this road, you need to implement some kind of caching functionality, since expressions aren't handled by the GC.
|
|
|
|
|
Ouch, thanks for the warning. I think I'll skip it since the whole point for me was obviating the need for caching.
If i'm going to do caching, I'll just support full code in the predicates. You know?
Gosh that's disappointing, but I'm really glad you warned me. Thanks again.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
|
I will definitely be looking into this.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Good luck.
And wear a wig so you don't tear out your own hair.  At least that's how I felt when I started with Expressions.
There are some examples on how to use Expressions in my articles, although the purpose was quite different.
|
|
|
|
|
I'm doing LALR(1) parse table generation right now. Expression trees are simple by comparison. LOL. I'm in the weeds over here - this is Dragon Book territory, and I've gone native. 
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I am not sure that I know exactly what you mean, but ...
.Net let you to parse a string expression using your own grammar, and then convert the resulting AST (abstract syntax tree) into the kind of AST predefined in .Net (have a look at the Expression class family). Then the framework will compile the later AST (object) into executable codes at runtime and be used immediately having access to most of the parent runtime context ... We do that quite a lot in one of our projects.
Most of other languages (I know of, which are not alot) do not allow you to do that ...
|
|
|
|
|
It's the compilation part that bothers me. Once a windows PE loads a DLL it doesn't get unloaded.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the monster, codewitch wrote: This means I can't support syntactic predicates or code behinds in my grammars at run time.
Looks like an opportunity to write another chapter in your science-fiction epic  We'll see if the ratio of ten Lounge posts to 0.025 KLOC holds Quote: 'One must still have chaos in oneself to be able to give birth to a dancing star.' Nietzsche
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
i'm a talker what can I say?
But yes, I breathe chaos. I mean, have you seen my code?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the monster, codewitch wrote: have you seen my code
Yes, it reminded me of Thai traffic in terms of frequent pile-ups, no one observing traffic light signals, or speed limits
Actually, I am a fan of your work, and its ambition, even though I can't understand it ... yet. It's great thing to love what you do, to be deeply involved. Van Gogh said: Quote: "I'm an artist: it's self evident that word implies looking for something all the time without ever finding it in full. It is the opposite of saying: 'I know all about it. I've already found it.'
I remain fascinated by the (very old) methodology of "Decision Tables," which, I am sure you know, is one way to describe a grammar, or state machine.
The problem that intrigues me is: given a set of "rules" like this:Quote: Airfare
Infant passengers under two years old are offered a discount of 80% on domestic flights Infant passengers under two years old are offered a discount of 70% on international flights.
Youth passengers (between two and sixteen) are offered a discount of 10%, for any kind of destination.
Frequent flyer enjoys a discount of 20%.
For international flights, passengers are offered 15% discount if they travel during off-seasons.There would be no discount for international flights, except that when the passenger is an infant passenger or when travelling during off-season.
Passengers who make reservation five months before their journey are offered a discount of 10%.
Frequent flyer enjoys a discount a 15% by making reservation five months before their journey.
The amount of discount is accumulated.
The maximum amount of discount for infant passengers is 80%
The maximum amount of discount for non-infant passengers is 20%
While a decision table (or a gigantic nested if/then/else) for this can be designed any number of ways, how do you parse/analyze ... in code ... the factors with the most discriminatory power, and the factors that can be omitted in evaluation based on the key factors. I scan the rules, and, intuitively, see 'age as the key factor, but, damn if I can articulate exactly how that intuitive response comes into play.
I show this rule-set to intermediate students; their responses, in terms of what is most significant, vary widely.
cheers, Bill
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
You need to establish your input alphabet first.
Age is one input. Another is time of travel. Another is area of travel (international v domestic)
consider it a tuple.
maybe i'm forgetting something as i am out of coffee at the moment.
But that tuple there is your input you can feed to a state machine.
Normally my inputs are chars most of the time but they don't have to be. =)
anyway, i see this as a state machine. Your accept states have the discount encoded as a percentage, and the different paths that are taken depend on the value of those tuples, with each transition being able to be on one of the tuple's members. So each arrow above it has a predicate like an age range or a destination region.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I "borrowed" that rule set from: [^]. Feel free to use, if you wish, as an example your code can parse ... when your code ever reaches the point of ... whatever.
The key issue here, for me, is the factor-analysis that leads to the decision table with least complexity, and most robustness, and one that can be verified as handling all possible inputs (given reasonable constraints on inputs).
imho, this problem is a single-dimension workflow: other problem spaces that involve back-tracking, 'undo, handling asynchronous events that may occur in any temporal order ... have other "dimensions."
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
BillWoodruff wrote: The key issue here, for me, is the factor-analysis that leads to the decision table with least complexity, and most robustness, and one that can be verified as handling all possible inputs (given reasonable constraints on inputs).
That's why i suggested a state machine. They're kind of self optimizing if you can construct one as an NFA - all you have to do is do a powerset expansion on it then remove duplicates from the result. Any ambiguities are then easily determinable from the resulting set of accepts. The math behind it is all sound and verified for i don't know how long.
As long as your input sets are constrained to a deterministic, finite alphabet, your FA machine should do the job.
And as far as this
BillWoodruff wrote: s a single-dimension workflow: other problem spaces that involve back-tracking, 'undo, handling asynchronous events that may occur in any temporal order
A DFA doesn't "backtrack" but an NFA does, virtually. The upshot is you can conceptually backtrack but the resulting state machine will not, once you do the powerset to turn an NFA into a DFA which makes it more predictable and efficient.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Unfortunately, I am not familiar with the theory of finite and deterministic automata. I am interested in the analysis of complex rule sets leading to simple-as-possible code "engines."
Having once been kind-of a social scientist, I do have some experience with factor analysis.
One thing I am sure of is that, given a well-formed decision table, I could write code to turn that into an interactive system.
cheers, Bill
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
finite state machines resolve directly to jump tables.
so think like:
a switch case with a bunch of goto cases in it, mapping the logic out.
the code is pretty simple.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
... and now I have taken a big step ahead.
No more scratching my head over any details.(Almost) no more masking and wrapping that thing up like an old mummy. Even that did not prevent the Super Soaker (TM) of an airbrush from finding the tiniest fold in my paint mask and squirt about half a litre of paint through it per second.
UH-1E 151886, now in color[^]. Plus some of my 3D printed parts.
How do you like the color? The Marine Corps did not fly around in ugly army olive drab. It had to be 'medium field green' and I had to mix up quite a lot of it.
There still is enough to do. First, I got to clean up all the spots where the Super Soaker (TM) blasted its way through the masking tape. Then spray on the bigger insignia with paint masks and (sigh) the Super Soaker (TM). Apply the smaller decals (including the 'fuel dick drain'). And then comes my last chance to mess things up royaly: detailing and weathering.
So, how do you like it? It's still a bit boring right now. With more details and some 'dirt' it will look far better. or it's finally ruined.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Bell-issimo !
|
|
|
|
|
Thanks!
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Nice...
Technician
1. A person that fixes stuff you can't.
2. One who does precision guesswork based on unreliable data provided by those of questionable knowledge.
JaxCoder.com
|
|
|
|
|
Thanks!
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I like it! 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
