Re: Namespace solution?
On Monday 25 June 2001 13:42, Everett L.(Rett) Williams sent this to
me, and I thought I would forward it here for discussion...
...
> I don't believe in using "globals". There is always a higher level, and
> things should be declared where they are used when possible. Any variable
> should be relatively global to anything below it in the scope tree and
> yield or mask as the case may be to things above it.
What you say is true, and were there any other way of breaking our
source code into modules while still allowing them to share variables
(routines...etc) then I would be for that.
Names declared inside a routine now override any with the same
name declared in the main body of the code.
There's no warning, it just does, and that seems to
cause few people any grief.
If we were to extend those characteristics so that names declared in
the body of the code (outside a named routine) would take precedence
over any declared externally (in other include files) should we expect
that to cause more problems?
Probably. This should at least justify a warning, so you have the opportunity
to change that name in your code - not in the include, which might well
be impossible.
[I wrote]
> > Unfortunately, when you declare a global variable (X, for example)
> > in an include file, you are laying claim to the use of the name X for
> > variables, constants, and routine names, not only for your own program,
> > but for ALL programs which want to make use of that include file.
> > Even those written by others.
> > You are, in effect, claiming a Universal Copyright on the name X.
> >
> > The result? Name collisions. It would be relatively easy to add two or
> > three lines
> > to a widely used Euphoria include (Win32Lib comes to mind) which would
> > break 95% of the existing Euphoria programs worldwide. Most of us don't
> > really want to do that.
>
> I think that you have stated the clearest case for namespace control that I
> seen
>
> so far.
>
> > What we want to do is to be able to declare a variable
> > (constant,routine...) in ONE place that is visible to all the files in
> > OUR program, without affecting
> > other programmer's efforts. More of a cooperative "export - import"
> > scheme, as opposed the "pre-emptive strike" plan we have now.
> >
> > Here are some possibilities: I think, by far, #3 is the best....
> >
> > 1. Deprecate the 'global' keyword, and introduce the new keywords:
> > export and import..
> > example:
> > export x,y -- in file a
> > export x,y -- in file.b
> >
> > -- your program
> > import x from file.a
> > import y from file.b
<snip>
>
> This is truly interesting. I've seen it used directly in assembler programs
> and indirectly in other languages and then realized in the linker. The real
> term for these is "weak externals". I'd like to see it used in the service
> of true modularity rather than the "cheap" modularity of includes. This
> along with a dynamic load mechanism should be the means of establishing
> true modules in Euphoria and several other languages that I can think of.
>
> > 2. Expand the syntax of 'include' so that all globals may have a unique
> > prefix
> > attached by the programmer as they are included.
> > example:
> > include file.a as a
> > include file.b as b
> >
> > ? a.x -- prints the x in file.a
> > b.x = 33 -- sets x in file.b to 33
> >
> > You would still be free to declare x in your own program file, which
> > would
> > be legal and would be referred to as just plain x (x = 34)
> >
> > Possible problems: What happens if you include an existing program
> > which uses
> > the plain 'include' syntax? These "unqualified" includes would
> > prevent you from
> > using variables of the same name in your code. And you might not
> > have the
> > ability or inclination to go into those include files to add the new
> > syntax. Doing
> > so would mean you'd have a 'customized' package, with all the
> > problems that implies. What if that include file were shrouded?
>
> Actually, as has been noted by several people, if you prefix all items from
> both
>
> the include and all it's descendants, the problem is solved.
>
> > 3. Allow 'retroactive name decoration'. The interpreter is good at
> > catching name collisions. The problem is that your only option, once a
> > collision is
> > found, is to halt with an error. This doesn't necessarily have to be
> > the case.
> >
> > Consider this:
> >
> > global atom x -- declared in file.a
> >
> > --file.c
> > include file.a
> > integer x -- oops!
> >
> > ** Warning: Local integer x conflicts with global atom x in "file.a"
> > **
> >
> > So you go back in revise your code, not by changing your locally
> > declared integer x, but by 'retroactively' changing the declarations
> > as they are read in from file.a
> >
> > -- file.c
<snip>
I am unclear how this will work.
If file.a and file.b are iused by file.c, and
you then use file.c in your program, what happens when
file.a and file.b both declare the same name, say X?
(As they well may, anytime anyone changes either)
When file.c refers to X, and both file.a and file.b contain an X,
which X is meant? How is this resolved, bearing in mind that
you may not have access to the source for file.c, or you may
be loathe to change something that is supposed to be a
standard library. Win32Lib, for example?
> From your reply to Tony Bucholz:
>
> I really find Tony's shorthand to be a pain. Create more than a page of
> code that way and truly go nuts.
>
> > While your shorthand above would be a big improvement, I would really
> > like to see it implemented fully: e.g:
> >
> > with customer [ i ] do
> > NAME = "Joe Blow" -- not [NAME], just NAME
> > ADDR = "1234 Fifth St."
> > with TXN [ 4 ] do
> > ITEM = "Dog food"
> > AMT = 2.99
> > end with
> > end with
>
> Named structure elements with aliases for blocks of elements would
> certainly be a vast improvement over what we now have. Now, you need to put
> forth a suggestion for the implementation of this. This just shows the use.
> The biggest
> problem in attaching this to the current sequences is the infinite
> malleability of
> the current sequence structure. Fixed sequences would be a subset of the
> current sequence structure that would give us easy access to column
> indexing and named structures. We can still have much of the current
> flexibility if we just allow naming of declared points in the structure.
Somewhere along the line I think Rob got the impression that structures
are for fixed length variables, and for nothing else, therefore they have
no place in Euphoria. That is just not true. What we've asked for is some
reasonable way to address the bits and pieces that make up one of those
'infinitely flexible' Euphoria sequences. Naming the pieces seems the most
logical way, and if it turns out looking like a 'record' then so be it.
Right now, it looks like an array - but Euphoria doesn't have those,
either, right? Should we also not allow subscripting?
> > Which would be a welcome relief from the abominable:
> >
> > customer[i][NAME] = "Joe Blow"
> > customer[i][ADDR] = "1234 Fifth St."
> > customer[i][TXN][4][ITEM] = "Dog food"
> > customer[i][TXN][4][AMT] = 2.99
> >
> > When you have a bunch of nested fields, this kind of thing gets
> > error prone, and not only your code, but Euphoria as well, looks bad.
>
> The nested fields are the least of the problems. The use of global
> constants is the real garbage heap. It pollutes the address space while not
> really providing the structures that we want in the first place.
>
> Beyond these items, my favorite bugaboo in Euphoria is the current numeric
> behavior. I want fixed point and integer arithmetic that I can rely upon. I
> know that this would require a numeric library, but they exist and can be
> included. Then, I truly would not have to care about internal
> implementation. The current usage tells me that I should not have to pay
> attention to this, but in reality, I do. Sometimes, I have floating point,
> and sometimes my integer usage gets promoted to floating point without me
> intending it, and then never changes back, even when the calculation comes
> back into range. This is unacceptable to me for business use.
I understand this - it's one reason I somtimes dust off an old copy of BCD
Pascal. The other reason is that it produces usable programs that
are 15 - 20 k bytes in size.
> Everett L.(Rett) Williams
> rett at gvtc.com
|
Not Categorized, Please Help
|
|
