top 5 list needed
i have an opportunity to get an email sent to the faculty of a top CS dept. my goal is to get internal support for a potential YAPC to be hosted there. so i want to present perl 6 to them in a way which will sell them on its academic and cutting edge aspects. your mission is to write some short (2-3 sentence) bullet items that highlight some major area of interest to ivory tower types. some rules: no marketspeak. write it as if you know what you are talking about! :) refer to interesting langs and what we stole from them (and made better) use academic buzzwords! some obvious topics are: grammars (better than anything since snobol :) the new OO design (stole the best from the rest and perlized it) continuations and stuff parrot (a new vm to run and bind them all) so have at it and sell perl 6 to the professors. thanx, 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: Standard library for perl6? (graphical primitives)
On Sat, Oct 15, 2005 at 08:33:26AM +0300, Markus Laire wrote: Could it be possible to create a Standard library for perl6, which would also include graphical primitives (putpixel, getpixel, getcolordepth, putimage, getimage, copyrectangle)? I'm interested in creating a perl6 binding to cairo (http://cairographics.org), but haven't gotten anywhere close to starting that project. -kolibrie
Re: use fatal err fail
On Wed, Sep 28, 2005 at 11:46:37AM -0500, Adam D. Lopresto wrote: [2] I've actually seen data lost due to this. When drive space is very limited (due to, for instance, a user quota) it's often possible to open a new file (since there's some space left), but the close fails since too much was written to it. Likewise. A certain reputable OS vendor's NFS implementation went multithreaded, with the result that close() was now where the over quota error was reported, rather than the individual writes. Said reputable OS vendor's own C compilers weren't checking close(), so they were caught out by this too. So I think that the problem is real, and is worthy of addressing. I'm not sure of the best approach, or syntax, or defaults. Nicholas Clark
Re: Translitteration and combining strings and array references
[EMAIL PROTECTED] (Eric) writes: On Fri, 14 Oct 2005 08:38:55 +0200, Peter Makholm [EMAIL PROTECTED] wrote: Yesterday I spend some hours getting pugs to understand translitterations with multiple ranges in each pair. E.g. Actually its been fixed already. Of course i think the whole thing was then broken again, i was planning on checking it out sometime tonight after someone else figures out the current $?SELF being undeclared bug. Saturday I think everything but the test suite was working in some way. It needed some changes in the syntax like explicit parens around pairs and the testsuite wasn't corrected for this. Would the prober thing be to update the tests for the syntax that is working and maybe add a extra test for the syntax as speced? I planed to look at it but found something to read instead. ;) BTW it doesn't need any hash i just needed pairs which it had for about an hour before things changed again. lol. so is development on pugs I guess, here today, gone tomorrow, back again another day. Yeah, very fun way to confuse a newbie into perl6-hacking but thanks for all you help. -- Peter Makholm |Yes, you can fight it, but in the end the ultimate [EMAIL PROTECTED] | goal of life is to have fun http://hacking.dk | -- Linus Torvalds
Re: top 5 list needed
Uri, Well, aside from what is actually *in* Perl 6 currently, there are a number of interesting side projects, which may or may not get included in the final language design. Such as: On Oct 18, 2005, at 3:40 AM, Uri Guttman wrote: the new OO design (stole the best from the rest and perlized it) The current object model prototype (not yet totally approved) is a self-bootstrapping meta-circular object model which is heavily influenced by the CLOS Meta Object Protocol and Smalltalk. It includes several features which are not found in any of your traditional OO languages, such as Roles (which are a descendent of Traits, I could site some papers here is this would help). You might also want to include Luke Palmer's current work on Attribute Grammars and the Theory model. Both of these are very Haskell-ish. I will let Luke speak about those. Yuval Kogman's recent Exceptuation proposal (the marriage of exceptions and continuations, this exceptions you can *actuallY* recover from) is very similar to the condition system of Common LISP. There has also been much work on a type inferencing system for Perl 6 (type *checking* if just old-skool, all the cool kids infer). The fact Pugs is written in Haskell (a language only a professor could love) might be a help. There is also the new Perl 6 packaging system. It will be far more complex than the Perl 5 one, since it will not only include the 3 part name (Foo-0.0.1-cpan:JRANDOM), but it will probably need to support seperate compilation units as well. This is borrowed from everywhere, but specifically we have looked at Fortress (the new scientific progamming language from Sun) and the new .NET assembly model. Thats about all I can think of now. Stevan
Re: top 5 list needed
Some other features:
1) You can write your program in any combination of programming styles
and languages, as you see fit. Thus, you can use your OO library
written in Ruby, that really fast C routine, and your Perl code, all
in one place.
2) There are a large number of operators that support list
manipulation, such as the zipper, the == and == operators, reduce,
and others I can't remember in addition to P5's map, grep, and sort.
3) Macros. Nuff said.
4) More declarative syntax. This is more of a handwavy, but the syntax
feels (to me) as if it's more declarative than before. For example,
for @x - $x { ... }
for @x - $x, $y { ... }
That reads like a math proof. For all X, do such-and-such.
Rob
Re: Re(vised): Proposal to make class method non-inheritable
Stevan Little skribis 2005-10-18 10:16 (-0400): You are probably right, but are the twigils actually special? or is it just a naming convention. dot sigils are not actually special. They are required on has-variables and forbidden on all other. Changing them to be optional is trivial, or so I hope. (I believe that sigils or twigils should not indicate scope, duration or type. The distinctin between the major variable types is useful, further distinction is not.) I don't think this is true, this is a Perl 5-ism. Perl 5 isn't a synonym for bad. Perl 5-ism can be construed as positive or negative. Please do elaborate. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Re(vised): Proposal to make class method non-inheritable
On Tue, 2005-10-18 at 10:16 -0400, Stevan Little wrote: On Oct 18, 2005, at 6:56 AM, Miroslav Silovic wrote: Uhm. I'm not sure either. :) The way I read Larry's mail, multimethods use .isa operator to detect whether $foo belongs to Foo. And for every class, Foo.isa(Foo) is true (this is exceptional behaviour of .isa). So (sidebar: it will probably use .does actually, but this an as yet unresolved detail) Consider it fairly resolved. (What? Using type as a marker of potential coercion? Yep!) -- c
Re: Translitteration and combining strings and array references
I have a suggestion/proposal/whatever.
I am just starting to get a grasp of uses for pairs and where they are
handy. Working on string.trans some showed that it would be useful to have
the function accept a list of pairs. That was working until the fix for
magical pairs went through and now the pairs in the call are treated as
named arguments. After some discussion with iblech and looking at the
Synopsis it looks like *%hash will slurp up named args into a hash and
[EMAIL PROTECTED] slurp up extra parameters. *%hash could work for trans except
it
stringifies the left (or magic quotes or whatever the term is) and looses
order. Both of those are significant to trans and possibly other uses for
lists of pairs. So I was wondering if we could have a signature that meant
to slurp up named args and put them in a list as pairs. For now I suggest
[EMAIL PROTECTED], because it has the flattening connotation already and we are
sort
of flattening a list of named args into a list of pairs.
The biggest issue I see with this is that i don't know how the key value of
named args is handled and if it is handled too soon to then be useful in a
pair.
Currently we (can|will be able to) do
string.trans( (['h','e'] = 0) );
string.trans( == ['h','e'] = 0);
Those are fine and i can live with that, but it seems that if we made the
signature of trans
method trans(Str $self: [EMAIL PROTECTED]) {};
Then we could just do plain old:
string.trans(['h','e'] = 0);
Which to me seems a lot easier to read. I would propose that it only effects
named params so that there is no concern about pairs in values and how to
handle them.
Re: Re(vised): Proposal to make class method non-inheritable
[EMAIL PROTECTED] wrote:
U... I'm not sure that allowing $. injection from the nested
blocks is a good thing. I don't think it's ambiguous, but to me it
looks weird and confusing - if a user put the variable in the nested
block like that, it's almost certain he actually meant to write
{
my $foo;
}
and the . was put there erroneously.
Gack, furthermore, I was thinking 'has' and reading/writing 'my'. Sorry. :(
But given that the variable will be accessible to all methods via
the closure mechanism, the only thing missing I think is the
ability to get at the variable via introspection.
Now, as for class methods, I suppose it is possible to just stash
then in the classes symbol table like with variables. However, do
we then loose the method call syntax?
Well, if it belongs to the module part of the class, the syntax
would be Bar::method(...), right?
Yes, but the . is the method invocation operator, the :: is package
symbol table access. I think they really mean different things.
Yes.
Now to be literal-minded, if Foo is a class...
Foo::method() would mean package(Foo)::method() (do package access, call
method. No invocant, but you can access the proper child of Foo as $*MODULE)
Foo.method() would mean Class::method(Foo:) (forward to metaclass, with
class as an invocant)
Nicely symetric, and (IMHO) completely unintuitive. So what exactly
means to say that a class is a module?
This also means that they would not (directly) be inheritable
since inheritence moves along superclass lines, and not with @ISA.
Well, namespaces should generally be inheritable.
I don't think this is true, this is a Perl 5-ism.
How else would lexical namespaces inject variables from outer block
into the inner?
I think you are confusing namespacing with scoping. The scope rules
are as such that the inner can access see the outer.
Fair enough. I was talking about implementation - this means you need
symbol table import and shadowing (with the symbols defined in the inner
scope). Same (or similar) policy could be used for class methods and
attributes.
I guess at the package level declaration that Class1 is Class2 would
just inject symbols from one module into the other? (yes, this is
kinda handwavy :/ )
I don't think this would be so, unless you explicitly asked for it.
I'm not sure I understand, why not?
Anyway, this makes me cringe on a certain level, although I'm not
sure I can put the reason into words. Strictly speaking, it's bad
only if there are cases where multimethod should behave differently
for a class and an instance. One case I can think of is
class AutoCreation { ... };
multi dwimmy_instance(class AutoCreation $obj) { $obj.new() }
multi dwimmy_instance(AutoCreation $obj) { $obj }
I think we need some ability to differentiate between the class
version of Foo and the instance version of Foo.
I think we agree here. :)
Miro
Re: top 5 list needed
On 10/18/05, Rob Kinyon [EMAIL PROTECTED] wrote:
3) Macros. Nuff said.
Not quite. Lispish macros, that is, macros that let you look at what
you're expanding.
4) More declarative syntax. This is more of a handwavy, but the syntax
feels (to me) as if it's more declarative than before. For example,
for @x - $x { ... }
for @x - $x, $y { ... }
That reads like a math proof. For all X, do such-and-such.
Uh huh. Sure it does.
(Were you referring to the fact that @x and $x are different things,
but really refer to the same thing (a collection and a particular
object in the collection)).
Luke
Re: top 5 list needed
On 10/18/05, Uri Guttman [EMAIL PROTECTED] wrote: i have an opportunity to get an email sent to the faculty of a top CS dept. my goal is to get internal support for a potential YAPC to be hosted there. so i want to present perl 6 to them in a way which will sell them on its academic and cutting edge aspects. your mission is to write some short (2-3 sentence) bullet items that highlight some major area of interest to ivory tower types. Which one? CS departments vary in what they consider cool. When I talked to the attribute grammar guy here at CU, he snickered when he found out we were writing Perl 6 in Haskell, dismissing Haskell as a mathematical exercise. It would be wise to do some research and figure out what this CS department considers cool before trying to techword them. Luke
Re: Translitteration and combining strings and array references
On 10/18/05, Eric [EMAIL PROTECTED] wrote:
Currently we (can|will be able to) do
string.trans( (['h','e'] = 0) );
string.trans( == ['h','e'] = 0);
Those are fine and i can live with that, but it seems that if we made the
signature of trans
method trans(Str $self: [EMAIL PROTECTED]) {};
Then we could just do plain old:
string.trans(['h','e'] = 0);
Which to me seems a lot easier to read. I would propose that it only effects
named params so that there is no concern about pairs in values and how to
handle them.
Uh, no. Certainly not for a method. For a bare sub that has been
predeclared it may be possible. But we don't want to remagicalize
pairs after we just argued the heck out of it to make pairs *always*
be named parameters.
The way I'd do the interface is like this:
string.trans([
h e = 0,
]);
It looks nicer if you use the indirect object form:
trans string: [
h e = 0,
];
Luke
Re: Standard library for perl6? (graphical primitives)
Markus Laire wrote: I'm not completely sure if it would be worth the trouble to support only most primitive graphical commands in core, (no windows, etc..), and leave the rest to the modules (or to the programmer). To a large extent, I'd want to leave most details to modules, etc. But what would be nice (tm) would be to establish a framework within graphics libraries can the created. Sort of like DBI/DBD: A core set of capabilities ala DBI, implemented in multiple ways via drivers (DBD). The only problem is ... it's hard. But things like create window are the sort of interfaces that you would want to become defacto standards. Drawing pixels/lines is much less interesting (except as exposed by a canvas widget) The thing that makes it feasable is perhaps that most look-and-feel stuff is already externalized from specific applications. So it is reasonable to have a generic open window that just works. Perhaps the equivalent of DBI is semantically the same as the interface to web browsers (client side) -- thats probably the closest we have a broadly accepted standard.
Making Wrong Code Type Wrong
JoelOnSoftware wrote an article I recently saw linked on perlmonks: http://www.joelonsoftware.com/articles/Wrong.html The article discusses writing robust software, specifically by dealing with data separation. In my interpretation the article introduces a type system. This type system helps write robust software, but has some limitations: * Type information is checked by the programmer * Full annotations must be supplied by the programmer * Lack of annotation is hard to detect The system helps you separate data that has not been massaged for a certain piece of code, from touching that code. The only way to let that data reach the code is by using a filter that sanitizes it. Joel uses 'Request(Foo)' to mean something akin to $q-param(Foo) in CGI.pm land, and Write like 'print' (assuming an HTML output). His example shows how cross site scripting can arise, and how to use the type system to avoid this problem. The type system is implemented using coding standards: you tag variable names, much like a tagged union. In his example, the union type discusses data safety, and has two subtypes: safe and unsafe. This relates very closely to tainting, but differs in one respect - it's a static analysis. Tainting does the same thing with no user annotation, at runtime, under very specific situation. Perl 6 will need support for this kind of tainting, and I raised it before, but now I would like to propose something else. Let's look at Joel's code for a second: us = UsRequest(name) usName = us recordset(usName) = usName sName = SFromUs(recordset(usName)) WriteS sName At the top, the 'us' annotations denote that Request will return an unsafe value, and 'us' is an unsafe value. Then 'usName' is assigned to it (in a far away piece of code, btw). The programmer knows that 'usName' cannot be named 'sName' because it's getting it's value from a variable that is also tagged with 'us'. Later, the value is stored in a DB. When extracted from the DB, we know the value is unsafe, because it is tagged as such. Then SFromUS is like a complex casting operator, that makes something unsafe into something safe. The naming convention is supposed to help the programmer *see* when things go wrong. In Perl 6 ideally this would look like this, IMHO: my $str = $q.param(name); ... my $name = $str; $storage.store(name, $name); ... my $name = $storage.get(name); print encode($name); because type annotation sucks. Superficially, this code does not have the property that both Joel and I want it to have - safety, but I think this can be resolved. Perl 6 has the notion of roles. Let's say we were to decorate the param method of the http request object, asking for a symbolic role to be attached to all the values it returns. What we want to get out of it is that in the scope of our code (the lexical scope, the current class and it's subclasses, the consumers of this module, etc etc), any retrieval of a param will tag the data as unsafe, without param even knowing about this. Then the view is also tagged - no data may enter the Template namespace with this tag, or even more analy, for the scope that we use Template, the only data we allow ourselves to put into it, is something that is explicitly tagged as safe. The implementation of this system is trivial with Perl 6's tools: roles and compile time type inferrence allow the user to make a system that gives the exact same features as Joel's system does by wrapping interfaces. However, what I'm more interested in is decorating existing interfaces, in a limited scope. The reason we want a limiting scope is that it is not our concern how other pieces of code use $q.param safely or unsafely, with our definition of safety or with someone else's definition of it. What I'd like to be able to do is declare something that applies to all code in my system (application, module, script, whatever) that does this: my $str = $q.param(name); ... my $name = $str; $storage.store(name, $name); ... my $name = $storage.get(name); print encode($name); and enables me to say that print $name; is disallowed using the following rules: everything from $q.param is also of the type Unsafe everything going into $storage.store needs to get a callback triggered if it us unsafe (and more data about it will be stored in the DB). everything coming out of $storage.get must also trigger a callback, that will retag it as necessary. everything going into print must be of the type Safe the function encode has the type Unsafe - Safe Using these 5 rules I can then gain control over much larger bits of code. The only question left unanswered is how do I say what code, and what is the syntax for these decorations. This tagging gets very interesting with
Re: Translitteration and combining strings and array references
On 10/18/05, Luke Palmer [EMAIL PROTECTED] wrote: Uh, no. Certainly not for a method. For a bare sub that has been predeclared it may be possible. But we don't want to remagicalize pairs after we just argued the heck out of it to make pairs *always* be named parameters. My thought was that it wouldn't be much different than *%hash as a signature except you wouldn't loose order and the keys wouldn't me mashed. Is what I'm suggesting more magical in someway? I freely admit it might be a bad idea, I just wasn't sure why and thought i might bring it up since this seems different than the magical ness of pairs before. -- -- __ Eric Hodges
Re: top 5 list needed
On Oct 18, 2005, at 1:45 PM, Luke Palmer wrote: On 10/18/05, Rob Kinyon [EMAIL PROTECTED] wrote: 3) Macros. Nuff said. Not quite. Lispish macros, that is, macros that let you look at what you're expanding. To further expand on this, they will be AST-manipulating macros (LISP style) rather than text-replacing macros (C style). Stevan
Re: Making Wrong Code Type Wrong
Yuval Kogman skribis 2005-10-18 20:38 (+0200): the function encode has the type Unsafe - Safe I read the article before. What occurred to me then did so again now. What exactly do Unsafe and Safe mean? Safe for *what*? Something that is safe to put in HTML may be unsafe to put in an rfc822 header, and what may be safe there is likely to be unsafe in a shell command line. Instead of Safe and Unsafe, I suggest using safe::html, safe::rfc822, safe::bash, etcetera instead of Safe, and nothing instead of Unsafe. If it's not safe::($usage), then it's unsafe. Just like how something that isn't defined() is undef, without there being any need for an undefined() test. One problem still is that once something is encoded, quoted or escaped it can't always be easily re-encoded. Encoding functions should therefor check if a variable does safe::(none()) and warn or fail if so. I used lc class names, because they're empty roles, used only for decoration and does-testing, and has no methods. I've thought about suggesting such a convention, and this, I guess, is as good a time as any. Another possibility is to use Str types, and coercion for encoding. In that case I suggest the lit operator that provides Str::Literal contextcoercion, which coerces to any other string type without encoding. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Making Wrong Code Type Wrong
On Tue, Oct 18, 2005 at 21:04:02 +0200, Juerd wrote: Yuval Kogman skribis 2005-10-18 20:38 (+0200): the function encode has the type Unsafe - Safe I read the article before. What occurred to me then did so again now. What exactly do Unsafe and Safe mean? Safe for *what*? That was just a naive example - the words Unsafe and Safe are user defined, and are chosen on a case by case basis in their app. One problem still is that once something is encoded, quoted or escaped it can't always be easily re-encoded. Encoding functions should therefor check if a variable does safe::(none()) and warn or fail if so. I don't see how this relates to the OP, or why encoding functions should implement it like this. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me sneaks up from another MIME part: neeyah! pgpt9EIUEZ61e.pgp Description: PGP signature
Re: Making Wrong Code Type Wrong
Yuval Kogman skribis 2005-10-18 21:22 (+0200): I read the article before. What occurred to me then did so again now. What exactly do Unsafe and Safe mean? Safe for *what*? That was just a naive example - the words Unsafe and Safe are user defined, and are chosen on a case by case basis in their app. I think there's a lot to be gained by implementing something like this globally, consistently. CPAN is part of Perl, as far as I'm concerned. One problem still is that once something is encoded, quoted or escaped it can't always be easily re-encoded. Encoding functions should therefor check if a variable does safe::(none()) and warn or fail if so. I don't see how this relates to the OP, or why encoding functions should implement it like this. The should is not to be taken literally, and applies only to the described hypothetical universe. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Making Wrong Code Type Wrong
[snip] Let me rephrase to see if I understand you - you like the fact that boxed types + roles applied to those types + compile-time type checking/inference allows you to tag a piece of information (int, char, string, obj, whatever) with arbitrary metadata. Add that to the fact that you can lexically mark certain function signatures as checking against said arbitary metadata and you can provide taint-checking to an arbitrary complexity. Yeah, that's cool. :-) Rob
syntax for accessing multiple versions of a module
Sorry if I'm asking a question that I've missed in a synopsis. Perl 6 will be able to load more than one version of the same module. As I understand it, this would let you have more than one version of DBI loaded in the same interpreter, and also have DBI written by Tim Bunce and DBI written by A.U.Thor in the same interpreter. Is the syntax for accessing different versions of the same module from Perl nailed down yet? Specifically this is in reference to wondering if the multiple module trick would actually be possible in perl 5: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2005-10/msg00585.html and how to do something functionally like: my $foo = DBI(1.38)-new(); my $bar = DBI(1.40)-new(); or whatever to distinguish which you wanted to call a class method on. Nicholas Clark
Re: syntax for accessing multiple versions of a module
Nicholas Clark skribis 2005-10-18 22:41 (+0100): my $foo = DBI(1.38)-new(); my $bar = DBI(1.40)-new(); I like this syntax, and have a somewhat relevant question: can a module be aliased entirely, including all its subclasses/-roles/-.*? Something like use DBI as RealDBI; use MyDBI as DBI; Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: top 5 list needed
SL == Stevan Little [EMAIL PROTECTED] writes: SL On Oct 18, 2005, at 1:45 PM, Luke Palmer wrote: On 10/18/05, Rob Kinyon [EMAIL PROTECTED] wrote: 3) Macros. Nuff said. Not quite. Lispish macros, that is, macros that let you look at what you're expanding. SL To further expand on this, they will be AST-manipulating macros (LISP SL style) rather than text-replacing macros (C style). my impression is that both styles are supported as you can return either text or an AST (compiled code) from a macro. 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: syntax for accessing multiple versions of a module
On 10/18/05, Juerd [EMAIL PROTECTED] wrote: Nicholas Clark skribis 2005-10-18 22:41 (+0100): my $foo = DBI(1.38)-new(); my $bar = DBI(1.40)-new(); I like this syntax, and have a somewhat relevant question: can a module be aliased entirely, including all its subclasses/-roles/-.*? Something like use DBI as RealDBI; use MyDBI as DBI; Since a Package or a Module can be a scalar, there shouldn't be a reason why this isn't possible. Rob
Re: top 5 list needed
On 10/18/05, Uri Guttman [EMAIL PROTECTED] wrote: SL == Stevan Little [EMAIL PROTECTED] writes: SL On Oct 18, 2005, at 1:45 PM, Luke Palmer wrote: On 10/18/05, Rob Kinyon [EMAIL PROTECTED] wrote: 3) Macros. Nuff said. Not quite. Lispish macros, that is, macros that let you look at what you're expanding. SL To further expand on this, they will be AST-manipulating macros (LISP SL style) rather than text-replacing macros (C style). my impression is that both styles are supported as you can return either text or an AST (compiled code) from a macro. That sounds really ... inefficient. For that to work, you'd have to have seen the macro definition earlier in the parse cycle, then encounter the call to the macro (thus consuming the token), unshift the tokens of the macro into the parse queue (thus necessitating a parse queue), then reparse the whole block because of potential bracing issues. Text-substitution macros would have to be handled in an earlier pass, but the macro might be referencing items from BEGIN blocks already seen ... It's called a preprocessor in C for a reason. Rob
Re: syntax for accessing multiple versions of a module
Nicholas,
This is addressed in S11, here is a link:
http://search.cpan.org/~ingy/Perl6-Bible/lib/Perl6/Bible/S11.pod
To summarize, the syntax to load the modules is:
use Dog-1.2.1;
While the syntax to create a specific version of a module is:
my Dog-1.3.4-cpan:JRANDOM $spot .= new(woof);
I addresses the class creation syntax partially in the initial
version of the Metamodel prototype, which was built in p5. I
basically just aliased the package with the long name (%{Dog-1.3.4-
cpan:JRANDOM::} = %{Dog::}). However this does no good for loading
of modules.
I have been giving this some though though, and here is a rough
sketch of what I have come up with so far.
Any module loaded is stored into *:: (or the p5 *main::) as the
longest name given. This means that if I do this:
use Dog-1.2.1-cpan:JRANDOM;
Then I have an entry for Dog-1.2.1-cpan:JRANDOM in the symbol
table. If, further along in the compilation process, I encounter
another Dog, such as:
use Dog-0.0.2-cpan:LWALL;
Then this is added as Dog-0.0.2-cpan:LWALL into the main symbol
table. Then once the compilation process is complete, I traverse the
symbol table hierarchy collecting all the names. Any duplicate short
names (Dog) are noted for later. Once I have collected all the names,
I build all my aliases.
So if I find:
use Cat-0.0.1-cpan:JRANDOM;
only once, I build an alias for (at a minimum) Cat and Cat-0.0.1.
For my duplicates, the table would look something like this I think:
Dog = Dog-1.2.1-cpan:JRANDOM
Dog-1.2.1 = Dog-1.2.1-cpan:JRANDOM
Dog-0.0.2 = Dog-0.0.2-cpan:LWALL
We are explictly giving the preference to the later version number (I
think we discussed this at the Toronto hackathon).
Another school of thought would be that Dog alone would be
considered ambiguious and so we would just alias far enough to be
clear, like this:
Dog = Ambiguity Error!
Dog-1.2.1 = Dog-1.2.1-cpan:JRANDOM
Dog-0.0.2 = Dog-0.0.2-cpan:LWALL
Of course, this means that if I also load Dog-1.2.1-cpan:LWALL that
the table looks like this:
Dog = Ambiguity Error!
Dog-1.2.1 = Ambiguity Error!
Dog-0.0.2 = Dog-0.0.2-cpan:LWALL
And the user is now forced to add the cpan id to get Dog-1.2.1. I am
not sure how strict @Larry wants this to be.
I have been meaning to do some kind of p5 prototype of this, I can
push it up the TODO list if it would help you.
Stevan
On Oct 18, 2005, at 5:41 PM, Nicholas Clark wrote:
Sorry if I'm asking a question that I've missed in a synopsis.
Perl 6 will be able to load more than one version of the same
module.
As I understand it, this would let you have more than one version of
DBI loaded in the same interpreter, and also have DBI written by
Tim Bunce
and DBI written by A.U.Thor in the same interpreter.
Is the syntax for accessing different versions of the same module
from Perl
nailed down yet?
Specifically this is in reference to wondering if the multiple
module trick
would actually be possible in perl 5:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2005-10/
msg00585.html
and how to do something functionally like:
my $foo = DBI(1.38)-new();
my $bar = DBI(1.40)-new();
or whatever to distinguish which you wanted to call a class method on.
Nicholas Clark
