1. Improvements
On Sat, 26 Aug 2000, Rob wrote:
> Derek Parnell writes:
> > this discussion reminds me to ask what plans do you
> > have for the next (and subsequent) release of Euphoria
> The translator will keep me busy for several more weeks.
> After that I'll do some namespace improvements,
> after consulting with this mailing list.
1. There's general agreement that we need to eliminate namespace collisions,
without breaking already existing code, if possible.
2. The proliferation of OOP add-ons shows that some variation of
the object-oriented approach is wanted by at least some of us.
Unfortunately, all of these efforts are made slower, more difficult
and syntactically awkward by the lack of access to Euphoria internals.
Here's my proposal:
1. The interpreter should append (internally) an indicator to each
global variable or routine which indicates which include file it came from.
When a variable or routine is referenced, if there is only one use of that
name, things work just as they do now..
If there is more than one like-named variable or routine, the most-recently
declared version is assumed, but a warning message (similar to the
unused variable message) is issued. For example:
mainprog.ex - line 39
coords = {10,20} <- referencing sequence coords from window.e
window.e - line 100
x = foo() <- referencing function foo() from button.e
That way, if the program doesn't act as expected, we have a clue as to what is
wrong, and once things work ok, we can turn off the warnings.
Suppose we want to override the default "most recently declared" rule, and
want to refer to the coords variable in button.e, not the one in window.e?
The alternatives include:
button.coords = {10,20} -- dot notation as in Pascal, etc. (one keystroke)
button->coords = {10,20} -- (minus,shift, > = 3 key strokes, no more meaning)
button~coords = {10,20} -- let's be different.
It's also _very_ useful to have a more concise notation for referencing
multiple vars, e.g.
with button do
coords = {10,20}
size = {400,200}
end with
or, button~
coords = {10,20},
size = {400,200}
You'll notice that this more or less emulates the dreaded "structure":
without calling it that. ;)
However, I'd really like to see this taken a step further:
Once we have a way to declare variables / functions / procedures with the
same name in more than one include, think how nice it would be if we could
declare multiple instances of things described in those include files:
-- button.e
global sequence coords, size, colors, text
global procedure show()
.....
-- window.e
global sequence title
global procedure show()
....
-- MyProgram.ex
include button.e as button -- kind of an improved "type" declaration
include window.e as window
button ok_btn, cancel_btn -- create 2 instances of each new improved "type"
window mainwin, about
ok_btn~size = {80,20} -- each instance has its own copy of the variables
cancel_btn~size = {120,20}
ok_btn~text = "%OK"
cancel_btn~text = "&Cancel"
mainwin~coords = {1,1} -- coords inherited from button.e
mainwin~title = "My Program"
about.~title = "About this program...."
Let's take this to its logical conclusion, and in the process, improve on the
usual OOP notation as follows:
show(mainwin)
show(ok_btn)
show(cancel_btn)
Note that there is a show() procedure declared in button.e, and another
different show() procedure declared in window.e,
Euphoria should be able to call the correct one based on information stored
in the instance passed to the call - i.e. show(mainwin) calls window.e show(),
while show(ok_btn) and show(cancel_btn) call the show() procedure in button.e.
No dot notation needed!
If there were no locally declared show() routine in window.e, however, then the
global procedure show() in button.e would be called, as button.e was included
before window.e. That wouldn't necessarily be a problem, but it might justify a
warning message.
Not having access to the internals of Euphoria, I don't know how hard it would
be to implement this, but I can't see anything impossible about it.
Regards,
Irv
2. Re: Improvements
Thanks for the suggestions Irv.
I read them all. They sound reasonable.
I'll put them in my "name space" e-mail
folder and ponder them again in a few weeks.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Improvements
Will something be done about the problem that you have to have all routines
that you use, before you? Because that's what I think is the real problem.
The namespace problem you can avoid like this: WHAT_button.
4. Re: Improvements
On Mon, 28 Aug 2000, you wrote:
> Will something be done about the problem that you have to have all routines
> that you use, before you? Because that's what I think is the real problem.
I see no problem here. The reason Euporia can load, interpret, and run
a 300 line program more quickly than gcc can compile a 3 line C program,
is that Euphoria doesn't have to do a lot of preprocessing and backtracking.
If you expect to scatter routines at random thru the code, then we'll have to
put up with that backtracking. Declaring routines before use is no more
trouble than declaring them afterward, and having a consistent structure
makes a program easier to understand. That is: if you see a reference to
a variable or a function, you already know where to look for it. - in fact,
you should have already read the definition.
example:
quick now, how many parameters can be sent to the function zpar() ?
What value(s) does it return?
Don't know, do you?
You would if it had been declared already!
> The namespace problem you can avoid like this:WHAT_button. --
So, when I use an include file from Jiri, and another from Dave, I have to
rewrite the names of globals in one or both? Not only does that invalidate the
"stamp", but when Jiri updates his file, I have to go in and modify the new
one again? I don't see how that is any solution at all.
Regards,
Irv
5. Re: Improvements
Irv wrote:
> quick now, how many parameters can be sent to
> the function zpar()? What value(s) does it return?
> Don't know, do you?
>
> You would if it had been declared already!
The more interesting question is, does Euphoria know?
It doesn't seem to. After all, I can't ask if it knows the "zpar" routine,
what the parameter count and type are, or if it's a function or a procedure.
There's no reflection in Euphoria.
>> The namespace problem you can avoid like this:WHAT_button. --
>
> So, when I use an include file from Jiri, and
> another from Dave, I have to rewrite the names
> of globals in one or both?
Once we have namespaces, Jiri and Dave would get around to rewriting their
libraries, and remove the global declarations. Then you would reference them
properly as:
jiri.GLOBAL_IN_ONE
dave.GLOBAL_IN_ONE
I suppose that Robert could design the namespace directive to ignore all
"global" declarations in a module, so you wouldn't have to rewrite any older
modules, but this is a bit of a hack.
-- David Cuny
6. Re: Improvements
>It's also _very_ useful to have a more concise notation for referencing
>multiple vars, e.g.
>with button do
> coords = {10,20}
> size = {400,200}
>end with
Just use one of the syntaxes, not all of them. I don't like the dot nation
.. Euphoria programs already have a tendacy to have command lines that are
just a bit tooo long. (for example: x[y][length(p)-2..length(p)] etc)
But then again, you don't need a new syntax theoretically. Look:
include button.e
procedure button_foo (integer x)
foo (x)
end procedure
include otherfile.e
procedure otherfile_foo (integer x)
foo(x)
end procedure
7. Re: Improvements
On 28 Aug 2000, at 19:57, Fam. Nieuwenhuijsen wrote:
> >It's also _very_ useful to have a more concise notation for referencing
> >multiple vars, e.g.
>
> >with button do
> > coords = {10,20}
> > size = {400,200}
> >end with
I used that *very* infrequently, even when i could, in pascal.
> Just use one of the syntaxes, not all of them. I don't like the dot nation
I do, in vars as well. It's nice to be able to clear a slew of them with
unset %weather.*
that will clear
%weather.time
%weather.place
%weather.state
%weather.city
%weather.room
%weather.nick
etc,,, just not in Eu (yet?).
> .. Euphoria programs already have a tendacy to have command lines that are
> just a bit tooo long. (for example: x[y][length(p)-2..length(p)] etc)
>
> But then again, you don't need a new syntax theoretically. Look:
>
> include button.e
>
> procedure button_foo (integer x)
> foo (x)
> end procedure
>
> include otherfile.e
>
> procedure otherfile_foo (integer x)
> foo(x)
> end procedure
Made me think,, since we can trace(x) and trace(0) , can we un-include button.e
?
include button.e
draw( stuff........ )
uninclude button.e
include otherfile.e
draw( other stuff........)
uninclude otherfile.e
Both files would be in our exe, but the interpreter or translator would have the
name in
each place linked only to the last file included. Yep, it's prolly too much of
another
hack.
Kat
8. Re: Improvements
On Mon, 28 Aug 2000, you wrote:
>
>
> Just use one of the syntaxes, not all of them. I don't like the dot nation
> .. Euphoria programs already have a tendacy to have command lines that are
> jjust a bit tooo long. (for example: x[y][length(p)-2..length(p)] etc)
>
> But then again, you don't need a new syntax theoretically. Look:
>
> include button.e
>
> procedure button_foo (integer x)
> foo (x)
> end procedure
>
> include otherfile.e
>
> procedure otherfile_foo (integer x)
> foo(x)
> end procedure
Well, although I can't really see how an underscore is either better or worse
than a period, the main problem with this approach is twofold:
1. It adds another function call on top of the function already written in the
include file. In loops, this will slow things down considerably. There's also
the extra typing. More chance for errors.
2. Eliminating the "attempt to redefine" error when you have two
globals with the same name, which would be necessary in order for the above to
work, could cause some interesting problems for people who are using existing
libraries. (No more warnings about duplicated variable or function names)
Ideally, the "dot" notation (whatever) shouldn't be required, except in cases
where there is a confirmed conflict. That would let existing code run without
changes.
Perhaps an error message is all that's needed.
"foo" is defined in button.e
"foo" is defined in other.e
when there's any question. When you get the error, add the appropriate prefix.
--
Regards,
Irv
9. Re: Improvements
I had similar problems with the namespace, thats why i created WinEdit.exe
and FiFEu.exe.
With FiFEu.exe you do a search for ALL var names, then prepend a prefix.
Example:
ThisVar
occurs in other programs and so you wish to rename it to:
FirstClass_ThisVar
and perhaps in the other program:
SecondClass_ThisVar
Use FiFEu.exe to find all occurances in the directory and then click on one
hit in the list that comes up and then click "open new".
Then you can use the file search to find other occurances and type
"FirstClass_" in the lower edit box and click "prepend" for each one.
Have fun.......
--Al
10. Re: Improvements
> > The namespace problem you can avoid like this:WHAT_button. --
>
> So, when I use an include file from Jiri, and another from Dave, I have to
> rewrite the names of globals in one or both? Not only does that
invalidate the
> "stamp", but when Jiri updates his file, I have to go in and modify the
new
> one again? I don't see how that is any solution at all.
>
> Regards,
> Irv
>
No; The author of include file must name them originally that way they don't
conflict with any others, they mustn't be common names. When i write global
routines in my include files i never name them like 'button', but
'TS_button' (my initials).
11. Re: Improvements
--On Tue, 29 Aug 2000, <tone.skoda at SIOL.NET> wrote:
>
> No; The author of include file must name them originally that way they don't
> conflict with any others, they mustn't be common names. When i write global
> routines in my include files i never name them like 'button', but
> 'TS_button' (my initials).
Well, that is sort of a band-aid approach to the problem.. With most other
languages, which may have thousands of people writing "includes", it wouldn't
be practical. Tom Smith might just write code too, you know.
This problem has of couse been faced, and solved, in most mainstream
languages. We're just waiting for Rob to come up with a Euphorish solution. If
it's like his other solutions, there's a 50/50 chance that he'll come up with
some extremely clever and innovative new way to implement this.
Irv
Regards,
Irv
