Re: In defense of zero-indexed arrays.
On 05/12/02 02:45 -0800, Michael G Schwern wrote: I'm going to ask something that's probably going to launch off into a long, silly thread. But I'm really curious what the results will be so I'll ask it anyway. Think of it as an experiment. So here's your essay topic: Explain how having indexes (arrays, substr, etc...) in Perl 6 start at 0 will benefit most users. Do not invoke legacy. [1] With languages like Perl that have negative subscripts, using a zero base gives continuity. @INC[-2..2] should continue to DWIM. Cheers, Brian
RE: Stringification of references and objects.
Joseph F. Ryan:
# Why? Isn't the pretty form more generally useful?
#
#
# I don't think so; I'd think it to be annoying to have type
# more code in order to specify a more cocise form; if I need
# to dump a structure, I'd prefer to do it manually.
I think it's useful to be able to say @array.str() and $arrayref.str()
and get the same result. And since we already know what @array.str will
do (essentially what @array does in Perl 5), that suggests that
$arrayref.str() will do the same.
# method str() {
# #Unnamed invocant means you need $_, right?
# return $_.class() ~ ($_.id());
# }
#
# (where id() returns a uniquely identifying integer, usually the
# address).
#
#
# Objects aren't references anymore, are they? So I don't
# think it is apporpriate for an object to stringify with its id.
To tell you the truth, I don't consider arrayrefs references anymore.
They're just Array objects that don't happen to be in @whatever symbols.
I don't know if this is the official view, but that fits my brain
better.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible.
--Ayn Rand, explaining how today's philosophies came to be
Re: Stringification of references and objects.
Brent Dax wrote To tell you the truth, I don't consider arrayrefs references anymore. They're just Array objects that don't happen to be in @whatever symbols. I don't know if this is the official view, but that fits my brain better. So you're saying that classes should stringify to a pretty-print of their public members?
Re: Usage of \[oxdb] (was Re: String Literals, take 2)
On 12/05/2002 12:18 PM, Michael Lazzaro wrote: On Thursday, December 5, 2002, at 02:11 AM, James Mastros wrote: On 12/04/2002 3:21 PM, Larry Wall wrote: \x and \o are then just shortcuts. Can we please also have \0 as a shortcut for \0x0? \0 in addition to \x, meaning the same thing? I think that would get us back to where we were with octal, wouldn't it? I'm not real keen on leading zero meaning anything, personally... :-P You misinterpret. I meant \0 meaning the same as \c[NUL], IE the same as chr(0), a null character. (I suppse I should have said \0x[0].) Which means that the only way to get a string with a literal 0xFF byte in it is with qq:u1[\xFF]? (Larry, I don't know that this has been mentioned before: is that right?) chr:u1(0xFF) might do it too, but we're getting ahead of ourselves. Hmm... does this matter? Sorry. It does, in fact, not matter... momentarly stopped thinking in terms of utf8 encoding being a completly transparent process.
Re: purge: opposite of grep
On Fri, 6 Dec 2002, Damian Conway wrote: The selector block/closure would, naturally, be called in Cint context each time, so (again, as Larry pointed out) a boolean function would naturally classify into two arrays. Though it might at first be a little counterintuitive to have to write: OK, but I would assert that the false/true classification is going to be the more common case, not classify by index position, and that furthermore there will be a lot of situations where the false/true value may be any number, not just 1 or 0. For example, suppose I want to separate a list of people into people who have never donated money and those who have. Assuming that each person object has a donations property which is an array reference, I would want to classify them in this manner: (@nevers, @donors) := classify($_-[donations]) @people; According to the Cint model, that would give me people who have donated zero times, and people who have donated once, and the people who have donated more than once would be lost. Now, of course you can force the dontations into a boolean context, but, frankly, I think If we force people to always remember to force boolean context, just to preserve the (IMHO) unusual case of classifying by integer, we're, on balance, making more work for the world. Ergo, I suggest we simply have a separate command for the false/true situation: (@nevers, @donors) := falsetrue($_-[donations]) @people; (Yes, falsetrue is a stupid name, please replace with something better.) -miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Quick translation wanted
Is it clear how attributes accessors on objects are going to work yet?
I need to say something along the lines of:
sub new {
my $class = shift;
my ($name, $age) = @_;
bless {
name = $name,
age = $age
}, $class;
}
sub age { my $self=shift; $self-{age} }
--
They laughed at Columbus, they laughed at Fulton, they laughed at the
Wright brothers. But they also laughed at Bozo the Clown.
-- Carl Sagan
Re: Quick translation wanted
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Sender: [EMAIL PROTECTED]
From: Simon Cozens [EMAIL PROTECTED]
Date: 06 Dec 2002 14:54:43 +
Organization: Bethnal Green is PEOPLE!
X-Posted-By: 217.204.174.162
Is it clear how attributes accessors on objects are going to work yet?
I need to say something along the lines of:
sub new {
my $class = shift;
my ($name, $age) = @_;
bless {
name = $name,
age = $age
}, $class;
}
sub age { my $self=shift; $self-{age} }
There's nothing decided on how constructors work yet, so I'll use a
fill-in syntax.
class Person {
has $.name is private;# No accessor generated
has $.age;
method new($n, $a) {
($.name, $.age) = ($n, $a);
return bless; # bless me = myself
}
}
Re: purge: opposite of grep
On Fri, Dec 06, 2002 at 09:33:14AM -0500, Miko O'Sullivan wrote: For example, suppose I want to separate a list of people into people who have never donated money and those who have. Assuming that each person object has a donations property which is an array reference, I would want to classify them in this manner: (@nevers, @donors) := classify($_-[donations]) @people; According to the Cint model, that would give me people who have donated zero times, and people who have donated once, and the people who have donated more than once would be lost. Then turn donations into a boolean. (@donors, @nevers) := classify(!$_-[donations]) @people; I don't think there is the need to bloat the langauge with every special case we can think of. Graham.
Re: String Literals, take 3
On Fri, 6 Dec 2002, Joseph F. Ryan wrote:
What's wrong with single quoted here-docs?
What's wrong is that the documentation team is trying to allow \qq[]
there too, contradicting their own assertion that backslashes are not
special in that context.
Don't forget that the backslash is already special in
non-interpolating strings; I don't think that adding a single
special case will make things too confusing.
What if \q[] was allowed in interpolated strings, but not in
non-interpolated strings. Then I'm happy with that non-interpolated
strings really don't interpolate, and you might be happy because it would
only make sense to do one level of nesting. ie, you cannot embed \qq[]
inside \q[]. Or you could do $(''), which is the same number of
characters as \qq[], and doesn't require introducing
yet-another-new-rule-to-an-already-too-complicated-escaping-system.
I think \qq[] is the much more useful of the two, so
that really doesn't help much.
Oh well, I'm being overly-speculative above, which I shouldn't do on this
list, but I was wondering if compromise was possible. Changing the
behavior of backslashes and balanced delimiters is also speculative.
The current behavior in perl5 is that only two sequences are special in
non-interpolated strings
\\ -- \
\delim -- delim
delim can be either the opening or closing delimiter when they are
balanced. So you CAN backslash them, but I don't HAVE to.
Larry has added \qq[] and \q[], so \q is now special. (Are \qw[] and
\qx[] in? qw doesn't make sense, and qx might be insecure.)
I would really appreciate a ruling from the design team before we change
non-interpolative semantics regarding:
1) the interpretation of \anything-else,
PRO: it makes backslash behavior consistent
CON: the perl5 behavior is as unobtrusive as possible
2) requiring balanced delimiters to be escaped,
PRO: it's consistent with non-balanced delimiter requirements
CON: you already can; don't force it those who don't want it
3) allowing \qq[] in single-quoted here-docs.
PRO: it's consistent with single-quotes
CON: it contradicts the assertion that backslashes are not special in
single quoted here-docs
we need a quoting mechanism where NOTHING is special
(Those are ordered from least to most offensive, BTW.)
~ John Williams
Re: Stringification of references and objects.
On Friday, December 6, 2002, at 04:28 AM, Joseph F. Ryan wrote: Brent Dax wrote To tell you the truth, I don't consider arrayrefs references anymore. They're just Array objects that don't happen to be in @whatever symbols. I don't know if this is the official view, but that fits my brain better. So you're saying that classes should stringify to a pretty-print of their public members? How about something like what Ruby's irb does? % irb irb(main):001:0 class Foo irb(main):002:1def initialize irb(main):003:2 @a, @b, @c = 1, 2, 3 irb(main):004:2end irb(main):005:1 end nil irb(main):006:0 Foo.new #Foo:0x2767a4 @c=3, @b=2, @a=1 irb(main):007:0
RE: Stringification of references and objects.
Joseph F. Ryan:
# Brent Dax wrote
#
# To tell you the truth, I don't consider arrayrefs references
# anymore.
# They're just Array objects that don't happen to be in @whatever
# symbols. I don't know if this is the official view, but that fits my
# brain better.
#
#
# So you're saying that classes should stringify to a
# pretty-print of their public members?
No, because that wouldn't reveal enough for an equality check. At the
same time, however, exposing private members would be wrong, especially
since editing the string and creating a new instance from it would allow
the user to manipulate private members.
What I'm saying is that .str and .identity (for lack of a better name)
are identical in Object, but classes should feel free to override .str
if they have a better WTDI. The built-in classes (Array, Hash, etc.)
should override .str to yield their members in some format (probably
influenced by properties).
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible.
--Ayn Rand, explaining how today's philosophies came to be
Re: purge: opposite of grep
On Thursday, December 5, 2002, at 07:55 PM, Damian Conway wrote:
equally. The built-in would actually be doing classification of the
elements of the list, so it ought to be called Cclassify.
I worry that Cclassify sounds too much like something class-related,
and would confuse people. What about Carrange or something? Decent
thesaurus entries for separate include:
assign, classify, comb, compartmentalize, discriminate, distribute,
group, order, segregate, sift, winnow, amputate, cut, dismember,
excise, lop, disunite, divorce, estrange, part, wean, detach,
disconnect, disengage, dissociate, extract, isolate, part, steal, take,
uncouple, withdraw
Some of those might be appropriate (or just amusing). :-)
The selector block/closure would, naturally, be called in Cint
context each time, so (again, as Larry pointed out) a boolean
function would naturally classify into two arrays. Though it
How would you do something like:
(@foo,@bar,@zap) := classify { /foo/ ;; /bar/ ;; /zap/ } @source;
I was more hoping for a Cfor or Cgiven derivative that would
provide a series of 'stream'-like tests, not just one test with N
answers. Something that was a shorthand for the obvious but somewhat
tedious Cgiven counterpart. (If @source had an entry 'foobar', we
could debate whether that should go in one destination stream or two.)
Especially since you then get your purge/vrep/antigrep for free:
I don't think we need a separate func either, but if we're gonna have a
purge/vrep/antigrep, can someone _please_ think of a better name for
it? purge clearly needs an inverse called binge, vrep sounds
like, well, UNIX, and antigrep sounds like something I put in my car
to avoid it grepping when I start it on cold mornings.
Even just ngrep sounds better to me. :-|
MikeL
Re: Stringification of references and objects.
On Friday, December 6, 2002, at 01:28 AM, Joseph F. Ryan wrote: Array(0x1245AB) Personally, I like this format. It's succinct, informative, and tells you enough to do identity testing. I like it too, but I thought everyone else hated it :) I think people like it fine, but many people don't want it to be the default stringification. Like I said in an earlier thread, the problem is that there's stringification for output purposes and stringification for debugging purposes, but we have to chose one or the other to be the default. I'd rather the debugging one _not_ be the default, personally, because I imagine the other usage is more common. An obvious counterproposal would be to say that references are invisible to stringification (e.g. it stringifies to whatever its contents stringify to). This would seem to be in keeping with the the spirit of arrayref/array transparentness, etc. So you're saying that classes should stringify to a pretty-print of their public members? No, the AS_STRING (or str(), or whatever) is definitely the way to go. We pretty much _have_ to do it via a method. Brent Dax wrote: What I'm saying is that .str and .identity (for lack of a better name) are identical in Object, but classes should feel free to override .str if they have a better WTDI. The built-in classes (Array, Hash, etc.) should override .str to yield their members in some format (probably influenced by properties). I like this a lot, personally. MikeL
Re: purge: opposite of grep
Michael Lazzaro wrote: I worry that C sounds too much like something class-related, and would confuse people. What about C or something? Decent thesaurus entries for include: assign, classify, comb, compartmentalize, discriminate, distribute, group, order, segregate, sift, winnow, amputate, cut, dismember, excise, lop, disunite, divorce, estrange, part, wean, detach, disconnect, disengage, dissociate, extract, isolate, part, steal, take, uncouple, withdraw designate? -- Tim
Re: Quick translation wanted
On Fri, Dec 06, 2002 at 08:44:23AM -0700, Luke Palmer wrote:
: Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
: Sender: [EMAIL PROTECTED]
: From: Simon Cozens [EMAIL PROTECTED]
: Date: 06 Dec 2002 14:54:43 +
: Organization: Bethnal Green is PEOPLE!
: X-Posted-By: 217.204.174.162
:
:
: Is it clear how attributes accessors on objects are going to work yet?
: I need to say something along the lines of:
:
: sub new {
: my $class = shift;
: my ($name, $age) = @_;
:bless {
: name = $name,
: age = $age
:}, $class;
: }
:
: sub age { my $self=shift; $self-{age} }
:
:
: There's nothing decided on how constructors work yet, so I'll use a
: fill-in syntax.
:
: class Person {
: has $.name is private;# No accessor generated
: has $.age;
Attributes are probably private by default. Methods are public
by default.
: method new($n, $a) {
: ($.name, $.age) = ($n, $a);
: return bless; # bless me = myself
: }
: }
That would need to be a .bless, since bless is not longer a
builtin, but a class method. So I'd make it:
class Person {
has $.name;
has $.age is public;
method new($n, $a) {
($.name, $.age) = ($n, $a);
return .bless;
}
}
which is short for something like:
class Person {
has $.name;
has $.age;
method new($class: $n, $a) {
($.name, $.age) = ($n, $a);
return $class.bless;
}
method age () is rw {
return $.age;
}
}
There may well be a property on a class that makes all its attributes
public by default, so it acts more like a struct in C++.
As for constructor syntax, I suppose we might make use of the $. notation
like this:
method new($.name, $.age) {
return $class.bless;
}
and it would be assumed that those args go straight into the object. We
also have to thrash out the difference between new and init. An
init() call might occur within a bless, in which case you might just
write
method init($.name, $.age) {...}
Maybe the default initializer is
method init($.name = undef, $.age = undef, *@extras) {...}
So we might actually end up with a constructor calls looking like
$class.bless(name = $me, rank = low, serial = 12345);
Named parameters tend to work a lot better than positional for constructors,
especially if the parameters intended for a different initializer can be
ignored.
But this is all Apo 12, so still highly speculative...
Larry
Re: purge: opposite of grep
Michael said:
I worry that Cclassify sounds too much like
something class-related
'Classify' also seems wrong if some items are
thrown away. I like 'part':
(@foo,@bar) := part { ... } @source;
Headed off in another direction, having a sub
distribute its results like this reminds me of:
... - ...
Can arrays on the rhs of a - ever mean
something useful?
--
ralph
Re: Quick translation wanted
Date: Fri, 06 Dec 2002 11:15:20 -0800
From: Larry Wall [EMAIL PROTECTED]
As for constructor syntax, I suppose we might make use of the $. notation
like this:
method new($.name, $.age) {
return $class.bless;
}
Come to think of it, new is a class method, not an object method. How
is that specified again? Is there going to be sugar to blur that
distinction for constructors?
Luke
Re: Quick translation wanted
On Fri, Dec 06, 2002 at 12:27:31PM -0700, Luke Palmer wrote:
: Date: Fri, 06 Dec 2002 11:15:20 -0800
: From: Larry Wall [EMAIL PROTECTED]
:
: As for constructor syntax, I suppose we might make use of the $. notation
: like this:
:
: method new($.name, $.age) {
: return $class.bless;
: }
:
: Come to think of it, new is a class method, not an object method. How
: is that specified again? Is there going to be sugar to blur that
: distinction for constructors?
You'll not that $class was declared typeless, so it doesn't matter if it was
actually a class or an object of that class.
Actually, that last example was wrong--it should have been
method new($.name, $.age) {
return .bless;
}
or
method new($class: $.name, $.age) {
return $class.bless;
}
But in either case, if $class is untyped, it can work with either cloning
or class-based constructors.
Larry
Re: String Literals, take 3
Date: Fri, 6 Dec 2002 10:16:20 -0700 (MST) From: John Williams [EMAIL PROTECTED] 2) requiring balanced delimiters to be escaped, PRO: it's consistent with non-balanced delimiter requirements CON: you already can; don't force it those who don't want it I'll say no, agreeing with the CON. 3) allowing \qq[] in single-quoted here-docs. PRO: it's consistent with single-quotes CON: it contradicts the assertion that backslashes are not special in single quoted here-docs I'd say no here, which is consistent with Perl 5. My opinion basically agrees with Perl 5: I've never had a problem with those quoting rules. OTOH, I've never had to deal with localization. In single-quoted heredocs, _nothing_ should be special. When I'm writing a P::RD grammar, I don't want to worry about doubling my backslashes, which might already be doubled. is never pretty. If there is a single backslashed construct, then backslashes must be doubled, which stinks. we need a quoting mechanism where NOTHING is special I agree one-hundapacent! Luke
Re: Stringification of references and objects.
On Fri, Dec 06, 2002 at 10:40:18AM -0500, Dan Sugalski wrote:
: If an aggregate and a reference to an aggregate are going to behave
: the same, which is what Larry's indicated in the past, then
: stringifying a reference should be the same as stringifying its
: referent.
This is a bit of an oversimplification. $foo and @foo do not always
behave the same, even if $foo and @foo refer to the same array object.
In particular, $foo doesn't behave like @foo in a list context.
Scalars must continue to behave like scalars in list context, even
if they're internally composite. As in Perl 5, if you say
for $foo {...}
the sub only gets one argument, the array ref, but if you say
for @foo {...}
or
for @$foo {...}
you get all of the elements.
But it's probably fair to say that $foo and @foo always behave
identically in a scalar context.
We may, in fact, have to deprecate the term list context and replace
it with something like flattening context, since we can have lists
of scalars that are in some sense in a list context but that aren't
in a flattening context:
my ($a,@b,%c) := (@a,$b,%c);
But flattening is a lousy word. It's really more of a variadic
context, but that's no improvement.
At the moment I can't think of anything better than splat context...
Larry
Re: String Literals, take 3
On Fri, Dec 06, 2002 at 10:16:20AM -0700, John Williams wrote:
: On Fri, 6 Dec 2002, Joseph F. Ryan wrote:
:
: What's wrong with single quoted here-docs?
:
: What's wrong is that the documentation team is trying to allow \qq[]
: there too, contradicting their own assertion that backslashes are not
: special in that context.
Ahem. If you go back and look again, you'll see that I'm the one
who contradicted the assertion...
: Don't forget that the backslash is already special in
: non-interpolating strings; I don't think that adding a single
: special case will make things too confusing.
:
: What if \q[] was allowed in interpolated strings, but not in
: non-interpolated strings. Then I'm happy with that non-interpolated
: strings really don't interpolate, and you might be happy because it would
: only make sense to do one level of nesting. ie, you cannot embed \qq[]
: inside \q[]. Or you could do $(''), which is the same number of
: characters as \qq[], and doesn't require introducing
: yet-another-new-rule-to-an-already-too-complicated-escaping-system.
:
: I think \qq[] is the much more useful of the two, so
: that really doesn't help much.
:
: Oh well, I'm being overly-speculative above, which I shouldn't do on this
: list, but I was wondering if compromise was possible. Changing the
: behavior of backslashes and balanced delimiters is also speculative.
:
: The current behavior in perl5 is that only two sequences are special in
: non-interpolated strings
:
:\\ -- \
:\delim -- delim
:
: delim can be either the opening or closing delimiter when they are
: balanced. So you CAN backslash them, but I don't HAVE to.
:
: Larry has added \qq[] and \q[], so \q is now special. (Are \qw[] and
: \qx[] in? qw doesn't make sense, and qx might be insecure.)
That's not what I said. I said that \qq[ is special. Don't go
chopping my bracket off--I intend it to be required. Also, there's
no reason to allow \q[] inside single quotes. The others are rare
enough that they could be put inside \qq[].
In fact, if you want it all consistent, we could say that the *only*
way to put anything non-verbatim into any single-quoted string is
with \qq[]. So instead of '\\' you'd say '\qq[\\]' and instead of '\''
you'd say '\qq[']'. (And no, the latter doesn't actually require a
backslash before the '. If you think it does, you're still thinking
of a two-pass lexer like Perl 5. Perl 6 will have a one-pass lexer,
and the only delimiter it's looking for at the time it sees the quote
is actually a right bracket.)
On the other hand, people are likely to expect \\ and \' to continue working
as they currently do in ordinary single quoted strings. We could go with
the stricter rule for just single-quoted here docs, I suppose.
: I would really appreciate a ruling from the design team before we change
: non-interpolative semantics regarding:
:
: 1) the interpretation of \anything-else,
:PRO: it makes backslash behavior consistent
:CON: the perl5 behavior is as unobtrusive as possible
Well, no, I don't think \\ and \' are really as unobtrusive as possible...
: 2) requiring balanced delimiters to be escaped,
:PRO: it's consistent with non-balanced delimiter requirements
:CON: you already can; don't force it those who don't want it
See above about one-pass lexer. Balanced delimiters generally need no
backslashing unless they're a literal outside of any other bracketing
construct.
: 3) allowing \qq[] in single-quoted here-docs.
:PRO: it's consistent with single-quotes
:CON: it contradicts the assertion that backslashes are not special in
: single quoted here-docs
: we need a quoting mechanism where NOTHING is special
:
: (Those are ordered from least to most offensive, BTW.)
Then paint me most offensive, by all means. :-)
Larry
Re: In defense of zero-indexed arrays.
On Thu, Dec 05, 2002 at 02:45:39AM -0800, Michael G Schwern wrote: Explain how having indexes (arrays, substr, etc...) in Perl 6 start at 0 will benefit most users. Do not invoke legacy. [1] Answer 1: Ignoring legacy, it won't. Answer 2: Because C uses 0-based indexes, Parrot is written in C, and it would be just painful to switch back and forth when working on different layers of the system. (Not a legacy argument, unless you want to argue that Parrot is a legacy system.) Answer 3: In a lower-level language than Perl, an array is usually a block of memory divided into array elements. The index is the offset from the start of the array. In languages like C which allow pointer arithmetic, it makes sense for the array index to be the element offset, to allow a[i] to be equal to *(a + i). Higher level languages should follow this convention, for consistency. (Again, not a legacy argument, since it offers a first-principles rationale for 0-based arrays in certain contexts.) - Damien
Re: In defense of zero-indexed arrays.
2002-12-05 10:45:39, Michael G Schwern [EMAIL PROTECTED] wrote: I'm going to ask something that's probably going to launch off into a long, silly thread. But I'm really curious what the results will be so I'll ask it anyway. Think of it as an experiment. So here's your essay topic: Explain how having indexes (arrays, substr, etc...) in Perl 6 start at 0 will benefit most users. Do not invoke legacy. [1] [1] ie. because that's how most other languages do it or everyone is used to it by now are not valid arguments. Ask any Pascal programmer. :) The other (reverse) way out, i'm not trying to make an essay, just think out loud but if you have $string = Hello World, and you want the last three chars, you do: $wanted = substr $string, -3; If the first index was 1, it could be ok too, but what would be offset 0? What if someone was looking at his string backwards? $pos = 1; # 0 | 1 # - substr $string, $pos--, 1; # 'H' | 'e' substr $string, $pos--, 1; # 'd' | 'H' substr $string, $pos--, 1; # 'l' | '' ? substr $string, $pos--, 1; # 'r' | 'd' ? Dont ask me why someone would do that... But i expect to get the last $string's char with $pos == -1, not 0. I also find the 'offset' idea to be consistent with binary math. After all, with bytes, 0x7F + 1 == +0d127 but also -0d128... and i found it sometimes useful to be able to mix signed and unsigned values. One could argue it's not the way to go, it's tricky, you dont mix signed/unsigned... blah. Walking is tricky, bicycling is tricky, remember the first time you tried and you fell? blah. no more args :-) (yet another lurker)
Re: purge: opposite of grep
On 5 Dec 2002, Rafael Garcia-Suarez wrote: John Williams wrote in perl.perl6.language : If you want good'ol Unix flavor, call it vrep. Compare the ed(1) / ex(1) / vi(1) commands (where 're' stands for regular expression, of course) : :g/re/p :v/re/p Or, to follow the spirit rather than the letter of Unix, how 'bout ere for Elide REgex or tang for Tog's A Negated Grep? /s
Perl 6 and Set Theory
=head1 Perl 6 and Set Theory
This document will introduce a new way of thinking about some Perl 6
constructs. In addition, it proposes some minor changes that would
help this way of thinking be more consistent. These changes may make
Perl 6 a better language in general, as a side effect.
Even in absence of an explicit set type, Perl 6 is quite proficient
in set theory. There are two types of sets it knows about: finite and
infinite. The former we call junctions, while classes make up
infinite sets.
=head2 Junctions
Junctions are a transparent mechanism for dealing with finite sets.
They indeed hold a discrete set of objects, but operations on the
junction are automatically delegated to operations on its members.
The two types of junctions, disjunctive (Cany) and conjunctive
(Call) just determine how the junction is evaluated in boolean
context.
The expressions:
1 | 2 | 3
any(1, 2, 3)
1 2 3
all(1, 2, 3)
represent the set:
{ 1, 2, 3 }
Which we will call N. Performing some operation Iz on them
constructs and returns the set:
{ z(x): x ∈ N }
If, for example, this operation is C{ $^x + 2 }, we have:
{ x + 2: x ∈ N }
or
{ 3, 4, 5 }
If that was a comparison operation, say C{ $^x 2 }, the resultant
set would be:
{ undef, undef, 1 }
Evaluating this in boolean context should be true if the junction was
conjunctive, and false if it was disjunctive. So, for a junction J,
boolean context evaluation is defined as follows:
{ ∃x: x ∈ J ∧ ?x, disjunctive
?J ≡ {
{ ∀x: x ∈ J ⇒ ?x, conjunctive
That is, the type of junction just determines whether the quantifier
is existential or universal.
There is one behavior of junctions, however, that doesn't work with
this definition: If a boolean operation is applied in non-boolean
context to a junction, it will return a junction of only the values
for which the condition evaluated true. But with a few minor changes,
this can be achieved:
• Junctions discard Cundefs on-sight (i.e. Cundef can never be
a member of a junction).
• Comparison operators return Cundef if they fail, and their
left-hand side Cbut true if they succeed.
• Comparison operators are right-associative.
Unfortunately, the last change clobbers the left-short-circuiting
behavior of comparison operators. A way to fix this would be to treat
a chain of comparison operators as a single n-ary operator. Other
methods for fixing this are welcome (and encouraged).
Note that the definition of how junctions behave in itself allows
operators involving more than one junction to represent the outer
product of those junctions with respect to an operator. Consider two
sets, A = any(1,2,3), and B = all(4,5,6).
A + B = { x + B: x ∈ A }
= { { x + y: y ∈ B }: x ∈ A }
= { { 5, 6, 7 }, { 6, 7, 8 }, { 7, 8, 9 } }
Where each inner set is a conjunctive set, and the outer is a
disjunctive set. If you call this resultant set C, and ask:
5 C 9
It would be true (in fact, C5 but true), as all(6, 7, 8) would
match.
=head2 Classes
In Perl 6, classes represent infinite sets of objects. The class
CInt represents the set of integers, CNum the set of all numbers,
including the integers. Inheritance represents supersets. Finite
sets, or junctions, can be used for union and intersection of these
infinite sets.
Unlike junctions, classes are not transparent interfaces to their
members. You can't say C Int 10 to find out whether all
integers are greater than 10. There is, in fact, no way to assert
this in Perl, as Perl would have to instantiate ℵ₀ objects, which
would take ℵ₀ seconds (forever). Similarly with Num, except now
there's ℵ₁ objects and seconds (foreverer).
For instance, to declare a variable that can represent either an
integer or a string:
my (Int | Str) $var;
The type of that variable is the union of the sets of integers and
strings. The value of $var must be a member of at least one of those
sets.
Since a derived object can be used in place of its parent anywhere, it
must represent an improper superset of its parent. This seems
backwards, but if you think about it logically: Every member of the
parent set needs to be a member of the child set; every member of the
child set need not be a member of the parent set. Q.E.D.
Multiple inheritance represents a superset of multiple sets.
CObject or CUNIVERSAL represents the universe; i.e. the set of
all objects. The null junction Cany() represents the empty set
(which is different from Cundef, as proposed above).
It is an interesting issue whether any junction can be used as a
class. That is:
my (1 | 2 | 4) $var;
would declare $var to only accept values 1, 2, and 4. This probably
introduces too much complexity for what it's worth.
=head2 Summary
The rules for a junction J, again, are:
z(J) ≡ { z(x): x ∈ J }
{ ∃x: x ∈ J ∧ ?x, disjunctive
?J ≡ {
{ ∀x: x ∈ J ⇒ ?x, conjunctive
Re: Stringification of references and objects.
Michael Lazzaro [EMAIL PROTECTED] writes: On Friday, December 6, 2002, at 01:28 AM, Joseph F. Ryan wrote: Array(0x1245AB) Personally, I like this format. It's succinct, informative, and tells you enough to do identity testing. I like it too, but I thought everyone else hated it :) I think people like it fine, but many people don't want it to be the default stringification. Like I said in an earlier thread, the problem is that there's stringification for output purposes and stringification for debugging purposes, but we have to chose one or the other to be the default. I'd rather the debugging one _not_ be the default, personally, because I imagine the other usage is more common. Well, personally I think you're very wrong. Kent Beck is good on this in 'Smalltalk Best Practice Patterns': The two audiences for strings generated by objects, you and your client are often in conflict. You want all the internal, structural details of your object laid out in one place so you don't have to go searching layers and layers of objects to find what you want. Your client assumes the object is working correctly and just wants to see externally relevant aspects of the object in the string. He notes that VisualWorks Smalltalk makes the distinction between 'displayString', for the user oriented stringification and 'printString', for the programmer oriented. Personally I reckon that having the the default behaviour be the 'debugging' string makes too from the point of view of separation of concerns; generally you want to separate formatting from the objects themselves. Also, the debugging approach makes sense from the point of view of a 'composite' object. One can imagine cases where a contained object makes incorrect assumptions about how it is being displayed, which could cause problems for the implementation of the container's as_string method; instead of simply doing: join \n\t .members (say), you could find yourself adding class based overrides for different sorts of member objects and it could all get ugly quickly. An obvious counterproposal would be to say that references are invisible to stringification (e.g. it stringifies to whatever its contents stringify to). This would seem to be in keeping with the the spirit of arrayref/array transparentness, etc. Personally I'm not keen on this idea. The distinction between the thing itself and a pointer to the thing is an important distinction for the programmer to be aware of. -- 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?
Re: Stringification of references and objects.
This is a bit of an oversimplification. $foo and @foo do not always behave the same, even if $foo and @foo refer to the same array object. In particular, $foo doesn't behave like @foo in a list context. Scalars must continue to behave like scalars in list context, even if they're internally composite. Am I the only one here who thinks Perl 6's rules for arrays/lists/refs are getting way too complicated? This is getting even worse than C's confusion of them. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Stringification of references and objects.
On Friday, December 6, 2002, at 01:08 PM, Piers Cawley wrote:
He notes that VisualWorks Smalltalk makes the distinction between
'displayString', for the user oriented stringification and
'printString', for the programmer oriented.
One could imagine a scenario in which a user could accomplish an
unlimited number of styles of stringification by creating multiple
subclasses of CStr, one per desired style:
class FormalStr is Str;
class InformalStr is Str;
class PersonName {
...
method FormalStr { $.hon $.first $.middleInitial\. $.last }
method InformalStr { $.nick || $.first }
}
my PersonName $name = .new(...);
my FormalStr $s = $name;# Dr. William P. Smith
my InformalStr $s = $name;# Bill
Whether that is good, bad, or indifferent I leave to the OO Police.
But the same approach could be used for Str and DebugStr, etc. It just
depends on what audience we want Perl6 str's to be geared for.
(Ignoring the various context/coercion issues raised by the above.)
MikeL
Re: Usage of \[oxdb]
On Fri, Dec 06, 2002 at 03:24:44PM +1100, Damian Conway wrote:
Larry was certainly in favour of it when he wrote A5
(see under http://search.cpan.org/perl6/apo/A05.pod#Backslash_Reform).
Except the separators he suggests are semicolons:
Perl 5 Perl 6
\x0a\x0d\x[0a;0d] # CRLF
\x0a\x0d\c[CR;LF] # CRLF (conjectural)
I just had this thought - can I interpolate in there?
Something like
\c[$(call_a_func())]
and I interpolate the string returned by call_a_func() using whatever
interpolation system it finds itself in. (so the same function could
create the literal control characters if it finds itself in \c[...], or
the pretty-printed version if it finds itself within \\c[...]
I'm not sure if this is useful - I think its only benefit is to save a
string eval occasionally, with the downside of being obscure, complicating
understanding (interpolation becomes run time rather than compile time if
it's non-constant), and possibly the implementation.
[No I'm not smoking anything. I'm drinking tea today. Maybe it's just side
effects of over-exposure to london.pm yesterday, or reading Damian's book
(If it moves^Wis a reference - bless it! :-))]
Nicholas Clark
PS Time for a second edition:
perl5.8.0 -lwe 'format FOO = ' -e '.' -e '$a = *FOO{FORMAT}; print ref $a'
FORMAT
Re: Stringification of references and objects.
On 12/6/02 4:41 PM, Michael Lazzaro wrote: my PersonName $name = .new(...); my FormalStr $s = $name;# Dr. William P. Smith my InformalStr $s = $name;# Bill Whether that is good, bad, or indifferent I leave to the OO Police. I'm not even deputized, but I call foul: excessive use of subclassing ;) Even in Perl 5 code, I end up having multiple stringification methods for things like error messages. But I simply use different method names for each (e.g. error() and public_error()), and don't bother with overloading at all. I think the desire to have stringification DWIM is now bordering on RMMP (read my mind, please :) Yes, there will probably be many WTDI in Perl 6, but I doubt any will end up beating the simplicity and clarity of named methods. Standardizing these methods names in an effort to help out debuggers seems reasonable, but I wouldn't go much further than that. In fact, I'd go so far as to say that the default stringification of most objects should probably still be something like FOO(0x1234), since I frequently use those strings to find out if two things are pointing to the same object. At the very least, some sort of similar unique identifier should be accessible to any stringification method writer... -John
Re: purge: opposite of grep
On Thu, 5 Dec 2002, Sean O'Rourke wrote: On 5 Dec 2002, Rafael Garcia-Suarez wrote: John Williams wrote in perl.perl6.language : If you want good'ol Unix flavor, call it vrep. Compare the ed(1) / ex(1) / vi(1) commands (where 're' stands for regular expression, of course) : :g/re/p :v/re/p Or, to follow the spirit rather than the letter of Unix, how 'bout ere for Elide REgex or tang for Tog's A Negated Grep? Gah. s/Tog/Tang/. /s
Re: In defense of zero-indexed arrays.
Damien Neil wrote: On Thu, Dec 05, 2002 at 02:45:39AM -0800, Michael G Schwern wrote: Explain how having indexes (arrays, substr, etc...) in Perl 6 start at 0 will benefit most users. Do not invoke legacy. [1] Answer 1: Ignoring legacy, it won't. Bingo. Answer 2: Because C uses 0-based indexes, Parrot is written in C, and it would be just painful to switch back and forth when working on different layers of the system. (Not a legacy argument, unless you want to argue that Parrot is a legacy system.) I doubt most users will be writing Parrot. Answer 3: In a lower-level language than Perl, an array is usually a block of memory divided into array elements. The index is the offset from the start of the array. Assuming the base index of the array is 0. More generally, the index of an array element is that element's offset from the base index of the array. Your argument is somewhat circular. I have oodles of arrays declared to start at 1980. Most of my arrays start at index 1. But then I'm a Fortran programmer. (And I hope that's not an opening for a language war thread.) Choice of language aside, having max_index == num_elements appeals to me. YMMV. In any case, the choice of default base index is less important for Perl than for other languages given how seldom arrays in Perl are accessed by index as opposed to manipulated by push, pop, for $x (@array) loops and such. brad
Re: purge: opposite of grep
Sean O'Rourke writes: On Thu, 5 Dec 2002, Sean O'Rourke wrote: how 'bout tang for Tog's A Negated Grep? Gah. s/Tog/Tang/. Wouldn't that mean we had to rename grep to 'gnat'? (Gnat's Not A Tang, presumably, never mind rot13 and reversal...) -- Aaron Crane * GBdirect Ltd. http://training.gbdirect.co.uk/courses/perl/
Re: In defense of zero-indexed arrays.
On Thu, Dec 05, 2002 at 02:45:39AM -0800, Michael G Schwern wrote: : I'm going to ask something that's probably going to launch off into a long, : silly thread. But I'm really curious what the results will be so I'll ask : it anyway. Think of it as an experiment. : : So here's your essay topic: : : Explain how having indexes (arrays, substr, etc...) in Perl 6 start at 0 : will benefit most users. Do not invoke legacy. [1] How about, because I like it? You may, of course, see that as a legacy argument, depending on our relative ages... :-) Anyway, that aside, I see no reason why we couldn't have array types that are explicitly declared with array bases other than 0. Perhaps even the built-in types can just take a range property: my @array is range(1...); One could even go so far as to have a pragma that causes all arrays declared in the current *lexical* scope to be based at 1. Call it use fortran; or some such... This is not problematical in the same way that $[ was, since we're limiting the effect to the current lexical scope. In fact, speaking of legacy, you'll recall that the fix for Perl 5 was to make $[ = 1; really do a lexically scoped declaration despite having the appearance of a global assignment. By the way, I noticed when visiting Uruguay that the elevators number the floors ...-2, -1, 0, 1, 2..., where 0 is the ground floor, and basement floors are negative. Way cool. Now all we have to do is convince everyone that the year 1 B.C. is the same as year 0 A.D., and 2 B.C. is the same as -1 A.D., and so on. Larry
Re: In defense of zero-indexed arrays.
Larry wrote: : Explain how having indexes (arrays, substr, etc...) in Perl 6 start at 0 : will benefit most users. Do not invoke legacy. [1] How about, because I like it? You may, of course, see that as a legacy argument, depending on our relative ages... :-) A practical argument in its favour is that it makes circular-lists-via-modulo: @list[++nextidx%7] = $nextval; and cyclic-value-mapping-via-modulo: $day_name = Sun Mon Tue Wed Thu Fri Sat[$day%7]; both work correctly. Anyway, that aside, I see no reason why we couldn't have array types that are explicitly declared with array bases other than 0. Perhaps even the built-in types can just take a range property: my @array is range(1...); Surely, that would be: my @array is domain(1...); ??? Damian
Re: Usage of \[oxdb]
Nicholas Clark mused: I just had this thought - can I interpolate in there? Something like \c[$(call_a_func())] Why not just: $(chr call_a_func()] ??? Damian
Re: purge: opposite of grep
Dave Whipp wrote:
I notice everyone still want Int context for eval of the block:
Pease don't forget about hashes. Is there such a thing as
'hashkey context'?
I doubt it. Unless you count Str context.
Perl6 is much better than Perl5 for naming parameters. Could
we make the following work?
( low=@under,
mid=@in_range,
high=@over )
= partition @input - $v {
$v 10 ?? low :: $v 20 ?? high :: mid;
};
I very much doubt it. I think at that point you really want:
for @input - $v {
push ($v 10 ?? @under :: $v 20 ?? @over :: @in_range), $v;
}
Also, can I return superpositions (sorry, junctions), to provide
multiple classifications? Or would I return an array for that?
A (dis)junction ought to work there.
Damian
Re: purge: opposite of grep
Michael Lazzaro wrote:
How would you do something like:
(@foo,@bar,@zap) := classify { /foo/ ;; /bar/ ;; /zap/ } @source;
Since I don't understand what that's supposed to do, I probably *wouldn't*
do something like it. What effect are you trying to achieve?
Damian
RE: purge: opposite of grep
Damian Conway:
# Also, can I return superpositions (sorry, junctions), to provide
# multiple classifications? Or would I return an array for that?
#
# A (dis)junction ought to work there.
That sounds horribly scary...
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
If you want to propagate an outrageously evil idea, your conclusion
must be brazenly clear, but your proof unintelligible.
--Ayn Rand, explaining how today's philosophies came to be
Re: In defense of zero-indexed arrays.
DC == Damian Conway [EMAIL PROTECTED] writes: DC A practical argument in its favour is that it makes DC circular-lists-via-modulo: DC @list[++nextidx%7] = $nextval; DC $day_name = Sun Mon Tue Wed Thu Fri Sat[$day%7]; DC both work correctly. not to defend 1 based arrays but all you have to do with the above is add the base offset to them: DC @list[++nextidx%7 + 1] = $nextval; DC $day_name = Sun Mon Tue Wed Thu Fri Sat[$day%7 + 1]; in any case i like 0 based. the best argument i have seen so far is that is makes -1 a meaningful index. that is something pl1 and fortran could never do without a range declaration. and larry's property and pragma ideas are fine solutions for those who want impaired indexing. :) uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com - Stem and Perl Development, Systems Architecture, Design and Coding Search or Offer Perl Jobs http://jobs.perl.org
