On Sat, Feb 26, 2000 at 11:29:23AM -0500, Ezra Peisach wrote:
>
>
> Ok - I'm game. Do you have any ground rules regarding the syntax of "u"?
Well, the higher level we can make it, the better. On the other hand,
making it relatively similar to bourne shell wouldn't hurt since that
is already a known quantity, and will be easier for maintainers to get
to grips with. Being able to ditch all the "portable sh" contortions
will be a big win in its own right.
> For instance, will you support functions, cleanup handlers, and system
> builtins? I am assuming basic conditionals, loops, etc.
Whatever is necessary. We have carte blanche to design a whole new
language to fit the problem space. However, I'm not sure functions
are a good idea -- not to say I'm ruling them out -- for two reasons:
(i) if some sequence needs to be repeated, rather that interpret a
bunch of `u' code every time, we have a candidate for some higher
level language command which should be a implemented in C, (ii) I am
still leaning towards some kind of declarative syntax to abstract away
dependencies (think "makefiles on steroids") which would replace
functions with a rule declaration.
Some of the code will need to be procedural (inside the rule
declarations for example), so flow control is in for sure.
> In looking at the simple compile example, you need to be able to
> lock/unlock a file, create symlinks, execute other programs, and
> cleanup if interrupted.
>
> A cleanup handler might not be required if, for instance, the locking
> file operation will do an implicit unlock if interrupted during the
> compile phase.
I think a good way to do cleanup would be to attach an error block or
exception handler to each rule which would release any resources and
do anything else that seems pertinent if the execution of a rule is
interrupted or otherwise fails. As the dependencies in the rules
unwind, they could accumulate a stack trace as their associated error
blocks would be called until one of them handles the exception or the
top level is reached and the trace is displayed.
> So, from a performance point of view - having the ability to create
> symlinks, lock files, rename files, unlink file, create directories,
> etc. should all be native to the interpreter.
Yup. I would like to keep execution of other programs to a minimum
though -- that is why shell scripts are so slow. The ability to do it
is good from an extensibility point of view, but I think we should
define a concrete set of programs that can be forked for the first
cut, and implement anything else as a builtin. I think only the
following are needed: ar, as, cc, dlltool, file, install, ld, nm,
objdump and strip. Did I miss anything?
What we need now is some example code to work out the syntax of
`u'. Generality is definitely not an issue, though we do need it to
be extensible, so a balance must be struck between not too low a level
that we end up with another spaghetti implementation, and not so high
a level that adding new features means resorting to extending the
syntax of `u' every time.
My prototype breaks each line into tokens separated by spaces, or
grouped by double quotes, and builds an argv array from these tokens.
The first token is looked up in a table of builtins, and if found
called with the argv array as a parameter. If a builtin is not found,
currently the path is searched, but I am working on changing that to
search for a loadable module by preference.
Variables are implemented: `set symbol value' to set, and `$symbol' to
dereference. Like bourne shell, a variable expands to a single token
in the argv array passed to builtins, even if it has whitespace.
Command substitution is implemented: `$(foo bar baz)' works just like
bash.
I need to abstract the tokeniser to use syntax tables, so that new
syntax can be added easily -- for example: rather than hard coding
variable expansion into the reader, a `$' encountered in the input
stream would have a function pointer to consume valid identifier
characters to assemble a variable name to look up in the symbol table.
The explanation is woolly, but you'll see what I mean when I drop the
tarball.
Cheers,
Gary.
--
___ _ ___ __ _ mailto:[EMAIL PROTECTED]
/ __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED]
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
\___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page: /___/ /___/ gpg public key:
http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc
