OpenEuphoria

Namespace comments, forward and extern, comments about speed

• Posted by Jeff Zeitlin <jeff.zeitlin at MAIL.EXECNET.COM> Jun 25, 1998
• 761 views

Revisiting the discussion on namespacing that I started a while
back, I don't recall whether I publicly observed that Robert has
already done _part_ of the job in allowing global scope
variables, file scope variables, and procedure scope variables.
The rest of the job, and I don't minimize the difficulty, is in
including a mechanism that will allow resolution of duplicate
and/or ambiguous names.  There have been several suggestions for
syntax.  The two which I think are probably the best are

include foo.e as foo

with namespace foo
include foo.e
without namespace

Note that using the with/without construct would require deciding
whether to allow nested namespaces, and, if not, how to handle
"nested" namespace invocations:

with namespace foo
include foo.e                   -- functions are foo_funcname()
with namespace bar
include bar.e                   -- foo_bar_funcname()?=20
                                                -- bar_foo_funcname()?
                                                -- bar_funcname()?
-- foo_funcname() (ignoring
                                                nested decl)

Either overall syntax would be suitable, IMO (I have no comment
at this time on the desirability of allowing nesting), and
neither would break existing code, as in both cases, the default
(omitting the as clause or the with/without namespace statements)
would maintain the current behavior of non-namespacing.  I once
again urge Robert to seriously consider this.



Another useful bit of syntactic sugar involves "finishing" the
job that was begun with routine_id() and call_proc(), and the
corresponding routines for accessing Win32 DLLs.  The DLL linkage
capability gives, in essence, equivalent functionality to what in
most languages is an "extern" or "external" declaration; the
internal linkage (routine_id() etc.) gives, in essence,
equivalent functionality to what most implementations of Pascal
call "forward".

This last is truly a matter of syntax rather than functionality -
but I think that the existing syntax for the functionality is
awkward, and likely to "turn off" experienced programmers who
might otherwise give consideration to Euphoria for their
projects.



On the speed of Euphoria:  I just had a graphic (pun intended -
read on) illustration of just how useful Euphoria sequences can
be, and how much improvement in performance can be seen from
proper use - I found an old program, written in BASIC, that
implemented an idea from Scientific American's column "Computer
Recreations" (although at the time it might have been
"Metamagical Themas" or even "Mathematical Games") - look for the
key word "demons" for more info.  The source was QBASIC
compatible; I also had a Turbo BASIC .EXE file of it.

Run under the QBASIC interpreter, the program took 50 seconds to
calculate a function of a 200x200 array.

The Turbo BASIC .EXE took 5 seconds for the same function.

A statement-for-statement translation of BASIC to Euphoria gave
_zero_ improvement.  But, when I rewrote the Euphoria to take
advantage of sequence operations, the _interpreted_ Euphoria took
2 seconds - or less - for the same function.  I never doubted
Robert's claims for Euphoria - but it was never really driven
home until this...
--
Jeff Zeitlin
jeff.zeitlin at mail.execnet.com