%hash1 ... %hash2
This is inspired inpart by discussions I had on #perl6.
Basically what is the behavour of the hyperop when applied to two
hashes. The concensus was that the hashes would get unrolled into
lists, and the pairs would get matched up more or less randomly.
I don't feel that this is a usefull DWIMy behavour. I think a
more usefull behavour is the following. Pairs on both sides that have
common keys should have there values oped together and a hash
should be created from these. The behavour would be something like
this (please forgive bugs).
multi sub infix_circumfix_meta_operator:{'',''} (Hash %a,Hash %b,Code $op) {
my Hash %return;
for intersection(keys %a,keys %b) - $key {
%return{$key} = $op($a{$key},$b{$key});
}
return %return;
}
Would this be sensible, usefull behavour?
--
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.
Binding slices
Following a conversation with Chip on IRC, is this my @y := @foo[0..][1]; legal?
proposal: binding with a function
Hi,
As I know, for binding, you can use the := operator, and just this:
$a := $b;
I would like to make a proposal, based on Ruby[1]:
alias $a, $b;
It's a fun:
sub newline {
\n x $_;
}
alias newlines, newline;
So you can write:
print 5.enters;
Currently, you have to write it a more uglier way:
my newlines := newline;
Anyway, char '' is really neccesary there? It should work w/o it, too, as
I think. Now - in Pugs - it doesn't.
Bye,
Andras
[1] http://www.zenspider.com/Languages/Ruby/QuickRef.html#29
Assigning Proxy objects
Hi,
sub proxy () is rw {
return new Proxy:
FETCH = { 42 },
STORE = - $new { 23 };
}
say proxy();# 42
say proxy() = 40; # 40, 23, or 42?
Currently I think the last line should output 40, consider:
sub innocent_sub ($var is copy) {
my $foo = ($var = 40);
# Do something with $foo, relying on $foo being 40.
}
{ my $x = does not matter; innocent_sub $x }
# Works
{ my $x := proxy(); innocent_sub $x }
# Would break if (proxy() = 40) would not return 40.
But I can argue that the return value of Proxy object should
be the return value of the code given by FETCH in the Proxy
object construction, too...
Opinions?
--Ingo
--
Linux, the choice of a GNU | To understand recursion, you must first
generation on a dual AMD | understand recursion.
Athlon!|
MMD vs. anonymous parameter types referencing earlier parameters
This:
multi sub is_equal(Integer $a, Integer where { $_ == $a } $b: ) { 1 }
hurts. At least as I've been given to understand it[*], is impossible
to implement, because the second parameter's type can't be precalculated
in order to prepare for MMD dispatching.
The type object describing $b cannot be pre-constructed. Its 'where'
clause is a closure that must capture the value of a passed value of
$a. The subroutine object describing the where clause closure will be
different every time, as the stack frame containing $a is different
every time (perhaps even being called recursively). Therefore, every
time $b has to be instantiated, a new type object has to be created
first to describe it.
In short, $b has no pre-calculable type. And you can't calculate the
MMD potential of a subroutine unless you know the actual types of its
MMD-participating parameters.
(This also means that the type of is_equal:(...) is impossible to
express, unless I greatly misunderstand the foo:() syntax. But
it doesn't matter what you call it if you can't call it.)
If you *really* *do* want MMD to include arbitrary boolean tests that
make Perl decide this is not the MMD you are looking for, maybe you
should introduce an internal Perl 6 exception type which would be
interpreted by MMD dispatch to mean that. Then you could emit that
exception as late as you want, after doing as many tests as you think
appropriate:
multi sub is_equal(Integer $a, Integer $b) {
$a == $b or die Perl6.MMD.Jedi_mind_trick;
1;
}
Without precalculable types, that's pretty much the best semantic you
can hope for. May as well let the sub body use it too.
PS: Of course this example also implies that each parameter's
declaration introduces a new lexical scope to its right. But that
bridge was crossed when you allowed earlier parameters to
participate in the calculation of default values for later ones.
At least it doesn't interfere with MMD.
[*] Autrijus introduced me to this construct, so unless the response
is we changed our mind ...
--
Chip Salzenberg [EMAIL PROTECTED]
Re: State of Design Documents
On 6/13/05, Patrick R. Michaud [EMAIL PROTECTED] wrote: Since it might not have been clear from my earlier post -- I've now committed the S17 framework draft into the repository. Thanks. I am now questioning using Perl6 Timeline By Apocolypse as reference material. I am rather interested in seeing the specs for pack/unpack so I went about finding where it should go: There are 2 RFCs listed for A09 for pack/unpack 142 Enhanced Pack/Unpack 247 pack/unpack C-like enhancements There is an RFC for A13 regarding distinguishing packed data 258 Distinguish packed data from printable strings The rest of the RFCs for pack/unpack fall into A29 246 pack/unpack uncontrovercial enhancements 248 enhanced groups in pack/unpack 249 Use pack/unpack for marshalling 250 hooks in pack/unpack Now S09 and S13 have already been written but do not include the details regarding pack/unpack. The patch to S29 is obvious - just add a heading for pack/unpack and hope someone fills in the blanks. The patch for S13 is more difficult since I don't believe it warrants a full heading. Probably just needs a guess as to how to expose the flag to return a bool value i.e. $string.packed, comment about the 'packed' warnings/strictures pragma, and stick it the right place. The patch to S09 has me stumped. Is there any other reference material I can use to put together solid frameworks that are closely representative to what @larry might produce? Pm Cheers, Joshua Gatcomb a.k.a. L~R
Re: Binding slices
On 6/14/05, Piers Cawley [EMAIL PROTECTED] wrote: Following a conversation with Chip on IRC, is this my @y := @foo[0..][1]; legal? Definitely not. But it sure would be nice if this: my @y := @foo[0...][1]; were. Luke
Re: MMD vs. anonymous parameter types referencing earlier parameters
Chip Salzenberg wrote:
This:
multi sub is_equal(Integer $a, Integer where { $_ == $a } $b: ) { 1 }
hurts. At least as I've been given to understand it[*], is impossible
to implement, because the second parameter's type can't be precalculated
in order to prepare for MMD dispatching.
Quite interesting that Cecil already has it. The thing is called
Predicate Dispatch and there exist efficient implementation strategies.
And it is possible to calculate a static supertype of the above,
which is is_equal:( Integer, Integer : ).
In short, $b has no pre-calculable type. And you can't calculate the
MMD potential of a subroutine unless you know the actual types of its
MMD-participating parameters.
I don't know what 'MMD potential' is.
(This also means that the type of is_equal:(...) is impossible to
express, unless I greatly misunderstand the foo:() syntax. But
it doesn't matter what you call it if you can't call it.)
The syntax might just be:
is_equal:(Integer $a, Integer where { $_ == $a } :)
The only point is that I see no way for the compiler to
optimize to anything but a dynamic dispatch. Thus a more
declarative style of predicate specification would be
helpfull.
PS: Of course this example also implies that each parameter's
declaration introduces a new lexical scope to its right.
Well the colloquial spec of your function is just 'it takes
two equal integers'. And the two element list (3,3) is a
subtype of it.
Regards,
--
TSa (Thomas Sandlaß)
new mailing list: perl6-general?
Hi, I would have some general Perl6 programming questions. Where should I ask them? It's not about language design, not about compiling/compilers and even not related to the internals. As more and more people will start hacking Perl6, I think, that it would be useful to having a list for this. In this particular case, I would like to ask about creating a langugage construct (maybe there's a desgin pattern for it, maybe not) for a web templating system can be expanded by the user. Bye, Andras
?CALLER::BLOCK vs. any hope of efficient compilation
I'd like a ruling that ?CALLER::BLOCK is not a general-purpose block promoter, but only works if the calling block already marked itself as callable, perhaps by mentioning ?BLOCK in its body. First, I like the idea that all blocks act as if they were subs WRT being callable and accepting parameters. However, the as if part of that statement is very important to a compiler. AFAICT, to achieve reasonable performance, a compiler must be able to assume that in the absence of markers or predeclaration, a given block need not be given all the accoutrements and instrumentation of a full subroutine, because nobody is going to call it _as_ a subroutine. It therefore would a Bad Thing if ?CALLER::BLOCK worked generally. If the caller _is_ a block that was already marked at compile time as requiring full sub properties then, of course, it's no problem to use the syntax ?CALLER::BLOCK to denote it. -- Chip Salzenberg [EMAIL PROTECTED]
Re: %hash1 ... %hash2
Luke Palmer wrote:
On 14 Jun 2005 06:07:10 -, David Formosa (aka ? the Platypus)
[EMAIL PROTECTED] wrote:
multi sub infix_circumfix_meta_operator:{'',''} (Hash %a,Hash %b,Code $op) {
my Hash %return;
for intersection(keys %a,keys %b) - $key {
%return{$key} = $op($a{$key},$b{$key});
}
return %return;
}
Would this be sensible, usefull behavour?
I think so.
In fact, I've implemented hash vector and hash matrix classes
which are useful for doing various linearesque things, when you don't
know how many elements your vectors will have. The difference between
the hyper hash ops and vector-vector ops in my class is the fact that
you did intersection instead of union (I assumed unset elements were
0). Unfortunately, such an assumption doesn't make sense on a general
scale, so I wonder whether I would end up using the hash hyper ops or
whether I'd just go and implement them again.
So, I'd really like to see a couple examples where this behavior could
be useful. I don't doubt that it can, but I can't think of anything
at the moment.
This is effectively the Database inner vs outer join issue. There are
times you need one and times you need the other. Example for the outer
join case: combining two invoices where you want to add together the
subtotals for each type of item and missing items on either invoice
should be assumed to be 0 quantity at 0 dollars. Note that just like in
the reduce op you need to know the identity value associated with the
op. come to think of it just like in the DB world you really need 4
different versions: inner join (intersection of keys), full outer join
(union of keys) and the left and right outer joins where you on consider
the missing keys on the left or right sides. This means that the current
hyper-op should be define to be one of inner or full and we need some
syntax to specify the other three op types. -:left Ugh!
As a sidenote this would make writing a simple in Perl 6 DB module trivial.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: MMD vs. anonymous parameter types referencing earlier parameters
On Tue, Jun 14, 2005 at 03:43:42PM +0200, TSa (Thomas Sandlaß) wrote:
Chip Salzenberg wrote:
This:
multi sub is_equal(Integer $a, Integer where { $_ == $a } $b: ) { 1 }
hurts. At least as I've been given to understand it[*], is impossible
to implement, because the second parameter's type can't be precalculated
in order to prepare for MMD dispatching.
Quite interesting that Cecil already has it. The thing is called
Predicate Dispatch and there exist efficient implementation strategies.
Link link.
In case it matters, we're trying to support the Perl 6 semantics of
both ($a:$b:) and ($a,$b:). The former looks like something that
could be implemented with something called predicate dispatch, but
the latter I'm not so sure of.
(This also means that the type of is_equal:(...) is impossible to
express, unless I greatly misunderstand the foo:() syntax. But
it doesn't matter what you call it if you can't call it.)
The syntax might just be:
is_equal:(Integer $a, Integer where { $_ == $a } :)
It's a new type object every time, so every time you run that code you
get a new type object to describe $b, and therefore the type object of
the expression will never match up with the one used in the function
definition.
Are you suggesting that type equivalence tests include introspection
into the semantics of the closure? If so, what is close enough? If
not, how can Parrot ever know that
Integer where { $_ == $a }
is the same as
Integer where { $^foo == $a }
but different from
Integer where { $_ != $a }
? Down that path lay madness.[*]
The only point is that I see no way for the compiler to optimize to
anything but a dynamic dispatch.
s/the compiler/Parrot/, since the specific multi implementation can be
introduced after the call is compiled.
[*] There is another theory which states this has already occurred.
--
Chip Salzenberg [EMAIL PROTECTED]
Re: new mailing list: perl6-general?
Hi, Just wanted to say the same. All my questions starting as How to... and Is this... are just to trivial to ask here :) OTOH as there is no global Perl5 list (AFAIK, at least), these things should go to the regional mail-lists - later on. However, at this phase of develpment of Perl6/Pugs/Parrot/Andtherest, we would just overload those who are not (yet) interested in Perl6 with a continuous fear of getting Warnocked ;) Andras++ - Fagzal Hi, I would have some general Perl6 programming questions. Where should I ask them? It's not about language design, not about compiling/compilers and even not related to the internals. As more and more people will start hacking Perl6, I think, that it would be useful to having a list for this. In this particular case, I would like to ask about creating a langugage construct (maybe there's a desgin pattern for it, maybe not) for a web templating system can be expanded by the user. Bye, Andras
Re: new mailing list: perl6-general?
On Tue, Jun 14, 2005 at 04:27:20PM +0200, Fagyal Csongor wrote: Just wanted to say the same. All my questions starting as How to... and Is this... are just to trivial to ask here :) - Fagzal I would have some general Perl6 programming questions. Where should I ask them? It's not about language design, not about compiling/compilers and even not related to the internals. Bye, Andras If you're IRC-able, then get on irc.freenode.net and join #perl6. People there are always happy to blather on about perl6 stuff that is related to pugs/perl6 development (including general perl6 programming questions). -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: new mailing list: perl6-general?
On Tue, Jun 14, 2005 at 03:54:45PM +0200, BÁRTHÁZI András wrote: I would have some general Perl6 programming questions. Where should I ask them? It's not about language design, not about compiling/compilers and even not related to the internals. As more and more people will start hacking Perl6, I think, that it would be useful to having a list for this. As you mention, general Perl6 programming questions probably don't belong on perl6-compiler, as that list is focused more on compiler implementation issues (Perl6, Pugs, PGE) than on how does the language work. So, that leaves either perl6-language or a new list. Personally I could see it going either way -- even though general Perl6 programming questions aren't directly about language design, it may still be useful to language designers to see the types of questions that people are asking and to see how well the language design can work in practice. Or maybe that's not needed. But I tend to lean away from list proliferation where possible. So, I'd suggest putting general questions about Perl 6 on perl6-language. In saying this, however, I think it's important to try to distinguish questions about Perl 6 from questions about the various implementing components such as Pugs, PGE, and any forthcoming Perl 6 compiler(s). For some time these implementations will be only approximations of the Perl 6 language design, so they're not authoritative as far as testing understanding of Perl 6. (But they are often very illustrative and educational. :-) So, questions like XYZ doesn't seem to work in Pugs or PGE probably belong on perl6-compiler. So, as a general rule of thumb, I'd say that if a question involves getting something to actually run with the available Perl 6 tools, then that question belongs on perl6-compiler. Otherwise, perl6-language (or a new list for that purpose) is the place to go. Perhaps what we need is updated descriptions of the various mailing lists on perl.org (http://dev.perl.org/perl6/lists/)? I'll draft some proposed changes to that page. Pm
Re: new mailing list: perl6-general?
Hi, So, that leaves either perl6-language or a new list. Personally I could see it going either way -- even though general Perl6 programming questions aren't directly about language design, it may still be useful to language designers to see the types of questions that people are asking and to see how well the language design can work in practice. Or maybe that's not needed. But I tend to lean away from list proliferation where possible. So, I'd suggest putting general questions about Perl 6 on perl6-language. In saying this, however, I think it's important to try to distinguish questions about Perl 6 from questions about the various implementing components such as Pugs, PGE, and any forthcoming Perl 6 compiler(s). For some time these implementations will be only approximations of the Perl 6 language design, so they're not authoritative as far as testing understanding of Perl 6. (But they are often very illustrative and educational. :-) So, questions like XYZ doesn't seem to work in Pugs or PGE probably belong on perl6-compiler. Where should I ask, that what's PGE means? Yes, I know, it's Parrot Grammar Engine, and I know what it is, but a beginnner maybe not. And I think that there are a lot of questions around like this, but people feel, that those questions don't fit to the lists. Or maybe not, don't know. I agree, that it is useful for the designers to see the questions, but if it will be a separate list, it still won't be impossible for them. Anyway, I understand why you wrote what you wrote, so as there will be no decision, I'll ask my questions on perl6-compiler. Bye, Andras
Re: new mailing list: perl6-general?
Hi, Anyway, I understand why you wrote what you wrote, so as there will be no decision, I'll ask my questions on perl6-compiler. I mean, perl6-language. Bye, Andras
Re: ?CALLER::BLOCK vs. any hope of efficient compilation
On Tue, Jun 14, 2005 at 04:13:08PM +0200, Chip Salzenberg wrote: : It therefore would a Bad Thing if ?CALLER::BLOCK worked generally. : If the caller _is_ a block that was already marked at compile time as : requiring full sub properties then, of course, it's no problem to use : the syntax ?CALLER::BLOCK to denote it. It's okay to optimize away callability, though I'd like to point out that ?CALLER::BLOCK by itself doesn't imply a call. It might most often be used to get at the block's metadata without the intent of calling it. And in that case it needs only a tiny bit of dynamic support, probably just some link to the current (static) lexical block scope object that you could probably get from caller() anyway. But it's fine to throw an exception if they actually try to call the beastie unexpectedly. Larry
Creating a web templating engine
Hi,
I'm busy with creating a widget based web templating engine, but I have
some problems, please help me. The engine would allow you to define
widgets, and use those in your templates. I would like it to be an OO
module.
In the template, you can write this:
server:input id=name width=100px maxlength=64 important=yes /
When the template engine read it, it will call a subroutine:
call_a_sub_for_input(id='name', width='100px', maxlength='64',
important='yes');
What this sub gives back, will be put into the output. I hope, you got the
idea.
I have the code, that can parse the template, and the code, that would
call the widget, so no problems with it. I don't know, how to put it
together. I don't know, how should the programmer define a new widget,
how it would be the most nicer way? How it can be detected by the template
engine? I don't want a register function, like this:
$wte = new WTE;
$wte.register('input', my_input_widget);
I don't prefer it, to be 20-30 register line in my programs, that does
nothing, just register.
It would be OK, to just define a global subroutine, and allow the template
engine to call widget_$name if it reads a widget, but...
sub widget_input(*%params) {
...
}
It's not nice. Maybe something like this?
new_widget :input = {
return input /;
}
It's almost a register function, but it's more compact, and I like it. But
if I would like to get parameters from the widget caller, how can I manage
it? Is it possible to call this new noname sub with parameters, and get it
easily inside the sub, for example like this:?
new_widget :input = {
my $name = _something_{'id'};
return 'input name=' ~ $name ~ ' /';
}
And I have more questions, but that's enough for this mail. Did you got my
problem?
Bye,
Andras
Re: Creating a web templating engine
Hi,
$wte = new WTE;
$wte.register('input', my_input_widget);
I don't prefer it, to be 20-30 register line in my programs, that does
nothing, just register.
maybe something like this?
class MyWTE is WTE {
method input (...) {...}
method some_other_thing_you_would_have_had_to_register (...) {...}
...;
}
And how the WTE class will be able to call these methods?
new_widget :input = {
my $name = _something_{'id'};
return 'input name=' ~ $name ~ ' /';
}
new_widget :input = - Str $id {
return 'input name=' ~ $id ~ ' /';
}; # or
new_widget :input = sub (Str $id) {
return 'input name=' ~ $id ~ ' /';
}
Hmm. It's still good, isn't it?
new_widget :input = sub($id) {
...
}
I think I like it. :) I would choose a bit more compact form if it's
possible (I think, it isn't) - so if somebody has any idea, please let me
know. :) But it's quite OK.
Thanks,
Andras
Re: Creating a web templating engine
Hi,
BRTHZI Andrs wrote:
$wte = new WTE;
$wte.register('input', my_input_widget);
I don't prefer it, to be 20-30 register line in my programs, that
does nothing, just register.
maybe something like this?
class MyWTE is WTE {
method input (...) {...}
method some_other_thing_you_would_have_had_to_register (...) {...}
...;
}
And how the WTE class will be able to call these methods?
you'd have to instantiate your MyWTE class instead of the original WTE.
Then you'd simple call the methods on your MyWTE object:
my $wte = MyWTE.new;
$wte.input(...);
$wte.some_other_thing_you_would_have_had_to_register(...);
But I don't know if that's convenient in your program/module.
--Ingo
--
Linux, the choice of a GNU | When cryptography is outlawed, bayl bhgynjf
generation on a dual AMD | jvyy unir cevinpl!
Athlon!|
Re: MMD vs. anonymous parameter types referencing earlier parameters
Chip Salzenberg wrote:
Link link.
http://www.cs.washington.edu/research/projects/cecil/www/Papers/gud.html
In case it matters, we're trying to support the Perl 6 semantics of
both ($a:$b:) and ($a,$b:). The former looks like something that
could be implemented with something called predicate dispatch, but
the latter I'm not so sure of.
I never understood the difference. So if someone were so nice to
enlighten me...
(This also means that the type of is_equal:(...) is impossible to
express, unless I greatly misunderstand the foo:() syntax. But
it doesn't matter what you call it if you can't call it.)
The syntax might just be:
is_equal:(Integer $a, Integer where { $_ == $a } :)
It's a new type object every time, so every time you run that code you
get a new type object to describe $b, and therefore the type object of
the expression will never match up with the one used in the function
definition.
Hmm, looks like we have very different views of how dispatch works
and what the acting entitys are. To me is_equal is an object that
knows a set of targets basically indexed by their :() --- let's
call that the implementation signature. The call site knows the list
of parameters and is_equal. From this information a set of applicable
targets is calculated. This is the first time that the where clause
comes into play. If it returns false, that target is not considered
any further. When it returns true the closure comes into play when
the most specific target is determined. The value and type of $a are
known and as such constrain the type of $b and produce a more specific
match then an unconstrained Integer. In other words the type of $b
is a parametric, single value subtype of Integer.
Are you suggesting that type equivalence tests include introspection
into the semantics of the closure?
No. I just think that the closure is called at dispatch time as discribed
above and that this is the very moment when the instanciation of the
parametric type of $b takes place.
If so, what is close enough? If
not, how can Parrot ever know that
Integer where { $_ == $a }
is the same as
Integer where { $^foo == $a }
but different from
Integer where { $_ != $a }
It doesn't. The Code object stores the targets and the respective
closures.
? Down that path lay madness.[*]
MMD becomes MAD ;)
s/the compiler/Parrot/, since the specific multi implementation can be
introduced after the call is compiled.
Yep, but the type system is still there. And you are right, that there
is no chance in pre-calculating such dispatches. But that is the expected
price to pay for predicate dispatch. And the target selector living inside
the MMD object might actually be 'recompiled' during runtime when new
instances are added. That is similar to the automata behind regular
expressions.
Regards,
--
TSa (Thomas Sandlaß)
Re: proposal: binding with a function
On Tue, Jun 14, 2005 at 02:06:37PM +0200, BÁRTHÁZI András wrote:
: Hi,
:
: As I know, for binding, you can use the := operator, and just this:
:
: $a := $b;
:
: I would like to make a proposal, based on Ruby[1]:
:
: alias $a, $b;
You can always write a macro that does that.
: It's a fun:
:
: sub newline {
: \n x $_;
: }
:
: alias newlines, newline;
At one point we had a macro variant for single words:
word enters {'newline'};
But it's not clear which syntactic categories pay attention to that.
It's obvious that your intent is to alias a method name, here, but
that's not at all obvious to the compiler. Most simple macros remap
terms, not method names, which are a subset of postfix operators that
require the dot.
: So you can write:
:
: print 5.enters;
:
: Currently, you have to write it a more uglier way:
:
: my newlines := newline;
That won't work on a method name anyway unless you do it in the
dispatch class.
: Anyway, char '' is really neccesary there? It should work w/o it, too, as
: I think. Now - in Pugs - it doesn't.
The point of the sigils is to help keep the namespaces and syntactic
categories straight, and to indicate you're talking about the actual
variable object rather than just a name. Since you're merely trying
to remap the name here and not the object (which isn't even a variable
in your own package), the use of is going to be inappropriate in
any event. What you're really looking for is some kind of macro
based syntactic sugar that maps the appropriate syntactic category.
Maybe something based on this:
my macro postfix:enters { 'newline' }
There's some possibilility of syntactic sugar resembling:
my postfix:enters ::= newline;
But Perl 6 is not going to encourage the C-preprocessor mindset of
completely divorcing the meaning of identifiers from their syntactic
context. In other words, you can't wildcard the syntactic category:
*:enters ::= newline;
You'll have to write your own macro if you want to do that.
Larry
Re: Assigning Proxy objects
On Tue, Jun 14, 2005 at 12:33:34PM +, Ingo Blechschmidt wrote:
: Hi,
:
: sub proxy () is rw {
: return new Proxy:
: FETCH = { 42 },
: STORE = - $new { 23 };
: }
:
: say proxy();# 42
: say proxy() = 40; # 40, 23, or 42?
:
: Currently I think the last line should output 40, consider:
:
: sub innocent_sub ($var is copy) {
: my $foo = ($var = 40);
: # Do something with $foo, relying on $foo being 40.
: }
:
: { my $x = does not matter; innocent_sub $x }
: # Works
:
: { my $x := proxy(); innocent_sub $x }
: # Would break if (proxy() = 40) would not return 40.
:
: But I can argue that the return value of Proxy object should
: be the return value of the code given by FETCH in the Proxy
: object construction, too...
:
: Opinions?
The intention is that lvalue subs behave in all respects as if they
were variables. So consider what
say $nonproxy = 40;
should do. This also extends to other operations than assignment:
temp $foo.bar() = 40;
or the very-nearly-Software-Transactional-Memory-oriented:
let $object.attribute() = 40; # hope this sticks...
Larry
Re: BEGIN {...} and IO
Ingo Blechschmidt wrote:
# No problem:
my $data = BEGIN {
my $fh = open some_file err...;
=$fh;
};
# Problem;
my $fh = BEGIN { open some_file err... };
# Compile-time filehandle leaked into runtime!
say =$fh;
[...]
* There's a boolean property may_leak_into_runtime every object has,
with a default of true.
BEGIN and CHECK then check if the object they're about to return has
.may_leak_into_runtime set to false -- if that's the case, die:
class MyClass does may_leak_into_runtime(false) {
method get_some_value () {...}
}
my $foo = BEGIN { MyClass.new }.get_some_value; # really means
my $foo = BEGIN {
my $result = MyClass.new;
$result.may_leak_into_runtime ?? $result :: die ...;
}.get_some_value;
Pro: Great flexibility, easy to use
unfortunately, even though I really like that solution, I found a
scenario where it'll fail:
my $foo = BEGIN {
my $fh = open some_file;
# $fh.may_leak_into_runtime is 0, so if we return $fh
# the compiler would throw an exception.
# But, instead, we create a closure:
my $code = { =$fh };
# $code.may_leak_into_runtime is 1, as Code is not an IO.
# So, this won't fail at compile-time.
};
say $foo();
# Compiler isn't able to catch this error at compile-time.
Maybe we should just hardcode the filehandles-leaking-into-runtime case
in the compiler? And, if the compiler can't detect the problem at
compile-time, just throw a runtime exception?
my $fh = BEGIN { open some_file };
=$fh; # Can't readline() on unopened filehandle leaked
# from compile-time into runtime, try to...
Opinions?
--Ingo
--
Linux, the choice of a GNU | Wissen ist Wissen, wo man es findet.
generation on a dual AMD |
Athlon!|
Re: Binding slices
Luke Palmer [EMAIL PROTECTED] writes: On 6/14/05, Piers Cawley [EMAIL PROTECTED] wrote: Following a conversation with Chip on IRC, is this my @y := @foo[0..][1]; legal? Definitely not. But it sure would be nice if this: my @y := @foo[0...][1]; were. I think that's what I meant to write :)
Re: State of Design Documents
On Tue, Jun 14, 2005 at 09:38:43AM -0400, Joshua Gatcomb wrote: : On 6/13/05, Patrick R. Michaud [EMAIL PROTECTED] wrote: : : Since it might not have been clear from my earlier post -- I've : now committed the S17 framework draft into the repository. Thanks. : : I am now questioning using Perl6 Timeline By Apocolypse as reference : material. Heh, that classification was a fast guess about RFCs made more than 4 years ago. I'm amazed it's stood up as well as it has, even where it hasn't. : I am rather interested in seeing the specs for pack/unpack : so I went about finding where it should go: : : There are 2 RFCs listed for A09 for pack/unpack : 142 Enhanced Pack/Unpack : 247 pack/unpack C-like enhancements : : There is an RFC for A13 regarding distinguishing packed data : 258 Distinguish packed data from printable strings : : The rest of the RFCs for pack/unpack fall into A29 : 246 pack/unpack uncontrovercial enhancements : 248 enhanced groups in pack/unpack : 249 Use pack/unpack for marshalling : 250 hooks in pack/unpack I think at this point we should assume that any RFCs that haven't been officially blessed should be considered officially suspect, and prior art (Perl 5) should generally take precedence unless we decide otherwise. If something seems too good to leave out, we can talk about it here. That being said, it's pretty clear that there are some things that are suboptimal about Perl 5's pack/unpack. : Now S09 and S13 have already been written but do not include the : details regarding pack/unpack. : : The patch to S29 is obvious - just add a heading for pack/unpack and : hope someone fills in the blanks. : : The patch for S13 is more difficult since I don't believe it warrants : a full heading. Probably just needs a guess as to how to expose the : flag to return a bool value i.e. $string.packed, comment about the : 'packed' warnings/strictures pragma, and stick it the right place. : : The patch to S09 has me stumped. : : Is there any other reference material I can use to put together solid : frameworks that are closely representative to what @larry might : produce? Not really, except insofar as we've talked about compact classes of native types working like C structs. There are lots of nitty things we can fix with pack/unpack, but the basic underlying problem is that pack/unpack are defined operationally rather than declaratively. As a kind of funny bytecode for serializing operations, it's rather powerful, but you'll notice that C gets by without such operationally defined structs. So I think that what we're going to end up with is a pack/unpack engine not so different from what we have, but it will very rarely be used directly. Rather, any compact class can automatically serialize/deserialize automatically, but can also be asked for its pack pattern for explicit control of pack/unpack when you want that. At the same time, I think the pack/unpack bytecode is not necessarily the final compiled form, since many of them could be jitted to PASM code that doesn't need to be interpreted by a pack/unpack engine, but handled directly by the VM, and maybe even jitted down to real machine code. That implies that either we modify the pack/unpack interface to allow explicitly produced compiled objects via MMD: @foo = unpack(packcomp(H*), $string) or we rely on caching of the compiled pack program with the supplied string. @foo = unpack($pk, $string);# recompiled only if $pk changes Arguably the latter is more user friendly, and doesn't commit to the compiled form if it turns out to actually be more efficient to interpret the pack bytecode directly. And we already presumably do that sort of caching for strings interpreted as rules. Larry
Re: MMD vs. anonymous parameter types referencing earlier parameters
On Tue, Jun 14, 2005 at 04:25:17PM +0200, Chip Salzenberg wrote:
: On Tue, Jun 14, 2005 at 03:43:42PM +0200, TSa (Thomas Sandlaß) wrote:
: The syntax might just be:
:
: is_equal:(Integer $a, Integer where { $_ == $a } :)
:
:
: It's a new type object every time, so every time you run that code you
: get a new type object to describe $b, and therefore the type object of
: the expression will never match up with the one used in the function
: definition.
Constrained subtypes are not types. The actual type is
is_equal:(Integer, Integer)
: Are you suggesting that type equivalence tests include introspection
: into the semantics of the closure? If so, what is close enough? If
: not, how can Parrot ever know that
:
: Integer where { $_ == $a }
:
: is the same as
:
: Integer where { $^foo == $a }
:
: but different from
:
: Integer where { $_ != $a }
:
: ? Down that path lay madness.[*]
Agreed, which is why constrained subtypes may only be used where they
make sense operationally. Unfortunately, MMD dispatch is one of those
places where we'd like to use constrained subtypes as a tie-breaker
for multies that would otherwise be considered ambiguous. As far as the
actual MMD engine is concerned, it could just arrange such methods
in any order, and call the first one, on the assumption that there is
some implicit code at the beginning of each that throws your magical
not me exception, which is really just next METHOD in disguise,
I suspect. If you write your constraints ambiguously, then you get
ambiguous dispatch order within the cohort. The engine should be under
no obligation to order the entries in most specific to most general,
except insofar as a signature without a constraint is considered more
general than one with a constraint, and sorts to the end of the cohort.
: [*] There is another theory which states this has already occurred.
There's more than one method to our madness.
Larry
Re: %hash1 ... %hash2
David Formosa (aka ? the Platypus) [EMAIL PROTECTED] wrote: If you consider arrays to be hashes keyed by integers then @a .. @b does the equiverlent of an inner join. I would suggest that if we are going to have outer join versions then we have something like this It does? I thought that when [EMAIL PROTECTED] != [EMAIL PROTECTED], the shorter one got extended with undefs... -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker
Hyper-concat
Hi!
While playing around with some japh-obfus (which turned into my first commit
to Pugs, yay!) I spotted this
say a b c ~ 1 2 3;
# prints a1b2c3
my $string=a b c ~ 1 2 3;
say $string;
# prints a1 b2 c3
I suppose this is caused by some context things. Csay imposes list context
(as print in Perl 5), but the assignment imposes scalar context.
But where do the spaces in the second example come from?
(sorry if this question is obvious/FAQ, but I'm just starting Perl6/Pugs
stuff (finally...))
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: Hyper-concat
Hi,
Thomas Klausner wrote:
my $string=a b c ~ 1 2 3;
say $string;
# prints a1 b2 c3
But where do the spaces in the second example come from?
the spaces come from the stringification of lists/arrays:
my @array = a b c d;
say [EMAIL PROTECTED];# a b c d
You can use
say [~] @array; # abcd or
say @array.join();# abcd or
say join , @array;# abcd
if you want to supress the spaces.
And you could override this by doing something like:
class MyArray is Array {
method *prefix:~ (@self: ) { [~] @self }
}
my @array is MyArray = a b c d;
say [EMAIL PROTECTED];# abcd
--Ingo
--
Linux, the choice of a GNU | The computer revolution is over. The
generation on a dual AMD | computers won. -- Eduard Bloch [EMAIL PROTECTED]
Athlon!|
Re: Hyper-concat
On Tue, Jun 14, 2005 at 10:31:58PM +0200, Ingo Blechschmidt wrote: : You can use : say [~] @array; # abcd or : say @array.join();# abcd or : say join , @array;# abcd : if you want to supress the spaces. I think a bare @array.join should also work. Larry
Re: Hyper-concat
Larry Wall skribis 2005-06-14 14:15 (-0700): On Tue, Jun 14, 2005 at 10:31:58PM +0200, Ingo Blechschmidt wrote: : You can use : say [~] @array; # abcd or : say @array.join();# abcd or : say join , @array;# abcd : if you want to supress the spaces. I think a bare @array.join should also work. I think it should not. split splits on whitespace, stringification joins on whitespace, reverse in scalar context joins on whitespace. It would be fair if join defaulted to ' ' as well. You suggested cat as a join assuming '' in an old thread. I still like that idea. [ 'a' .. 'e' ].join # a b c d e [ 'a' .. 'e' ].cat# abcde Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Hyper-concat
On Tue, Jun 14, 2005 at 11:33:21PM +0200, Juerd wrote:
: You suggested cat as a join assuming '' in an old thread. I still like
: that idea.
:
: [ 'a' .. 'e' ].join # a b c d e
: [ 'a' .. 'e' ].cat# abcde
I had forgotten that. Yes, there is a little something to be
said for preserving the (mostly false) symmetry of split and join.
I think I argued for .cat on the basis that it also gives us cat as
a list operator. But these days that's just [~], so at the moment
I'm inclined to stick with argumentless .join doing concatenation,
especially since I'd like to undo the split(' ') special case anyway
and use a different notation for word splitting.
Larry
Re: Hyper-concat
Larry Wall skribis 2005-06-14 14:54 (-0700):
: [ 'a' .. 'e' ].join # a b c d e
: [ 'a' .. 'e' ].cat# abcde
I had forgotten that. Yes, there is a little something to be
said for preserving the (mostly false) symmetry of split and join.
I think I argued for .cat on the basis that it also gives us cat as
a list operator. But these days that's just [~], so at the moment
I'm inclined to stick with argumentless .join doing concatenation,
especially since I'd like to undo the split(' ') special case anyway
and use a different notation for word splitting.
Still, argumentless split probably defaults to something. And ' ' is a
good thing to default to, IMO. It doesn't have to be a special case. In
fact, it not being a special case makes the symmetry less false, and
would --if ' ' is the default-- make the case even stronger for join to
default to ' ' too.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Hyper-concat
At 12:01 AM +0200 6/15/05, Juerd wrote:
Larry Wall skribis 2005-06-14 14:54 (-0700):
: [ 'a' .. 'e' ].join # a b c d e
: [ 'a' .. 'e' ].cat# abcde
I had forgotten that. Yes, there is a little something to be
said for preserving the (mostly false) symmetry of split and join.
I think I argued for .cat on the basis that it also gives us cat as
a list operator. But these days that's just [~], so at the moment
I'm inclined to stick with argumentless .join doing concatenation,
especially since I'd like to undo the split(' ') special case anyway
and use a different notation for word splitting.
Still, argumentless split probably defaults to something. And ' ' is a
good thing to default to, IMO. It doesn't have to be a special case. In
fact, it not being a special case makes the symmetry less false, and
would --if ' ' is the default-- make the case even stronger for join to
default to ' ' too.
I think that '' is the best default case for both split and join in Perl 6.
They would be symmetrical because they are both ''.
And the space character is really a rather arbitrary looking value
for a default and is equally valid with, say, the line break, so how
can one say it is better?
-- Darren Duncan
Re: Hyper-concat
Darren Duncan skribis 2005-06-14 15:12 (-0700): And the space character is really a rather arbitrary looking value for a default and is equally valid with, say, the line break, so how can one say it is better? Array stringification uses it too, by default. The lesser the number of defaults, the more predictible the language is. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Hyper-concat
Juerd wrote: Still, argumentless split probably defaults to something. And ' ' is a good thing to default to, IMO. I like /\s+/ as a default for split better. -- Rod Adams
