1. Euphoria features
- Posted by Jason Gade <jgade at NETZERO.NET>
Nov 12, 1999
-
Last edited Nov 13, 1999
First, let me say that I love the simplicity of Euphoria (I even like the
abbreviation of 'U4' that someone came up with.)
Second, let me say that I have never written any large projects. I have
been planning on writing a Euphoria 'Rogue' clone for nearly a year now, and
never did follow through with my 'CoreWar' ideas which Rod and others
inspired in me.
Now, on to *my* ideas.
First off, I think that Euphoria is very cool the way that it is. Although
namespace needs to be addressed, programmers need to find the language's
true paradigm before trying to make it into C or Java.
The infamous construct of
xy = get_position()
position( xy[1], xy[2] )
should never have been begat. The most Euphorian solution should have been
for position() to take a sequence as a parameter list instead of integers.
xy = get_position()
position( xy )
I am even thinking (though not convinced) that functions and procedures
should *always* take one parameter, and that '&' should replace ',' as a
parameter separator.
position( x & y )
Although I don't know object orientation very well, I do believe that
Euphoria should lean in that direction. Mainly polymorphism ( I think that
that term is correct ) where functions and procedures take values that make
sense to them.
So, for my ideas to additions:
{ line, column } = get_position
does make *some* sense to me. Not wholly in favor, but not against it
either. I need more convincing.
My other idea, for namespace, is as follows:
--foo.e
include bar.e
import var1, var2, var3 --you could even use a 'type' identifier (such
as integer, atom, sequence, user-defined) if you *must*
import constant CONST_I, CONST_II, CONST_III
import func_one, func_two, proc_three
The import keyword would make these identifiers global to the file. If the
file was included, then it would be *just* within that file. If the file
was the main program, then it would be the entire program (after the import
statements).
The main idea is that the programmer should *know* what is being included in
his/her program.
An alternate would be an 'export' keyword, which would put the onus on the
include file programmer to decide what should be exported.
I think that the 'type' declaration can adequately handle structures, but it
would be longer to program than in other languages.
type employee( sequence empl )
if length( empl ) = 4 then
if sequence( empl[1] ) then -- last name, could use string type
if sequence( empl[2] ) then -- first name, could use string
type
if atom( empl[3] ) then -- salary, could use float type
if integer( empl[4] ) then -- years in service,
could use type
return TRUE
end if
end if
end if
end if
end if
return FALSE
This would trap bad structs, but it is cumbersome. There may be a better
way. Also, if speed is a consideration then it would only apply to dev,
alpha, or beta programs. Then you should have 'without type_check' if your
source is stable.
I think that routine_id() is okay, but that it should be global. This can
facilitate OO, and it could even do away with my proposed 'import' or
'export' keywords.
It should be combined with variable_id() though, even though I would loathe
to see pointers in Euphoria. It could be useful in overriding scope when
necessary.
I can forsee a Euphoria in which most 'objects' are defined in separate
include files that contain functions for working with that object.
Object-oriented, but not in the non-flexible way that most OO languages are
defined.
Sequences are very powerful, and I think that we haven't even scratched the
surface yet in their utility.
__________________________________________
NetZero - Defenders of the Free World
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html
2. Re: Euphoria features
- Posted by Roderick Jackson <rjackson at CSIWEB.COM>
Nov 12, 1999
-
Last edited Nov 13, 1999
Jason Gade wrote:
[...]
>First off, I think that Euphoria is very cool the way that it is.
Before going any further, I'll second this observation.
>The infamous construct of
>
> xy = get_position()
> position( xy[1], xy[2] )
>
>should never have been begat. The most Euphorian solution should have been
>for position() to take a sequence as a parameter list instead of integers.
I agree. Alas, it's already been done. BUT... it might not
necessarily be set in stone. I know Rob has opted to break
old code before by introducing short-circuting to 'if'
statements (I *still* don't understand why, but anyway.)
So, there is somewhat shaky precedent to justify changing
'position' and any other built-in functions to be more
orthogonal. Fix it *before* Euphoria takes over the
programming industry. Note, I'm not necessarily in favor
of such a change; I'm just thinking about the
ramifications versus benefits.
>I am even thinking (though not convinced) that functions and procedures
>should *always* take one parameter, and that '&' should replace ',' as a
>parameter separator.
!!!
You know, this thought had occured to me recently as well,
but I forced it aside. ("My, what an odd thought you are!
Shoo, before someone notices you!") But honestly, I think
it would have worked out very nicely had Euphoria been
designed that way from the start; '&' in place of ','
would have been all that was needed. (Well, okay, for
those of you who would complain about the need to depress
the shift key to make the '&' character, we can also
imagine Rob had used ';' instead of '&' for
concatenation...) Oooh, this thought is starting to
really demand my attention... I think I'll have to sleep
on it.
>Although I don't know object orientation very well, I do believe that
>Euphoria should lean in that direction.
It does somewhat already, probably more than any of us
currently realizes (keep reading....)
>I think that the 'type' declaration can adequately handle structures, but it
>would be longer to program than in other languages.
I agree, it works to an extent. The problems most
people have with that method though are:
1) You'd usually use constants to access the elements,
and then you run into scoping problems again (and
I admit, STRUCT37_NAME gets messy...)
2) It's TOO flexible. You'd have a hard time setting
up a structure that way that could be used to
extract records of exactly x bytes in length,
each consisting of exactly y fields (each being a
specific number of bytes in length), from a file.
>I think that routine_id() is okay, but that it should be global.
Mmm, I'm not settled either way with that...
>It should be combined with variable_id() though, even though I would loathe
>to see pointers in Euphoria. It could be useful in overriding scope when
>necessary.
Well, while this would be useful for a one-line swap function,
I don't see much point in the pass-by-reference methodology it
would bring about. Speed's not a concern since Eu usually just
passes pointers. And I would think the desire to avoid the
messiness of passing multiple variables through several levels
could be removed by just redesigning the setup (i.e., use
local variables rather than parameters.)
I do agree with the 'no pointers' though.
Oh, and I think I'll bring this up; if 'variable_id' ever
*were* implemented, I'd be willing to bet that it would be
limited to the current scope. 
>I can forsee a Euphoria in which most 'objects' are defined in separate
>include files that contain functions for working with that object.
>Object-oriented, but not in the non-flexible way that most OO languages are
>defined.
You know, I really don't see anything stopping us from
programming in this manner right now. I guess in a sense,
many libraries already do that somewhat (I know Picasso
does, by lumping the routines into POLYGONS.E, TEXTURES.E,
etc.) I guess no one thinks of it as OOP when achieved in
such a 'raw' way; I know I often fall into the trap of
thinking 'object-orientation' = 'elaborate framework'.
>Sequences are very powerful, and I think that we haven't even scratched the
>surface yet in their utility.
That's an understatement! 
Rod Jackson
3. Re: Euphoria features
Jason Gade wrote:
>Second, let me say that I have never written any large projects. I have
>been planning on writing a Euphoria 'Rogue' clone for nearly a year now, and
>never did follow through with my 'CoreWar' ideas which Rod and others
>inspired in me.
Well at least you shouldn't be encumbered by any preconceptions.
>Now, on to *my* ideas.
>First off, I think that Euphoria is very cool the way that it is. Although
>namespace needs to be addressed, programmers need to find the language's
>true paradigm before trying to make it into C or Java.
Nobody here wants it to be in C or Java, but it sure would be nice to
be able to steal what those languages have without the mess they have
it in.
>The infamous construct of
>
> xy = get_position()
> position( xy[1], xy[2] )
>
>should never have been begat. The most Euphorian solution should
>have been for position() to take a sequence as a parameter list
>instead of integers.
>
> xy = get_position()
> position( xy )
Agreed, but this is a matter of programming, not language design. It can
be easily resolved with a little tiny piece of code.
>I am even thinking (though not convinced) that functions and procedures
>should *always* take one parameter, and that '&' should replace ',' as a
>parameter separator.
>
> position( x & y )
Then, you also need to convince yourself that you want to fill in a
sequence before every procedure or function call that you make...I
don't think so! Also, individual variables in a function or procedure
call tend to explicitly document that call if the variable names are
reasonably chosen.
>Although I don't know object orientation very well, I do believe that
>Euphoria should lean in that direction. Mainly polymorphism ( I think that
>that term is correct ) where functions and procedures take values that make
>sense to them.
>
>So, for my ideas to additions:
>
> { line, column } = get_position
>
>does make *some* sense to me. Not wholly in favor, but not against it
>either. I need more convincing.
>
>My other idea, for namespace, is as follows:
>
> --foo.e
>
> include bar.e
>
> import var1, var2, var3 --you could even use a 'type' identifier (such
>as integer, atom, sequence, user-defined) if you *must*
> import constant CONST_I, CONST_II, CONST_III
> import func_one, func_two, proc_three
>
>The import keyword would make these identifiers global to the file. If the
>file was included, then it would be *just* within that file. If the file
>was the main program, then it would be the entire program (after the import
>statements).
>
>The main idea is that the programmer should *know* what is being included >in
>his/her program.
The alternate view, is that a programmer should not have to know what
is in every include to use it. If the functions are well documented and the
variables and functions are uniquely identified by prefixing, No conflict
can occur.
>An alternate would be an 'export' keyword, which would put the onus on the
>include file programmer to decide what should be exported.
Import and export both require study and intimate knowledge of variable
use in a program and in all it's includes. Let us assume that you are a
maintenance programmer called in to fix this program that you have
never seen before. Now also assume that this program is holding up
something critical like your payroll check. Tell me how much time you
want to spend checking out every include before you add an extra
variable to this program. After my first few years in this business, I
came up with the "two o'clock rule". If it is not going to be easy to
figure out at two o'clock in the morning 6 months to two years after
I have written it or last seen it, then I shouldn't write it. If I follow that
rule, then at least the poor devil who isn't me and never has seen it
before will stand a chance of working on it.
>I think that the 'type' declaration can adequately handle structures, but it
>would be longer to program than in other languages.
>
> type employee( sequence empl )
> if length( empl ) = 4 then
> if sequence( empl[1] ) then -- last name, could use string type
> if sequence( empl[2] ) then -- first name, could use string
>type
> if atom( empl[3] ) then -- salary, could use float type
> if integer( empl[4] ) then -- years in service,
>could use type
> return TRUE
> end if
> end if
> end if
> end if
> end if
> return FALSE
>
>This would trap bad structs, but it is cumbersome. There may be a better
>way. Also, if speed is a consideration then it would only apply to dev,
>alpha, or beta programs. Then you should have 'without type_check' if your
>source is stable.
And how is this type of thing going to describe the umpty hundred bit and
byte flags in the average message header, no matter the protocol. They
have to be literally unpacked one by one and then moved into a different
sequence or atom before they can be intelligently maneuvered. And
since the data stream is dynamic, and treacherous, I really need for
type checking to stay on. Can you spell Methuselah...the guy whose
age you will approach while all this gets done.
>I think that routine_id() is okay, but that it should be global. This can
>facilitate OO, and it could even do away with my proposed 'import' or
>'export' keywords.
>
>It should be combined with variable_id() though, even though I would loathe
>to see pointers in Euphoria. It could be useful in overriding scope when
>necessary.
>
>I can forsee a Euphoria in which most 'objects' are defined in separate
>include files that contain functions for working with that object.
>Object-oriented, but not in the non-flexible way that most OO languages are
>defined.
It is hard to disagree with the thoughts here, but until you have specific
ideas, it is hard to comment.
>Sequences are very powerful, and I think that we haven't even scratched the
>surface yet in their utility.
If you look at some of the code in the archive, you will see that this pack
of hens and roosters has done a whole lot of scratching. Granted that
there is a huge amount of power here. The thread on vertical slicing,
otherwise known as columns, is a good beginning for extending the
implicit power of the data description in the sequence to real use in
programs.
Everett L.(Rett) Williams
rett at gvtc.com
4. Re: Euphoria features
- Posted by Jason Gade <jgade at NETZERO.NET>
Nov 12, 1999
-
Last edited Nov 13, 1999
-----Original Message-----
From: Roderick Jackson <rjackson at CSIWEB.COM>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: Friday, November 12, 1999 9:56 PM
Subject: Re: Euphoria features
>Jason Gade wrote:
>[...]
>>First off, I think that Euphoria is very cool the way that it is.
>
>Before going any further, I'll second this observation.
I'm glad that someone agrees!
>
>>The infamous construct of
>>
>> xy = get_position()
>> position( xy[1], xy[2] )
>>
>>should never have been begat. The most Euphorian solution should have
been
>>for position() to take a sequence as a parameter list instead of
integers.
>
>I agree. Alas, it's already been done. BUT... it might not
>necessarily be set in stone. I know Rob has opted to break
>old code before by introducing short-circuting to 'if'
>statements (I *still* don't understand why, but anyway.)
>So, there is somewhat shaky precedent to justify changing
>'position' and any other built-in functions to be more
>orthogonal. Fix it *before* Euphoria takes over the
>programming industry. Note, I'm not necessarily in favor
>of such a change; I'm just thinking about the
>ramifications versus benefits.
>
>>I am even thinking (though not convinced) that functions and
procedures
>>should *always* take one parameter, and that '&' should replace ',' as
a
>>parameter separator.
>
>!!!
>
>You know, this thought had occured to me recently as well,
>but I forced it aside. ("My, what an odd thought you are!
>Shoo, before someone notices you!") But honestly, I think
>it would have worked out very nicely had Euphoria been
>designed that way from the start; '&' in place of ','
>would have been all that was needed. (Well, okay, for
>those of you who would complain about the need to depress
>the shift key to make the '&' character, we can also
>imagine Rob had used ';' instead of '&' for
>concatenation...) Oooh, this thought is starting to
>really demand my attention... I think I'll have to sleep
>on it.
Orthogonal is very good for Euphoria. Repeat after me, "Functions and
Procedures must accept all arguments that make sense for that operation."
>
>>Although I don't know object orientation very well, I do believe that
>>Euphoria should lean in that direction.
>
>It does somewhat already, probably more than any of us
>currently realizes (keep reading....)
>
>>I think that the 'type' declaration can adequately handle structures,
but it
>>would be longer to program than in other languages.
>
>I agree, it works to an extent. The problems most
>people have with that method though are:
>
>1) You'd usually use constants to access the elements,
> and then you run into scoping problems again (and
> I admit, STRUCT37_NAME gets messy...)
>2) It's TOO flexible. You'd have a hard time setting
> up a structure that way that could be used to
> extract records of exactly x bytes in length,
> each consisting of exactly y fields (each being a
> specific number of bytes in length), from a file.
Yes, but one must think "outside of the box" (I *love* that cliche) in
regards to data types. Sequences can both represent structured data and
unstructured data. It is up to the programmer to clear up the ambiguities.
And using constants isn't *that* hard! If you are making up
structures/sequences that are *that* long then they need to be broken up
into smaller bites (no pun); just like functions need to be broken up when
they get too long.
Neither a proc/func nor a struct definition should take up more than say two
pages in an editor. If they do, then they need to be broken down into
smaller units.
The cool thing about sequences is that they can contain other sequences.
And even though it should be simpler in the language, you can always define
sequences in a type for early version error checking.
>
>>I think that routine_id() is okay, but that it should be global.
>
>Mmm, I'm not settled either way with that...
>
>> It should be combined with variable_id() though, even though I
would loathe
>>to see pointers in Euphoria. It could be useful in overriding scope
when
>>necessary.
>
>Well, while this would be useful for a one-line swap function,
>I don't see much point in the pass-by-reference methodology it
>would bring about. Speed's not a concern since Eu usually just
>passes pointers. And I would think the desire to avoid the
>messiness of passing multiple variables through several levels
>could be removed by just redesigning the setup (i.e., use
>local variables rather than parameters.)
>
>I do agree with the 'no pointers' though.
>
>Oh, and I think I'll bring this up; if 'variable_id' ever
>*were* implemented, I'd be willing to bet that it would be
>limited to the current scope.
I see routine_id() and variable_id() more in the way of scope
resolution/object orientation in order to publicize code and variables in
includes. I don't mean to use these constructs to globalize identifiers
that aren't meant to be globalized. Although a person could do so if she
chooses.
>
>>I can forsee a Euphoria in which most 'objects' are defined in
separate
>>include files that contain functions for working with that object.
>>Object-oriented, but not in the non-flexible way that most OO
languages are
>>defined.
>
>You know, I really don't see anything stopping us from
>programming in this manner right now. I guess in a sense,
>many libraries already do that somewhat (I know Picasso
>does, by lumping the routines into POLYGONS.E, TEXTURES.E,
>etc.) I guess no one thinks of it as OOP when achieved in
>such a 'raw' way; I know I often fall into the trap of
>thinking 'object-orientation' = 'elaborate framework'.
I agree with you in that we are not (much) prevented programming in OO
methods. Just a few back-breaking work-arounds that we must deal with, but
that OO is also probably much easier than the published OO libraries in the
archive would have one believe.
>
>>Sequences are very powerful, and I think that we haven't even
scratched the
>>surface yet in their utility.
>
>That's an understatement!
>
>
>Rod Jackson
>
Two ideas that I have had for OO sequences, without adding a lot of overhead
are as follows:
The first element of an object is the instance (from 1 on to ... )
Then, sequence itself contains all of the elements of the object. Different
functions in the include file return or execute various members or methods
of the object. Simplicity within the Euphoria paradigm is the key, and this
would eliminate the assignment or copy constructort.
sequence Dungeon -- New variable
Dungeon = NewDungeon() -- from include file
The NewDungeon() function will return a sequence containing the instance of
the variable, and then all of the elements.
The other idea is to use static sequences within the include file to keep
track of various properties of an object and use the instance variable to
track which element the programmer is referring to. Of course, then the
programmer would have to write her own assignment and copy constructors.
That would bypass the efficiency of sequences, unless the data is static to
the class and not to the instance, of course.
hit_points = GetPlayerHP(rogue)
This would set the object hit_points to whatever GetPlayerHP returns for
that variable.
It doesn't matter if the elements are contained in the object itself or
within static variables indexed by instance within the include file. It is
up to the programmer. As long as the documentation or the code is clearly
written ...
J.
__________________________________________
NetZero - Defenders of the Free World
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html
5. Re: Euphoria features
-----Original Message-----
From: Everett Williams <rett at GVTC.COM>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: Friday, November 12, 1999 10:32 PM
Subject: Re: Euphoria features
>Jason Gade wrote:
>
>>Second, let me say that I have never written any large projects. I
have
>>been planning on writing a Euphoria 'Rogue' clone for nearly a year
now, and
>>never did follow through with my 'CoreWar' ideas which Rod and others
>>inspired in me.
>
>Well at least you shouldn't be encumbered by any preconceptions.
>
>>Now, on to *my* ideas.
>>First off, I think that Euphoria is very cool the way that it is.
Although
>>namespace needs to be addressed, programmers need to find the
language's
>>true paradigm before trying to make it into C or Java.
>
>Nobody here wants it to be in C or Java, but it sure would be nice to
>be able to steal what those languages have without the mess they have
>it in.
I don't have a problem with stealing from these languages. Especially a
"standard library".
>
>>The infamous construct of
>>
>> xy = get_position()
>> position( xy[1], xy[2] )
>>
>>should never have been begat. The most Euphorian solution should
>>have been for position() to take a sequence as a parameter list
>>instead of integers.
>>
>> xy = get_position()
>> position( xy )
>
>Agreed, but this is a matter of programming, not language design. It
can
>be easily resolved with a little tiny piece of code.
>
>>I am even thinking (though not convinced) that functions and
procedures
>>should *always* take one parameter, and that '&' should replace ',' as
a
>>parameter separator.
>>
>> position( x & y )
>
>Then, you also need to convince yourself that you want to fill in a
>sequence before every procedure or function call that you make...I
>don't think so! Also, individual variables in a function or procedure
>call tend to explicitly document that call if the variable names are
>reasonably chosen.
I don't quite understand what you mean here by "fill in a sequence".
>
>>Although I don't know object orientation very well, I do believe that
>>Euphoria should lean in that direction. Mainly polymorphism ( I think
that
>>that term is correct ) where functions and procedures take values that
make
>>sense to them.
>>
>>So, for my ideas to additions:
>>
>> { line, column } = get_position
>>
>>does make *some* sense to me. Not wholly in favor, but not against it
>>either. I need more convincing.
>>
>>My other idea, for namespace, is as follows:
>>
>> --foo.e
>>
>> include bar.e
>>
>> import var1, var2, var3 --you could even use a 'type' identifier
(such
>>as integer, atom, sequence, user-defined) if you *must*
>> import constant CONST_I, CONST_II, CONST_III
>> import func_one, func_two, proc_three
>>
>>The import keyword would make these identifiers global to the file.
If the
>>file was included, then it would be *just* within that file. If the
file
>>was the main program, then it would be the entire program (after the
import
>>statements).
>>
>>The main idea is that the programmer should *know* what is being
included >in his/her program.
>
>The alternate view, is that a programmer should not have to know what
>is in every include to use it. If the functions are well documented
and the
>variables and functions are uniquely identified by prefixing, No
conflict
>can occur.
Just like a programmer must declare her variables I do think that a
programmer should know which procs/functions are included in her program. I
don't mean that she needs to know what procs/functions are called by
included functions, just that of course she should declare the ones she is
using.
I kinda agree with linking names to includes by prefixing, but it should be
voluntary.
>>I think that the 'type' declaration can adequately handle structures,
but it
>>would be longer to program than in other languages.
>>
>> type employee( sequence empl )
>> if length( empl ) = 4 then
>> if sequence( empl[1] ) then -- last name, could use string
type
>> if sequence( empl[2] ) then -- first name, could use
string
>>type
>> if atom( empl[3] ) then -- salary, could use float
type
>> if integer( empl[4] ) then -- years in
service,
>>could use type
>> return TRUE
>> end if
>> end if
>> end if
>> end if
>> end if
>> return FALSE
>>
>>This would trap bad structs, but it is cumbersome. There may be a
better
>>way. Also, if speed is a consideration then it would only apply to
dev,
>>alpha, or beta programs. Then you should have 'without type_check' if
your
>>source is stable.
>
>And how is this type of thing going to describe the umpty hundred bit
and
>byte flags in the average message header, no matter the protocol. They
>have to be literally unpacked one by one and then moved into a
different
>sequence or atom before they can be intelligently maneuvered. And
>since the data stream is dynamic, and treacherous, I really need for
>type checking to stay on. Can you spell Methuselah...the guy whose
>age you will approach while all this gets done.
>
If you have more than a few members of an object, then you should break it
down into sub-objects. Byte flags would have to be checked by code, like
almost any other language out there.
No language can prevent poor programming, just make it easier to program
well.
>>I think that routine_id() is okay, but that it should be global. This
can
>>facilitate OO, and it could even do away with my proposed 'import' or
>>'export' keywords.
>>
>>It should be combined with variable_id() though, even though I would
loathe
>>to see pointers in Euphoria. It could be useful in overriding scope
when
>>necessary.
>>
>>I can forsee a Euphoria in which most 'objects' are defined in
separate
>>include files that contain functions for working with that object.
>>Object-oriented, but not in the non-flexible way that most OO
languages are
>>defined.
>
>It is hard to disagree with the thoughts here, but until you have
specific
>ideas, it is hard to comment.
>
>>Sequences are very powerful, and I think that we haven't even
scratched the
>>surface yet in their utility.
>
>If you look at some of the code in the archive, you will see that this
pack
>of hens and roosters has done a whole lot of scratching. Granted that
>there is a huge amount of power here.
Vertical slicing is needed; I just haven't thought about it much myself yet.
>The thread on vertical slicing,
>otherwise known as columns, is a good beginning for extending the
>implicit power of the data description in the sequence to real use in
>programs.
One of the points I think of Euphoria is getting away from rigid data
description.
>
>Everett L.(Rett) Williams
>rett at gvtc.com
>
J.
__________________________________________
NetZero - Defenders of the Free World
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html
6. Re: Euphoria features
> >Jason Gade wrote:
> >
> >Then, you also need to convince yourself that you want to fill in a
> >sequence before every procedure or function call that you make...I
> >don't think so! Also, individual variables in a function or procedure
> >call tend to explicitly document that call if the variable names are
> >reasonably chosen.
>
>I don't quite understand what you mean here by "fill in a sequence".
In other words, assign values to the elements of a sequence. The
concatenation is a cute trick. but actually harder to read than comma
delimiters. I am not against it, I just can't see the purpose. On the
other hand, orthogonality between arguments of related functions
is a meaningful goal. We just don't have it and changing it at this
point would break a lot of code. If you want it, you can just build an
include with wrapper functions for the current functions that are not
orthogonal.
> >>The main idea is that the programmer should *know* what is being
>included >in his/her program.
> >
> >The alternate view, is that a programmer should not have to know what
> >is in every include to use it. If the functions are well documented
>and the
> >variables and functions are uniquely identified by prefixing, No
>conflict
> >can occur.
>
>Just like a programmer must declare her variables I do think that a
>programmer should know which procs/functions are included in her program. >I
>don't mean that she needs to know what procs/functions are called by
>included functions, just that of course she should declare the ones she is
>using. I kinda agree with linking names to includes by prefixing, but it
>should be voluntary.
I agree with the voluntary part. The prefixes would be optional and would
only apply to "exposed" items anyway, so the load on the interpreter
would be little different than it already is. Something of the form
xyz include foo.e or include foo.e name xyz
without the prefix would be
include foo.e in either case
As to knowing and declaring functions, a library may contain
literally hundreds of functions and the programmer may need all or
only a few. Having to go back and declare each function before it
can be used is an unnecessary hassle. The interpreter can see
which functions are used and proceed on that basis. If you can
describe some advantage in declaring those functions, I will
reconsider the point.
>
>If you have more than a few members of an object, then you should break it
>down into sub-objects. Byte flags would have to be checked by code, like
>almost any other language out there.
>
>No language can prevent poor programming, just make it easier to program
>well.
In many, if not most programming situations these days, the data that
we get to use is determined externally to our program or series of
programs almost by definition. I know how to check bit and byte codes,
but I don't have to have the extra overhead of pulling individual, non-word-
aligned bytes out of a data structure or bits out of a byte if adequate
built in types are available. With no data type smaller than 32 bits in this
language, a lot of code is generated in breaking out and reassembling
bit and byte values. Much of that code makes no logical sense. It is
just transforming from one set of coordinates to another...the type of
thing that a compiler or interpreter optimizes very well.
When I do a get, depending on the input, I may obtain a sequence of
bits, bytes, and words of arbitrary complexity. However many pieces
that I break that down into, I had better be able to tie all those pieces
together into a single structure for the IO function to populate. If I must
parse every stitch of data coming in, the overhead will fast get out of
hand. Much data is defined by standards and interface documentation
that is outside of any language. If I cannot with some efficiency
handle whatever data format is thrown at me, I will again spend
inordinate amounts of time and very "gothic" code handling these
situations.
>One of the points I think of Euphoria is getting away from rigid data
>description.
As long as we are within Euphoria and we, the programmers get to
define all the data for both inputs and outputs, you are right. I wish that
I could say that I have worked on a lot of projects that are that
self-contained. Unfortunately, tain't so.
Everett L.(Rett) Williams
rett at gvtc.com
7. Re: Euphoria features
Jason Gade wrote:
>Yes, but one must think "outside of the box" (I *love* that cliche) in
>regards to data types. Sequences can both represent structured data and
>unstructured data. It is up to the programmer to clear up the ambiguities.
>And using constants isn't *that* hard! If you are making up
>structures/sequences that are *that* long then they need to be broken up
>into smaller bites (no pun); just like functions need to be broken up when
>they get too long.
If I have two or more files with the same field name in them, but in different
positions, constants just became a major source of difficult to avoid
error. Now, I have to think up two or more names for the identical field.
This is not only confusing, it is just flat wrong. Prefixing solves the
problem with no violence to content or meaning.
>
>Neither a proc/func nor a struct definition should take up more than say two
>pages in an editor. If they do, then they need to be broken down into
>smaller units.
Agreed, but the structures must be nested, or I will have to piece them
together at the time that they are used together, another code-expensive
and error prone task that has no purpose that I can think of.
>The cool thing about sequences is that they can contain other sequences.
>And even though it should be simpler in the language, you can always define
>sequences in a type for early version error checking.
Agreed, but remember the overhead problem. Type checking can be very
expensive outside of built in types...and even with built in types, if it is
over-used.
>Two ideas that I have had for OO sequences, without adding a lot of overhead
>are as follows:
>
>The first element of an object is the instance (from 1 on to ... )
>
>Then, sequence itself contains all of the elements of the object. Different
>functions in the include file return or execute various members or methods
>of the object. Simplicity within the Euphoria paradigm is the key, and this
>would eliminate the assignment or copy constructort.
>
> sequence Dungeon -- New variable
> Dungeon = NewDungeon() -- from include file
>
>The NewDungeon() function will return a sequence containing the instance of
>the variable, and then all of the elements.
>
>The other idea is to use static sequences within the include file to keep
>track of various properties of an object and use the instance variable to
>track which element the programmer is referring to. Of course, then the
>programmer would have to write her own assignment and copy constructors.
>That would bypass the efficiency of sequences, unless the data is static to
>the class and not to the instance, of course.
>
> hit_points = GetPlayerHP(rogue)
>
>This would set the object hit_points to whatever GetPlayerHP returns for
>that variable.
>
>It doesn't matter if the elements are contained in the object itself or
>within static variables indexed by instance within the include file. It is
>up to the programmer. As long as the documentation or the code is clearly
>written ...
Can't begin to say that I understand exactly all of this, but I think that it
implies dynamic use of the interpreter to execute the elements of an
instance(did I get anywhere close to that?). We don't currently have that
capability, though I can think of 101 uses for it.
Everett L.(Rett) Williams
rett at gvtc.com
8. Re: Euphoria features
From: Everett Williams <rett at GVTC.COM>
Subject: Re: Euphoria features
<snip Jason's type check routine>
> And how is this type of thing going to describe the umpty hundred bit
> and
> byte flags in the average message header, no matter the protocol. They
> have to be literally unpacked one by one and then moved into a different
> sequence or atom before they can be intelligently maneuvered. And
> since the data stream is dynamic, and treacherous, I really need for
> type checking to stay on. Can you spell Methuselah...the guy whose
> age you will approach while all this gets done.
It appears that at least two people are laboring under a misconception
of exactly what type() does.
Bear in mind that a type() failure can _only_ cause an immediate abend. Very
useful when debugging, but worse than useless in a production program.
Surely I don't have to explain this further.
If type() could modify the passed parameter according to some rules you set
up, e.g: ask the clumsy typist to try again, it would be much more useful.
If it were faster, that wouldn't hurt either.
Irv
9. Re: Euphoria features
Jason Gade writes:
> I am even thinking (though not convinced) that functions
> and procedures should *always* take one parameter, and
> that '&' should replace ',' as a parameter separator.
You might be interested to know that for the first few months
of Euphoria's existence, functions and procedures *did*
only take one parameter. (I was *really* minimalist back then
...long before you guys corrupted me).
Instead of passing multiple arguments as:
foo(a, b, c)
You had to do it as:
foo({a,b,c})
procedure foo(object x) referenced its parameters using
subscripts as x[1], x[2], and x[3].
Eventually I broke down and allowed multiple named parameters.
The readability of:
procedure foo(object apples, object oranges, object bananas)
is much better than:
procedure foo(object x)
object apples, oranges, bananas
apples = x[1]
oranges = x[2]
bananas = x[3]
...
and it eliminates the overhead of {,,} before the call,
and three subscript operations inside the routine.
(Back then "object" was the *only* type,
for-loops didn't exist, ... the good old days!)
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
10. Re: Euphoria features
On Sat, 13 Nov 1999 08:37:33 -0500, Irv Mullins <irv at ELLIJAY.COM> wrote:
>From: Everett Williams <rett at GVTC.COM>
>Subject: Re: Euphoria features
><snip Jason's type check routine>
>
>> And how is this type of thing going to describe the umpty hundred bit
>> and
>> byte flags in the average message header, no matter the protocol. They
>> have to be literally unpacked one by one and then moved into a different
>> sequence or atom before they can be intelligently maneuvered. And
>> since the data stream is dynamic, and treacherous, I really need for
>> type checking to stay on. Can you spell Methuselah...the guy whose
>> age you will approach while all this gets done.
>
>It appears that at least two people are laboring under a misconception
>of exactly what type() does.
>
>Bear in mind that a type() failure can _only_ cause an immediate abend. Very
>useful when debugging, but worse than useless in a production program.
>Surely I don't have to explain this further.
>
>If type() could modify the passed parameter according to some rules you set
>up, e.g: ask the clumsy typist to try again, it would be much more useful.
>If it were faster, that wouldn't hurt either.
>
>Irv
I stand corrected. I must have been thinking of a real world where error
recovery is possible. Still, one can always hope And by the way, your
age is showing. I haven't "heard" anyone use the term "abend" since I
worked my last dump on an IBM mainframe. Seems like in COBOL
programs, D37s' and E37's were the most common. Been a long time.
Working failure codes on PC's is a non-rewarding process, since I have
access to so little of the object code, much less the source.
Everett L.(Rett) Williams
rett at gvtc.com
11. Re: Euphoria features
Robert wrote:
> procedure foo(object apples, object oranges, object bananas)
>
>is much better than:
>
> procedure foo(object x)
> object apples, oranges, bananas
> apples = x[1]
> oranges = x[2]
> bananas = x[3]
> ...
???
You mean nobody just used:
procedure foo (object fruit)
...
x = fruit[APPLES] -- don't bother with intermediate variables
...
(There, that looks a whole lot less cumbersome.)
While it might be less efficient, and require extra
keystrokes, and run into the global-constant-problem
again, surely it... well, um, what I mean to say is...
hold on, I know there's a point to be made here....
>(Back then "object" was the *only* type,
>for-loops didn't exist, ... the good old days!)
!!!
So there was NO type-checking at all? I'm shocked!
Well, frankly I think the introduction of types
(and the elegant implementation of user-defined
types) was a plus. I really can't see how you could
verify user input without it:
if (integer (x)) then
I won't even *touch* the lack of for-loops...
Rod Jackson
12. Re: Euphoria features
----- Original Message -----
From: Roderick Jackson <rjackson at CSIWEB.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Saturday, November 13, 1999 6:15 PM
Subject: Re: Euphoria features
> >(Back then "object" was the *only* type,
> >for-loops didn't exist, ... the good old days!)
>
> !!!
>
> So there was NO type-checking at all? I'm shocked!
> Well, frankly I think the introduction of types
> (and the elegant implementation of user-defined
> types) was a plus. I really can't see how you could
> verify user input without it:
>
> if (integer (x)) then
Another language i use has *zero* type checking, other than internally in
it's functions/procedures and binary vars (which i can use like sequences),
so if i want to know what is in a var, i use :
if ( x isin %alphabet )
if ( x !isin %numset )
if ( x isin %punctset )
or i pass it to a math function,, $round() will round off trailing
non-numerals, for instance. You don't need types to write code. It's only
occasionally handy in debugging when you have no control over what may be in
the variable you want to look at.
> I won't even *touch* the lack of for-loops...
I still want goto's. And i want to be able to goto a variable's contents
too, as if it were a form of case statement.
whatisthis {
goto $1
:apple return fruit
:potato return vegetable
}
( it returns $null if $1 is not a target )
Kat,
still looking for the ideal language.
13. Re: Euphoria features
Kat wrote:
>From: Roderick Jackson
>Subject: Re: Euphoria features
>
The part about types is just too turned around to even try to respond to.
>
>I still want goto's. And i want to be able to goto a variable's contents
>too, as if it were a form of case statement.
Can you spell spaghetti. Have you ever seen spaghetti code. Have you
ever tried to maintain code written with even moderate amounts of goto's
in it? Yeah, yeah...pipe down peanut gallery... I know you are going to
say something about programmer discipline, but nobody has ever shown
me a situation where a "general goto", that is one not strictly limited in
scope and function, is even desirable, much less necessary. The single
exception is in exit from error traps, but since we have no error or other
event traps, not even that is under discussion here. Goto's also cause
major problems in scope control. Consider a direct branch from about
four levels down in function code inside a routine in an include to some
point at the main level of the include or even outside the include or about
four levels down in some other function heirarchy in the same include.
>
>whatisthis {
>goto $1
>:apple return fruit
>:potato return vegetable
>}
>( it returns $null if $1 is not a target )
Unless I have entirely misunderstood this example, it implies instancing
or re-entering the interpreter to "execute" a variable. I call this a dynamic
or self-modifying program. This is what the data/code equivalence of
LISP does. There is enormous power and a great deal of peril in this
simple, but profound idea. It would instantly make Euphoria into an
AI(artificial intelligence) language, and allow truly non-predictable
outcomes from a programming process. Learning becomes a possible
property of a program written with this type of recursive execution.
I for one would love it, but it truly would alter the whole aspect of the
language. It would make Euphoria extremely useful for AI without
requiring it to acquire too many of the business oriented changes
(namespace still needs to be fixed and sequence handling needs to
be made symmetric). It might even appeal to the minimalist that
is responsible for this whole shebang. The only other thing that it
would probably demand would be a strengthening of the string
handling capabilities of Euphoria since a great deal of the
programming effort would be directly in handling the strings that
represent the new programs to be executed.
>Kat,
>still looking for the ideal language.
I have referred indirectly to this concept several times previously, but
there were no bites, so I dropped it. Thankyou for provoking me to
attack it again. The concept is implicit if not simply attained in any
interpreter.
Everett L.(Rett) Williams
rett at gvtc.com
14. Re: Euphoria features
Kat wrote:
>
> >I still want goto's. And i want to be able to goto a variable's contents
> >too, as if it were a form of case statement.
I thought about that the other day, and _methinx_ we may already have goto's,
just in a different form... calling other procedures.
I mean, sure, I liked the way in BASIC where I could say 'goto (line) 10' but it
wasn't all that great to me. in Euphoria, all you need to say is
if <something screwed up happens> then
<procedure()> else
<whatever you feel like>
At least thats how I used goto's in BASIC...
So goto's aren't really needed anymore... :)
--"LEVIATHAN"
15. Re: Euphoria features
----- Original Message -----
From: LEVIATHAN <leviathan at USWEST.NET>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Sunday, November 14, 1999 5:53 AM
Subject: Re: Euphoria features
> Kat wrote:
>
> >
> > >I still want goto's. And i want to be able to goto a variable's
contents
> > >too, as if it were a form of case statement.
>
> I thought about that the other day, and _methinx_ we may already have
goto's,
> just in a different form... calling other procedures.
That's not the same, and calling procedures adds time to your code. Lots of
overhead in compiled languages, but i don't know how Eu does it.
> I mean, sure, I liked the way in BASIC where I could say 'goto (line) 10'
but it
> wasn't all that great to me. in Euphoria, all you need to say is
>
> if <something screwed up happens> then
> <procedure()> else
> <whatever you feel like>
That's not quite how i use gotos. For instance, if i want a better form of
addy mask on irc, better than *!*ident at *.bellsouth.net, i use an if to see
if it's a bellsouth mask, then i skip all the other tests for the other 50
nets that use other location codes in their masks. The procedure you'd call
is what is on the other side of my goto, all the code hasto execute it. In
your example, i'd have elses stacked up testing for each net, and probably
a test at the bottom involving global vars to test if i should call the
procedure again or not.
What about this:
<begin imaginary code>
pokedata {
if ( $1 is hex ) { convert to dec here | goto poke }
if ( $1 is bin ) { convert to dec here | goto poke }
if ( $1 is octal ) { convert to dec here }
:poke
do the poke here
}
Now, what if there were 500 if statements there? Do you want to write them?
I don't. In that example, there's little chance of encountering 500 number
bases, but there are more than 500 names of people/objects , and more than
500 stars, and more than 500 species, etc ( altho i grant that there are
better ways of handling the getting the qualities of 500 species than an
case/if tree).
The preceeding example can be restated as :
pokedata {
case $type($1) of {
hex : convert to dec
bin : convert to dec
octal : convert to dec
}
poke it here
}
Imho, there is little difference in the reulting machine code from that case
statement and this goto:
pokedata {
goto $getbase($1)
:hex | convert to dec | goto poke
:bin | convert to dec | goto poke
:octal | convert to dec
}
:poke
poke it here
}
So the words used in the scripting language *can* have little to do with
that the interpreter/compiler makes in the machine code. The language exists
only to make the writing of code easier, so we don't need to remember all
the cpu op codes. If it's easier for you to use the case statement, do so.
If it's better for you to use the if statement, then do that. But since the
machine code may be identical in both cases, why would the language be
designed to restrict which we use? You drive a Ford, someone else drives a
Chevy or Nissan or Kia or Whatever.
Kat
16. Re: Euphoria features
Kat wrote:
> > Kat wrote:
> >
> > >
> > > >I still want goto's. And i want to be able to goto a variable's
> contents
> > > >too, as if it were a form of case statement.
> >
> > I thought about that the other day, and _methinx_ we may already have
> goto's,
> > just in a different form... calling other procedures.
>
> That's not the same, and calling procedures adds time to your code. Lots of
> overhead in compiled languages, but i don't know how Eu does it.
>
<nod> Thats true... but thats how it can be in Euphoria... I may have not
thought about the overhead to procedure calling, as I may have thought there is
no overhead to procedure calling. If there is, I stand corrected.
>
> > I mean, sure, I liked the way in BASIC where I could say 'goto (line) 10'
> but it
> > wasn't all that great to me. in Euphoria, all you need to say is
> >
> > if <something screwed up happens> then
> > <procedure()> else
> > <whatever you feel like>
>
> That's not quite how i use gotos. For instance, if i want a better form of
> addy mask on irc, better than *!*ident at *.bellsouth.net, i use an if to see
> if it's a bellsouth mask, then i skip all the other tests for the other 50
> nets that use other location codes in their masks. The procedure you'd call
> is what is on the other side of my goto, all the code hasto execute it. In
> your example, i'd have elses stacked up testing for each net, and probably
> a test at the bottom involving global vars to test if i should call the
> procedure again or not.
>
Hrm, then why not a procedure to filter out the masks? take a file of all the
people there on the channel, along with their IP address, and filter it down for
bellsouth masks? It'd essentially be the same thing... sorta like this:
<pseudo-code>
if mask != "bellsouth.net" then <procedure that reads the next line from the
file>()
else <procedure to do whatever you wanted with it, perhaps output it to another
file>()
</pseudo-code>
Then, after the procedure is done, call the above back to continue processing
it.
Essentially the same, no?
>
> What about this:
> <begin imaginary code>
> pokedata {
> if ( $1 is hex ) { convert to dec here | goto poke }
> if ( $1 is bin ) { convert to dec here | goto poke }
> if ( $1 is octal ) { convert to dec here }
> :poke
> do the poke here
> }
>
> Now, what if there were 500 if statements there? Do you want to write them?
> I don't. In that example, there's little chance of encountering 500 number
> bases, but there are more than 500 names of people/objects , and more than
> 500 stars, and more than 500 species, etc ( altho i grant that there are
> better ways of handling the getting the qualities of 500 species than an
> case/if tree).
<nod> Thats how goto's work... they (in my experience) will go back and help in
redirecting the processing, so that there is no need for 500 statements to test
if something is true, just go back and test the next, no?
>
>
> The preceeding example can be restated as :
> pokedata {
> case $type($1) of {
> hex : convert to dec
> bin : convert to dec
> octal : convert to dec
> }
> poke it here
> }
>
> Imho, there is little difference in the reulting machine code from that case
> statement and this goto:
> pokedata {
> goto $getbase($1)
> :hex | convert to dec | goto poke
> :bin | convert to dec | goto poke
> :octal | convert to dec
> }
> :poke
> poke it here
> }
>
<nod> True, except that in the case statement, it isn't told to explicitly go to
the next, where the goto statement says exactly where to go. True?
>
> So the words used in the scripting language *can* have little to do with
> that the interpreter/compiler makes in the machine code. The language exists
> only to make the writing of code easier, so we don't need to remember all
> the cpu op codes. If it's easier for you to use the case statement, do so.
> If it's better for you to use the if statement, then do that. But since the
> machine code may be identical in both cases, why would the language be
> designed to restrict which we use? You drive a Ford, someone else drives a
> Chevy or Nissan or Kia or Whatever.
>
Agreed, yet we do want to be careful what we ask for, as it may only cause bloat
to Euphoria. If a case statement and a goto statement are relatively the same,
then whats the use of implementing goto?
--"LEVIATHAN"
17. Re: Euphoria features
This goto request reminds me of some of BASIC's kludges.
INPUT A
on A goto 1, 2, 55, 312
I despise jumping around a program in such a disorderly fashion.
(IMO): if this were to be implemented into Euphoria, it would
greatly degrade the simplicity that everything is linear or
calling a function/procedure. With GOTO, your second line of
code can be abort(0) yet still have a fully functioning program.
YUK.
Try this on for size.
GOTO Start
abort(0)--never used.
Start:
puts(1, "The above was easily bypassed and is useless.")
GOTO's are one of the strongest components of spaghetti code.
Without goto, creating spachetti code is more difficult.
Lucius L. Hilley III
lhilley at cdc.net lucius at ComputerCafeUSA.com
+----------+--------------+--------------+----------+
| Hollow | ICQ: 9638898 | AIM: LLHIII | Computer |
| Horse +--------------+--------------+ Cafe' |
| Software | http://www.cdc.net/~lhilley | USA |
+----------+-------+---------------------+----------+
| http://www.ComputerCafeUSA.com |
+--------------------------------+
----- Original Message -----
From: Kat <KSMiTH at PELL.NET>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Saturday, November 13, 1999 7:58 PM
Subject: Re: Euphoria features
> ---------------------- Information from the mail
header -----------------------
> Sender: Euphoria Programming for MS-DOS
<EUPHORIA at LISTSERV.MUOHIO.EDU>
> Poster: Kat <KSMiTH at PELL.NET>
> Subject: Re: Euphoria features
> --------------------------------------------------------------------------
-----
>
> ----- Original Message -----
> From: Roderick Jackson <rjackson at CSIWEB.COM>
> To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
> Sent: Saturday, November 13, 1999 6:15 PM
> Subject: Re: Euphoria features
>
>
> > >(Back then "object" was the *only* type,
> > >for-loops didn't exist, ... the good old days!)
> >
> > !!!
> >
> > So there was NO type-checking at all? I'm shocked!
> > Well, frankly I think the introduction of types
> > (and the elegant implementation of user-defined
> > types) was a plus. I really can't see how you could
> > verify user input without it:
> >
> > if (integer (x)) then
>
> Another language i use has *zero* type checking, other than internally in
> it's functions/procedures and binary vars (which i can use like
sequences),
> so if i want to know what is in a var, i use :
> if ( x isin %alphabet )
> if ( x !isin %numset )
> if ( x isin %punctset )
> or i pass it to a math function,, $round() will round off trailing
> non-numerals, for instance. You don't need types to write code. It's only
> occasionally handy in debugging when you have no control over what may be
in
> the variable you want to look at.
>
> > I won't even *touch* the lack of for-loops...
>
> I still want goto's. And i want to be able to goto a variable's contents
> too, as if it were a form of case statement.
>
> whatisthis {
> goto $1
> :apple return fruit
> :potato return vegetable
> }
> ( it returns $null if $1 is not a target )
>
> Kat,
> still looking for the ideal language.
>
18. Re: Euphoria features
----- Original Message -----
From: LEVIATHAN <leviathan at USWEST.NET>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Sunday, November 14, 1999 2:34 PM
Subject: Re: Euphoria features
> Kat wrote:
>
> >
> > That's not quite how i use gotos. For instance, if i want a better form
of
> > addy mask on irc, better than *!*ident at *.bellsouth.net, i use an if to
see
> > if it's a bellsouth mask, then i skip all the other tests for the other
50
> > nets that use other location codes in their masks. The procedure you'd
call
> > is what is on the other side of my goto, all the code hasto execute it.
In
> > your example, i'd have elses stacked up testing for each net, and
probably
> > a test at the bottom involving global vars to test if i should call the
> > procedure again or not.
> >
>
> Hrm, then why not a procedure to filter out the masks? take a file of all
the
> people there on the channel, along with their IP address, and filter it
down for
> bellsouth masks? It'd essentially be the same thing... sorta like this:
> <pseudo-code>
> if mask != "bellsouth.net" then <procedure that reads the next line from
the
> file>()
> else <procedure to do whatever you wanted with it, perhaps output it to
another
> file>()
> </pseudo-code>
>
> Then, after the procedure is done, call the above back to continue
processing
> it.
>
> Essentially the same, no?
No, that's not what i was doing. Instead of this in a nicklist popup:
mode # +b $address($$1,4)
i use this:
mode # +b $newmask($address($$1,4))
which i have written to notice the location codes in some addys, and leave
those in the mask, while blocking all the other variable parts of the dialup
mask. It's handy in bans, akicks, identifying clones better, ident
variables, etc. Like this:
//echo -s $newmask(nick!ident at user-38ldh1q.dialup.mindspring.com,4)
*!* at user-*ldh*.dialup.mindspring.com
( the ldh is the location )
> > What about this:
> > <begin imaginary code>
> > pokedata {
> > if ( $1 is hex ) { convert to dec here | goto poke }
> > if ( $1 is bin ) { convert to dec here | goto poke }
> > if ( $1 is octal ) { convert to dec here }
> > :poke
> > do the poke here
> > }
> >
> > Now, what if there were 500 if statements there? Do you want to write
them?
> > I don't. In that example, there's little chance of encountering 500
number
> > bases, but there are more than 500 names of people/objects , and more
than
> > 500 stars, and more than 500 species, etc ( altho i grant that there are
>
> > better ways of handling the getting the qualities of 500 species than an
> > case/if tree).
>
> <nod> Thats how goto's work... they (in my experience) will go back and
help in
> redirecting the processing, so that there is no need for 500 statements to
test
> if something is true, just go back and test the next, no?
My code didn't go back, it went forwards. Loop commands go back "better", in
coding style, anyhow. I didn't give a looping example.
> > The preceeding example can be restated as :
> > pokedata {
> > case $type($1) of {
> > hex : convert to dec
> > bin : convert to dec
> > octal : convert to dec
> > }
> > poke it here
> > }
> >
> > Imho, there is little difference in the reulting machine code from that
case
> > statement and this goto:
> > pokedata {
> > goto $getbase($1)
> > :hex | convert to dec | goto poke
> > :bin | convert to dec | goto poke
> > :octal | convert to dec
> > }
> > :poke
> > poke it here
> > }
> >
>
> <nod> True, except that in the case statement, it isn't told to explicitly
go to
> the next, where the goto statement says exactly where to go. True?
The compiler/interpreter will insert the opcode for a jump to the end of the
case block, so you don't need to write it. Or for those compilers making a
procedure out of everything, a RetFmSub. In both examples above, the poke is
executed after the input is proofread.
> >
> > So the words used in the scripting language *can* have little to do with
> > that the interpreter/compiler makes in the machine code. The language
exists
> > only to make the writing of code easier, so we don't need to remember
all
> > the cpu op codes. If it's easier for you to use the case statement, do
so.
> > If it's better for you to use the if statement, then do that. But since
the
> > machine code may be identical in both cases, why would the language be
> > designed to restrict which we use? You drive a Ford, someone else drives
a
> > Chevy or Nissan or Kia or Whatever.
> >
>
> Agreed, yet we do want to be careful what we ask for, as it may only cause
bloat
> to Euphoria. If a case statement and a goto statement are relatively the
same,
> then whats the use of implementing goto?
`Cause not everything is easiest in a case block,, in some cases, it is as
bad as a stack of else blocks. I saw a case statement that filled 32K once
written by someone trying to make all his code inline and not call
procedures. ewwww.
Kat
19. Re: Euphoria features
----- Original Message -----
From: Lucius L. Hilley III <lhilley at CDC.NET>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Sunday, November 14, 1999 1:32 PM
Subject: Re: Euphoria features
> This goto request reminds me of some of BASIC's kludges.
> INPUT A
> on A goto 1, 2, 55, 312
>
> I despise jumping around a program in such a disorderly fashion.
That's disorderly? How?? Can you replace that one line with another that is
less "disorderly" and yet does the same function? I mean other than the line
i gave, which is "goto A". 
You would have loved the basic compiler i wrote, you could goto a target in
the middle of a line of code. hehe
> (IMO): if this were to be implemented into Euphoria, it would
> greatly degrade the simplicity that everything is linear or
> calling a function/procedure. With GOTO, your second line of
> code can be abort(0) yet still have a fully functioning program.
> YUK.
>
> Try this on for size.
>
> GOTO Start
> abort(0)--never used.
>
> Start:
> puts(1, "The above was easily bypassed and is useless.")
Then why did you write it that way? <blink>
> GOTO's are one of the strongest components of spaghetti code.
> Without goto, creating spachetti code is more difficult.
Hmm,, "more difficult" means not impossible... Maybe we should remove all
the other ways of writing spagetti code too, cause someone might, someday
and somewhere, write something you can't read? Maybe local vars should be
eliminated, cause they can be used over and over again in different
functions. Holy cow!,, the word "clothes" , sheesh, that could mean almost
*anything* in the way of apparel!!!, brb, i am going to write a strongly
worded email to Websters!!
Kat
20. Re: Euphoria features
Whoo... :)
32K case blocks AREN'T good practice, and probably calling procedures would have
been better. But then again, that isn't Euphoria; perhaps C or QB would have a
_larger_ overhead for calling procedures...
But my final point i'm trying to get at is that goto really shouldn't go into
the interpreter, as a form of 'goto' already exists. Sure, it may not goto a
line or do really spashul things like it may have in other languages, but thats
how it is, I suppose.
For the greater purpose, calling procedures in case statements is how I have
usually used goto's, and usually how i've seen goto's used. Maybe i'm reeeally
shortsided, so sue me. 
But for the Euphoria core interpreter, it shouldn't
be, in my opinion. Yours may be different, thats kewl, but for now, i'm done
defending my position :)
(FYI, this is the most I've defended my position on something on this list :)
--"LEVIATHAN"
21. Re: Euphoria features
>> You would have loved the basic compiler i wrote, you could goto a target
>> in the middle of a line of code. hehe
Then why don't you write a basic compiler in Euphoria and share your code
with the list so we can learn something about how to write a compiler ?
22. Re: Euphoria features
Bernie Ryan wrote:
>>> You would have loved the basic compiler i wrote, you could goto a target
>>> in the middle of a line of code. hehe
>
>Then why don't you write a basic compiler in Euphoria and share your code
>with the list so we can learn something about how to write a compiler ?
Actually Kat, if you *did* port your compiler to Euphoria,
I think a lot of folks, myself included, would be interested
and appreciative. Even if it is a BASIC compiler.
Rod Jackson
23. Re: Euphoria features
----- Original Message -----
From: Roderick Jackson <rjackson at CSIWEB.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Sunday, November 14, 1999 5:06 PM
Subject: Re: Euphoria features
> Bernie Ryan wrote:
> >>> You would have loved the basic compiler i wrote, you could goto a
target
> >>> in the middle of a line of code. hehe
> >
> >Then why don't you write a basic compiler in Euphoria and share your code
> >with the list so we can learn something about how to write a compiler ?
>
> Actually Kat, if you *did* port your compiler to Euphoria,
> I think a lot of folks, myself included, would be interested
> and appreciative. Even if it is a BASIC compiler.
Well, it was on the C64, and i don't know if i can even read those floppys
anymore. Why would you want 6502 machine code ported to Eu?
Kat
24. Re: Euphoria features
- Posted by Bernie Ryan <bwryan at PCOM.NET>
Nov 14, 1999
-
Last edited Nov 15, 1999
On Sun, 14 Nov 1999 18:41:21 -0600, Kat <KSMiTH at PELL.NET> wrote:
>Well, it was on the C64, and i don't know if i can even read those floppys
>anymore. Why would you want 6502 machine code ported to Eu?
You could produce a basic compiler that outputs 80x86 machine code.
Everyone on the list would then learn how you do the parsing, error
checking, optimization and how to emit the machine code for the various
constructs. Maybe you could even show us how to to do garbage collection.
I think that would would be very educational.
25. Re: Euphoria features
- Posted by Jason Gade <jgade at NETZERO.NET>
Nov 14, 1999
-
Last edited Nov 15, 1999
-----Original Message-----
From: Irv Mullins <irv at ELLIJAY.COM>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: Saturday, November 13, 1999 6:50 AM
Subject: Re: Euphoria features
>From: Everett Williams <rett at GVTC.COM>
>Subject: Re: Euphoria features
><snip Jason's type check routine>
>
>> And how is this type of thing going to describe the umpty hundred bit
>> and
>> byte flags in the average message header, no matter the protocol.
They
>> have to be literally unpacked one by one and then moved into a
different
>> sequence or atom before they can be intelligently maneuvered. And
>> since the data stream is dynamic, and treacherous, I really need for
>> type checking to stay on. Can you spell Methuselah...the guy whose
>> age you will approach while all this gets done.
>
>It appears that at least two people are laboring under a misconception
>of exactly what type() does.
>
>Bear in mind that a type() failure can _only_ cause an immediate abend.
Very
>useful when debugging, but worse than useless in a production program.
>Surely I don't have to explain this further.
>
>If type() could modify the passed parameter according to some rules you
set
>up, e.g: ask the clumsy typist to try again, it would be much more
useful.
>If it were faster, that wouldn't hurt either.
>
>Irv
>
Yes, I do understand that declaring a variable to a user-defined type will
cause the program to crash on error. I do believe that this would be useful
for debugging but not for production-quality programs. I would expect types
to be unnecessary in my code before I called it production-quality! But
types can also be used not for declaring a variable but as a special purpose
function for range testing. And the program doesn't exit when type is used
in that fashion.
__________________________________________
NetZero - Defenders of the Free World
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html
26. Re: Euphoria features
- Posted by Kat <KSMiTH at PELL.NET>
Nov 14, 1999
-
Last edited Nov 15, 1999
----- Original Message -----
From: Bernie Ryan <bwryan at PCOM.NET>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Sunday, November 14, 1999 8:27 PM
Subject: Re: Euphoria features
> On Sun, 14 Nov 1999 18:41:21 -0600, Kat <KSMiTH at PELL.NET> wrote:
>
> >Well, it was on the C64, and i don't know if i can even read those
floppys
> >anymore. Why would you want 6502 machine code ported to Eu?
>
> You could produce a basic compiler that outputs 80x86 machine code.
I really do have other things on my mind, or i'd still be using it. And
prolly not be online yet.
> Everyone on the list would then learn how you do the parsing, error
>
> checking, optimization and how to emit the machine code for the various
>
> constructs. Maybe you could even show us how to to do garbage collection.
>
> I think that would would be very educational.
It would for me too, i didn't do any garbage collection in the kernal. I did
have code that basically ( pun intended ) wrote out the low memory vars to a
upper area, pulled the high mem vars down, thereby compacting them, and then
pulled the ones i temporarily stored in upper memory down on top of those.
It was slow as cold honey, but it was a 1Mhz 8bit cpu. The block moves were
faster, so writing out zero page and the app and a small slice of memory was
easy and fast, making it worthwhile to do time-slice multitasking on the C64
easy. As was mapping the VIC chip to make windows that were more stable and
faster than mswin1.0 on a 286. Even with word wrapping in those windows.
Maybe i should try to make the system operateable again,, i'm getting
nostagic. Heh, i remembered the reliability of the CBM floppies, nevermind.
As for learning things, you can get the source code to several compilers
online, isn't the compiler that comes with some linux open source? What
about the GNUPascal, and other GNU code?
Kat
27. Re: Euphoria features
- Posted by nieuwen at XS4ALL.NL
Nov 15, 1999
Lucius, goto's _are_ effective ..
One out of 10, maybe 15 algorithms I use, depends on flag variables to jump out
of multiple
levels of a loop. Now that's messy.
Also 'spaghetti' code, its a cliche. The whole concept. You are just repeating
some body
else. No offense, but we all know what the public's opinion is about goto,
premarital sex,
other races, nationalism and drugs. Let me restate your comment.
> GOTO's are one of the strongest components of spaghetti code.
> Without goto, creating spachetti code is more difficult.
Goto's are a very strong component of code.
Without goto, creating code is more difficult.
Isn't this what really meant ?
And yes, you can give me examples of spaghetti code, I would give you examples
of the
macaroni we are forced to eat, by the lack goto, nowadays. I mean, you can,
technically, kill
a person with a fork, so should we make a fork illegal ?
Ralf Nieuwenhuijsen
[[ Email ]]
nieuwen at xs4all.nl
ralf_n at email.com
[[ I-Seek-You ]]
UIN: 9389920
[[ The Elevator ]]
http://www.xs4all.nl/~nieuwen
Download NeoPlanet at http://www.neoplanet.com
28. Re: Euphoria features
Lucius, Ralf, Kat
When you goto out of a "for" or a "while", you leave the statement in
an uncertain status if you do not go through some form of termination
of the for or while structure, including garbage collection. Very little
in practical reality is saved. Also, in Euphoria, I would like to know where
to you would go. The only thing that resembles a label or address in
Euphoria is a procedure name. If you goto a procedure, where will you
return to. If you goto a function name to whom will you return the value
and where will you return to. It appears that Euphoria was designed
to be goto proof. Now, we need not only goto's, but labels.
In addition, nobody has addressed my question about the scoping
effects of gotos. When you goto from the middle of a function or a
procedure to some other location that would normally have a
hierarchically built scope, how do you reestablish that scope? How do
you collapse the scope that you are leaving? Euphoria is a block
structured language, and I imagine the interpreter is built around
the initializing and closing of those blocks. If goto out of a block structure
does not close that block, what happens to it? If it does, what have
I gained? If blocks can only be entered at the top, does Euphoria
entirely depend on the initialization code to clear a block? Things like
exit argue otherwise.
Just a few questions to rock you to sleep with.
Everett L.(Rett) Williams
rett at gvtc.com
29. Re: Euphoria features
----- Original Message -----
From: Everett Williams <rett at GVTC.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Monday, November 15, 1999 3:10 AM
Subject: Re: Euphoria features
<snip>
> Also, in Euphoria, I would like to know where
> to you would go. The only thing that resembles a label or address in
> Euphoria is a procedure name. If you goto a procedure, where will you
> return to. If you goto a function name to whom will you return the value
> and where will you return to. It appears that Euphoria was designed
> to be goto proof. Now, we need not only goto's, but labels.
Well of course we need labels. How else will I be able to write wonderful,
meaningful, bugfree, useful code like:
PERFORM LBL2X4 THRU LBL4X5 VARYING X BY 6
Regards,
Irv
30. Re: Euphoria features
On Mon, 15 Nov 1999 07:11:52 -0500, Irv Mullins <irv at ELLIJAY.COM> wrote:
>----- Original Message -----
>From: Everett Williams <rett at GVTC.COM>
>To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
>Sent: Monday, November 15, 1999 3:10 AM
>Subject: Re: Euphoria features
>
>
><snip>
>> Also, in Euphoria, I would like to know where
>> to you would go. The only thing that resembles a label or address in
>> Euphoria is a procedure name. If you goto a procedure, where will you
>> return to. If you goto a function name to whom will you return the value
>> and where will you return to. It appears that Euphoria was designed
>> to be goto proof. Now, we need not only goto's, but labels.
>
>Well of course we need labels. How else will I be able to write wonderful,
>meaningful, bugfree, useful code like:
>PERFORM LBL2X4 THRU LBL4X5 VARYING X BY 6
>
>Regards,
>Irv
Irv,
Just remember that when that showed up in COBOL, it was meant to
replace the goto for all except the most extreme circumstances. Fortran
at the time had no easy way to return from a routine to where that routine
had been called from unless the routine was made external, separately
compiled, and linked or dynamically called. The THRU created really
nasty order dependencies, so moving a routine became hazardous. We
recommended that programmers put a label at the beginning of a routine
and one at it's end with block coding style(we already had the example
of ALGOL...I think, the first block coded language). We allowed no
further branching outside that block and no code was allowed to flow
THRU a block. The block had to be performed. Still, in all a major
improvement over FORTRAN.
Everett L.(Rett) Williams
rett at gvtc.com
31. Re: Euphoria features
On Mon, 15 Nov 1999 08:59:35 +0000, nieuwen at XS4ALL.NL wrote:
>Lucius, goto's _are_ effective ..
>One out of 10, maybe 15 algorithms I use, depends on flag variables to jump out
>of multiple
>levels of a loop. Now that's messy.
>
>Ralf Nieuwenhuijsen
Ralf,
Those flag variables, if named something explanatory provide status
information that is most valuable, specifically in debugging or influencing
the code to be performed at the target of the goto. My favorite is a
depth variable for recursive code. The other problem with goto, is that it
is a tailless kite. It provides no pointer to it's source once it gets where
it is going. I suspect that because of the violence done to block structures
and the loss of state information(currently, in Euphoria, you are always
in the main line, or in a procedure or function stack that leads back to
the main line), the overhead alone will prevent the use of goto's if
Robert is foolish enough to resurrect this long-dead canard for those
who haven't learned how to structure their logic yet. By the way,
routine_id() with call...call_back is a goto with many of the same effects.
Everett L.(Rett) Williams
rett at gvtc.com
32. Re: Euphoria features
----- Original Message -----
From: Everett Williams <rett at GVTC.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Monday, November 15, 1999 2:10 AM
Subject: Re: Euphoria features
> Lucius, Ralf, Kat
>
> When you goto out of a "for" or a "while", you leave the statement in
> an uncertain status if you do not go through some form of termination
> of the for or while structure, including garbage collection.
But when you leave the block that holds that procedure, everything local to
that procedure is reset anyways, and that memory is returned to the pool.
All the local vars are wiped ( or their pointers are set to null, so as to
be garbage collected ), all the global vars don't need any attention. If you
do exit a nested for loop, only to hit the outer next, you are simply
restarting that section of code. Especially if the procedure loop is
separate blocks of code that are arrived at with a gosub opcode and left by
a retsub opcode, a goto within the procedure is not a problem. The only time
it's complicated, imo, is when traversing the subroutine block boundries,,
so don't do that, as i did say before.
>Very little
> in practical reality is saved. Also, in Euphoria, I would like to know
where
> to you would go. The only thing that resembles a label or address in
> Euphoria is a procedure name. If you goto a procedure, where will you
> return to. If you goto a function name to whom will you return the value
> and where will you return to. It appears that Euphoria was designed
> to be goto proof. Now, we need not only goto's, but labels.
You do not goto a function name, you goto a target made just for the goto,
residing in the current procedure or function. In the main code block, you
can jump over function calls, but once in that function, the farthest you
can jump is to the end of that function. That's al that most people need,
it's all that i need, to stop processing when the problem is solved,, and
not at that point to begin processing exit flags in if statements. Here's an
example label--> :eoThisParagraph
> In addition, nobody has addressed my question about the scoping
> effects of gotos. When you goto from the middle of a function or a
> procedure to some other location that would normally have a
> hierarchically built scope, how do you reestablish that scope? How do
> you collapse the scope that you are leaving? Euphoria is a block
> structured language, and I imagine the interpreter is built around
> the initializing and closing of those blocks. If goto out of a block
structure
> does not close that block, what happens to it? If it does, what have
> I gained? If blocks can only be entered at the top, does Euphoria
> entirely depend on the initialization code to clear a block? Things like
> exit argue otherwise.
I answered previously! In compiled languages that don't garbage collect,
once you pop the stack at the end of the procedure to find the address you
came from, all the vars are "forgotten", and that procedure's stack is
forgotten too. I would suppose in an interpreted language, a call to a
function to set all those vars' pointers to null does the "forgetting" part,
and once set to null ( or nil or $nill or whatever ), the garbage collection
handles them normally. Consider that a part of the garbage collection in a
way, because it's done *now* anyways with loop vars when the procedure is
left, i believe, so add the local var list to that function (once we get
procedure/function local vars), since they are declared local, we know what
they are, so adding them to cleanup should not be a problem, i bet Robert
must do this anyways.
> Just a few questions to rock you to sleep with.
Sticks and rocks may,, oh, nevermind
Kat
33. Re: Euphoria features
----- Original Message -----
From: Everett Williams <rett at GVTC.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Monday, November 15, 1999 11:34 AM
Subject: Re: Euphoria features
> On Mon, 15 Nov 1999 08:59:35 +0000, nieuwen at XS4ALL.NL wrote:
>
> >Lucius, goto's _are_ effective ..
> >One out of 10, maybe 15 algorithms I use, depends on flag variables to
jump out of multiple
> >levels of a loop. Now that's messy.
> >
>
> >Ralf Nieuwenhuijsen
>
> Ralf,
>
> Those flag variables, if named something explanatory provide status
> information that is most valuable, specifically in debugging or
influencing
> the code to be performed at the target of the goto. My favorite is a
> depth variable for recursive code.
A var you coded yourself, or the for/while vars? I addressed the for/while
vars earlier. You can do the tracing vars you write now, if you do, as you
do now.
>The other problem with goto, is that it
> is a tailless kite. It provides no pointer to it's source once it gets
where
> it is going.
Eu currently stores program flow, it can continue to do that, backtracing
that store as needed.
>I suspect that because of the violence done to block structures
> and the loss of state information(currently, in Euphoria, you are always
> in the main line, or in a procedure or function stack that leads back to
> the main line), the overhead alone will prevent the use of goto's if
> Robert is foolish enough to resurrect this long-dead canard for those
> who haven't learned how to structure their logic yet.
I know how to build up a huge pile of procedures, calling them as needed
with if statements, using global vars to pass back flags about whether to
call the next procedure, etc., and i consider that worse than any
block-scope-limited goto could ever be. It's more code, more overhead, and
harder to debug. I agree with Ralf on this one. Gimme a goto.
>By the way,
> routine_id() with call...call_back is a goto with many of the same
effects.
Routine_id() should be only setting a memory pointer before it is normally
set by the interpreter/compiler. No harm in that. In fact, if it's not done,
how can you have two functions call each other?
Kat
34. Re: Euphoria features
Ralf wrote:
> Lucius, goto's _are_ effective ..
I'm not a big fan of GOTOs, but they are quite effective for exiting nested
blocks of logic.
Yes, I know that you *could* move those blocks into a routine, and use
'return' to jump out of the routine. And I also know that there are
structured ways of writing code that avoid GOTOs - my eBasic translator can
cleverly re-write GOTOs into structured code, resulting in functionally
equivalent but entirely unreadable code.
Restricting the GOTO to only forward jumps might be a reasonable constraint.
I'm not sure I'm ready for named GOTOs, like:
goto $foo
You can already do that by setting up vectors through routine_id:
call_proc( foo, {} )
-- David Cuny
35. Re: Euphoria features
Everett Williams writes:
> In addition, nobody has addressed my question
> about the scoping effects of gotos.
I'd assume the following constraints:
1. GOTOs limited to the same routine. I arbitrarily disallow in-line GOTOs.
2. Only forward GOTOs:
foo:
-- NOT ALLOWED
goto foo:
3. You can leap out of block structures:
for i = 1 to 10
for j = 1 to 10
if x = 12 then
goto label:
end if
end for
label:
end for
4. You can leap into block structures:
goto label:
for i = 1 to 10 do
-- NOT ALLOWED
label:
Seems to me that this allows the goal of leaping out of blocks of logic.
-- David Cuny
36. Re: Euphoria features
On Mon, 15 Nov 1999 12:16:24 -0600, Kat <KSMiTH at PELL.NET> wrote:
>> >Ralf Nieuwenhuijsen
>>
>Eu currently stores program flow, it can continue to do that, backtracing
>that store as needed.
But, it is not implicit to the flow of the program. When I code a procedure
or a function I know where control will return. When I goto, that is lost.
>>I suspect that because of the violence done to block structures
>> and the loss of state information(currently, in Euphoria, you are always
>> in the main line, or in a procedure or function stack that leads back to
>> the main line), the overhead alone will prevent the use of goto's if
>> Robert is foolish enough to resurrect this long-dead canard for those
>> who haven't learned how to structure their logic yet.
>
>I know how to build up a huge pile of procedures, calling them as needed
>with if statements, using global vars to pass back flags about whether to
>call the next procedure, etc., and i consider that worse than any
>block-scope-limited goto could ever be. It's more code, more overhead, and
>harder to debug. I agree with Ralf on this one. Gimme a goto.
The need for status or state variables cannot be obviated by goto's. In
fact, the lack of current state information causes more program error
in interactive situations than almost any other cause. The same window
create routine may function in a variety of situations, but when it comes
time to delete or alter that window, I'd better have current state information
on it and any windows that it is related to or touches. Trying to manage
"state" or status by carefully crafted goto's that take me out of the
logical dead-ends that I have programmed, is about as error prone as
anything that I can think of. Status information "flattens out" the code
model and allows state or status switching by allowing the storing of one
set of status information and the fetching of another.
>>By the way,
>> routine_id() with call...call_back is a goto with many of the same
>effects.
>
>Routine_id() should be only setting a memory pointer before it is normally
>set by the interpreter/compiler. No harm in that. In fact, if it's not done,
>how can you have two functions call each other?
>
>Kat
Gee, and that is just what I thought a label was, "a memory pointer...set
by the interpreter/compiler". I reiterate. Routine_id() is just a goto in
sheeps clothing...and just as messy.
Everett L.(Rett) Williams
rett at gvtc.com
37. Re: Euphoria features
David Cuny writes:
>3. You can leap out of block structures:
>
> for i = 1 to 10
> for j = 1 to 10
> if x = 12 then
> goto label:
> end if
> end for
> label:
> end for
>Seems to me that this allows the goal of leaping out of blocks of logic.
>
>-- David Cuny
This seems like a good idea to me. I think allowing goto's like basic uses
would be bad cos it'd introduce a whole lot of new problems. But ecsaping
deeply nested loops like that would be a good advantage, I always find that
one of the harder things to work around in EU.
-Mark.
38. Re: Euphoria features
I wrote:
> 4. You can leap into block structures:
>
> goto label:
> for i = 1 to 10 do
> -- NOT ALLOWED
> label:
That should have been:
> 4. You can NOT leap into block structures:
-- David Cuny
39. Re: Euphoria features
Everett Williams wrote:
> Routine_id() is just a goto in
> sheeps clothing...and just as messy.
Perhaps a 'gosub' in sheep's clothing is a bit more accurate.
-- David Cuny
40. Re: Euphoria features
Gee, goto supporters are coming out of the woodwork now! )
Kat
----- Original Message -----
From: Liquid-Nitrogen Software <nitrogen_069 at HOTMAIL.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Monday, November 15, 1999 1:41 PM
Subject: Re: Euphoria features
> David Cuny writes:
>
> >3. You can leap out of block structures:
> >
> > for i = 1 to 10
> > for j = 1 to 10
> > if x = 12 then
> > goto label:
> > end if
> > end for
> > label:
> > end for
>
> >Seems to me that this allows the goal of leaping out of blocks of logic.
> >
> >-- David Cuny
>
> This seems like a good idea to me. I think allowing goto's like basic uses
> would be bad cos it'd introduce a whole lot of new problems. But ecsaping
> deeply nested loops like that would be a good advantage, I always find
that
> one of the harder things to work around in EU.
>
> -Mark.
>
41. Re: Euphoria features
On Mon, 15 Nov 1999 11:17:37 -0800, Cuny, David at DSS <David.Cuny at
DSS.CA.GOV> wrote:
>Everett Williams writes:
>
>> In addition, nobody has addressed my question
>> about the scoping effects of gotos.
>
>I'd assume the following constraints:
>
>1. GOTOs limited to the same routine. I arbitrarily disallow in-line GOTOs.
>
>2. Only forward GOTOs:
>
> foo:
> -- NOT ALLOWED
> goto foo:
>
>3. You can leap out of block structures:
>
> for i = 1 to 10
> for j = 1 to 10
> if x = 12 then
> goto label:
> end if
> end for
> label:
> end for
Did I miss something...exit can accomplish this one. If I may borrow
your example.
for i = 1 to 10
for j = 1 to 10
if x = 12 then
goto label:
end if
end for
...
procx()
...
label:
end for
Exit cannot accomplish this.
So can this.
for i = 1 to 10
for j = 1 to 10
if x = 12 then
exit
end if
end for
if x != 12 then
...
procx()
...
end if
end for
It is explicit and costs one more line of code. OR
skip1 = true
for i = 1 to 10
for j = 1 to 10
if x = 12 then
skip1 = false
exit
end if
end for
while skip1 do
...
procx()
...
skip1 = false
end while
end for
This has the advantage of explicitly describing the range of code to be
skipped and the variable name tells you the purpose of the while(along
with any comments you might have). The goto allows code to be
inadvertently added in the area skipped by the goto with little indication
that it may not be executed at the exit to the for. I also allows selective
skipping. More lines of code that clearly document intent and create
very little extra overhead if I understand what is likely to have to be done
when a goto is encountered.
>4. You can leap into block structures:
>
> goto label:
> for i = 1 to 10 do
> -- NOT ALLOWED
> label:
Agreed, this is a real non-starter.
>Seems to me that this allows the goal of leaping out of blocks of logic.
>
>-- David Cuny
For your perusal.
Everett L.(Rett) Williams
rett at gvtc.com
42. Re: Euphoria features
----- Original Message -----
From: Everett Williams <rett at GVTC.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Monday, November 15, 1999 1:56 PM
Subject: Re: Euphoria features
> On Mon, 15 Nov 1999 12:16:24 -0600, Kat <KSMiTH at PELL.NET> wrote:
>
>
> >> >Ralf Nieuwenhuijsen
> >>
>
> >Eu currently stores program flow, it can continue to do that, backtracing
> >that store as needed.
>
> But, it is not implicit to the flow of the program. When I code a
procedure
> or a function I know where control will return. When I goto, that is lost.
You don't return from a goto,,, if you did, that would be a gosub, which we
call "calling a function/procedure". A goto limited in scope to the function
it resides in will still return from that function in the manner that
function returns now. If you are coding tracking vars, and you want out of a
routine with your tracking vars intact/updated , then goto :eoThatFunction,
and play with the tracking vars there at the end of the function, before the
actual end.
> >>I suspect that because of the violence done to block structures
> >> and the loss of state information(currently, in Euphoria, you are
always
> >> in the main line, or in a procedure or function stack that leads back
to
> >> the main line), the overhead alone will prevent the use of goto's if
> >> Robert is foolish enough to resurrect this long-dead canard for those
> >> who haven't learned how to structure their logic yet.
> >
> >I know how to build up a huge pile of procedures, calling them as needed
> >with if statements, using global vars to pass back flags about whether to
> >call the next procedure, etc., and i consider that worse than any
> >block-scope-limited goto could ever be. It's more code, more overhead,
and
> >harder to debug. I agree with Ralf on this one. Gimme a goto.
>
> The need for status or state variables cannot be obviated by goto's.
If you don't need them except for getting out of loops the current messy way
we *must* use occasionally ( a la Ralf ) , then that's all the more vars we
need not code.
>In
> fact, the lack of current state information causes more program error
> in interactive situations than almost any other cause. The same window
> create routine may function in a variety of situations, but when it comes
> time to delete or alter that window, I'd better have current state
information
> on it and any windows that it is related to or touches. Trying to manage
> "state" or status by carefully crafted goto's that take me out of the
> logical dead-ends that I have programmed, is about as error prone as
> anything that I can think of. Status information "flattens out" the code
> model and allows state or status switching by allowing the storing of one
> set of status information and the fetching of another.
How is how Eu/you store window info related to a goto in the program *flow*
? A goto has nothing to do with the state of events that call the windoze
api for windows. A look into the assy code for a goto in the pascal
debugger shows a straight translation from the script language to a goto
assy language equivalent. And when my code is done processing, and there is
no more to do, i'd really like to stop processing it and goto the end of
that processing section.
> Gee, and that is just what I thought a label was, "a memory pointer...set
> by the interpreter/compiler".
The label is the memory location pointed to by the goto.
>I reiterate. Routine_id() is just a goto in
> sheeps clothing...and just as messy.
But a goto target is not a routine. Routines should not be goto-able.
Whether or not a goto can hit a forward target or not, it should still be
limited in scope to the current function/procedure, and hit no targets
outside that block. A goto in main should not hit a target in a
function/procedure, and vice versa.
Kat,
thinking this topic has been covered pretty well now.
43. Re: Euphoria features
cheers,
Derek Parnell
dparnell @ vic.bigpond.net.au
Melbourne, Australia
|----- Original Message -----
|
|> David Cuny writes:
|>
|> >3. You can leap out of block structures:
|> >
|> > for i = 1 to 10
|> > for j = 1 to 10
|> > if x = 12 then
|> > goto label:
|> > end if
|> > end for
|> > label:
|> > end for
|>
Another way of doing this is to change Eu so that blocks can be named.
block_name:
for i = 1 to 10
for j = 1 to 10
if x = 12 then
next block_name
end if
end for
end for
44. Re: Euphoria features
Everett Williams wrote:
> Did I miss something...exit can accomplish this one.
Yes, the example was trivial.
I'd like to make my position on GOTOs more clear: I'm not really interested
in adding a GOTO to Euphoria. Rather, I'm more interested in a good way of
getting out of deeply nested logic structures in an efficient manner.
Using flags is the 'correct' way of doing it, but the resulting code often
seems to obscure the intent, rather than clarify it. Moving the block into a
routine is possible, but sharing variables can be problematic in Euphoria,
especially since they are scoped as local.
I seem to recall that even the K&R text acknowleged that the GOTO is the
best method of expressing that intent.
The 'problem' with block structures is that they are local; they neither
know about the blocks outside of themselves, or inside of them. If we were
only talking about 'for' loops, than something like:
for i = 1 to 10 do
for j = 1 to 10 do
...
leave i loop
...
end for
end for
Would work. But there are 'while' loops as well. I suppose you could add
labels to the loops, as in:
outerWhile: while true do
for i = 1 to 10 do
...
leave outerWhile:
...
end for
end while
This strikes me as being less clear than the pure GOTO, and it disallows
instance where you have a series of instructions, but want to stop if an
error is encountered:
if handle = -1 then
goto fileError:
end if
...
if writeResult = -1 then
goto fileError:
end if
...
if closeFileResult = -1 then
goto fileError:
...
return
fileError:
...
return
Yes, I know that you could set a flag, etc. But it still seems to me that
the GOTO best expresses the intent of the code: if an error is encountered,
skip the rest of the code and run the error handler.
-- David Cuny
45. Re: Euphoria features
Kat wrote:
> Gee, goto supporters are coming out of the woodwork now! )
Don't be so naive, Kat. This one goes back quite a bit. On several
occasion I was stoned and almost excommunicated for just saying a well
placed goto can often save your skin.
jiri
46. Re: Euphoria features
That reminds me of a feature I wouldn't mind seeing: flag()
Not necessary, of course, but nice to have.
example:
procedure test()
puts(1,"test")
flag(hey)
end procedure
test()
if flag(hey) = 1 then do
...
end if
Of course, the same thing could be accomplished with a simple 'flag = 1', but
then you could run
into scope problems.
Greg Phillips
Everett Williams wrote:
> On Mon, 15 Nov 1999 08:59:35 +0000, nieuwen at XS4ALL.NL wrote:
>
> >Lucius, goto's _are_ effective ..
> >One out of 10, maybe 15 algorithms I use, depends on flag variables to jump
> >out of multiple
> >levels of a loop. Now that's messy.
> >
>
> >Ralf Nieuwenhuijsen
>
> Ralf,
>
> Those flag variables, if named something explanatory provide status
> information that is most valuable, specifically in debugging or influencing
> the code to be performed at the target of the goto. My favorite is a
> depth variable for recursive code. The other problem with goto, is that it
> is a tailless kite. It provides no pointer to it's source once it gets where
> it is going. I suspect that because of the violence done to block structures
> and the loss of state information(currently, in Euphoria, you are always
> in the main line, or in a procedure or function stack that leads back to
> the main line), the overhead alone will prevent the use of goto's if
> Robert is foolish enough to resurrect this long-dead canard for those
> who haven't learned how to structure their logic yet. By the way,
> routine_id() with call...call_back is a goto with many of the same effects.
>
> Everett L.(Rett) Williams
> rett at gvtc.com
47. Re: Euphoria features
> ---------------------- Information from the mail
header -----------------------
> Sender: Euphoria Programming for MS-DOS
<EUPHORIA at LISTSERV.MUOHIO.EDU>
> Poster: "Cuny, David at DSS" <David.Cuny at DSS.CA.GOV>
> Subject: Re: Euphoria features
> --------------------------------------------------------------------------
-----
<SNIP>
>
>
> Would work. But there are 'while' loops as well. I suppose you could add
> labels to the loops, as in:
>
> outerWhile: while true do
> for i = 1 to 10 do
> ...
> leave outerWhile:
> ...
> end for
> end while
Hmm, Exiting while loops does pose a bit of a problem.
This will definately require even more consideration.
> This strikes me as being less clear than the pure GOTO, and it disallows
> instance where you have a series of instructions, but want to stop if an
> error is encountered:
>
> if handle = -1 then
> goto fileError:
> end if
>
> ...
> if writeResult = -1 then
> goto fileError:
> end if
>
> ...
> if closeFileResult = -1 then
> goto fileError:
>
> ...
> return
>
> fileError:
> ...
> return
>
>
> Yes, I know that you could set a flag, etc. But it still seems to me that
> the GOTO best expresses the intent of the code: if an error is
encountered,
> skip the rest of the code and run the error handler.
>
> -- David Cuny
>
David, That would be a GOSUB.
Basic's "ON ERROR GOSUB Label" comes to mind
What does this mean? It means I would use a subroutine to handle it
in the first place.
procedure fileError()
--Handle the file Error.
if can_not_handle then
abort(err_code)--
end if
end procedure
if handle = -1 then
fileError():
end if
...
if writeResult = -1 then
fileError():
end if
...
if closeFileResult = -1 then
fileError():
end if
PS: No, My idea of exit(A) or exit[A] isn't mimicking others
similar ideas. I simply had not read those messages
before forming that thought. Same with my other near
identical response to a previous message.
As usual, someone seems to beat me to the punch.
Lucius L. Hilley III
lhilley at cdc.net lucius at ComputerCafeUSA.com
+----------+--------------+--------------+
| Hollow | ICQ: 9638898 | AIM: LLHIII |
| Horse +--------------+--------------+
| Software | http://www.cdc.net/~lhilley |
+----------+-----------------------------+
48. Re: Euphoria features
>>I seem to recall that even the K&R text acknowleged that the GOTO is the
>>best method of expressing that intent.
K&R page 62 section 3.9
I qoute :
"C provides the infinitely-abusive goto statement, and labels to branch to.
Formally, the goto is never necessary, and in pratice it is almost always
easy to write code without it."
Then they give two examples one using the goto to get out deeply nested
structure and then the second with flags and tests to exit showing
that code involving a goto can always be written without one.
All Euphoria needs two keywords, one that breaks out of a single nested
structure and one that breaks out of deeply nested structure. This would
would eliminate the abuse of a goto.
49. Re: Euphoria features
----- Original Message -----
From: Greg Phillips <i.shoot at REDNECKS.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Monday, November 15, 1999 5:54 PM
Subject: Re: Euphoria features
> ---------------------- Information from the mail
header -----------------------
> Sender: Euphoria Programming for MS-DOS
<EUPHORIA at LISTSERV.MUOHIO.EDU>
> Poster: Greg Phillips <i.shoot at REDNECKS.COM>
> Subject: Re: Euphoria features
> --------------------------------------------------------------------------
-----
>
> That reminds me of a feature I wouldn't mind seeing: flag()
>
> Not necessary, of course, but nice to have.
>
> example:
>
> procedure test()
> puts(1,"test")
> flag(hey)
> end procedure
>
> test()
>
> if flag(hey) = 1 then do
> ...
> end if
>
> Of course, the same thing could be accomplished with a simple 'flag = 1',
but then you could run
> into scope problems.
>
> Greg Phillips
>
Intriguing. Still not much of a real solution though.
At least we are thinking. :)
Lucius L. Hilley III
lhilley at cdc.net
+----------+--------------+--------------+
| Hollow | ICQ: 9638898 | AIM: LLHIII |
| Horse +--------------+--------------+
| Software | http://www.cdc.net/~lhilley |
+----------+-----------------------------+
50. Re: Euphoria features
----- Original Message -----
From: Bernie Ryan <bwryan at PCOM.NET>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Monday, November 15, 1999 4:51 PM
Subject: Re: Euphoria features
> >>I seem to recall that even the K&R text acknowleged that the GOTO is the
> >>best method of expressing that intent.
>
>
> K&R page 62 section 3.9
>
> I qoute :
>
> "C provides the infinitely-abusive goto statement, and labels to branch
to.
> Formally, the goto is never necessary, and in pratice it is almost
always
> easy to write code without it."
I think gasoline and automobiles should be eliminated, they both cause
far-reaching negative impact on the environment, and they are implicated in
the deaths of thousands of people each year in the usa. We can all use
horses, bicycles, and helicopters.
> Then they give two examples one using the goto to get out deeply nested
> structure and then the second with flags and tests to exit showing
> that code involving a goto can always be written without one.
But why be forced to make a pile of
if-elsif-elsif-elsif-elsif-elsif-elsif-elsif-elsif-endif when an some
if-gotoend-endif will work?
> All Euphoria needs two keywords, one that breaks out of a single nested
> structure and one that breaks out of deeply nested structure. This would
> would eliminate the abuse of a goto.
And not solve the pile of elsif above. When i give directions to someone on
how to get somewhere, i use "go to", sigh,, i'll need to start forming my
directions into elsif statements just to improve my syle, i guess. <sigh>
Kat
51. Re: Euphoria features
- Posted by Everett Williams <rett at GVTC.COM>
Nov 15, 1999
-
Last edited Nov 16, 1999
Derek Parnell wrote:
>
>Another way of doing this is to change Eu so that blocks can be named.
>
> block_name:
> for i = 1 to 10
> for j = 1 to 10
> if x = 12 then
> next block_name
> end if
> end for
> end for
You forgot the "end block", but we can see it anyway. ALGOL strikes
again, if we have to do this, programmer controlled blocks would be
an attractive option, in addition to maintaining the structure of the
language. It also allows for structure in mainline code with very little
cost involved.
Everett L.(Rett) Williams
rett at gvtc.com
52. Re: Euphoria features
- Posted by Everett Williams <rett at GVTC.COM>
Nov 15, 1999
-
Last edited Nov 16, 1999
David.Cuny wrote:
>Everett Williams wrote:
>
>> Did I miss something...exit can accomplish this one.
>
>Yes, the example was trivial.
Sorry about that, but you ignored the "skip" routine which I thought made
the deeper point. The skip routine encapsulated the items that were to be
intentionally skipped, documenting the intent. Goto documents nothing.
It is a high-altitude bomber that leaves no marks except on the target
where it is headed. That may be great in bombing, but it sure leaves lots
of questions in a program.
>
>I'd like to make my position on GOTOs more clear: I'm not really interested
>in adding a GOTO to Euphoria. Rather, I'm more interested in a good way of
>getting out of deeply nested logic structures in an efficient manner.
>
>Using flags is the 'correct' way of doing it, but the resulting code often
>seems to obscure the intent, rather than clarify it. Moving the block into a
>routine is possible, but sharing variables can be problematic in Euphoria,
>especially since they are scoped as local.
Well chosen, documented, and named flag variables usually resolve this
objection.
>I seem to recall that even the K&R text acknowleged that the GOTO is the
>best method of expressing that intent.
>
>The 'problem' with block structures is that they are local; they neither
>know about the blocks outside of themselves, or inside of them. If we were
>only talking about 'for' loops, than something like:
>
> for i = 1 to 10 do
> for j = 1 to 10 do
> ...
> leave i loop
> ...
> end for
> end for
>
>Would work. But there are 'while' loops as well. I suppose you could add
>labels to the loops, as in:
>
> outerWhile: while true do
> for i = 1 to 10 do
> ...
> leave outerWhile:
> ...
> end for
> end while
>
>This strikes me as being less clear than the pure GOTO, and it disallows
>instance where you have a series of instructions, but want to stop if an
>error is encountered:
>
> if handle = -1 then
> goto fileError:
> end if
>
> ...
> if writeResult = -1 then
> goto fileError:
> end if
> ...
> if closeFileResult = -1 then
> goto fileError:
> ...
> return
>
> fileError:
> ...
> return
>
>Yes, I know that you could set a flag, etc. But it still seems to me that
>the GOTO best expresses the intent of the code: if an error is encountered,
>skip the rest of the code and run the error handler.
>
>-- David Cuny
Ignoring the obvious elseif structure, let us assume a situation where
later on I decide to add some logic between return and fileError: for
whatever reason. If the code is large, will I remember that the return
does not in all cases lead to the fileError:? Maybe the code to be added
only needs to be run in certain cases. Multiply that times about five or
ten special cases as is often the condition in highly complex decisional
code. Without flags, I don't have anything to test for the various
combinations of decisions that I have to make. Furthermore, now I
have to find everybody that goes to this label and fix them to handle the
needed flags. That is the bottom problem with goto. It carries no information
with it in the way that a procedure stack does just by it's nature and
sequence.
Goto is like the guy that sees a fire in the bathroom as he turns
away from the urinal. He goes running out of the bathroom yelling fire.
Nobody is likely to tell him that he left his fly open and his wallet on the
sink. In a few minutes, he is going to realize the importance of these two
things. Since the fly is still attached(the flag) he can do something about
it. The wallet, however, is quite another matter. By the time he hits the
street, he may not even remember which bathroom that he was in.
That is the reason for not using goto's. I agree that the "shorter range"
ones that you speak of sound attractive, and would certainly be less
damaging than the more general type. However, one man's procedure may
be larger than somebody else's whole program. A goto can go across
several pages of code, even in the restricted situation.
Everett L.(Rett) Williams
rett at gvtc.com
53. Re: Euphoria features
- Posted by Greg Phillips <i.shoot at REDNECKS.COM>
Nov 15, 1999
-
Last edited Nov 16, 1999
"Lucius L. Hilley III" wrote:
> >
> > That reminds me of a feature I wouldn't mind seeing: flag()
> >
> > Not necessary, of course, but nice to have.
> >
> > example:
> >
> > procedure test()
> > puts(1,"test")
> > flag(hey)
> > end procedure
> >
> > test()
> >
> > if flag(hey) = 1 then do
> > ...
> > end if
> >
> > Of course, the same thing could be accomplished with a simple 'flag = 1',
> but then you could run
> > into scope problems.
> >
> > Greg Phillips
> >
>
> Intriguing. Still not much of a real solution though.
> At least we are thinking. :)
>
It's not intended to be a solution, just one of those things that might make
Euphoria a bit more fun to use, and a bit nicer to look at.
Regards,
Greg Phillips
54. Re: Euphoria features
Thus spake nieuwen at XS4ALL.NL on Mon, 15 Nov 1999:
>Subject: Re: Euphoria features
>Goto's are a very strong component of code.
>Without goto, creating code is more difficult.
Yeah, like imagine assembler without gotos!
ZB
55. Re: Euphoria features
On Wed, 17 Nov 1999 14:03:55 -0500, Bruce M. Axtens <zaphod_beeblebrox at
SIL.ORG> wrote:
>Thus spake nieuwen at XS4ALL.NL on Mon, 15 Nov 1999:
>>Subject: Re: Euphoria features
>
>>Goto's are a very strong component of code.
>>Without goto, creating code is more difficult.
>
>Yeah, like imagine assembler without gotos!
>
>ZB
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 L.(Rett) Williams
rett at gvtc.com
56. Re: Euphoria features
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.
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.
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.
jiri
57. Re: Euphoria features
- Posted by Everett Williams <rett at GVTC.COM>
Nov 17, 1999
-
Last edited Nov 18, 1999
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
58. Re: Euphoria features
Everett L.(Rett) Williams wrote:
>Building the pieces for peeking and poking is so foreign to
>Euphoria's intent.
Everett, it's extremely difficult not to be sarcastic when confronted
with such definitive statements, such deep insights, especially
considering your limited experience with the language.
>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.
First of all, we haven't got it. And I will probably spend the rest of
the night awake, puzzled how assembly code is more readable and / or
more explicit (!) than a bunch of peeks and pokes. If you want any
number of examples of horribly inefficient assembly, written by mere
dabblers, just ask - I wrote some of them.
>>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
<snip>
Fortunately, you are not in a position to arbitrate what I know and
what I don't. I have not rubbed shoulders "with people at the leading
edge of the business", but I have been around long enough (possibly
longer than you) to recognize an old campaigner when I see one. It was
meant as a compliment, anyway.
Just a final note, I hope you will not be too offended. You are fast
developing quite a reputation for skillfully, subtly changing subjects
of your arguments (again a compliment full of admiration). Your
'portability' tack is likely to impress only the very impressionable.
I am not one them. If you want portability, switch / go back to C.
That's as close as you can get to it. Plain old C. You will find it on
every platform, in every environment, and it's usually affordable.
Beyond that THERE IS NO REAL PORTABILITY IN THE REAL WORLD! (BTW I do
not understand why the vast majority of this congregation seems to
hate C so much. Ignorance? (this will make me even more popular..)
After all, it is a remarkably simple, elegant language, a bit too
terse for my taste, but with very few flaws and still unsurpassed for
its power in the right hands. And it all started way back in the early
seventies and is still going strong. - Please notice, I am not
including
C++, a monstrosity, I believe *no one* completely understands, not
even its parents).
Enough! Stop! - Sorry. jiri
59. Re: Euphoria features
On Thu, 18 Nov 1999, JIRI wrote:
> BTW I do
> not understand why the vast majority of this congregation seems to
> hate C so much. Ignorance? (this will make me even more popular..)
> After all, it is a remarkably simple, elegant language, a bit too
> terse for my taste, but with very few flaws and still unsurpassed for
> its power in the right hands.
True. With all that power comes a plethora of ways to misuse it, either
intentionally or by accident. C makes it far to easy for inexperienced
programmers to trip and fall into a pit, where they land on the bodies of the
experienced C programmers that preceeded them.
Irv
60. Re: Euphoria features
jiri babor wrote:
>Everett L.(Rett) Williams wrote:
>
>>Building the pieces for peeking and poking is so foreign to
>>Euphoria's intent.
>
>Everett, it's extremely difficult not to be sarcastic when confronted
>with such definitive statements, such deep insights, especially
>considering your limited experience with the language.
Sarcasm, from you, I will take...even if ill founded.
>>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.
>
>First of all, we haven't got it. And I will probably spend the rest of
>the night awake, puzzled how assembly code is more readable and / or
>more explicit (!) than a bunch of peeks and pokes. If you want any
>number of examples of horribly inefficient assembly, written by mere
>dabblers, just ask - I wrote some of them.
And I a few thousand more. What I meant was that given explicit named
data structures describing bits, bytes and double bytes as well as words,
inline assembler, where necessary for efficiency can refer to existing
named data items rather than machine addresses. With those data
structures available, the majority of those peeks and pokes would become
unnecessary.
>Your 'portability' tack is likely to impress only the very impressionable.
>I am not one them. If you want portability, switch / go back to C.
It seems that Rob is among the impressionable because he is porting the
language to the Linux environment. I kinda thought that opened up the
subject of portability as a legitimate item for discussion.
>(BTW I do not understand why the vast majority of this congregation
>seems to hate C so much. Ignorance? (this will make me even more >popular..)
>After all, it is a remarkably simple, elegant language, a bit too
>terse for my taste, but with very few flaws and still unsurpassed for
>its power in the right hands. And it all started way back in the early
>seventies and is still going strong. - Please notice, I am not
>including C++, a monstrosity, I believe *no one* completely understands,
>not even its parents).
Agreed and agreed...except for that part about C being a simple and
elegant language. I'd have to hold that one at arms length...at least in
comparison to Euphoria. C's flaws are in style rather than substance.
It is, as you say, powerful and portable...and I would add stable,
efficient, and highly optimized to that group of compliments. I got involved
in a proposed port of C to some logic composed of AMD bit-slice
hardware in the early 80's.
>Enough! Stop! - Sorry. jiri
If by "stop" you mean quit advocating a future that I think is attainable
with very little real effort...never. You are certainly free to ignore any posts
that I make, though I would hope that you would not do that. When it
comes to things like goto, I will go down with the ship on that one. Goto
is an abomination that has cost me more hours than almost any single
item that I can think of. Ralf, callow youth, has probably never seen a
14,000 line assembler program that had to be split into two or more pieces
to be handled by most of the editors of it's time(1974). It should never
have existed, but it did, and it was not in my power to change that fact.
Since branching in 360 assembler does not have too many structured
forms outside of BALR, goto was the rule there and is the rule in
most assemblers. One can design structured branches with macros and
I did, but there was no standard, generally available set of macros that
accomplished that goal...the objection being that they slowed things
down. Never mind old ghouls and ghosties. I have not seen any language
that goto improved unless it had no mechanism for otherwise controlling
flow(early EasyTreve). Even that, since it was seldom used for programs
longer than 100 lines(and could generate complete, selective reports in
that span) was not particularly difficult to control with If's, especially if
one spent a few seconds considering how to structure the If's before
starting to code.
Too the future,
Everett L.(Rett) Williams
rett at gvtc.com
61. Re: Euphoria features
Everett wrote:
>>Enough! Stop! - Sorry. jiri
>If by "stop" you mean quit advocating a future that I think is attainable
>with very little real effort...never. You are certainly free to ignore any
posts
>that I make, though I would hope that you would not do that. <snip>
Sorry, complete misunderstanding. It was a cry to myself, at 3 o'clock in the
morning, to stop raving and get some sleep. jiri
62. Re: Euphoria features
i have done almost enything to off from this euphoria but
nothing helps.
i do not want all this stuped infos to my email
PLEASE SIGNOFF
-----Original Message-----
From: Irv Mullins <irv at ELLIJAY.COM>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: 15 November 1999 15:25
Subject: Re: Euphoria features
>----- Original Message -----
>From: Everett Williams <rett at GVTC.COM>
>To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
>Sent: Monday, November 15, 1999 3:10 AM
>Subject: Re: Euphoria features
>
>
><snip>
>> Also, in Euphoria, I would like to know where
>> to you would go. The only thing that resembles a label or address in
>> Euphoria is a procedure name. If you goto a procedure, where will you
>> return to. If you goto a function name to whom will you return the value
>> and where will you return to. It appears that Euphoria was designed
>> to be goto proof. Now, we need not only goto's, but labels.
>
>Well of course we need labels. How else will I be able to write wonderful,
>meaningful, bugfree, useful code like:
>PERFORM LBL2X4 THRU LBL4X5 VARYING X BY 6
>
>Regards,
>Irv
63. Re: Euphoria features
On Fri, 19 Nov 1999, you wrote:
> i have done almost enything to off from this euphoria but
> nothing helps.
> i do not want all this stuped infos to my email
>
> PLEASE SIGNOFF
>
Everything except read the directions:
Getting off the list
To leave the list, send an e-mail message to:
LISTSERV at LISTSERV.MUOHIO.EDU
The subject of your message doesn't matter, but the body of your message must
be:
SIGNOFF EUPHORIA
Irv
64. Re: Euphoria features
Hi Kat,
Tuesday, Tuesday, November 16, 1999, you wrote:
K> I think gasoline and automobiles should be eliminated, they both cause
K> far-reaching negative impact on the environment, and they are implicated in
K> the deaths of thousands of people each year in the usa. We can all use
K> horses, bicycles, and helicopters.
Horses and horse carts actually are much more difficult to control
than cars, and when they were in use caused a lot of deaths. In the
area of pollution, you haven't seen pollution till you've seen the,
uh, manure that a horse can put out. This increases flies, rats, and
therefore disease, which is a very potent form of pollution.
Umm, how does this relate to Euphoria and this thread? Let me see if I
can dig (so to speak) my way out. Maybe this applies to gotos as well,
they, like the "good old days", only seem better than what you want to
do now. Convenient in some ways, but not in others. Everything has a
trade off. Did that bring it back around to Euphoria?
Jonathan mailto:jcchina at bigfoot.com
65. Re: Euphoria features
----- Original Message -----
From: Jonathan Craft <jcchina at BIGFOOT.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Sunday, November 21, 1999 1:10 AM
Subject: Re: Euphoria features
> Hi Kat,
>
> Tuesday, Tuesday, November 16, 1999, you wrote:
>
> K> I think gasoline and automobiles should be eliminated, they both cause
> K> far-reaching negative impact on the environment, and they are
implicated in
> K> the deaths of thousands of people each year in the usa. We can all use
> K> horses, bicycles, and helicopters.
>
> Horses and horse carts actually are much more difficult to control
> than cars, and when they were in use caused a lot of deaths. In the
> area of pollution, you haven't seen pollution till you've seen the,
> uh, manure that a horse can put out. This increases flies, rats, and
> therefore disease, which is a very potent form of pollution.
>
> Umm, how does this relate to Euphoria and this thread?
It's called sarcasm, read the lines in the email i replied to.
> Let me see if I
> can dig (so to speak) my way out. Maybe this applies to gotos as well,
> they, like the "good old days", only seem better than what you want to
> do now. Convenient in some ways, but not in others. Everything has a
> trade off. Did that bring it back around to Euphoria?
I didn't know we had left Eu as a topic till this email.
Btw, you didn't address bicycles or helicopters.
Kat
66. Re: Euphoria features
Hi Kat,
Saturday, Saturday, November 20, 1999, you wrote:
>> K> I think gasoline and automobiles should be eliminated, they both cause
>> K> far-reaching negative impact on the environment, and they are
K> implicated in
>> K> the deaths of thousands of people each year in the usa. We can all use
>> K> horses, bicycles, and helicopters.
>>
>> Horses and horse carts actually are much more difficult to control
>> than cars, and when they were in use caused a lot of deaths. In the
>> area of pollution, you haven't seen pollution till you've seen the,
>> uh, manure that a horse can put out. This increases flies, rats, and
>> therefore disease, which is a very potent form of pollution.
>>
>> Umm, how does this relate to Euphoria and this thread?
K> It's called sarcasm, read the lines in the email i replied to.
And it's called joking. My tongue was firmly in my cheek when I wrote
it. Sorry if it didn't fly, but my humor is sometimes a bit dry. The
question was to myself as rhetorical one which I then proceed to
answer. I can see where that may have been misleading.
>> Let me see if I
>> can dig (so to speak) my way out. Maybe this applies to gotos as well,
>> they, like the "good old days", only seem better than what you want to
>> do now. Convenient in some ways, but not in others. Everything has a
>> trade off. Did that bring it back around to Euphoria?
K> I didn't know we had left Eu as a topic till this email.
And here I thought I'd done a good job of making an apropos
application...;->.
K> Btw, you didn't address bicycles or helicopters.
Well, you can't solve all the world's problems in only one
message...wait till the next one.
Jonathan mailto:jcchina at bigfoot.com
