On Thu, Dec 12, 2002 at 01:50:37PM -0800, Brent Dax wrote:
: Larry Wall:
: # Hmm. Those don't really stand out enough. Maybe we should go with
: # OBJECT:: and GLOBAL:: just for a little more visual punch.
:
: How about CORE:: instead of GLOBAL::? This helps stick with tradition
: and minimize the number of reserved packages.
I don't like the Perl 5 tradition on top-level namespaces.
First of all, nobody really knows what core means anymore. Is it
just the built-in opcodes? Is it the functions that come with the
distribution? Neither of those map onto Perl 5 concept of CORE::
anymore. So Perl 6 doesn't have a CORE:: anymore. What used to
be in CORE goes into "*", whever that means.
Second, in Perl 5 there are two global namespaces apart from CORE::.
If you say $::foo, you get $main::foo. If you say $STDIN, you
get some other namespace that has no name in Perl 5. In Perl 6,
the latter truly global namespace is combined with CORE to get what
"main" was trying to be in Perl 5. The former "main" namespace is
no longer intended to be used for globals, and the $::foo syntax is
no longer supported for that purpose. The translator will translate
$::foo to $Main::foo.
So $*IN really is considered to be in the global namespace, not
in the core namespace. You might argue that "stdin" is "core" in
some sense, but all global names go into "*", not just built-ins.
This includes all user-defined package names. So the real name of
package Foo is GLOBAL::Foo. It's not Main::Foo, nor is it CORE::Foo.
It's short name isn't ::Foo, but *Foo. And you can just call it Foo
because the search for identifiers ends in GLOBAL (except for methods,
for which the search ends in OBJECT).
: # : And what will:
: # :
: # : main.*can('foo')
: # :
: # : result in?
: #
: # These days it's "Main", not "main". And it's a module, not a
: # class, so probably it fails, unless someone can think of
: # something useful for it to mean.
:
: I'd hope that Perl would allow me to do something like that to see if
: Main::foo exists...
Ordinarily you'd test for subs with one of
exists &Main::foo
&Main::foo.exists
As to whether .can should work for that, it should depend on whether
it's possible to invoke "foo" as a method in Main. This may or may
not be the same thing as having a "sub" declaration named "foo".
Certainly classes will distinguish subs from methods. It may be
that modules will too, and you'd have to write "package Main" to
get Perl to confuse them like Perl 5 does. But that's not decided yet.
It's not clear what .can should return for a multimethod, either.
You'd have be able to return results like: "yes int can mult, but
only if the second argument is an int or num". Basically, .can
has a bad syntax. We need a modifier on an ordinary multimethod
or subroutine call that says, "Go through all the motions of calling
this, but don't really." To do that kind of almost-dispatch you often
need the actual arguments, or something resembling them. One is tempted
to say that taking a reference to a function call with arguments
does something like this:
\&Main::foo(1,3)
The reference could be bound to the dispatch list, or be false if nothing
matched.
Except that syntax currently means something else, and doesn't work
for method calls. Maybe it's a good place for a question mark:
&Main::foo?(1,3)
$foo.bar?(3)
and maybe even
$x +? $y
It's vaguely possible this should be unified with currying if the
construct actually returns a reference with prebound arguments.
It's also possible that it's not visible enough, and we should say
splashy like:
can { &Main::foo(1,3) }
can { $foo.bar(3) }
can { $a + $y }
Exactly how much can-{} should do without doing anything is left as
an exercise for the reader. What would it do with this:
can { $a + $y + snort() }
I suppose one could set up a transactional structure in which "can"
actually does the side effects hypothetically, with the option of
committing later. Sort of what a "try" block would like to be when
it grows up...
Larry
