Re: [CVS ci] class refactoring 1 - Integer
[ From p6i ]
Patrick R. Michaud writes:
> On Fri, Dec 10, 2004 at 08:50:46PM +0100, Leopold Toetsch wrote:
> > Not quite. It gives one value if one is true or 0 (false). This is more
> > information then the perl5 implementation returns. The returned value (if
> > any) is still true but usable, if I just want one of both. Well that's
> > "logical xor" - not binary xor.
>
> Agreed. At some point this probably belongs on perl6-languages (and
> apologies if this posting to p6i is therefore inappropriate). But if
> the following hold (Perl 5):
>
> print (0 and "hello");# outputs "0"
> print ("" and "hello"); # outputs ""
> print (0 or "hello"); # outputs "hello"
> print ("" or "hello");# outputs "hello"
> print ("" or 0); # outputs "0"
> print (0 or ""); # outputs ""
> print (not("" or 0)); # outputs "1"
> print (not("a" and "b")); # outputs ""
>
> it seems like one should be able to do:
>
> print (0 xor "hello");# outputs "hello"
> print ("" xor "hello"); # outputs "hello"
> print ("hello" xor 0);# outputs "hello"
> print ("hello" xor ""); # outputs "hello"
> print ("world" xor "hello"); # outputs ""
> print (0 xor ""); # outputs "1"
> print ("" xor 0); # outputs "1"
>
> Just as C returns its first non-false argument, the interpretation
> of C would be that it returns its single non-false argument, or 1 if
> both (all?) arguments logically evaluate to false.
Well, IAAL. :-)
In particular, xor is analogous, operatorwise, to the junctive one().
one() represents its single true value when it evaluates to true in
conditionals:
my $smin = one(3,6,9,12) < 5;
So it seems logical that xor do the same. I don't see any loss of
generality in doing so, and you're keeping around more information.
For the PMC variant, it seems like returning *the* true PMC is the
correct thing to do, because the definiton of the canonical "true"
differs from language to language. Parrot has a canonical false.
Luke
Re: Undeclared attributes
Dave Whipp wrote:
Attributes are declared with C, but also have a unique signil
C<$.>. So is it strictly necessary to declare them? Or rather, is it
Cly necessary -- i.e. is the following legal?
no strict;
class Foo {
method bar {
say $.a++
}
}
For the standard layout, I'd think it'd be good to declare the
attributes, but perhaps not necessary. An object of class C, IIRC, will
just be an object in the parrot sense; doing an C
will cause the attribute to be added to all other objects of that class,
and to all objects that "is" or "does" that class; That might involve
a whole lot of work.
But maybe you are asking if Perl6 can intuit that you implied an
unwritten C But it could be a C or C or
C.
BTW, should we be able to write pragmas like this:
class Foo isnt strict{...}
or
class Foo isn't strict{...}
--abhijit
Re: S05 question
On Thu, Dec 09, 2004 at 11:18:34AM -0800, Larry Wall wrote:
> On Wed, Dec 08, 2004 at 08:24:20PM -0800, Ashley Winters wrote:
> : I'm still going to prefer using :=, simply as a good programming
> : practice. My mind sees a big difference between building a parse-tree
> : object and just grepping for some word I want in a string. Within a
> : rule{} block, there is no place except the rule object to keep your
> : data (hypothetically -- haha), so it makes sense to have everything
> : capture unless otherwise specified. There's no such limitation in a
> : regular code block, so I don't see the need.
>
> Since regex results are lexically scoped in Perl 6, in a regular
> code block we can do static analysis and determine whether there's
> any possibility that $ is referenced at all, and optimize it
> away in many cases, if it turns out to be high overhead. But as Patrick
> points out, so far capture seems pretty cheap.
It might turn out to be worth optimizing only when ALL of the
"capture" blocks are unused - the saving from avoiding setup
costs together with avoiding the (too small to be a bother
by themselves) incremental costs, might be significantwhen
taken together.
--
Undeclared attributes
Attributes are declared with C, but also have a unique signil
C<$.>. So is it strictly necessary to declare them? Or rather, is it
Cly necessary -- i.e. is the following legal?
no strict;
class Foo {
method bar {
say $.a++
}
}
Classes with several, mostly unused, attributes
Consider a class (e.g., the hypothetical Geometry::Triangle) that can
have several attributes (side1, side2, side3, angle1, ang_bisector1,
side_bisector, altitude1 and so forth), most of which will not be
needed for most instances of Geometry::Triangle.
I know how this can be done in P5. Using the layout "Hash" things are
easy. How can P6 deal with this, without allocating too much memory to
things that'd never get used? The layout "P6Hash" could come to the
rescue, but there is still the issue of syntax:
what exactly does C do? IIRC, in the P6Opaque layout,
every instance of the class would have space the size of a PMC allocated
for it. This behavior is not needed for P6Hash, and it should just leave
attributes alone until they are assigned to (where defaults are also
"assigns").
In which case, maybe for that layout we can get away without declaring
all attributes, perhaps? (Since the declaration does nothing except help
the parser).
I was thinking whether we could do something like this:
class Triangle is layout does autovivify{
method calculate_bisectors { $.bisector1 = ...;
# $.bisector1 autovivifies
}
}
where it is an error without the autovivify, and only P6Hash supports
autovivification.
--abhijit
Re: iterators and functions (and lists)
Michele Dondi writes: > On Mon, 6 Dec 2004, Larry Wall wrote: > > >to return an infinite list, or even > > > > return 0..., 0...; > > > >to return a surreal list. Either of those may be bound to an array > > Hope not to bark something utterly stupid, but... if one iterates over > such a list, may it be that on the first C one really starts over > from the "second 0"? Well, unless some adverb is given to the point that > one really has to > > last :everything # or somesuch... Balancing the mathematical preposterousness and the actual usefulness of such a thing, I really don't think that's going to fly. From the finite world, Ï and Ï*2 look exactly the same, and I'm pretty sure that, cool as Perl is, it's still in the finite world. In particular, calling C and having the loop not exit is more than a little weird. Whatever you can do with that, you could do with a sligh redesign: return [ 0... ], [ 0... ]; And then your C is a C for a nested loop. Luke
Re: state vs my
On Sat, 4 Dec 2004 22:03:19 -0800, Larry Wall <[EMAIL PROTECTED]> wrote:
On Sun, Dec 05, 2004 at 02:15:51AM +0300, Alexey Trofimenko wrote:
: oh! that it. I've found example which could make it clear to me
:
: sub test {
: return sub {
: for 1..3 {
:state $var = 1;
:print $var++
: }
: }
: }
:
: $a = test; $a() for 1..3; print ';'
: $b = test; $b() for 1..3;
:
: that could print, for different possible definitions of "state":
: 1) 123123123;123123123
: 2) 123456789;123456789
: 3) 123456789;101112131415161718
:
: looks like you meant third(!) variant.. but it doesn't make any sense
: for me.
I don't know how you even get the third variant. I think it should be 2,
though I see how you'd get 1 if you think a loop clones every time
through.
third variant is what we get if we replace C with perl5 "my $var if
0" here (not exactly, because $var start value would be undef in that
case).
Certainly that one doesn't, since it doesn't refer to any external
lexicals.
Perhaps statehood should be limited to "official" subs just like
"return" is.
they must be limited. It would be really strange if
sub test {
for 1..3 {
state $var = 1;
print $var++
}
}
test();test();
and
sub test {
my $a;
for 1..3 {
do_something_with($a);
state $var = 1;
print $var++
}
}
test();test();
would print different results.
But actually I would prefer if state somehow could be made to work other
way, even if closure isn't cloned. I mean, first variant, mentioned at top
of the message. Then we could use state vars in things like:
# I know that _this_ particular task could be solved better
# I'm not good in examplification.
%hash = map {state $k=1; $_ => $k++ } @array;
and always get our keys numbered from 1. And one still get behaviour(2) if
state declaration is at start of subroutine.
(Hmm, but I can't figure if it is possible )
This applies to FIRST {...} blocks too.
for 1..10 {
for 1..3 {
FIRST {...}
...
}
}
I'd expect that FIRST would be fired 10 times, not only once, because
FIRST looks here just as a mere funny loop control structure.
and of course I don't want it to happen once here, and 10 times there,
depending on such a subtle thing as appearance of outer lexical variables
in inner block. hmm.. but I don't want unnecessary cloning either, if it'd
slow down my program. I have a cake, please show me where to bite:)
Re: iterators and functions (and lists)
Michele Dondi wrote: On Sun, 5 Dec 2004, Matthew Walton wrote: At least we had the sense to call them subroutines instead of functions. Of course, that also upset the mathematicians, who wanted to call them functions anyway. Go figure. That might be because the mathematicians haven't heard of a variant of a function which is allowed to have side effects yet. More or less BS for, from the point of view of a mathematitian (i.e. from the point of view of Mathematics), you still have "true functions", they're either not just the *same* function each time, or the same function with some arguments/parameters set to different values (that in the implementation are passed implicitly rather than explicitly), which are fundamentally the same thing after all (up to an isomorphism, that is). I wasn't intending to be taken seriously with that comment. I hope everyone realised that...
Re: iterators and functions (and lists)
On Mon, 6 Dec 2004, Larry Wall wrote: to return an infinite list, or even return 0..., 0...; to return a surreal list. Either of those may be bound to an array Hope not to bark something utterly stupid, but... if one iterates over such a list, may it be that on the first C one really starts over from the "second 0"? Well, unless some adverb is given to the point that one really has to last :everything # or somesuch... Michele -- Some time ago,I managed to wipe out almost all of /usr/bin while doing some cleaning (don't drink and root...:-) - Predrag Ivanovic in CRUX mailing list
Re: specifying the key Type for a Hash
On Mon, 6 Dec 2004, Luke Palmer wrote: Well, there's always "domain" and "range", if we want to be mathematical. [snip] What you want here is "domain" and "codomain". Which leads me to believe that you don't want either. For the record, in most connections "range" would be just as good. Indeed "codomain", especially from the algebraic/categorial point of view is sounds somehow better. Michele -- [ standard bull-shit snipped ] Your friend, Nathan the Great Age 11 The best of your postings is the backside. Please let the front also blank in the future. - Rainer Rosenthal in sci.math, "Re: Cantor Paradox :-)"
Re: iterators and functions (and lists)
On Sun, 5 Dec 2004, Matthew Walton wrote: At least we had the sense to call them subroutines instead of functions. Of course, that also upset the mathematicians, who wanted to call them functions anyway. Go figure. That might be because the mathematicians haven't heard of a variant of a function which is allowed to have side effects yet. More or less BS for, from the point of view of a mathematitian (i.e. from the point of view of Mathematics), you still have "true functions", they're either not just the *same* function each time, or the same function with some arguments/parameters set to different values (that in the implementation are passed implicitly rather than explicitly), which are fundamentally the same thing after all (up to an isomorphism, that is). Michele -- I find the line "I am not pestering anybody, I am asking questions on usenet. That's what usenet is for." a classic. It's like "I am not talking to you, I am just opening and closing my mouth while standing close to you. That's what a mouth is for." - David Kastrup, on comp.text.tex (slightly edited)
Re: state vs my
On Fri, 3 Dec 2004, Brent 'Dax' Royal-Gordon wrote: Larry Wall <[EMAIL PROTECTED]> wrote: So optimizing to a state variable won't necessarily help your loop overhead, but it could help your subroutine overhead, at least in Perl 5, if Perl 5 had state variables. Best you can do in Perl 5 is an "our" variable with an obscure name. my $x if 0; I know it's *going* away, but it hasn't *gone* away yet. Personally I'm glad this is going away. I'm not bothered by the caveats of the docs: it's the construct itself that somehow strikes me as "innatural", to the point that I've never been bitten in the neck by using it inadvertently for I would have never ever though about doing so... In fact a declaration is fundamentally a way to introduce an "object" to be used subsequently, and the fact that it can be used also in the same statement in which it is declared doesn't make things really different. So how can I *declare* something depending on a condition?!? I can branch over a condition to execute either one block or another *within* which things can be declared or some such. Not the other way round... Michele -- A question out of curiousity: who is this Green of Green's functions? Is he the same person of Green's theorem? :) Yes. He was also an early environmentalist; hence the current phrases "green" this and "green" that... - David C. Ullrich on sci.math, thread "Who is Green?"
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Fri, 3 Dec 2004, Larry Wall wrote:
On Fri, Dec 03, 2004 at 06:43:05PM +, Herbert Snorrason wrote:
: This whole issue kind of makes me go 'ugh'. One of the things I like
: best about Perl is the amazing simplicity of the <> input construct.
Hmm.
while (<>) {...}
for .lines {...}
Looks like a wash to me.
Partly it does. The point is that not only the <> is simple, but that it
is also visually distinctive, which is important IMHO.
Obviously the new proposal of unary C<=> is just as good from this point
of view...
: Replacing that with something that not only is object oriented, but on
: top of that also LOOKS object oriented is bound to be a loss. It's
: going to be that bit longer to write, and not the least bit easier to
: understand.
Really? I dare you to show those two lines to any random
computer-literate but non-Perl-speaking stranger and see which one
they understand better.
Of course they'd understand better the latter, but I think that there's a
limit to non-Perl-speaking-people-friendship. After all this may be useful
for learning perl, but learning it to a good degree would always involve
getting acquainted with quite a lot of typical idioms, so this does not
make much of a point IMHO, provided that when a typical user becomes
familiar with those idioms he can perceive (i) how good they look in
source code (ii) how useful they result in practice.
It's all cargo cult at that level anyway, so whether it looks OO or not
is really completely immaterial to its usability.
Indeed it's not *purely* a matter of "looking OO", but of "looking yet
another more-or-less alphabetic string" (yes, even with a prepended point:
it's just not as markedly distinctive!). As I said, <> is deeply etched in
Perl programmers' cortex as an input operator. In other words it may well
be cargo cult, but not in a totally negative acceptation: I mean... till
it works, and works well as it currently does!
And I don't buy the nuclear blackmail argument either. I'll start
worrying about people switching to Python and Ruby when those languages
get a clue about how natural languages work. As far as I know, there's
OTOH, as a side note, but not a totally unrelated one, I guess, one should
pay some attention not to exaggerate following natural languages
principles in designing programming languages: granted, I appreciate their
pervasiveness in (current) perl and indeed probably this is one of the
reasons I love it. But I think that there are some natural limits to this
as well: AFAIK any attempt to overcome them was basically a failure. We
want the *right* mixture of conciseness, intutivity, clarity instead. In
this sense a construct like
while (<>) {
...
}
really doesn't resamble any natural language construct as far as I can
see, but indeed it's an idiom that perl programmers easily become familiar
with and like to use... well, I think so!
Michele
--
I hold a square measuring 10x10 metres away from a person who is standing
100 metres away.
I ask them to shoot the square with a high-accuracy gun.
Don't stand there holding the square when they are shooting...
- Robert Israel in sci.math, "Re: Scaling"
Re: xx Inf
On Fri, 3 Dec 2004, Larry Wall wrote: On Sat, Dec 04, 2004 at 01:11:30AM +0100, Juerd wrote: : What happens to the flip flop operator? Will .. in scalar context remain : the same? I don't think so. It's definitely a candidate for a longer Huffmanization simply in terms of frequency of use. On top of which, almost no Perl 5 programmers even know what it does. Plus it's Well, I have the vague feeling that you may have some more experience with Perl than I do, however such a claim seems a bit exaggerate to me. For example I do know what it does and even though I consider myself to be at most an advanced beginner rather than an expert, I think that I use it correctly and to great advantage, when I do use it, that is... For sure it can't be just me!! Michele -- DAX ODIA ANCORA - Scritta su diversi muri milanesi
