[gPXE-devel] Control Flow (Flow of Control)

[Stefan Hajnoczi]

On Fri, Mar 19, 2010 at 9:16 PM, Shao Miller
<Shao.Miller at yrdsb.edu.on.ca> wrote:
>> A possible way to extend the language is by having a minimal
>> "dot-language":
>>
>>    gPXE> . +
>>    gPXE> . -
>>    gPXE> # Choose your stack
>>    gPXE> . working_setting
>>    gPXE> # Copy a setting (stack)
>>    gPXE> . from_setting to_setting
>>    gPXE> . command_to_define : expansion
>>    gPXE> . condition_setting ? true_command
>>    gPXE> . condition_setting ! else_command
>>
>> etc.  My hope would be that parsing code cost could be minimized with
>> something like, though extending the language from within the language
>> is just an idea to share, not a recommendation.

I am reading your "dot-language" like a stack-based language and I
think that's what you intended.  A stack-based language is simple in
some ways (as you say the parser is trivial) but I'm not sure it is
the right thing for gPXE for a few reasons.

The stack-based model and the syntax is not as familiar as shell-like
languages.  gPXE scripting should be easy to pick up and use.  Most
people will not write gPXE script on a daily basis, and tools that
require relearning every six months when you revisit them are a pain.
Let's make the language familiar so you can modify your colleague's
script a year after it was written without having to invest too much
time in learning the language and reverse engineering the script.

Although the interpreter (parsing and executing) is simple, a
stack-based language requires standard library code or primitives.
It's easy to forget about DUP, DUP2, ROT, -ROT, and the other utility
operators needed to write code.

There is already a command interpreter in gPXE.  Adding control flow
and expression evaluation will extend the existing facilities.  A
stack-based language, on the other hand, will be orthogonal to all the
existing features: settings variables, expansion, command interpreter.
 I suspect that it will cost more code (and effort) building parallels
to existing features in the stack language.

I know you said you weren't proposing this as something to implement
but I wanted to share my thoughts on that scripting direction.

Stefan