<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Re: [gPXE-devel] Control Flow (Flow of Control)</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE="2">The "dot language" was only suggested as a way to buld libraries in scripts versus in gPXE code. If you build an extensive "standard library" with a "dot language" and it actually extends gPXE scripting in a user-friendly way, then you push the burden of code size cost onto the script. - Shao<BR>
<BR>
----- Original Message -----<BR>
From: Stefan Hajnoczi <stefanha@gmail.com><BR>
To: Miller, Shao<BR>
Cc: gpxe-devel@etherboot.org <gpxe-devel@etherboot.org><BR>
Sent: Sun Mar 21 01:18:53 2010<BR>
Subject: Re: [gPXE-devel] Control Flow (Flow of Control)<BR>
<BR>
On Fri, Mar 19, 2010 at 9:16 PM, Shao Miller<BR>
<Shao.Miller@yrdsb.edu.on.ca> wrote:<BR>
>> A possible way to extend the language is by having a minimal<BR>
>> "dot-language":<BR>
>><BR>
>> gPXE> . +<BR>
>> gPXE> . -<BR>
>> gPXE> # Choose your stack<BR>
>> gPXE> . working_setting<BR>
>> gPXE> # Copy a setting (stack)<BR>
>> gPXE> . from_setting to_setting<BR>
>> gPXE> . command_to_define : expansion<BR>
>> gPXE> . condition_setting ? true_command<BR>
>> gPXE> . condition_setting ! else_command<BR>
>><BR>
>> etc. My hope would be that parsing code cost could be minimized with<BR>
>> something like, though extending the language from within the language<BR>
>> is just an idea to share, not a recommendation.<BR>
<BR>
I am reading your "dot-language" like a stack-based language and I<BR>
think that's what you intended. A stack-based language is simple in<BR>
some ways (as you say the parser is trivial) but I'm not sure it is<BR>
the right thing for gPXE for a few reasons.<BR>
<BR>
The stack-based model and the syntax is not as familiar as shell-like<BR>
languages. gPXE scripting should be easy to pick up and use. Most<BR>
people will not write gPXE script on a daily basis, and tools that<BR>
require relearning every six months when you revisit them are a pain.<BR>
Let's make the language familiar so you can modify your colleague's<BR>
script a year after it was written without having to invest too much<BR>
time in learning the language and reverse engineering the script.<BR>
<BR>
Although the interpreter (parsing and executing) is simple, a<BR>
stack-based language requires standard library code or primitives.<BR>
It's easy to forget about DUP, DUP2, ROT, -ROT, and the other utility<BR>
operators needed to write code.<BR>
<BR>
There is already a command interpreter in gPXE. Adding control flow<BR>
and expression evaluation will extend the existing facilities. A<BR>
stack-based language, on the other hand, will be orthogonal to all the<BR>
existing features: settings variables, expansion, command interpreter.<BR>
I suspect that it will cost more code (and effort) building parallels<BR>
to existing features in the stack language.<BR>
<BR>
I know you said you weren't proposing this as something to implement<BR>
but I wanted to share my thoughts on that scripting direction.<BR>
<BR>
Stefan<BR>
</FONT>
</P>
</BODY>
</HTML>