On Thu, Mar 03, 2005 at 09:30:03AM -0800, Brian Ingerson wrote:
: Hi all,
:
: I'm hacking on pugs. I've added a Config.hs which is generated from the
: build system's perl's Config.pm. This allows me to expose the Perl6 magical
: variable $?OS.
:
: There are a lot of other config values that seem like they don't really need
: their own global. Things like 'privlib' and 'installsitearch'.
Hmm, well, there's a sense in which the ? secondary sigil already means
they're config values known at compile time and not true globals. I think
: How about a config hash %?CONFIG for these.
:
: %?CONFIG{'privlib'}
: %?CONFIG{'installsitearch'}
:
: Or would %*CONFIG be better?
Which of those is better would depend on whether you view the values as
compile-time or run-time values. We already distinguish, for instance:
$?OS the OS we are compiling on
$*OS the OS we are running on
While those are usually the same, they don't have to be. I think we
think about this in worst-case terms: what if you're compiling your
program down to an AST in PUGS on Windows on an Intel CPU, converting
the AST to Parrot bytecode on a Sparc Solaris box, and running the
bytecode under Linux running on the Cell architecture in your new
holographic videophone? Then what exactly do we mean when we say
"the configuration"?
In fact, what I think we're dealing with are lots proxies for different
software and hardware objects. In fact, $?OS probably shouldn't return
the OS name. It should return an object describing the compiler's OS.
We were starting to make some distinctions such that the name is
$?OSNAME
$*OSNAME
when we actually want the name, and
$?OS
$*OS
when we want the object describing the OS, which presumably contains
configuration values for that OS. But that's a bit artificial.
Maybe $?OS.name or $?OS<name> should return the name of the object.
Or maybe $?OS just returns the name in string context.
Anyway, the various OSes are only one kind of object. We might
distinguish objects such as
$?CPU object describing configuration of the compiling cpu
$*CPU object describing configuration of the running cpu
$?ARCH object describing configuration of the compiling architecture
$*ARCH object describing configuration of the running architecture
In any event, I think these objects could contain (and perhaps act as)
hashes of config values, so you could get at things like
$?CPU<speed> how fast am I compiling right now?
$*CPU<speed> how fast am I running right now?
and of course more standard things like:
$*ARCH<intsize> size of int on running architecture
$*OS<privlib>
To the extent that these are passive values, it's okay to model them as
a hash. At some point we start getting more active items like
$*OS.install('Cygwin') if $*OS eq "Windows";
and then perhaps methods are a better model. Maybe methods are the right
model all the way through for consistency:
$?CPU.speed how fast am I compiling right now?
$*CPU.speed how fast am I running right now?
$*ARCH.intsize size of int on running architecture
$*OS.privlib
$*OS.upgrade;
I think that's a little harder to read than $*ARCH<intsize>, though.
Well, hey, we've said that any object can behave as a hash of its
public accessors, so it really don't matter which way they write it.
Larry
