1. Linux & DLLs & Short-Circuit
- Posted by Robert Craig <rds at EMAIL.MSN.COM>
Jun 30, 1998
-
Last edited Jul 01, 1998
David Cuny writes:
> Well, my Unix guru verified me that Unix DOES support
> dynamic shared libraries (which are the same as DLLs).
> So that staic linkage thig I was worried about isn't an issue -
> but I'm sure Robert already knew that.
No I didn't. In my Unix days I had used shared libraries,
for printf() etc. but I had never dynamically linked to a
C routine using a name that I created at runtime.
> He also claims that the function pointer/var args approach
> should work just fine. So a Linux port with DLL links similar
> to Win32 is on my wish list.
It's good to know that there are no severe obstacles
to porting. I've finished implementing short-circuit, so I'll
have to choose another project. 
I did a pretty thorough check for old code that might
break using short-circuit evaluation. I actually studied
many suspicious cases in detail. Conclusion: I couldn't
find *any* program on the RDS Web site that will break.
Several programs contained calls to functions with
side-effects that might be skipped by short-circuit,
but in no case did it actually affect the correctness
of the program. I'm sure a few programs "out there" will
break, but the percentage is probably well under 1%.
In any case there will be a warning.
I implemented short-circuit evaluation
of "and" and "or" whenever these occur in a
"conditional expression" - that's one of the following 3
cases:
if condition then ...
elsif condition then ...
while condition do...
Full evaluation will continue to happen everywhere else.
For instance:
x = expression
foo(expression, expression...)
x[expression] = ...
This is necessary because in Euphoria "and" and "or"
can sometimes result in a sequence. It would be wrong to
short-circuit something like:
x = 1 or {0,2,4}
and say that x is 1.
x really *must* be set to {1,1,1}.
However, a conditional expression must evaluate to
an *atom* or Euphoria will pull the plug on your program
and give you an error message. So in a conditional
expression, we can say that short-circuit evaluation
will either give you the same result as full evaluation,
or your program contains an "error" and would otherwise
die. It turns out that if you have something like:
if (1 and {0,2,4}) ... then
then with full evaluation you are doomed to having
a fatal error. There is no operation that you can apply
that will convert a sequence back to an atom to get
a valid condition. You could pass the sequence
to a function that returns an atom, but short-circuit
will not apply when evaluating arguments (where a
sequence is a legitimate result).
So, with short-circuit evaluation of conditionals:
A or B, A and B,
you either get the same result as full-evaluation,
or there's an error in expression B (that won't be caught).
Not catching an error in B is often exactly what you
want to happen, and is one of the advantages of
short-circuit. B could have many types of error:
subscript out-of-bounds, uninitialized variable etc.
If B results in a sequence, that's just another type
of error that we will skip.
I think the rationalization above allows us to introduce
short-circuit evaluation without creating logical
inconsistencies in the language. There are other
places where an atom must be the result of an
expression, but I'd rather not take advantage
of them. e.g. subscripts, assignments to atom
variables, etc.
Regards,
Rob Craig
Rapid Deployment Software
