• entries
23
28
• views
20191

# Of rnfnCodeLite and Grammars, Part 1

257 views

Mirrored Here

Right, so in an effort to design a decent parser for rnfnCodeLite to use for syntax highlighting, as well as possibly IntelliSense and AutoFormatting, I need to write out what I need for it to do, and throw out some rudimentary ideas. For whatever reason, doing so in WordPress' tool seems somehow better than plain ol' notepad(or the plain text editor in VS, or any notepad clones). Plus, if I throw this in my GameDev Journal, where someone might actually read it, I might get some decent feedback.

## rnfnBNF Specs

I was originally writing out what the rnfnBNF grammar, as I'm calling it, would need to do, and then I was going to specify the features after. However, this came off as confusing, or at least the way I was going about it. So instead, I'll list my idea of what the specs will be like, though they are certainly not set in stone.

### EBNFesque

Since rnfnBNF is based somewhat off of EBNF, it will follow most, if not all, of the same rules(as seen on the wikipedia page):

Firstly, defining. Unlike EBNF, where it is just =;, rnfnBNF should also allow for the setting of variables/options. As it stands, I'll likely just use rule=definition; for rules, $variable=value; for global variables, and %option[type]=default-value;. Should [type] not be a recognizable value for rnfnBNF options(such as a boolean, Color, string, etc.), the option will be ignored. The main difference between the global variables and the options is that the options would be saved between instances of the rnfnCodeLite control, so such things as color preference could be altered in an Options/Preferences form of the control and used when the rnfnBNF spec file is used again. Global variables could either be used solely by the spec file, or if there is an underscore between the$ and the name of the variable, it would indicate a special variable used by rnfnCodeLite, such as the language(s) the rules are intended for, default color, etc. (Note: This probably won't have much bearing right now, but variables will be treated as references.)

For both rules and variables, the rest of the EBNF grammar would hold. (*...*) for comments, ?...? for special sequences, etc. I might consider making the concatenation symbol optional for easier reading, but possibly not. Fortunately, EBNF allows for two methods of extending it even further:

### EBNF Functions

Since there is a concatenation symbol, something like foobar (whatsit) isn't considered legal, which allows for special functions to be thrown in. Should I make the concatenation symbol optional, I'll likely be making the parser check to see if foobar(whatsit) was one such function that it had. If so, it'd parse as a function, if not it'd be treated as a regular foobar,(whatsit).

Since "," is already in use, and I might want to allow for rnfnBNF grammar to be used as an argument inside a function without tedious quotation marks, I'll likely use another character for argument seperation. For now, I'll use the ":" character, but that isn't concrete.

A few functions I'm toying around with having included are:

• _if(variable=value:rnbnBNF grammar)

• _elseif(variable=value:rnbnBNF grammar)

• _else(rnbnBNF grammar)

• _ifexists(variable:rnfnBNF grammar)

• _create(variable:value)

• _delete(variable)

• _regexp(.NET regexp pattern)(iffy)

• functions in respect to scope/level

• functions in respect to intellisense

• functions in respect to autoformatting

### EBNF Special Sequence

Normally, the ?...? sequence seems to be meant for including characters or somesuch that aren't easily accessible by the keyboard, etc. Such as ?PI? might stand for the UTF representation of pi(that I'm too lazy to look up right now). However, rnfnBNF will use it not as an extender of the grammar, but as an extender of the rule. This is to say, anything in ?...? isn't part of the definition of the rule, but something that pertains to the rule in itself. This could include details to the Intellisense to track any instances of this rule in the language(such as declaring a function), setting options specific to this rule(color/back color of a number), etc.

### Context-Free Free?

Not having researched context grammars very much, but looking at the Definite clause grammar, it seems that allowing a rule to have arguments, it can allow for context-sensitive grammars. I'm leaning towards implementing this right now, but if I do I might make paramter/local variables to a rule be preceded by a special character, maybe "_"? rule(_foobar)=something | _if(_foobar="yay":somethingAdditional); doesn't look too terribly bad. Plus, you can know if a variable is local or not just by looking.

## Part 1, Fin

It is getting late, and I've been writing and rewriting this post for awhile now. I'll leave it as it is for the most part. Might make some minor changes if I notice 'em, but anything else will have to wait for Part 2. Hope the writing isn't too "splotchy", as I jumped around quite a bit.

Part 2 will likely cover Intellisense, Scope, and AutoFormatting ideas/problems I have, as well as any changes I come up with and/or from feedback. At this rate, however, this grammar is getting incredibly complex. I'll have to look at it and see if I can't implement it in a fashion where it is easy/simple, but not take up too much room. I'm toying with treating variables and rules all as one element, at the moment. This would mean I could handle them the same. This would also mean that variables could be functions. i.e., foobar and foobar(bleh) could be defined. Or maybe I'll just throw away variables, consider them to be rules, and just have rules and options. I might do that.

Anywho, before I digress any further, thanks for reading, and please leave feedback if you have it on the grammar ideas.

There are no comments to display.

## Create an account

Register a new account