1. Lobbying
Rob,
I'd be in favor of subscriting/slicing of expressions. As for the infamous
goto, I can't go along with that, but perhaps you would consider a labeled
exit statement and a labeled continue statement as in Java? This would
meet 90% of the cases where a programmmer might want a goto. If this is
still out of the question, how about just a contiue statement--it would skip
the rest of the loop like exit, but go back to the start of the loop rather
than exiting.
-- Mike Nelson
2. Re: Lobbying
On 4 Sep 2000, at 8:18, Michael Nelson wrote:
> Rob,
>
> I'd be in favor of subscriting/slicing of expressions. As for the infamous
> goto, I can't go along with that, but perhaps you would consider a labeled
> exit statement and a labeled continue statement as in Java? This would
> meet 90% of the cases where a programmmer might want a goto. If this is
> still out of the question, how about just a contiue statement--it would skip
> the rest of the loop like exit, but go back to the start of the loop rather
> than exiting.
I don't know java, but a continue sounds like a forwards goto, and i'll be glad
to accept
any goto i can get. Since a forwards reference for a goto is harder on the
single-pass
compiler/interpreter, since it can't know *where* the target is till it reads
that far in the
code, if the forwards goto is done, the backwards goto would be even easier to
do.
Kat
3. Re: Lobbying
>still out of the question, how about just a contiue statement--it would
skip
>the rest of the loop like exit, but go back to the start of the loop rather
>than exiting.
>
>-- Mike Nelson
>
I'm in favour of this one, it would allow very efficient code.
Regards,
Aidan.
4. Re: Lobbying
>I am glad to see you getting back on the list recently. You had
>sort of disappeared for a while.
Well, I'm glad to be back .. the reason I have these little dissapearrances
is usually either that I have nothing to say about a certain subject .. or
.. that I'm not really much into euphoria at that moment ....
About the no new syntax .. what I meant, was that the already available
syntax would be used:
include filea.e
function geta (object x)
return get (x)
end function
include fileb.e
function getb (object x)
return get (x)
end function
print (1, geta(sd)) -- calls geta () .. which calls from filea.e
print (1, get(sd)) -- from fileb.e
print (1, getb(sd) -- calls getb() .. which calls from fileb.e
See, no new syntax ? However, there *is* new functionality.
You are free to overload, and including a file which was already included,
puts the file on top of the search priority.
I think you were assuming I also meant NO new syntax, NO new solution, which
was not the case.
> - Add (built-in or not) routines that offer dynamical
>include files. This dynamic approach should allow for the more
>powerfull usages of include files. Such as mixing include files,
>alter the code, calling routines with error trapping, etc. It has
>the following advantages:
>And, a huge amount of management overhead on the programmers part,
>along with a surfeit of includes upon includes upon includes. Why?
There are a number of features that many people seem to want, however,
everyone wants them in a different form. Some need dynamic includes, some
need to be able to have the interpreter execute custom made code, many want
error trapping and some want to be able to change/alter the namespace of
some includes. (make include filea use fileb against its own will .. sort
of) ... so many different features, for specialized situations ? why not
just have a built-in function to execute and/or shroud euphoria code ? With
a few functions it gives all the acces everybody wants, and they can shape
it like they want, without making euphoria too complex.
>Your approach requires that the programmer have intimate
>knowledge of the internals of every include, or over-use includes
>out of self defence. The whole point of using other people's
>includes is to leverage their knowledge and work. If I have to
>know everything that they knew to write the include, what have
>I gained. In addition, at some point in this process, some of the
>authors are likely to start shrouding their includes. Then, your
>technique will really be vulnerable.
Well, it won't be vulnerable, but for some situations shrouded files are
useless (enforcing routine overloading, etc.) but I feel in the future we're
already going to a situation where the interpreter needs to take on the
shroud-problems such as conflicting names. Keeping all the routine names in
tact will do much good.
> - full run time control (very powerfull)
>Dynamic includes cannot be allowed without allowing the
>interpreter to be dynamically called. Their is nothing simple
>about that thought. If we are to get some dynamic control of the
>interpreter, that will mean huge changes in the language. I
>actually am for some of those changes. I consider the compiler a
>shortsighted abomination that does very little for the language.
>Dynamic access to the interpreter could make this a direct AI
>language like LISP. If you have ever seen the IBM language, now
>available independently, called REXX, you would understand the
>kind of power that this would mean in a typed language such as
>Euphoria.
Indeed, extremely powerfull .. program A writes the code of program B and
has it executed in real time.
Perhaps its a real chalange for Robert, but if we all consider Euphoria to
be that good, why not aim for the top .. adjusting the interpreter to allow
multiple instances in this way, is nothing more than keeping track of a
stack list .. how do you think recursion works currently ? No big thing.
> - takes the new compiler into account (dynamically
>included routines are off course never compiled, but always
>interpreted)
>You seem to be contradicting yourself here. What do you mean?
If you compile a program that uses dynamic includes, the dynamic includes
are not compiled off course. When a routine from a dynamic include is
called, it will still be interpretered the old style. No big thing as well,
the interpreter's code is for 90% in the c-lib its providing .. I only
foresee problems with enforcing the public domain-version. Perhaps compiled
programs that use dynamic include files can only be an option for registered
users because they aren't allowed to distribute the c-lib alone.
Perhaps things a little bit more clear now ?
Ralf N.
