develooper Front page | perl.perl6.language | Postings from March 2005

Re: Config Variables

Thread Previous | Thread Next
Larry Wall
March 3, 2005 11:25
Re: Config Variables
Message ID:
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 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


when we actually want the name, and


when we want the object describing the OS, which presumably contains
configuration values for that OS.  But that's a bit artificial.
Maybe $? 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

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

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.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About