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'.

How about a config hash %?CONFIG for these.

    %?CONFIG{'privlib'}
    %?CONFIG{'installsitearch'}

Or would %*CONFIG be better?

Cheers, Brian

I guess another practical difference is that if you say

    $*OS<nonesuch>

you get an undefined value, whereas if you say

    $*OS.nonesuch

it throws an exception.  Though I suppose you could always say:

    $*OS.?nonesuch

instead to force it to undef if the method can't be found.  But that's
getting kind of cluttery, and I still like the hash notation for its
visual pill.  It lets you focus in on the parameter name and sort
of ignore where its coming from.  The important thing to the user is
the "intsize", and not the fact that it had to be looked up in some
particular architecture object.

Larry

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

At first I was overwhelmed by your reply, but it's soaking in... :)

My goal in the short term is to create an environment where regular
folks can start writing and installing and sharing Perl6 modules. It's
a lot of hacky work on various subsystems. And one thing I need is
config info.

Unfortunately, pugs has no object support yet. It probably will in the
next week or two. In the meantime I'll just wing it with an eye towards
the future.

Thanks for the mind expanding reply.

Cheers, Brian

Er, sorry.  Sometimes I get so excited about the Promised Land that I
forget we're still standing ankle deep in dying tube worms somewhere
out in the middle of the Red Sea seabed watching with interest the
approach of Pharoah's army, and trying to ignore the walls of water
stacked up on each side.

: My goal in the short term is to create an environment where regular
: folks can start writing and installing and sharing Perl6 modules. It's
: a lot of hacky work on various subsystems. And one thing I need is
: config info.

For now a hash is just fine for that, especially if all the info
is being imported from one place.  Maybe we should just lump it all
under %?OS, since that's what a lot of the values are related to at
the moment.  (To a process, everything looks likes an OS anyway.)

: Unfortunately, pugs has no object support yet. It probably will in the
: next week or two. In the meantime I'll just wing it with an eye towards
: the future.

As a kind of cheap no-brainer, maybe throw an alias like

    %*OS ::= %?OS;

in there to encourage people to start thinking about the destinction
between compile-time and run-time, even if the two hash's values are
identical for now.  They would presumably diverge when we have separate
compilation.

: Thanks for the mind expanding reply.

You're welcome.  Next time don't eat blue sugar cubes from my frig.  :-)

Larry

Sorry.

--Dks