OpenEuphoria

Re: Suggested enhancement

• Posted by Carlos Jose Gonzalia <gonzalia at CRIBA.EDU.AR> Apr 21, 1997
• 1238 views

Jeff Zeitlin wrote:

> I'm not sure I perceive why forward declarations would be
> necessary - would you be willing to elucidate?

In most cases you can do the same job as a mutual recursion does if you just
rewrite the algorithm, but this can be difficult and makes the code hard to
read. The reason why this matters so much for parsers is that parser algorithms
are naturally mutually recursive, since their grammar form (EBNF, context-free
grammar or syntax diagram) is by definition mutually recursive. As regards to
efficiency, a good grammar-based parser (by this I mean the grammar is
"factored non-left-recursive") is practically as efficient as a non-mutually
recursive parser. Check any good text on compiler construction for details.

> 3. A procedural parameter capability - you could write highly
>           generic routines without needing to redefine
>           procedures or functions for (for example) [cut]

This is the best proposed enhancement to Euphoria I've heard till now...
Wish I had come with it ;)! I believe it's possible to embed this feature
into the language in one of two different ways, so to keep type-safety:

  1. Allow fully general procedure/function parameters types, for example,
     a function that sorts an arbitrary sequence of objects in some user-defined
     order would have as header

        function sort (sequence nonsorted, function less_eq(object a, object b))

     or something similar. The trouble with this approach is that the
     proc/fun parameters could have their own proc/fun parameters. This makes
     for a difficult interpreter implementation, and considerable execution
     overheads if used extensively. The type-checking issues are also very
     difficult to deal with, unless one restricts the allowed types of the
     proc/fun's arguments. All this is due to the more complex calling mechanism
     and the possibility of having a proc/fun argument reference its static
     context (non local variables known only to itself) when it is called
     inside the routine it was passed to.

  2. Allow restricted procedure/function parameter types, such that their
     argument is just an "object", not another proc/fun. This would put all
     the effort of type-consistency in the programmer's hands, in a way much
     like the type idea of Euphoria, so it fits nicely in that scheme.

I believe 2 would be the best choice for the enhancement. I'm not sure having
dynamic run-time macro facilities would be an advisable idea. Just think
all the parsing, type-checking and precompiling that will happen with all
those macros moving around the program... Cameron Kaiser mentioned the
possibility of using closures, but the implementation of closures is very
expensive both in time and space...

Somebody suggested the idea of having proc/fun types could be useful for
having sequences of proc/funs (sorry, I can't find the exact reference between
the lots of e-mails here). This is very difficult to have in Euphoria, since
you would be able to put type incompatible functions in the same list, and
then sometime later call the functions stored in the list. This obviously
requires a lot of type information to be mantained besides those functions
in the sequence (this is called a "descriptor"). Managing all that type info
would be difficult, and there is also needed information about the static
context of all those functions. This mandatory dynamic type checking would
cause a significant overhead to the execution time, too.

In short, I believe the idea of restricted proc/fun argument types would be
a great thing to have, but it shouldn't be as general as the mentioned
features for efficiency problems would arise.

-----------------------------
Carlos Gonzalia,
Universidad Nacional del Sur
Bahia Blanca, Argentina.
gonzalia at criba.edu.ar
-----------------------------