On Fri, Mar 19, 2010 at 9:16 PM, Shao Miller <[email protected]> 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 _______________________________________________ gPXE-devel mailing list [email protected] http://etherboot.org/mailman/listinfo/gpxe-devel
