Re: Packages
Matt Lewis wrote:
>
> Derek Parnell wrote:
> >
> > I believe Chris has an exagerated sense of this issue too. It is not a
> > problem
> > in the sense that people are tripping up on it all the time and are thus
> > being
> > frustrated by the language design.
> >
> > This strikes me as a concept that Chris would like to see implemented
> > because
> > its a neat one. And I agree with that. The concept of "packages" for
> > Euphoria
> > is a nice one, but the lack of it is not, as we speak, causing any general
> > angst.
> >
> > I think that if I were to advocate such a concept, I'd do only two things:
> > (1) Create a new keyword that defines the scope of an identifier as being
> > limited
> > to the package. This would work like 'global' but things outside the package
> > could not access the identifier.
> > eg.
> > sequence mVersion = "1.0" -- seen only in containing file
> > package integer vNextID -- seen only in containing package
> > global constant Foo = "FOO" -- seen only in containing application
>
> This seems sane to me.
>
> > (2) Define the term package as meaning "all the files in the same
> > directory".
> >
> > Thus statements in C:\foo\abc.e can access 'package' items in c:\foo\def.e
> > but
> > statements in C:\bar\qwerty.e cannot see those 'package' items.
>
> I like this less. Along with CChris' reservations, I think that this
> would complicate the distribution process. This system reminds me of
> java (not the same, obviously, but some real parallels). Libraries
> that used the package functionality would have to be kept in their
> directory structure when distributed [as source] with applications.
>
> It's not necessarily a bad thing, but I believe that it's different than
> how most people currently use libraries. Easier might be to use some kind
> of a "with package xyz" sort of statement. Package names would have to
> be treated like normal symbol names for resolution purposes, or we end
> up in the same mess all over again.
>
All of the questions below are answered to in the paper. Details follow.
> To demonstrate this, suppose that both two math libraries used the same
> package:
> }}}
<eucode>
> with package math
> </eucode>
{{{
> Clearly, neither wants to see the other's packaged symbols. Also, the app
> using these libs might want to see the packaged symbols of one, but not
> the other:
> }}}
<eucode>
> -- derek_math.e
> with package math
>
> -- matt_math.e
> with package math
>
> -- my_app.ex
> include derek_math.e as dmath
> include matt_math.e as mmath
> with package dmath:math
> </eucode>
{{{
> The "with package" may not be correct, since it's probably important to
> declare whether you're extending the package or just using it. Or maybe
> not.
>
package identifiers are exported symbols, hence cannot be redefined as packages
- they are not considered as variable/routine identifiers in my implementation -.
So, the second "with package math" will cause an error. I didn't consider a
mechanism to resolve such conflicts, but at least they are detected.
In my understanding, packaging is a very specific binding to a library, so that
package names are recommended to be very likely unique.
This point is probably not explicit enough in the paper, I'll clarify it tonight
(3pm here - cannot upload from office).
> Also, what if you use multiple "with package" statements?
The various directives are pushed onto a stack, and the last issued one is the
active one. On reaching the end of a source file, all directives issued in the
file are popped off the stack. Popping the previous directive is allowed, using
"with previous_package". Popping a directive not defined in the current file
causes an error.
The paper explicitly states why a file may need two or more directives, a "with
package xxx" one and a "without package" one when the exported symbols start
being defined. This is a constraint resulting from define_before_use stringent
Euphoria policy. Properly flagging the identifiers as "internal" or "exported",
instead of the fuzzy "global", removes this need for sectioning.
> Can
> code be part of multiple packages?
>
No. Every symbol belongs to a single package, the one specified by the directive
that was in force when it was defined. If no directive was ever issued in the
base file of the symbol, then:
* If the definition file is included, and if a directive was in effect at the
time of inclusion, then this directive is active - it is on top of the stack;
* Otherwise, the symbol belongs to the unnamed package. If the active directive
was "without package", the effect would be the same.
This is why it is recommended that files which don't include any other file, or
don't use intrapackage globals, be added a "without package" directive at the
beginning, so that their behaviour is not affected by the including file, and
remains as intended.
One can achieve the same result using a wrapper include file, as demonstrated in
the paper. This eliminates any code modification altogether.
A symbol may be moved from a context to another using the restrict directive.
This is a supposedly uncommon thing to do. I say "context", because it may be a
file name, namespece or package identifier indifferently.
> What if a symbol is declared as package, but there's no "with package"
> directive?
>
Since there is no package directive, the symbol belongs to the unnamed package.
Since the unnamed package has no concept of packaged symbol, the "package"
modifier (which I call "internal") has no effect.
> Are only things surrounded by with/without package included in the package?
As mentioned before, everything belongs to a package. Either an explicit
directive is in force, and the symbol belongs to the corresponding named package
or to the unnamed package, or not, and the symbol belongs to the unnamed package.
By the way, if it is preferred to write "with package _none" rather than
"without package", this is not an issue at all. Thought the latter was more
intuitive.
>
> No doubt there are more questions that need to be answered.
>
> Matt
Perhaps yet another answer: since the system is meant to make binding an
identifier to a variable a less error-prone process, and since it only deals with
this issue, only the front end needs to be modified. Translated/bound code is
unaffected, as well as any generated IL - I should add this IL bit to the paper
as well.
HTH
CChris
|
Not Categorized, Please Help
|
|
