Re: Who is @Larry?
On Thu, Aug 25, 2005 at 09:25:30PM -0400, Matt Fowles wrote: > I have a simple question. Who comprises @Larry? I am fairly sure > that I know a few people in it, but I am highly doubtful that I know > all of them. dev.perl.org has a "Who's Who" list: http://dev.perl.org/perl6/people.html The Architecture team is comprised of: < larry damian chip leo chromatic allison hugo luke nathan dan > Thanks, /Autrijus/ pgptVEZlu8p04.pgp Description: PGP signature
Re: Who is @Larry?
> "MF" == Matt Fowles <[EMAIL PROTECTED]> writes:
MF> All~
MF> I have a simple question. Who comprises @Larry? I am fairly sure
MF> that I know a few people in it, but I am highly doubtful that I know
MF> all of them.
if $you_have_to_ask ~~ @Larry {
say 'you are not in @Larry' ;
}
i think i am getting the syntax right.
also i think it should be %Larry since there is no inherent order in the
members and all of them are randomly located. but @Larry is easier to
say out loud.
:)
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
Who is @Larry?
All~ I have a simple question. Who comprises @Larry? I am fairly sure that I know a few people in it, but I am highly doubtful that I know all of them. Thanks, Matt -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -Stan Kelly-Bootle, The Devil's DP Dictionary
Re: Perl 6 code - a possible compile, link, run cycle
On 8/25/05, Yuval Kogman <[EMAIL PROTECTED]> wrote: > On Thu, Aug 25, 2005 at 11:16:56 -, David Formosa (aka ? the Platypus) > wrote: > > On Wed, 24 Aug 2005 16:13:03 +0300, Yuval Kogman <[EMAIL PROTECTED]> wrote: > > > > [...] > > > > > perl6 creates a new instance of the perl compiler (presumably an > > > object). The compiler will only compile the actual file 'foo.pl', > > > and disregard any 'require', 'use', or 'eval' statements. > > > > use has the potentional to change the way the compiler > > parses the code. So use needs to be regarded. > > Hmm... Good point. > > I don't know how this is dealt with WRT to the "every module is > compiled with it's own compiler" approach perl 6 is supposed to > have. It's pretty simple, really. If module A "use"s module B, then you go and compile B first. Then, when you get to "use B" in module A, you just call "B::import" at compile time. That is, the modules are compiled separately, but you're allowed to run things from an already compiled module while you are compiling another one. Luke
Binding of array elements
Hi,
with PIL-Run (Perl 6 to Perl 5 compiler) progressing rapidly, the topic
"binding" came up on #perl6.
"Binding is a simple symbol table manipulation, right?"
"No, consider @array[$idx] := $var or more generally
$sub(@args) := $var."
Then we wondered what should happen to array elements which are bound to
other variables if some things happen to the array. (Of course, the
same thoughts apply to hashes as well).
Consider an element @array[$idx] being bound to a variable $var, i.e.
@array[$idx] := $var;
After the binding, what happens if you do...
* @array[$idx] = $new_value;
# $var is now $new_value
* @array.delete($idx);
# $var unchanged, but assigning to $var doesn't modify @array any
# longer; similarily, changing @array[$idx] doesn't modify $var now.
* @array = ();
# $var unchanged, but assigning to $var doesn't modify @array any
# longer; similarily, changing @array[$idx] doesn't modify $var now.
* @array := @other_array;
# $var unchanged, but assigning to $var doesn't modify @array any
# longer; similarily, changing @array[$idx] doesn't modify $var now.
* sub foo (@arr) { @arr[$idx] = $new_value }
foo @array;
# $var and @array[$idx] are now $new_value
* sub bar (Array $arr) { $arr[$idx] = $new_value }
foo @array;
# $var and @array[$idx] are now $new_value
* sub grtz ([EMAIL PROTECTED] is rw) { @args[$idx] = $new_value }
grtz @array;
# $var and @array[$idx] are now $new_value
* sub baka ([EMAIL PROTECTED]) { push @args, $some_value }
baka @array;
# $var, @array[$idx] and @array unchanged
Sane?
* What happens if @array gets spliced?
More precisely, does &splice call .delete before changing an array
element? I.e. does &splice call...
@array.delete($some_index); @array[$some_index] = $some_value;
# or
@array[$some_index] = $some_value;
* What happens if the array becomes tied (or was already)?
--Ingo
--
Linux, the choice of a GNU | The computer revolution is over. The
generation on a dual AMD | computers won. -- Eduard Bloch
Athlon!|
Re: Perl 6 code - a possible compile, link, run cycle
Hi, Yuval Kogman wrote: > On Thu, Aug 25, 2005 at 15:42:28 +0200, Ingo Blechschmidt wrote: >> This section will contain all information needed: >> * User-defined operators >> * Other symbols exported by "is export" >> * Exported macros > > Okay, this raises a distinction: > > Compile time exports > Runtime exports Well, all exports happen at compile-time, but you're right, some exports (regular subs) will probably not be used before runtime. > If I compile foo.pl, which uses SomeModule, and SomeModule exports > stuff at compile time, and foo.pl's object code is saved, what > happens when SomeModule is upgraded? Right. If you upgrade your glibc to an ABI-incompatible version, things will probably break. But, as you say, we can... > try to link the runtime symbols anyway, the user expects it to > work > > try to recompile foo.pl if it's source code is available > > when compiling foo.pl, prelink SomeModule's runtime symbols into > it, to ensure that no other version of SomeModule can affect > foo.pl's emitted code. This can be a recursive or non recursive > process. --Ingo -- Linux, the choice of a GNU | Mr. Cole's Axiom: The sum of the generation on a dual AMD | intelligence on the planet is a constant; Athlon!| the population is growing.
Re: Perl 6 code - a possible compile, link, run cycle
On Thu, Aug 25, 2005 at 15:42:28 +0200, Ingo Blechschmidt wrote: > This section will contain all information needed: > * User-defined operators > * Other symbols exported by "is export" > * Exported macros Okay, this raises a distinction: Compile time exports Runtime exports Modules can affect both the compilation of code that links against them by doing compile time exports like macros, infix subs, and so forth, and change the runtime by exporting functions and what not. When code is being compiled all the submodules are compiled, and the compile time exports are read from the linkable unit by the compiler, which determines which of these to use. This is used to affect compilation. The linkable units are cached. Any amount of time passes, and then the compiled code is run, triggerring linkage, which triggers compilation of modules. Since this compilation found the cached files, they are linked, and everyone is happy. There is one problem: If I compile foo.pl, which uses SomeModule, and SomeModule exports stuff at compile time, and foo.pl's object code is saved, what happens when SomeModule is upgraded? We can no longer link against it because potentially foo.pl's compilation depends on a certain state. The solution to this is to give the user some options: try to link the runtime symbols anyway, the user expects it to work try to recompile foo.pl if it's source code is available when compiling foo.pl, prelink SomeModule's runtime symbols into it, to ensure that no other version of SomeModule can affect foo.pl's emitted code. This can be a recursive or non recursive process. -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me kicks %s on the nose: neeyah! pgpCvMECA6CmW.pgp Description: PGP signature
Re: Perl 6 code - a possible compile, link, run cycle
Hi,
Yuval Kogman wrote:
> On Thu, Aug 25, 2005 at 11:16:56 -, David Formosa (aka ? the
> Platypus) wrote:
>> On Wed, 24 Aug 2005 16:13:03 +0300, Yuval Kogman
>> <[EMAIL PROTECTED]> wrote:
>> > perl6 creates a new instance of the perl compiler (presumably an
>> > object). The compiler will only compile the actual file 'foo.pl',
>> > and disregard any 'require', 'use', or 'eval' statements.
>>
>> use has the potentional to change the way the compiler
>> parses the code. So use needs to be regarded.
>
> Hmm... Good point.
>
> I don't know how this is dealt with WRT to the "every module is
> compiled with it's own compiler" approach perl 6 is supposed to
> have.
The indermediate form of a compiled .pm has to have a section containing
information about the symbols exported by the module, similar to
today's pilGlob section Pugs gives you if you use -CPIL, -CPerl5, or
-CJSON:
$ pugs -CPerl5 -we 'sub foo {...}' | \
perl -MYAML -we 'print Dump(eval <>)'
--- !perl/PIL::Environment
pilGlob:
[...]
- !perl/PSub
pSubBody: PNil
pSubLValue: 0
pSubName: '&main::foo'
pSubParams: [...]
pSubType: SubRoutine
pilMain: !perl/PStmts
pStmt: PNoop
pStmts: PNil
This section will contain all information needed:
* User-defined operators
* Other symbols exported by "is export"
* Exported macros
Note that *none* of these things influence the compilation of other .pls
and .pms unless they're exported. I.e.:
# Foo.pm
module Foo {
sub infix:<+> ($a, $b) { 42 }
say 1 + 1; # 42
}
# Exported symbols: ::Foo
# test.pl
use Foo;
say 1 + 1; # 2
# Bar.pm
module Foo {
sub infix:<+> ($a, $b) is export(:DEFAULT) { 42 }
say 1 + 1; # 42
}
# Exported symbols: ::Foo, &infix:<+>
# test.pl
use Bar;
say 1 + 1; # 42
--Ingo
--
Linux, the choice of a GNU | We are Pentium of Borg. Division is futile.
generation on a dual AMD | You will be approximated.
Athlon!|
Re: Perl 6 code - a possible compile, link, run cycle
On Aug 25, 2005, at 7:16 AM, David Formosa (aka ? the Platypus) wrote: On Wed, 24 Aug 2005 16:13:03 +0300, Yuval Kogman <[EMAIL PROTECTED]> wrote: [...] perl6 creates a new instance of the perl compiler (presumably an object). The compiler will only compile the actual file 'foo.pl', and disregard any 'require', 'use', or 'eval' statements. use has the potentional to change the way the compiler parses the code. So use needs to be regarded. Conceptually, Yuval's mechanism could still work. It's just that, when you go back and compile the 'use' lines, they may invalidate a compilation unit you thought you were finished with. --Dks
Re: Perl 6 code - a possible compile, link, run cycle
On Thu, Aug 25, 2005 at 11:16:56 -, David Formosa (aka ? the Platypus) wrote: > On Wed, 24 Aug 2005 16:13:03 +0300, Yuval Kogman <[EMAIL PROTECTED]> wrote: > > [...] > > > perl6 creates a new instance of the perl compiler (presumably an > > object). The compiler will only compile the actual file 'foo.pl', > > and disregard any 'require', 'use', or 'eval' statements. > > use has the potentional to change the way the compiler > parses the code. So use needs to be regarded. Hmm... Good point. I don't know how this is dealt with WRT to the "every module is compiled with it's own compiler" approach perl 6 is supposed to have. Autrijus - do you have any solution? Either way, this simply implies that compilation is recursive, at least to determine whether the used module affects compilation. Perhaps the use macro could do this on it's own. I still think that "regular" linkage should be decoupled from compilation though, even if it's partially done during the compilation of a 'use' statement. -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me supports the ASCII Ribbon Campaign: neeyah!!! pgptwKRhiHhGC.pgp Description: PGP signature
Re: Perl 6 code - a possible compile, link, run cycle
On Wed, 24 Aug 2005 16:13:03 +0300, Yuval Kogman <[EMAIL PROTECTED]> wrote: [...] > perl6 creates a new instance of the perl compiler (presumably an > object). The compiler will only compile the actual file 'foo.pl', > and disregard any 'require', 'use', or 'eval' statements. use has the potentional to change the way the compiler parses the code. So use needs to be regarded. -- Please excuse my spelling as I suffer from agraphia. See http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more. Free the Memes.
Re: Demagicalizing pairs
On Thu, Aug 25, 2005 at 20:23:55 +1000, Stuart Cook wrote: > Here's a suggestion: > Within argument lists, both of them are special syntactic forms for > named arguments: > > foo(a => 'b', :c); # both named args > my $pair = :a; > foo($pair); # not a named-arg call > ...or else find new syntax to disambiguate: For disambiguation I think we should have symmetric functions: foo(pairs(a => 'b', :c)); my $pair = :a; foo(named($pair)); This can be implemented in a number of ways (NamedArg isa Pair, macros, special construct). Edge case: foo(my $x = :foo); bar($x); As I see it in this example bar is getting a pair, not a named argument. foo() on the other hand could get either a named argument since :foo was in it's parameters, or a pair, since (my $x = :foo) is an expression. If the named semantics are in the micro-lexical scope of the call to the pair constructor, foo() gets a named. If not, it gets a pair. In either condition, there should be a warning: "Possible unintended use of pair instead of named argument in :foo, call to foo() at ..." and disambiguation can fix this: foo(named(my $x = :foo)); foo(pair(my $x = :foo)); -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me groks YAML like the grasshopper: neeyah!! pgp4XME69xRIb.pgp Description: PGP signature
Re: Demagicalizing pairs
Here's a suggestion:
Outside of argument lists, both a=>'b' and :a('b') (and friends) are
equivalent, and denote an ordinary pair value.
Within argument lists, both of them are special syntactic forms for
named arguments:
foo(a => 'b', :c); # both named args
If you want to pass pair values into a sub, either use an intermediate
variable...
my $pair = :a;
foo($pair); # not a named-arg call
...or else find new syntax to disambiguate:
foo( (a => 'b') ); # ok, so maybe parens aren't such a good idea
Or just use existing language constructs:
foo( do{a=>'b'}, {:c;}() ); # both positional args
And if you explicitly want to use individual pair values as named
args, just exploit the fact that a pair can act like a one-element
hash, and splat it:
my $arg = :echo;
foo( *%$arg ); # yes, I know it's three symbols
Then the only magic rule most people need to remember is:
"Pair syntax denotes named-arg passing, but only in an arg list."
Magic can never be hidden (or happen accidentally), people can
explicitly circumvent the default behaviour, and the whole system has
very little inconsistency.
Thoughts?
Stuart
Re: Demagicalizing pairs
On 8/24/05, Damian Conway <[EMAIL PROTECTED]> wrote: > Larry wrote: > > > Plus I still think it's a really bad idea to allow intermixing of > > positionals and named. We could allow named at the beginning or end > > but still keep a constraint that all positionals must occur together > > in one zone. > > If losing the magic from =>'d pairs isn't buying us named args wherever we > like, why are we contemplating it? Well, that was one of the nice side-effects of the proposal, solving something that had been bugging me. But the main reason for this proposal was to demote Pair into a regular data type that wouldn't sneak into somebody's named argument when we weren't looking. In the Old Regime, I fear that I would never ever use Pair *except* for named arguments precisely because I need to keep far too much information in my head to use them safely. > > so we should put some thought into making it syntactically trivial, if > > not automatic like it is now. The whole point was to deautomatize it! However, here's an interesting solution: pairs are scanned for *syntactically* *on the top level* of a function call (allowing named() or however we spell it as a fallback when we want to be dynamic). However, :foo(bar) and foo => bar are equivalent again. foo $x, $y; # two positionals, regardless of what they contain foo $x, :y($y)# a positional and a named foo $x, y => $y # a positional and a named foo $x, (y => $y) # two positionals: $x and the pair y => $y foo $x, (:y($y)) # same In the fourth example, y => $y is no longer on the syntactic top level, so it is not interpreted as a named argument. > > > I hate to say it, but the named args should probably be marked > > with : instead of + in the signature. That's pretty cool. Can't say I like the secondary sigil: it's really not marking a property of the variable, but a property of the parameter list. That information should probably be kept inside the parameter list alone. Luke
