RE: Properties
> From: Luke Palmer [mailto:[EMAIL PROTECTED]
> Hodges, Paul writes:
> >
> > sub setvals ($o, [EMAIL PROTECTED]) {
> > $o but= $_;
> > $o.$_ = true;
> > }
>
> Y'all seem to be missing a C somewhere :-)
>
> sub setvals ($o, [EMAIL PROTECTED]) {
> $o but= $_ for @t;
> }
LOL!!! I can't believe I missed that! =o)
You're obviously right, tho.
> I think that should work, as the right side of C should
> always be a property, so a property reference ought be interpreted
correctly.
>
> > One thing, though could I do this? >=o}
> >
> > my property (foo,bar,baz) ^is true;
> > $thingy ^but= (foo,baz);
>
> No, but you might be able to if you used proper vectorizing syntax ;-)
>
> my property (foo,bar,baz) is sometrait; # is automatically
distributes
> $thingy Âbut=Â (foo,baz);
Didn't know "is" would do that. Good to know!
And in my meager defense, I did reference MikeL's operator synopsis as of
3/25/03, which said ^[op] might be a synonym for <<>> or >><< (Sorry, no
fancy chars here. :)
> C doesn't seem like a trait you would put on a property. C
> is a run-time property, and I think it would be awfully confusing to
> make it a trait as well. If you're talking about some kind of
> initialization, you might use:
>
> my property (foo,bar,baz) is first(1);
>
> Or C might be correct if you're -- somehow -- deriving these
> properties from the C property. But I don't think that was the
> intent.
Was just initializing. Don't remember "is first(whatever)", though it seems
a bit familiar.
> > I'm pretty sure that syntax is way wonky -- would "is" be a
> > vectorizable operator? Does it even qualify as an operator at all?
>
> C is definitely an operator, much in the same way C is an
> operator. Whether it's vectorizable is questionable, because in all
> cases I've seen the vectorization is implicit. That is, if it has a
> non-vector meaning, the meaning of:
>
> my ($a,$b,$c) is foo;
>
> is a little fuzzy. What's C applying to if it's not
> applying to all of $a, $b, and $c?
I hadn't seen it done that way...at least not recently enough that I
remembered it.
Last I recall, someone was thinking it would be
my ($a is foo, $b is foo, $c is foo);
Which really sux. I'm glad that was cleaned up.
> > > > then write allow() to build roles for each value passed in,
> > > > maybe taking an arg to say whether they should be truly global,
> > > > or built in the caller's namespace
> > >
> > > Isn't that what my, our, Exporter, and the globalifying * are
> > > all about?
> >
> > Probably, though I haven't seen anything yet about how the
> > P6 version of the Exporter is going to handle things like specifying
> > exportation of my() vars &co.
>
> I'm pretty sure that the interface to Exporter can be cleaned
> up quite a bit in Perl 6. For now, though, I think it's fine to assume it
works
> exactly like Perl 5's.
Which is why I was building an allow(), which would let you specify property
names to create in the use() statement of the module. I have *NO* clue how
you would use the current Exporter to create roles on-the-fly, but I think I
could build something that would do its own exporting to whatever level it
was told. Maybe level 0 is make them but don't export, 1 is export them into
the calling namespace, and 2 is truly global:
use MyRoles export => 0, <>;
my $whatsit but= MyRoles.foodiddly; # above line made this acceptable
$whatsit.foodiddly = 1;
but could I instead say
my $whatsit but= MyRoles.foodiddly(1);
or something like that?
*
"The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other use
of, or taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from all
computers.61"
Re: 'Core' Language Philosophy
Michael Lazzaro <[EMAIL PROTECTED]> writes: > On Wednesday, November 26, 2003, at 12:29 PM, Larry Wall wrote: >> If you contrast it with an explicit try block, sure, it looks >> better. But >> that's not what I compare it with. I compare it with Perl 5's: >> >> $opus.write_to_file($file) or die "Couldn't write to $file: $!"; >> >> That has some known problems with false positives, er, negatives, >> which Perl 6 addresses with things like: >> >> $opus.write_to_file($file) err fail "Couldn't write to $file: $!"; >> >> But if we're going to talk about philosophy, we should talk about >> Perl's notion of not forcing people to escalate all the way to >> exceptions when a lesser form of undefinedness or falseness will do. >> Perl 6 doesn't back off from this. In fact, it takes it further >> by allowing you to return unthrown exceptions as "undef". And by >> providing a "fail" that either returns or throws the exception >> depending on the preferences of the caller. > > Well, yes, hmm, har, but... > > Speaking only for myself, my own (database-heavy) code already makes > pretty extensive use of the differences between "false", > "unknown/undefined/NULL", and "worthy of exception" -- all three of > those conditions may exist at various times, and no two of them can > reasonably be lumped together as being logically identical. So implement a *real* NULL instead of trying to force 'undef' somewhere it doesn't want to go.
>>OP<< [was: Re: Properties]
On Monday, December 1, 2003, at 01:05 PM, Hodges, Paul wrote: Didn't know "is" would do that. Good to know! And in my meager defense, I did reference MikeL's operator synopsis as of 3/25/03, which said ^[op] might be a synonym for <<>> or >><< (Sorry, no fancy chars here. :) Hey, that was *March*! ;-) The fossil records from that time are fragmentary, at best. I don't think I ever saw any further reference to the ^[op] syntax staying alive; I assume that means it's dead. Last I heard, which was admittedly around the same time frame, we'd have the non-Unicode-using >>op<<, and a Unicode synonym »op«, and that's it. There were also vaguely threatening proposals to have <> and >>op<< do slightly different things. I assume that is also dead, and that <> is (typically) a syntax error. If anyone in the know knows otherwise, plz verify for Piers' summary and the future fossil record. MikeL
Re: >>OP<< [was: Re: Properties]
Michael Lazzaro writes:
>
> On Monday, December 1, 2003, at 01:05 PM, Hodges, Paul wrote:
> >Didn't know "is" would do that. Good to know!
> >And in my meager defense, I did reference MikeL's operator synopsis as
> >of
> >3/25/03, which said ^[op] might be a synonym for <<>> or >><< (Sorry,
> >no
> >fancy chars here. :)
>
> Hey, that was *March*! ;-) The fossil records from that time are
> fragmentary, at best.
>
> I don't think I ever saw any further reference to the ^[op] syntax
> staying alive; I assume that means it's dead. Last I heard, which was
> admittedly around the same time frame, we'd have the non-Unicode-using
> >>op<<, and a Unicode synonym æopæ, and that's it.
>
> There were also vaguely threatening proposals to have <> and >>op<<
> do slightly different things. I assume that is also dead, and that
> <> is (typically) a syntax error.
Ack. No, slightly different things would be a very bad idea.
At the moment, as most of you probably know, they do *very* different
things. >>op<< vectorizes the operator, and <> is
equivalent to qw{some stuff}.
And as far as I know, << and >> are exactly equivalent to æ and æ in all
cases.
Luke
> If anyone in the know knows otherwise, plz verify for Piers' summary
> and the future fossil record.
>
> MikeL
>
Re: >>OP<< [was: Re: Properties]
Luke Palmer writes: > And as far as I know, << and >> are exactly equivalent to æ and æ in all > cases. By which I mean  and Â, of course. :-/ (mutt is kind of a pain in this area) Luke Ã
Re: >>OP<< [was: Re: Properties]
On Tuesday, December 2, 2003, at 12:37 PM, Luke Palmer wrote:
Michael Lazzaro writes:
There were also vaguely threatening proposals to have <> and
>>op<<
do slightly different things. I assume that is also dead, and that
<> is (typically) a syntax error.
Ack. No, slightly different things would be a very bad idea.
At the moment, as most of you probably know, they do *very* different
things. >>op<< vectorizes the operator, and <> is
equivalent to qw{some stuff}.
Sorry, right.
I therefore deduce that the proposal to have, for example, <<+>> mean a
different flavor of vectorization than >>+<<, e.g. for these to do
different things:
@a >>+<< @b;
@a <<+>> @b;
is quite soundly and completely dead.
Excellent. Let us not speak of it again.
MikeL
Re: >>OP<< [was: Re: Properties]
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote: > > On Monday, December 1, 2003, at 01:05 PM, Hodges, Paul wrote: > > Didn't know "is" would do that. Good to know! > > And in my meager defense, I did reference MikeL's operator > > synopsis as of 3/25/03, which said ^[op] might be a synonym > > for <<>> or >><< (Sorry, no fancy chars here. :) > > Hey, that was *March*! ;-) The fossil records from that time are > fragmentary, at best. lol... and I've been a little out of the loop lately, too. > I don't think I ever saw any further reference to the ^[op] syntax > staying alive; I assume that means it's dead. Last I heard, which > was admittedly around the same time frame, we'd have the > non-Unicode-using >>op<<, and a Unicode synonym »op«, and that's it. I think I saw a few of those in passing. Been a while. :) > There were also vaguely threatening proposals to have <> and > >>op<< do slightly different things. I assume that is also dead, > and that <> is (typically) a syntax error. Which is probably a good idea. We have any/all/one/none, and not *everything* needs a punctuation-type version. I'd actually rather *not* have alternate versions of those, unless they do something different, like they way "or" has a lower precedence than "||". Likewise, if we're going to use <<>> as P6's version of P5's qw//, then never mind the complexity of making the parser able to figure out that a given case of <<+>> means I've deleted all other items from the list, rather than wanting a distributive addition Yes, I could figure it out, but there are currently enough contextually dependent items in the language that the importance of that one doesn't strike me as 'core' necessary, if you know what I mean. :o) > If anyone in the know knows otherwise, plz verify for Piers' summary > and the future fossil record. > MikeL Could we get a synopsis posted somewhere? Maybe something that inticates the current state of this particular onion? __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
Re: >>OP<< [was: Re: Properties] [OT]
> And as far as I know, << and >> are exactly equivalent to æ?? and æ?? > in all cases. lol I get the idea, but I foresee these unicode bits as becoming an occasional sharp spot in my metaphorical seat of consciousness. :) I am not seeing unicode. __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
This week's summary
The Perl 6 summary for the week ending 20031130
Welcome back to the weekly Perl 6 Summary, which I'm hoping to keep on a
weekly cycle for the foreseeable future.
It's been a relatively low volume week this week, I'm assuming that
Thanksgiving had something to do with it (I hope those of you who
celebrate it had a jolly good extended weekend), and for the first time
in ages perl6-language saw almost as much traffic as perl6-internals.
We're still going to start with perl6-internals though.
Some PIR "How do I?" questions
Last week Dan put up a list of questions about IMCC, intending it as a
bit of grit. This week Melvin Smith added a couple of layers of nacre by
checking in an initial IMCC FAQ (you'll find it at imcc/docs/imcfaq.pod
in your parrot directory if you're following with CVS). After an initial
flurry of work on adding to the FAQ, the discussion seems to have
drifted off into discussions of bike shed pigmentation. Yes, the FAQ may
need to be split eventually, but splitting an FAQ into sub documents is
trivial compared to actually answering the questions. Ahem. Editorial
ends.
http://groups.google.com/[EMAIL PROTECTED]
http://www.parrotcode.org/faq/imcc -- The FAQ
PIO_eof
Vladimir Lipsky had a few questions about how the Parrot IO subsystem
(PIO) handles error conditions. This sparked a discussion of whether the
various PIO functions should make some assertions up front about their
arguments. Consensus said "yes", they help with debugging, and the
performance 'hit' is minuscule.
http://groups.google.com/[EMAIL PROTECTED]
Freezing and Thawing
Discussion of the details of object serialization continued this week.
Judging by the amount of clarification traffic that's been going on in
this thread (and others), I find myself wondering if the time has come
for some generous benefactor to sponsor the principals to get together
in a conference room with copious whiteboard acreage. Sponsors welcome.
http://groups.google.com/[EMAIL PROTECTED]
Segfault warning boxes
Consider a system of test machines, all of them happily running in
unattended mode, constantly checking out the latest version of parrot,
compiling everything, running the tests and reporting the results to
some central webserver that displays a status report for all to see.
It's not just a good idea, it's the Parrot tinderbox.
Now, consider an operating system that takes it upon itself to throw up
a modal dialog box when a program segfaults.
The two don't sit well together do they? Which is why Dan has committed
a patch to disable the "Your program has crashed, want to send a report
to Microsoft?" box that pops up on Win32 when Parrot segfaults. Still,
at least it can be disabled.
Dan asked for opinions on whether the (non tinderbox) default should be
to put up a dialog box or not. And it appears that, if you disable the
dialog box, there's no other notification (apart from the failed test,
obviously) that there was a segfault. I am sure I'm not alone in
boggling at this, but it looks like the default will be to display the
dialog.
http://groups.google.com/[EMAIL PROTECTED]
Perl 6 updated
Allison Randal sent in a patch to update the Perl 6 compiler to use the
right operators ("^+" becomes ">>+<<", "~~" (meant xor)
becomes "^^", making way for "=~" to become "~~"). She's still working
on other tweaks to get the semantics of what's already been implemented
right, and claims to be sufficiently annoyed by the failing regex tests
that she might have to go and make them work to remove the annoyance.
Which would be good. (I'm afraid that the tantalizing code I mentioned
last week has actually been there for ages, as I feared it had). That
capital fellow, chromatic applied the patch.
http://groups.google.com/[EMAIL PROTECTED]
String formatting and transformation
Dan got around to specifying some details about string formatting and
transformation. Essentially there will be various case changing
transformations and a couple of different formatting approaches, one
"sprintf" like and another more like traditional COBOL style formatting.
Dan's not sure yet whether these formatters will get ops or simply be
implemented in the standard library.
http://groups.google.com/[EMAIL PROTECTED]
AUTOLOAD anyone?
Someone calling itself ibotty wondered if there would be a default PMC
method that gets automagically called whenever a method call isn't
found. To which the answer is "Yes, when it's done".
http://groups.google.com/[EMAIL PROTECTED]
erl.org
Determining PMC memory addresses
Cory Spencer wanted to know if there was a PASM way of finding whether
two PMCs share the same memory address. "Not yet", said Leo Tötsch, "but
there are entries in the v
