Re: Euphoria features
On Thu, 18 Nov 1999 12:10:18 +1300, Jiri Babor <J.Babor at GNS.CRI.NZ> wrote:
>Everett L.(Rett) Williams wrote:
>
>>Yeah, like imagine writing everything in assembler! Duh! Then
>>you wouldn't need Euphoria or any other high level language.
>>With any luck, we can have Euphoria code looking like assembler
>>code now that we have peek and poke. Make a nice pair up with
>>goto.
>
>
>Everett,
>
>Believe me, we all already know you do not like gotos, routine-ids and
>peeks and pokes. The last three are just basic tools, integral parts
>that keep the rest of the language simple and uncluttered.
Actually, the code that it takes to support these constructs clutters the
heck out of program after program. Building the pieces for peeking and
poking is so foreign to Euphoria's intent. I want to hide all the dependent,
non-Euphoria based code either behind the call() interface, or directly
visible as is the case of inline assembler. Even with the bit, byte, and
double byte items that I want for describing "foreign" data structures, I
want them restricted to use in program calls and IO routines. Where
they are to exist in Euphoria code, I propose that they be restricted to
the procedure in which they are used and restricted to existence on
only one side of an assign statement. At least, inline assembler is
highly efficient and isolatable to the scope of a procedure. The
inline assembler can be made more readable and efficient by giving it
access to Euphoria variables local to the procedure. It also avoids call
overhead where efficiency is the major goal. It's final advantage is, that
it is explicit.
>I know campaigners like you almost never change their minds. But,
>please, just for a moment, forget all ivory tower dictates, go into
>the Archives and have a look around. You will find almost all
>significant / interesting contributions depend heavily on those basic
>tools.
You know nothing of the sort. I have spent a great deal of my career
working with people at the leading edge of the business. I opposed IBM
when they were running over people and I have consistently opposed
MS that is far less ethical than IBM ever was. I change my mind when
someone shows me something to indicate that I ought to change it.
Yes, I am painfully aware that those contributions are of the nature that
you say. Because of the reflection of the environment found in the code,
portability is out of the question for most of that code. Because of some
of the lacks in things such as namespace, much of that code is far less
readable than it could have been. Much of it is written by old hands who
do very well with the tools that they have at hand.
>What are you trying to achieve anyway? Rob is not going to delete them
>from our vocabulary just because you keep hitting us with the
>structural programming bible.
Structural programming grew up after I entered the business, but I
discovered that most of the really good programmers that I knew were
already using most of the useful parts of it. By the way, Euphoria is
built along structural programming guidelines as far as I can tell. It
implicitly enforces some of them. It explicitly doesn't have gotos and
I suspect that heritage is straight from that structural programming
bible that I never read.
>jiri
As a result of Rob's recent participation, we have a fairly definitive ruling on
goto. Now it would seem that the conversation that several of us have
been having on the subject of exit from looping structures is more
appropriate to the future. IMO the basic idea that Mr. Hilley put forward
along with the trim that I and others have provided constitute a very
clean basis for accomplishing the goals of the short range goto without
the need for labels or the goto and with very little change to the language.
I understand that he is unlikely to delete them in this version of the
language, but he might not propagate them into other environments as
the language is ported. Since almost zero percent of the code written
using those constructs is portable, anyway, implementing a different
set of mechanisms in a port would cost almost nothing to legacy code.
If other mechanisms are implemented that are easier and cleaner, I
believe that they will eventually push out the less effective code
constructs.
Everett L.(Rett) Williams
rett at gvtc.com
|
Not Categorized, Please Help
|
|
