Re: Temporal.pod truncate
On Thu, 8 Apr 2010, Carl Mäsak wrote:
Among the cons: we lose the nice symmetry wherein :today clears all
values smaller than days, :toyear clears all values smaller than
years, etc. :tomonday is still pretty straightforward, but it's a
subtle category error.
Of course. What I really want is for weeks to start on Sunday, like
all the calendars around me seem to indicate that they do. Rather than
pushing my particular time-ideology on everyone else, I would like to
see a post-modern solution for the problem.
Having an internal variable like $[ to define the first day of the week
has turned out bad in the past, so I proposed this solution instead.
Apart from that, I wouldn't mind making the change. Though maybe we
should take a step backward and just remove :toweek altogether on
the grounds that it doesn't belong, and is more confusing than useful.
I agree that :toweek is confusing, but just because not everyone can
agree on the definition of week. But if you are writing a calendar
application, it is very useful. We measure time in weeks just as often
as we measure it in months, and weeks are a much less confusing time
interval than months are. Just because we prefer to _write_ dates
in terms of months doesn't mean weeks are any less valid of a time
interval. Anything besides year and day is rather artificial,
so maybe we should forget about months, weeks, hours, minutes and
seconds too. They should all be part of the calendar class, right?
On Fri, 9 Apr 2010, yary assumed:
indeed truncating to any day of the week can be implemented by user
trivially by adding/subtracting a constant number of days from the
Monday returned.
No, it's not a constant.
$sun = DateTime.new('2010-04-11').trunc( :tosunday ) # 2010-04-11
$mon = DateTime.new('2010-04-11').trunc( :tomonday ) # 2010-04-05
$sun - $mon == 6 days
$sun = DateTime.new('2010-04-12').trunc( :tosunday ) # 2010-04-11
$mon = DateTime.new('2010-04-12').trunc( :tomonday ) # 2010-04-12
$sun - $mon == -1 day
On Thu, 8 Apr 2010, Mark J. Reed wrote:
I think that :toweek should stay as-is; it truncates to whatever the
.week method returns, and that's Monday-based. It would be too
inconsistent for it to do anything else.
Agreed. That's why I asked for :tosunday
Asking for the latest prior Sunday or any other weekday is a useful
function, but it doesn't really have anything to do with 'truncation'.
Asking for the first of the month is truncating to an even more arbitrary
interval than a seven-day period, but we still call it truncation somehow.
The trouble with asking for the prior sunday, is that on sunday an
implementation of the prior() function will return a date 7 days prior to
today, while an implementation of the truncate() function will return
today.
Temporal.pod truncate
Small feature request: $dt.truncate( :toweek ); is somewhat ambiguous, since some people start their week on Sunday, while the module truncates to Monday. Would you consider a less ambiguous week truncation? $dt.truncate( :tosunday ); $dt.truncate( :tomonday ); ~ John Williams
Re: $_ defaulting for mutating ops
On Wed, 2 Nov 2005, Michele Dondi wrote: On Fri, 28 Oct 2005, John Williams wrote: But IMHO the reduction in typing for this relatively minor issue is not really worth the surprise to newbies at seeing operandless operators. I don't buy that argument as newbies are already exposed to all sorts of surprises including operandless operators. Including mutating operandless operators. What is s/// after all? Or is there a good reason for an asymmetry between different classes of operators? Well, s/// is a term, for one thing. It is not so much an operator, as it is a subroutine with really strange syntax, and the side-effect of changing the $_ variable. You need to use an operator to get it to affect a different variable. It looks funny no matter how much you squint your eyes. Not that that is a bad thing of course, but I don't think it should be used as an example for operators to follow. ~ John Williams
Re: $_ defaulting for mutating ops
On Tue, 25 Oct 2005, Juerd wrote:
For comparison, here is the same code snippet again. First with, and
then without explicit $_.
With:
given ($subject) - $_ {
$_ ~~ s/foo/bar/;
$_++;
$_ x= 2;
$_ ~= !;
}
Without:
given ($subject) {
s/foo/bar/;
++;
x= 2;
~= !;
}
I think the latter is more elegant, without reducing legability or
maintainability. I also think that the code is immediately obvious, even
to people coming from Perl 5, who never read this thread.
I don't really agree with your method of addressing the issue. When I have
been annoyed by this issue it is because I can write $x = $x * 2 as
$x *= 2;
which is elegant, but $x = $x * 2 + 1 requires two statements when using
meta-operator-equals:
$x *= 2;
$x += 1;
which is probably less elegant than the original $x = $x ... form.
One could cascade those with extra parens...
($x *=2) += 1;
(($_ += 1) x= 2) ~= !;
If one were to change the associativity of the meta operators such that
the parens were not needed the result would be very similar to your
example, minus a few semicolons.
$_ += 1
x= 2
~= !;
however, I would definitely want someone other than myself to ponder the
implications of mucking with associativity like that.
But IMHO the reduction in typing for this relatively minor issue is not
really worth the surprise to newbies at seeing operandless operators.
~ John Williams
Re: Demagicalizing pairs
On Wed, 24 Aug 2005, Damian Conway wrote: Larry wrote: Plus I still think it's a really bad idea to allow intermixing of positionals and named. We could allow named at the beginning or end but still keep a constraint that all positionals must occur together in one zone. If losing the magic from ='d pairs isn't buying us named args wherever we like, why are we contemplating it? I've lost track of the score in this thread, but I thought I would throw a couple pennies into the fountain. I really dread the thought of losing C name = value for named parameters. Off the top of my head, ADA, PL/SQL, and php all use that syntax, so it would be a shame to lose something that newbies might find familiar. On the other hand I would like it if the adverbial named parameter style C :name(value) were allowed at the begining as well as the end of the parameter list. I think adverbs read better when they are next to the verbs they modify, and I would be nice if I didn't have to resort to macro magic to get them there. Mixing named and positionals is bad though. ~ John Williams
DBI v2 - Data In and Data Out
the are returned from DBI. DATE columns as a DateTime object, LOB colums as an IO object, etc. I think this requires more cooperation from the drivers than any of the previous suggestions. It might also be slower, due to the need to ask for type information from the database. So maybe this one is turned on optionally, and not guaranteed to work with all drivers. Something which is complementary to the method used to handle data types on input would be good. Maybe return values are assigned a role such a SqlInteger, SqlDate, etc, and users can install multi subs to coerce them to the type the user desires. Not sure how well that would work for LOBs. Or maybe we register a conversion sub with DBI for each database type we want to be handled specially. ~ John Williams
Re: Documentation trait / Docstring equiverlent
On Thu, 30 Jun 2005, chromatic wrote: On Thu, 2005-06-30 at 04:33 +, David Formosa (aka ? the Platypus) wrote: I'm just wondering if a documentation trait on subs would be usefull. If we are going to have something like p6explain the doc trait could be used as the source for the infomation for it. p6explain would simply have to walk the AST reading the doc traits and pasting the text together. I certainly hope so. Given Larry's recent work with the Perl 5 tokenizer to include this information in the optree, it's a shame for Perl 6 to throw away potentially useful data recklessly. There is something to be said for actually _organizing_ the documentation too, which is why POD docs for a function are not always next to the function itself. That said, I hope the documentation trait on subs can optionally be a pointer to the (section of the POD) document where the documentation actually resides. ~ John Williams
Re: Reductions, junctions, hashslices, and cribbage scoring
On Wed, 25 May 2005, Rob Kinyon wrote:
(This post references the discussion at
http://www.perlmonks.org/?node_id=458728, particularly dragonchild's
response at the bottom.)
For those who don't know, cribbage is a game where each player has
access to 4 cards, plus a community card. Various card combinations
score points. The one in question is when cards add up to 15. If you
have a group of cards that add up to 15, you receive 2 points. This is
for every group, so if you have a ten and 2 fives, you get 4 points.
Two tens and two fives is 8 points. Face cards are worth 10 and aces
are 1, for these purposes.
I proposed the following:
# Fifteens
$score += 2 * all( 15 == [EMAIL PROTECTED] any( 0 .. 4 ) } );
* Is this syntax legal?
I think so.
* Does it do what I want it to do?
Definitely not. It looks like you are thinking of junctions in terms of
arrays, instead of scalar quantum superpositions.
any( 0 .. 4 )
This returns a scalar junction of the five values (0,1,2,3,4).
What you want is clearly all possible subsets of 0..4. You probably
should write a coroutine to generate a lazy list of them.
@hand{ $junction }
returns a scalar junction of the five cards in the hand. Junctions
auto-thread through operators, including postcircumfixes.
[+] $junction
returns $junction, since [+] $scalar == $scalar. The individual values
auto-thread through.
15 == $junction
This returns a junction of booleans. Knowing the possible values of
@hand, all of them are false.
all( $junction )
I'm not real good with nested junctions...
2 * $junction
This returns another junction, with all elements doubled. (still zeros)
You obviously want 2 * junction.elems, but I'm not sure if junctions
support that method.
$score += $junction
Again this will make $score a junction of values. It will not add each of
the junction values to $score. You probably want something like
C $score += $junction.values but that is another indication
that you should be using arrays instead of junctions. And I'm not sure
about the object interface to junctions anyway.
* Is there another way?
Assuming you write the subset coroutine above, how about
$score +=
( subsets(0..4) == map { 2 * (15 == [+] @[EMAIL PROTECTED]) } == [+] )
~ John Williams
Re: reduce metaoperator
On Wed, 4 May 2005, Larry Wall wrote: It would be nice to have an easy-to-access What's this? interface that could be stitched into your favorite editor to identify what's under the cursor, or at least a command like: p6explain '[+]' That would make me extremely happy. :$sum = [+] @array; # meta operator Another random thought which came to me (right after \\+ could be mnemonic for return a function ref for this operator) was this: How does [+] know you mean reduce infix:+, @array; instead of reduce prefix:+, @array; which is nonsense, but the [+] is in a prefix position. With the hyper metaoperator, the real operator is always in the place where it would normally be parsed. But this metaoperator pulls the real operator out of its usual pre/in/post position. I suppose users will need to know the answer when they start trying to write their own metaoperators. Maybe the metaoperator's function signature resolves that somehow? But I haven't been following the function signature thread closely. I can see how to ask for a binary (hence infix) operator, but how do I ask for a prefix or postfix operator specifically, which + and + do? Maybe there are Operator::Prefix, etc, roles defined so you can ask for them? ~ John Williams A06 typo: infix:+( prefix:-($a), $b) [Update: That's now infix:+( prefix:-($a), $b) .] The correction only corrected one of the errors: infix:+( prefix:-($a), $b)
Re: reduce metaoperator
On Thu, 5 May 2005, David Wheeler wrote: I can see how to ask for a binary (hence infix) operator, but how do I ask for a prefix or postfix operator specifically, which + and + do? Maybe there are Operator::Prefix, etc, roles defined so you can ask for them? Ask for them for what? For negating all elements of an array: @negatives = -« @positives; They should write them [metaoperators] only for infix operators. The above example is in S03, so that is not an option. Because [] applies only to infix operators, as I understand it. You understand it. I understand it. But how does the parser know the difference between @x = - @y; and @x = [+] @y; or even @x -= @y; which shows that the position of metaoperator is not the distinguishing factor.
Re: reduce metaoperator
On Thu, 5 May 2005, John Williams wrote: or even @x -= @y; Doh! That should be C $x -= $y; of course.
Re: reduce metaoperator
$sum = reduce(+) @array; # macro $sum = reduce infix:+ @array; # regular sub $sum = [+] @array; # meta operator ($sum = 0) += @array;# hyper tricks use My::Cool::Reduce::Mixin; # unless in core $sum = @array.reduce(+); # macro-ey method There can never be too many ways to do it, but as one who hasn't been able to keep very current with perl6l lately, I think a particularly relevant question we should be asking a lot is, How long will it take someone reading that code to figure out what it means? The nice thing about reduce is that it is easy to find in the index. [+] will not be in the index, although I'm sure it would be the first thing one would look for. I'm not sure how many other things a newbie will try before looking up metacircumfix:[ ] or however that is spelled. Also in the same light, I am not convinced that reduce is used often enough to deserve a shorter huffman encoding. Sure it makes that fancy slice shorter, but how much headscratching is required for a human to parse that shortness? Personally, I think this would be more readable, in part because the object paradigm is widely understood. @foo[0..9; @array.reduce(infix;) ; 0..9]; @foo[0..9; @array.reduce(;) ; 0..9]; I actually kinda like the idea, in spite of coming across as a naysayer here. It just seems like an idea that should be in a module instead of in core, which seems like an awful strange thing to say to $Larry. ~ John Williams P.S. I like [+] better than \\+ because I cannot figure out what \\ would be mnemonic for. P.P.S. We can't use (R)+ ... it's already trademarked! :)
Re: Hyper operator corner case?
I found where Damain explains the rule as basically replicate dimensions,
extend lengths, using an identity value when extending the length.
http://www.mail-archive.com/perl6-language@perl.org/msg08304.html
On Wed, 13 Apr 2005, Thomas Sandlaß wrote:
Brent 'Dax' Royal-Gordon wrote:
IIRC, it's f) (1,2,3,4,5) + (1,2,$identity,$identity,$identity),
where $identity's value is determined by a table something like this:
In the case of infix_circumfix_meta_operator:{'»','«'}:(List,List:op)
there's no upgrade---to use the S03 term. A simple apply op where
the lists overlap and keep the rest of the longer one suffices.
That is (1,2,3,4,5) + (1,2) becomes (1+1, 2+2, 3, 4, 5). For
infix_circumfix_meta_operator:{'»','«'}:(List,Scalar:op) the upgrade
works by applying the operator with the scalar to all entries:
(1,2,3,4,5) + 1 becomes (1+1, 2+1, 3+1, 4+1, 5+1).
Good point. Another one is: how does the meta_operator determine the
identity value for user-defined operators?
(1,2,3,4,5) my_infix_op (3,2,4)
Maybe we should say that the excess length is simply copied unchanged.
But some might argue that not calling the op for each element would be
cheating somehow. That's not my position, but I cannot think how to
refute it right now, if you want the side-effects.
What I ask myself is wether (1,2,3) »+ 1 should be a syntax error or just
a different form to express the :(List,Scalar:) case. BTW, I know that
infix_prefix_meta_operator:{'»'} isn't mentioned in A12.
I could be wrong, though; I can't find any support for it in the design
docs.
Replicate dimensions is specified in the first version of A3.
The length issue was resolved on the mailing lists.
Could someone add the ruling to S3 to answer this FAQ?
I believe the fine points fall out like this:
@a + 1# replicate
@a + (1) # replicate: (1) is still scalar
@a + [1] # extend: [1] is an array (and will auto-deref)
~ John Williams
Re: Angle quotes and pointy brackets
On Tue, 30 Nov 2004, Larry Wall wrote:
Here's the proposal.
First the bad news:
* We accept that the C operator requires whitespace
around it, and be prepared to be burned in effigy occasionally.
My biggest worry about this is that people will be writing
if $x3
loop( $x=0 ; $x10 ; $x++ )
more than occasionally.
* We steal angles away from iterators.
I vote we do that in any case.
Now, that has certain interesting outcomes.
* We get ... as the qw// shorthand where a term is expected.
* Most uses of qw// involve strings and lists, so there's little
visual interference with numeric comparison operators.
* We get the cute, clean and rather more typeable
$varkey1key2[3]key3
I'm starting to like $var{'key1'}{'key2'}[3]{'key3'} more and more.
And it's the only way to write $var{'key with spaces'}, right?
* That means that, roughly, we have this proportion:
'...' : ... :: ... : «...»
That's definitely worth a cuteness award.
Now with those out of the way, the good news:
* All other uses of «...» and ... swap, pretty much.
Moving this to the end, because I want to request clarification in the
context of rules.
* Match vars become $foo instead of $«foo».
* A rule like ident now captures, while «ws» or ws doesn't.
Is all the Extensible metasyntax (...) being changed to «...» ?
Or is the new rule that ... is capturing metasyntax, and «...» is
non-capturing metasyntax?
Does / -alpha / capture to $0{'-alpha'} ?
Or should that be written / -«alpha» / ?
You can't really capture anything on an assertion, so
/^foo .* ( do { say Got here! } or 1 ) .* bar$/
is probably not an issue at all.
How are the results different between these?
/ident/
/(ident)/
/(«ident»)/
~ John Williams
Re: What Requires Core Support (app packaging)
On Tue, 7 Sep 2004, James Mastros wrote: PS -- Unreatedly, why, oh why, do people insist on an apostrophe in 80's Maybe in the 80's is like at the Jones's. Not that I care, mind you. and postfix:'th? It's 80s and postfix:th! Probably to help separate the term from the postfix operator. $foo = 3; @array[ $foo'th ];
more ordinal discussion
On Tue, 7 Sep 2004, Juerd wrote: John Williams skribis 2004-09-07 11:37 (-0600): and postfix:'th? It's 80s and postfix:th! Probably to help separate the term from the postfix operator. @array[ $foo'th ]; Maybe what I'm saying now is a really bad idea, because it doesn't make sense, but can't we just have an adverb that changes an integer into an ordinal? 4 :th $foo :th No. Adverbs modify verbs (operators or functions), not terms like 4 or $foo. Obviously, the : should be optional for literal integers: 4th 3th Yes, because 3 and th parse as different tokens.
Re: The last shall be last
On Sun, 5 Sep 2004, Matt Diephouse wrote: Am I the only one that thinks that -1st should return the last element in an array under the nth scheme? 1st should mean the first element. -1st should mean the first element of the reversed array. Don't say -1st is the first from last. If last is the opposite of first, I would expect 1st to mean first from first, which would mean the second. Say first from the end. It matches up with perl5 C$array[-1] and is a workable interpretation of negative ordinals. So I could think that way too. @ary[ 1st .. -1st ]# hmm...
Re: parameter contexts (was: Synopsis 9 draft 1)
On Sat, 4 Sep 2004, Juerd wrote:
John Williams skribis 2004-09-03 23:06 (-0600):
(A and Z)
I think I'd prefer alpha and omega.
Why not use Cyrillic or Korean or the secret code alphabet we used in
school?
I meant the actual words alpha and omega, because they're like A and Z
but with some extra religious connotation of first and last.
st (nd, rd) as a cardinal postfix operator sounds good.
To keep 1st+$n a Cardinal, we could define
multi operator:+ (Cardinal $a, Int $b) is commutative {...}
Is nth a magic function that returns the cardinal size of the
dimension it is in?
~ John Williams
Re: The last shall be last (was: The first shall be first)
On Sat, 4 Sep 2004, Jonathan Lang wrote: The only place where it makes sense to wrap is when you define 0th as the final element, making it logical that 0th+1 == 1st and 1st-1 == 0th. I don't think 0th is a good name for the final element. I've never seen it used for that. I've only seen it used as a synonym for the element with index 0. (Which is usually also the 1st element.) No newbie is going to read 0th and think last. nth means last in at least some instances (e.g. summation from 1 to n). The primary meaning is any element, but its still better than 0th. last would be better, but I don't want the homonym term problem with loops. It's also not quite symmetrical with 1st. nth or zth are better symmetry with 1st. BTW, there should be no ambiguity between Cpostfix:'th and C'', because one occurs where an operator is expected, and one occurs where a term is expected. last (=nth) and last (=break) are both terms unfortunately. ~ John Williams
Re: Synopsis 9 draft 1
On Thu, 2 Sep 2004, Larry Wall wrote:
A multidimensional array is indexed by a semicolon list, which is really
a list of lists in disguise. Each sublist is a slice of one particular
dimension. So
@array[0..10; 42; @x]
is really short for
@array.postcircumfix:[]( == [0..10], [42], [EMAIL PROTECTED] );
I'm a bit surprised.
If I declare
method postcircumfix:[] ($self: [EMAIL PROTECTED]);
Is $object[$yada] the same as
$object.postcircumfix:[]( $yada ); # which I would expect
or
$object.postcircumfix:[]( == [ $yada ] ); # which surprises me
If the latter, Why?
If the former, where did the extra magic for arrays come from?
Tangential trivial thoughts:
Can I declare an alphabetic postcircumfix operator?
sub postcircumfix:ipso...facto ( $left, $inside ) {...}
Is that even usable, given that no space is allowed before the
postcircumfix operator? Or does this work:
$foo.ipso 'bar' facto;
Or maybe it has to be declared multi instead of sub for that?
~ John Williams
Re: parameter contexts (was: Synopsis 9 draft 1)
I think we just need something really short and unconfusing for the commonest cases, @a[ 42 ; -1 but last ] That reads pretty well, no? Maybe the other end isn't quite as good: @a[ 1 but first .. -2 but last ] Hmm. Should -1 but last or 0 but last be the last element? ~ John Williams
Re: parameter contexts (was: Synopsis 9 draft 1)
If you insist on using A and Z, at least make them \A and \Z, to give a stronger visual cue that something different is happening. I think I'd prefer alpha and omega. Or maybe turn my previous suggestion around and make first and last special constants. Then say: @a[ first .. last but 1 ] Or does it have to be last but int(1) ? ~ John Williams
adverbs
Adverbs are confusing me mightily lately.
It may be that Larry's A12 revision just needs a few examples
*with* parenthesis to straighten me out.
Here are some semi-coherent attempts to sort it out
in my mind. Please correct me where I have made mistakes.
What is the rule(s) for when :foo is an adverb, and when :foo
is just a pair constructor?
So far I think that :foo is an adverb where an operator
is expected, but :for is a pair constructor where a term
is expected.
Why is this difference important?
Perhaps because an adverb goes looking for something to
apply itself to.
How does it decide what to apply itself to?
4) Adverbs apply to the previous unparenthesized prefix, infix,
or postfix operator, bypassing simple terms and other pill
operators such as circumfix or postcircumfix.
But what about the rules for additional arguments as adverbs?
1d) Additional [function] arguments may occur as adverbs *only* if
there are explicit parens.
2d) Given 2c, additional [method] arguments may occur as adverbs
whether or not there is an argument pill:
I assume rule 1d only applies to arglist parenthesis,
and not grouping parenthesis?
The legal syntaxes below all mean the same thing, right?
func(1,2,3,:foo); # ok
func 1,2,3,:foo ; # ok
func(1,2,3):foo ; # ok
func(1,2,3 :foo); # ok (explicit parens)
func 1,2,3 :foo ; # ILLEGAL (according to A12 revision)
And for 2d, these are the same:
.meth(1,2,3):foo ;
.meth(1,2,3 :foo);
Does rule 1d or rule 4 does apply inside this parenthesized arglist?
func( eeney, meeny, miney :moe );
Does :moe apply to func (rule 1d) or miney (rule 4)?
Does it depend on the declaration of miney?
sub miney {...} # simple term: moe applies to func
sub miney(*%adv) {...} # does a slurpy hash make a function a list operator?
sub miney($+moe) {...} # I'll take that moe
sub miney($+curly) {...} # Arg OK, but not that one!
Is this correct according to 2d, assuming func and meth are 0-ary:
say func :foo; # say( func, foo=1 )
say .meth :foo;# say( .meth( foo=1 ) )
but if func is 2-or-more-ary, then:
say func :foo; # say( func( foo=1 ) )
A unary function cannot take an adverb, because it has no slurpy hash.
Is a function with a slurpy hash automatically a list operator,
even if it has 0 or 1 positional arguments?
Do I have my whitespace rules right below?
say foo :bar; # say( foo( bar=1 ) ) assuming foo is listy
say .foo :bar; # say( .foo( bar=1 ) )
say foo: bar; # foo.say(bar)
say foo:bar ; # ?? say foo :bar ??
Adverbs are still passed to the function as just a pair,
so they have to come after positional parameters.
But that's kinda ugly in some cases. Are there ways to get
around it?
If I know the names of the positional parameters, I can put the
adverb (aka pair constructor) first, and pass all the parameters
in via names.
sub foo( $bar, $baz, %*advs) {...}
foo :expletive bar=3, baz=42;
If I think my function would look better with the :adverb
next to the function, and still have positional parameters,
I can just declare foo with no named positional parameters,
and any parameters after the adverb will go in the slurpy array.
Larry also shows this example:
@a.sort:quick:{ +$_ } # both adverbs apply to .sort
Would that work for the functional form too?
sort :quick :{ +$_ } @a;
Does adverbial block find its way into the block parameter,
which was actually declared as an optional positional parameter
(of type Criteria)?
~ John Williams
Re: Synopsis 2 draft 1
On Sat, 14 Aug 2004, Larry Wall wrote: To get a Perlish representation of any data value, use the C.repr method. This will put quotes around strings, square brackets around list values, curlies around hash values, etc., such that standard Perl could reparse the result. XXX .repr is what Python calls it, I think. Is there a better name? Is .dump taken? It reminds me of Data::Dumper.
Re: enhanced open-funktion
On Tue, 13 Jul 2004, Larry Wall wrote:
On Tue, Jul 13, 2004 at 07:24:55AM -0600, Luke Palmer wrote:
: But in Perl 6, you don't have to specify things like that through the
: mode string: you can specify them through named parameters:
:
: my $fh = open $filename :excl;
While that probably works, I think better style would be to use a comma:
my $fh = open $filename, :excl;
That explicitly passes :excl to open as a term in a list rather
than relying on the magical properties of :foo to find the preceding
operator adverbially when used where an operator is expected. We may
have to tighten up the definition of operator :foo a bit, since it's
not always going to be clear which preceding operator is intended.
Even quotes are operators if you squint.
[snip]
I see several directions we could go to clarify this, and I don't
entirely like any of them. [snip]
Operator adverbs are, in essence, postfix operators with weird
precedence. We're going to have to be very explicit about what we
mean by weird here. Unfortunately, this morning I don't feel
very explicit.
My understanding is that the :adverb is at the end because it is passed as
a named argument, which must be after the positional arguments. And that
is certainly unambiguous with the comma.
However we have a precedent in m:i// where the :adverb comes directly
after the operator. It's probably special because it is parsed that
way, but it's so common that I feel I can use it as a precedent anyway.
So if :adverbs are having such a weird time finding their verbs, wouldn't
it be easier to allow them to be placed directly after the verb all the
time? Then the magic is merely moving it into the named args section
instead of wondering which operator's named args section it belongs to.
Then
my $fh = open $filename :excl;
is unambiguously
my $fh = open (circumfix:('$filename', :excl));
while what was actually wanted is written as either of
my $fh = open $filename, :excl; # part of the arg list
my $fh = open :excl $filename; # adverb to open
And besides, I think it reads better when the adverb is next to the verb.
yes, no, maybe?
~ John Williams
Re: The .bytes/.codepoints/.graphemes methods
On Thu, 1 Jul 2004, Juerd wrote: Matt Diephouse skribis 2004-06-30 20:51 (-0400): my $string = Hello, World!; say $string[0..4]; # prints Hello\n $string[7...] = Larry!; say $string; # prints Hello, Larry!\n And that array is one of bytes? graphemes? In general, I like the idea. In [EMAIL PROTECTED], almost the same was suggested, but implemented differently: a string's .bytes method in list context (but isn't it array context, technically?) would dwym. As would the other parts-of-string methods. What if you could add the slice onto the method: my $string = Hello, World!; say $string.bytes[0..4]; # prints Hello\n $string.codepoints[7...] = Søren!; say $string; # prints Hello, Søren!\n The string slicing operator would have to return an array of bytes/codepoints/etc in list context and a substr in scalar context. ~ John Williams
Re: if, loop, and lexical scope
On Sun, 27 Jun 2004, Luke Palmer wrote: Alexey Trofimenko writes: AFAIR, I've seen in some Apocalypse that lexical scope boundaries will be the same as boundaries of block, in which lexical variable was defined. Yep. Except in the case of routine parameters, but that's nothing new. (This may be a bit tangential, but it still concerns scope...) I am reminded of a strange case I came across in perl5, and I wondered how perl6 would behave for the following: $b = 'a'; my $b ='b' , print $b\n; print $b\n; In perl5, this prints: a b Which seems to show that the my $b doesn't actually come into scope until the end of the statement in which it is defined. Is that correct? and what will perl6 do? I know an obvious answer is don't do that, which is what I had to (not) do, but this is a greatly simplified version of some generated code. ~ John Williams
Re: idiom for filling a counting hash
On Tue, 18 May 2004, Stéphane Payrard wrote:
I use over and over this idiom in perl5:
$a{$_}++ for @a;
In perl6, using a hash slice and a hyper(increment)operator:
[EMAIL PROTECTED];
Re: A12: default accessors and encapsulation
On Tue, 20 Apr 2004, Luke Palmer wrote:
There. Now here's the important part: in order to *use* all this, you
import whatever module defines it, and then say:
class Dog {
method foo (?$arg) is accessor {
# accessor code here
}
}
If that's not easy enough for you, well, you're probably out of luck.
It would be even easier if we could put the read-accessor-code and
write-accessor-code in different methods.
class Dog {
multi method foo { ... }
multi method foo ($arg) is accessor { ... }
}
With this syntax, either method could be simply be omitted to create a
read-only or write-only accessor. The tricky part is getting the trait
on foo($) to override foo() correctly.
~ John Williams
Re: A12: default accessors and encapsulation
On Tue, 20 Apr 2004, Luke Palmer wrote:
John Williams writes:
On Tue, 20 Apr 2004, Luke Palmer wrote:
There. Now here's the important part: in order to *use* all this, you
import whatever module defines it, and then say:
class Dog {
method foo (?$arg) is accessor {
# accessor code here
}
}
If that's not easy enough for you, well, you're probably out of luck.
It would be even easier if we could put the read-accessor-code and
write-accessor-code in different methods.
class Dog {
multi method foo { ... }
multi method foo ($arg) is accessor { ... }
}
Ugh! That's what I originally suggested, and it was shot down it was.
My first solution to your problem introduced the traits Cget and
Cset, allowing you to write it like this:
class Dog {
method foo ()
will get { ... }
will set { ... }
{ } # usually empty
}
I guess I bogged down that message with the implementation, so the
result may have been easy to miss.
Well, I think we've come full circle. The get/set is the same as the
presumed current implementation, just with different keywords:
class Dog {
has $.foo
will FETCH { ... }
will STORE { ... }
;
}
I'm not saying there is anything wrong with that, but John Siracusa is
asking for something different, I think. A simple accessor which looks
like a method without having to play with Proxy, FETCH, STORE, etc.
If it still looks like $obj.foo = 1 outside the class, that's good too.
(Delphi and C# can do it; why can't we?)
Getting the multi-methods foo()/foo($) to automagically act as the
reader/writer for a virtual foo attibute seems like it would fulfill
his requirements. foo() already works for the reader, but foo($) needs
some help to make $obj.foo = 1 call $obj.foo(1).
Here's a feeble attempt to do what I suggested:
role accessor {
has $.accessor = 1;
multi sub trait_auxiliary:is( accessor $trait, meth(Any) ) {
my $class = meth.meta.class;
class $class is extended {
# class methods take precedence, so install a method
# in the class is default so it gets called first
multi method $meth.meta.name () is default {
return my $proxy is Proxy (
STORE = { meth($^val) },
FETCH = {
my ($reader) =
grep !$_.meta.default ,
$class.meta.getmethods;
$reader;
},
);
}
}
$meth does accessor;
}
}
class Dog {
multi method foo { ... }
multi method foo ($arg) is accessor { ... }
}
my Dog $spot;
$spot.foo++;
~ John Williams
minimal accessor declaration
On Tue, 20 Apr 2004, Brent 'Dax' Royal-Gordon wrote:
John Williams wrote:
I'm not saying there is anything wrong with that, but John Siracusa is
asking for something different, I think. A simple accessor which looks
like a method without having to play with Proxy, FETCH, STORE, etc.
If it still looks like $obj.foo = 1 outside the class, that's good too.
(Delphi and C# can do it; why can't we?)
C# does it as
...
Interesting. Here's the Delphi version, for comparison.
// the trivial attibute
SomeNumber : Integer;
// the virtual property
// read/write can refer to either a variable or a func/proc
property VirtWrite : Integer read SomeNumber write SetSomeNumber;
procedure SetSomeNumber( in : Integer );
function GetSomeNumber : Integer;
The big win being that one can replace the trivial attribute with a
property, and the interface stays the same.
The perl6 version of that would of course be
class Dog {
method getfoo returns Int {...};
method setfoo(Int $v) {...};
has Int $.foo will FETCH \getfoo
will STORE \setfoo;
}
I'm not saying there is anything wrong with that. I completely agree with
Larry that the correct interface for accessors is $x = $obj.foo = $y;
I'm mainly curious if there is an even simpler way to define the
implementation of the accessor than the above.
The simplest possible rw accessor is
method foo is rw { $.foo };
which basically just makes $.foo available to the outside. When you get
more complex and need to intercept the reading and writing, it's clear
that returning a Proxy object is the best way (so far proposed) to do the
right thing for ($x = $obj.foo = $y) and ($obj.foo++). For convenience
and to avoid being uncool-retro, one also wants to separate the accessor
into read and write multi methods.
multi method foo() returns Int {...};
multi method foo(Int $v) {...};
has Int $.foo will FETCH { .foo } # ignore the name conflict for now
will STORE { .foo($^value) };
The declaration of the has variable to delegate to the above methods now
becomes repetitive boilerplate code, which could be eliminated by a clever
trait. It also interferes with the obvious name for a multi method
reader.
foo() obviously works fine (by itself) as a reader, but foo($) needs some
help. Somehow foo() has to return a Proxy which delegates STOREs to
foo($), and FETCHes to itself. Since foo() works fine as a read-only
accessor by itself, a minimalist approach shouldn't require foo() to add a
trait. foo($) needs the help so it should get the trait.
So I propose (in the request-for-comments sense, not the this should
go into perl6 core sense) that given a trivial accessor:
has $.foo is rw;
the minimal replacement with full read/write control would be this:
multi method foo() {...};
multi method foo($v) is accessor {...};
(And the accessor trait somehow does the magic to define a new foo() which
returns a Proxy which delegates to the declared foo() or foo($).)
~ John Williams
Re: A12: default accessors and encapsulation
On Tue, 20 Apr 2004, Juerd wrote:
Brent 'Dax' Royal-Gordon skribis 2004-04-20 12:58 (-0700):
method buffersize()
will store {
my $sqrt=$^v.sqrt;
die $^v is not a power of two unless int($sqrt) == $sqrt;
$.buffer = \x[0] x $^v;
}
{ +$.buffer.bytes }
Could this be written as:
method buffersize {
+$.buffer.bytes
} will store {
my $sqrt = $^v.sqrt;
...
}
Or does will store BLOCK really have to go before the main block?
The syntax rules in Apocalypse 6 require the main block to be at the
end. http://dev.perl.org/perl6/apocalypse/A06.html#The_sub_form
Re: backticks
On Fri, 16 Apr 2004, Juerd wrote:
Defining ` to be a bareword quoting operator would be only one step away
from what I suggested initially:
1. %hash`key
2. %array`5
3. :key`value
4. say `hello;
This would make it like now, but allowing only one bareword, and
only if it is simple (identifier-ish). Oh, and much easier to read and
type :)
I like the idea of making a bareword quoting operator!
I never liked unbalanced quotations in lisp, and I don't think I will like
them in perl either.
Written language sets a strong precedent that quotations should be
balanced. (Apostrophes are not balanced, but they elide instead of
quote.) I haven't decided how I feel about a bareword quoting operator,
but I am strongly against quoting things with unbalanced quotation marks.
Besides:
say `hello;
say 'hello';
I count one keystroke difference there, and ' is easier to type than `,
so give it some credit for that. You'll spend many, many more keystrokes
explaining to people what the first one means, and why unexpected things
happen if they type
say `hello`;
Just so you don't read too much into that, I will agree in advance that
%hash`key is more apostrophitic in nature. I disagree with that change
for other reasons, but making ` an unbalanced quoting operator is
one step too far.
(But only 1 and 2 really matter to me. 1 more than 2.)
To get an item out of a hash, you can write %varname{key}.
You can also write %varnamekey if there aren't any spaces in
the key. Finally, if the key doesn't have any characters in it
except for letters, numbers and underscores, you can write
%varname`key.
That's not a great way to teach a langage, and for a reference manual, I
think separation into three paragraphs will make things much clearer.
You didn't answer his question, which is less complicated?
Basically, if ` is made a generic bareword quoter, is its plural
form. That makes it easier to explain.
Well, except that it isn't really!
Three different subscripting syntaxes, each with different quoting rules.
I don't find that prospect attractive.
~ John Williams
Re: backticks
On Wed, 14 Apr 2004, Juerd wrote:
I propose to use ` as a simple hash subscriptor, as an alternative to {}
and . It would only be useable for \w+ keys or perhaps -?\w+. As
with methods, a simple atomic (term exists only in perlreftut, afaix,
but I don't know another word to describe a simple scalar variable)
scalar should be usable too.
can then also be written as:
%hash`key
ugly.
$hashref`foo`bar`baz`quux
ugly ugly ugly
%hash`$key
oops, you contradicted yourself here. only be useable for \w+ keys
With some imagination, this can also be used for arrays. That would need
to allow the key to have /^-/ and it poses a problem with hybrids like
$0. Normally []/{} decides whether it's a hash or array dereference, but
for this easy-to-write thing a /^-?\d+$/ should be doable. After all, []
and {} are still available if you need to be explicit.
$0`15 # $0[15]
$0`alpha # $0{'alpha'}
You are repeating the errors of javascript. $0[15] != $0{15}
:key`value
use Some::Module :foo :bar :baz`quux :xyzzy;
I think I would prefer something more intuitive, like :baz=quux
Any [^\w\s] character could be used there unambiguously, and = has the
already existing parallel with command-line args, but ` is just an unused
character.
and ` is in an extremely easy to type place.
... on a us/english keyboard ...
I think %hash`key makes sense. But I'd like to find out if more people
like this idea.
one emphatic negative vote here.
hash subscriptor
On Wed, 10 Mar 2004, Larry Wall wrote:
You subscript hashes with {...} historically, or these days, «...»,
when you want constant subscripts. So what you're looking for is
something like:
if / ?foo ... ?baz ... { $?foo{'baz'} ... $?baz } .../
or
if / ?foo ... ?baz ... { $?foo«baz» ... $?baz } .../
I'm probably a bit behind on current thinking, but did %hash{bareword}
lose the ability to assume the bareword is a constant string?
And why «»? Last I heard, that was the unicode version of qw(), which
returns an array. Using an array constructor as a hash subscriptor is
not a least surprise to me.
~ John Williams
RE: Mutating methods
This brings me to another idea I have.. although I have a feeling you guys
have already thought of it.
Instead of ...
$x = $a + $b + $c + $d;
How about ...
$x = +«$a $b $c $d»
The closest way to what you have written is this:
$x = 0;
$x »+=« ($a, $b, $c, $d);
Or the slightly less attractive (IMHO) syntax invented recently:
$x +=« ($a, $b, $c, $d);
Of course, perl6 will have a built-in reduce function as well (RFC76):
$x = reduce {$^a + $^b} $a, $b, $c, $d;
~ John Williams
Re: Semantics of vector operations
On Fri, 23 Jan 2004, Larry Wall wrote: Sorry, I was just copying the designers of supercomputers in my terminology. So you can really blame Seymour Cray for misappropriating the term. On a Cray, vector processing is just operations applied in parallel to two one-dimensional lists. Unfortunately, I don't think you'll be able to get an apology from Seymour Cray these days... I really only care about the concept--I don't give a rip about the word vector. I can let it go at the drop of a hat. Because of the confusion engendered by overloaded use of the term vector, I've recently taken to calling them distributed operations instead. But that's a mouthful. Maybe we need to make up a new word. But dwimops is a bit too general. Parops, genops, hmm... Maybe we should go back to hyper ops. On the other hand, we could teach the mathemeticians not to assume that their usage of a word is the only usage. :-) I just want to chime in to support dropping the term vector. There are enough people who speak both math and CS that I have noticed a lot of confusion caused by the term, not only in the outer product vs inner product vs what-we-really-mean, but also with stopping at the max or min when working with unequal length lists. I would vote for element-wise for a relatively accurate description, or hyper for short, fun, and not-implying-anything-specific description. I did a quick survey of a few vector math packages to find some math-friendly terms. The operations are usually described as being done element by element. Matlab uses the term array operator, but that may be overused in perl. Octave says element by element. Mathematica uses the term element-wise. Template Numerical Toolkit used both: Array (element-wise). ~ John Williams
grep EXPR, LIST
Perl5 map and grep allow the first argument to be an expression which is passed to the function instead of being evaluated. (Sort of a bare block.) What does the signature for this look like? Is it done with is parsed tricks, or will perl6 require the map BLOCK LIST syntax? I was recently bit by the BLOCK/hashref-EXPR ambiguity here, but maybe that won't happen as often if hashrefs are required to use = instead of comma. ~ John Williams
Re: == vs. eq
On Thu, 3 Apr 2003, mlazzaro wrote: Yes. I expect that internally, that's how it will work. (And agreed, C.ref is probably a good name.) My concern with explicitly comparing refs in order to compare identity is a philosophical one. It may be perfectly acceptable to do it via $x.ref == $y.ref;# do they exist at the same location? but I worry that that is a bit obtuse. I'd rather people didn't have to worry about comparing reference locations, even indirectly, because it leads to thinking you can do things like this: my $loc = $x.ref; ...stuff... $loc == $y.ref;# OOPS: but has $x moved since then? Depending on the implementation, code like that might be dangerous. I don't thing there is any danger. Consider this: my $xref = \$x; ...stuff... print $$xref;# OOPS: but has $x moved since then? Obviously that oops is not a concern. The reference is not necessarily a memory address. The GC can move objects around if it wants, but it must make sure the references to an object still refer to the object. The danger I see with reference comparison involves the perl6 auto-dereferencing, and how to be sure we have a reference-to-an-object and not a reference-to-a-reference-to-an-object. For example: $b = @a; $b.ref; # is this [EMAIL PROTECTED] or [EMAIL PROTECTED] $b.ref == @a.ref; # will this work? should this work? I like the suggestion of =:= in particular because it so clearly relates to bound to, so it feels quite elegant. Personally, I doubt the necessity of yet-another-operator, because I'm not convinced the operation is a frequent one. We may both be biased by our personal coding experience on that count. But, no one can stop you from defining infix:=:= in your own code. ~ John Williams
Re: == vs. eq
On Tue, 1 Apr 2003, Michael Lazzaro wrote: As I said before, I would strongly doubt that there will be an .id method _at all_ on any builtin types/classes -- because unless we used memory location as the id, it would imply that a separate id had to be calculated and stored with each object, which would be expensive, and if we _did_ use mem location as the id, getting and storing the id would be largely useless, since it could change unpredictably. So I would imagine it _is_ possible to test that two values have the same identity, but I would imagine it is -not- possible to actually get what that identity is. There's no .id method, per se, unless you create one yourself. What about the \ (reference) operator? If you take two references to an object, they should compare the same, right? ~ John Williams
Re: == vs. eq
On Tue, 1 Apr 2003, Miko O'Sullivan wrote: =:= is a generic comparison operator that simply calls the value_for_comparison method of the objects on left and right. If they both return the same string, then the expression returns true, else it ^^ returns false. If they don't have that method, that's a fatal error. Their value_for_comparison() methods must have been defined in the same class, otherwise you're comparing apples and oranges. (Yes, I'm sure we can think of a better name than value_for_comparison.) I propose the name str for the value_for_comparison method, and eq for the generic comparison operator. That's how my objects will work, anyway. ~ John Williams
Re: A6: Pipes
On Tue, 11 Mar 2003, Damian Conway wrote: These are basically all just two edge-cases. Namely: @var == LIST and: LIST == @var Have you considered: LIST == @var.operator:= LIST == @var.STOREARRAY LIST == @var.how_do_i_spell_the_assignment_method ?
Re: newline as statement terminator
I'll just weigh in with my vote against this.
On Tue, 4 Feb 2003, Stéphane Payrard wrote:
In the tradition of Perl concision, I would like newline to be a
statement terminator everywhere it can: that is when
a) the parser expects an operator
_and_ b) we are not in the middle of a parenthesised expression.
I agree that this is bad because it will enforce style, which is something
we should _not_ do.
TCL has this rule, with the result that
if (foo)
{
do something
}
doesn't work, because if (foo) is an incomplete statement. So one is
forced into this style:
if (foo) {
do something
}
Note that, for Perl 6, Larry has already opened the path in his fourth
apocalypse:
$x = do {
...
} + 1;
is different from
$x = do {
...
}
+ 1;
Well, I think the motivation was that
m/foo/ and do {
something;
}
print done;
is such a terrible newbie-trap (it was for me, at least), that they had to
do something to fix it.
~ John Williams
Re: Shortcut: ?=
What about: ($var = 'succeeded') ||= 'failed'; On Mon, 3 Feb 2003, Sean O'Rourke wrote: Argh. Please disregard that last message as the ramblings of a pre-caffeinated mind. /s On Mon, 3 Feb 2003, Sean O'Rourke wrote: On Mon, 3 Feb 2003, Dave Mitchell wrote: $var ??= 'succeeded' :: 'failed'; Aha! $var 'succeeded' || 'failed'; Thank you, precedence. /s
RE: arrays, hashes unified indexing syntax impact on future varia tion s on other collection types
Because some things have both, and do different things with each.
Ok $0 is special. But isn't it _the_ special case? And strictly speaking,
its an ordered associative array right? It doesn't really need the full
range of expression offered by $0{...} and $0[...]. All it needs is $0[1]
for ordered lookups and $0[1] for named lookups.
My favorite example of this sort of object is a row from a database.
Each value has a name (the column name) and a position (from the order in
which the columns were requested), so it would be nice to be able access
it either way.
~ John Williams
Re: Spare brackets :-)
On 28 Jan 2003, Aaron Sherman wrote:
I'm not sure I recall the sufficient, yet irrelevant technical reasons.
I certainly can't think of anything. It also helps in the case of
objects that are non truly arrayish or hashish:
my SuperTree $foo;
$foo[Munge]; # Returns the node whose value is Munge
$foo[0]; # Returns a node based on tree-position
The only remaining behavior of braces that I can think of as different
from brackets is auto-quoting, and is there a good reason that brackets
could not auto-quote?
I think you are still overlooking the autovivification behavior.
i.e. What is the difference between these:
1) $a{1234567} = 1;
2) $a[1234567] = 1;
Answer: #1 creates 1 element. #2 creates 1,234,567 elements!
I think that is a big enough difference that perl should not be asked
to guess.
Similar precendents are + vs ~, == vs eq, etc.
~ John Williams
Re: Spare brackets :-(
ECMAscript already tried this.
Bad idea.
If your hash keys happen to look like large numbers (e.g. you
have 7-digit product codes) as soon as you store one of them, it says:
Oh, this looks like a number, so we'll store it like an array and
happily creates a million empty array entries for you.
~ John Williams
On Tue, 28 Jan 2003 [EMAIL PROTECTED] wrote:
This may sound like a silly idea but ...
Has anyone considered removing with the syntactic distinction between
numeric and string indexing -- that is, between array and hash lookup?
In particular, it would seem that
%foo[$key]
would be just as easy for the compiler to grok as
%foo{$key}
but would mean that we could stop worrying about the precedence of
postfix/infix {, and things like
if %test { $count++ }
would not require whitespace before the { to be disambiguated.
I don't have a complete solution as anonymous array and hash construction would
still need different syntaces, but has anyone else thought about this?
- Martin
Re: More Array Behaviors (Take 2)
On Tue, 28 Jan 2003, Dan Sugalski wrote: At 10:13 AM -0800 1/28/03, Michael Lazzaro wrote: @a[ Inf ] # undef (warning: can't use Inf as array index) I'd throw an exception here. @a[-4]# undef (warning: index out-of-bounds) @a[-Inf] # undef (warning: can't use Inf as array index) Or zero, since it's an int array. If you throw an exception for +Inf, you should throw it for -Inf too. ~ John Williams
Re: More Array Behaviors
On Mon, 27 Jan 2003, Michael Lazzaro wrote: Some requests for verification, plus additional questions. If anyone has any arguments/clarifications/questions on these, please discuss so I can document. 1) Edge cases in array indexing: @a[ undef ] # undef, or 1? @a['foo'] # undef, or 1? These should generate warnings, at least. I don't know whether undef or 1 is more correct. Perl5 chooses 1, but it's smart enough to distiguish between $a[1e0] (returns 2) and $a[1e] (returns 1 and a non-numeric warning), so it's definitely choosing to return $a[0] for non-numeric indexes. (0+1e is 1, not 0) Is [undef] the same as [0] in Perl6? Is there any index value you can give that will cause an exception? What about @a[NaN]? Just another warning probably. ~ John Williams
Re: Variable Types Vs Value Types
On Thu, 9 Jan 2003, Peter Haworth wrote: On Wed, 8 Jan 2003 15:39:52 -0500, Dan Sugalski wrote: At 7:29 PM -0700 1/7/03, John Williams wrote: Perhaps you could explain how the $0 object will work in your mind. A5 assert that $0 is a object, and it behaves as an array and a hash, depending on how you subscript it. Typeglobs are gone, and we're all hoping the TIE interface is gone too, so how will this effect be accomplished? All variables in parrot are implemented as PMCs, and all PMCs may be accessed with a string, integer, or PMC subscript or set of subscripts. For PMCs that don't do subscripting this will be a fatal error, for those that do it'll do whatever the PMC is supposed to do. (In the case of $0, do the lookup) That's phrased like it's the type of the subscript value which determines whether it's a hash-like or array-like access. Shouldn't it be the type of brackets which do that? Yes, that's what I meant, even if I didn't say it clearly. How you subscript it would be either with brackets or with braces. ~ John Williams
Re: Variable Types Vs Value Types
On Fri, 3 Jan 2003, Dave Whipp wrote: John Williams wrote: Do they? One is obviously an array, and one is obviously a scalar. You may get an error (cannot alias an array as a scalar) or $b get aliased to the array-in-scalar-context (a reference). This is one of those how we think about the fundamentals things. I am taking the viewpoint that everything is in object. How you or I think about the fundamentals is a moot point, really. Objects are not covered until apocalypse 20-something, so the main thing we have to go on is Larry's statement to the effect that things will behave like objects if you treat them like objects. One of the issues I hoped to provike discussion of is the difference between $b = @a; and $c := @a; The former obviously creates a reference to the array; but does the latter? That is a good question. Someone wiser that me will have to interpret the true meaning of $c := @a;. An ArrayRef is an object that provides indirection to an array object. But for $c, I have requested a binding, not an assignment. $c should hold, literally, the same object as @a. If an ArrayRef is a new object, then we shouldn't create this new object as part of a binding operation. Saying an Arrayef is a different object from an Array may be taking the analogy a bit too far. They are different things, yes, but since perl6 references dereference automatically, calling an method on an ArrayRef will be the same as calling a method on the Array it references. If only objects have types then yes, you'd override the .num method. But that sidesteps the issue: what if a *variable* has its own behaviour. Well, I suspect that would be a bad idea. One of the really annoying things about most OO languages is that if I call my Geo Prizm a Vehicle, it suddenly forgets that it is a Geo Prizm. So $ParkingLot.Vehicle[38].door.open() would fail because not all Vehicles (motorcycles) have doors. I really hope that a weakly-typed, OO language will free me from type-casting hell. If variables get to have their own behavior, then you have accomplished the same thing in a different way. We will have to typecast our cars/objects every time we go the the parking lot/collection, because we want them to stop acting like generic vehicles/superclasses. my Foo $a = ...; my Bar $b := $a; Assuming that Foo and Bar are both compatible with the referenced object, To be compatible, they have to be the class of the object or a superclass of the object, right? (Have the interface of is like saying it's a superclass for languages that don't have multiple inheritance.) do both $a and $b behave identically? Or can the variable's type influence the behavior of that variable ... This might seem like a silly thing to want to do; Yes. but it seems to me that there are often cases where we want different behaviors in different contexts. There may be cases, yes. Making it the default case is a probably a really bad idea. Hopefully my example above illustrates why. If you are in that case, I imagine you can just do $a.Bar::xxx() or $a.Foo::xxx() to get what you want. ~ John Williams
Re: AW: my int( 1..31 ) $var ?
On Sat, 4 Jan 2003, Murat Ünalan wrote: print creditcard if $var == CreditCard( 'VISA' ); wich should do a mod10 on $var and then match a regex or something. I think one could say CreditCard( 'VISA' ) is then the property. And after reading further seeing it could be smart matched like: print creditcard if $var ~~ CreditCard( 'VISA' ); Brought to a point: Properties could be also smart matched. Wouldn't it be easier to say: print creditcard if CreditCard( $var ) eq 'VISA'; ~ John Williams
Re: AW: AW: my int( 1..31 ) $var ?
On Sun, 5 Jan 2003, Murat Ünalan wrote:
Properties *can* be smart-matched:
print creditcard if $var.prop().{CreditCard} ~~ 'VISA';
or:
print creditcard if $var.prop{CreditCard} ~~ 'VISA';
or:
print creditcard if $var.CreditCard ~~ 'VISA';
I think this is similar to John Williams suggestion:
print creditcard if CreditCard( $var ) eq 'VISA';
Well, no. In my suggestion, CreditCard is a sub which checks whether $var
is a valid credit card, returning the card type.
In Damian's example, he is assuming $var already has a property assigned
to it called CreditCard possibly containing the value 'VISA'. So his has
less processing they either of ours.
The problem I see with:
print creditcard if $var ~~ CreditCard( 'VISA' );
is that CreditCard does not know what $var is. Even if you overload the
smartmatch operator on $var's class, it is still comparing $var with the
value returned from CreditCard.
sub CreditCard
{
#connect to a specific database (VISA, MASTERCARD, ..)
#compare with non-blocked or valid cards
}
...
Excerpt: My concept is to have a twofold view about properties. One
thing that is attributing a type during decleration, and something that
could verified against in other context. All my thinking on that
orginates from Damians Attribute::Type.
Hopefully i do not confuse you too much.
A sub is not a property. It might be a method, which could sometimes look
like a property (as in Damian's third example), but you have strayed so
far away from properties that you are talking about something else now.
~ John Williams
Re: Variable Types Vs Value Types
One of the wise may override my evaluation, but... On Thu, 2 Jan 2003, Dave Whipp wrote: Can the type of a variable vary independenty of its value? My understanding is that the type of a variable merely restricts the type of value you can assign to it. (Well, it probably does more, but I'm not clear on what or how yet.) Consider the following: my @a = (1,2,3); my $b := @a; @a and $b both refer to the same object. $b's object has methods such as PUSH, POP, etc, as does @a's. Do they? One is obviously an array, and one is obviously a scalar. You may get an error (cannot alias an array as a scalar) or $b get aliased to the array-in-scalar-context (a reference). So the type of the value (object) is the same in each case, but the variable's types are different. OK, I'll assume $b is a reference to @a. The difference becomes very obvious when you start doing DWIM stuff. Consider this code: print @a + $b This will evaluate each, in numeric context. To get at those numbers, Perl will translate this to something like print @a.FETCHSIZE + $b.FETCHNUM And will promptly get a run-time error for the latter (maybe just a warning). No, as smylers said, an arrayref in numeric context is the length of the array. (Arrays and arrayrefs behave the same in scalar context, if I'm paraphrasing Larry correctly.) Now consider a more extreme (and probably very bad) example: imagine we want to (lexically) redefine how an array behaves in numeric context: Lets say that we want it to use the sum of its elements, not its size. We don't want to modify the object itself (except to give it the Csum method): we simply want Perl to use the object slightly differently: my @a = (1,2,3) but implements_sum_method; # add .sum method to vtable my SummingArray $b := @a; Actually, (unless implements_sum_method is a subclass of SummingArray,) it looks like an error to me, because @a is an array and/or an implements_sum_method, but $b is restricted to holding a SummingArray. We're getting into areas of but which I'm not sure about, but if SummingArray is a class which impliments .sum and overrides .num to use it, then this might work (with the same caveats about aliasing an array to a scalar): my @a = (1,2,3) but SummingArray; # or subclass of summingarray my SummingArray $b := @a; The type of $b refers to the variable's type, not the object's. But the value's type is what will be used in vtable lookups, I assume. Let us suppose that the type-definition syntax allows us to tell perl: when you use this variable in numeric context, call your object's Csum method.. now, when we code That would happen when you override the .num method, or whatever the value-in-numeric-context method is called. print @a + $b; perl maps this to print @a.FETCHSIZE + $b.sum; or to: print @a.Array::num + $b.SummingArray::num; and prints 9. We don't need the variable-type magic, of course. We could have just said print @a + @a.sum; and gotten the same result. But the ability to express the behaviour of variables, independently of values, could be useful (and more powerful than a ctie). Or it might just cause confusion. As counter-example, consider: my Array @array := SpecialArray.new; Should the value in @array act like an Array or a SpecialArray? Most people would say SpecialArray, because a SpecialArray ISA Array. I can interpret what you are saying as sometimes, WIM is to act like Array, in which case, that's not what most people mean, so you need to be more explicit somehow. I can also interpret what you want as saying my SpecialArray @array := Array.new should autopromote the value to a subclass somehow, which would be very strange. I'm no OO guru, but trying to call a method which is only defined in a subclass of an object's class is probably not going to work. On the other, other hand, if the SpecialArray class has defined a constructor or assignment operator which accepts an Array, then you have told the compiler how to do the desired autopromotion (although I still doubt it would work with an alias-operator), and it can mostly DWYM, although the type of the value has actually changed in this scenario. ~ John Williams
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: purge: opposite of grep
On Wed, 4 Dec 2002, Miko O'Sullivan wrote: FWIW, I came up with purge because my first inclination was to spell grep backwards: perg. :-) While purge is cute, it certainly is not obvious what it does. Of course neither is grep unless you are an aging unix guru... How about something which is at least obvious to someone who knows what grep is, such as vgrep or grep:v? Or maybe that's not any better than grep !(...). ~ John Williams
Re: Primitive Vs Object types
I gotta admit that this issue is bugging me too. Larry mentions (in http://groups.google.com/groups?hl=enlr=ie=UTF-8selm=Pine.LNX.4.44.0210140927520.20533-10%40london.wall.org) that all-uppercase is ugly and has boundary conditions. Maybe it would be helpful to know what conditions are causing problems. All-lowercase implies that we want them to be used *more* than the object types. But it seems like we should encourage the use of the object types. Maybe that's because we want to discourage undef values, but I've been programming databases too long, so I like undefs now. We certainly don't want to discourage using the autopromoting Int - Long - Bignum features of the object types, do we? Also the typecasting functions have been defined in all lower case, which would suggest to the naive user that they will typecast to primitive types, and perhaps even throw an exception when an undef is cast. On Wed, 6 Nov 2002, Michael Lazzaro wrote: David Whipp wrote: Dan Sugalski [mailto:dan;sidhe.org] wrote: At 6:50 PM -0800 11/6/02, David Whipp wrote: Whenever a value passes through a primitive type, it loses all its run-time properties; and superpositions will collapse. What makes you think so, and are you really sure? If I am wrong, then I am in need of enlightenment. What is the difference between the primitive types and their heavyweight partners? And which should I use in a typical script? It has been stated multiple times that primitive types can't take runtime properties or other object-like features, so that they may be as lightweight as possible -- flyweight classes, as it were. 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. I don't think the point is to store them as small as possible, but as efficiently as possible. That is, in whatever register size the hardware works best on. We don't want to compact unrelated bits into a single hardware address, because then we are forced to do extra masking and shifting everytime we want to use the value. ~ John Williams
Re: Perl6 Operator (REMAINING ISSUES)
On Fri, 1 Nov 2002, it was written: On Fri, Nov 01, 2002 at 10:35:08AM -0800, Ed Peschko wrote: So again, I don't see the difference between the two. ^[+]= and ^+= are synonyms as far as I can see, and hence no need for the first form. Only in the absence of overloading, and only because we've naively defined array ops to always do union rather than intersection. If there were a vector op that took the shorter of two arrays as the overall length, then a = a »op« b Ooo! I have it! a »op« b # picks the shorter of the two lengths (intersection) a «op» b # picks the longer of the two lengths (union) Maybe the hyper-hash guys could work with it too. ~ John Williams
Re: Perl6 Operator List, Damian's take
On Tue, 29 Oct 2002, Austin Hastings wrote: Any of you OO guys know of a case where $a = $a + $b; # A [+]= B; -- A = A [+] B; and $a += $b; # A [+=] B; should be different? They are different in the scalar [op] list case, as explained here: http://archive.develooper.com/perl6-language%40perl.org/msg10961.html ($a = 0) [+=] b; # sum ($a = 1) [*=] b; # product ($a ='') [~=] b; # cat ~ John Williams
Re: Vectorizing operators for Hashes
On Wed, 30 Oct 2002, Me wrote: %a ^:union[op] %b %a :foo[op]:bar %b I think that any operators over 10 characters should be banished, and replaced with functions. ~ John Williams
Re: perl6 operator precedence table
On Thu, 17 Oct 2002, Adam D. Lopresto wrote: : It's rare enough to need bitwise things in Perl 5 (outside golf). I'm : hoping that it'll be even rarer in Perl 6, as better interfaces are : designed for the things which at present require flipping individual : bits. I almost wonder if it's wrong to waste ~ on it... That would be an argument for b| and b, I suppose. That looks like about the best. When rare things get too punctuation-heavy, people start to get really confused. I agree. b| and b are the first operators which look good to me. Most of the other proposals look like line-noise, and I would hate to have to start agreeing with perl-detractors. Bitand and and bitor work for me too. ~ John Williams
Re: Draft Proposal: Attributes: public vs. private
On Sat, 12 Oct 2002, Larry Wall wrote:
On Sat, 5 Oct 2002, John Williams wrote:
: Personally, I hope they look like attributes.
They will, outside the class anyway. Inside it's $.foo.
: But if they do, the perl5
: lvalue subs are not the way to do it. Why? Because an lvalue sub returns
: a lvalue which get set _after_ the sub returns. At that point it is too
: late for the sub to do anything useful with the new value.
Lvalue methods will have some kind of optional property which specifies
a closure to execute after the modification happens.
method foo {
my $handle = find_database(random criteria);
return $handle.fetch();
WRITE {
$handle.store(shift);
}
}
Or some such. Note how the internal block allows capture of the $handle from
the original closure. (A READ closure was also discussed in Zurich.)
That looks good. I was actually imagining some sort of tie-like routine
which would be called whenever the variable was accessed.
method foo is accessor ($stuff_i_might_need_to_know, $new_value) {
if exists($new_value) {
...
$.foo = $new_value;
}
...
return $.foo;
}
lvalue methods still seem to work in reverse to me though. If I say
$x = $object.foo = $y;
then first an lvalue accessor returns an object to receive the value of
$y. Next the write (oh by the way...) closure is called. Finally the
value of $y is passed on to $x, but its too late for foo to change its
mind about what its own value will be if something in write{} caused the
collapse of its quantum state.
An accessor like the above could return a different value than it was
given, which would admittedly be an odd thing to do, but perl users being
what they are, someone would think of a reason to do it.
By the way, which apocalypse will describe how properties work?
It seems like they will need some similar way of taking control when a
variable or value (or method or class or whatever) is accessed.
~ John Williams
Re: [ANNOUNCE] Perl6 OO Cookbook, v0.1
On Wed, 9 Oct 2002, Michael Lazzaro wrote: PLEASE contribute to this document! Email me with suggestions, yes or no votes on recipe approaches, info on philosophies or best-guess syntax, etc., or discuss them here on perl6-language. Very nice. I hope this evolves into a useful perl6 reference. Here are some comments on section 1. Recipe 1.6 my $obj = MyClass.new(...); # synonymous, if ... is empty Yes. my $obj = MyClass(...); This seems to assume that objects have a default method if you treat them like a subroutine. Kinda tcl-ish, but I don't recall anything like this in the apocalypes. my $obj = MyClass; I think $obj would contain a reference to MyClass, not an instance of MyClass. my $obj is MyClass; # similar to above, but autovivifying? This declares $obj as a MyClass, but does not instantiate it. If I recall the discussion on this subject, the preferred syntax was my $obj is Myclass .= new(...); Notice that you still have to explicitly invoke the new method. The is MyClass merely prevents you from assigning a non-MyClass value to $obj. The difference between my $i is int = 3 and my $obj is MyClass = MyClass.new is that 3 is already an instance of int. MyClass does not have a textual representation which the compiler will recognize unless you perform some source filtering/lexical rules tricks. The theory about being autovivified according to the default constructor is nice, but I think it is not true. If you do not explicitly assign a value to a variable (number, string, or object), it gets a value of undef. Autovivification refers to the automatic creation of the *variable*, not the value. If you use a variable before declaring it, the variable is created with a value of undef. Similarly, if you use a hash or array item which does not exist, it is autovivified with a value of undef. Recipe 1.10 1.11 Issue: Or can you? In perl5, class methods are the same as instance methods. The difference is that they receive a class reference as $self instead of an object instance. (perl5 class references happen to be strings, but we won't hold perl6 to that.) So it is not yet known whether class methods in perl6 will have any greater distinction from instance methods than that. Recipe 1.15 I think the thought here was to use the binding operator. my ClassAlias := MyClass; ~ John Williams
Re: perl6 operator precedence table
On Tue, 8 Oct 2002, Larry Wall wrote:
: but I think the latter is unnatural enough that it deserves parens, so I'd
: put 'but' above comma (and probably '='), but below just about everything
: else.
Could perhaps unify with C... Wouldn't hurt for it to be
non-associative like C...
'Is' and 'but' return their left operand to allow chaining, so don't 'is'
and 'but' need to be left associative so the following will work?
0 but true but string('zero rows affected')
I'd be more inclined to unify and | with * and +, since that's
exactly what they are in Boolean algebra, where 1*1 == 1. I think
the argument that it breaks C compatibily is weak in this case,
since almost everyone admits that C is broken in this respect.
Good point.
Alternately, we take | and away from bitwise ops and do something
more useful with them. I have been asked privately by a sight
impaired person to consider using | as the separator for parallel
streams rather than the almost invisible ; character, for instance.
Being a bit sight impaired myself at the moment, I have great empathy...
| and do one thing different from + and *. They impose integer context
on their operands, rather that just numeric.
How about moving ** down to just above *? There's no precedence from C,
and -$a**2 is a bit counter-intuitive mathematically. I'm not sure
what the intuitive behavior should be for the other unary operators
though.
I can post a revised table if the associativity of 'but' is clarified.
~ John Williams
my $zen = true but false;
Re: RFC: [] as the solitary list constructor
On Sun, 6 Oct 2002, Luke Palmer wrote: Do parens still provide list context on the left side of an assignment? What do these two do: my $x = ARGS; my ($y) = ARGS; Parens just grouping suggests that C$x and C$y should be the same (which may well be good, as it's a subtle distinction which trips up many beginners in Perl 5). If so, what's the preferred way of getting the 'other' behaviour? Maybe:? my ($y) ^= ARGS; That's like saying $y = ARGS[$_] for 0..+@ARGS; so $y will probably end up with the _last_ element of ARGS. I suggest: my $y = shift; # if this still works in perl6 my $y = ARGS[0]; ~ John Williams
RE: We need an OO issue list tutorial!
On Fri, 4 Oct 2002, [EMAIL PROTECTED] wrote: Perhaps to go with Apocalypses and Exegeses we could have Psalms, a bunch of bitsize perls of wisdom. Except, um, psalms are, by definition, sacred, so, um, I dunno, just a thought. Larry? Proverbs?
Re: We need an OO issue list tutorial!
On Fri, 4 Oct 2002, Michael Lazzaro wrote: Observation: We're doing a *lot* of talking past each other. Proposed Remedy: We need to better document our discussions so that we don't keep having them. --- I volunteer (*shudder*) to be another grunt secretary and start compiling a preliminary document, written as a tutorial for newbies (because we are *all* newbies when it comes to perl6 OO) that covers perl6 OO philosophies as they evolve -- if everyone is ok with that idea, and if nobody else is already doing it. Yeah! Derived from the RFCs and subsequent discussions, here is a proposed OO Bill of Rights: fundamental truths that I *think* are already agreed upon, and from which all other OO laws must be derived: (OO Article 1) It should be possible, in general, to do anything you did in perl5 in perl6. (OO Article 2) perl6 should not be geared towards any one OO methodology. (OO Article 3) There should no longer be any hint of the implementation of perl objects as hashes. (OO Article 4) perl6 objects must be able to be used *universally* as fully-fledged built-in types: scalars, arrays, hashes, etc. (OO Article 5) perl6 OO -- at least, some definable subset of it -- needs to be runtime-friendly. (OO Articles 6) Also considered drop-deads: interfaces, assertions (of various sorts), multiple inheritance, complex delegation. Can we at least agree on these? Are there other basic tenets that should be included? Bravo! I suspect everything mentioned in article 6 except multiple inheritance could be delegated (no pun intended) to the zealots mentioned in article 2. If we can reach some consensus, the next step is to start presenting the ~10 (by my rough count) fundamental open issues that are screwing everything else up. I think it would help immensely if we knew some details of the implementation of is properties. From the plethora of things they are expected to do, it seems like every variable access or subroutine/method call or maybe even block invocation will need to be able to be intercepted by property classes (or whatever they are). This would certainly make perl5 'tie's easy to abolish. But there may be sticky issues about who gets called first when something has multiple properties. A think a lot of the syntax discussions could be narrowed down better if we had some inkling of the implementations. (Since properties are completely new in perl6, which apocalypse do they belong to anyway?) ~ John Williams
Re: Delegation syntax? (was: Re: Private contracts)
On Thu, 3 Oct 2002, Michael Lazzaro wrote:
1) Delegation through inheritance:
(a.k.a. mixin classes, hard delegation, concrete interfaces,
etc., etc.)
Example: I want to say that a class DataManager has the capabilities
of the interfaces DataStrategy and CacheStrategy, but is not strictly a
subclass of either. In other languages, this might appear like:
class DataManager implements DataStrategy, CacheStrategy { ... }
- or -
class DataManager mixin DataStrategy, CacheStrategy { ... }
Aside from runtime mixin', in what way does inheritance _not_ do what you
want?
2) Delegation through attribute:
(a.k.a soft delegation, instance-based delegation, etc., etc.)
The ability to specify that, if an instance of an object DataSnippet
is affiliated with a specific, runtime instance of a DataManager, e.g.
class DataSnippet {
attr $data_manager is DataManager;
}
... then [some, all] public methods of $self.data_manager can
automatically be delegated by the DataSnippet to that specific
instance, eliminating the need for code that makes you want
to kill yourself:
method foo (...) { $self.data_manager.foo( ... ) }
method bar (...) { $self.data_manager.bar( ... ) }
# ... repeat until carpel tunnel syndrome sets in ...
Reaction #1: Only on a perl list would it occur to people to complain
about that. :)
Reaction #2: Inheritance would automatically delegate all those
methods, so again, in what way does inheritance _not_ solve the problem?
Finally, a question about interfaces:
In what way is an interface different from a pure abstract class (i.e.
containing only method declarations, but no code)?
~ John Williams
DISCLAIMER: This post assumes perl6 will have multiple inheritance.
Re: Private contracts?
On Thu, 3 Oct 2002, Trey Harris wrote: Incidentally, has there been any headway made on how you DO access multiple classes with the same name, since Larry has (indirectly) promised us that? I.e., I import two classes LinkedList and BTree, both of which define a Node class? Hopefully, LinkedList defines a LinkedList::Node class, and BTree defines a BTree::Node class. Either by explicitly naming them that or by virtue of being defined as an inner class (which might also make it private). ~ John Williams
Re: for loop and streams
On Thu, 26 Sep 2002, Sean O'Rourke wrote: Different operators doing different things sounds awful to me, because it makes it hard to predict what will happen, because new operators will have to be able to control what they do with their operands, and because new types of array-like operands will have to tell operators how to treat them. Blech. Maybe treating lazy and/or infinite data structures as infinitely short for this purpose would capture most of what we mean, so hype(A,B) would take the longer of two finite lengths, the more finite of a finite and an infinite length, and infiniti for two infinite operands. Sounds reasonable. Of course, this still doesn't account for what kind of extension makes most sense for a given operand/operator pair. It seems to me that anything more complex than undef (which is consistent with out-of-bounds array accesses) would be a nightmare to get right. We should respect default values if arrays can declare them. Perhaps there will be a modifier for operator declarations to declare what the default behavior should be. Otherwise I don't know how different behaviors for different operators would be possible, especially for user-defined operators. sub operator:foo is hyper_default(1) ... I agree with Blech, but we can procrasticate doing it at least until Damian makes it clear how operators will define their behavior. Otherwise, a contextualized undef (0 in numeric context, '' in string) would seem DWIM to me. I wouldn't want to throw tons of warnings from one operation, so maybe hyper-operating on unequal lengths gets a new warning, instead of throwing lots of 'undefined value' warnings. ~ John Williams
perl6 operator precedence table
I'm trying to write a revised operator precedence table for perl6,
similar to the one in perlop.pod.
This is what I have come up with based on Apocalypse 3 and Exegesis 3.
Does anyone have comments? I'm not sure if the precedence
for : (adverb) or 'is' and 'but' are quite right.
perl6 operator precedence
leftterms and list operators (leftward) [] {} () quotes
left. and unary .
nonassoc++ --
leftis but
right **
right ! \ and unary ~ + - * _
left=~ !~
left* / % x
left+ - _
left
right named unary operators, -X
left = = lt gt le ge == != = eq ne cmp
left
left| ~
left
left|| ~~ //
nonassoc.. ...
right ??::
right = := **= += -= _= *= /= %= x= = |= ~=
= = = ||= ~~= //=
left, =
left;
left:
nonassoclist operators (rightward)
right not
leftand
leftor xor err
Here is a list of changes from perl5:
. becomes _
- becomes .
== etc unified with etc, and given left associativity
binary ^ becomes ~
?: becomes ??::
added ~~ // err
added ; with lower precedence than ,
added unary * and _ with same precedence as unary + -
added binary :=
added unary . with same precedence as binary .
( .foo === $self.foo )
added : (adverb operator) with low precedence(?)
print foo: $x, $y, $z; # lower than ,
my $fh = open $filepath : mode='rw'; # lower than =
added 'is' and 'but' with high precedence(?)
my $thing is constant = 3 but false;# higher than =
Larry mentions that other precedence unifications are possible. I can see
the following as possibilites. Are there others?
with
| with ||
with * /
~ John Williams
Re: Regex query
In a message dated Tue, 24 Sep 2002, Chip Salzenberg writes: then what about $a = (1) ? And if someone says that I have to write: $a = (1,) then I am going on the warpath. That Way Lay Python. You _can_ write that, but you don't _have_ to. [1], (1), list(1), or maybe other things will work too. But (1) is not enough in scalar context. On 24 Sep 2002, Aaron Sherman wrote: The crux of the no-parens for lists discussion has been the idea that in the current state of affairs, square brackets are a pointless tumor on the syntax of Perl 6. You don't need them, not ever... almost. You can do: $x = (1,2,(3,4),(5,(6))) And everything except for that last C(6) will be an anonymous array, constructed for your viewing pleasure. Of course (again, NOT PROPOSING ANYTHING, just citing how it is supposed to be now): $x = [1,2,[3,4],[5,[6]]] Will do what you intended, but now we're keeping brackets on just for the single-element anonymous array feature, which is one hell of an impact on the syntax for such a small feature. Larry's comment about [1,2,3] being mnemonic because we use a[1] to index arrays was an excellent point. Since [1,2,3] works for both $a = [] and a = [], maybe we should consider dropping the parenthesis instead of the brackets. (And I was the putz that first suggested that brackets might be superfluous.) Of course, that won't stop commas from creating lists. On Tue, 2002-09-24 at 11:07, Trey Harris wrote: push a, (7,3,2); would push the elements 7, 3 and 2 to the end of a, but push a, [7,3,2]; would push a single element containing the arrayref [7,3,2] onto the end of a. From reading the apocalypses, I think Larry, et al, are aware of this, and I fully expect the situation to be clarified when the next apocalypse comes out. Maybe we should have a pool for the release date? :) That doesn't really work. Because now you introduce the case where: $x = (1,2,3); y = (1,2,3); $z = [1,2,3]; push a, $x, y, $z, (1,2,3), [1,2,3]; Behaves in ways that will take hours to explain to newbies, and I assure you it ain't WIM. Not even a little bit. The parenthesis have no effect because they are only grouping. So the only question in my mind is whether y gets flattened or is treated as a single object. In either case, we can clarify our meaning by writing *@y to force flattening or \@y to prevent flattening. ~ John Williams
Re: Paren madness (was Re: Regex query)
On Tue, 24 Sep 2002, Mike Lambert wrote: $a = (1, 2, 3); # Same as Perl 5's $a = [1,2,3]; $a = (1) should then do $a = [1], according to the above. This implies that: ($a) = (1) implies that $a is [1], something I don't particularly agree with. You may be missing the change in the comma operator. Perl5 uses the return the rightmost value comma from C. Perl6 is changing the comma to a list constructor. So (1,2,3) is definitely a list, but (4) probably isn't. If I understand our non-conclusions so far, we're waiting for Larry to clarify: 1) how to create a 1-tuple/1-item list? 2) how to interpret the flattened list context? e.g. given this: $x = (1,2,3); y = (1,2,3); $z = [1,2,3]; push a, $x, y, $z, (1,2,3), [1,2,3]; What flattens, what doesn't, and how do you override the behavior? Is there anything I missed? ~ John Williams
Re: s/// in list context
Two weeks ago, Nicholas Clark wrote: So would it be possible for s/// to have the same return values as m// in perl6? Since no one authoritative has responded to this, I will just add my support that it seems like a reasonable request. s/// currently returns the number of substitutions made. Otherwise it returns false. If s/// were to return the $0 object from its matching pass, $0 would evaluate to true or false in boolean context, depending on if a match was successful, and would evaluate the number of matches in numeric context. Which is the same behavior as the perl5 s/// return value. (Actually s/// returns on no matches now, whereas $0 would evaluate to false or 0 depending on context, but I doubt that would be a serious compatibility issue.) And getting the matching values before substition was done is a bonus in list context. ~ John Williams
Re: Paren madness (was Re: Regex query)
On Mon, 23 Sep 2002, Trey Harris wrote:
So then, I think if there's just some clarification about how one-tuples
are formed, I think everything I wrote in my earlier mail can DWIM
correctly. There seems to be no magic here, quotations from LoTR to the
contrary. :-)
Your post was very helpful to pull us back to sanity.
Allowing list context to create a 1-item list out of a scalar makes sense
in my mind. (ie a = 7 sets a[0] to 7).
~ John Williams
P.S. Caution: this way lies madness...
In perl5, to get the 'x' repetition operator to do a list repeat, it
must be in list context _and_ the left side must be in parenthesis. Will
this strange combination of syntactic context and semantic context still
apply in perl6? Would it be simpler if it only relied on the scalar/list
context?
After testing various cases of x, I came up with one that I cannot
explain. Can someone tell me what is happening here (in perl5)?
$ perl -le 'print {[ $a = ('a','b') x 3 ]}; print $a'
a bbb
bbb
or in other words, after evaluating a = $a = ('a','b') x 3,
$a is 'bbb' and a is ('a','bbb') !
Re: Regex query
On Sat, 21 Sep 2002, Jonathan Scott Duff wrote: Why can't perl be smart enough to figure out what we mean? Something along these lines: (7) # list context (3+4) # numeric context (there's a numeric operator in there) (3+4,5) # list context (comma trumps the numeric op) My understanding of context (which admittedly, may be completely incorrect) is that context is imposed from the outside. So in (3+4), 3 and 4 are in numeric contect because the '+' says so, but we can't tell what context (...) is in, because there is no context. + has higher precendence than comma, so the 3+4 becomes 7 before the comma creates a list: 7,5. A different workaround just occurred to me for perl6. Maybe instead of (7) having list context imposed by the parenthesis, imposing list context on a scalar automatically creates a 1 item list. So: a = (7); is the same as a = 7; And actually, that works in perl5 too. So maybe we're arguing about nothing? (7,) is an abomination. It's one of python's misfeatures that annoys me the most. Strangely enough, it's one of the features of perl that I really like, although you have to think of it in the context of ( 'a', 'long', 'list', 'of', 'items', 'one', 'per', 'line', # -- notice the comma! ) Of course, _requiring_ the comma is bad, but as long as we can use [7] or rely on list context creating a single item list out of a single item, it is not required. ~ John Williams
Re: Regex query
On Sat, 21 Sep 2002, Jonathan Scott Duff wrote: I can't tell whether (7).length is asking for the length of 7 or the length of a list, but I would be badly surprised if (3+4).pow(2) returned 1 instead of 49. So, you expect 7.pow(2) to work? I'd expect it to be an error (this isn't python after all). Larry said in Apocalypse 2 that things should act like objects if we ask them to, but I suppose the details will wait until Apocalypse 10-12. Maybe 7.operator:**(2) would be more correct. Anyway, (7) or (3+4) should yield a number, not a list, because otherwise every math expression will break. Consider: $a = (7); $b = ( $x + $y ); Both () are in scalar context, not list or numeric. You can easily make it a list with (7,) or [7] but you could only make it a number with numeric(7) (if the numeric() counterpart to scalar() exists). +(7) could still be the length of a list. Of course there are non-numeric contexts too, such as (a). Would it be fair to say that parenthesis should not alter the context when used in expressions? ~ John Williams
Re: Regex query
On Fri, 20 Sep 2002, Larry Wall wrote: Yes, in fact any list forced into scalar context will make a ref in Perl 6: $arrayref = (1,2,3); That would seem to obviate the need for brackets to define array references. Is there any case where [1,2,3] would be needed instead of (1,2,3)? Also, does any list include a list of pairs? Because that would look more like a hash than a list. $ref = ( one = 1, two = 2, three = 3); ~ John Williams
Re: Regex query
On Fri, 20 Sep 2002, Larry Wall wrote: On Fri, 20 Sep 2002, John Williams wrote: : On Fri, 20 Sep 2002, Larry Wall wrote: : : Yes, in fact any list forced into scalar context will make a ref in Perl 6: : : $arrayref = (1,2,3); : : That would seem to obviate the need for brackets to define array : references. Is there any case where [1,2,3] would be needed instead of : (1,2,3)? Sure, in a list context. [1,2,3] is really short for scalar(1,2,3). I was just thinking that $((1,2,3)) is also the same as [1,2,3], and shorter than scalar(1,2,3). ~ John Williams
RE: Regex query
On Fri, 20 Sep 2002, David Whipp wrote: Larry wrote: : $shouldbe3 = (1,2,3) + 0; It's 3, though not for the reason a Perl 5 programmer would think. (In Perl 6 it's the length of the anonymous array, not the last value.) This kind of clever magic always makes me nervous: it introduces subtle bug potentials. (7,8,9) == 3 # true (7,8) == 2 # true (7) == 1 # false () == 0 # true? I believe the last two cases should be: (7,)== 1 (,) == 0 Because its the perl6 comma that creates the list, not the parenthesis. ~ John Williams
Re: Regex query
On Fri, 20 Sep 2002, Jonathan Scott Duff wrote: But I cannot tell whether (7) is list context or numeric context, Nope, you can't tell without the surrounding context: (7) + 0;# numeric $a = (7); # list (7) == 1; # boolean (same as (7).length == 1) No, that last one is clearly numeric context. == operates on numbers and returns boolean. I can't tell whether (7).length is asking for the length of 7 or the length of a list, but I would be badly surprised if (3+4).pow(2) returned 1 instead of 49. ~ John Williams
reduce via ^ again
Apologies for trying to resuscitate this old horse, but a new idea occurred to me. Back in October I suggested that $a ^+= b would act like reduce, but in discussion it was decided that it would act like length, by the interpretation: $a ^+= b $a = $a ^+ b $a = ($a, $a, $a, ...) ^+ b $a = ($a+$b[0], $a+$b[1], ...) $a = (a list in scalar context ) $a = length(b) I now pose the question: Is ^+= a hyper assignment operator or an assignment hyper operator? An assignment hyper operator would be interpreted as above, or with two arrays as: a ^+= b a = a ^+ b a = ($a[0] + $b[0], $a[1] + $b[1], ... ) A hyper assignment operator would be interpreted like this (doing the hyper part first): a ^+= b $a[0] += $b[0], $a[1] += $b[1], ... $a[0] = $a[0] + $b[0], $a[1] = $a[1] + $b[1], ... With two arrays the method is different, but the end result is the same. (One might be more efficient than the other, but I won't speculate on that here.) But with a scalar involved the method and the result is different. $a = length(b) is the assignment hyper operator interpretation. The hyper assignment operator interpretation looks like this: $a ^+= b ($a, $a, $a, ...) ^+= b $a += $b[0], $a += $b[1], $a += $b[2], ... which is DWIM: $a = reduce(b), assuming, of course that $a is initially zero. For a = $b, the end result also appears to be the same. assignment hyper operator a ^+= $b a = a ^+ $b a = a ^+ ($b, $b, $b, ...) a = ($a[0]+$b, $a[1]+$b, $a[2]+$b, ...) hyper assignment operator a ^+= $b a ^+= ($b, $b, $b, ...) $a[0] += $b, $a[1] += $b, $a[2] += $b, ... ~ John Williams
reduce via ^
I just read Apocalypse and Exegesis 3, and something stuck out at me because of its omission, namely using hyper operators for reduction. $a ^+= @list; # should sum the elements of @list Larry says @a ^+ 1 will replicate the scalar value for all a's, and Damian talks about doing summation with the reduce function without mentioning this compact syntax. So am I overlooking some obvious reason why this won't work? ~ John Williams
