Path: utzoo!attcan!uunet!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!mahendo!wlbr!hacgate!ashtate!dbase!awd
From: awd@dbase.A-T.COM (Alastair Dallas)
Newsgroups: comp.databases
Subject: Re: FORCE
Summary: psuedo-code in an exe
Message-ID: <513@dbase.A-T.COM>
Date: 11 Apr 90 00:52:31 GMT
References: <23925@usc.edu> <1990Apr6.131126.2015@xenitec.on.ca>
Organization: Ashton Tate Development Center Glendale, Calif.
Lines: 72


The original version of Clipper produced an .exe file, allright, but
it contained largely pseudo-code.  To some extent, you have to use
pseudo code because of the dBASE language's late binding of identifiers.
What am I talking about?  Consider:

	Name = "Jones"
	Fname = space(8)
	@ 10,10 GET Fname
	READ
	USE (Fname)     * or, USE &Fname

	? Name

Ok, this compiles into:

	<assign literal "Jones" to memvar Name>
	<call space() with arg 8>
	<assign result to memvar Fname>
	<get, read>
	<call use() with arg memvar Name>
	<call ?() with arg.... with arg.... uh...>

You don't know what you're printing.  Is it the memvar called Name that
you dealt with a minute ago, or is it the field in the file that you
just put into Use?  

To avoid some sort of psuedo-code in this and similar situations, you
can just say "the user can't open arbitrary DBF files--we have to "see"
each DBF at compile time."  Since Clipper doesn't have this restriction,
nor many restrictions on macro usage, it seems likely that some binding
is still delayed until runtime.  If you delay binding infinitely, you
have an interpreter; the more binding you do up front, the more 
compilerish you are.

As I said, the first version of Clipper compiled code that looked
something like:

	CALL	INTERPRET
	DB	f3h, 02h, 54h, ...

which is a clever way of using psuedo code and still calling yourself
an .exe. compiler.  I understand, however, that subsequent versions
have gotten more sophisticated and granular.  My guess is that today's
Clipper is more like:

	CALL	EVAL_ADDR
	DB	f3h, 02h
	PUSH 	AX
	CALL	ASSIGN_MVAR

and so forth.  Still late-binding of identifiers, but less interpreted
than the 1.0 version.

For the record, I'm told A-T's Professional Compiler (with which I
am not at all involved) will be even "closer to the machine," using
a variety of code-global optimizations.  I heard a rumor at one point
that you'd be able to tell it "these are the only DBFs I expect to 
deal with" and it would optimize to a fare-thee-well, or you could
say "stay loose" and it wouldn't.  If I knew anything, I couldn't
talk about it, so don't listen to me...

Oh, yes, and back to the subject: What I've heard about FORCE is
that it shines on a lot of the dBASE language compatibility issues,
such as late-binding, and in exchange gives you the highly-optimized
code that A-T's compiler will when the right switches are thrown.
Only with FORCE, there's no compatibility switch.  But this is all
rumor and hearsay--please correct me if I'm wrong.

/alastair/

Disclaimer> I'm speaking for myself, as usual, not my employer.