Re: More Namespace
Lucius L. Hilley III wrote:
> Maybe, we could use local.
>
>You have include file.e naturally makes it global.
>however we could confine it with local.
>
>include file.e
>
>local include file.e
>
>With local the globals are only available to the program
>that included it.
This is a explicit way of accomplishing what Ralf was trying to do
implicityly and it allows more control.
>
>> Poster: David Cuny <dcuny at LANSET.COM>
>> Subject: Re: More Namespace
>>
--------------------------------------------------------------------------
>-----
>>
>> I agree that there should be a namespace modifier. I was thinking of
>> something like 'friend' or 'module'.
>>
>> Here's one use of 'friend': you have a library that's a single file, and
>> you'd like to break it up into parts. Writing:
>>
>> include friend <module name>
>>
>> tells Euphoria that the routines are shared, but are not global.
>>
>> Here's another example: Let's say that I wanted to use Neil in my
library.
>I
>> could write:
>>
>> include friend neil.e
>>
>> And Neil would be visible to my library, but not to the routines that are
>> using my library. If I wanted the Neil routines to be global, I would
>write:
>>
>> include global neil.e
>>
>> and all the routines declared as global in Neil would really be global.
>>
>> Under this kind of setup, the keyword 'global' should really be replaced
>> with 'export' - it defines the interface to the library routines, but
it's
>> up to the include routine to decide if the routines are global or local
to
>> the module.
>>
>> -- David Cuny
>>
I really like your idea of exporting visibility of items. External calls and
variables will vastly expand the power of the language.
This leads to a lot of possibly difficult to interpret situations, such as
when you include neil.e "locally" or as "friend", and I, including your
library, then include neil.e directly. Many times, when somebody uses a
well-known, stable library, only the interface is really known to them, not
the code or it's includes and that is what leverage is all about...they
should be able to do that transparently. Some form of instancing would
almost have to happen here to prevent logical dead ends. The more I listen
to this, the more that I see a need to examine how and when the interpreter
is called and how modularity is to be defined in this interpretive
environment.
Some of these issues are over 30 years old and have not gone away, only
changed context. In the IBM mainframe world, we had many battles over
reentrant, reusable, and serially reusable code. I am trying to straighten
out in my mind how these apply to interpretive code. Mr. Craig, if you are
listening, I would really like to see somewhere a design discussion of
Euphoria...whether it is truly interpretive, compile and go, or
incrementally compiled and what you think that those terms mean, if
anything, relative to Euphoria. Also, a flow of the language processing
would be really helpful in trying to suggest reasonable modularity ideas.
Sometimes, a block diagram of the language flow really makes these issues
come into clarity.
IMHO, the only thing that matters is that we find a simple, reasonably
transparent(to current methods and programs) way of sharing code and
procedures(note that those are two different issues) and data structures.
Data structures that are to be reused should only have to be defined once.
Modifiers to an include of a data structure should allow it to be reused
multiply in the same program without recoding(those prefixes again).
Programs with already encapsulated function(objects raising their ugly heads
again) should be accessible from other programs in addition to internal
includes and procedure and function calls. The nature of an interpreter or
similar language processor may and can allow a single copy of code to serve
all the purposes that are necessary. The purpose of instantiation of code
and variables, or of the reuse of code and variables can be effected by
varying the manner in which they are called or interpreted.
More things like routine-id() should not enter the language. They are
disruptive and break down consistency in programs. The interpretive
language, Rexx solved this problem long ago, by recursively interpreting
lines of code until all variables were resolved. This allowed dynamic code
and an equivalence of code and data almost as powerful as LISP. It should
include variables in place of routine names. If we can gain some
programmatic or rule based control over the function of the interpreter
itself, Euphoria will gain an enormous amount of power and scope without
damage to the simplicity of the language itself. That simplicity and
naturalness along with the genius stroke of the data types and typing are
what make Euphoria really attractive to start with. Granted, these things
may do major violence to the internal structure of the interpreter itself,
but should not affect the usability of the language or it's external
representation to any great degree.
Everett L.(Rett) Williams
rett at gvtc.com
|
Not Categorized, Please Help
|
|
