Re: perl6-lang Project Management
Michael Lazzaro wrote: [...some good points...] > and has resulted in us revisiting decisions *repeatedly* Simon Cozens wrote: [...some good ideas...] > [1] You can tell I've been rereading MMM... Maybe there's some benefit to be had from revisiting old material? :-) I can't think of any non-trivial piece of software I've written without going over the design several times... just like I can't think of any great book that I've fully appreciated without reading through it several times. Sometimes the Perl 6 design process looks like a machine that's running fast but moving forward slowly, churning over the same ground. But in this case, the purpose of our vehicle is to plough the ground. We're more concerned about tilling the soil than getting to the other side of the field as quickly as possible. From that perspective, it looks to me at least, like we're making much better progress. Well, "we" meaning "you". I'm no use to anyone - my head exploded days ago in a big mess of Unicode operators. <<*[BOOM]*>>8-| Keep up the good work. A
Re: Unifying invocant and topic naming syntax
ralph wrote:
My estimate (based on the -- not inconsiderable --
code base of my own modules) is closer to 5%.
Your estimate of what others will do when
knocking out 10 line scripts in a hurry,
or what's in your current p5 modules?
Both.
Can currying include the given topic?
sub bar is given($foo) {
...
}
$foo = &bar.assuming( foo => 0 )
Maybe. Depends whether we treat the topic specifier as an out-of-band
parameter mechanism. Personally, I'm leery of doing that, but Larry might
well feel it's okay.
And what about a topic placeholder:
$foo = { print $^_ };
such that $^_ is effectively converted to
an 'is given($^_)'.
No, that doesn't work. The placeholder $^_ is
entirely unrelated to $_. Besides, what's wrong with:
$foo = sub { print $_ } is given($_);
???
Damian
Re: list comprehensions
Piers Cawley pointed out:
%a_students = grep {.key ~~ :i/^a/}, %grades.kv;
I think you could probably get away without the .kv there since, in a
list context you're going to get a list of pairs anyway.
In fact, the code is invalid as it stands. The following variations
work as desired:
%a_students = grep {.key ~~ /:i^a/} %grades;
or:
%a_students = grep {.key ~~ m:i/^a/} %grades;
or:
%a_students = grep sub($k,$v){$k ~~ m:i/^a/}, %grades.kv;
Damian
Re: Superpositions and laziness
Piers Cawley mused:
The idea being that, when you do
a_pure_func($val1|$val2|$val3)
instead of Perl going away and doing the calculation right away, you
get back a 'special' superposition
Remember to s/superposition/junction/g. For this week, at least ;-)
> which stores an 'invocation description' and calculation is deferred
> until you need to get a superposition's list of possible states.
You get most of that with just:
$deferred = &a_pure_func.assuming(arg=>$val1|$val2|$val3);
Then, later, when you want the result junction:
$junction = $deferred();
Of course, the utility of this kind of laziness isn't restricted to
superpositions, so maybe there would be an C property for
subroutines. For example, given the eager subroutine:
sub a_pure_func(Num $n) returns Num {
return $n ** $n
}
we could make it lazy thus:
sub a_pure_func(Num $n) is lazy returns Num {
return $n ** $n
}
which would cause any invocation of C to cache
its arguments (probably in a closure) and return a "proxy"
Num that carries out the computation only when the proxy is
evaluated.
Then it wouldn't matter what the subroutine did, or whether
the argument was a simple number, some species of junction,
or some mysterious object of a class derived from Num.
Damian
Re: String -> Numeric conversion
Michael Lazzaro wrote:
If anyone knows the answer to these two questions, I'd appreciate it.
Only Larry "knows". But I'm prepared to take an educated guess.
1) What do these do?
my int $n = 5; # OK
Yes.
my int $n = 5.005; # trunc or err?
Truncate to 5 with optional warning (would be my preference).
my int $n = "5.05ff" # 5, 0, undef, NaN, or exception?
Truncate to 5 with optional warning (would be my preference).
my int $n = "fdsjfdf"# 0, undef, NaN, or exception?
Call C would be my preference.
That is, let the user decide whether the result is C or an exception.
2) Do "num" and "int" share a common base "is a number" class, such that
(in perl5-ish speak) we can say
if want(numeric) { ... }
to identify both, or is "num" the base class to test for, and "int" a
subclass?
The latter would be my expectation. Though it's C, not c, I believe.
Damian
Re: Unicode operators
Flaviu Turean wrote: [...] 5. if you want to wait for the computing platforms before programming in p6, then there is quite a wait ahead. how about platforms which will never catch up? VMS, anyone? Not to start an OS war thread or anything, but why do people still have this mistaken impression of VMS? We have compilers and hard drives and networking and everything. We even have color monitors. Sure, we lack a decent c++ compiler, but we consider that a feature. :-) brad
Re: perl6-lang Project Management
>1) We find a team of volunteers who are willing to "own" the > task of converting each Apocalypse into a complete design. If > nobody wants to write the Perl 6 user manual, then we might as well > give up and go home now. So far we only need to find four, though, > so it Might Just Work. I would prefer to work from perl5 documentation. Because: - some documents can be already written, even when there is not yet an Apoc tallking about them. (for example, "perlvar" shoud be reasonably easy) - Apocalypses talk about a big number of issues, while perl5 pods are already structured in documents of reasonable length. - The sorther length of perl5 pods documents makes it much easier for a single person to make the specific task. People would volunteer for a document, and write and send it for review in a separate list from perl6-language. There should be someone to finally aprove the tentative version. It could be someone with experience in perl5 documentation, and not necessarily from the design team (because the task is about documenting, not creating). -angel
on Topic
I just want to be sure I understand correctly :
In your article at perl.com you describes various ways and situations
when perl creates a topic and this is described as perl making the
following binding on my behalf:
$_ := $some_var ; *1*
and probably marking $_ with some additional properties (e.g. is
read-only ...) .
questions:
???
if I will write that explicitly myself will that have *the same*
effect ? in other words, is *1* _all_ that topic is about ? Or there
is some additional magic. particularly , will "when" work as before ,
What will happen if I will _override_ $_ explicitly inside
e.g. "given" construct or other topicalizers:
my $x,$z;
given $x->$y {
$_ := $z ;
when 2 { ... } #checks against $z ???
}
???
methods topicalize their invocant. Is $self aliased to $_ inside the
method in this ex. ?
method sub_ether ($self: $message) {
.transmit( .encode($message) );
}
will it be an error to write
method sub_ether ($self: $message, $x is topic) {...}
what happens if I write
method sub_ether ($self: $message) {
$_ := $message ;
}
or
method sub_ether ($self: $message) {
$_ = $message ;
}
is $_ always lexical variable. Or I can have $MyPackage::_ ?
and just on the related topic :
* can I alias $something to $_ ?
$something := $_
(it seems that I can , because $_ is just another variable )
also , is this valid ?
$b := $a ;
$c := $b ;
( now changing value of one variable will change other two ??? )
or e.g.
$a = 1 ;
$Z = 10 ;
$b := $a ;
$c := $b ;
print $c # prints 1
$a := $Z ;
print $c # prints 10
$a = 5;
print $Z # prints 5
am I wrong ?
also
@a := ( $a, $b)
$b := $c
@a[1] = 10 ;
print $c # prints 10
???
thanks
Arcadi
Re: Primitive Vs Object types
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote: > Primitive types were originally intended for runtime speed, thus an > "int" or a "bit" is as small as possible, and not a lot of weird > runtime > checking has to take place that would slow it down. It can't even be > undef, because that would take an extra bit, minimum, to store. This just ain't so. I once worked on a CPU simulator, and in order to set watch values on arbitrary memory we used a "key" value that, if present in simulated memory, indicated that a search of the "watches table" was in order. That key was chosen empirically, based on histogramming the ROM images and active program state, and choosing the lowest frequency value. Thus, the "fetch byte" primitive would automatically check and notify whenever a 0xA9 was seen. (Sometimes it really meant 0xA9, other times it meant "0x00, but halt execution".) The same can be done here, if the internals folks can make the assumption that the case is really uncommon. To wit: For 'bit', the key value is (eenie, meenie, ...) '1'. Any '1' value will trigger a search for undef bit values. Presuming that bit values will not frequently be undef, the search should be cheap and the storage requirements will be something on the order of C + Num_undef_bits * sizeof(addr_t) Which will be greater than one extra bit when few or no bit objects are used, and will be very much smaller than one extra bit when many bit objects are used. In short: It's possible, even easy, to implement ANY feature (properties, undef, etc) for primitive types in this manner. It absolutely *IS* correct to say "That's an implementation detail" and leave it to the internals team to figure out HOW they want to do it. So what's the difference REALLY? =Austin __ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2
Re: Primitive Vs Object types
On Thursday, November 7, 2002, at 06:36 AM, Austin Hastings wrote: For 'bit', the key value is (eenie, meenie, ...) '1'. Any '1' value will trigger a search for undef bit values. Presuming that bit values will not frequently be undef, the search should be cheap and the storage requirements will be something on the order of Right. So it's a question of having a little extra storage (at least 1 bit, somewhere, for each "undef"), but more importantly a question of whether or not there are "primitive" types that circumvent that check. From A2 we have: "Run-time properties really are associated with the object in question, which implies some amount of overhead. For that reason, intrinsic data types like C and C may or may not allow run-time properties. In cases where it is allowed, the intrinsic type must generally be promoted to its corresponding object type (or wrapped in an object that delegates back to the original intrinsic for the actual value). But you really don't want to promote an array of a million bits to an array of a million objects just because you had the hankering to put a sticky note on one of those bits, so in those cases it's likely to be disallowed, or the bit is likely to be cloned instead of referenced, or some such thing." If internals says that there's no runtime speed issue, that's awesome. I think we just have to be aware of one of our implied goals -- that Perl6 can be used for giant data-munging tasks without speed penalties so horrific as to send people to other languages. MikeL
Re: perl6-lang Project Management
On Thursday, November 7, 2002, at 03:44 AM, Angel Faus wrote: 1) We find a team of volunteers who are willing to "own" the task of converting each Apocalypse into a complete design. If nobody wants to write the Perl 6 user manual, then we might as well I would prefer to work from perl5 documentation. Because: Unfortunately, after doing lots of initial outlining, I don't see a whole lot of useful correlation between them anymore. :-/ The perl5 pods are not terribly detailed compared to what we need, and there's so many changes in the "fundamentals" of the language that we really have to explain and support it in a much more sophisticated way, if we want the language to grow. So I've become fairly convinced we need to rethink the docs, just like we're rethinking the language. So far, I have experimented with two approaches ... the "annotated recipes" approach (1), and the "booklike" approach (2): example 1: http://cog.cognitivity.com/perl6/1_intro/6.html example 2: http://cog.cognitivity.com/perl6/val.html to check out how they both would feel online. The "annotated recipes" approach is an *excellent* format for a document to be constructed in, since it allows realtime feedback from people -- you can post your proposed changes right there, and have them reviewed, without anyone duplicating effort and without checkin/checkout/patch issues. It's self-organizing, and it doesn't need teams -- people can contribute when and how they like, to whatever they like. Good when dealing with lots of opinionated but lazy people. ;-) OTOH, the "booklike" approach is much easier (for me, at least) to write *large* chunks of documentation very quickly, but is more difficult to contribute to. There's probably a happy medium here somewhere. After experimenting, I myself have been gravitating towards the online mysql (http://www.mysql.com/documentation/) documentation as the best example of what I think we need for a "final version". Maybe. Check it out and see what you think. I dunno anymore, maybe we need to rethink what place there is for public domain docs at all. Perhaps we just have a man page that says "buy the damn books, you cheapskate" and be done with it. MikeL
Re: perl6-lang Project Management
On Thu, 7 Nov 2002 at 10:38 -0800, Michael Lazzaro <[EMAIL PROTECTED]: > I dunno anymore, maybe we need to rethink what place there is for > public domain docs at all. Perhaps we just have a man page that says > "buy the damn books, you cheapskate" and be done with it. I trust you were joking, right? I learned perl3 by reading the 62 pages of the manual. I learned perl4 by reading the 76 pages of the manual, and then bought the book. For perl5 I read much of the manual, and bought and read 4 books. (there are nearly 2000 pages of pod documentation for perl5.9, not counting the perldoc of the installed modules). I expect that perl6 will have more online documentation, and I'll probably learn from the new books I purchase. With out authoritive online documention I don't think that perl6 will go anywhere.
Re: on Topic
In the hope this saves Allison time, and/or
clarifies things for me, I'll attempt some
answers.
> In your article at perl.com you describes
> various ways and situations when perl
> creates a topic and this is described as
> perl making the following binding on my behalf:
>
> $_ := $some_var ; *1*
Well, $_ might not be bound to a named variable
but instead be just set to a value, or it might
be bound to an array cell or some other unnamed
container.
> is *1* _all_ that topic is about ?
Sorta. To quote an excellent summary:
"Topic is $_".
> my $x,$z;
> given $x->$y {
> $_ := $z ;
> when 2 { ... } #checks against $z ???
> }
Yes.
> methods topicalize their invocant. Is $self
> aliased to $_ inside the method in this ex. ?
>
> method sub_ether ($self: $message) {
> .transmit( .encode($message) );
> }
Yes.
> will it be an error to write
> method sub_ether ($self: $message, $x is topic) {...}
No.
> what happens if I write
> method sub_ether ($self: $message) {
> $_ := $message ;
> }
> or
>
> method sub_ether ($self: $message) {
> $_ = $message ;
> }
Both Ok. $_ is "it" and has the value $message;
in the former case $_ and $message are bound.
> is $_ always lexical variable.
Yes.
> Or I can have $MyPackage::_ ?
You can copy or alias any value.
> * can I alias $something to $_ ?
> $something := $_
Sure. Because...
> (it seems that I can , because $_ is just
> another variable )
> $b := $a ;
> $c := $b ;
>
> ( now changing value of one variable will
> change other two ??? )
Yes.
> or e.g.
>
> $a = 1 ;
> $Z = 10 ;
>
> $b := $a ;
> $c := $b ;
>
> print $c # prints 1
> $a := $Z ;
> print $c # prints 10
> $a = 5;
> print $Z # prints 5
Yes.
> also
>
> @a := ( $a, $b)
Er, I don't think (it makes sense that) you
can bind to a literal.
> $b := $c
> @a[1] = 10 ;
> print $c # prints 10
Lost you there, even ignoring the literal issue.
--
ralph
Re: Primitive Vs Object types
Michael Lazzaro wrote: On Thursday, November 7, 2002, at 06:36 AM, Austin Hastings wrote: For 'bit', the key value is (eenie, meenie, ...) '1'. From A2 we have: "Run-time properties really are associated with the object in question, which implies some amount of overhead. For that reason, intrinsic data types like C and C may or may not allow run-time properties. From E2: a C will never have attributes or promote to an object. My interpretation: A C my start as as C as long as the compiler/optimizer doesn't see any attributes/tie/bless or whatever, that would need an object. If so, it promotes to an object. More important: how big is Cbit_ar is dim(1000,1000)>. It will be 10^6 / (sizeof(int) * CHAR_BIT) + list_overhead. leo
Re: on Topic
Me writes:
> In the hope this saves Allison time, and/or
> clarifies things for me, I'll attempt some
> answers.
>
Thanks .
> > In your article at perl.com you describes
> > various ways and situations when perl
> > creates a topic and this is described as
> > perl making the following binding on my behalf:
> >
> > $_ := $some_var ; *1*
>
> Well, $_ might not be bound to a named variable
> but instead be just set to a value,
sure , I forgot , e.g.
given $x+1 {
when 2 { ... }
}
or it might
> be bound to an array cell or some other unnamed
> container.
>
>
>
> > is $_ always lexical variable.
>
> Yes.
>
>
> > Or I can have $MyPackage::_ ?
>
> You can copy or alias any value.
no, I mean is '$_' a valid name to live in package namespace ?
$main::_ = 1 ;
$::_ = 1;
our $_ ;
???
or variable with name '$_' is always implicitly "my" ??
> > also
> >
> > @a := ( $a, $b )
>
> Er, I don't think (it makes sense that) you
> can bind to a literal.
I think I meant this :
*@a := ( $a, $b )
although , to be true , I dont understand why the first version is
wrong. Do you mean that @a := expect 1 array variable and I give it
2 scalars ?
but if :
$ref = ( $a, $b ) ;
@a := $ref ;
this , probably is OK, but now changing $a or $b will not affect @a
and vice-versa.
so , anyway,
*@a := ( $a, $b )
> > $c := $b
> > @a[1] = 10 ;
> > print $c # prints 10
???
and also , one more question.
is this correct :
$x is constant = 1;
$y = 5;
$y := $x ;
$y = 1 # ERROR cannot change constant value
or in words, are (all) compile - time properties passed automatically
upon binding ?
thanks ,
arcadi .
Re: Superpositions and laziness
> Date: Thu, 07 Nov 2002 20:48:50 +1100
> From: Damian Conway <[EMAIL PROTECTED]>
>
> we could make it lazy thus:
>
> sub a_pure_func(Num $n) is lazy returns Num {
> return $n ** $n
> }
>
> which would cause any invocation of C to cache
> its arguments (probably in a closure) and return a "proxy"
> Num that carries out the computation only when the proxy is
> evaluated.
sub a_pure_func(Num $n) returns Num {
class is Num {
method FETCH { $n * $n } }.new
}
Yes? No?
Luke
Re: Superpositions and laziness
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> From: Luke Palmer <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Date: Thu, 7 Nov 2002 13:49:14 -0700 (MST)
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>
> > Date: Thu, 07 Nov 2002 20:48:50 +1100
> > From: Damian Conway <[EMAIL PROTECTED]>
> >
> > we could make it lazy thus:
> >
> > sub a_pure_func(Num $n) is lazy returns Num {
> > return $n ** $n
> > }
> >
> > which would cause any invocation of C to cache
> > its arguments (probably in a closure) and return a "proxy"
> > Num that carries out the computation only when the proxy is
> > evaluated.
>
> sub a_pure_func(Num $n) returns Num {
> class is Num {
> method FETCH { $n * $n } }.new
> }
Whoops, I mean...
sub a_pure_func(Num $n) returns Num {
class is Num {
has Num $cache;
method FETCH { $cache //= $n * $n } } }
Wow, I've never seen such a compact implementation of such a thing. I
love you, Perl 6 <3
Luke
Re: Unicode operators
At 1:27 PM -0800 11/6/02, Brad Hughes wrote: Flaviu Turean wrote: [...] 5. if you want to wait for the computing platforms before programming in p6, then there is quite a wait ahead. how about platforms which will never catch up? VMS, anyone? Not to start an OS war thread or anything, but why do people still have this mistaken impression of VMS? We have compilers and hard drives and networking and everything. We even have color monitors. Sure, we lack a decent c++ compiler, but we consider that a feature. :-) Lacking a decent C++ compiler isn't necessarily a strike against VMS--to be a strike against, there'd actually have to *be* a decent C++ compiler... -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Superpositions and laziness
Luke Palmer wrote:
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
From: Luke Palmer <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Date: Thu, 7 Nov 2002 13:49:14 -0700 (MST)
X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
Date: Thu, 07 Nov 2002 20:48:50 +1100
From: Damian Conway <[EMAIL PROTECTED]>
we could make it lazy thus:
sub a_pure_func(Num $n) is lazy returns Num {
return $n ** $n
}
which would cause any invocation of C to cache
its arguments (probably in a closure) and return a "proxy"
Num that carries out the computation only when the proxy is
evaluated.
sub a_pure_func(Num $n) returns Num {
class is Num {
method FETCH { $n * $n } }.new
}
Whoops, I mean...
sub a_pure_func(Num $n) returns Num {
class is Num {
has Num $cache;
method FETCH { $cache //= $n * $n } } }
Wow, I've never seen such a compact implementation of such a thing. I
love you, Perl 6 <3]
This is better, but it doesn't deal with STORE or does it? Nope, it
doesn't. You need to delegate to $cache.
Hmmm...
sub a_pure_func(Num a) returns Num {
class is Num {
has Num $cache is delegate;
method FETCH {$cache //= $n * $n } }.new }
Or...
sub a_pure_func(Num $a) returns Num {
class is Num (
has Num $cache;
method FETCH { .cache //= $n * $n }
method STORE(Num $x) { .cache = $x } }.new }
I think
Luke
Re: Primitive Vs Object types
At 8:29 PM +0100 11/7/02, Leopold Toetsch wrote: Michael Lazzaro wrote: On Thursday, November 7, 2002, at 06:36 AM, Austin Hastings wrote: For 'bit', the key value is (eenie, meenie, ...) '1'. From A2 we have: "Run-time properties really are associated with the object in question, which implies some amount of overhead. For that reason, intrinsic data types like C and C may or may not allow run-time properties. From E2: a C will never have attributes or promote to an object. Attributes aren't properties. Basically anything you can potentially find in a symbol table or lexical scratchpad will potentially be able to have a property attached to it. The only way that we'll be able to reasonably restrict (and optimize) the use of low-level data types is to keep them out of the symbol tables, which then makes using them in string evals and suchlike things somewhat problematic. (And not allowing properties on them will require us to throw runtime errors) It'll also make passing them in as parameters interesting, as we'd then need to construct temporary full variables that held them, which'd be somewhat interesting to deal with. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Unifying invocant and topic naming syntax
Damian:
> ["it" will be passed to about 5% of subs,
> regardless of whether the context is your
> 10 line scripts or my large modules]
If the syntax for passing "it" to a sub
remains as verbose as it currently is,
you are probably right that "it" won't
be used to achieve brevity! I think it's
a pity given that the core point of "it"
is to achieve brevity.
Why do you think your estimate of Perl 6
usage of "it" is so much lower than is
true for the standard Perl 5 functions?
Btw, can I just confirm that one can't do:
sub f ($a = ) { ... }
or
sub f (;$_ = ) { ... }
where is the upscope it and $_
is the sub's topic.
> > Can currying include the given topic?
>
> Maybe.
Naturally, I see this as another symptom
of the way upscope "it" is being treated
as a second class citizen, and that this
is leading things in the wrong direction.
> > And what about a topic placeholder:
> >
> > $foo = { print $^_ };
> >
> > such that $^_ is effectively converted
> > to an 'is given($^_)'.
>
> No, that doesn't work. The placeholder
> $^_ is entirely unrelated to $_.
Well, it is at the moment, but there is
clearly mnemonic value between $^_ and $_.
> Besides, what's wrong with:
>
> $foo = sub { print $_ } is given($_);
Compared with
$foo = sub { print $^_ };
The answer is brevity, or lack thereof.
Why bother with currying? Why bother with
the "it" concept? None of these are necessary.
They simplify code generation, but their more
general feature is enabling brevity.
--
ralph
RE: Primitive Vs Object types
Dan Sugalski wrote: > At 8:29 PM +0100 11/7/02, Leopold Toetsch wrote: > >Michael Lazzaro wrote: > >>On Thursday, November 7, 2002, at 06:36 AM, Austin Hastings wrote: > >> > >>>For 'bit', the key value is (eenie, meenie, ...) '1'. > > > >> From A2 we have: > >> > >>"Run-time properties really are associated with the object in > >>question, which implies some amount of overhead. For that reason, > >>intrinsic data types like C and C may or may not allow > >>run-time properties. > > > >From E2: a C will never have attributes or promote to an object. > > Attributes aren't properties. I thought: 'attributes' :Perl5 == 'properites' isa Perl6 Can someone point me to Perl6 definitions for both terms? -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
Re: Primitive Vs Object types
On Thu, Nov 07, 2002 at 03:56:04PM -0600, Garrett Goebel wrote:
> Dan Sugalski wrote:
> > At 8:29 PM +0100 11/7/02, Leopold Toetsch wrote:
> > >Michael Lazzaro wrote:
> > >>On Thursday, November 7, 2002, at 06:36 AM, Austin Hastings wrote:
> > >>
> > >>>For 'bit', the key value is (eenie, meenie, ...) '1'.
> > >
> > >> From A2 we have:
> > >>
> > >>"Run-time properties really are associated with the object in
> > >>question, which implies some amount of overhead. For that reason,
> > >>intrinsic data types like C and C may or may not allow
> > >>run-time properties.
> > >
> > >From E2: a C will never have attributes or promote to an object.
> >
> > Attributes aren't properties.
>
> I thought:
>
> 'attributes' :Perl5 == 'properites' isa Perl6
Yeah. Where the Apocalyses and Exegeses say "attributes" they are
referring to data members of an object:
class Foo {
has $.bar is friendly;
}
$.bar is an attribute (of Foo-ish objects), friendly is a property (of
the $.bar attribute).
> Can someone point me to Perl6 definitions for both terms?
It's probably in Michael Lazzaro's documentation somewhere ;-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
RE: Primitive Vs Object types
At 3:56 PM -0600 11/7/02, Garrett Goebel wrote: Dan Sugalski wrote: At 8:29 PM +0100 11/7/02, Leopold Toetsch wrote: >Michael Lazzaro wrote: >>On Thursday, November 7, 2002, at 06:36 AM, Austin Hastings wrote: >> >>>For 'bit', the key value is (eenie, meenie, ...) '1'. > >> From A2 we have: >> >>"Run-time properties really are associated with the object in >>question, which implies some amount of overhead. For that reason, >>intrinsic data types like C and C may or may not allow >>run-time properties. > >From E2: a C will never have attributes or promote to an object. Attributes aren't properties. I thought: 'attributes' :Perl5 == 'properites' isa Perl6 Can someone point me to Perl6 definitions for both terms? Short(ish) answer: perl 6 attributes are much like the hash entries in a perl 5 object (assuming you use a hash as your object), only the keys are fixed at class definition time, and each parent/child/grandchild class can only see its own slots in the objects. And slot names don't collide, so every class in a 47-class inheritance chain can have an attribute "Foo". perl 6 properties are more on the order of runtime notations on a variable. (Damian likes the properties-as-PostIt-note metaphor. As do I, come to think of it) Properties will be global to a variable, and queryable at runtime. Attributes are class-specific for a variable (okay, class instance specific, if you do Evil Things with multiple copies of a single base class in different legs of the inheritance tree and override the default behaviour of the engine) and not queryable at runtime without really nasty parrot assembly code. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: perl6-lang Project Management
[responding to several of the most recent posts] Let's table discussion of the details for a few days until we get the perl6-documentation list set up. Then we can dig into planning out the scope and goals of the project, and what roles various people might take. Allison
Re: Primitive Vs Object types
[Recipients list trimmed back to just the list - it was getting ridiculous.
So everyone will get only get one copy and it may take a tad longer to
get there . . .]
On 2002-11-07 at 17:07:46, Dan Sugalski wrote:
> Attributes are class-specific for a variable (okay, class instance
> specific, if you do Evil Things with multiple copies of a single base
> class in different legs of the inheritance tree and override the
> default behaviour of the engine) and not queryable at runtime without
> really nasty parrot assembly code.
You won't be able to query attributes at run-time? Even within
the class? I rather like the ability to loop through
the attributes of an object with something like this Perl5 code:
foreach my $attr (qw(foo bar baz))
{
print "$attr: $this->{$attr}\n";
}
Will something like that not be possible in Perl6?
--
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G | [EMAIL PROTECTED]
Atlanta, GA 30348 USA | +1 404 827 4754
Re: Primitive Vs Object types
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Thu, 7 Nov 2002 17:19:28 -0500
> From: "Mark J. Reed" <[EMAIL PROTECTED]>
> Content-Disposition: inline
> X-Julian-Day: 2452586.42675
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>
> [Recipients list trimmed back to just the list - it was getting ridiculous.
> So everyone will get only get one copy and it may take a tad longer to
> get there . . .]
>
> On 2002-11-07 at 17:07:46, Dan Sugalski wrote:
> > Attributes are class-specific for a variable (okay, class instance
> > specific, if you do Evil Things with multiple copies of a single base
> > class in different legs of the inheritance tree and override the
> > default behaviour of the engine) and not queryable at runtime without
> > really nasty parrot assembly code.
> You won't be able to query attributes at run-time? Even within
> the class? I rather like the ability to loop through
> the attributes of an object with something like this Perl5 code:
>
> foreach my $attr (qw(foo bar baz))
> {
> print "$attr: $this->{$attr}\n";
> }
>
> Will something like that not be possible in Perl6?
I'm afraid that statement is false for all values of "something" :)
Could you just look through the lexical scope of the object?
for $this.MY.kv -> $k, $v {
print "$k: $v\n"
}
Or would you look through the class's lexical scope and apply it to
the object?
for keys $this.class.MY {
print "$_: $this.MY{$_}\n"
}
I think one of those two is possible. (Providing the .class method
exists and DWIMs)
Luke
Re: Primitive Vs Object types
On 2002-11-07 at 15:28:14, Luke Palmer wrote:
> > From: "Mark J. Reed" <[EMAIL PROTECTED]>
> > Will something like that not be possible in Perl6?
>
> I'm afraid that statement is false for all values of "something" :)
Good point. Erratum: for "possible", read "easy". :)
> Could you just look through the lexical scope of the object?
>
> for $this.MY.kv -> $k, $v {
> print "$k: $v\n"
> }
>
> Or would you look through the class's lexical scope and apply it to
> the object?
>
> for keys $this.class.MY {
> print "$_: $this.MY{$_}\n"
> }
>
Either of those would be sufficiently "easy". Thanks.
--
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G | [EMAIL PROTECTED]
Atlanta, GA 30348 USA | +1 404 827 4754
Re: Primitive Vs Object types
On Thu, Nov 07, 2002 at 04:16:50PM -0500, Dan Sugalski wrote: : At 8:29 PM +0100 11/7/02, Leopold Toetsch wrote: : >Michael Lazzaro wrote: : > : >> : >>On Thursday, November 7, 2002, at 06:36 AM, Austin Hastings wrote: : >> : >>>For 'bit', the key value is (eenie, meenie, ...) '1'. : > : > : >> From A2 we have: : >> : >>"Run-time properties really are associated with the object in : >>question, which implies some amount of overhead. For that reason, : >>intrinsic data types like C and C may or may not allow : >>run-time properties. : > : > : >From E2: a C will never have attributes or promote to an object. : : Attributes aren't properties. : : Basically anything you can potentially find in a symbol table or : lexical scratchpad will potentially be able to have a property : attached to it. The only way that we'll be able to reasonably : restrict (and optimize) the use of low-level data types is to keep : them out of the symbol tables, which then makes using them in string : evals and suchlike things somewhat problematic. (And not allowing : properties on them will require us to throw runtime errors) It'll : also make passing them in as parameters interesting, as we'd then : need to construct temporary full variables that held them, which'd be : somewhat interesting to deal with. I don't much care about single scalar bits or ints, but I do care that an array of a million bits be represented by a million bits or so, especially in the absence of any properties. I can see ways of binding properties to a location without growing the location itself, but I think stuffing a junction of ints into a single location is somewhat problematical. As for undef, it *could* just be a property, but for efficiency it would be nice to represent it in-band for those types that can so represent it, and it ought to be possible to tell the million bit array whether or not it is willing to store undef properties off to the side. We can argue whether the default should be yes or no... Larry
Re: on Topic
On Thu, Nov 07, 2002 at 01:36:07PM -0600, Me wrote: : > is *1* _all_ that topic is about ? : : Sorta. To quote an excellent summary: : : "Topic is $_". A "real" topicalizer also sets a topicalizer scope that can be broken out of. : > also : > : > @a := ( $a, $b) : : Er, I don't think (it makes sense that) you : can bind to a literal. Well, it makes as much sense as binding it in a function parameter. In this case it'd be equivalent to @a := [ $a, $b ] That is, it's bound to a temporary. : > $b := $c : > @a[1] = 10 ; : > print $c # prints 10 No, the [...] copies values upon composing the anonymous array. Larry
Re: Unicode operators
On Nov 07, Dan Sugalski wrote: > Lacking a decent C++ compiler isn't necessarily a strike against > VMS--to be a strike against, there'd actually have to *be* a decent > C++ compiler... Doesn't VMS have a /bin/false? - Kurt
Perl 6 documentation project mailing list
Ask was fast: > Subscribe by sending mail to [EMAIL PROTECTED] > NNTP access and archives at nntp.perl.org will be available a few > hours after the first posting to the list. Let the games begin... Allison
Re: Perl 6 documentation project mailing list
Allison Randal <[EMAIL PROTECTED]> writes: > Ask was fast: > >> Subscribe by sending mail to [EMAIL PROTECTED] >> NNTP access and archives at nntp.perl.org will be available a few >> hours after the first posting to the list. > > Let the games begin... Those of us with subs to perl6-all will get this anyway, right? -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
