1. Ideas for next Eu
- Posted by Darth Maul <Prog_Matt at YAHOO.COM>
Nov 05, 1999
-
Last edited Nov 06, 1999
You know how in Q(uirk)Basic, all values are passed to FUNCTIONs/SUBs by
reference? Maybe you should add a 'byref' keyword so that variables are pas-
sed by reference. This would make porting progs from QB to Eu a little
easier.
- Matt
2. Re: Ideas for next Eu
On Fri, 5 Nov 1999, Darth Maul wrote:
> You know how in Q(uirk)Basic, all values are passed to FUNCTIONs/SUBs by
> reference? Maybe you should add a 'byref' keyword so that variables are pas-
> sed by reference. This would make porting progs from QB to Eu a little
> easier.
Ick! IMHO it is a poor practice to have variables passed to a sub or
function be globally changed by that sub or function. Besides, you
can already easily accomplish that same effect by declaring your
variables outside of your subs/functions (then you don't even need to
pass them). There is more than one way to get around your porting problem
than to introduce that ugliness into Euphoria. But again, that's just my
opinion.
Can you provide a better reason for this inclusion (besides making it
easier to port poorly written QB progs)?
-- Brian
3. Re: Ideas for next Eu
- Posted by simulat <simulat at INTERGATE.BC.CA>
Nov 05, 1999
-
Last edited Nov 06, 1999
Hi
The programs I write are pretty self-contained; that is, there's no
interaction with the user. In that context, it's kind of a nuisance to not
be able to modify global variables from inside functions. Here's an example.
I have a sequence called "tiles" that holds a bunch of bitmaps. The bitmaps
are manipulated by placing tiles[x] onto the screen and then drawing on the
screen then saving the screen to tiles[x] again. Sometimes, the functions
that accesses tiles are deeply buried within strings of other functions. I
end up having to pass tiles through a bunch of functions that don't use it,
just to make it available for one that does (but that might not even be
called), and then I have to pass the modified value back up the chain. I
think this is less than elegant, maybe even ugly. It's certainly a hassle.
It would be a lot easier if there was just a way to modify the global
variable.
OK - I admit it - I learned to program on something called "Level 1 BASIC".
All the variables were global. Variable names could be up to 2 characters
long. I found that if I needed a variable to be local that it was easy to
do, but that it was rarely necessary. It didn't take long for me to
appreciate the benefits of structured programming and I found it easy to
implement in that completely unstructured environment.
I understand that when programs are written by large teams, and when
software is used by many people at once, extreme efforts must be taken to
protect data integrity. But that's not what I'm doing. I write programs that
make pictures. It's no big deal if it crashes - it's not like it's
controlling an airplane or anything. I find that the subtle logic bug is
rare, but that the crashes caused by the safety features of structured
programming (like not letting functions modify global variables) are a
constant hassle.
I like Euphoria. It works just perfectly for the kind of programming that I
do. One of it's benefits is that it has very little programming overhead.
Personally, I think that "beauty" would be found by making the language
looser and more flexible. There are lots of languages around that are rigid.
Bye
Martin
>From: Brian K. Broker <bkb at CNW.COM>
> On Fri, 5 Nov 1999, Darth Maul wrote:
>
> > You know how in Q(uirk)Basic, all values are passed to FUNCTIONs/SUBs by
> > reference? Maybe you should add a 'byref' keyword so that variables are
pas-
> > sed by reference. This would make porting progs from QB to Eu a little
> > easier.
>
> Ick! IMHO it is a poor practice to have variables passed to a sub or
> function be globally changed by that sub or function. Besides, you
> can already easily accomplish that same effect by declaring your
> variables outside of your subs/functions (then you don't even need to
> pass them). There is more than one way to get around your porting problem
> than to introduce that ugliness into Euphoria. But again, that's just my
> opinion.
>
> Can you provide a better reason for this inclusion (besides making it
> easier to port poorly written QB progs)?
>
> -- Brian
>
4. Re: Ideas for next Eu
It sounds as if you are doing something of this nature.
function this1(sequence xy)
return xy+1
end procedure
function this2(sequence xy)
xy = this1(xy)
do_other_things()
end function
function this3(xy)
xy = this2(xy)
end function
In this case I would probably do the following.
sequence xy
procedure this1()
xy += 1
end procedure
procedure this2()
this1()
do_other_things()
end procedure
procedure this3()
this2()
end procedure
Notice that xy is still local yet it is available to all the
routines that are declared after it. This works as long as
all of the routines are in the same file.
If you wish to span include files you would be force to use
global. Such as:
global sequence xy
include this1.e
include this2.e
procedure this3()
this2()
end procedure
xy is then available to everything after the global sequence xy
statement.
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: simulat <simulat at INTERGATE.BC.CA>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Saturday, November 06, 1999 2:44 AM
Subject: Re: Ideas for next Eu
> ---------------------- Information from the mail
header -----------------------
> Sender: Euphoria Programming for MS-DOS
<EUPHORIA at LISTSERV.MUOHIO.EDU>
> Poster: simulat <simulat at INTERGATE.BC.CA>
> Subject: Re: Ideas for next Eu
> --------------------------------------------------------------------------
-----
>
> Hi
> The programs I write are pretty self-contained; that is, there's no
> interaction with the user. In that context, it's kind of a nuisance to not
> be able to modify global variables from inside functions. Here's an
example.
>
> I have a sequence called "tiles" that holds a bunch of bitmaps. The
bitmaps
> are manipulated by placing tiles[x] onto the screen and then drawing on
the
> screen then saving the screen to tiles[x] again. Sometimes, the functions
> that accesses tiles are deeply buried within strings of other functions. I
> end up having to pass tiles through a bunch of functions that don't use
it,
> just to make it available for one that does (but that might not even be
> called), and then I have to pass the modified value back up the chain. I
> think this is less than elegant, maybe even ugly. It's certainly a hassle.
> It would be a lot easier if there was just a way to modify the global
> variable.
>
> OK - I admit it - I learned to program on something called "Level 1
BASIC".
> All the variables were global. Variable names could be up to 2 characters
> long. I found that if I needed a variable to be local that it was easy to
> do, but that it was rarely necessary. It didn't take long for me to
> appreciate the benefits of structured programming and I found it easy to
> implement in that completely unstructured environment.
>
> I understand that when programs are written by large teams, and when
> software is used by many people at once, extreme efforts must be taken to
> protect data integrity. But that's not what I'm doing. I write programs
that
> make pictures. It's no big deal if it crashes - it's not like it's
> controlling an airplane or anything. I find that the subtle logic bug is
> rare, but that the crashes caused by the safety features of structured
> programming (like not letting functions modify global variables) are a
> constant hassle.
>
> I like Euphoria. It works just perfectly for the kind of programming that
I
> do. One of it's benefits is that it has very little programming overhead.
> Personally, I think that "beauty" would be found by making the language
> looser and more flexible. There are lots of languages around that are
rigid.
>
> Bye
> Martin
>
>
>
>
>
> >From: Brian K. Broker <bkb at CNW.COM>
> > On Fri, 5 Nov 1999, Darth Maul wrote:
> >
> > > You know how in Q(uirk)Basic, all values are passed to FUNCTIONs/SUBs
by
> > > reference? Maybe you should add a 'byref' keyword so that variables
are
> pas-
> > > sed by reference. This would make porting progs from QB to Eu a little
> > > easier.
> >
> > Ick! IMHO it is a poor practice to have variables passed to a sub or
> > function be globally changed by that sub or function. Besides, you
> > can already easily accomplish that same effect by declaring your
> > variables outside of your subs/functions (then you don't even need to
> > pass them). There is more than one way to get around your porting
problem
> > than to introduce that ugliness into Euphoria. But again, that's just
my
> > opinion.
> >
> > Can you provide a better reason for this inclusion (besides making it
> > easier to port poorly written QB progs)?
> >
> > -- Brian
> >
>
5. Re: Ideas for next Eu
Thanks Lucius - you've cleared up a couple of issues for me.
But still, it seems like a workaround to me. I think it would be better to
have all variables global by default, with the ability to make variables
local if you want.
In following the various discussions on the List, I see that lots of people
are pushing Euphoria towards being a mainstream language like C, that is
used to write commercial and industrial software. I think that this is a
mistake. There are lots of languages around that are very rigid, that
absolutely force the user to be very particular about how data and
programming structures are handled. And I agree that you need languages like
that for major software packages developed by large teams.
But I don't need that sort of language for my work. I need a language that
is fluid, gives me access to all the resources of my computer, and that has
a minimum of programming overhead.
Let's look at the present example from Lucius:
>If you wish to span include files you would be force to use
>global. Such as:
>
>global sequence xy
>
>include this1.e
>include this2.e
>
>procedure this3()
>this2()
>end procedure
>
>xy is then available to everything after the global sequence xy
>statement.
If you get the declaration wrong (ie "global sequence xy"), then the program
crashes. Why bother with the overhead of the declaration? Why not just leave
it out?
This is not a trivial concern. In my practice, I find that it takes as much
effort to debug the programming overhead as it does to debug the program
logic.
In fact, it takes quite a bit more; the hassles I get when I move functions
from one library to another are entirely overhead problems, because the
logic already works. I think that the effort spent in making the overhead
work is a cost imposed on me by a flawed paradigm. The paradigm is to
prevent logical errors by rigid programming practice enforced by the
language. Maybe an entity like NASA needs to work with such a rigid
paradigm, but I sure don't. It's just a bunch of stuff in the way.
Bye
Martin
6. Re: Ideas for next Eu
----- Original Message -----
From: simulat <simulat at INTERGATE.BC.CA>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Sunday, November 07, 1999 12:41 PM
Subject: Re: Ideas for next Eu
>
> This is not a trivial concern. In my practice, I find that it takes as
much
> effort to debug the programming overhead as it does to debug the program
> logic.
> In fact, it takes quite a bit more; the hassles I get when I move
functions
> from one library to another are entirely overhead problems, because the
> logic already works. I think that the effort spent in making the overhead
> work is a cost imposed on me by a flawed paradigm. The paradigm is to
> prevent logical errors by rigid programming practice enforced by the
> language. Maybe an entity like NASA needs to work with such a rigid
> paradigm, but I sure don't. It's just a bunch of stuff in the way.
Well, Martin, I think you'll like my new programming language. It does
away with all that "unnecessary overhead".
It has handy global variables that do not need to be declared in advance.
They use easy to remember names: 'A' thru 'Z'.
Right now, this paradigm-less language only runs on the TRS-80 model I,
but because of the great demand, no doubt it will soon be ported to the PC.
Irv
7. Re: Ideas for next Eu
- Posted by Ad Rienks <kwibus at ZONNET.NL>
Nov 07, 1999
-
Last edited Nov 08, 1999
The language you describe also runs on a Spectrum ZX80. To make things even
easier, the variables can only be integers or simple strings.
Ad
----- Oorspronkelijk bericht -----
Van: Irv Mullins <irv at ELLIJAY.COM>
Aan: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Verzonden: zondag 7 november 1999 20:18
Onderwerp: Re: Ideas for next Eu
> ----- Original Message -----
> From: simulat <simulat at INTERGATE.BC.CA>
> To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
> Sent: Sunday, November 07, 1999 12:41 PM
> Subject: Re: Ideas for next Eu
>
> >
> > This is not a trivial concern. In my practice, I find that it takes as
> much
> > effort to debug the programming overhead as it does to debug the program
> > logic.
> > In fact, it takes quite a bit more; the hassles I get when I move
> functions
> > from one library to another are entirely overhead problems, because the
> > logic already works. I think that the effort spent in making the
overhead
> > work is a cost imposed on me by a flawed paradigm. The paradigm is to
> > prevent logical errors by rigid programming practice enforced by the
> > language. Maybe an entity like NASA needs to work with such a rigid
> > paradigm, but I sure don't. It's just a bunch of stuff in the way.
>
> Well, Martin, I think you'll like my new programming language. It does
> away with all that "unnecessary overhead".
> It has handy global variables that do not need to be declared in advance.
> They use easy to remember names: 'A' thru 'Z'.
> Right now, this paradigm-less language only runs on the TRS-80 model I,
> but because of the great demand, no doubt it will soon be ported to the
PC.
>
> Irv
8. Re: Ideas for next Eu
Irv,
You know just as well as I do, public ridicule is the most effective
way to silence people with uncomfortable ideas. Your remarks are very
cute, but on par with the contribution of the other 'defender of the
faith' in this debate, Brian K. Broker, who obviously thinks, the
design of a language is some sort of a beauty contest.
Martin has raised several legitimate concerns, in a very polite
language. He also gave some of his reasons, and I for one agree with
just about every thing he said. But that's beside the point. Please,
let's forget, just for a moment, what high priests of structural
design, or object oriented principles, or any other failed religion
are trying to dictate to us. I think, Martin's views deserve more than
a nasty sneer. jiri
9. Re: Ideas for next Eu
My language has only 1 variable name "A" and it can accept any data type.
I am leaving up to the programmer to keep track of it's contents and
it's scope.
10. Re: Ideas for next Eu
How do you write a useful program with only one variable??
----- Original Message -----
From: Bernie Ryan <bwryan at PCOM.NET>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Sunday, November 07, 1999 3:51 PM
Subject: Re: Ideas for next Eu
> My language has only 1 variable name "A" and it can accept any data type.
>
> I am leaving up to the programmer to keep track of it's contents and
>
> it's scope.
>
11. Re: Ideas for next Eu
- Posted by Pete Eberlein <xseal at HARBORSIDE.COM>
Nov 07, 1999
-
Last edited Nov 08, 1999
Bernie said that the variable A can accept any data type, and I take that to
include sequences. You can put all your neccessary values in a sequence and
manipulate them using subscripts, and there you have it. Bernie, we need a
name for this language... since it only allows the variable A, how about
calling it Agony (as opposed to Euphoria 
On Sun, 7 Nov 1999 17:50:13 -0600, Kat <KSMiTH at PELL.NET> wrote:
>How do you write a useful program with only one variable??
>
>
>----- Original Message -----
>From: Bernie Ryan <bwryan at PCOM.NET>
>To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
>Sent: Sunday, November 07, 1999 3:51 PM
>Subject: Re: Ideas for next Eu
>
>
>> My language has only 1 variable name "A" and it can accept any data type.
>>
>> I am leaving up to the programmer to keep track of it's contents and
>>
>> it's scope.
>>
12. Re: Ideas for next Eu
>How do you write a useful program with only one variable??
You make it Global, and then re-use it MANY times 
m
13. Re: Ideas for next Eu
- Posted by Irv Mullins <irv at ELLIJAY.COM>
Nov 07, 1999
-
Last edited Nov 08, 1999
----- Original Message -----
From: Kat <KSMiTH at PELL.NET>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Sunday, November 07, 1999 6:50 PM
Subject: Re: Ideas for next Eu
> How do you write a useful program with only one variable??
Instances
14. Re: Ideas for next Eu
Aw -- c'mon Irv - I already confessed to that. Where do you think I got such
a good idea?
And In fact, there are emulators around for it. That version of BASIC was
written by Microsoft, and it may be the last piece of efficient code that
they wrote.
>>OK - I admit it - I learned to program on something called "Level 1
BASIC".
> Well, Martin, I think you'll like my new programming language. It does
> away with all that "unnecessary overhead".
> It has handy global variables that do not need to be declared in advance.
> They use easy to remember names: 'A' thru 'Z'.
> Right now, this paradigm-less language only runs on the TRS-80 model I,
> but because of the great demand, no doubt it will soon be ported to the
PC.
>
> Irv
>
15. Re: Ideas for next Eu
- Posted by Irv Mullins <irv at ELLIJAY.COM>
Nov 07, 1999
-
Last edited Nov 08, 1999
----- Original Message -----
From: Jiri Babor <J.Babor at GNS.CRI.NZ>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Sunday, November 07, 1999 4:57 PM
Subject: Re: Ideas for next Eu
> Irv,
>
> You know just as well as I do, public ridicule is the most effective
> way to silence people with uncomfortable ideas. Your remarks are very
> cute, but on par with the contribution of the other 'defender of the
> faith' in this debate, Brian K. Broker, who obviously thinks, the
> design of a language is some sort of a beauty contest.
>
> Martin has raised several legitimate concerns, in a very polite
> language. He also gave some of his reasons, and I for one agree with
> just about every thing he said. But that's beside the point. Please,
> let's forget, just for a moment, what high priests of structural
> design, or object oriented principles, or any other failed religion
> are trying to dictate to us. I think, Martin's views deserve more than
> a nasty sneer. jiri
Martin's post, while certainly polite, seems most likely a skillful troll.
I rather enjoyed it, in fact. If I am wrong, and he was serious, then I
would
really like to see examples of this "fluid" language, and how it would make
programming easier.
Irv
16. Re: Ideas for next Eu
On Mon, 8 Nov 1999 10:57:05 +1300, Jiri Babor <J.Babor at GNS.CRI.NZ> wrote:
>You know just as well as I do, public ridicule is the most effective
>way to silence people with uncomfortable ideas. Your remarks are very
>cute, but on par with the contribution of the other 'defender of the
>faith' in this debate, Brian K. Broker, who obviously thinks, the
>design of a language is some sort of a beauty contest.
>
>Martin has raised several legitimate concerns, in a very polite
>language. He also gave some of his reasons, and I for one agree with
>just about every thing he said. But that's beside the point. Please,
>let's forget, just for a moment, what high priests of structural
>design, or object oriented principles, or any other failed religion
>are trying to dictate to us. I think, Martin's views deserve more than
>a nasty sneer. jiri
yeah, there is a rather sarcastic tone in my initial reply (sorry if I
offended anyone) but I did make it clear that I was merely expressing my
opinion. As with any 'enhancement', just because it's there doesn't mean I
have to use it. But if somebody wrote a library that changed the variables
I passed... well, I think that would make for some difficult debugging.
-- Brian
17. Re: Ideas for next Eu
- Posted by simulat <simulat at INTERGATE.BC.CA>
Nov 07, 1999
-
Last edited Nov 08, 1999
Hi
Irv said:
> Martin's post, while certainly polite, seems most likely a skillful troll.
> I rather enjoyed it, in fact. If I am wrong, and he was serious, then I
> would
> really like to see examples of this "fluid" language, and how it would
make
> programming easier.
>
> Irv
I'm sorry to disappoint you Irv, but my posting was serious.
I've already given an example of a "fluid" language (in the sense I'm
talking about). Level 1 BASIC that ran (still does) on a TRS80 Model 1. It
had lots of limitations, but it you didn't have to worry about whether a
variable was local or global. They were all global. That language was almost
completely unstructured, compared to say, C. I wrote a lot of spaghetti
code. Eventually I imposed my own structure by developing a structured
programming style. I wrote some pretty interesting software on that system,
and some of it (a halftone exposure calculator) is still in daily use
(though translated to GWBasic).
Eventually I developed my own system for creating local variables and
implemented it whenever I needed it. I had no trouble with having variables
global as a default. And this was on a system where the range of variable
names was very small.
The problem with primitive languages wasn't how you used variables, it was
just the lack of memory, and the limits of crude graphics that made me want
to move on.
Euphoria is an excellent example of a fluid language, even if I do think it
could loosen up a bit. It's only got a few data types, you can make more if
you want, and as Lucius demonstrated, it's easy to make variables global if
you want. And sequences must be one of the most flexible data types going.
I'm self educated a computerist. I've tried hard, on several occasions to
master C. I could get programs going, but I was never comfortable with it.
The problem was the infinite data types, combined with the pointer based
parameter passing. The simplest task seemed complicated and obscure by the
time it was done.
Now that stuff is what I call programming overhead. It may be worth the
trouble in some circumstances, but it is an expense. The question is "When
is the benefit worth the expense?" The point I make is that in lots of
circumstances the programming overhead has no benefit and is quite
expensive. What's the justification for the expense in those circumstances?
Many of us have commented on what a pleasure Euphoria is to use. For me, it
lets me do whatever I want with very little "expense". It's got this great
international community extending it in all kinds of directions. It's one of
the few things in the world to live up to it's name. I think that fluidity
is the way to go.
So why is "global" equated with "ugly"?
And how does forcing people to do things that aren't necessary, but are
error prone, make programming easier?
Bye
Martin
18. Re: Ideas for next Eu
On Sun, 7 Nov 1999 09:41:27 -0800, simulat <simulat at INTERGATE.BC.CA> wrote:
>But I don't need that sort of language for my work. I need a language that
>is fluid, gives me access to all the resources of my computer, and that has
>a minimum of programming overhead.
>
>This is not a trivial concern. In my practice, I find that it takes as much
>effort to debug the programming overhead as it does to debug the program
>logic.
>In fact, it takes quite a bit more; the hassles I get when I move functions
>from one library to another are entirely overhead problems, because the
>logic already works. I think that the effort spent in making the overhead
>work is a cost imposed on me by a flawed paradigm. The paradigm is to
>prevent logical errors by rigid programming practice enforced by the
>language. Maybe an entity like NASA needs to work with such a rigid
>paradigm, but I sure don't. It's just a bunch of stuff in the way.
As long as you limit yourself to programs less than a hundred lines and never
use any includes, your paradigm will work. Outside those bounds lurks absolute
disaster with everything defaulted to global. Every time you add a new variable,
you will have to make a run to see whether it will crash the program. What a
crock. Flexibility is wonderful, but as an old friend of mine once said, "Did you
ever try to sit in a flexible chair?" The word global isn't going to add one
extra line to your code, but it will document something that has "global"
effects. The flexibility of this language is in it's base design. Allowing things
such as you suggest will make every program a minefield. Their is an old aphorism
that says that things should be simple by design, not designed to be simple. A
language does not become flexible by allowing bad design and coding. Easy
extension to deal with new and changing environments makes a language or a
program flexible. In addition, a global-by-default memory model cannot be garbage
collected to any practical effect. Too much of memory is tied down by the global
variables long after it becomes disposable.
Everett L.(Rett) Williams
rett at gvtc.com
19. Re: Ideas for next Eu
- Posted by David Cuny <dcuny at LANSET.COM>
Nov 07, 1999
-
Last edited Nov 08, 1999
Martin wrote:
> Many of us have commented on what a pleasure
> Euphoria is to use. For me, it lets me do whatever
> I want with very little "expense".
I agree - it's generally pleasant writing code in Euphoria, and this isn't
something to be dismissed lightly.
I personally dislike it when the compiler forces me to do things that are
'good for me', when I know that it could certainly do things automatically.
Variable declaration is one of them, but I've gotten used to it by now.
Variable initialization, on the other hand, is one that still baffles me.
Euphoria forces you to declare your variables, but you have to assign them
on a different (logical) line of code. You can't just write:
integer foo = 0
but instead have to write:
integer foo
foo = 0
It seems to me that if you are going to force the user to declare variables,
and make the program abort if they are not initialized, you should let them
intialize the variables where they are being declared.
Shutting down the application without an error recovery routine is something
else I take issue to. The EE editor still (very rarely) will abort on an
error, and I'll lose data. If there was a vectored onError routine that
could execute before program shutdown, I'd at least be able to try to save a
backup file.
Robert seems adamant about keeping forward references difficult in Euphoria,
because he considers this to be bad coding style. This seems to me another
attempt to force the user into 'good coding style'. Sometimes there are
compelling reasons to use forward references, and I don't know that making
the user feel irritated that they have to jump through hoops is a good
thing.
Since I'm on a roll, I'm mention the scope constraints of routine_id and the
fact that the value starts at zero... did I miss anything?
OK, moving on to the future of Euphoria. I think that the namespace is
important. The ability to scale programs well is important, and it seems
that Java's thought the problem through fairly well. Someone floated the
idea of using Euphoria in HTML, similar to JavaScript - an intriguing idea.
-- David Cuny
20. Re: Ideas for next Eu
On Sun, 7 Nov 1999 23:39:14 -0800, David Cuny <dcuny at LANSET.COM> wrote:
>Martin wrote:
>
>> Many of us have commented on what a pleasure
>> Euphoria is to use. For me, it lets me do whatever
>> I want with very little "expense".
>
>I agree - it's generally pleasant writing code in Euphoria, and this isn't
>something to be dismissed lightly.
>
>I personally dislike it when the compiler forces me to do things that are
>'good for me', when I know that it could certainly do things automatically.
>Variable declaration is one of them, but I've gotten used to it by now.
Which is a huge step different than the compiler just letting you get into any
trouble that you wish as Mr. Martin basically suggested. Default global is a
complete non-starter for reasons I posted about four posts back on the list by
date.
>
>Variable initialization, on the other hand, is one that still baffles me.
>Euphoria forces you to declare your variables, but you have to assign them
>on a different (logical) line of code. You can't just write:
>
> integer foo = 0
>
>but instead have to write:
>
> integer foo
> foo = 0
>
>It seems to me that if you are going to force the user to declare variables,
>and make the program abort if they are not initialized, you should let them
>intialize the variables where they are being declared.
And, it speaks to consistency. What is listed as initialization is really just
an assignment like any other.
>Shutting down the application without an error recovery routine is something
>else I take issue to. The EE editor still (very rarely) will abort on an
>error, and I'll lose data. If there was a vectored onError routine that
>could execute before program shutdown, I'd at least be able to try to save a
>backup file.
I strongly agree here...especially if Euphoria is to be used for long running,
interactive programs. But herein lies a really ugly challenge to the scoping
rules. Error routines need to be supplied by their creator with certain
inalienable rights These include the need to have sufficient information to
know where they were called from and sufficient scope control to both work with
the variables amongst which they were spawned and to reestablish consistency at
the point that they reenter the flow, be that at the main or at the routine from
which they were spawned. This usually requires the addition of either explicit or
implicit rules to the language.
>
>Robert seems adamant about keeping forward references difficult in Euphoria,
>because he considers this to be bad coding style. This seems to me another
>attempt to force the user into 'good coding style'. Sometimes there are
>compelling reasons to use forward references, and I don't know that making
>the user feel irritated that they have to jump through hoops is a good
>thing.
I don't think that it has anything to do with coding style or didn't until
routine_id() was shoehorned into the language. It was intrinsic to the design of
the language and the interpreter. Now that that is there, there seems little
further reason to limit forward references.
>Since I'm on a roll, I'm mention the scope constraints of routine_id and the
>fact that the value starts at zero... did I miss anything?
I'm not sure I understand exactly what you mean by scope constraints here, but I
surely understand the difficulty of controlling scope and garbage collection when
things like call_back are around.
>
>OK, moving on to the future of Euphoria. I think that the namespace is
>important. The ability to scale programs well is important, and it seems
>that Java's thought the problem through fairly well. Someone floated the
>idea of using Euphoria in HTML, similar to JavaScript - an intriguing idea.
I thought somebody was already doing CGI with Euphoria. If that can be
accomplished locally as well as on the server, then some real power will result.
After your last post to me, I researched the archives a little further, and as
confusing as that process is, gleaned a fair amount of information. In the past,
you have been a real proponent of portability. There has been a more than
sufficient discussion of namespace over a long period of time to make it crystal
clear what the need is. Modularity and interpreter control have been discussed at
a lower level, but the needs are no less clear. It seems foolish to be expanding
the platform base of the language without clearing these huge, longterm issues.
Linux and other platforms are critical longterm, but completing the language is
more important. Certainly Linux and portability should be kept in mind as the
founders code these new things. I don't think that anyone has addressed the
problem of memory fragmentation in long running programs. That is an issue that
will raise it's ugly head in long running programs if such were made possible by
error recovery.
>
>-- David Cuny
Everett L.(Rett) Williams
rett at gvtc.com
21. Re: Ideas for next Eu
----- Original Message -----
From: simulat <simulat at INTERGATE.BC.CA>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Monday, November 08, 1999 1:17 AM
Subject: Re: Ideas for next Eu
> Hi
> I'm sorry to disappoint you Irv, but my posting was serious.
>
> I've already given an example of a "fluid" language (in the sense I'm
> talking about). Level 1 BASIC that ran (still does) on a TRS80 Model 1. It
> had lots of limitations, but it you didn't have to worry about whether a
> variable was local or global. They were all global. That language was
almost
> completely unstructured, compared to say, C. I wrote a lot of spaghetti
> code. Eventually I imposed my own structure by developing a structured
> programming style. I wrote some pretty interesting software on that
system,
> and some of it (a halftone exposure calculator) is still in daily use
> (though translated to GWBasic).
I also have several programs in daily use which were originally written
in BASIC for the TRS-80. Of course, they were re-written as soon as more
capable languages became available. Let's pick one as an example, call it
program "A"...
> Eventually I developed my own system for creating local variables and
> implemented it whenever I needed it. I had no trouble with having
variables
> global as a default. And this was on a system where the range of variable
> names was very small.
So you are doing, manually, what would otherwise be accomplished
automatically
using a more capable language. I also pity anyone who tries to read or
modify a
program which has, say, 741 global variables, as would program A.
> The problem with primitive languages wasn't how you used variables, it was
> just the lack of memory, and the limits of crude graphics that made me
want
> to move on.
True about the lack of memory, and crude graphics. However, the real problem
with program A was not memory or graphics, but how to read and write 741
variables to and from disk. You couldn't even read and write arrays, still
can't
as far as I know, much less declare a neat structure to manage that data.
> Euphoria is an excellent example of a fluid language, even if I do think
it
> could loosen up a bit. It's only got a few data types, you can make more
if
> you want, and as Lucius demonstrated, it's easy to make variables global
if
> you want. And sequences must be one of the most flexible data types going.
True, but it also lacks scalability. Program A, for example, needs to be
able to
store and retrieve those 741 variables for each day of the year over a
several
year period, and run weekly, monthly, and yearly averages, highs, lows, etc.
Oh, did I mention _quickly_? I haven't even tried this in Euphoria, because
it
lacks proper structured variables, and would require me to write my own
random access disk routines. Other languages have those built in.
> I'm self educated a computerist. I've tried hard, on several occasions to
> master C. I could get programs going, but I was never comfortable with it.
> The problem was the infinite data types, combined with the pointer based
> parameter passing. The simplest task seemed complicated and obscure by the
> time it was done.
I certainly agree on those points. The infinite data types require a lot of
annoying type casting. The pointer junk is a byproduct of C being a very
low-level language. Too bad they are still used.
However, by definition, all C variables are global, unless otherwise
specified. You should like that feature.
> Now that stuff is what I call programming overhead. It may be worth the
> trouble in some circumstances, but it is an expense. The question is "When
>is the benefit worth the expense?" The point I make is that in lots of
> circumstances the programming overhead has no benefit and is quite
> expensive. What's the justification for the expense in those
circumstances?
Euphoria doesn't use pointers. It does still require some type casting,
especially when you're dealing with Windows. I wish there were a way
to avoid that.
> So why is "global" equated with "ugly"?
Not ugly, just amateurish. It is much easier to write and debug code that
is short, clear, and self-contained, as opposed to code cluttered with
hundreds of non-relevant details and a minefield of potential side-effects.
If I want to write "for i = 1 to 10 do", I really shouldn't have to read the
entire program again to see if there is a global variable 'i' out there
somewhere which
shouldn't be clobbered. Or perhaps my routine calls a function during the
loop, now
I have to check that function to see if it, or any function it calls,
affects 'i'.
Too much backtracking, too much wasted time and effort.
> And how does forcing people to do things that aren't necessary, but are
> error prone, make programming easier?
I could ask you the same question. Global variables (excepting data that
must be available to all routines in a program) are both unnecessary
and error prone.
And of course, instead of declaring and initializing variables ahead of
time,
it's more fun to just write the program and spend the rest of your time
trying
to figure out why the dollar amount it prints on your paycheck this week is
"$%)@".
Regards,
Irv
22. Re: Ideas for next Eu
------=_NextPart_000_0042_01BF29D9.35CC80A0
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I really don't see the need for any fundamental change in the way =
Euphoria works. A GUI and better file handling would be highly =
desireable--in my mind, better as includes than built-ins so that those =
who prefer alternatives can use them easily. With regard to routine_id, =
I find it essential--there is no other means for indirect function and =
procedure calls--and it's MUCH easier than pointers! I might like to =
have something comparable for data to allow indirect references, but =
this isn't critical. I would like to see the restriction on forward =
references dropped, but can live with it. A possible compromise: C's =
method of requiring functions to be declared before use but not =
requiring them to be defined before use could be implemented in =
Euphoria:
declare function foo(integer,sequence)
bar=3Dfoo(15,"ABC")
function foo(integer i,sequence s)
return s[i]
end function
This would be more readable than the routine_id equivalent and might not =
be too hard to implement.
And of course namespaces must be addressed. But all of these ideas are =
improvements to Euphoria, not fundamental changes of direction--IMHO, =
changes like variables global by default or passing by reference, etc. =
would be.
Actully, the more I think of that last isssue, the more I like the idea =
of data_id:
integer x,y
x=3D17
y=3Ddata_id("x")
then y could be passed as a parameter to a routine which could use if to =
maipulate x indirectly--the power of pointers without the enormous =
complexity. And it wouldn't get in anyone's way who didn't want =
it--just don't use it.
Actually all the OOP ideas I've seen do this, but having it built in =
would be useful in some non-OOP contexts as well.
--MIke Nelson
------=_NextPart_000_0042_01BF29D9.35CC80A0
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>I really don't see the need for any =
fundamental=20
change in the way Euphoria works. A GUI and better file handling =
would be=20
highly desireable--in my mind, better as includes than built-ins so that =
those=20
who prefer alternatives can use them easily. With regard to =
routine_id, I=20
find it essential--there is no other means for indirect function and =
procedure=20
calls--and it's MUCH easier than pointers! I might like to have =
something=20
comparable for data to allow indirect references, but this isn't =
critical. =20
I would like to see the restriction on forward references dropped, but =
can live=20
with it. A possible compromise: C's method of requiring =
functions to=20
be declared before use but not requiring them to be defined before use =
could be=20
implemented in Euphoria:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>declare function=20
foo(integer,sequence)</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 =
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>function foo(integer i,sequence =
s)</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2> <FONT =
color=3D#000000>return=20
s[i]</FONT></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT =
color=3D#000000></FONT></FONT><FONT=20
size=3D2>end function</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>This would be more readable than the routine_id =
equivalent and=20
might not be too hard to implement.</FONT></DIV>
<DIV><FONT size=3D2>And of course namespaces must be addressed. =
But all of=20
these ideas are improvements to Euphoria, not fundamental changes of=20
direction--IMHO, changes like variables global by default or passing by=20
reference, etc. would be.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>Actully, the more I think of that last isssue, the =
more I like=20
the idea of data_id:</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>integer x,y</FONT></DIV>
<DIV><FONT size=3D2>x=3D17</FONT></DIV>
<DIV><FONT size=3D2>y=3Ddata_id("x")</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>then y could be passed as a parameter to a routine =
which could=20
use if to maipulate x indirectly--the power of pointers without the =
enormous=20
complexity. And it wouldn't get in anyone's way who didn't want =
it--just=20
don't use it.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>Actually all the OOP ideas I've seen do this, but =
having it=20
built in would be useful in some non-OOP contexts as well.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>--MIke Nelson</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
------=_NextPart_000_0042_01BF29D9.35CC80A0--
23. Re: Ideas for next Eu
Everett Williams wrote:
> > Someone floated the idea of using Euphoria in HTML,
>> similar to JavaScript - an intriguing idea.
>
> I thought somebody was already doing CGI with Euphoria. If that
> can be accomplished locally as well as on the server, then some
> real power will result.
I was thinking of actually being able to write web applications in Euphoria.
I suspect that if RDS isn't inclined to get involved in the GUI portion of
Euphoria, requesting that Euphoria run GUI web based applications is even
more of a stretch.
> In the past, you have been a real proponent of portability.
I still am - but keep in mind that my focus tends to be from the GUI
perspective, since I'm pretty much immersed in that these days. That's one
of the reasons that I'm so enamored - from a conceptual basis - with Java.
They's been struggling with portabilty over all the major platforms (BeOS
support was just announced). The down side is that the Java API just keeps
getting bigger and bigger, and the reference books thicker and thicker. That
says something for the complexity of the task.
Out of curiosity, have there been any attempts to write any 'raw' X Window
toolkits?
-- David Cuny
24. Re: Ideas for next Eu
- Posted by Everett Williams <rett at GVTC.COM>
Nov 08, 1999
-
Last edited Nov 09, 1999
On Mon, 8 Nov 1999 16:48:18 -0800, David Cuny <dcuny at LANSET.COM> wrote:
>Everett Williams wrote:
>
>> > Someone floated the idea of using Euphoria in HTML,
>>> similar to JavaScript - an intriguing idea.
>>
>> I thought somebody was already doing CGI with Euphoria. If that
>> can be accomplished locally as well as on the server, then some
>> real power will result.
>
>I was thinking of actually being able to write web applications in Euphoria.
>I suspect that if RDS isn't inclined to get involved in the GUI portion of
>Euphoria, requesting that Euphoria run GUI web based applications is even
>more of a stretch.
>
>> In the past, you have been a real proponent of portability.
>
>I still am - but keep in mind that my focus tends to be from the GUI
>perspective, since I'm pretty much immersed in that these days. That's one
>of the reasons that I'm so enamored - from a conceptual basis - with Java.
>They's been struggling with portabilty over all the major platforms (BeOS
>support was just announced). The down side is that the Java API just keeps
>getting bigger and bigger, and the reference books thicker and thicker. That
>says something for the complexity of the task.
I would think that your own experience with attempting to map more and more of
the Windows GUI API would tell you that there is nothing trivial about the
project. The nice thing about the Java API, is that it is generally expressed in
class libs that you don't have to write, just use.
>
>Out of curiosity, have there been any attempts to write any 'raw' X Window
>toolkits?
>
>-- David Cuny
Somebody commented that the Linux beta ran under X Windows, but I am not certain
what they meant by that. I kind of doubt that there was any real linkage to the X
Window API.
Everett L.(Rett) Williams
rett at gvtc.com
25. Re: Ideas for next Eu
I'd like to contribute my own 1/50th of a dollar to this topic...
One continuing source of frustration for me is Euphoria's inability to deal
intelligently with returning more than one value from a function. Hence the
following annoyance, in two versions:
-- version 1: sensible variable names, inefficient code
sequence pos
integer line, column
pos = get_position()
line = pos[1]
column = pos[2]
-- do whatever
position(line, column)
-- version 2: more efficient execution, variable names less than helpful
sequence pos
pos = get_position()
-- do whatever
position(pos[1], pos[2])
This, to me, is one of the glaring inconsistencies in Euphoria's otherwise
very self-consistent language design. We can send multiple variables to a
routine, but can only receive one variable back.
Now, obviously, in most languages this is what we're normally stuck with.
But those languages don't have a data type like the sequence, and you'd
think Euphoria would have been designed to take advantage of that. Instead,
we as Euphoria programmers are forced to create receiving temp sequences
which we then have to:
1) "unpack" into variables with more sensible names, or
2) we simply subscript the temp sequence, at the cost of understandability.
I suppose a better variation on #2 would be to create intelligible constants
for subscripting of the receiving sequence, like so:
constant POS_LINE = 1, POS_COLUMN = 2
sequence pos
pos = get_position()
-- do whatever
position(pos[POS_LINE], pos[POS_COLUMN])
But, really, it would be much more efficient and intelligible (IMO) to be
able to do the following:
integer line, column
{line, column} = get_position()
-- do whatever
position(line, column)
Ahh, now *that's* more like it! It makes perfect sense when you read it,
without requiring the need for klunky subscripting, additional constants, or
manual "unpacking" of the values. "Elegance," if you like.
The current way Euphoria forces us to do this is annoying, unsightly,
potentially confusing, and could easily be done transparently by the
interpreter, as I have demonstrated above. I hope this idea (or something
like it) is being seriously considered for implementation in Euphoria's
future.
Thank you,
Gabriel
----------
Nothing is so remote from us as the thing which is not old enough to be
history and not new enough to be news.
G.K. Chesterton
----------
26. Re: Ideas for next Eu
I agree, this does make a lot of sense.
I would also like to see a further step... subscripting functions as though
they are sequences. Like so:
first_name=get_name(database)[1]
This can of course be done with a seperate routine, but whats the point of
duplicate program code? It only adds to file size.
Anyway thats just one thing Ive thought of as I have been programming Eden,
it might not seem to like a good idea to anyone else...LOL
Pete.
27. Re: Ideas for next Eu
----- Original Message -----
From: Pete King, Spectre Software <pete at THEKING29.FREESERVE.CO.UK>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Tuesday, November 09, 1999 5:03 PM
Subject: Re: Ideas for next Eu
> I agree, this does make a lot of sense.
>
> I would also like to see a further step... subscripting functions as
though
> they are sequences. Like so:
>
> first_name=get_name(database)[1]
>
> This can of course be done with a seperate routine, but whats the point of
> duplicate program code? It only adds to file size.
>
> Anyway thats just one thing Ive thought of as I have been programming
Eden,
> it might not seem to like a good idea to anyone else...LOL
It seems like an excellent idea, at least to me. There are many places
that this would be extremely helpful, and make programs easier to read.
Irv
28. Re: Ideas for next Eu
Pete King suggests:
>I would also like to see a further step... subscripting functions as
>though they are sequences. Like so:
>
>first_name=get_name(database)[1]
>
>This can of course be done with a seperate routine, but whats the point
>of duplicate program code? It only adds to file size.
Mmm...I guess I don't see any overriding need for subscripting of
expressions. It looks a tad goofy to me, and with multiple parameters or
complicated expressions it would obscure, rather than clarify, what was
going on. Shameless plug for my own idea, based on the above:
{first_name, last_name} = get_name(database)
Or something like that -- your given example, I fear, does not seem very
practical. Perhaps a better example might be a more persuasive argument for
your idea?
Speaking of a better example being more persuasive, here's another use for
my own idea which I would find *extremely* beneficial on a day-to-day
basis...
while 1 do
{return_code, data} = get(input_file)
if return_code = GET_SUCCESS then
data = reformat(data)
print(output_file, data)
elsif return_code = GET_EOF then
-- end of file
exit
else
-- corrupted data file
abort(13)
end if
end while
Hep yadda,
Gabriel
----------
It is the beginning of all true criticism of our time to realize that it has
really nothing to say, at the very moment when it has invented so tremendous
a trumpet for saying it.
G.K. Chesterton
----------
29. Re: Ideas for next Eu
My idea is applicable where you only want one result returned from a
function that supplies multiple results... you would have to discard the
ones you dont want otherwise, with my idea the compiler would do this.
Maybe its not so great an idea, just thought I would contribute.
30. Re: Ideas for next Eu
I'd like to be able to spec array fields, and to have Eu simply return $null
or "null" or something if it doesn't exist, rather than crashing. One
dimensional sequences are nice, the next step, i think, is to make them
multidimensional in the kernal. Right now i can add sequences to a
predefined sequence, and then search for that nested sequence,,, but once it
gets large enough to be useful to me, the search time is excessive.
I also like this function:
set %net dal
set %flood. [ $+ [ %net ] $+ . $+ [ $remove($address($nick,3),%apost) ] ]
$ctime
will *make* this var:
%flood.dal.!ident at .isp.net 942191823
That's just an example, not something useful,, but that ability to make new
var names and use them is an absolutely great freedom to free-form
programming. I am hoping the next step in that freedom is the ability in
that kernal to find that var by any of these forms, if i want to:
%flood.dal.!ident at .isp.net
%dal.flood.!ident at .isp.net
%!ident at .isp.net.flood.dal
%dal.!ident at .isp.net.flood
etc etc
Nameable timers that accept commands are nice too, and the ability to access
the list of timers and what they are set to do when they fire, etc. Lets see
all that in Eu, please?
Kat
31. Re: Ideas for next Eu
Gabriel Boehme wrote:
> {line, column} = get_position()
Yes!
-- David Cuny
32. Re: Ideas for next Eu
Hello
Pete King wrote:
>My idea is applicable where you only want one result returned from a
>function that supplies multiple results... you would have to discard the
>ones you dont want otherwise, with my idea the compiler would do this.
>
>Maybe its not so great an idea, just thought I would contribute.
This is an excellent suggestion IMO. For those who want a specific
example, here's one I have seen before.
----- code ---------
include get.e
constant
err = 1,
val = 2,
string = "{1,2,3}"
? value (string)[val]
--------------------
later,
Lewis Townsend
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
33. Re: Ideas for next Eu
- Posted by Brian Broker <bkb at CNW.COM>
Nov 09, 1999
-
Last edited Nov 10, 1999
On Wed, 10 Nov 1999 01:17:56 GMT, Lewis Townsend <keroltarr at HOTMAIL.COM>
wrote:
>This is an excellent suggestion IMO. For those who want a specific
>example, here's one I have seen before.
>
>----- code ---------
>include get.e
>constant
> err = 1,
> val = 2,
> string = "{1,2,3}"
>? value (string)[val]
>--------------------
>
But the error_status has a purpose. Why throw it out?
But I do like this idea:
-- code --
include get.e
object string, err, val
string = "{1,2,3}"
{err,val} = value(string)
if err = GET_SUCCESS then -- why not do some error checking?
? val
end if
-- end code --
No need for a temporary sequence to hold the result of value() and no need
for constants to make the code more readable.
But this topic has been thrown around quite a bit since I've found Euphoria
and I think the general consensus is that most would like to see the second
example doable. There seem to be mixed feelings about indexing a
function... (which I feel is a bit hard to follow as far as readability,
but it's an interesting concept).
-- Brian
34. Re: Ideas for next Eu
On Tue, 9 Nov 1999 16:40:10 -0800, David Cuny <dcuny at LANSET.COM> wrote:
>Gabriel Boehme wrote:
>
>> {line, column} = get_position()
>
>Yes!
>
>-- David Cuny
Isn't this just the latest thread of the namespace, structure discussion, just
an
elaborate dance around the need for structure naming? If "line" and "column"
are part of something that is 40 or 50 or a hundred items in size and I would
like to refer to them by name rather than by x[23] and x[77], maybe with x.line
and x.column, don't we need to be able to? Defining them individually and then
including them in a temporary sequence won't really work either, because they may
be an atom in sequence one, an integer in sequence two, and another sequence in
sequence three. And then, we really get into the variable
initialization problem with a vengeance. Though I am no expert in C, I think
that
is what stimulated the "void" definitions. Nothing in the world should keep the
current Euphoria definition from working, but I would like to add this to it.
null sequence xxxx{
atom x = 0,
atom line = 0,
sequence y = "Hello World",
integer {this, that,theother} = 1, -- to preserve current
syntax
-- and to
easily define more
-- more
than one at a time
atom column = 0,
atom z = 2}
Note the temporary sequence used as shorthand. By your rules, this would
result in a temporary seqence that looks like this.
{x,line,y,this,that,theother,column,z} = procx(mumble)
to be used once and thrown away and to be recoded each time I need to store
the results of procx(). Ugh! Now I can do something of the order of this:
-- use void definition from above
sequence yyyy instance xxxx -- which would create and initialize the seqence
sequence zzzz instance xxxx -- another sequence created and initialized
yyyy = procx(virtual_screen1)
zzzz = procx(virtual_screen2)
if yyyy.line != zzzz.line then
.... we are not synchronized ...etc..etc.
elseif yyyy.column = zzzz.column then
.... we are synchronized...etc....etc.
else
....... we are not synchronized....etc. etc.
end if
This is a stunningly bad example, because I have not coded much recently,
but I think the flavor is there to partake of. The obvious extension of this is
to
allow variables to be declared and defined in one step by borrowing the syntax
I have used above, or something similar.
When Euphoria really grows up and finds some way to deal with externally defined
data structures, then we will get some kind of bit, byte, and double
byte definitions to work with. By allowing named structures with these data
types, and enforcing their use, we can isolate Euphoria from the worst of their
effects. For example, Euphoria can force assignment of bits, bytes and double
bytes to atoms, integers, etc. before they can be used elsewhere in code in
the same way that variables are forced to be initialized before they are used.
Maybe something of the form of "null external sequence zzzz{....}" will do with
same basic syntax of above and the extra data types allowed only in
assignment statements that would do automatic conversion based on the
platform type. Only a single external data type variable would be allowed as
the source of an assignment with no other operations allowed. When
assigning to an external type variable, things would proceed normally.
In this process, we will get rid of a host of clumsy work arounds and allow
Euphoria to go out and play with the big boys on an even footing.
Everett L.(Rett) Williams
rett at gvtc.com
35. Re: Ideas for next Eu
In my post just previous, please...if you look at it online, don't use the
proportional font. You will not be able to make heads or tails of it. You
will have to scroll left and right to see some of it, but otherwise, you
will miss the entire meaning of what I have typed. I wish I understood
the rules for getting messages typed into the "reply" box of this forum
to behave and look decent. The part of the rules that I do understand
are a pain. Grrr.
Everett L.(Rett) Williams
rett at gvtc.com
36. Re: Ideas for next Eu
- Posted by Lewis Townsend <keroltarr at HOTMAIL.COM>
Nov 10, 1999
-
Last edited Nov 11, 1999
Hello
Brian Broker <bkb at CNW.COM> wrote:
>But the error_status has a purpose. Why throw it out?
There are situations that arise in which you know that the
string you are passing to value() will work. In these
situations it's a bother to have to use a temp variable and
still would be with:
{status, value} = value (string)
because I would then have to make sure I had a "status"
variable declared or at least junk or temp. I could live
with this if I could do this:
{0, value} = value (string) -- 0 is ignored
>But I do like this idea:
>
>-- code --
>include get.e
>
>object string, err, val
>
>string = "{1,2,3}"
>{err,val} = value(string)
>
>if err = GET_SUCCESS then -- why not do some error checking?
> ? val
>end if
>-- end code --
Yes, that is a good ideah too. In fact I hope that this syntax
is implemented before subscripting functions. However I don't
think this is a complete workaround for subsciption. The point
of which is to throw out anything that you don't need. While I'm
on the subject here's some more subscription ideas I would like:
object x
x = {{1,2},{3,4},{5,6}}
? x [1..3][2] -- HERE'S THE TRICK
-- output: {2,4,6}
object x
x = {9,8,7,6}
? x [1,3]
-- output: {9,7}
Of course I would like these to work in combination and on
functions as well. I know it's asking a lot but it makes
sense to me.
>There seem to be mixed feelings about indexing a function...
Yes
>(which I feel is a bit hard to follow as far as readability,
No (IMO)
later,
Lewis Townsend
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
37. Re: Ideas for next Eu
On Wed, 10 Nov 1999, you wrote:
> On Tue, 9 Nov 1999 16:40:10 -0800, David Cuny <dcuny at LANSET.COM> wrote:
>
> >Gabriel Boehme wrote:
> >
> >> {line, column} = get_position()
> >
> >Yes!
>
> Isn't this just the latest thread of the namespace, structure discussion, just
> an
> elaborate dance around the need for structure naming? If "line" and "column"
> are part of something that is 40 or 50 or a hundred items in size and I would
> like
> to refer to them by name rather than by x[23] and x[77], maybe with x.line
> and x.column, don't we need to be able to?
Right now, we can write this as:
MyWindow[line...column] = get_position() or as
MyWindow[location] = get_position()
Unfortunately, this is based on having declared constants for line, column,
and location previously, which can be a real pain when you're dealing with
a large number of items - an even bigger pain each time you modify the
"structure" - and downright unworkable if you have more than one object
which has need for a "line" and a "column" member.
A second drawback is that it is entirely possible to assign
MyWindow[location] = "Jersey City", which is likely to make the rest of your
program very unhappy, but won't provoke any error message at the point of
assignment.
<snip>
> Nothing in the world should keep the current Euphoria definition from
> working, but I would like to add this to it.
> null sequence xxxx{
atom x = 0,
atom line = 0,
sequence y = "Hello World",
integer {this, that,theother} = 1, -- to preserve current syntax
-- and to easilydefine
more
-- more than one at
atime
atom column = 0,
atom z = 2}
> Note the temporary sequence used as shorthand. By your rules, this would
> result in a temporary seqence that looks like this.
> {x,line,y,this,that,theother,column,z} = procx(mumble)
For accuracy, it should actually look more like:
{ x,line,y,{this,that,theother},column,z }
which preserves the internal sequence that is made up of {this,that,theother}
Your syntax needs to be changed slightly if we want to call this
sequence by name:
sequence things {integer this, integer that, integer theother} = 1
or perhaps less confusing:
sequence things (integer this, that, theother} = {1,1,1}
I certainly like the idea of creating and initializing a "structure" in one
step. It adds clarity and shortens the code.
> -- use void definition from above
> sequence yyyy instance xxxx -- which would create and initialize the seqence
> sequence zzzz instance xxxx -- another sequence created and initialized
> yyyy = procx(virtual_screen1)
We can already do this, by simply initializing the first
sequence, and then declaring the following sequences like so:
yyyy = xxxx
zzzz = xxxx
The drawback to this is, since we can't "type" members of a sequence at
present, there are no "types" to pass on to the new sequences either, just the
contents.
You'll have to explain your use of "void" and "null" here. How can a variable
be "void" ? C has void function returns, which is a clumsy and error-prone way
to make up for the fact that sometimes calls are made to routines which do not
return any value. Other languages just call these "procedures" and eliminate
possible confusion.
C also has null variables (variables pre-initialized to "nothing", which is
not what you're showing above, as you have assigned some value to each of them)
> zzzz =procx(virtual_screen2) >
> if yyyy.line != zzzz.line then
> .... we are not synchronized ...etc..etc.
> elseif yyyy.column = zzzz.column then
> .... we are synchronized...etc....etc.
> else
> ....... we are not synchronized....etc. etc.
> end if
Of course, we can do that now, as well, but in a much neater form:
(Again, only if we have declared line, column and location beforehand:)
if equal(yyyy[location], zzzz[location]) then we_are_synchronized....
alternatively:
if equal(yyyy[line..column], zzzz[line...column]) then we_are_synchronized......
These one-liners compare _all_ the entries, no matter how many, between line and
column (or contained within the sub-sequence "location") at one time, which is
less work and more understandable that the if ....elsif .... code above.
<snip>
> When Euphoria really grows up and finds some way to deal with externally
> defined data structures,
> then we will get some kind of bit, byte, and double
> byte definitions to work with. By allowing named structures with these data
> types, and enforcing
> their use, we can isolate Euphoria from the worst of their
> effects. For example, Euphoria can force assignment of bits, bytes and double
> bytes to atoms, integers, etc. before they can be used elsewhere in code in
> the same way that variables are forced to be initialized before they are used.
A plethora of data types has little real importance anymore. There's enough
memory and disk space available so that we can simply use 32 bits to store a
boolean if we want to. Who cares? Keep it simple - Euphoria doesn't need to
look like C or Pascal, with dozens of type casting functions to convert between
bytes and words, etc. These are the kind of things that often make up several
hundred lines of a thousand line program.
If for some reason we really need to ensure that a value will always fit
into a "byte", or a "word" , we can define our own "byte" or "word" type with
three lines of code. So, there can be as many self-proclaimed data types as one
wants to fool with.
On the other hand, it's really sad that we lose all ability to type check
assignments to all user-defined and built-in types as soon as we store the
data into sequences. That's why we need a "structure" which allows us to
declare a type and a name for each member of that "structure" ,"sequence", or
"object", whatever one wishes to call it, and have both the type and the name
follow that member wherever it goes.
Regards,
Irv
38. Re: Ideas for next Eu
On Wed, 10 Nov 1999, Lewis Townsend wrote:
> Yes, that is a good ideah too. In fact I hope that this syntax
> is implemented before subscripting functions. However I don't
> think this is a complete workaround for subsciption. The point
> of which is to throw out anything that you don't need. While I'm
> on the subject here's some more subscription ideas I would like:
>
> object x
> x = {{1,2},{3,4},{5,6}}
> ? x [1..3][2] -- HERE'S THE TRICK
> -- output: {2,4,6}
This (I call it "vertical" slicing) would be very handy in any number of
places, especially when dealing with business programs. Anything from
extracting a sequence of names from a name, address, phone # list,
searching columns for certain values, or doing math on whole columns of figures
(!) would be simplified.
> object x
> x = {9,8,7,6}
> ? x [1,3]
> -- output: {9,7}
Very handy, especially if find() or match() would return a sequence of matching
items from a list:
{1,3,12,55} , say, would mean the matching data was found in
record 1,3,12 and 55. Which you could then proceed to extract into a new
sequence : matchingitems = masterlist[{1,3,12,55}]
In conjunction with "vertical" sliceing, this could be extremely powerful.
matchingnames = masterlist[{1,3,12,55}][NAME]
> Of course I would like these to work in combination and on
> functions as well. I know it's asking a lot but it makes
> sense to me.
A lot of sense. Most of this seems do-able. I'm not sure how difficult it would
be to subscript functions, or what side effects it would cause, but there are a
lot of places it would be very useful.
>There seem to be mixed feelings about indexing a function...
> Yes
> >(which I feel is a bit hard to follow as far as readability,
> No (IMO)
Agreed. For example, I think that date[YEAR] or perhaps date([YEAR]) or
maybe date.year is more useful and readable than the alternative:
create a sequence
sequence x
assign
x = date()
extract
? = x[YEAR]
especially if, somehow, date() _knows_ the names of its members, so you don't
have to declare them as constants, which will sooner or later collide with
another of your or someone else's "YEAR", "MONTH", or "DAY".
Regards,
Irv
39. Re: Ideas for next Eu
- Posted by Everett Williams <rett at GVTC.COM>
Nov 10, 1999
-
Last edited Nov 11, 1999
On Wed, 10 Nov 1999 14:25:22 -0500, Irv Mullins <irv at ELLIJAY.COM> wrote:
>> >
>> >> {line, column} = get_position()
>> >
>> >Yes!
>>
>> Isn't this just the latest thread of the namespace, structure
>> discussion, just an elaborate dance around the need for structure
>> naming? If "line" and "column" are part of something that
>> is 40 or 50 or a hundred items in size and I would like to
>> refer to them by name rather than by x[23] and x[77],
>> maybe with x.line and x.column, don't we need to be able to?
>
>Right now, we can write this as:
>MyWindow[line...column] = get_position() or as
>MyWindow[location] = get_position()
I THINK that this only works when [line...column] are positioned properly
in the sequence MyWindow. The case that I was driving at was the one
where get_position_xxx() returns a sequence that doesn't start with
line and end with column and I would still like to be able access line and
column in that and another screen whose attributes have been gotten
through the same function. Regardless of the position of line and column
in the resulting sequence, if they are described in a proper structure, I
can refer to them by xxxx.line, xxxx.column, yyyy.line and yyyy.column
without fear of stepping on any constant or variable that may be defined
elsewhere. And I don't have constants proliferating all over the place and
taking up namespace that should be cleanly structured not to need them.
>
>Unfortunately, this is based on having declared constants for line, column,
>and location previously, which can be a real pain when you're dealing with
>a large number of items - an even bigger pain each time you modify the
>"structure" - and downright unworkable if you have more than one object
>which has need for a "line" and a "column" member.
My vote is that any solution that depends on constants is a chimera that
solves nothing and takes up memory for nothing.
>A second drawback is that it is entirely possible to assign
>MyWindow[location] = "Jersey City", which is likely to make the rest of your
>program very unhappy, but won't provoke any error message at the point of
>assignment.
Then why suggest it when you know it can't easily work in any large
program?
>
><snip>
>
>> Nothing in the world should keep the current Euphoria definition from
>> working, but I would like to add this to it.
>> null sequence xxxx{
> atom x = 0,
> atom line = 0,
> sequence y = "Hello World",
> integer {this, that,theother} = 1, -- to preserve current syntax
> -- and to
> easilydefine more
> -- more than one at
> atime
>
> atom column = 0,
> atom z = 2}
>
>> Note the temporary sequence used as shorthand. By your rules, this would
>> result in a temporary seqence that looks like this.
>> {x,line,y,this,that,theother,column,z} = procx(mumble)
>
>For accuracy, it should actually look more like:
>{ x,line,y,{this,that,theother},column,z }
>which preserves the internal sequence that is made up of {this,that,theother}
Actually not. The temporary sequence (this,that,theother} only exists on
that one line for the purpose of using the current assignment rules to
initialize it. When the line ends, the sequence dissolves back into the
individual integers from which it was temporarily formed.
>Your syntax needs to be changed slightly if we want to call this
>sequence by name:
> sequence things {integer this, integer that, integer theother} = 1
>or perhaps less confusing:
> sequence things (integer this, that, theother} = {1,1,1}
Ugh! You just created a completely new syntax that is both large and
cumbersome. The real power of the sequence assignment shorthand
can be used here to initialize the variables while adding no error
prone assignment lists that require proper left to right matching
to get the initializations right.
>I certainly like the idea of creating and initializing a "structure" in one
>step. It adds clarity and shortens the code.
>
>> -- use void definition from above
>> sequence yyyy instance xxxx -- which would create and initialize the seqence
>> sequence zzzz instance xxxx -- another sequence created and initialized
>> yyyy = procx(virtual_screen1)
>
>We can already do this, by simply initializing the first
>sequence, and then declaring the following sequences like so:
>yyyy = xxxx
>zzzz = xxxx
>The drawback to this is, since we can't "type" members of a sequence at
>present, there are no "types" to pass on to the new sequences either, just the
>contents.
Why take up the space until the item is needed when the only thing needed
is not data, but structure.
>You'll have to explain your use of "void" and "null" here. How can
>a variable be "void" ? C has void function returns, which is a clumsy
>and error-prone way to make up for the fact that sometimes calls
>are made to routines which do not return any value. Other
>languages just call these "procedures" and eliminate possible confusion.
>
>C also has null variables (variables pre-initialized to "nothing", which is
>not what you're showing above, as you have assigned some value to each of them)
I just knew that I would get in trouble by trying to use as an example
anything in a language that I don't program in 
Sorry to be unclear.
That is why I used the adjective "null" for the sequence descriptor. Cancel
anything that I said about "void" as being stupid and random. HOWEVER,
the null sequence/structure that I described does not have any values
assigned in it. It is only a template for the assignment of those values
when the structure is instanced. The instancing of the structure will
trigger the running of the initializations and the assigning of the
names modified by their sequence variable.
>> zzzz =procx(virtual_screen2) >
>> if yyyy.line != zzzz.line then
>> .... we are not synchronized ...etc..etc.
>> elseif yyyy.column = zzzz.column then
>> .... we are synchronized...etc....etc.
>> else
>> ....... we are not synchronized....etc. etc.
>> end if
>
>Of course, we can do that now, as well, but in a much neater form:
>(Again, only if we have declared line, column and location beforehand:)
>
>if equal(yyyy[location], zzzz[location]) then we_are_synchronized....
>
>alternatively:
>if equal(yyyy[line..column], zzzz[line...column]) then
>we_are_synchronized......
>
>These one-liners compare _all_ the entries, no matter how
> many, between line and column (or contained within the sub-sequence
>"location") at one time, which is less work and more understandable
> that the if ....elsif .... code above.
Again, I apologize for the code, but the forms in it apply whether I
WANT to compare all the values between line and column or not.
I can still use your form if I want to compare all those values and
yes that is nice.What if the values in between line and column
are not being kept in synch. Again, please do not confuse the
specific example with the method proposed. Nothing that is will
be lost, but the ability to refer in an unambiguous manner to
individual data items in a sequence/structure is not currently
possible without the above excoriated(by both you and me)
constant technique. I don't wish to lose any of the current
capabilities.
> <snip>
>
>> When Euphoria really grows up and finds some way to deal
>>with externally defined data structures, then we will get some
>>kind of bit, byte, and double byte definitions to work with. By
>>allowing named structures with these data types, and enforcing
>> their use, we can isolate Euphoria from the worst of their
>> effects. For example, Euphoria can force assignment of bits,
>>bytes and double bytes to atoms, integers, etc. before they can
>>be used elsewhere in code in the same way that variables are
>>forced to be initialized before they are used.
>
>A plethora of data types has little real importance anymore.
>There's enough memory and disk space available so that we
>can simply use 32 bits to store a boolean if we want to. Who
>cares? Keep it simple - Euphoria doesn't need to look like C
>or Pascal, with dozens of type casting functions to convert
>between bytes and words, etc. These are the kind of things that
>often make up several hundred lines of a thousand line program.
Agreed in principal, but not in fact. Euphoria does not control the
data generated by the rest of the world, regardless of how logical
it currently is to only use 32 bits for everything. When a processor
is having to shove it around, many times it uses bits for flags. If
we would like easy access to the assembler world on various
processors, bit, byte and double-byte types will vastly simplify the
process and the code. In addition, a huge amount of the data in the
online transmission world is full of bits and bytes, because network
speeds are not likely to soon approach processor speeds and
throwing in unused filler to make everything a 32 bit word would
drastically slow down routing, transmission, etc.
>If for some reason we really need to ensure that a value will always
>fit into a "byte", or a "word" , we can define our own "byte" or "word"
>type with three lines of code. So, there can be as many
>self-proclaimed data types as one wants to fool with.
Those data types currently cause huge overhead in programs that
make any significant use of them...to the point that type checking
must be turned off in most production programs that have them. We
lose one of the real powers of Euphoria in more dynamic programs
because we refuse to recognize these common data types in any
form.
I am effectively proposing that, by limiting those data types to an
"external" sequence type and putting the conversion into the assign
statement, type checking can be preserved and Euphoria can
continue in large part, unsullied. It also allows Euphoria itself to
take care of things like bit order and sign handling differences found
in different machines.
>On the other hand, it's really sad that we lose all ability to type
>check assignments to all user-defined and built-in types as soon
>as we store the data into sequences. That's why we need a
>"structure" which allows us to declare a type and a name for
>each member of that "structure" ,"sequence", or "object",
>whatever one wishes to call it, and have both the type and the
>name follow that member wherever it goes.
>
>Regards,
>Irv
In summation, we differ mostly in degree rather than kind. I hope I have
made my proposals a little clearer in this post. I would especially like
your and anybody else's opinion about the way I propose to assign and
initialize structures at the point of instance. The syntax of individual
items is not nearly as important. IMO, there is some real power in
this way of naming and assigning at the point of definition of "real"
data. It should also improve garbage collection, by putting the creation
of data closer to the code that uses it.
Everett L.(Rett) Williams
rett at gvtc.com
40. Re: Ideas for next Eu
- Posted by Everett Williams <rett at GVTC.COM>
Nov 10, 1999
-
Last edited Nov 11, 1999
On Wed, 10 Nov 1999 16:31:33 -0500, Irv Mullins <irv at ELLIJAY.COM> wrote:
>On Wed, 10 Nov 1999, Lewis Townsend wrote:
>
>> Yes, that is a good ideah too. In fact I hope that this syntax
>> is implemented before subscripting functions. However I don't
>> think this is a complete workaround for subsciption. The point
>> of which is to throw out anything that you don't need. While I'm
>> on the subject here's some more subscription ideas I would like:
>>
>> object x
>> x = {{1,2},{3,4},{5,6}}
>> ? x [1..3][2] -- HERE'S THE TRICK
>> -- output: {2,4,6}
>
>This (I call it "vertical" slicing) would be very handy in any number of
>places, especially when dealing with business programs. Anything from
>extracting a sequence of names from a name, address, phone # list,
>searching columns for certain values, or doing math on whole columns of figures
>(!) would be simplified.
>
>> object x
>> x = {9,8,7,6}
>> ? x [1,3]
>> -- output: {9,7}
>
>Very handy, especially if find() or match() would return a sequence of
>matching
>items from a list:
>{1,3,12,55} , say, would mean the matching data was found in
>record 1,3,12 and 55. Which you could then proceed to extract into a new
>sequence : matchingitems = masterlist[{1,3,12,55}]
>In conjunction with "vertical" sliceing, this could be extremely powerful.
>matchingnames = masterlist[{1,3,12,55}][NAME]
In common parlance, those two functions would be called findall and
matchall. In the SPF and Rexx editors in the IBM world, these
functions lend themselves to a technique so useful for code
correction, that I have sought it in every editor since then and not
found it. Specifically the TSO/SPF editor allows line numbering to be
turned on and off. It can be used for editing without saving it. In line "1"
in the number field, I can type x99999, which means exclude from here
the next 99999 lines from the display. In this case, that means all
lines. Then, you do something that is of the following form:
find all "xyz" from line 1 to 9999 and column 1 to 80 searching only
excluded lines
which translates to something like
fa 1 99999 1 80 "xyz" x
This little jewel then displays only the lines that contain the found
text that are currently excluded. Now, instead of seeing the whole
blankety-blank program with the field highlighted, I get to see only
the lines that contain the sought object. With a little adjustment to
options or preferences, I can see the line before and after the
occurrence with the found line. In SPF, there was a line in between
found items with the number of lines still excluded between the
found items. I hope that somebody besides me can see the utility of
that kind of thing for doing program changes or corrections. Most
people using the SPF editor had never thought of the technique,
even though there was one example in the manual with it. They
never "got" it. To make a long story short, Your extended find()
or match() function with the vertical slice sequence would allow this
very powerful form of editing. If somebody else doesn't do it, I
will.
>
>> Of course I would like these to work in combination and on
>> functions as well. I know it's asking a lot but it makes
>> sense to me.
>
>A lot of sense. Most of this seems do-able. I'm not sure how difficult it would
>be to subscript functions, or what side effects it would cause, but there are a
>lot of places it would be very useful.
>
>>There seem to be mixed feelings about indexing a function...
>> Yes
>> >(which I feel is a bit hard to follow as far as readability,
>> No (IMO)
>
>Agreed. For example, I think that date[YEAR] or perhaps date([YEAR]) or
>maybe date.year is more useful and readable than the alternative:
>create a sequence
> sequence x
>assign
> x = date()
>extract
> ? = x[YEAR]
>
>especially if, somehow, date() _knows_ the names of its members, so you don't
>have to declare them as constants, which will sooner or later collide with
>another of your or someone else's "YEAR", "MONTH", or "DAY".
>
>Regards,
>Irv
In effect, you are asking the interpreter to do automatic selective
sub-sequencing based on arguments to a function. With proper
structure naming, this would be a lot less necessary, but still very
nice. Intuitive, too...which in my world makes it even more desirable.
Everett L.(Rett) Williams
41. Re: Ideas for next Eu
- Posted by Irv Mullins <irv at ELLIJAY.COM>
Nov 10, 1999
-
Last edited Nov 11, 1999
From: Everett Williams <rett at GVTC.COM>
Subject: Re: Ideas for next Eu
>
> In effect, you are asking the interpreter to do automatic selective
> sub-sequencing based on arguments to a function. With proper
> structure naming, this would be a lot less necessary, but still very
> nice. Intuitive, too...which in my world makes it even more desirable.
As long as functions _can_ return objects, then it really seems
rather lame to not take advantage of that feature in every way possible.
Being able to select a portion of the normally returned object would often
be preferable to receiving a complete structured variable, and having to
break out the part(s) you are interested in using from that variable in a
later step.
There's nothing in this that would preclude a function call sans the extra
arguments, so functions could still be used just as they are currently.
Irv
42. Re: Ideas for next Eu
On Wed, 10 Nov 1999 22:36:57 -0500, Irv Mullins <irv at ELLIJAY.COM> wrote:
>From: Everett Williams <rett at GVTC.COM>
>Subject: Re: Ideas for next Eu
>
>
>>
>> In effect, you are asking the interpreter to do automatic selective
>> sub-sequencing based on arguments to a function. With proper
>> structure naming, this would be a lot less necessary, but still very
>> nice. Intuitive, too...which in my world makes it even more desirable.
>
>As long as functions _can_ return objects, then it really seems
>rather lame to not take advantage of that feature in every way possible.
>Being able to select a portion of the normally returned object would often
>be preferable to receiving a complete structured variable, and having to
>break out the part(s) you are interested in using from that variable in a
>later step.
>
>There's nothing in this that would preclude a function call sans the extra
>arguments, so functions could still be used just as they are currently.
>
>Irv
Agreed, now how do we get the manager of this hotel to provide us
with the items that we have requested? It seems that many of these
functions..er..items have been known and requested with some fervor
for quite some time by a decent number of the discerning clientele.
Either they can't, they don't want to, or they think that spreading out
to other platforms will gain them more than completing the language.
Right now, they have a language sufficiently elegant to attract a coterie
of devoted followers. However, because of the narrow focus of what
so far has been done on the language, a great deal of the code
generated by programmers working in it has been for the purpose of
hacking their way through the jungle to Assembler and C. Even for
those purposes, the tools are so incomplete as to render much of the
code as peeks and pokes, or to put it in another way, back to ye olde
machine code. That seems a horribly inelegant way to spend one's
time. The libraries being written are great work, but terribly vulnerable
to rather minor changes in the environment or the language. And a
great deal of the code will not survive without great pain in the next
generation of processors. At the very least, programmers should have
sufficient tools to easily communicate with other programs of
whatever origin, and use data of whatever origin or type. Resorting to
machine code should happen only through interfaces, never through
direct code. External code should be self contained and independent
of Euphoria. At the very least, it should be created separately and
then loaded and branched to by interface, even if that
interface is unique to Euphoria. If one wishes to write an assembler
in Euphoria, I think it is well suited to that purpose. But, separate it
from Euphoria. Have tools to build and package routines to that
interface I spoke of earlier. Write all those routines in Euphoria if you
wish. Then, when the change in environment comes, the only
routines that will have to be re-written will be external to "working"
Euphoria code. The tools only have to be rewritten once and the
routines dependent on local architecture were already known as
items that would have to be rewritten.
Oh well, dismount soap box and save wind for other days.
Everett L.(Rett) Williams
rett at gvtc.com
43. Re: Ideas for next Eu
- Posted by Robert Craig <rds at ATTCANADA.NET>
Nov 11, 1999
-
Last edited Nov 12, 1999
Everett Williams writes:
> Agreed, now how do we get the manager of this hotel
> to provide us with the items that we have requested?
> It seems that many of these functions..er..items have
> been known and requested with some fervor for quite
> some time by a decent number of the discerning
> clientele. Either they can't, they don't want to, or they
> think that spreading out to other platforms will gain
> them more than completing the language.
I appreciate all suggestions regarding new language
features. I read all the posts and I add notes to my
wish list. I am not trying to be rude by not responding.
There are many reasons why I generally
do not jump in immediately (or ever) and give
my opinions on proposed features:
1. The feature has already been proposed and kicked around
and the poster is "rediscovering" it.
2. I'd rather let other people debate it before I prejudice the
discussion by coming down on one side or the other.
3. I don't want to drop what I am working on,
do a full analysis of the feature, and construct a
detailed response. I can't simply say "right"
or "wrong" to a new language feature. There are
many considerations to take into account and a lot
of it is very subjective.
In private e-mail, Everett, you have asked me to
publish my "philosophy", along with a detailed roadmap
of where Euphoria is going. This is not easy for me
to do. I am the type of person who hates planning.
I plan just enough to know what my next move should be,
then I stop planning.
I don't adhere blindly to any "philosophy". The original
philosophy behind Euphoria was to make a language
that was strikingly simpler and easier to learn, with fewer
concepts in it, yet very powerful. As people started to use it,
they pressed me to add all sorts of useful
features. All I can say now is that I am still committed to
improving Euphoria in whatever direction that might lead.
My original "minimalist" bias remains. I'm not simply lazy.
I really believe in keeping the language strikingly simple,
even if it means passing up really "cool" features, or forcing
the programmer to do a bit more typing, or put up with
some minor inconveniences.
You have on many occasions stated that Euphoria
is an "incomplete" product. It seems to me that the
only "complete" software is software that nobody uses.
Actively-used software will always have pressure on it
to grow and change and become more "complete".
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
44. Re: Ideas for next Eu
On Thu, 11 Nov 1999 21:37:30 -0500, Robert Craig <rds at ATTCANADA.NET> wrote:
>Everett Williams writes:
>> Agreed, now how do we get the manager of this hotel
>> to provide us with the items that we have requested?
>> It seems that many of these functions..er..items have
>> been known and requested with some fervor for quite
>> some time by a decent number of the discerning
>> clientele. Either they can't, they don't want to, or they
>> think that spreading out to other platforms will gain
>> them more than completing the language.
>
>I appreciate all suggestions regarding new language
>features. I read all the posts and I add notes to my
>wish list. I am not trying to be rude by not responding.
>There are many reasons why I generally
>do not jump in immediately (or ever) and give
>my opinions on proposed features:
>
> 1. The feature has already been proposed and kicked around
> and the poster is "rediscovering" it.
>
> 2. I'd rather let other people debate it before I prejudice the
> discussion by coming down on one side or the other.
>
> 3. I don't want to drop what I am working on,
> do a full analysis of the feature, and construct a
> detailed response. I can't simply say "right"
> or "wrong" to a new language feature. There are
> many considerations to take into account and a lot
> of it is very subjective.
As I noted in that private email that you speak of hereafter, I know
that you cannot respond to every such email, but a monthly
newsletter posted on the site or sent to the list would really
improve confidence and reduce other demands.
>
>In private e-mail, Everett, you have asked me to
>publish my "philosophy", along with a detailed roadmap
>of where Euphoria is going. This is not easy for me
>to do. I am the type of person who hates planning.
>I plan just enough to know what my next move should be,
>then I stop planning.
>
>I don't adhere blindly to any "philosophy". The original
>philosophy behind Euphoria was to make a language
>that was strikingly simpler and easier to learn, with fewer
>concepts in it, yet very powerful. As people started to use it,
>they pressed me to add all sorts of useful
>features. All I can say now is that I am still committed to
>improving Euphoria in whatever direction that might lead.
>My original "minimalist" bias remains. I'm not simply lazy.
>I really believe in keeping the language strikingly simple,
>even if it means passing up really "cool" features, or forcing
>the programmer to do a bit more typing, or put up with
>some minor inconveniences.
>
>You have on many occasions stated that Euphoria
>is an "incomplete" product. It seems to me that the
>only "complete" software is software that nobody uses.
>Actively-used software will always have pressure on it
>to grow and change and become more "complete".
>
>Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
As the Masai of Southern Africa say, "The great elephant speaks!".
Before I proceed, let me repeat again that which brings me here.
Euphoria is a remarkably elegant algorithmic language of remarkable
simplicity and readability. Normally, that does not just mean simple
as in small. That means intuitive or easily understood or natural. The
"if-then-elseif....else-end if" is a construct of absolute perfection. The
"sequence" is close behind. It allows the description of almost any
form of data, compactly and cleanly. Slices are wonderful, but they
only run one way. How strange, how incomplete. I must refer to
everything in them by subscript...almost as error prone as assembler.
That is, unless I am willing to use a conflict prone and dangerous
method of constants that eats up namespace and memory to little
practical purpose. What is minimalist about that? And what is
minimalist or clean and simple about peek and poke, two very blunt
instruments that bring out everything that is worst in programming
style. Then, we have routine_id(), that broke the simple declare before
use rule in the ugliest possible manner. In my world, those are not
clean, minimalist additions to a clean and minimalist language.
Kluge or SNAFU gets my vote.
I find little to disagree with in what you say except that the results of
what you have done engender/cause what you say you are against.
When a language does not have standard facities for the most basic
functions that a language must perform, it forces the programmers
into complex, forced, non-minimalist solutions to ordinary, everyday
problems. Clean variable usage, modular development, and standard
facilities for handling external data of arbitrary(read that as produced
by languages and facilities other than Euphoria) format are not minor
conveniences. Without these facilities, Euphoria is the perfect language
for writing crystalline clear algorithms suitable for teaching or
learning. With them it becomes a full fledged, commercial language
capable of tackling any task that falls within it's performance
parameters.
Really cool, in my mind, means things like GUI's and IDE's and Games.
You appear to have enough people willing to do the really cool things
if you will just provide the tools to make it cleanly possible. When I say
incomplete, I refer to the big three above and things like sequence
handling that have missing modes. As for active use, I would not
recommend active use of this language for any large, commercial
code or product without the "big three" items above. The rest should
be done just to make coding more straightforward and simple as you
seem to espouse. In any case, I see little active, commercial use of
the product. Most of the action I see is by hobbyists and gamers and
concerns addressing the language's needs in the development area...
libraries, IDE's, GUI's, etc. Use in a serious commercial project in
this day and time requires tools, and a whole lot more information about
your plans and intentions than just "wherever the future leads you".
No responsible decision maker could allow usage of the language in
it's current state with that kind of ringing commitment to progress. It
may not be laziness, but the effect on the language is the same.
I have proposed several solutions to problems that would IMO be
reasonably elegant and compatible with the language as it now
stands(see my description of a null sequence with names and
initialization in a recent post to Irv). Others have done much, much
more(the recent description of a syntax for vertical slices was most
excellent) and are certainly more familiar with the peculiarities of
Euphoria. I have seen compelling discussions of include handling,
and namespaces as everyone knows has been discussed to the
breaking point. Modularity beyond includes I have not found major
discussion on, but it is absolutely necessary for really large projects.
In two of the three areas that I have discussed, there is plenty to go
on to just code it up and make it available. With a little thought, a
solution to true modularity can be found(I have some ideas that I
will get to in other posts). I am sure you can manage on your own
if you wish.
None of this will keep me from using the language and admiring the
language for what it is. Everything that I have seen marks you as a
thoughtful and helpful person when your help is necessary and
needed. It pains me to see your efforts not met with the recognition
they deserve, but that will continue to be the case as long as the
language is limited by it's "incompleteness" as I have defined it above.
I would hope that the language will never truly be complete, but you
might note that the widely used languages have the facilities that I
mention and a very slow change rate. Internal optimization, ports
to other environments, and tools should be most of the work of
completing the language. Additions to basic facilities on a regular
basis should be neither necessary nor desirable.
I hope you have not found this insulting. Insult was no part of my intent.
Progress is.
Everett L.(Rett) Williams
rett at gvtc.com
45. Re: Ideas for next Eu
- Posted by jiri babor <jbabor at PARADISE.NET.NZ>
Nov 12, 1999
-
Last edited Nov 13, 1999
Dear Everett, you are a bloody vandal. It had taken us almost four
years of careful planning / low cunning to lure him out of the
shadows, and you slammed him back into his shell. Shame on you!
jiri
46. Re: Ideas for next Eu
- Posted by nieuwen at XS4ALL.NL
Nov 12, 1999
-
Last edited Nov 13, 1999
> breaking point. Modularity beyond includes I have not found major
> discussion on, but it is absolutely necessary for really large projects.
Modularity is one of the two 'solutions' the group has provided.
I have always pledged for modularity, although a great part of the list, voted
for a dot-like
syntax. .... you really are covering old ground a bit.
> In two of the three areas that I have discussed, there is plenty to go
> on to just code it up and make it available. With a little thought, a
> solution to true modularity can be found(I have some ideas that I
> will get to in other posts). I am sure you can manage on your own
> if you wish.
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
47. Re: Ideas for next Eu
On Fri, 12 Nov 1999 20:45:29 +1300, jiri babor <jbabor at PARADISE.NET.NZ>
wrote:
>Dear Everett, you are a bloody vandal. It had taken us almost four
>years of careful planning / low cunning to lure him out of the
>shadows, and you slammed him back into his shell. Shame on you!
>
>jiri
Jiri,
Sorry, I am alien being unaware of strange habits of indigenous
creatures of type robertus craigus minimalistus. Will defer to your
superior knowledge...and take future posts to "great elephant"
offline.
Remind me to never get caught in a crossfire between you and Irv. If
I were a frog, I might get a leg pulled off.
Everett L.(Rett) Williams
rett at gvtc.com
48. Re: Ideas for next Eu
I think I'd like to make a few comments here.
Everett Williams wrote:
>On Thu, 11 Nov 1999 21:37:30 -0500, Robert Craig <rds at ATTCANADA.NET> wrote:
[...]
>
>Slices are wonderful, but they
>only run one way. How strange, how incomplete.
??? I don't understand this. Run what way?
>I must refer to
>everything in them by subscript...almost as error prone as assembler.
>That is, unless I am willing to use a conflict prone and dangerous
>method of constants that eats up namespace and memory to little
>practical purpose. What is minimalist about that?
Surely you're not suggesting that all index accesses
be forced to be named? That wouldn't fit well with the
concept of a structure of arbitrary size. Allowing just
numeric indexing certainly seems more minimalist (and
'cleaner') than allowing both indexing AND record-like
naming at the same time.
>And what is
>minimalist or clean and simple about peek and poke, two very blunt
>instruments that bring out everything that is worst in programming
>style.
Well, I can easily see them as being minimalist. Any
language that has a prayer at achieving low-level access
needs them. Granted, they are messy, but considering we
live in a C-oriented world (for the most part) and that
much Euphoria programming involves Windows, there's a
clear requirement there as well.
>Then, we have routine_id(), that broke the simple declare before
>use rule in the ugliest possible manner. In my world, those are not
>clean, minimalist additions to a clean and minimalist language.
Well, c'mon, a minimalist attitude must be constrained
by needed features (which I'm sure is your point, but
read on.) I'm sure routine_id will be a point of
controversy for a long time, but apparently, for
Windows programming, it's absolutely *essential*. I.e.,
any minimalist language that is intended to be used
with Windows MUST have it, or it can not be used with
Windows. I don't see most proposed changes to the
language, or proposed points of focus, having that
level of absolute need.
>When a language does not have standard facities for the most basic
>functions that a language must perform, it forces the programmers
>into complex, forced, non-minimalist solutions to ordinary, everyday
>problems. Clean variable usage, modular development, and standard
>facilities for handling external data of arbitrary(read that as produced
>by languages and facilities other than Euphoria) format are not minor
>conveniences. Without these facilities, Euphoria is the perfect language
>for writing crystalline clear algorithms suitable for teaching or
>learning. With them it becomes a full fledged, commercial language
>capable of tackling any task that falls within it's performance
>parameters.
>Really cool, in my mind, means things like GUI's and IDE's and Games.
Just for the record, really cool could mean something
else entirely to other people. Many on this list would
love to see Euphoria fully ready to tackle the business
programming environment. Others still the database
realm. You'd be surprised how many people could care
less about Windows-like environments at all (and probably
secretly dislike all of the effort being put into such.)
I think demanding that GUIs and IDEs or even games be the
primary focus of development for the language is a bit
narrow.
>In any case, I see little active, commercial use of
>the product. Most of the action I see is by hobbyists and gamers and
>concerns addressing the language's needs in the development area...
>libraries, IDE's, GUI's, etc.
Which would likely be true of any young language that
1) hasn't received a lot of media hype, 2) isn't a spin-
off a currently hot language, and 3) doesn't use one
principle "hook" (like complete cross-platforming, or
Internet suitability) to sell to people.
>No responsible decision maker could allow usage of the language in
>it's current state with that kind of ringing commitment to progress. It
>may not be laziness, but the effect on the language is the same.
This is going too far. Rob's lack of structures,
function indexing, etc. doesn't make him irresponsible.
He's under NO obligation whatsoever to provide a Swiss-
army-knife product along the lines of Visual Basic,
capable of writing practically any heavy-duty commercial
project desired. Frankly, there's really no reason to
expect him to want such. (It's to his credit that he
hasn't already just gotten fed up with our continual
demands and stepped out of the picture entirely.
Especially considering that the very layout of the
language implies the route he wants to take with it,
and a lot of the suggestions try to pull it onto a
different route.)
If Rob DOES want to see major commercial use of his
language, at the expense of everything else, then yes,
there are things the language still needs, things that
have been mentioned before on the list, including--as
you mentioned--a need for planning. But apparently,
he has limits as to the what he's willing to sacrifice
for that commercial use. And to criticize him for not
immediately implementing specific tools/features/etc.
that would lead to such utility, or for going about
developing the language in a way that doesn't suit your
particular needs (or for that matter, anyone else's
particular needs) is unwarranted. Progress, like what
would make the language "cool", can mean entirely
different things to different folks.
>Insult was no part of my intent.
>Progress is.
Likewise with my comments.
Rod Jackson
49. Re: Ideas for next Eu
Well done, guys & gals, congratulations. The last few days have been,
no doubt, the finest in the long history of the list. Just about every
imaginable tabu has been broken, just about every body worth insulting
was successfully insulted, we have also extracted half a confession
from Rob and, most importantly, we have the conservatives on the run!
(And not a line of code in sight!)
Just keep it coming. jiri
50. Re: Ideas for next Eu
Mr. Jackson,
Points very well taken. I appreciate your manner and your concerns. I don't
happen to agree entirely with you, but I like your style. Please read on.
> Roderick Jackson wrote:
>>
>>Slices are wonderful, but they
>>only run one way. How strange, how incomplete.
>
>??? I don't understand this. Run what way?
Rather than say run what way, say how do I describe a column or a
range of columns in a two-dimensional structure without a chiropracter
to realign my spine when I get through.
>
>>I must refer to
>>everything in them by subscript...almost as error prone as assembler.
>>That is, unless I am willing to use a conflict prone and dangerous
>>method of constants that eats up namespace and memory to little
>>practical purpose. What is minimalist about that?
>
>Surely you're not suggesting that all index accesses
>be forced to be named? That wouldn't fit well with the
>concept of a structure of arbitrary size. Allowing just
>numeric indexing certainly seems more minimalist (and
>'cleaner') than allowing both indexing AND record-like
>naming at the same time.
Absolutely not, indexes are useful and sometimes absolutely
necessary in ill-defined data. We don't have just numeric indexing,
we already have a redefinition or a naming of a datum called a constant.
In a minimalist language, constants are not necessary. They are a
subset of and can be emulated with variables. If we are going to have
descriptive naming (most useful in fixed structures, but somewhat
applicable in variable structures also), why don't we do it right?
Constants occupy real memory and namespace and are inherently
deceptive, when used as indexes. They seem to say that they are
picking out whatever item that their name indicates, when in
reality, they are just place holders for a number which logically
would vary across different sequences with the same "content" in
different locations or pointed to by different indexes to be correct.
Indexes are no different from and no more informative than offsets
in assembler. They are needed, but do we really want to look at them
in a high level language any more than is absolutely necessary. If
you look at most modern assemblers that use named offsets you
will have the answer to your question.
>>And what is
>>minimalist or clean and simple about peek and poke, two very blunt
>>instruments that bring out everything that is worst in programming
>>style.
>
>Well, I can easily see them as being minimalist. Any
>language that has a prayer at achieving low-level access
>needs them. Granted, they are messy, but considering we
>live in a C-oriented world (for the most part) and that
>much Euphoria programming involves Windows, there's a
>clear requirement there as well.
I absolutely deny that peek and poke are the only way to accomplish
what you are speaking of here. Even C allows access to variables in
inline assembler rather than force the type of machine code level
programming that peek and poke generate.
>
>>Then, we have routine_id(), that broke the simple declare before
>>use rule in the ugliest possible manner. In my world, those are not
>>clean, minimalist additions to a clean and minimalist language.
>
>Well, c'mon, a minimalist attitude must be constrained
>by needed features (which I'm sure is your point, but
>read on.) I'm sure routine_id will be a point of
>controversy for a long time, but apparently, for
>Windows programming, it's absolutely *essential*. I.e.,
>any minimalist language that is intended to be used
>with Windows MUST have it, or it can not be used with
>Windows. I don't see most proposed changes to the
>language, or proposed points of focus, having that
>level of absolute need.
You're cheating again...switching boats..er..arguments in mid-discussion.
Minimalist does not mean small or even simple. It means the minimum
necessary to effiiently accomplish the goal(in the dictionary according to
Everett Williams ) I am a strong believer in Occam's razor, that says
when presented with two EQUAL(emphasis mine) solutions to a problem
the simpler one is normally the better choice. Now if the simpler solution
is already superior by some fairly complete set of criteria, then Occam's
razor is unnecessary. When the simpler solution is weaker, the going
gets tough. Decisions, decisions...then the problem must be altered to
allow a less than optimum solution. Usually the problem is altered by
non-technical factors such as time, money, etc.
Now, back to your switched argument. I'm not ready to admit that
routine_id() is the only or even the optimal solution to the problem
of Windows programming. Something that accomplishes what
routine_id() does is necessary. If I want to kill a mouse in my house,
I use poison, or a trap, or at most a .22 with ratshot in it. If I go get
an army tank, I really trash the house in the process. Enough! System
routines that request the same facilities that are provided by peek, poke,
routine_id, call_C, and their ilk can be written and optimized in the
interpreter. Then, if we have real data structures that address real
world data(not designed or provided by another Euphoria program) and
these system routines, we can code ordinary looking Euphoria code
to accomplish these ends. I grant that available time and effort limits
may have prompted the creation of these ugly ducklings, but I
would suggest that they have created and will create a lot of ugly
code that will truly injure the clean, minimal nature of Euphoria before
they are excised.
>
>>When a language does not have standard facities for the most basic
>>functions that a language must perform, it forces the programmers
>>into complex, forced, non-minimalist solutions to ordinary, everyday
>>problems. Clean variable usage, modular development, and standard
>>facilities for handling external data of arbitrary(read that as produced
>>by languages and facilities other than Euphoria) format are not minor
>>conveniences. Without these facilities, Euphoria is the perfect language
>>for writing crystalline clear algorithms suitable for teaching or
>>learning. With them it becomes a full fledged, commercial language
>>capable of tackling any task that falls within it's performance
>>parameters.
>
>>Really cool, in my mind, means things like GUI's and IDE's and Games.
>
>Just for the record, really cool could mean something
>else entirely to other people. Many on this list would
>love to see Euphoria fully ready to tackle the business
>programming environment.
I don't ordinarily like to insert comments in the middle of a paragraph,
but this time I must. Having Euphoria ready to and capable of
handling the business programming environment is my most
fervent wish. IDE's and similar items are just tools to effect that end.
I'm not into "really cool" of any kind. I'm into getting work done. I just
borrowed somebody else's phrase.
>Others still the database
>realm. You'd be surprised how many people could care
>less about Windows-like environments at all (and probably
>secretly dislike all of the effort being put into such.)
>I think demanding that GUIs and IDEs or even games be the
>primary focus of development for the language is a bit
>narrow.
That must have been my evil twin My only interest in GUI's is
that they are where most programming is done these days. If
Windows had a true character environment that did not invoke a
DOS window, I would love it. Proportional text makes messy pudding
out of source code. I do, however, believe that an IDE is a practical
necessity in a modern programming environment. The text environment
of the IBM TSO/SPF or VM/CMS environment in it's later incarnations
with REXX as a macro language were/are truly powerful programming
environments. In VM, you could even immediately route the program
test to another virtual machine running whatever platform was your target
environment, switch to that window, observe, and switch back to fix
whatever errors that you had. I'll take and use all the GUI facilities for
the tools and the output, but source code in any other than fixed format
is a positive pain in the tush.
>>In any case, I see little active, commercial use of
>>the product. Most of the action I see is by hobbyists and gamers and
>>concerns addressing the language's needs in the development area...
>>libraries, IDE's, GUI's, etc.
>
>Which would likely be true of any young language that
>1) hasn't received a lot of media hype, 2) isn't a spin-
>off a currently hot language, and 3) doesn't use one
>principle "hook" (like complete cross-platforming, or
>Internet suitability) to sell to people.
I wouldn't denigrate those "hooks" that you refer to above. Euphoria
can get to several of them IMO. And, getting to one of them would
make it a currently hot language. Computing in the modern environment
isn't the "crystal palaces" of "Kublai Khan". Mr.'s Gates and Grove have
shown that it is a lot more like mud wrestling. Anything that
survives in this environment will get a little dirt on it. Doing things
like peek, poke, and routine_id() is like throwing a fight before the
opening round bell has rung.
>>No responsible decision maker could allow usage of the language in
>>it's current state with that kind of ringing commitment to progress. It
>>may not be laziness, but the effect on the language is the same.
>
>This is going too far. Rob's lack of structures,
>function indexing, etc. doesn't make him irresponsible.
>He's under NO obligation whatsoever to provide a Swiss-
>army-knife product along the lines of Visual Basic,
Who would want that? Adding practical programming tools to
Euphoria will not make a sow's ear out of this silk purse unless
the tools are implemented in a thoughtless fashion.
>capable of writing practically any heavy-duty commercial
>project desired.
I desire, I desire.
> Frankly, there's really no reason to
>expect him to want such. (It's to his credit that he
>hasn't already just gotten fed up with our continual
>demands and stepped out of the picture entirely.
>Especially considering that the very layout of the
>language implies the route he wants to take with it,
>and a lot of the suggestions try to pull it onto a
>different route.)
>
>If Rob DOES want to see major commercial use of his
>language, at the expense of everything else, then yes,
>there are things the language still needs, things that
>have been mentioned before on the list, including--as
>you mentioned--a need for planning. But apparently,
>he has limits as to the what he's willing to sacrifice
>for that commercial use. And to criticize him for not
>immediately implementing specific tools/features/etc.
>that would lead to such utility,
In the accelerated world that we live in, 3 1/2(it could be longer,
I am just going by the date of the beginning of the list) years is not
immediately. It isn't even "andante". It's more the pace of
Sancho Panza's burro. The big "IF" is "DOES Rob want to see
major commercial use of his language", period. I WOULD DEARLY
LOVE TO HAVE AN ANSWER TO THAT QUESTION. Most of the
"expenses" that you and I have mentioned will make the language
more "complete" or "symmetric" or "orthogonal". They will leave
the language orders of magnitude less complex than the nearest
competition and will allow the commercial use we are speaking of.
If there is no intent to get to that goal, then Euphoria is just a really
elegant hobby tool that has sucked up a great deal of time and
effort by a group of really talented people that could have been using
their efforts towards some productive goal. It's only utility would then
be as a training or learning tool(not an ignoble goal by any means).
Of course, anyone who learns on Euphoria is really going to hate
the "real" world of C, etc. and wonder why Euphoria never grew up.
> or for going about
>developing the language in a way that doesn't suit your
>particular needs (or for that matter, anyone else's
>particular needs) is unwarranted. Progress, like what
>would make the language "cool", can mean entirely
>different things to different folks.
Thirty-three years of experience with dozens of languages and
many different programming environments makes my
understanding of "needs" a little different than the understanding
of the average newbie. The fact that the core needs that I refer
to are echoed in large part by what I perceive as a majority(if with varying
methods) of the experienced types that I note on this forum, makes me
think that my requests are neither narrow nor too specific. I have
acquired and helped write software tools for engineering, corporate, and
software development environments. I have been a senior systems
programmer responsible for the software, security, stability, and
performance, not to mention troubleshooting of every problem that no
one else could figure out, of the mainframes of a multi-billion dollar
corporation in the late 70s when b meant a big number and didn't make
anybody think of Bill Gates.
>>Insult was no part of my intent.
>>Progress is.
>
>Likewise with my comments.
>
>Rod Jackson
If the answer to the above critical question is YES, then I guess I will
try to pipe down and wait to see what Rob's next move is. I am not into
guru's or other such theocracies, no matter how God-like or capable,
so being dependent on the whim of a single person gives me gas.
Impatiently yours,
Everett L.(Rett) Williams
rett at gvtc.com
51. Re: Ideas for next Eu
- Posted by nieuwen at XS4ALL.NL
Nov 14, 1999
> Constants occupy real memory and namespace and are inherently
They don't. The interpreter just 'fills' em in, and releases the memory.
Would they occupy real memory, you would be allowed to make constants
dynamically,
rather than only on the top-level. (so, they can all be replaced before the code
is start)
> I absolutely deny that peek and poke are the only way to accomplish
> what you are speaking of here. Even C allows access to variables in
> inline assembler rather than force the type of machine code level
> programming that peek and poke generate.
The grammer of language, determines how we manage our code. This I won't get
into now.
The routines/commands of a language, determine what our code is capable of
doing. There
are a million things really *not* possible without peek & poke. From custom
mouse routines,
to ... plus, about these routines: don't like 'em, don't use them. All these
examples of better
interfaces to win32 .. ("even C allows .. ") .. all these alternatives can be
added to Euphoria
by writing a routine and putting it into a library ... those routines however
would use peek and
poke. Now what if you like your alternative and I like another, should Robert
add them both
? Of say, I'm giving your peek/poke and you help yourself. Programming is always
about
doing something hard in the most simple way possible. You don't want to program.
You want
to be able to say .. "eh like-doom, but eh .. the gun should look like .. and
.. " ... or you
could just write the freaking enginge yourself in Euphoria. Low-level acces is a
must. Think
about it. Technically, you should be able to do anything with Euphoria. From any
type of
algorithm to acces to every part of the system. The whole declare_dll, etc. part
of Euphoria is
actually redunant as well. (it could have been done in Euphoria, and put into an
include) ..
> Minimalist does not mean small or even simple. It means the minimum
> necessary to effiiently accomplish the goal(in the dictionary according to
> Everett Williams ) I am a strong believer in Occam's razor, that says
Look at what you're now saying. It goes completely against the argument you use
againt
poke & peek. And considering the subject, you are using the argument on. It's
rubbish.
Routine-id has more right to exist (using YOU"re definition of minimalistic!)
than normal the
ability to directly call a function. It would allow us to write/use any scope
mechanism that we
like, very powerfyll, it really is the minimum nessasary to accomplish any goal.
> allow a less than optimum solution. Usually the problem is altered by
> non-technical factors such as time, money, etc.
Eh .. ok.
> code that will truly injure the clean, minimal nature of Euphoria before
> they are excised.
Completely the opposite. What you want to do is limit what is possible with
Euphoria.
Less goals, less features. Irregardless of the fact I couldn't care less or more
about
minimalistic (it's not a goal on itself! it's just a word you came accros in
Robert mail the other
day ... now, speaking about cheating (as you were occusing Roderick of) ...
*thats*
cheating. With the routine-id mechanism, David is capable of writing Liama ..
99% of Liama
runs using any GUI. 1% is the OS-specific part. Would routine-id be replaced by
specific
interfaces that differ (routine-id and the dll-linkage routines are all equal
for every OS) for
each OS, he would have to write that 99% differently for each OS.
Minimalistic you say ?
> I don't ordinarily like to insert comments in the middle of a paragraph,
> but this time I must. Having Euphoria ready to and capable of
> handling the business programming environment is my most
> fervent wish. IDE's and similar items are just tools to effect that end.
> I'm not into "really cool" of any kind. I'm into getting work done. I just
> borrowed somebody else's phrase.
Most of us are doing this Euphoria stuff for fun. What makes your motives so
much more
important than ours. Plus, those tools are already there. Why re-invent a wheel,
instead of
creating something new, fill a gap, ....... maybe some prefer a bicycle ..
> That must have been my evil twin My only interest in GUI's is
> that they are where most programming is done these days. If
Yeah, yeah. Cities are where most ppl live. Is this because of the much
healthier environment
? Is this because of the all the great advantages of living in a big city. You
know, smoke,
traffic jams .. etc.
So, now you want to cut down the trees, and turn this forest into big city no.
23987u52
Great!
> Sancho Panza's burro. The big "IF" is "DOES Rob want to see
> major commercial use of his language", period. I WOULD DEARLY
Come on. Would he do that, MS Euphoria would be out in a week, packed with every
new
version of windows, and within month market leader in the 'euphoria section'.
Maybe Robert
is just picking fights he can win.
You think its all *that* easy. That is really works like your simplied version
of reality,
simplified in need for you comprehension. Maybe, just maybe, there's more to it.
Plus, trying to create a perfect language, has got nothing to do with a
development curve, a
future plan, or whatever. Only huge companies take that route. They, purposely,
create an
non ideal program, that can be replaced by better versions for years to come.
Honest, a
perfect OS is not commercially effective, unless you patents every part of it.
But I don't think
any small company is capable of such high legal investments of today's
-out-of-balance-
society where courts rule over the other two (what were they again ? lol.)
aspects of
democracy that should have been able to keep the judge from playing god.
> Of course, anyone who learns on Euphoria is really going to hate
> the "real" world of C, etc. and wonder why Euphoria never grew up.
I'm already hating C. So why create another ?
You can't be on top of a mountain and be perfect. Goverments are never
right.Jalousy and
affection really are the two only emotion, we're having. The best music is never
to be found in
charts, pushed by their marketing agents (ouch, there I said it!) Looks are
important ...
.................. and Euphoria can't be great and be used by the avarage user
as well. It just
doesn't work that way!
The avarage user, uses avarage tools. The avarage music listener listens to
avarage music.
And the avarage tree catches an avarage amount of wind. You're an idealist, like
most of us
are, but you should be realistic as well. Euphoria's development is part of
Robert's Income.
We all want to change the world, but are you're risking your ass ?
> corporation in the late 70s when b meant a big number and didn't make
> anybody think of Bill Gates.
Bill Gates got the avarage user involved in PC's.
What does it got to do with us ?
> >>Insult was no part of my intent.
> >>Progress is.
> >
> >Likewise with my comments.
Likewise.
> If the answer to the above critical question is YES, then I guess I will
> try to pipe down and wait to see what Rob's next move is. I am not into
> guru's or other such theocracies, no matter how God-like or capable,
> so being dependent on the whim of a single person gives me gas.
Learn C. Write your own language. Why not use this urge to independency as a
creative
stimulans ? Because you are right, it's unfortunate that we're all so dependent
on some much.
Of which most are just ungraspable mechanics of society, rather than persons you
can
discuss with. Wouldn't it be great if there was a director of social rules, open
for any new
ideas and critism ? ... I think we're lucky that we are talking to a person.
Rather than to
society, companies, or goverments. Would this mailing list still be able when
Euphoria is as
big as you want it to be ? No it, wouldn't .. how would you feel when
you've got a mail
like you had, but didn't have a place to sent it to. When you weren't part of
the discussion.
Dependance is one thing. At least you're able to have some influence.
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
52. Re: Ideas for next Eu
- Posted by Roderick Jackson <rjackson at CSIWEB.COM>
Nov 15, 1999
-
Last edited Nov 16, 1999
Well, I'll try to keep this brief for all concerned, but
we'll see how it goes...
Everett Williams wrote:
> Roderick Jackson wrote:
>>>
>>>Slices are wonderful, but they
>>>only run one way. How strange, how incomplete.
>>
>>??? I don't understand this. Run what way?
>
>Rather than say run what way, say how do I describe a column or a
>range of columns in a two-dimensional structure without a chiropracter
>to realign my spine when I get through.
Okay, I understand a desire for columns, but how does a lack
of a facility to get at them make the language incomplete? If
I recall correctly, C doesn't allow you to extract a column
from a 2D structure either...
(Please note that this question does NOT mean I'm trying to
say that the language is complete.)
>>>I must refer to
>>>everything in them by subscript...almost as error prone as assembler.
>>>That is, unless I am willing to use a conflict prone and dangerous
>>>method of constants that eats up namespace and memory to little
>>>practical purpose. What is minimalist about that?
>>
>>Surely you're not suggesting that all index accesses
>>be forced to be named? That wouldn't fit well with the
>>concept of a structure of arbitrary size. Allowing just
>>numeric indexing certainly seems more minimalist (and
>>'cleaner') than allowing both indexing AND record-like
>>naming at the same time.
>
>Absolutely not, indexes are useful and sometimes absolutely
>necessary in ill-defined data.
[...]
>Indexes are no different from and no more informative than offsets
>in assembler. They are needed, but do we really want to look at them
>in a high level language any more than is absolutely necessary.
Uh-uh... we're asking if only having indexes follows
Rob's minimalist bias. And since anything that can
be done with named elements can be done via indexing...
>>>And what is
>>>minimalist or clean and simple about peek and poke, two very blunt
>>>instruments that bring out everything that is worst in programming
>>>style.
>>
>>Well, I can easily see them as being minimalist. Any
>>language that has a prayer at achieving low-level access
>>needs them. Granted, they are messy, but considering we
>>live in a C-oriented world (for the most part) and that
>>much Euphoria programming involves Windows, there's a
>>clear requirement there as well.
>
>I absolutely deny that peek and poke are the only way to accomplish
>what you are speaking of here. Even C allows access to variables in
>inline assembler rather than force the type of machine code level
>programming that peek and poke generate.
How does allowing assembler make it any different?
Cleaner looking, yes, but in my mind I really don't
see a difference between
poke (addr, value)
and
MOV #7F, ADDR
>>>Then, we have routine_id(), that broke the simple declare before
>>>use rule in the ugliest possible manner. In my world, those are not
>>>clean, minimalist additions to a clean and minimalist language.
>>
>>Well, c'mon, a minimalist attitude must be constrained
>>by needed features (which I'm sure is your point, but
>>read on.) I'm sure routine_id will be a point of
>>controversy for a long time, but apparently, for
>>Windows programming, it's absolutely *essential*. I.e.,
>>any minimalist language that is intended to be used
>>with Windows MUST have it, or it can not be used with
>>Windows. I don't see most proposed changes to the
>>language, or proposed points of focus, having that
>>level of absolute need.
>
>You're cheating again...switching boats..er..arguments in mid-discussion.
>Minimalist does not mean small or even simple. It means the minimum
>necessary to effiiently accomplish the goal(in the dictionary according to
>Everett Williams )
Well, I don't really have a problem with a constraint on
that. In other words, describing Euphoria as "a minimalist
language for Windows" as opposed to just "a minimalist
language." In which case some facility allowing for Windows
interaction is inherint in the definition.
>I am a strong believer in Occam's razor, that says
>when presented with two EQUAL(emphasis mine) solutions to a problem
>the simpler one is normally the better choice.
[...]
>Now, back to your switched argument. I'm not ready to admit that
>routine_id() is the only or even the optimal solution to the problem
>of Windows programming. Something that accomplishes what
>routine_id() does is necessary. If I want to kill a mouse in my house,
>I use poison, or a trap, or at most a .22 with ratshot in it. If I go get
>an army tank, I really trash the house in the process. Enough! System
>routines that request the same facilities that are provided by peek, poke,
>routine_id, call_C, and their ilk can be written and optimized in the
>interpreter.
You seem to be implying some specific construct, but I
guess it's going over my head... how would you propose
allowing Windows to call one of your functions without
a command that has all of routine_id()'s functionality?
I can't think of any other alternative.
>>Others still the database
>>realm. You'd be surprised how many people could care
>>less about Windows-like environments at all (and probably
>>secretly dislike all of the effort being put into such.)
>>I think demanding that GUIs and IDEs or even games be the
>>primary focus of development for the language is a bit
>>narrow.
>That must have been my evil twin
Oh, just stick around the list long enough. They'll make
themselves known (no offense to them...)
>My only interest in GUI's is
>that they are where most programming is done these days.
Mmmm, ummm, I'll admit, I don't have your broad work
experience in the programming realm, so I won't
venture to deny or support that, but I know a number
of similarly experienced people who would *vehemently*
oppose that statement. 
[...]
>I'll take and use all the GUI facilities for
>the tools and the output, but source code in any other than fixed format
>is a positive pain in the tush.
Well, I'll second that!
(Side-note to anyone involved with ACI and their 4D
IDE... get rid of the proportional font!!!)
>>In any case, I see little active, commercial use of
>>the product. Most of the action I see is by hobbyists and gamers and
>>concerns addressing the language's needs in the development area...
>>libraries, IDE's, GUI's, etc.
>
>Which would likely be true of any young language that
>1) hasn't received a lot of media hype, 2) isn't a spin-
>off a currently hot language, and 3) doesn't use one
>principle "hook" (like complete cross-platforming, or
>Internet suitability) to sell to people.
>I wouldn't denigrate those "hooks" that you refer to above. Euphoria
>can get to several of them IMO. And, getting to one of them would
>make it a currently hot language. Computing in the modern environment
>isn't the "crystal palaces" of "Kublai Khan". Mr.'s Gates and Grove have
>shown that it is a lot more like mud wrestling. Anything that
>survives in this environment will get a little dirt on it. Doing things
>like peek, poke, and routine_id() is like throwing a fight before the
>opening round bell has rung.
Well, concerning the "mud wrestling", I'll quickly
admit to that. But, personally, that's my concern.
That Euphoria, in the drive to become "market-savvy",
will get so dirty as to lose it's original shine.
I'd rather have it shiny and not-as-popular-or-even-
useful instead of the opposite. I can already use
languages like that.
Oh, and about the hooks, I'm not belitting them. If
you ask me, building a language around one principle
element that also acts as a hook is a great thing;
unfortunately, I don't see Euphoria as having anything
like that ("simplicity", while potent, just doesn't
seem to come across as an attention-grabber anymore.)
[...]
>The big "IF" is "DOES Rob want to see
>major commercial use of his language", period. I WOULD DEARLY
>LOVE TO HAVE AN ANSWER TO THAT QUESTION.
Understood. However, he might not be able to fully
answer that question himself. I'm not sure I'd be
able to in his situation.
[...]
>If there is no intent to get to that goal, then Euphoria is just a really
>elegant hobby tool that has sucked up a great deal of time and
>effort by a group of really talented people that could have been using
>their efforts towards some productive goal.
Ugh... I really wish you wouldn't look at it that way.
I chose to use Euphoria because of what it currently is.
I want to work with it, even if that means I won't rake
in the cash, fame, or even "productivity" of C, Java,
etc. I'd rather spend my free time writing code for
myself in Euphoria than using C to make Mr. Gates' next
blockbuster app. Granted, if Euphoria didn't exist
I could use my free time writing for myself in C, but I
think I wouldn't like it as much.
I'm sure a lot of potentially brilliant engineers choose
to tinker with stuff in their garage rather than go the
accepted route. I don't consider such a decision a loss.
> It's only utility would then
>be as a training or learning tool(not an ignoble goal by any means).
>Of course, anyone who learns on Euphoria is really going to hate
>the "real" world of C, etc. and wonder why Euphoria never grew up.
Hmm... I think I'd be critical of any course that only
used one tutorial language in the first place. Although,
I'd wager a bet that a programmer "weaned" on just
Euphoria would probably hit C and wonder why on earth
anyone would use it if they didn't have to. (Yes, I
said "weaned"--I can't think of a more clear phrase
right now, so...)
>> or for going about
>>developing the language in a way that doesn't suit your
>>particular needs (or for that matter, anyone else's
>>particular needs) is unwarranted. Progress, like what
>>would make the language "cool", can mean entirely
>>different things to different folks.
>Thirty-three years of experience with dozens of languages and
>many different programming environments makes my
>understanding of "needs" a little different than the understanding
>of the average newbie.
I can understand that. But remember, newbies have
needs too.
>If the answer to the above critical question is YES, then I guess I will
>try to pipe down and wait to see what Rob's next move is. I am not into
>guru's or other such theocracies, no matter how God-like or capable,
>so being dependent on the whim of a single person gives me gas.
Well, I'm not trying to put Rob on a pedastal, but I
really don't have a problem with the way he's doing
things now. And to be honest, I don't feel *entirely*
secure with Euphoria being in just his hands. However,
there are advantages to the situation, and hey--it's
HIS brainchild--so I'm not going to complain.
Rod Jackson
53. Re: Ideas for next Eu
- Posted by Greg Phillips <i.shoot at REDNECKS.COM>
Nov 15, 1999
-
Last edited Nov 16, 1999
Here's another program flow idea:
restart(id)
where id is the name of an enclosing function or procedure.
Consider the following:
integer a
a = 0
procedure test()
a+=1
if a != 2 then
restart(test)
end if
puts(1, "a = 2!!")
end procedure
restart(test) implies that execution continues at the start of the procedure.
It could be used in conjunction with exit() to test for certain conditions.
Useless? Maybe. But heck, it's an idea.
Regards,
Greg Phillips
54. Re: Ideas for next Eu
----- Original Message -----
From: Greg Phillips <i.shoot at REDNECKS.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Tuesday, November 16, 1999 12:04 AM
Subject: Re: Ideas for next Eu
> Here's another program flow idea:
> restart(id)
> where id is the name of an enclosing function or procedure.
> Consider the following:
>
> integer a
> a = 0
>
> procedure test()
> a+=1
> if a != 2 then
> restart(test)
> end if
> puts(1, "a = 2!!")
> end procedure
>
> restart(test) implies that execution continues at the start of the
procedure.
> It could be used in conjunction with exit() to test for certain
conditions.
>
> Useless? Maybe. But heck, it's an idea.
Is that a "goto start of proc" or a recursive self-call ? Ie, do the vars
get reset, or new vars built?
Kat
55. Re: Ideas for next Eu
- Posted by Greg Phillips <i.shoot at REDNECKS.COM>
Nov 15, 1999
-
Last edited Nov 16, 1999
Kat wrote:
> From: Greg Phillips <i.shoot at REDNECKS.COM>
> > Here's another program flow idea:
> > restart(id)
> > where id is the name of an enclosing function or procedure.
> > Consider the following:
> >
> > integer a
> > a = 0
> >
> > procedure test()
> > a+=1
> > if a != 2 then
> > restart(test)
> > end if
> > puts(1, "a = 2!!")
> > end procedure
> >
> > restart(test) implies that execution continues at the start of the
> procedure.
> > It could be used in conjunction with exit() to test for certain
> conditions.
> >
> > Useless? Maybe. But heck, it's an idea.
>
> Is that a "goto start of proc" or a recursive self-call ? Ie, do the vars
> get reset, or new vars built?
>
> Kat
The program just jumps to the start of the proc, with no resetting of vars.
Scope rules apply, however, so if a var is initialized *in* the proc, as
opposed to outside, as in the above example, it is reinitialized each time.
Greg
56. Re: Ideas for next Eu
> As the Masai of Southern Africa say, "The great elephant speaks!".
I didn't know there were masai in Southern Africa. Did you mean
Eastern africa ?
57. Re: Ideas for next Eu
On Tue, 16 Nov 1999 11:57:02 +0100, Raude Riwal <RAUDER at THMULTI.COM> wrote:
> > As the Masai of Southern Africa say, "The great elephant speaks!".
>
> I didn't know there were masai in Southern Africa. Did you mean
>Eastern africa ?
Now you're going to get technical with me on the Masai..yikes! I didn't say
SOUTH Africa, as in the country...I said southern Africa...as in any place
south of the midline of the bulge running east/west...
whichever you prefer. But, you are right. Go back to pumping oil
Everett L.(Rett) Williams
rett at gvtc.com
