[TYPO3-50-general] TypoScript 2.0 EBNF

[Elmar Hinz]

> 
> Yes, you're right. However, I decided to not program a lexer because  
> after
> starting with it I realized it would only complicate things if we worked
> with tokens and even tokenize ourselves. Instead of writing my own  
> FSM [1]
> I just used regular expressions.

Hmm, lexers also use regular expressions to tokenize. The API of the lexer
is quite simple: "Give me the next token." It's the token source for the
compiler. There is no need to reinvent regular expressions as an own
finite state machine, even if you would use a fullblown lexer/compiler
architecture.

> 
> Although I'm not really an expert in compilter theory, I think that  
> this is
> just a valid way to go.
> 

Yes and no. It works. But it's a one step architecture. Separtion into
different steps (preprocessor, lexer, compiler, ...) has the main target to
keep each step as simple as possible. And simple steps are easy to
improve or extend or to put additional steps in between.

Old TYPO3 IMHO died because of to less separation of functionality. Every
improvemt or extension of the giant, complex objects and functions led to
conflicts. It was to difficult to modernize it on time.

> 
> You're absolutely right, parse conditions are the weak point. The big  
> requirement
> for implementing them is that the condition must be evaluable during  
> parse time.
> Therefore most of the traditional conditions like browser agent, ip  
> address etc.
> wouldn't work.

At least if you don't want to parse it for each call. :-)

> 
> Therefore I called them "parse conditions" so it becomes clear that  
> these are
> conditions for parsing and only at parse time. One condition I  
> imagine for that
> is the TYPO3 Environment: If in development mode, use this  
> TypoScript, if in
> production mode, use that.
> 
> Most of the other conditions (time, browser agent etc.) will have to  
> be implemented
> with .if conditions. But at least we have simplified the syntax of that.

So parse conditions could be implemented as a preprocessor. A chance to
separate them from TS and to keep TS clean.

Regards

Elmar