[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Scriptometer: measuring the ease of SOP (Script Oriented Programming) of programming languages

> It's like calling your friend to say "Hey, I missed school today, can 
> you tell me what homework
> question number 1 was?" and your friend says "I gotta hang up the phone, 
> a bug-eyed
> monster just came to the door!".  No value is returned by the 
> get-homework-question
> function.  You get to say how a "gotta-hang-up" is handled.

It depends upon whether one cares
more about doing the homework, or
saving one's friend.

In the first case, "gotta-hang-up"
is handled the same way as "no, I
missed school too": upon not having
enough information after the call
to finish do-homework, one starts
over, calling friend N+1.

In the second case, no matter what
one is calling about (do-homework, 
go-to-the-game, etc.) "a bug-eyed
monster" is handled the same way:

(so we need not have a special
"gotta-hang-up" clause, at the
call site, for either case)



> In fact, exception handling is an area where the scripting languages
> might be able to do a better job, and come up with some useful
> innovations, with their tendency to a stronger focus on how people
> use and want to use languages.

After introducing too many non-local
exits via exceptions, something like
unwind-protect is nice to recoalesce
the logic, which helps with keeping
data* structures consistent.  On the
other hand, if one has a handy ACID
environment, it can implicitly handle
those partial rollbacks. 

Has anyone run across a system which
used guarded commands, but with atomic
transactions instead of the guards?

An IF c0 [] c1 [] c2 FI would finish
in a state where one of the commands
had succeeded, and a DO ... OD would
finish in a state where all of them
had failed.  In no case would any of
the partial executions be visible by
the final state.

Such atomicity might be too heavy for
general scripting, but I mention it
because I once had the pleasure of
working on a web editor which had a
undo/redo mechanism (for the user, of
course), and discovered that the undo
also made it easy to write code which
would try a fast optimistic transform,
with the option of, halfway through,
undoing its work and punting to the
slow but correct transform.


* I suppose for the fp crowd, this is
not an issue.  For those of us who do
keep state, non-local exits are dual
to assignment: a variable's value is
determined by the *last* assignment
before the *first* exit.