1. My Lobbying
My lobbying:
I realize adding new features into a language puts a strain on
the program maintenance, but as long as your considering updating
anyway these are some ideas that really wouldn't take that much
effort since all of the data required here would be readily
available internally (except for maybe #1 below).
1. local variable definitions:
Just the way they are now except dont generate an error
when there is a global with the same name.
Locals would be handled as someone else mentioned, like:
ThisObject=_Object --access local var
ThatObject=Object --access global var
2a. External Euphoria structure passing:
passing the address of, say, a sequence to another Euphoria
program. The other program gets to operate on the same data.
2b. Ideally, publish the structure of the sequence along with that
to allow true C extensions to the language. This would allow
the greatest boost to Euphoria as programmers could no longer
complain they cant do this and they cant do that, and this is
too slow and that is too slow.
3a. if defined, if not defined:
this is wayyyy too handy to overlook.
Someone else mentioned they like this also.
3b. Alternately, at least:
include ( {thisfile.e, thatfile.e, thisotherfiletoo.e})
--wont take much to do that 
That way includes could be conditional.
to be continued......
--Al Getz
2. Re: My Lobbying
Irv,
Thanks for your input.
Have you posted YourLobbying to the list site? I'd like to
see some more of your ideas too.
>>> Irv wrote:
First of all, you can already declare a variable within a routine
with the same name as a global variable. There are no error messages.
The local is the one that gets referenced.
<<<
Yes, but local file declarations would be the goal here:
------------------------------------
in file.exw:
global atom FirstAtom
FirstAtom=1.1 --global
-------------------------------------
in file.ew:
local atom FirstAtom
FirstAtom=2.2 --local
procedure PrintAllAtoms()
atom FirstAtom
FirstAtom=3.3 -- or declared in procedure declaration
-- and passed.
--C++ style access:
printf(1,"%f\n",::FirstAtom) --prints global atom "1.1"
printf(1,"%f\n", :FirstAtom) --prints file local atom "2.2"
printf(1,"%f\n", FirstAtom) --prints proc private atom "3.3"
--Irv's style access:
printf(1,"%f\n",global FirstAtom) --prints global atom
printf(1,"%f\n",local FirstAtom) --prints file local atom
printf(1,"%f\n", FirstAtom) --prints proc private atom
end procedure
---------------------------------------
Of course almost any style access would be fine, as long
as the three types of variables can be accessed.
>>> Irv wrote:
Wouldn't help, even If we knew the structure, since we can't find it.
<<<
If Euphoria can find it, we can find it.
>>> on if defined, if not defined Irv also wrote:
But why?
<<<
if defined, if not defined:
One obvious use here is when declaring constants:
you have a program written declaring constants and some constants
generate errors because they are already declared in someone elses
program (like Win32Lib). I think a better way around this one
though is to create a single file to declare all windows constants.
Users of Win32Lib could simply declare this, or declare it in
Win32Lib. Win32Lib wrappers could be spared the task of including
constants in their works.
Any other ideas?
Thanks,
--Al
3. Re: My Lobbying
Al Getz wrote:
> I think a better way around this one
> though is to create a single file to declare all windows constants.
> Users of Win32Lib could simply declare this, or declare it in
> Win32Lib. Win32Lib wrappers could be spared the task of including
> constants in their works.
...and all those ( mostly unused ) constants wouldn't be included in a
*bound* program, as they are now. Two-pass bind... anyone ?
Wolf
4. Re: My Lobbying
On Wed, 06 Sep 2000, you wrote:
Al Getz wrote:
> irv wrote:
> Wouldn't help, even If we knew the structure, since we can't find it.
> <<<
>
> If Euphoria can find it, we can find it.
Only if you can convince Rob to add a function to return the
(momentary) address of a sequence. As well as some kind of a
lock function to prevent garbage collection and sequence copying
from taking place while you work with the structure. Otherwise, it'll
be gone by the time you're ready to write something there.
Odds of Rob doing this are less than .01%, I think.
> if defined, if not defined:
> One obvious use here is when declaring constants:
> you have a program written declaring constants and some constants
> generate errors because they are already declared in someone elses
> program (like Win32Lib)....
Yes, proper handling of namespacing is a far better solution to this
problem than "if defined" could ever be. See just about any C program
for proof of the awkwardness of that approach.
Besides, I see no way that "if defined" could help in the situation you
propose:
if defined x then -- oh,oh, x was already used in Win32lib
constant myx = 3
elsif defined myx then -- oops, myx declared in Jiri's fonts
constant anotherx = 3
elsif defined anotherx then -- oops, declared in Freds Functions
constant yetanotherx = 3
....
After all this, how does your program know to refer to yetanotherx
in place of the original x?
Do you have to change all the following code?
--
Regards,
Irv
5. Re: My Lobbying
On Wed, 06 Sep 2000, Al Getz wrote:
>
> Yes, but local file declarations would be the goal here:
>
> --C++ style access:
> printf(1,"%f\n",::FirstAtom) --prints global atom "1.1"
> printf(1,"%f\n", :FirstAtom) --prints file local atom "2.2"
> printf(1,"%f\n", FirstAtom) --prints proc private atom "3.3"
I have never seen a better example of why C++ programmers go insane
at an early age. Imagine trying to debug a 100,000 line program where
someone has accidentally hit the : twice, instead of once, and no one
can figure out why the payroll is all screwed up.
--
Regards,
Irv
6. Re: My Lobbying
irv wrote:
> > Wouldn't help, even If we knew the structure, since we
> can't find it.
> > <<<
> >
> > If Euphoria can find it, we can find it.
>
> Only if you can convince Rob to add a function to return the
> (momentary) address of a sequence. As well as some kind of a
> lock function to prevent garbage collection and sequence copying
> from taking place while you work with the structure. Otherwise, it'll
> be gone by the time you're ready to write something there.
>
> Odds of Rob doing this are less than .01%, I think.
>
I agree here, although I think that once the compiler comes out, there will
be a lot of reasons to want to do this. What do you do when you want to
pass a sequence to a DLL created in Eu? And I'm sure people will want to do
this. For example, imagine Eu scripting using David Cuny's (and someone
elses--can't remember the name) Eu emulator. Sure it's slow now, but it
should be sped up significantly by being compiled.
Right now, my solution would be to shamelessly copy Rob's method of storing
a sequence in a file that's used in EDS--see compress() and decompress() (or
maybe Gabriel's routines in bget.e?). Sure, it'll be slower than a direct
reference, but by how much? This could also be used to transfer data
between concurrent Eu processes, using OLE, or something.
Matt Lewis
7. Re: My Lobbying
----- Original Message -----
From: "irv" <irv at ELLIJAY.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Thursday, September 07, 2000 1:35 AM
Subject: Re: My Lobbying
> > if defined, if not defined:
> > One obvious use here is when declaring constants:
> > you have a program written declaring constants and some constants
> > generate errors because they are already declared in someone elses
> > program (like Win32Lib)....
>
> Yes, proper handling of namespacing is a far better solution to this
> problem than "if defined" could ever be. See just about any C program
> for proof of the awkwardness of that approach.
>
> Besides, I see no way that "if defined" could help in the situation you
> propose:
>
> if defined x then -- oh,oh, x was already used in Win32lib
> constant myx = 3
> elsif defined myx then -- oops, myx declared in Jiri's fonts
> constant anotherx = 3
> elsif defined anotherx then -- oops, declared in Freds Functions
> constant yetanotherx = 3
> ....
> After all this, how does your program know to refer to yetanotherx
> in place of the original x?
> Do you have to change all the following code?
I was thinking more along the lines of ...
if not defined True then
constant True = 1
end if
if not defined False then
constant False = 0
end if
if not defined trim then
function trim(sequence s)
.
.
.
end function
end if
etc...
As many commonly required names (constants and functions) are missing from
standard Euphoria, people have a tendency to re-invent them in the various
generic include files. But not always. The namespace resolution should be
one way of overcoming this, however it could still mean that unnecessary
items get defined. Unnecessary, because a perfectly good definition might
already exist, but because I can't be sure I define it again anyway, then
use my definition and ignore the earlier one.
---
cheers
Derek
8. Re: My Lobbying
----- Original Message -----
From: Derek Parnell <dparnell at BIGPOND.NET.AU>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Wednesday, September 06, 2000 4:11 PM
Subject: Re: My Lobbying
\
> I was thinking more along the lines of ...
>
> if not defined True then
> constant True = 1
> end if
> if not defined False then
> constant False = 0
> end if
>
> if not defined trim then
> function trim(sequence s)
> .
> .
> .
> end function
> end if
>
> etc...
I see. That is a problem I haven't run across. Generally, I just go ahead
and
use a constant or variable, and if it isn't defined somewhere, I'll get an
error the first time I try to run the program. Then I can define it as I
want,
without worrying about breaking someone else's code.
On the other hand, if I try to define TRUE, even though it has already been
defined
elsewhere, I'll get a message telling me this. That approach seems
completely
satisfactory, and reduces the possibility of introducing new and puzzling
bugs. Suppose I define TRUE='Y' somewhere, and you use it, expecting
it to be = 1?
> As many commonly required names (constants and functions) are missing from
> standard Euphoria, people have a tendency to re-invent them in the various
> generic include files. But not always. The namespace resolution should be
> one way of overcoming this, however it could still mean that unnecessary
> items get defined. Unnecessary, because a perfectly good definition might
> already exist, but because I can't be sure I define it again anyway, then
> use my definition and ignore the earlier one.
But, as things stand, you can't define something again, if it already
exists.
You'll be warned if you try, and you _cannot_ "ignore the earlier one".
If, on the other hand, it doesn't exist, then you have little choice but to
write the code, or find a library which already contains it.
So this is, as far as I can tell, a solution in search of a problem.
While it's true that there are a lot fewer required names in Euphoria than
in other languages, that is a "good thing". Quick, list all the string
conversion
functions in C. Bet you miss a few. Now, cross off your list all those that
can't
be duplicated by combining two or three Euphoria commands. Not many left,
are there?
Irv
9. Re: My Lobbying
irv wrote:
> Only if you can convince Rob to add a function to return the
> (momentary) address of a sequence. As well as some kind of a
> lock function to prevent garbage collection and sequence copying
> from taking place while you work with the structure. Otherwise, it'll
> be gone by the time you're ready to write something there.
I must be missing something here; I can't think of a single reason I'd want
access to Euphoria's raw sequences. There are already a number of routines
available that will allow conversion of Euphoria sequences to and from C
strings, numeric arrays in memory, and so on. I can't imagine that writing
these routines by hand would be more accurate, or significantly faster.
-- David Cuny
