Nested modules
Luke Palmer
relationship between the module before the :: and the one after. I
think this is an important thing to keep.
However, will it be possible to, for example, do:
module Foo;
module Bar { ... }
And refer to the inner module as, say, Foo.Bar. A more interesting
concept, can one use variables as modules, like:
::($foo)::somefunc();
Or some awful thing like that?
And of course this would imply the existance of anonymous modules. Yay.
Luke
Joseph Ryan
>So, we can have :: in names, but that doesn't represent any inherent
>relationship between the module before the :: and the one after. I
>think this is an important thing to keep.
>
>However, will it be possible to, for example, do:
>
> module Foo;
>
> module Bar { ... }
>
>And refer to the inner module as, say, Foo.Bar.
>
Kinda like an inner class in Java?
> A more interesting
>concept, can one use variables as modules, like:
>
> ::($foo)::somefunc();
>
except dynamic?
(On a side note, that syntax doesn't seem right, although I can't
fathom what is...)
>Or some awful thing like that?
>
>And of course this would imply the existance of anonymous modules. Yay.
>
How... would that be useful? What would one use an anonymous
module for that they couldn't do with an anonymous class? I
thought a module was more of a compiletime distinction, while
a class was a runtime + compiletime (i.e. all encompassing)
one.
- Joe
Larry Wall
: So, we can have :: in names, but that doesn't represent any inherent
: relationship between the module before the :: and the one after. I
: think this is an important thing to keep.
:
: However, will it be possible to, for example, do:
:
: module Foo;
:
: module Bar { ... }
That just makes another global module named Bar. To get an inner
module, you'd have to use what we already use to get "packaged"
names of variables:
module Foo;
our module Bar { ... }
: And refer to the inner module as, say, Foo.Bar.
Its full name would be Foo::Bar. The other would be a Bar method
call on class Foo, presumably.
: A more interesting
: concept, can one use variables as modules, like:
:
: ::($foo)::somefunc();
:
: Or some awful thing like that?
Yes, there's going to be a ::() interpolation syntax for names.
: And of course this would imply the existance of anonymous modules. Yay.
Yes, and you left out lexical modules:
module Foo;
my module Bar { ... }
In theory I suppose you could have objects with module attributes:
class Foo {
has module .Bar { ... }
}
Just don't ask me what it means...
Larry
Damian Conway
> In theory I suppose you could have objects with module attributes:
>
> class Foo {
> has module .Bar { ... }
> }
>
> Just don't ask me what it means...
Of course, Larry's just joking there...he knows precisely what it means.
It means that every object of class Foo has its own private version of
the .Bar module which in turn has its own private namespace. So that, for
example, any reference to a package variable of that module:
method Foo::baz {
$.Bar::qux++;
}
refers to the $qux variable belonging to the .Bar module belonging to the Foo
object on which the &baz method was invoked.
This kind of behaviour is more useful for nested classes, I suspect, but
it should certainly be available for nested modules as well.
Damian
Joseph Ryan
> Larry wrote:
>
>
> This kind of behaviour is more useful for nested classes, I suspect, but
> it should certainly be available for nested modules as well.
So, what's the difference between a module and a class, and
why would you want dynamic namespaces? Isn't that something
you'd use a class for? I'm a bit confused. (-:
- Joe
Doug McNutt
But I have some problems with what I see. RFC 82 hints at my plight with this:
>The first source of discussion was around whether there is any consistent meaning to array operations. The source of this was that some felt that other people may want C<*> to mean something other than element-wise multiplication by default (e.g. matrix inner product). However no-one actually said that I<they> wanted it to work this way, only that I<others> may prefer it, particularly mathematicians.
This physicist wants it that way. In scalar context $dotproduct = @A >>*<< @B; ought to return the scalar (dot, inner) product of vectors @A and @B by which I mean the sum of the products of like components. In array context it is quite reasonable to return the element by element products but it will be for accounting rather than for electrical engineering, mapmaking, and 3D rendering.
@C = @A >>+<< @B; returning the vector sum is mathematically correct.
An intrinsic ability to figure the dot product is useful for matrix multiplication. RFC 82 offers a mathematically abhorrent example of element by element "matrix" multiplication:
> my int @mat1 = ([1,2], [3,4]);
> my int @mat2 = ([2,2], [1,1]);
> my @mat3 = @mat1 * @mat2; # ([2,4],[3,4])
Perhaps the designations "mat1, 2, 3" are not intended to be abbreviations for the word matrix but it is dangerous indeed to provide a syntax that will surely be confused with true matrix multiplication. @matC = @matA >>*<< @matB should produce elements in the result which are the dot products of the row vectors of the left matrix with the column vectors of the right. Note that one or the other of the input matrices needs to be transposed and some standardized notation is required. Matrix multiplication is not commutative.
The apocalypse at <http://dev.perl.org/perl6/apocalypse/A03.html> has this to say about confusing people.
>Anyway, in essence, I'm rejecting the underlying premise of this RFC (82), that we'll have strong enough typing to intuit the right behavior without confusing people. Nevertheless, we'll still have easy-to-use (and more importantly, easy-to-recognize) hyper-operators.
And then it goes on about other vector-like things:.
>This RFC also asks about how return values for functions like abs( ) might be specified. I expect sub declarations to (optionally) include a return type, so this would be sufficient to figure out which functions would know how to map a scalar to a scalar.
There is the norm of a vector, actually the length if we're talking about 3 dimensional geometry, which can be considered the abs(@A) as a scalar. It would be the positive square root of the sum of the squares of the components. = sqrt ( @A >>*<< @A ).
It would also be possible to include a scalar norm of a matrix which would be its determinant but that's probably fodder for a module dedicated to solution of linear equations.
The mathematical talk continues in <http://dev.perl.org/perl6/exegesis/E03.html> with:
>Substitute our vector, Victor!
And then goes on to talk about the interpretation of @array as a perl 5 scalar count of elements which might well be strings rather than numbers. I think the meaning of "vector" here really is an array of usually 3 elements in a coordinate system but it's not terribly clear. In computer science, the term has also been used for what we now call a pointer to a memory location.
An element by element concatenation of two arrays of text is certainly reasonable. As a multiplication I'm not sure what it would mean but it's a bit like the @mat1 >>*<< @mat2 in the quote above. Not very interesting or useful.
Whatever be the final result for perl 6 syntax it ought either to use the terms matrix and vector as employed by the likes of Maxwell and Heisenberg and provide mathematically correct operators or it should avoid those terms when documenting hyper-operators that do something else.
And then there are those two-component vectors which are complex numbers. . . and vector cross products. . . and quaternions. . .
I am officially retired with some time but I have yet to process my first CVS file and, though I do C, there is a long learning curve for this guy who started when FORTRAN was a pup. Is anyone interested enough to encourage me? What can I do? I run Mac-Darwin and Linux.
dmc...@macnauchtan.com
http://www.macnauchtan.com/
--
--> The best programming tool is a soldering iron <--
Luke Palmer
Doug McNutt writes:
> >The first source of discussion was around whether there is any
> >consistent meaning to array operations. The source of this was that
> >some felt that other people may want C<*> to mean something other
> >than element-wise multiplication by default (e.g. matrix inner
> >product). However no-one actually said that I<they> wanted it to work
> >this way, only that I<others> may prefer it, particularly
> >mathematicians.
>
> This physicist wants it that way. In scalar context $dotproduct = @A
> >>*<< @B; ought to return the scalar (dot, inner) product of vectors @A
> and @B by which I mean the sum of the products of like components. In
> array context it is quite reasonable to return the element by element
> products but it will be for accounting rather than for electrical
> engineering, mapmaking, and 3D rendering.
>
> @C = @A >>+<< @B; returning the vector sum is mathematically correct.
>
> An intrinsic ability to figure the dot product is useful for matrix
> multiplication.
I was sincerely pissed when PDL, the Perl language _for_ mathematicians,
was not capable of easily doing a tensor inner product. The "threading"
system was too advanced, and you needed to jump through hoops to get it
to do the simple thing.
While Perl 6 is not being designed as a language for mathematicians,
it's not being designed as a language against mathematicians. I want an
inner product.
One can generally do a dot product as such:
$prod = @a >>*<< @b ==> sum;
Where:
sub sum(*@data) { reduce { $^a + $^b } 0, @data }
But
$prod = @a >>*<< @b;
Won't get you the dot product without some kind of module. It'll get
you a reference to the array of @a[$i] multiplied by @b[$i]. And
putting a numeric context on that won't do it either; that will give you
the length of the resulting array.
PDL has a lot of liberty in Perl 6, though. They can easily go far
enough to overload piddle operations to do the Right Thing. If they so
desire (don't know whether I would be for or against this), they could
make up a whole new piddle sigil, so you could go:
@>pid = (1,2,3,4,5);
And have the scalar operations work right automatically. That might
actually be the way to go, because when I'm programming these sorts of
things, I have arrays and I have vectors, and I rarely interchange them.
And abs() really doesn't seem the place to put the norm. That feels
more like norm() to me.
> An element by element concatenation of two arrays of text is certainly
> reasonable. As a multiplication I'm not sure what it would mean but
> it's a bit like the @mat1 >>*<< @mat2 in the quote above. Not very
> interesting or useful.
>
> Whatever be the final result for perl 6 syntax it ought either to use
> the terms matrix and vector as employed by the likes of Maxwell and
> Heisenberg and provide mathematically correct operators or it should
> avoid those terms when documenting hyper-operators that do something
> else.
So, I guess it won't be concerting to you to hear that we're calling
hyper-operators vector-operators. I personally think it's not the
operators that are misleading, though. They have clear and well-defined
semantics, and when these are single-dimensional arrays, vector-operator
makes a lot of sense.
Anyway, I'm kind of losing my point. Basically, I think that the
mathematically correct stuff should be saved for other kinds of
variables or other kinds of operators. It's more important to have a
consistent and useful semantic with vector operators than it is to get
it to work mathematically in the >>*<< case.
PDL will likely be the place to go for these semantics. Considering my
vast disappointment with the current state of PDL, I'll probably be a
contributor this second time 'round.
> And then there are those two-component vectors which are complex
> numbers. . . and vector cross products. . . and quaternions. . .
All of which deserve types and their own set of semantics.
Luke
Dan Sugalski
> I am officially retired with some time but I have yet to process my
> first CVS file and, though I do C, there is a long learning curve for
> this guy who started when FORTRAN was a pup. Is anyone interested enough
> to encourage me? What can I do? I run Mac-Darwin and Linux.
Well, I'm neither a mathematician nor a physicist (and I don't even play
one on TV) but I can really use folks who are or were. If you're willing,
subscribe to the internals list (perl6-intern...@perl.org) and
we'll see what we can do with you. :)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Paul Hodges
> On Sun, Nov 02, 2003 at 07:50:05PM -0700, Luke Palmer wrote:
> : So, we can have :: in names, but that doesn't represent any inherent
> : relationship between the module before the :: and the one after.
I think we may have drifted off what I perhaps wrongly perceived to be
the salient point:
> : I think this is an important thing to keep.
When we started addressing
> : However, will it be possible to, for example, do:
> : module Foo;
> : module Bar { ... }
Larry said:
> That just makes another global module named Bar. To get an inner
> module, you'd have to use what we already use to get "packaged"
> names of variables:
>
> module Foo;
> our module Bar { ... }
>
> : And refer to the inner module as, say, Foo.Bar.
>
> Its full name would be Foo::Bar. The other would be a Bar method
> call on class Foo, presumably.
This means that Foo::Bar is now inherently a sub-space of Foo, doesn't
it? Though it also seems to imply that explicitly declaring a module
Foo::Bar is still ok. I suspect that's where I'm wrong. Can we still
declare "top-level" modules with embedded :: divisions?
Now, personally, I disagree with Luke; I *like* this structure that
says Foo::Bar is part of Foo, but he says he considers it important to
keep the current idiom that module Foo is not inherently associated
with module Foo::Bar, if I understood rightly.
So, in the interest of curiosity, why should :: *not* indicate a
sub-module?
Just because you can construct a Bar inside module Foo doesn't mean
that you shouldn't be able to write a seperate file with module
Foo::Bar (though as I said, this is probably where I'm wrong), but I
think it does point out a need for module writers to know the syntax,
and for the documenters to make it VERY CLEAR how NOT to write code
that will stomp on someone else's already loaded namespace....
Actually, I suspect the compilation will outlaw that anyway...???
Am I wandering out of the ballpark?
> : A more interesting concept, can one use variables as modules, like:
> :
> : ::($foo)::somefunc();
> :
> : Or some awful thing like that?
>
> Yes, there's going to be a ::() interpolation syntax for names.
Now that's cool. :)
But when he say "variables as modules", I assume he merely means
dynamically *specifying* modules by means of variables? I'd get
really confused otherwise.
> : And of course this would imply the existance of anonymous modules. Yay.
Can we see a quick example of that?
hmm...
my $tmp = module { sub quux { print "blather" } };
$tmp.quux; # prints "blather" ??
Wierd... cool, but looks like an object call..... My ears are smoking.
> Yes, and you left out lexical modules:
> module Foo;
> my module Bar { ... }
Lexicals I get, I think, and I'm starting to wrap my head around the
call syntax...I think....
Let's suppose:
use Foo;
use Foo::Bar;
where Foo.pm is
module Foo;
our module Bar { ... }
but Foo::Bar is in file Foo/Bar.pm as
module Foo::Bar;
Not an ideal situation, but I'm sure you could envision several ways
for the same effect to occur in much more realistic code....
I'd assume this would simply fail to load due to the conflict?
> In theory I suppose you could have objects with module attributes:
>
> class Foo {
> has module .Bar { ... }
> }
>
> Just don't ask me what it means...
>
> Larry
Proprietary subclasses? Cool!
But wouldn't that let you use the syntax Luke proposed above?
in Foo.pm
class Foo {
has module .Bar {
sub baz { 1 }
}
}
in Foo/Bar.pm
module Foo::Bar;
sub baz { 0 }
in tst.pl
use Foo;
use Foo::Bar;
print Foo::Bar.baz(); # 0?
print Foo.Bar.baz(); # 1?
$o = Foo.new();
print $o.Bar.baz(); # 1?
print Foo.new().baz(); # 1?
That utterly rocks, in my rather limited view....
but will somebody verify my syntax? :)