1. RE: GOTO - A fresh perspective?
doc at edgetap.net wrote:
> Hi all,
...
> First, I would
> like to say that my general impression of everyone using this forum is
> that you are all pretty intelligent, thoughtful and considerate, if not
> agreeable, in your replies. However, this makes it all the more
> difficult for me to figure why you seem to be adopting language-centric
> arguments in your debate rather than accepting that if a feature helps
> someone do something easier then it is intrinsically "good" for them, if
>
> not for you personally.
I think your focus on the programmer is basically right. However, I
would argue by example that it is not necessarily the best thing for a
programming language to add features that one or more people like. I
offer perl is an example of a programming language where all of the
developers kept adding features to make it the way they wanted it.
Subroutine calls should be identified by using an ampersand in front of
their names, unless you don't want to, and parameters passed to a
subroutine should be enclosed in parentheses, unless you don't want to.
Scalar variables should have a dollar sign in front of their name, but
if you don't include the dollar sign and perl recognizes the word as a
variable then the dollar sign is optional. This type of do it if you
want or don't if you don't want has been done so much that different
programmers writing code in perl can use such widely divergent sets of
which punctuations they use that they almost look like different
languages. These options have made parsing perl more difficult and can
hardly have speeded up the resulting code. There are so many ways to do
the same things in perl that having used perl for years I still see
features and tricks in perl that I'd never even heard of before. This
makes it very difficult to pick up someone else's code to use or modify
it since they might well have used some feature that I'd never seen
before.
I offer this as an example of what can happen when too many features are
loaded into a language because "someone wanted it." While there are
features I would like to see added to Euphoria so that it would be
easier to interface with DLLs and do other things more easily, I can't
begrudge Robert trying to maintain his own vision for what Euphoria
should be. I just wish he was getting it done a bit faster. 
-JoKeR
(now using a new email address, formerly kriviere at mindspring.com)
2. RE: GOTO - A fresh perspective?
Hi 'Doc',
doc at edgetap.net wrote:
> Hi all,
>
> I will try and keep this short although I feel like writing volumes!
> First a short history: early last year I came across Euphoria and was
> (almost) gobsmacked at the flexibilty it seemed to offer. So I
> downloaded and set to work writing an test program for doing OpenGL
> graphics. Within days I had networking and had two machines with
> synchronised displays. The exercise showed me that Euphoria was
> However, this makes it all the more
> difficult for me to figure why you seem to be adopting language-centric
> arguments in your debate rather than accepting that if a feature helps
> someone do something easier then it is intrinsically "good" for them, if
>
> not for you personally.
Well, for me it's because it's the only real argument. Performance? Can
probably be worked around, and even if not it just bogs the discussion
into a comparison of trade-offs.
But I agree with you... if someone is helped by a GOTO, then more power
to them. I'm not going to try to strip it away from all their languages
(although I've heard that crusade-call before.)
>From this it is obvious that I consider a
> programming language as nothing more than a tool and that the programmer
>
> is THE most important factor in the overall equation.
Mmm, I see you're position, but I can't whole-heartedly agree with it.
No *one* programmer is that important (I think we all understand that),
and honestly, even if a vast majority of programmers are the
consideration, there are other factors that I think can take precedence.
<snip>
>Bluntly, it is the programmer who is
> important not the language, and it is the programmer who should be given
>
> the choice and the decision should not be made for him/her by other
> people who have no use for a feature.
To a good extent, I agree. Hence, the helpfulness of source code for a
language. Although I do wish to point out that I don't believe
programmers are the ultimate, final end-concern anymore than I think
consumers are the ultimate, final end-concern in running a business.
<snip>
> RapidEuphoria giving Kat, at least, the choice to use GoTo without
> going through hoops will of course make the decision a no-brainer 
Well, I understand your position. I've been there myself.
But don't you think that if you're evaluating Euphoria based on it's
lack of a GOTO, that there may be others who evaluate it based on it's
consistency, or even just the presence of a GOTO? Surely both of those
catagories need to be factored in as well?
Rod Jackson
3. RE: GOTO - A fresh perspective?
On 10 Feb 2002, at 21:22, Kenneth Riviere wrote:
>
>
> doc at edgetap.net wrote:
> > Hi all,
> ...
> > First, I would
> > like to say that my general impression of everyone using this forum is
> > that you are all pretty intelligent, thoughtful and considerate, if not
> > agreeable, in your replies. However, this makes it all the more
> > difficult for me to figure why you seem to be adopting language-centric
> > arguments in your debate rather than accepting that if a feature helps
> > someone do something easier then it is intrinsically "good" for them, if
> >
> > not for you personally.
Correct. You use the "continue" to get out of a loop, i'll use "goto eoloop".
Goto is at least nice enough to have a labeled :target: for where it is going
next!
> I think your focus on the programmer is basically right. However, I
> would argue by example that it is not necessarily the best thing for a
> programming language to add features that one or more people like. I
> offer perl is an example of a programming language where all of the
> developers kept adding features to make it the way they wanted it.
>
> Subroutine calls should be identified by using an ampersand in front of
> their names, unless you don't want to, and parameters passed to a
> subroutine should be enclosed in parentheses, unless you don't want to.
> Scalar variables should have a dollar sign in front of their name, but
> if you don't include the dollar sign and perl recognizes the word as a
> variable then the dollar sign is optional. This type of do it if you
> want or don't if you don't want has been done so much that different
> programmers writing code in perl can use such widely divergent sets of
> which punctuations they use that they almost look like different
> languages. These options have made parsing perl more difficult and can
> hardly have speeded up the resulting code. There are so many ways to do
> the same things in perl that having used perl for years I still see
> features and tricks in perl that I'd never even heard of before. This
> makes it very difficult to pick up someone else's code to use or modify
> it since they might well have used some feature that I'd never seen
> before.
But no one is asking for that sorta ambiguity in Eu, in fact, some of us are
worried about forks in the language like that.
The C64 used "gosub". Using functions and procedures in newer languages
replaced "gosub", but what if i had said way back then "no more gosub, it
makes for spagetti code, from now on, you must redefine names for the
subroutines, and use the routine name in place of the gosub() you are using
now"? Just think of the people reading the code, and seeing a new word they
have never seen, that is not in the core language help files!! And worse yet,
they must be placed before they are called in the code, so no more nested
dependancies!! What, there is a "main" and the program actually starts at
the bottom of the page?? Sheesh, no one would use a language like that!
Oh, but they do, they just rename the functionality and hide the details, and
force the user to learn the details of each new subset of the functionality in
the new syntax words, like "continue" and "exit". What's next, "break"?
Maybe a "restart_loop()"? Changing the control vars in the "for" line?
Parameters for "continue()"? No thanks, gimme the plain and simple "goto".
> I offer this as an example of what can happen when too many features are
> loaded into a language because "someone wanted it." While there are
> features I would like to see added to Euphoria so that it would be
> easier to interface with DLLs and do other things more easily, I can't
> begrudge Robert trying to maintain his own vision for what Euphoria
> should be. I just wish he was getting it done a bit faster.
Simply allowing backwards-looking target resolution would have meant
routine_id() wasn't needed. It would have been simple, imho, simply don't
raise an error for undefined word until it is still undefined at the end of the
compile. Somehow, to me, tossing in patches like "routine_id()" breaks the
vision of the language far more than a moderately restricted "goto" like Karl
made. If nothing else, Rob could have made the "routine_id()" internal, acting
by default on all functions and procedures, and simply said "from now on,
you don't need to define the function before you call it". But instead, he
added a new word to the language.
I bet Euman or Karl makes Eu threaded first too. Or execute vars or files as
if they had been proper global includes.
Sequences are great, truely wonderful, as good as chocolate. I use them as
strings, as nested strings, as data files. I don't restrict them to a string
type
where "char" must be only one char. Sequences means i don't haveto map
arrays of byte over the strings, and make wierd arrays of pointers to each
part of the string like i was doing in pascal. Nested sequences means i can
return nests of things, not one predefined thing. Giving us Lisp's sequences
with a Basic language syntax, that's Eu's claim to fame. Allowing better flow
control with a "goto", even more use of the sequences with exec(sequence
s), threads, etc., can only make Eu better and more appealing to a wider
audience.
Kat
4. RE: GOTO - A fresh perspective?
Kat wrote:
> Simply allowing backwards-looking target resolution would have meant
> routine_id() wasn't needed. It would have been simple, imho, simply
> don't
> raise an error for undefined word until it is still undefined at the end
> of the
> compile. Somehow, to me, tossing in patches like "routine_id()" breaks
> the
> vision of the language far more than a moderately restricted "goto" like
> Karl
> made. If nothing else, Rob could have made the "routine_id()" internal,
> acting
> by default on all functions and procedures, and simply said "from now
> on,
> you don't need to define the function before you call it". But instead,
> he
> added a new word to the language.
>
I agree with this 100%. Of course, not having routine_id would break
Win32lib all over the place. In order to be able to "register" a
routine to associate with an event there would still have to be some way
to pass something so that the routine can be linked into that library.
Of course, such a radical change as backward-looking target resolution
might have other consequences which would make linking into an event
handler easier.
> Sequences are great, truely wonderful, as good as chocolate. I use them
> as
> strings, as nested strings, as data files. I don't restrict them to a
> string type
> where "char" must be only one char. Sequences means i don't haveto map
> arrays of byte over the strings, and make wierd arrays of pointers to
> each
> part of the string like i was doing in pascal. Nested sequences means i
> can
> return nests of things, not one predefined thing. Giving us Lisp's
> sequences
> with a Basic language syntax, that's Eu's claim to fame.
Again, I agree. The sequences and the ease with which complex data can
be nested even beyond the limits of RAM are the thing that excites me
most about Euphoria. I was ready to use it based on that before I
realized how much faster it is than many other languages (my
long-beloved perl is left in the dust by Euphoria based on speed).
> Allowing better flow
> control with a "goto", even more use of the sequences with exec(sequence
>
> s), threads, etc., can only make Eu better and more appealing to a wider
>
> audience.
>
> Kat
And here we part ways. Different drummers, I guess.
-JoKeR
5. RE: GOTO - A fresh perspective?
Hi Euler,
I haven't been following the leadup to your message but has anyone
suggested the "Beginners Guide to Euphoria"?
It's a tutorial program that I have heard many good things about.
It's a little old now and probably doesn't have some of the new
language features. It's probably still worth looking at.
You can find it under Documentation on the archive at the RDS
web site.
With regard to "what Euphoria is?" and "What's Euphoria's future?"
... a have over the years posted many messages with similar content
and the end result is ... Euphoria IS a hobby language. A few (very
few) have produced commercial quality apps. These seem to be
very specialised. Saying that Euphoria can still be very useful but
that doesn't mean it's the best tool for alot of jobs. Also if your
deadicated enough you to can produce commercial quality apps.
It's a difficult road to travel though.
At some time in the future it "might" become easier to produce better
quality software ... easier ... as some of the major libraries mature
(win32lib, IDE etc).
Take and use Euphoria for what it is, not what it can be.
I'm sure everyone is interested in ideas that can increase the
use of Euphoria throughout the world.
As with many many "internet" based projects the onus is on "you" to do
what others haven't.
I too would love heaps more people programming in Euphoria but in the
end you have to be happy with what it can do for you now. You have
to be happy for what Euphoria is now. If your not happy with that
then Euphoria is not for you.
Change in the world of Euphoria is very slow. A year can go by with
no changes to base Euphoria interpreter.
Saying all that, I always seem to come back to tinker with my Euphoria
projects so I guess I must enjoy it.
Take Care,
Ray Smith
> This is terrible, I'm afraid. I'm quite confident that Euphoria will be
> on
> limbo while languages it can surpass easily, by any means, will last.
> I'm not
> sure if it's of RDS interest but if they *truly* believe in their
> product they
> should put some money on it. An unknown product is a dead product. How
> could I
> manage to (learn) teach Euphoria to others without books? Another
> question:
> what will last after all of you get your own copy of Euphoria? Will RDS
> just
> shut doors or would they last with a 50% income now and then? I just
> can't
> accept that. Let me put this way: RDS need to make a big move. They must
> turn
> Euphoria into a popular language. They have to convince someone with the
>
> ability and skills to spread the word as it is not of their business to
> spred
> the word. Unfortunately, hundreds of thousands users aren't enough in a
> world
> that counts in billions.
>
> > Someone could post a book on the internet, so that you could print your
> > own
> > copy, but then they would be doing a lot of work for free, so I don't
> > think
> > that's going to happen either.
> >
> Well, could be an e-book, a lot cheaper than on paper. Could be done at
> home by
> anyone with knowledge and writing skills. It could be made in PDF
> protected
> mode and selled by the Net. I don't mind the media: paper or e-paper (I
> can
> print it later), but I believe that information, to be valuable and
> understandable, at least to the great majority of persons, must be
> compiled as
> a book, not on information chunks.
>
> I'm not talking on freework either. I'm ready to pay for it. I know that
> you
> and others that are not newcomers like me don't need this, but you
> should
> consider very much that you're quite alone. You have the knowledge but
> don't
> have number. Without a minimum amount there will be no change, not
> enough
> *mass* to sustain a chain reaction. This may change from euphoria to
> entropy.
>
> Sorry if I'm so pessimist. Maybe I'm just on a bad day.
>
> Warmest Regards,
>
> -- Euler German
>
>
Ray Smith
http://www.geocities.com/ray_223
