Re: Different results with eval and compileToFiles()

[Per Bothner <per at bothner dot com>]

More later (I need to rush off), but ...

"Bradley M. Kuhn" <bkuhn@ebb.org> writes:

> I would like to set things up so that there is a class for each Perl package
> (compiled to ModuleExp), and each class has static variables (using
> Declaration fields in the ModuleExp) for all these "global" variables.

Hm.  My guess is that it might be better to use Bindings.  That is
each Perl "package" would be its own Environment, and for each
identifier in that package (a typeglob?) you have a Binding instance.
This does mean you have be able to associate separate scalar, array,
and hash values with a given Binding, but Kawa already does something
similar with Common Lisp (to handle separate function and value bindings).

Then when you compile a module, you create a static field - but the
sttaic field points to a Binding that contains the value, not the
value itself.

Using a Binding does cost some extra overhead for simple cases,
but it is more flexible.  You can implemented references, ties,
and aliases more easily and fairly efficiently.  You are also not
hardwired to module==package, and you can dynamically add new
entries to a package.

To see how this works, try a tried Scheme program:

        (module-static #t)
        (define x 10)

(The module-static is to force use of static fields.)

Unfortuantely, this part of Kawa (unalding modules and module-level
bidnings) is not as it should be.  I spent some time today on this,
and I will hopefully improve things very soon.  You might want to
not worry too much about packages and modules for now.

One other suggestion:  So you really need the Scalar class?
Why not use String and Number classes directly?  (You can use the
classes in gnu.math, if you wish, or plain old Number sub-classes
in java.lang.)
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/