Re: execution platform object? gestalt?
On Wed, Jul 27, 2005 at 08:59:53 -0700, Larry Wall wrote:
So in this particular case it might be better to just say
if exists get_javascript_class {...}
Eeep... That reminds me of how you check between versions of perl.
I think I want something else:
$?RUNTIME
this is a common interface to an object that does all this.
It's lexical because the same bit of code might run on a hybrid
platform if we're getting carried away.
It let's you ask mostly about roles:
if ($?RUNTIME ~~ /IsDomishBrowser/){
# the browser runtime has the window class in the dom, we
# can get it, and it doesn't matter if we're running on
# javascript or parrot embedded in mozilla
}
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me groks YAML like the grasshopper: neeyah!!
pgptwCHvfWSVG.pgp
Description: PGP signature
execution platform object? gestalt?
With the recent realization of the beginnings of a PIL-Javascript
emitter, it appears that my Perl6 program can run in a bizarre mix of
execution environments.
Forgive me if I missed this while trying to skim through the unearthly
number of perl6 messages so far, but...
It'd be nice if there was one central object that represented the
execution platform, with various methods based on the capabilities.
For example, this object, call it $*OS, could be queried to see
if we can get a native Javascript class (true only when running on
a JSplatform):
if $*OS.can(get_javascript_class) { # I'm running on a js platform
my $main_window = $*OS.get_javascript_class(Window).main;
...
}
The point would be to have one object that would understand the
platform dependent parts, and have a consistent naming for the methods
that are used by that object as the execution platform varies.
This is similar to the OS-9's gestalt tables, which got smarter as
the operating system had more features, but was a consistent way to
ask do we have a color monitor here?.
Is something like this already planned?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: execution platform object? gestalt?
Randal L. Schwartz wrote:
This is similar to the OS-9's gestalt tables, which got smarter as
the operating system had more features, but was a consistent way to
ask do we have a color monitor here?.
Is something like this already planned?
From my bubble in the Perl6 Universe this thing is an unbound
symbolic reference $::(to The Type System).
Welche Gestalt es bisher angenommen hat weiss ich nicht.
But it should be capable to appear in any(@form) to help
all(@us) where {any(@us) != ::United::States of America}. :)
--
$TSa.greeting := HaloO; # mind the echo!
Re: execution platform object? gestalt?
On Wed, Jul 27, 2005 at 07:09:41AM -0700, Randal L. Schwartz wrote:
: With the recent realization of the beginnings of a PIL-Javascript
: emitter, it appears that my Perl6 program can run in a bizarre mix of
: execution environments.
:
: Forgive me if I missed this while trying to skim through the unearthly
: number of perl6 messages so far, but...
:
: It'd be nice if there was one central object that represented the
: execution platform, with various methods based on the capabilities.
Yes, we'll have something like that, but...
: For example, this object, call it $*OS, could be queried to see
: if we can get a native Javascript class (true only when running on
: a JSplatform):
:
: if $*OS.can(get_javascript_class) { # I'm running on a js platform
: my $main_window = $*OS.get_javascript_class(Window).main;
: ...
: }
:
: The point would be to have one object that would understand the
: platform dependent parts, and have a consistent naming for the methods
: that are used by that object as the execution platform varies.
It's not entirely clear that get_javascript_class should be considered
a method of the OS and/or platform for which .can would be appropriate.
The method might be supplied by the platform, or it might be supplied
merely because someone somewhere said use JS and imported the behavior.
So in this particular case it might be better to just say
if exists get_javascript_class {...}
or maybe (if it's actually the time to get the class) just try
calling the routine and catch the exception, unless you're trying
to second-guess ahead of time. Or ask the language loader object
whether it has loaded JS. I'm just saying that the language loader
doesn't necessarily have to be considered part of the OS.
But that aside, yes, we'll have visiblility into $?OS (the compile-time
OS) and $*OS (the run-time OS). Or maybe those are just the names,
and hashes like %?OSfeature and %*OSfeature are the appropriate forms
for interrogating particular items. But $*OS as an object can subsume
both of those behaviors and also provide methods, so that's probably
the right way to go.
On the other hand, it's also not entirely clear that all platformish
feature sets should make themselves visible through one name. What's
an OS? Should we distinguish VM from that? Should we be able
to peer through VM and OS and get at MACHINE? What if it's running on
multiple machines and they want to give conflicting advice?
Arguably, it's probably good to have a single access point for
everything outside the VM, and OS is as good a name as anything for
that, as the abstraction of the world. (Hmm, if your program is
the flesh, that leaves the VM to be the devil, I guess.) However,
if we do that, then it would have to be recognized that the entire
Internet is hiding inside that OS bubble.
So I guess the question is whether we need $?VM and $*VM as well? Or
should we consider the VM to also be foreign and lump it with OS?
: This is similar to the OS-9's gestalt tables, which got smarter as
: the operating system had more features, but was a consistent way to
: ask do we have a color monitor here?.
:
: Is something like this already planned?
Yes, but we just need to be careful not to recreate The Registry.
We're looking more for a place for everything and everything in
its place, but we're still trying to understand what that means.
As you say, whatever we end up with does have to be extensible,
since we don't know all the places we'll want ten years from now.
It seems to me that the more places we can come up with now, though,
the less likely we are to have collisions later, unless our categories
are artificial. That tends to argue for separating out VM from OS,
and maybe COMPUTER, and NET, unless you think that NET =:= COMPUTER.
Larry
Re: execution platform object? gestalt?
LW == Larry Wall [EMAIL PROTECTED] writes: LW Yes, but we just need to be careful not to recreate The Registry. LW We're looking more for a place for everything and everything in LW its place, but we're still trying to understand what that means. LW As you say, whatever we end up with does have to be extensible, LW since we don't know all the places we'll want ten years from now. LW It seems to me that the more places we can come up with now, though, LW the less likely we are to have collisions later, unless our categories LW are artificial. That tends to argue for separating out VM from OS, LW and maybe COMPUTER, and NET, unless you think that NET =:= COMPUTER. then why not name it something like *?ENV (not to be confused with the shell/exec env which is still %ENV i assume)? then under that there are methods/hash entries like OS, VM, etc. it is the sum of all the (reasonably) known external things about this perl. OS seems too specific as does VM. they should just be subparts of the full env. this is also more like an intelligent Config.pm it seems. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: execution platform object? gestalt?
On Wed, Jul 27, 2005 at 04:27:15PM -0400, Uri Guttman wrote: : then why not name it something like *?ENV (not to be confused with the : shell/exec env which is still %ENV i assume)? Of course, the fact that you have to say not to be confused with can be taken as indicating that people will in fact confuse them... Larry
Re: execution platform object? gestalt?
LW == Larry Wall [EMAIL PROTECTED] writes: LW On Wed, Jul 27, 2005 at 04:27:15PM -0400, Uri Guttman wrote: LW : then why not name it something like *?ENV (not to be confused with the LW : shell/exec env which is still %ENV i assume)? LW Of course, the fact that you have to say not to be confused with LW can be taken as indicating that people will in fact confuse them... you could do it even worse by making the shell env be a method/entry of the perl env (bad syntax ahead): *?ENV.ENVPATH but my original point stands in that all this is should be under one builtin and it shouldn't be OS or VM. those should be parts of it and maybe shell env should be part of it too. this thingy should encompass all about this perl and the world it is in and the shell env is part of that. so other choices are the common and lame INFO and CONF. too bad ENV was taken already. i wish we could invent new words. :) bad idea: call it *?WALL cause everything is hanging on the wall. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: execution platform object? gestalt?
On Jul 27, 2005, at 6:18 PM, Uri Guttman wrote:
this thingy should encompass
all about this perl and the world it is in and the shell env is
part of
that.
How about *?PERL ?
if ( *?PERL.COMPILED_OS eq 'Unix') {...}
if ( *?PERL.CURRENT_OS eq 'Unix') {...}
*?PERL.Grammars{Regex} = $my_bizarre_new_regex_grammar;
etc.
--Dks
