Re: apo 2
> So bool would perhaps be a synthetic property that has opposite polarity > from bit? I can see that, sort of. It's something like electrons being > negative, thank you Mr. Franklin. s/bit/yes/ yes? And, despite perl5's use of no as the opposite of use, and given that there may be no use in perl6 (;>), and thus perhaps no no, (on and off?), then maybe no could be used as not yes? no?
Re: apo 2
> If you're trying to confuse me, I can assure you it's unnecessary. ;-) Hey, I try. --me (Under cover Ruby/Python agent and promotor of RFCs 380 thru 1,000,000)
Re: apo 2
> Well clearly "on" is the opposite of "no". Yes? maybe, as in: my cat maybe Dog; for some form of relaxed typing constraint.
:::: instead of qw// ?
My apologies if the following has already been suggested. I know Larry said the colon was his, but presumably he's not talking about the double colon, as currently used as a package name separator, right? What if: use Foo::Bar qw/ qux waldo /; can be written: use Foo::Bar :: qux waldo ::; Some disadvantages: o :: You can hardly see the double colons :: o Four shifted keystrokes. o There's ambiguity over what i:: means. Some plausible advantages: o The double colons echo the use of double colons as a separator in package (module) names, one of the most visible places that qw// gets used. o The four keystrokes are repeats. o The invisibility might sometimes be a good thing. In particular, I think the low noise works nicely on a 'use' (or 'mod' or whatever) line, which is in turn a good place (at the top of scripts) to reduce noise. It's plausible it might work nicely in at least some instances elsewhere in code. After all, one of the reasons to use qw// is to reduce noise that detracts from the words themselves. You will of course have qw// available if you need it. o Saves any other character(s) that might be used for replacing qw//.
Re: what I meant about hungarian notation
Larry: > Currently, @ and [] are a promise that you don't intend to use string > indexing on this variable. The optimizer can make good use of this > information. For non-tied arrays of compact intrinsic types, this > is going to be a major performance win in Perl 6. Assuming that optimization opportunities remained intact, do you think conflating @ and % would be a perl6 design win?
Re: what I meant about hungarian notation
> : Assuming that optimization opportunities remained intact, > > They won't, but go on. Because the syntax won't provide the compiler enough info? > : do you think conflating @ and % would be a perl6 design win? > > Nope, I still think most ordinary people want different > operators for strings than for numbers. Yes. But... I think it's rather more natural to view an array or hash element as a special form of function call than it is to view parens as operators. foo(1,2) is a function call with two numeric arguments. What syntax should one use to call a function with two string arguments? I am very happy that one does not have to use differing parens (and presumably commas) according to signature! The danger here is stretching analogies too far... > Dictionaries and calculators have very different > interfaces in the real world, and it's false economy > to overgeneralize. >From numbers versus strings as subscripts to this makes for an exquisitely ironic statement. I have lived in awe and admiration of Larry for years (and still do, I mean, A1/A2 are just incredible imo), but at last I know he's almost human!
Re: what I meant about hungarian notation
Larry: > : > Currently, @ and [] are a promise that you don't intend to use string > : > indexing on this variable. The optimizer can make good use of this > : > information. For non-tied arrays of compact intrinsic types, this > : > is going to be a major performance win in Perl 6. Clearly the promise can be broken, so there has to be a check somewhere along the line, right? If there is, and the check shows you don't have a (reasonable) integer, then perl can just switch to a hash lookup. I'd assume you are doing something vaguely similar to this any way, to do sparse arrays. If such a check is done, and the compiler code is written appropriately, there should be no reason why it incurs extra machine instructions in the event of there being an integer subscript.
Re: what I meant about hungarian notation
Larry,
No need to respond to individual points, because you
are so clearly wrong. ;> But I would appreciate an
overall response of something like either "this ain't
happening, so give up" or "it remains a possibility,
but I'm not yet remotely convinced". Thanks for your
continued forbearance.
> [mental model of ordered and unordered is important]
Yes. But I'm not sure that:
# ordered
@array = (1, 2, 3, 5, 8);
# unordered
%hash = (Fred => 22, Jane => 30);
is more or less typical than:
# unordered:
@array = ('England', 'France', 'Germany');
# ordered:
%hash = (Name => 'Ralph',
Street => '2512 Essex Place',
City => 'Nashville',
State => 'TN',
Zip => '37212',
Country => 'USA');
-
> [normal people want different operators for strings than for numbers]
I realize that perl is not a democracy (thankfully), but
it always helps to ask the people, as it were, so I've
created a survey about these issues, subtly slanted
in favor of voting for the status quo.
11 "normal people" (perl beginners) have responded
to this so far. 5 people say they prefer [] for both named
and numbered subscript parens, rather than [] for one
and {} for the other. 4 people prefer the status quo, and
these four hold this opinion much more strongly than
the ones voting for change. 2 don't care.
So, that doesn't help at all. ;>
You have noted the parallel between array/hash accessing
and function calls. The principle that people want this sort
of difference seems to suggest:
foo[1,2] # call function with numeric args
foo{'fred'} # call function with string args
which is just weird.
-
If you deprecated %foo{bar}, you would simplify a, er,
key aspect of perl and eventually free up % and {} for
other duties.
Re: what I meant about hungarian notation
> an ordered hash is common Arrays too. > not wise ... to alter features just for beginners. Agreed. > (PS 11 people isn't a statistic, its a night at the pub) Your round... The extra complexity of a separate hash syntax might be justified for other reasons, but not the ones given. No storm intended, but I think it is sometimes right to rebutt errors in current perceived wisdom. Especially if the error has a significant effect. This is one of those times.
Re: what I meant about hungarian notation
> Hm, OK. What does this access and using what method ?
>
> $foo = '1.2';
> @bar[$foo];
This is an argument against conflating @ and %.
It has nothing to do with using [] instead of {}.
(I accept that the @/% issue is problematic. Otoh,
I don't yet see @/% conflation as being obviously
a bad move in the way you and Larry seem to.)
> Having different brackets for accessing array or hash
> actually does help when reading code. Using the same
> is just adding unnecessary complexity
I can't tell if you mean this as a summary of your
earlier points, in which case please note response
above, or a separate point. If it is a separate point,
you don't say why, so, why?
Re: what I meant about hungarian notation
> > @bar[$foo]; # A
> > %bar{$foo}; # B
> > @bar{$foo}; # C
> > %bar[$foo]; # D
> >
> You forgot
>
> $bar[$foo]; # $bar is an array reference
> $bar{$foo}; # $bar is a hash reference
I can't argue with that.
My vote is now against conflating [] and {}.
---
Please bear with me just a (hoefully little) longer.
Ok, why not deprecate %foo and always use @
instead and have [] and {} represent two indexing
name spaces?
In perl 6 experiments, and perl 7, you'll have % to
play with.
Re: what I meant about hungarian notation
Graham Barr said: > I am not interested in continuing this in private. As you wish. > If you don't want your comments public then be quite. I thought it was best for the list if we had some private exchanges first to reduce noise. I'll try to remember that you don't like that approach. > survey ? I never saw any survey, It was an informal finger-in-the-wind thing I sent to a perl beginners list. Nothing special, just a quick survey. http://www.self-reference.com/cgi-bin/perl6plurals.pl > I certainly do not see that many people on the > list agreeing with you. And that means I should be quiet? I hope not.
Re: what I meant about hungarian notation
> As someone else pointed out (I forget who). But beginners are not > always the best people to ask. Beginner don't stay beginners for > long I think the quote was. And as I said before, I agree. I picked the beginners list as much because it was active as anything else. They are *somebody* after all, even if their preferences are not to be taken too seriously.
Re: what I meant about hungarian notation
> (i.e. ordered or "associative").
A (probably futile, but one has to try) plea for
people to use "numbered" rather than "ordered".
@foo = ['England', 'France', 'Germany'];# unordered
%foo = {First => Fred', Last => 'Bloggs']; # ordered
(I'd also suggest "named" instead of the scientific "associative".)
A summary: %, @, [], {}
I will read replies, and respond to off list emails,
but I will refrain from posting to the list on this topic
for at least one week.
If you have nothing new to add, then please don't post.
Suggestion: pseudohash.
%foo{Fred} = 'Bloggs';
$bar = %bar[1];# $bar is 'Bloggs'
Suggestion: deprecate %.
{} and [] act as named and numbered indices.
The benefit is saving % for alternative/future perl use.
One cost is the strangeness of @foo being, effectively,
two variables. I believe this is a strangeness that would
quickly dissipate, but that's just a guess.
Suggestion: deprecate {}.
The benefit is saving {} for alternative/future perl use,
and the fact that beginners prefer [] as the subscript
parens for both arrays and hashes by a more than 2
to 1 margin.
One cost is that:
$foo[$bar]
would be syntactically ambiguous. The compiler
would know enough to deal, but humans would not.
Suggestion: deprecate both % and {}.
Benefits are both of the above.
Costs are numerous and deep.
yastrl
Just a thought. No need for replies. Suggestion: rename local your. my is mine, nothing to do with anyone else's code. our is ours, used in my code and declared in a package known to my code. your is yours, the value used in code I call. Oh, and it's also ours.
Properties and stricture
Afaict, even with use strict at its most strict, perl 6 can't (in practice) complain, at compile time, if $foo.Foun refers to an undeclared Foun. Right? Should there be a strict mode that warns if a method name matches a built in property name?
$foo.Foun (was Re: Properties and stricture)
I apologize. I royally screwed up my original post. I had meant to ask two minor specific yes/no answer type questions about properties and stricture, that were mutually unrelated. Instead I asked one major open ended one. In the hope that I haven't completely blown any chance of getting answers to what I meant to ask, here's another shot: Question 1: Afaict, even with use strict at its most strict, perl 6 can't (in practice) complain, at compile time, if $foo.Foun refers to an undeclared Foun. Right? -- Question 2: Should there be a strict mode that warns if a method name matches a built in property name? -- Q1 followed from me thinking about my/our concepts as they might apply to properties. The more I thought about it, the more I gravitated toward the proposed system (lowercase for builtins, Mixedcase for user defined, only declare properties as part of my/our, etc), but I wanted to confirm that one ends up with this one unavoidable consequence -- that, ignoring unreasonable changes to perl, accidental $foo.Foun, even with strong stricture, will not be detectable. Q2 followed from me thinking about the way properties and object method names will share namespace. I wholeheartedly support the introduction of this sort of idiosyncratic, oddly, er, shaped, polymorphism. Larry's 'natural language' basis for perl is absolutely fundamental and brilliant, and I'm not questioning it whatsoever. But, within this framework, whatever stricture is reasonably available is nice, and I thought the specific mode I suggested made sense, assuming I understand the current proposal for properties.
Re: $foo.Foun (was Re: Properties and stricture)
>> Question 2:
>>
>> Afaict, even with use strict at its most strict, perl 6
>> can't (in practice) complain, at compile time, if
>>
>> $foo.Foun
>>
>> refers to an undeclared Foun.
>
> It could certainly warn you
Consider the code:
my $foo = 1 is Found;
&bar($foo);
sub bar { my $baz = shift; if ($baz.Found) { ...} }
Does the value of $baz have the Found property?
If so, does the compiler know that?
>> Question 2:
>>
>> Should there be a strict mode that warns if a
>> method name matches a built in property name?
>
> Possibly.
>
> Of course, the whole point of unifying the method and
> property access syntaxes was to allow exactly those
> kinds of shenanigans. But it might be a Good Thing
> if you had to explicitly turn off such a stricture to shenan
> that way:
>
> class FooClass;
> no strict 'properties';
>
> sub const (FooClass $self) {
> return $self{const} || $self.prop{const}
> }
Yes. That was pretty much exactly what I was thinking.
One of several benefits would be to help deal with the
introduction of new properties in later Perl versions.
When an older class was used with the newer Perl,
conflicting names would immediately break or warn,
which it seems to me would be a Good Thing.
Re: $foo.Foun (was Re: Properties and stricture)
> On Tue, Jun 05, 2001 at 04:38:24PM -0500, Me wrote: > > Question 1: > > > > Afaict, even with use strict at its most strict, perl 6 > > can't (in practice) complain, at compile time, if > > > > $foo.Foun > > > > refers to an undeclared Foun. > > > > Right? > > Can't you hear the low roar from the strong-typing argument coming > from the thread next door? Yes. Indeed the volume quite startled me... I.Found your notion of a "sealed off namespace" intriguing. I have no idea what it meant just yet; I'm going to go read and think about it now.
Re: $foo.Foun (was Re: Properties and stricture)
>> Consider the code:
>>
>> my $foo = 1 is Found;
>> &bar($foo);
>>
>> sub bar { my $baz = shift; if ($baz.Found) { ...} }
>>
>> Does the value of $baz have the Found property?
>
> Yes.
>
>> If so, does the compiler know that?
>
> No. Because it only has the property at run-time.
So, is it right to say that one can't use stricture to avoid
use of mistyped user defined value attached properties?
(Perhaps with the exception of references to a value
property in the same lexical scope as assignments of
that value?)
And, if this is so, then isn't it impossible to have useful
stricture about variable properties, because any given
reference to a property might be instead a value property
unknown to the compiler?
Re: $foo.Foun (was Re: Properties and stricture)
>> And, if this is so, then isn't it impossible to have useful >> stricture about variable properties, because any given >> reference to a property might be instead a value property >> unknown to the compiler? > > Yes. So: You can't have (variable or value) property stricture. Do these restrictions on property stricture have spill over effects on method name stricture? > Though static determinacy is obviously a desirable > thing... the dynamic power that Perl would have to > lose [to gain significantly more static determinacy] > would not compensate for the static benefits gained. Beautifully understated. :> > B&D languages What's B&D? > I very much doubt Perl is going to become > significantly more statically analyzable in general. Of course, static analysis doesn't have to only happen during a regular compilation pass. I can imagine the compiler architecture being such that it aids development of static analysis tools that take their time to do deep analysis which blurs the compile/runtime distinction as far as things like declaration stricture is concerned. But, where I had my doubts about stricture being an on topic perl6-language issue, I have none about static analysis support from the compiler. So, no more on that here from me... > Larry's MMV on that ;-) Man I really need to get up to speed with these acronyms. I know YMMV, is MMV a distant cousin perhaps?
Re: Properties and stricture
> [strict typing] > > Not a negative, but realize that many people find it > of less value than the annoyances it brings with it > (myself included) Michael, I don't know which is more impressive; the fact that use of a strictly typed language implies that a copy of you would land on the poor unsuspecting programmer's desk, or that you are self-deprecating enough to acknowledge that this would probably be an annoyance (at least in the first seconds or so prior to recognition of the rather cool magic involved). > > It could work in perl when perl is being used in an > > FP manner; that would indeed be very Perlish. > > Yes! That would be a magic trick I'd love to see. Indeed.
Re: $foo.Foun (was Re: Properties and stricture)
> > Afaict, even with use strict at its most strict, perl 6
> > can't (in practice) complain, at compile time, if
> >
> > $foo.Foun
> >
> > refers to an undeclared Foun.
>
> it is already detectable. from perldoc perlref:
Perhaps for perl 5, but, aiui, Damian confirmed
that my thinking about Perl 6 was correct.
> Although other discussion in the thread indicates that
> we may be confusing properties and member fields.
My concern was user defined variable and value properties.
(Though part of my reason for that concern was that whatever
limits on stricture might apply to any one member of the joint
property and method namespace might also have to apply
to the others.)
> as I understand it, .foo has been proposed to replace ->{foo} and
> we're talking about fields, not properties.
>
> Property access has got to be something else.
If that's so, I am totally confused.
Re: hash and array variables vs. references
> I have done a quick scan of the archives for a > discussion on this topic and didn't see it; if I > just missed it, I'd appreciate it if someone > could send me a link to the thread or > applicable RFC[s]. I suspect you didn't use the all search, right? Just in case: http://www.mail-archive.com/perl6-all%40perl.org/ Happy hunting (there's LOTS on your chosen topic). (I posted to the list in case anyone else reading it doesn't know about the all search.)
Multi-dimensional arrays and relational db data
(The intent is that) Perl 6 will be a better general purpose programming language for building application specific sub-languages. I'm interested in how far Perl 6 could go in providing support for a high-level expressive syntax sub-language for dealing with relational data. To the extent the general mechanisms will be in place in the core, there is no need to discuss it at this juncture; but then again, it's worth discussing to ensure that A) the general mechanisms will indeed be in place, and B) any syntaces chosen for core features won't jar with what makes sense for the relational data sub-language (at least not accidentally). For this post (and hopefully thread), I'm interested in focusing on the fact that a multi-dimensional array syntax, whatever it might end up being, is clearly going to be a direct analog of tables; that a multi-dimensional slice syntax could be seen as half way to virtual datasets drawn from multiple tables (eg a SQL select); that a discontiguous slice syntax gets the analogy even closer; that a missing piece, akin to SQL joins, could be darn useful outside of the usual database domain; that the issue that arrays have numeric indices means I'm really talking about multi-dimensional hashes, but then I don't see as sharp a divide between arrays and hashes as others may do, so I would expect whatever syntax is chosen for arrays is also usable for hashes; and finally that some of the issues that arise in considering multiple dimensional arrays are the same as those that arise in dealing with database data, for example sorting on multiple columns. I'm not going to post anything more concrete for this initial post. I thought others might want to pitch in first. If no one bites, I'll try to do a follow up in a few days with some more specific notes (unless someone bites so hard it's clear that I should just shut up).
Re: Multi-dimensional arrays and relational db data
> the end user is going to be able to > redefine the syntax anyway, Yes. But if the syntax for arrays and db data are to be simultaneously the same and as ideal as possible, then either the core array syntax needs to be relatively ideal for relational db data, or one needs to redefine the array syntax to match a created db syntax and thus have a version of perl that doesn't use the standard array syntax. While the latter is pretty cool, it's a whole lot less cool than the former (assuming that multi-dimensional arrays and relational db data are as close cousins as I think they may be).
Re: Multi-dimensional arrays and relational db data
> If array syntax really is a good analogy to database > access (it's not) Agreed. So long as you are talking about Perl 5's arrays. I disagree, if you are talking about 2 dimensional structures. If you don't think a two dimensional structure is a good basic fit with a lot of database access, what do you suggest IS a good fit? > array (or hash, you don't seem to care) Records have named fields so one dimension is like a hash. > Get started now - Perl 5's.. ...arrays are one dimensional. > tie and overload support should be more than sufficient. Aiui, overload won't get me past the one-dimensionality of Perl 5's arrays. Without a native 2d syntax, the win from tying isn't significant. > On the other hand, if Perl's array syntax isn't a good fit for > database access (bingo) then you propose we change > our array syntax to be a better fit. I don't think it's reasonable to say I propose you change something that hasn't yet been defined. Rather, it is precisely because you haven't yet defined the MD array syntax that I thought it worth at least considering how it parallels db data BEFORE you define it.
Re: Multi-dimensional arrays and relational db data
Sam, I don't think we're on the same wavelength. So a direct response seems pointless. Larry himself said: "while allowing multidimensional arrays to distinguish between [this and that] in a manner more conducive to database programming" Ok, I did s/numerical/database/, but what's a programming domain between friends?
Re: Multi-dimensional arrays and relational db data
> modeling of the whole database Doesn't seem like it's hard to do. With MD arrays, you are all but there anyway: Table: A 2d array. Whatever is introduced to more directly support handling MD arrays could very plausibly help in more directly supporting handling of single table data. This includes basic syntax, and standardized MD array sorting, filtering, and aggregating functions (which will all but inevitably emerge once standard direct support for MD arrays is in place). "Virtual dataset" from one table: A 2d 'slice' or rectangle. Both slices must support, er, discontiguousness. 'Horizontal' slice picks certain fields from the set available. I would expect it to be a small (or zero) hop, from whatever MD array syntax Perl 6 ends up with, to having a slice serve as a field selector. 'Vertical' slice picks certain records based on column data. This will be a bigger hop, involving some array filtering function, but it again seems inevitable that Perl 6's MD arrays will have this sort of filtering function/feature available. So, again, possibly zero extra work required. Dataset from multiple 'joined' tables (A pair of joined tables can be visualized as two spreadsheet like grids that intersect at right angles with the intersection point being the joined column. The vertical slice picks out rows where the joined column values from the two tables are the same.) Whatever is used to support vertical slicing based on col data should be extensible to do joining too. With the above, you have all the direct support I need to do all the non-transactional database crunching I have done with perl for the last several years. ALL of it. I'm pretty sure I'd be able to do grand sweeping db operations in one liners! > Didn't we have this discussion about six months ago??? I searched the perl6-all archives for any discussion of this sort of stuff when I first started to think about it. I used the string "SQL". I read all the posts (about 50-100 iirc). None went down this path.
Re: Multi-dimensional arrays and relational db data
> > [joining 2d arrays] > I can't envisage this... Perhaps you could reveal an example. Well, for a trivial example, here's two 2d arrays: foo, bar, baz, qux, quux, waldo and rab, foo, baz, xuuq, qux, zug Joining the first col of array 1 with the second col of array 2 would pick both rows from both arrays. Seems simple to me. Perhaps you meant the concrete method and/or syntax to achieve the join, or to reference the two arrays, or to reference the result table. But thinking of concrete details like that is way premature. For one thing, if Simon and Sam are anyone to go by, this thread has zero chance of getting over the basic "this is worth considering" consensus hurdle, so concrete details are pointless. > Particularly I can't envisage it for multicolumn Joining the first and last cols of array 1 with the second and last cols of array 2 would pick the first row from both arrays. Again, this seems simple to me. If you were considering my intersecting grids example, you need to view the multiple columns from each table as one column. > outer joins. Let's just consider a left outer join. That just means picking all rows from the first table referenced in what syntax is used (the left table) and either matching rows from the right table, or pretending there is a matching blank row from the right table. So, an outer left join between array 1 and 2 above, joined on the last col of array 1 and the last col of array 2 would pick both rows of array 1, and the first row of array 2, to go with the first row of array 1, and an unitialized row from array 2 to go with the second row of array 1. It's cumbersome describing this in english, but I would expect it to be really brain dead simple intuitive as a computer syntax and semantics.
Re: Multi-dimensional arrays and relational db data
OK. My last addition to this painful thread. > Your position depends on having a syntax so simple > that it is somehow worth implementing as a native > capability instead of the tied modules others have > pointed out. No it does not. I am not suggesting that a rdb modelling tied version of MD arrays would be in core. Of course it would not. I am suggesting that a rdb modelling tied version of MD arrays might be nice. And that for it to be its nicest: A) the general mechanisms that these tied arrays would need to work adequately will need to be in place in core; and B) the syntax and behaviors chosen for the core MD array features shouldn't jar with what makes sense for the db modelling tied version of MD arrays. I'll wrap with a final thought. I think there's scope for a simple generalized relational model (Nd arrays, joins between arrays, and Nd discontiguous slice subsets across joined arrays) to be a powerful yet simple general purpose algebra for creating normalized tabular datastructures. This has nothing to do with dbs, even less to do with SQL, and everything to do with general purpose programming expressiveness. OK. No more from me on this topic, at least not in the perl world.
Re: ~ for concat / negation (Re: The Perl 6 Emulator)
> > For what it's worth, I like it. > > So do I, actually... it's sort of growing on me. Me too. (I think it (~ for concat, ^ for negation) is just fine.) The "clash" with =~ is disappointing though. Now if Larry had the cahones to change the =~ operator... (I find the notion of a short infix word, like 'in', somewhat appealing. But I understand how easy it is to see this as more radical than is really called for.)
Generalizing value properties to become postits
Simplifying somewhat (ok, a heck of a lot), an rvalued:
$foo is bar
or
$foo : bar
is syntactic sugar for:
bar($foo)
with some extra magic for handling a properties hash
associated with $foo's value, in particular resetting the
hash when $foo's value changes.
Right?
Basically, perl will (do the equivalent of) define a sub bar
if it doesn't exist, then call bar, and bar can attach some
data to the value in $foo, or update some data attached
to the value in $foo, and will always return $foo.
Right?
If I got the above badly wrong, the rest of this post
probably won't make sense.
I also presume it would make sense to alias $_ to $foo
in (the method associated with) bar. (Is that intended?)
-
One could generalize so that bar can do as above, but
doesn't _have_ to do as above, ie it doesn't have to
attach data to $foo's value or update that data; it can
return a value other than $foo; and it can change the
value of $foo. Basically, an rvalued:
$foo : bar
becomes a syntactically and cognitively cheap way, and
a cognitively very different way, of calling bar on $foo, a
cheapness and difference that amplifies if one applies
several of these:
$foo : bar baz qux
instead of
qux(baz(bar($foo)))
I realize this isn't particularly appealing, but bare with me
a little longer.
So, in:
$foo : bar
bar in this context is not a property, but instead a more
general "post" or similar (alluding to the notion that it is
a bit like a postfix sub as well as (possibly) having the
sticky note aspect.)
So, to recap:
$foo : bar;
means bar is posted to $foo. $foo's value may change
or stay the same. The return value may be $foo's, either
before or after posting, or some other value. $foo's value
may now have an attached bar postit.
Presumably bar can be a block, method, or expression:
$foo : { code };
$foo : method;
More interestingly:
@foo : bar;
posts bar (expression, sub, block) to each element of
@foo. An alternate to 'for (@foo) bar' for single dim
arrays, and a syntactically cheap way to iterate over
entire multi-dim arrays (I'm assuming here that 'for'
won't, by default at least, iterate over all dimensions.)
@foo : bar;
@foo := bar;
@foo = @foo : bar;
are possibly just alternate ways of saying the same thing.
$foo := bar;
$foo = $foo : bar;
are also probably alternate ways of saying the same
thing, but are not necessarily the same as:
$foo : bar;
as the latter could return a value other than $foo.
Re: Generalizing value property setting to become postits
> Me:
[$foo is bar] can change the value of $foo.
> Damian:
Yes. For example:
my $foo is persistent;
Could you explain this further please?
> Me:
$foo : bar baz is roughly equivalent to baz(bar($foo))
> Damian:
Err. No. That would be:
bar(1); baz(1);
or possibly:
$_=\$foo; bar(1); baz(1);
.
.
There will, I hope, be a mechanism for pre- and postfixing
subroutines, but not properties I think.
I'm certainly not suggesting that : be _THE_ way to enable
postfixing of subs. (I would assume you need a character
pair to surround multiple args in the general case anyway,
quite apart from the fact that : doesn't immediately strike
me as a natural looking character for this sort of purpose.)
But the $foo : bar syntax IS (at the very least rather close to)
_A_ postfix sub syntax, whether or not this is currently viewed
as a desirable way to look at it.
> Damian:
You lost me here. Your ideas for properties are different
from mine
I didn't mean to suggest any changes whatsoever regarding
properties.
To the extent I understand them, I like them just the way you
have proposed. (Indeed, I thoroughly applaud your influence
on Perl 6. Personally I am rooting for one of my favortite bits
from clos, multimethods, which was covered by one of your
RFCs, but has not yet been raised on the list, though object
inheritance is all about method dispatch as well, so that has
made interesting reading.)
What I was suggesting was to consider broadening what the
$foo : bar style postfix sub syntax allows/assists bar to do,
so that bars can be used to set properties OR do other stuff.
If constraints of what bars can do are deemed appropriate to
ensure adequate performance for the property setting case,
which is after all, in the first place, the motivation for the syntax,
and in the second, the foreseeable primary use, well, so be it.
Otherwise, I see a possibly interesting twist in which bar can
do things beyond property setting, in particular, change $foo's
value.
Once one takes that step, : can become a generalized "apply
to value(s)" character, and the next natural step is:
@foo := bar;# iterate over @foo, applying bar to values.
One character, one concept ("apply to value(s)"), used for two
purposes that I think might not ever get in the way of each
other. (Though I'm not sure about that -- that's what this thread
was intended to help determine.)
Finally, and really a distinct point, I would like to see a distinct
term for value properties that doesn't use the word properties.
I liked the metaphor of post-it notes, and, if bars were to end
up being allowed to be an idiosyncratic but handy form of
postfix sub, then "postit" or similar would, imo, be a natural
name for value properties. Indeed, I think this may be true
even if bars remain constrained to setting postits, er, properties.
Re: Generalizing value property setting to become postits
> > What I was suggesting was to consider broadening what the > > $foo : bar style postfix sub syntax allows/assists bar to do, > > so that bars can be used to set properties OR do other stuff. > > > What's the practical utility of this? 1. Simplification for perl 6 implementation. I would expect it to be easier, when implementing the case of a user-defined property setting sub, to implement this as a straight reuse of existing perl functionality, namely use of plain old subs and $_ aliasing, than to invent some alternate mechanism purely because it is deemed evil to even have the option of changing the bar'd value. 2. Simplification for explanation. A value property setting sub is just a sub that happens to set a value property. Oh, and by the way, the most convenient and expressive notation for calling value property setting subs is the one we taught you for applying a sub to a value, namely one gets to: return $foo : bar; from @foo := bar;# already gonna have to be learnt for perl 6 3. Availability of another, brief, convenient and expressive way of calling subs with one argument on the left: OUTPUT : open ">foo"; OUTPUT : print "bar"; OUTPUT : close; I realize that a more general mechanism for postfix (or more accurately, infix) subs is hoped for, and, depending on how that looks, it might well make the above example pointless. Or, the more general mechanism for postfix/infix might subsume the above, so that property setting is just a way to use a sub with one of its args on its left, and that is just one of various postfix/infix options available. > > Once one takes that step, : can become a generalized "apply > > to value(s)" character, and the next natural step is: > > > > @foo := bar;# iterate over @foo, applying bar to values. > > > Actually, Larry has already indicated in an earlier message to > the list that ':' will work a lot like that! Yes, that was part of my reason for posting this. I thought it was interesting how the syntax fell in to place nicely for what Larry had already said he wanted, if ':' property setters are allowed to generalize to being subs (or blocks or -- I have more ideas on this, but they can wait or die with this thread) that can see and change the values from their left hand side. A key point here is that value properties apply to values, not variables, and element-wise operations also apply to values, not variables. Given that they share this applicability aspect, and (coincidentally?) shared ':' in proposed syntaces to date, I thought there might be value in looking at just how they might fit together.
Re: aliasing - was:[nice2haveit]
> Sounds like what we really want is a form of "for" which can iterate
> over a list of hashes or arrays:
>
> for my @a ( @foo, @bar ) { ...
>
> for my %h ( %foo, %bar ) { ...
Yes.
Isn't the underlying issue in the above how perl6 handles manipulation
and aliasing of multi-dimensional arrays into derived sub-structures?
In other words, isn't there a more general problem of how to provide
MD access and what to do with the currently one dimensional operations
like:
for (@foo) {
when @foo is multi-dimensional?
Jeremy Howard wrote RFCs that I think relate to this and pointed
me to J (APL cleaned up) as a powerful source of related ideas.
I think the specific issue above relates to a combination of
merge/unmerge and other proposed features.
pragma adverbs/attributes
> use strict 'recursive'; If this is not yet done and is deemed a good idea, I'd add that it seems to me to be equally applicable to perl 5. Further, considering the more general [pragma] 'recursive'; I can imagine pragma adverbs / attributes. I searched p5p and p6all for things like "pragma attributes" (and "recursive pragma") and didn't find anything relevant. It would seem natural (if not already going to be valid in p6) to allow something like: use foo :bar :quux; which clearly echoes: use foo qw( :bar :quux ); Perhaps pragma attributes could be used to make some common cases and highly visible uses of qw() rather prettier. Perhaps not. Regardless of the latter point, I could imagine: :recursive :excl :incl etc. I could further imagine a metapragma that makes these attributes available and used: use pragma 'adverbs'; Or maybe this functionality is added to: use attributes; I have no idea if any of this stuff would need to be in the perl compiler core. I can see a generic recursive pragma attribute being problematic if used anywhere but the file fed to perl, because then it becomes rather difficult to tell which pragma are in effect when looking at some source. (Otoh, for plain use strict, this seems pretty irrelevant.)
Re: Lexicals within statement conditionals
In a nutshell, you are viewing: foo if bar; as two statements rather than one, right? Personally, I think it's more natural to view the above as one statement, so any my anywhere in one element of it does not apply to other elements of it.
Re: CLOS multiple dispatch
> What is the need for CLOS? Are we trying to build a kitchen > sink here? To echo Michael, CLOS != multiple dispatch. > http://dev.perl.org/rfc/256.html "The usefulness of multiple dispatch depends on how intelligently the dispatcher decides which variant of a multimethod is "nearest" to a given set of arguments. That decision process is called I, and it is proposed that it be done (or I to be done, modulo optimization) like this:" I can imagine plausibly useful dispatch rulesets that do not involve comparing sums of inheritance distances. (Though this *is* all imagining as I haven't used multimethods/clos in about 10 years.) I would also imagine that others see that summing inheritance distances may not be the only intelligent way to pick among candidates when a perfect fit is not available. (By the way, the term variant is widely used to mean something utterly different in other common languages. And I never did find 'multimethods' appealing either.) Even if the dispatcher is the heart of multimethods, perhaps it would be nice if it were convenient to replace the dispatcher in whole or part. Kinda reminds me of the story of the old mop.
Re: CLOS multiple dispatch
> If the dispatcher is drop-in replacable, what does its > interface look like? I'm thinking this is either deep in mop territory, or a probably quite straightforward set of decisions about dispatch tables, depending on how you look at things. I found just one relevant occurence of 'mop' in perl6-all archives: http://www.mail-archive.com/perl6-all@perl.org/msg10432.html And not a single reply... I'd really like to see what Dan / lisp folks have to say about mops and perl6...
Re: Multiple-dispatch on functions
Dan, I don't immediately see how per object/class dispatch control helps to make multimethods pluggable. Perhaps a multimethod (a set of methods) is a class/object? Is there a general mop for dispatch? More generally: > Yes. Ordinary subroutine overloading (like that offered by C++) > certainly does fall out as a happy side-effect of multiple dispatch > in dynamic languages. > > For example, see: > > http://dev.perl.org/rfc/256.html#Handling_built_in_types How would you handle making (multimethod) dispatch pluggable when built in types are involved?
Re: What's up with %MY?
>> What about if the symbol doesn't exist in the caller's scope
>> and the caller is not in the process of being compiled? Can
>> the new symbol be ignored since there obviously isn't any
>> code in the caller's scope referring to a lexical with that
>> name?
>
> No. Because some other subroutine called from the caller's scope might
> also access caller().{MY}. In fact, you just invented a new pattern,
in
> which a set of subroutines called within a scope can communicate
invisibly
> but safely through that scope's lexical symbol table.
Foxy variables. Nice.
Re: NaN semantics
A quarter-baked idea: How about punting by using nan (all lowercase) as a boolean logic not-a-number, leaving NaN for someone to (later) create an IEEE style tristate not-a-number. Later: $foo == NaN; # NaN literal is not same as nan literal use NaN; NaN(expr);
Re: Apo4: PRE, POST
> [concerns over conflation of post-processing and post-assertions] Having read A4 thoroughly, twice, this was my only real concern (which contrasted with an overall sense of "wow, this is so cool"). --me
Re: [A-Z]+\s*\{
> On Saturday 19 January 2002 22:05, Brent Dax wrote: > > Is this list of special blocks complete and correct? > > > > BEGIN Executes at the beginning of compilation > > CHECK Executes at the end of compilation > > INIT Executes at the beginning of run > > END Executes at the end of run > > PRE Executes at beginning of block entry > > POST Executes at end of block entry > > NEXT Executes on call to next() within current block > > CATCH Executes on exception within current block > > KEEP Executes on normal exit of the current block > > UNDO Executes on "un-normal" exit of the current block - LAST (Per Damian's last (LAST/POST) post.) - FIRST? (Symmetry.) - ALWAYS? (Another plausible addition. Rounds out PRE and POST with invariant assertions that get checked twice, once at the time PRE does, once at the time POST does. Personally I'd leave this out until it became clear, well past p6.0, whether it was really worth it, but it seems worth mentioning.). --me
Apo4 misc (given nothing, ->, break, c::, keep/undo, hierarchy)
> "given nothing...":
>
> given () { ... }
do { ... }
seems simpler.
> Suppose you want to preserve $_ and alias
>
>given $value -> $g {
'->' seems more visually noisy than it need be in this case.
Perhaps:
given $value as $g { ... }
for @foo as $f { ... }
But, I can see how
> for 0 .. Inf; "a" .. "z" x 1000 -> $i; $a {
for 0 .. Inf; "a" .. "z" x 1000 as $i; $a {
would be seen as a counterexample by some.
> Similarly, if we make a word to mean to explicitly break
> out of a topicalizer, it should not be last. I'd suggest break!
> So it looks to me like we need a break.
I'm glad Larry didn't suggest 'done', because I really enjoyed Apo4.
I'll suggest it instead.
> I also happen to think that Exception is too long a name to
> prefix most common exceptions...
>c::NEXT
Based purely on visual impact, c:: seems best.
Perhaps 'when', or CATCH, could cause the parser to automatically
try an Error:: (or Exit:: or whatever) class prefix when it encounters a
classname.
> KEEP blocks would only be executed if the block succeeded.
> UNDO blocks would only be executed if the block failed.
What defines success? I sometimes raise exceptions to signal
that I'm done, with success, and it's time to wrap up and go back
to some calling code several levels up the stack. But I guess this
is an unusual case so not being able to use KEEP and UNDO
as intended is OK.
Or maybe each block has a Success class exception object
associated with it unless a different exception is raised, and
KEEP is called if the exception isa(Success). Then I can raise
a subclass of Success.
> However, X::Control exceptions (such as X::NEXT) are a
> subset of Exceptions
..
..
> Where exactly control exceptions fit in the class hierarchy is
> still open to debate
What about a change of perspective and terminology:
Exit (or Flow)
NEXT
Exception
ie exeptions are a subset of the ways to exit a block.
--me
Re: Some Apocalypse 4 exception handling questions.
> The problem I see with inheriting subblocks such as > FIRST/LAST/etc, is that they are tied in with the logic > ... of their enclosing block... Surely this is an argument *for* it being pretty odd *not* to inherit them. Let's say you add a LAST block to a method. In the LAST block you write clean up code that frees some resources. If you inherit from that method, and do not inherit the LAST block, then you've got a leak. This is obviously a mild example. --me
Re: Some Apocalypse 4 exception handling questions.
> I think our terminology is getting sloppy here. Ok, I (think I) understand. It's simple: If you declare a derived method, then preconditions and postconditions may or may not be inherited, and independently, the code may or may not be inherited. By default, the conditions are inherited and the code is not. One can optionally not inherit the conditions (at least preconditions, from another post I just read). And one can optionally inherit the code (by calling it). Right? Btw, are you going to have an equivalent of super? --me
Re: Some Apocalypse 4 exception handling questions.
> [final, private] I detest what these modifiers have done to me in the past. They seem very unperlish to me.
Re: Apocalypse 4 : The Strange Case of the STRANGE CASE
I would not be appalled if Perl 6 were to assume use
of caps for catcher block labels, but I would still like to
see Larry et al reconsider this design choice.
One suggestion is use of label syntax for catcher
blocks (suggests "come-from"). If catch and CATCH
were defined as synonyms, then one could type:
LAST: {
or
last: {
--me
"Non-yet-thrown exceptions must be a useful concept."
"Non-yet-thrown exceptions must be a useful concept." This is a bullet point from a list in Apo4 introducing coverage of exception handling. Was Larry talking about an exception object that hasn't yet been thrown? Did he refer to this issue again anywhere else in the Apo? --me
Re: Unary dot
> But suppose you want all .foo to refer to self and not
> to the current topic.
What about
given (self) { }
Also, what about
use invocant;
resulting in all method bodies in scope getting an implied
surrounding given (self) { }.
And what about 'me' or 'i' instead of 'self'?
And "use me;" instead of "use invocant;"?
--
me
PS. Please don't flame me, my assistant wrote this.
Re: Unary dot
> The following syntaxes have been seen: > > foo() > .foo() > ..foo() ## rejected because ".." is different binary op > class.foo() > FooClass.foo() > ::foo() > Package::foo() > $foo() > $_.foo() With a nod to Piers, and with apologes if this is silly in the context of Perl 6 syntax, what about: $.foo -- ralph
Re: Regex and Matched Delimiters
Let me see if I understand the final version of your (Mike's)
suggestions
and where it appears to be headed:
Backwards compatibility:
perl5 extended syntax still works in perl6 if one happens to use it.
Forward conversion:
Automatic conversion of relevant perl5 regex syntax to perl6 is simple.
New extension syntax:
1. Syntax is (ops data).
2. There are a bunch of built-in ops, but user can define new ones.
[2c. What about ( data) or (ops data) normally means non-capturing,
($2 data) captures into $2, ($foo data) captures into $foo?]
Rationalized ops syntax:
Ops string consists of arbitrarily ordered individual op characters.
(eg '<' signifies a look behind, '!<' signifies fail if look behind
match.)
Embedded code:
Code is inserted using {} with something other than digits in them.
(Other stuff, such as sexegers, ignored.)
--
ralph
Re: Please rename 'but' to 'has'.
I agree 'but' seems a tad odd, and I like the elegance of your suggestion at first sight. However... > First, but is just strange. I have a thing and I want to tell you it is > red, so I say 'but'. Huh? banana but red; "foo" but false; According to Larry, run time properties will most often be used to contradict a built-in or compile time property. If he is right about the dominant case being a contradiction, 'but' works better for me than anything else I can think of, including 'now' (explained below). - Even if usage to contradict a built-in or compile time property is not the most common form of usage, it is still arguably the case that if one keyword is to cover both cases (contradict or not), then having the keyword "warn" that contradiction may have occured is better than having the keyword indicate to a newbie that there is nothing to worry about, as would be the case with 'has'. Further, even if the "warn" notion is deemed unimportant, 'has' is still far from an ideal fit in many cases: banana has red; "foo" has false; Yet another issue is use of 'is' in a conditional: if ($foo is red) ... This would be nice, and would work nicely if one uses a different keyword for runtime properties, but works best if that other word is more consistent with the notion of 'is' than 'has' is. One plausible middle ground word off the top of my head that is odd in its own special way would be 'now': banana now red; "foo" now false; banana now foo; banana now tainted; I read 'now' as somewhat suggestive of changing something. -- ralph
Re: Regex and Matched Delimiters
> [2c. What about ( data) or (ops data) normally means non-capturing,
> ($2 data) captures into $2, ($foo data) captures into $foo?]
which is cool where being explicit simplifies things, but
ain't where implicit is simpler. So, maybe add an op ('$'?)
or switch that makes parens capturing by default, ie as
per perl5.
--
ralph
Re: Regex and Matched Delimiters
> Very nice (but, I assume you meant {$foo data})!
I didn't mean that (even if I should have).
Aiui, Mike's final suggestion was that parens end up
doing all the (ops data) tricks, and braces are used
purely to do code insertions. (I really liked that idea.)
So:
Perl 5Perl6
(data)( data)
(?opsdata)(ops data)
({}) {}
--
ralph
Re: Regex and Matched Delimiters
> /pat/i m:i/pat/ or // or even m ???
Why lose the modifier-following-final-delimiter
syntax? Is this to avoid a parsing issue, or
because it's linguistically odd to have a modifier
at the end?
> /^pat$/m /^^pat$$/
What's the mnemonic here? It feels the wrong
way round -- like a single ^ or $ should match
at newlines, double ^ or $ should only match
at start/end string.
Ah. The newline matches between the ^^ or $$.
That works.
Then there's the PID issue. Hmm. How to save $$
(it is nice for one liners)?
Sorry if this is a dumb suggestion, but could you have
just one assertion, say ^$, that alternates matching
just before and just after a newline?
> /./s // or /<.>/ ???
I'd expect . to match newlines by default. For a . that
didn't match newlines, I'd expect to need to use [^\n].
> space (or \h for "horizontal"?)
Can one quote a substring of a regex? In a later part you
say that \Q...\E is going away, so it seems not. It would be
nice to say something like:
/foo bar baz 'qux waldo' emerson/
and have the space between qux and waldo be literal.
Similar arguments apply more broadly so that one
could escape the usual meaning of metacharacters etc.
> \Lstring\E \L
> \Ustring\E \U
Maybe, if I wasn't too far off with the quote mark
suggestion above, then \L'string' would be more
natural.
> (?#...) {"..."} :-)
Will plain # comments work in p6 regexen?
> (?:...) <:...>
> (?=...)
> (?!...)
> (?<=...)
> (?
> (?>...)
Hmm. So <> are clustering just like ().
One difference is that () always capture whereas <>
only do so sometimes. Oh, and {} can too.
() are no longer used for clever stuff, <> are instead.
And {}.
Hmm. Time for bed.
--
ralph
Using closures for regex control
Larry said:
> I haven't decided yet whether matches embedded in
> [a regex embedded] closure should automatically pick
> up where the outer match is, or whether there should
> be some explicit match op to mean that, much like \G
> only better. I'm thinking when the current topic is a
> match state, we automatically continue where we left
> off, and require explicit =~ to start an unrelated match.
So, this might DWIM:
# match pat1 _ pat2 _ pat3 and capture pat2 match:
/ pat1
{ ($foo) = / pat2 / }
pat3 /
What is the meaning of a string returned by some code
inside a regex? Would this DWIM:
# match pat1 _ 'foo bar' _ pat2:
/ pat1 # white space is ignored
{ return 'foo bar' } # conserve whitespace
pat2 /
What if there were methods on the match state to
achieve regex extensions:
s/ { .<; /c/ } ei / ie /; # wierd look behind?
and so on:
/ pat1 { .>; /pat2/ } pat3 /
/ { .! and .<; /pat1/ } pat2 } /
--
ralph
Re: Regex and Matched Delimiters
> : I'd expect . to match newlines by default. For a . that > : didn't match newlines, I'd expect to need to use [^\n]. > > But . has never matched newlines by default, not even in grep. Perhaps. But: First, I would have thought you *can't* make . match newlines in grep, period. If so, then when perl is handling a multi-line string, it is handling a case grep never encounters. Second, I think the perl 5 default is the wrong one from the point of view of a typical newbie's guess. Third, I was thinking that having perl 6 regexen have /s on by default would be easy for perl 5 coders to understand; not too hard to get used to; and have no negative effects for existing coders beyond getting used to the change. -- ralph
Re: Regex and Matched Delimiters
> > : I'd expect . to match newlines by default. I forgot, fourth, this simplifies the rule for . -- it would become period matches any char, period. Fifth, it makes the writing of "match anything but newline" into an explicit [^\n], which I consider a good thing. Of course, all this is minor stuff. But I can't get my head around parse trees and grammars, so I'll continue to fiddle around spraying a bit of grafitti here and there on the bikeshed. -- ralph
Re: Regex and Matched Delimiters
> when matching against something like "foo\nwiffle\nbarfoo\n" >/(foo.*)$/ # matches the last line /(foo[^\n]*)$/ # assuming perl 6 meaning of $, end of string >/(foo.*)$/m # matches the first line /(foo[^\n]*)$$/ # assuming perl 6 meaning of $$, end of line or /(foo.*?)$$/ >/(foo.*)$/s # matches all three lines /(foo.*)$/ -- ralph
Using closures for regex control
[modified repost due to warnock's dilemma]
Would something like these DWIM?
# match pat1 _ pat2 and capture pat2 match:
/ pat1 { ($foo) = / pat2 / } /
# match pat1 _ 'foo bar':
/ pat1 { 'foo bar' } /
# match pat2 if not pat1
/ { ! /pat1/ } pat2 } /
# match pat2 if pat1 behind
/ { .lookbehind /pat1/ } pat2 } /
--
ralph
Re: Loop controls
I'm basically sold on Damian's conclusions. On the other
hand the 'otherwise' clause still feels to me like a CAPITALS
block.
So, as a tweak, I suggest:
while condition() {
...
}
NONE {
...
}
--
ralph
Re: Using closures for regex control
> : Would something like these DWIM?
> :
> : # match pat1 _ pat2 and capture pat2 match:
> : / pat1 { ($foo) = / pat2 / } /
>
> Yes
So a match in a closure starts where the outer match
was. Simple enough.
Will:
# match pat1 _ pat2 _ pat3 and capture pat2 match:
/ pat1 { ($foo) = / pat2 / } pat3 /
work?
> I don't think the return of the closure will be interpreted as
> [a string to be matched or a boolean success indicator or
> indeed anything, at least not something that the regex
> pays attention to]. Closures will be used for side effects,
> and I'd hate to see a lot of closures ending in a cryptic C<0;>.
Right.
Here's a thought, no need to respond just yet:
Perhaps the regex could look to see if the return
value has one of a set of properties. If it does not,
the regex ignores the return value. Otherwise it
uses the value in accord with the property:
# match pat1 _ 'foo bar':
/ pat1 { 'foo bar' is pat } /
Not exactly a compelling example, but the point is
this might be an appropriate way for closure return
values to participate in regex matching operation.
Aiui, one has regular perl code (not regex) read
access to what is *matched by* a parens, but not
write access to the *matching of* a parens.
So, one can do:
/ pat1 ( pat2 ) { $foo = $-1 } /
to read the value, but not
# made up, no thought applied, syntax
# match pat1 _ pat2 _ pat2
/ pat1 { .match 2 } ( pat2 ) /
where .match is followed by an expression that
applies some control to the next parens. I'm out
of my depth here, but can you see what I'm trying
to get to? To see how far one can have closures,
and hence regular perl syntax, take on regex
control duties.
--
ralph
Some regex syntax foibles
Current p6 rx syntax aiui regarding embedded code:
/
#1 do (may include an explicit fail):
{ code }
#2 do with implicit 'or fail'
<( code )>
#3 interp lit:
$( { code } )
#4 interp as rx:
<{ code }>
/
This feels cryptic. Do we need abbreviated syntax for
all these cases? If we do, is there a better syntax for
this stuff?
--
ralph
Re: atomicness and \n
> > $roundor7 = rx /<+[17]>/ > > That is: the union of the two character classes. > > Thank you; that wasn't in A5, E5 or S5. Will there be <-> as > well? >From A5: The outer <...> also naturally serves as a container for any extra syntax we decide to come up with for character set manipulation: <[_]++-> -- ralph
Re: Argument aliasing for subs
> Damian Conway wrote: > >>And is the is/but distinction still around? > > > >Oh, yes. > > Could someone please reference where this decision was > made. I do not find any information describing the distinction. The following May 2001 post was related. Poke around the thread it was in, especially posts by Larry or Damian: http:[EMAIL PROTECTED]/msg07604.html Btw, I've created a tiny url for using google groups to search for posts by Larry or Damian in perl 6 lists since early May 2002 (google doesn't have archives prior to then :<). http://tinyurl.com/1ce0 (Some posts similar to those shown will have been filtered out; you can fix that by going to the last page and clicking the 'repeat the search with the omitted results included' link). -- ralph
Re: @array = %hash
> [run time control of assignment behavior when array contains pairs]
How much have I misunderstood things from a mechanisms
available point of view (as against a practical / nice way to
do things) when I suggest something along the lines of:
my sub op:= (*@list : %adverbs) {
...
if %adverbs{keyed} = PAIR {
...
}
}
# create 2 element hash:
%hash = : { keyed=>PAIR } (1, 2, 3=>4, 5=6);
--
ralph
Re: Throwing lexicals
I may be missing your point, but based on my somewhat
fuzzy understanding:
> Oh. Duh. Why don't we have such a mechanism for matches?
>
> m/ my $date := /
>
> is ambiguous to the eyes. But I think it's necessary to have a
lexical
> scoping mechanism for matches
The above would at least have to be:
m/ { my $date := } /
(otherwise the 'my ' and ':=' would be matched literally.)
And you can of course do that.
But you won't be able to access $date outside the closure.
Hence the introduction of let:
m/ { let $date := } /
which makes (a symbol table like entry for) $date available
somewhere via the match object.
And has the additional effect that $date (I think the whole
variable/entry, but at the very least its value) disappears
if the match backtracks over the closure.
Right?
--
ralph
Re: Throwing lexicals
> I'm talking about just in the same namespace, how > do we keep rules from messing with file-scoped > (or any-scoped, for that matter) lexicals or globals. > How do we get rule- or closure-scoped lexicals > that are put into $0? How about something like the following rework of the capture/hypotheticals thing: You're allowed to declare variables beginning with a 0 inside rules, eg $0foo or @0bar. Rules by default capture to $0rulename. Variables that begin with a digit are rule variables, all rule variables are always hypothetical, no other variables are hypothetical. Drop the 'let' keyword. -- ralph
<( .... )> vs <{ .... }>
In several forms of courier, and some other text fonts
I view code in, I find it hard to visually distinguish the
pattern element:
<( ... )>
from:
<{ ... }>
What about replacing the former syntax with:
?
--
ralph
Backtracking syntax
Backtracking syntax includes:
:, ::, :::, ,
I like the way the ':' looks in patterns. But I noticed I have
several niggles about a number of other aspects of the
above syntax. All the niggles are minor, individually, but
they added up to enough that I thought I'd see what the
bikeshed might look like in another color.
First, the niggles:
1. It's nice how the ':', '::', and ':::' progression indicates
progressively wider scope. But I would be surprised if
newbies don't say to themselves, "now just how wide a
scope am I backtracking when there's three colons?".
2. Typo-trap: I can imagine it being fairly easy for some
people to miss, during debugging, both the visual and
behavioral distinction between '::' and ':::'.
3. It seemed odd how the and assertions
switch to the general <...> syntax. I felt like it would be better
if they avoided the general syntax, and preferably had some
family resemblance with the first three backtracking controls.
So, how about something like:
: # lock in current atom, ie as now
:] # lock in surrounding group, currently ::
:> # lock in surrounding rule, currently :::
:/ # lock in top level rule, currently
:// # cut
Thus, redoing a couple examples from synopsis 5:
m:w/ [ if :]
| for :]
| loop :] ?
]
rule subname {
([|_] \w*) :/ { fail if %reserved{$1} }
}
m:w/ sub ? /
--
ralph
Re: Backtracking syntax
> [EMAIL PROTECTED] (Me) writes: > > 1. It's nice how the ':', '::', and ':::' progression indicates > > progressively wider scope. But I would be surprised if > > newbies don't say to themselves, "now just how wide a > > scope am I backtracking when there's three colons?". > > Why would newbies be writing three-colon regexes? By "newbie" I meant it in a relative sense, ie. someone who is learning those particular features. The newbie could be an expert in Prolog and Perl 5. And I'm more concerned about when they are reading some existing patterns than when they are writing one. -- ralph
Re: <( .... )> vs <{ .... }>
> If you can't distinguish braces and parentheses (or quotes and
> backquotes in some other fonts), you are in deep trouble in many
> languages including perl5 BTW.
I've seldom found myself mistaking a brace for a paren
or a quote for a backquote when using Perl 5. So maybe
you are right.
But maybe not. Given that I have another definite concern,
mentioned below, I'll spray just a little bit more before I
pedal off.
I suspect the reason I didn't fall foul of '` and ({ ambiguity
in Perl 5 might be due to other cues being present.
If it looks like:
$stdout = '/bin/foo -abc def';
then those quotes are probably backquotes.
If I see
sub foo (
...
)
then I know those parens are probably braces.
But I'm not sure the cues will be so clear for the
pattern embedded code interpolation and assertion
cases.
And here's where I add my other small niggle: it's not
clear to me /mnemonically/ which is which. Even if
you can tell which is a brace and which a paren, you
are still left wondering what each does when you're
learning this new stuff. I mean, which one of these is
executing some code to return a boolean assertion,
and which one a string value to be interpolated?
$rx1 = rx / foo <( bar )> qux /;
$rx2 = rx / foo <{ baz }> qux /;
But then again, the above is obviously contrived.
I've got my clips on; I'm outta here.
--
ralph
Delegation syntax
Problem:
You want to use delegation (rather than inheritance)
to add some capabilities of one class or object to
another class or object.
Solution:
Use a PROXY block:
class MyClass {
PROXY {
attr $left_front_wheel is Wheel;
attr $right_front_wheel is Wheel;
when 'steer' { $left_front_wheel, $right_front_wheel }
}
...
}
Discussion:
The PROXY block behaves as if the following were
true. The block has a topic. The topic is an object
that represents a method call. This object stringifies
to the name of the method called. The block is called
each time a method call is invoked on the enclosing
class, or an instance of the class. The whens' blocks
are a list of things that are proxies for (ie delegatees
of) the matched call.
Roughly speaking, my idea is to do Damian's Delegation
class dressed using new clothes that look like ones from
the Apos that have come out since he wrote the module
at http://tinyurl.com/1qsk. A longer example follows.
class MyClass {
PROXY {
attr $left_front_wheel is Wheel;
attr $right_front_wheel is Wheel;
attr $left_rear_wheel is Wheel;
attr $right_rear_wheel is Wheel;
attr FlyWheel $flywheel .= new;
attr MP3::Player $mp3 .= new;
when 'steer'{ $left_front_wheel, $right_front_wheel }
when 'drive'{ 'rotate_clockwise' => $left_rear_wheel,
'rotate_anticlockwise' => $right_rear_wheel }
when 'power'{ 'brake' => $flywheel }
when 'brake'{ / .*_wheel / }
when 'halt' { 'brake' => SELF }
when /^MP_(.+)/ { sub { $1 } => $mp3 }
when 'debug'{ 'dump' => ATTRS }
}
...
}
or something like this.
--
ralph
Re: Draft Proposal: Declaring Classwide Attributes
I've looked before for discussion of the rationale behind
introducing attr/has and failed to find it. I noticed you
mention Zurich, so perhaps this decision followed from
discussion in living color (as against b+w).
Anyhow, what was deemed wrong with using my/our?
And...
> class Zap {
> my %.zap_cache; # a private classwide attribute
> our $.zap_count = 0; # a public classwide attribute
>
> has $.foo;
> has $.bar;
> }
>
> It may be that $.zap_count is public not so much because of the class
definition
> where it would default to private, but because $.zap_count's real
global name is
> $Zap::.zap_count. To get a public accessor method you might still
need to declare
> it public. And you could get a public accessor method to the "my"
variable as well
> the same way.
So:
class Zap {
my %zap_cache; # var, lexical
my %.zap_cache;# class attr, lexical
my %.zap_cache is public; # class attr, lexical/public
our $zap_count = 0;# var, lexical/global
our $.zap_count = 0; # class attr, lexical/global
our $.zap_count = 0 is public; # class attr, lexical/public/global
has $.foo; # instance attr, lexical
has $.bar is public; # instance attr, lexical/public
}
Yes?
What about something like:
my $.foo; # private instance attr
our $.foo; # public instance attr
my $foo;# as p5
our $foo;# as p5
MY $.foo; # private class attr
OUR $.foo; # public class attr
MY $foo;# invalid?
OUR $foo;# invalid?
method bar; # public instance method
my method bar; # private instance method
our method bar; # public instance method
MY method bar; # private classmethod
OUR method bar; # public classmethod
--
ralph
Re: Draft Proposal: Declaring Classwide Attributes
> Nothing the matter with "our" for class attributes since they're
> already stored in the package if we follow Perl 5's lead. But using
> "my" for instance attributes is problematic if we allow a class to
> be reopened:
>
> class Blurfl {
> my $.foo;
> }
> ...
> class Blurfl is continued {
> print $.foo;
> }
>
> This violates the Perl 6 rule that "my" is always limited to a block.
> That's why we came up with "attr", which has since mutated to "has".
[snip]
> It's my gut feeling that class variables are already pretty close to
> "our" variables, so we only need a new word for instance variables,
> which have a very different scope from any variables in Perl 5.
Ok.
We also need a signifier for class methods (assuming
a distinction is made).
Perhaps one could use an initial cap to indicate a class
attribute/method:
class foo {
my $bar;# my is not used for attributes
our $baz;# neither is our
has qux; # instance attribute
has Waldo; # class attribute
method qwe; # instance method
method Rty; # class method
}
or similar.
--
ralph
Re: perl6 operator precedence table
> Somebody fairly recently recommended some decent fixed-width typefaces. > I think it may have been MJD, but I can't find the reference right now > (could be at work). Michael Schwern recently suggested "Monaco, Neep or, if you can find them, Mishawaka or ProFont". I investigated and found this link to be useful: http://www.tobias-jung.de/seekingprofont/ -- ralph
Re: labeled if blocks
> And that's also why we need a different way of returning from the
> innermost block (or any labelled block). "last" almost works, except
> it's specific to loops, at least in Perl 5 semantics. I keep thinking
> of "ret" as a little "return", but that's mostly a placeholder in
> my mind. I've got a lot of those...
A unary <-, as in
if $foo -> {
<- $bar
}
?
--
ralph
Re: [RFC] Perl6 Operator List, Take 5
> : > I wonder if we can possibly get the Rubyesque leaving out of
> : > endpoints by saying something like 1..!10.
> :
> : Similarly: 1 >..< 10 == 2..9
> There's also an issue of what (1..10) - 1 would or should
> mean, if anything. Does it mean (1..9)? Does 1 + (1..10)
> mean (2..10)?
>
> And what would ('a' .. 'z') - 1 mean?
1..10-1 # 1..9
1+1..--10# 2..9
'a'..'z'-- # a - y
?
--
ralph
PS. [op] is such a sweet improvement. the [op=] vs [op]=
trick that then became possible, the move of ^ back to its
previous meaning, is nice icing.
Re: [RFC] Perl6 HyperOperator List
> So despite the beauty of > > @a [+] @b > > I think it cannot survive in its current form. It overloads square > brackets too heavily. What about using colon thus: @a [:+] @b or other character after the opening bracket, so long as that character is not valid as the initial character of a prefix op or term. There's also: @a []+ @b -- ralph
Re: Vectorizing operators for Hashes
> hash ^[op] hash > ... > array ^[op] scalar ie, generally: term ^[op] term > what to do if @a, @b in @a ^[op] @b have different length > what to do if %a, %b in %a ^[op] %b have not the same set of keys > what to do in %a ^[op] @a > > [what to do] resolved by hash property : I'd expect adverbs rather than adjectives for these sorts of issues, ie ':' modifiers of vectorization rather than use of variable/value properties. > @a ???[op] @b = [ array of @a[x] op @a[y] for all pairs x,y ] > > this path have no end, but where to stop ?? b4p6>J! ;> (http://jsoftware.com/) Seriously, I also think it's worth seeing where this goes. As noted above, I'd expect use of adverbs to allow modification of hyperactivity: %a ^[op] %b : union Of course, this suffers the obtw problem. An alternative might be: %a ^:union[op] %b I can definitely see scope for wanting separate adverbs to influence how vectorization works on the lhs and rhs. Perhaps %a :foo[op]:bar %b where I'm assuming :[op] instead of ^[op] as the base syntax for vectorization. -- ralph
Re: Vectorizing operators for Hashes
> > %a ^:union[op] %b > > > > %a :foo[op]:bar %b > > I think that any operators over 10 characters should > be banished, and replaced with functions. I'd agree with that. In fact probably anything over 4, and even 4 is seriously pushing it. I'll clarify that I am talking here about using adverbs. >From A3 (about the colon): Hence, this operator modifies a preceding operator adverbially. ... It can be used to supply a ``step'' to a range operator, for instance. I would expect the length of these adverbs to fall in a range somewhat the same as properties. So a word like 'union' is reasonable, and even 'intersection' too. Ignoring hyperoperators, one might use an adverb thus: $a / $b : dbz_Inf to have a divide by zero be treated as Infinity. I can see scope for a bunch of adverbs that control how a particular hyperoperation works. Thus, perhaps: @a ^[/] @b : short to stop iteration when the shortest of two arrays is used up. But this assumes that the adverb applies to the ^[] hyperop, not the / op. Perhaps this is resolved thus: @a ^[/ : dbz_Inf] @b : short But I also suspect it would be good to be able to associate distinct adverbs with the lhs and rhs of a binary operation. So I thought perhaps one could go down the path of @a ^ :step(2) [/ : dbz_Inf] :step(3) @b : short Hmm. Perhaps hyperop adverbs are preceded with a ^ and one gets instead: @a ^[/] @b : dbz_Inf, ^short, ^step(2,3) -- ralph
Re: Vectorizing operators for Hashes
> > union: > > intersection : > > How would this work for hashes with differing properties? > > %a ^is strict_keys; > %b ^is no_strict_keys; > > What would happen? That's one reason why I suggested control of this sort of thing should be a property of the operation, not of the operands. -- ralph
Re: Vectorizing operators for Hashes
> On Thu, 31 Oct 2002, Me wrote:
> : That's one reason why I suggested control of this sort
> : of thing should be a property of the operation, not of
> : the operands.
>
> I think that by and large, the operator knows whether it wants to
> do union or intersection. When you're doing +, it's obviously
> union that you want, with undef defaulting to 0. And // would
> want intersection.
Ok. So I accidentally got something right! ;> ("control of this sort of
thing should be a property of the operation, not of the operands.")
There are clearly some operations where adverbs make sense.
Presumably one of the classes of op for which adverbs might
make sense is hyperop.
Assuming so, did my suggestion of ^adverb make sense to you
as a way to distinguish op and hyperop adverbs?
--
ralph
Re: Vectorizing operators for Hashes
> temp sub infix:^[] is force_hash_to_intersect ; Right. A property used as you suggest is effectively an adverb applied at op definition rather than use. > maybe somebody will wont ( 1,2 ) ^[op] ( 1, 2, 3 ) to return array of > length 3 ; Right. It's quite plausible that one would want to be able to control this at op use, rather than definition. -- ralph
Re: Perl6 Operator (REMAINING ISSUES)
> > 1) Need a definite syntax for hypers > > ^[op] and <> > > have been most seriously proposed -- something that keeps a > > bracketed syntax, but solves ambiguity issues. > > hm. What was wrong with just '^' again? Right. I didn't have a problem with ^ in the first place. But... A ^ prefix visually interferes a lot more with the op being hypered. I didn't understand that until I first saw use of square brackets (interestingly, use of angle brackets didn't grab my attention, though that may have been due to other factors). Personally, I liked the use of single backtick someone suggested. I suspect that this is because it seemed to be just as good as square brackets at getting out of the way visually (vastly better than ^); was enough to catch my attention to suggest something special was going on; was just one, unshifted, character (or two, if used for a `op`= variant); and seemed to be the least disruptive (it left ^ for other duties and just meant one needed to eliminate `` for a syscall; hmm, maybe that's not acceptable...) -- ralph
Re: Perl6 Operator (REMAINING ISSUES)
> > A ^ prefix visually interferes a lot more > > I know it clutters up things a bit, that's my very argument; that > ^[ ] clutters up things even *more*. especially, with use of arrays: > > @array[1,2,3] ^[+=] @array[4,5,6]; > > bleah. > > @array[1,2,3] ^+= @array[4,5,6]; > > Not much of a improvement, but its palpable. Maybe. I slightly prefer the first line right now. But it's close, and I think I've gotten too used to both notations to know what I'd think if I saw one or other for the first time, and I don't know what I'd think after a month of use of one or other. As I said, it's close. This will defintely be my last email on the topic... There's a couple other reasons to go for ^[op]. One is that [] is more obviously indicative to a newbie that there is some array aspect to how the op applies than ^ (or backtick) would be. Another is that bracketing works better to indicate the difference between the two ...= variants that might be useful: @a ^[+=] @b @a ^[+]= @b # vectorize the +, not the = @a ^+= @b @a ^+^= @b # vectorize the +, not the = ?!? > '^' is being used as a sigil for an operator, and that all > you need is one keystroke in order to use it. On my keyboard it's two (shift and the 6 key). > Oh by the way. IMO 'vector' operators should be the > proper term. Oops. Yes. -- ralph
Unifying invocant and topic naming syntax
I read Allison's topicalization piece:
http://www.perl.com/pub/a/2002/10/30/topic.html
I started with a simple thought:
is given($foo)
seems to jar with
given $foo { ... }
One pulls in the topic from outside and
calls it $foo, the other does the reverse --
it pulls in $foo from the outside and makes
it the topic.
On its own this was no big deal, but it got
me thinking.
The key thing I realized was that (naming)
the invocant of a method involves something
very like (naming) the topic of a method,
and ultimately a sub and other constructs.
Thus it seems that whatever syntax you pick
for the former is likely to work well for
the latter.
Afaik, the syntax for invocant naming is:
method f ($self : $a, $b) { ... }
But whatever it is, I think one can build
on it for topic transfer / naming too in a
wide range of contexts.
With apologies for talking about Larry's
colon, something that really does sound
like it is taboo for good reason, I'll
assume the above invocant naming syntax
for the rest of this email.
So, perhaps:
sub f ($a, $b) is given($c) { ... }
sub f ($a, $b) is given($c is topic) { ... }
sub f ($a, $b) is given($_) { ... }
could be something like:
sub f ($c : $a is topic, $b) { ... }
sub f ($c : $a, $b) { ... }
sub f ($_ : $a, $b) { ... }
where the first arg to be mentioned is the
topic unless otherwise specified.
(The first line of the alternates is not
semantically the same as the line it is a
suggested replacement for, in that the
current scheme would not set the topic --
its value would be the value of $_ in
the lexical block surrounding the sub
definition. It's not obvious to me why
the current scheme has it that way and
what would best be done about it in the
new scheme I suggest, so I'll just move on.)
Anyhow, the above is my suggestion for an
alternate to 'is given' in a sub definition.
The obvious (to me) thing to do for methods
is to have /two/ colon separated prefixes of
the arg list. So one ends up with either one,
two, or three sections of the arg list:
# $_ is invocant:
method f ($a, $b) { ... }
# $_ and $self are both invocant:
method f ($self : $a, $b) { ... }
# $_/$self are invocant, $c caller's topic
method f ($self : $c : $a, $b) { ... }
One could have incantations such as:
method f ($self : $c : $a is topic, $b) { ... }
method f ($self : $c is topic : $a, $b) { ... }
method f ($self : $_ : $a, $b) { ... }
which all clobber the invocant being 'it',
but if that's what a method author wants,
then so be it.
One question is what happens if one writes:
method f (: $c : $a, $b) { ... }
Is the invocant the topic, or $c, ie what
does a missing invocant field signify?
Jumping to a different topic for one moment,
I think it would be nice to provide some
punctuation instead of (or as an alternate
to) a property for setting 'is topic'. Maybe:
method f ($self : $c : $a*, $b) { ... }
or maybe something like:
method f ($self : $c : $aT, $b) { ... }
(Unicode TM for Topic Marker? Apologies if I
screwed up and the TM character comes through
as something else.)
Anyhow, a further plausible tweak that builds
on the above colon stuff is that one could
plausibly do:
sub f ($bar : $a, $b) {
...
}
and then call f() like so:
f (20 : 30, 40)
as a shortcut for setting $_ before calling f(),
ie to set $_ in the body of f to 20, $a to 30.
Unfortunately that conflicts with use of colon
as an operator adverb. Conclusion: if y'all
end up using a different syntax for specifying
the variable name of the invocant for a method,
and go with the extension I suggested earlier
for replacing 'is given', then maybe the above
can still work, and maybe it would be a good
idea to allow it.
And if you do, I can see a further trick being:
given $foo {
# $_ = $foo here, hiding outer topic
}
given $c : $foo {
# $_ = $foo here, hiding outer topic
# $c = outer $_
}
And likewise for other topicalizers.
--
ralph
Re: UTF-8 and Unicode FAQ, demos
> After all, there's gotta be some advantage to > being the Fearless Leader... > > Larry Thousands will cry for the blood of the Perl 6 design team. As Leader, you can draw their ire. Because you are Fearless, you won't mind... -- ralph
Re: UTF-8 and Unicode FAQ, demos
> people on the list who can't be bothered to read > the documentation for their own keyboard IO system. Most of this discussion seems to focus on keyboarding. But that's of little consequence. This will always be spotted before it does much harm and will affect just one person and their software at a time. Errors in encoding during transmission is a whole lot more problematic. This will almost always be spotted after the fact, and may affect many people at a time and require fixes to multiple systems not controlled by the sender or receiver. -- ralph
Re: Unifying invocant and topic naming syntax
> > (naming) the invocant of a method involves
> > something very like (naming) the topic
>
> Generally, there's no conceptual link...
other than
> The similarity is that both are implicit
> parameters
which was my point.
Almost the entirety of what I see as relevant
in the context of deciding syntax for naming
the invocant is that it's an especially
important implicit argument to methods that
may also be the topic.
Almost the exact same thing is true of the
"topic", with the exception being that it
applies to subs as well as methods.
It's clear you could have come up with
something like one of these:
method f ($a, $b) is invoked_by($self)
method f ($a, $b) is invoked_by($self is topic)
method f ($a, $b) is invoked_by($_)
but you didn't. Any idea why not?
> There are times when it's useful to access
> the caller's topic without setting the current
> topic and times when it's useful to just set
> the current topic.
> ...
> When you have a system with two independent
> but interacting features, it's far more
> efficient to define two independent flags
> than to define 4 flags
Of course. The general scheme I suggested
doesn't impinge on this one way or the other.
But the specifics I suggested made a different
choice for the default situation.
As you said of the current scheme:
The following example will either print
nothing, or else print a stray $_ that is
in lexical scope wherever the sub is defined.
sub eddy ($space, $time) {
print;
}
In the scheme I suggest the first arg is the
topic by default (just as is the case for the
other topicalizers such as pointy sub, for,
etc in the current scheme). I think this
choice makes sense, but then, as I implied,
maybe I'm missing something.
> > method f ($self : $c : $a*, $b) { ... }
(where * is short for 'is topic'.)
> Is this really common enough to merit a single
> punctuation character?
If I didn't think so I wouldn't have suggested
the shortcut. ;>
> > Anyhow, a further plausible tweak that builds
> > on the above colon stuff is that one could
> > plausibly do:
>
> So, in this system, the colon is used for both
> explicit parameters and implicit parameters.
> ...
> I'd prefer more consistency.
If by "system" you mean the scheme I suggested
prior to this "plausible tweak", then no. The
colon would only be used in this way if one
introduced the tweak. Rejecting this tweak has
no impact on the value of the general scheme
I suggested.
The colon in my scheme (not the tweak) can
optionally be used to be explicit in sub
*defs* about otherwise implict args. The
tweak I am suggesting is that one could,
optionally, use the exact same syntax to
be explicit in sub *calls* about otherwise
implicit args. I think this has a clean
consistency.
> > given $c : $foo {
> > # $c = outer $_
> > }
>
> It would be much more transparent to simply
> name the outer topic.
How is this so different to
method f ($c : $foo) {
# $c = invocant
}
?
>
> Allison
--
ralph
Re: Unifying invocant and topic naming syntax
> relatively few subroutines need access
> to the upscope topic.
Well, this is a central issue. What are
the real percentages going to be here?
Just how often will one type the likes
of
-> is given($foo is topic) { ... }
rather than
-> $foo: { ... }
?
My imagination suggests to me that in a
typical short perl 6 script, between 20%
and 50% of all sub defs would use the
upscope topic... ;>
Seriously, the functions chapter of Camel
III contains 202 functions; 36 of these
use the upscope topic.
So that gives an idea of what to expect --
although there is likely to be /more/ use
of tricks like this that support brevity
when advanced coders specifically wish to
write brief scripts.
Unless of course the very syntax that
creates /call/ brevity is itself so
verbose that it neutralizes some of its
utility in such cases, something that
would be rather ironic, don't you think?
> Moreover, because ['is given'] compromises
> the lexical scoping of the upscope topic,
> it ought to be marked very clearly
Yes.
> [keywords are clearer than punctuation for
> marking something]
I think that's overly general.
In something that is as likely to be naturally
keyword dense as a sub or method definition, I
imagined the situation would be near reverse,
i.e. well chosen punctuation would often be a
better pick than YAK for marking something.
(Maybe colon isn't it, but I didn't pick that.)
Of course, in code written to be brief, sub
defs would tend to be less keyword, but then
again, in code written to be brief, brevity
would again suggest punctuation.
So perhaps punctuation wins in both cases;
in large projects sub defs will be keyword
dense and punctuation would better highlight
"it" and in small scripts, punctuation in
sub defs would be desirable for brevity.
--
ralph
Re: Unifying invocant and topic naming syntax
> > My imagination suggests to me that in a
> > typical short perl 6 script
>
> That's some imagination you've got there! ;-)
:>
> My estimate (based on the -- not inconsiderable --
> code base of my own modules) is closer to 5%.
Your estimate of what others will do when
knocking out 10 line scripts in a hurry,
or what's in your current p5 modules?
> But that's beside the point. The two factors
> that nix this idea IMHO are that:
>
> * Putting a non-parameter in the parameter list
>is Just Plain Wrong
Right. I've always thought that too.
> * Using a single character to denote the use of
>an upscope topic is insufficiently
>obvious (regardless of which character
>is used for the purpose)
Right again. And again, I've always thought
that too.
As I said in my original email on this topic:
Afaik, the syntax for invocant naming is:
method f ($self : $a, $b) { ... }
But whatever it is, I think one can build
on it for topic transfer / naming too in a
wide range of contexts.
I didn't like the invocant syntax but didn't
want to tackle the problems with it that you
so rightly list above. My point was always
just that what's good for one very common
implicit arg (invocant) seems to me likely
to be good for what could so easily become
the other-not-quite-so-but-still-somewhat
common implicit arg (it).
But I'll assume the horse is dead, and move
on to the horses sibling, which hopefully
might live on:
Can currying include the given topic? Can
I do something like:
$foo = &bar.assuming( _ => 0)
or whatever the latest syntax is?
And what about a topic placeholder:
{ print $^_ }
such that $^_ is effectively converted to
an 'is given($^_)'.
?
--
ralph
Re: Unifying invocant and topic naming syntax
> Can currying include the given topic? Can
> I do something like:
>
> $foo = &bar.assuming( _ => 0)
>
> or whatever the latest syntax is?
Oops. More clearly:
sub bar is given($foo) {
...
}
$foo = &bar.assuming( foo => 0 )
--
ralph
Re: list comprehensions
> Will there be some shorter-hand way to say these? > [list comprehensions] (bb clarified that this is about hash slicing.) >From A2: RFC 201: Hash Slicing ...Concise list comprehensions will require some other syntax within the subscript... And There are many ways we could reintroduce a slicing syntax ... but we'll defer the decision on that till Apocalypse 9 -- ralph
Re: on Topic
In the hope this saves Allison time, and/or
clarifies things for me, I'll attempt some
answers.
> In your article at perl.com you describes
> various ways and situations when perl
> creates a topic and this is described as
> perl making the following binding on my behalf:
>
> $_ := $some_var ; *1*
Well, $_ might not be bound to a named variable
but instead be just set to a value, or it might
be bound to an array cell or some other unnamed
container.
> is *1* _all_ that topic is about ?
Sorta. To quote an excellent summary:
"Topic is $_".
> my $x,$z;
> given $x->$y {
> $_ := $z ;
> when 2 { ... } #checks against $z ???
> }
Yes.
> methods topicalize their invocant. Is $self
> aliased to $_ inside the method in this ex. ?
>
> method sub_ether ($self: $message) {
> .transmit( .encode($message) );
> }
Yes.
> will it be an error to write
> method sub_ether ($self: $message, $x is topic) {...}
No.
> what happens if I write
> method sub_ether ($self: $message) {
> $_ := $message ;
> }
> or
>
> method sub_ether ($self: $message) {
> $_ = $message ;
> }
Both Ok. $_ is "it" and has the value $message;
in the former case $_ and $message are bound.
> is $_ always lexical variable.
Yes.
> Or I can have $MyPackage::_ ?
You can copy or alias any value.
> * can I alias $something to $_ ?
> $something := $_
Sure. Because...
> (it seems that I can , because $_ is just
> another variable )
> $b := $a ;
> $c := $b ;
>
> ( now changing value of one variable will
> change other two ??? )
Yes.
> or e.g.
>
> $a = 1 ;
> $Z = 10 ;
>
> $b := $a ;
> $c := $b ;
>
> print $c # prints 1
> $a := $Z ;
> print $c # prints 10
> $a = 5;
> print $Z # prints 5
Yes.
> also
>
> @a := ( $a, $b)
Er, I don't think (it makes sense that) you
can bind to a literal.
> $b := $c
> @a[1] = 10 ;
> print $c # prints 10
Lost you there, even ignoring the literal issue.
--
ralph
Re: Unifying invocant and topic naming syntax
Damian:
> ["it" will be passed to about 5% of subs,
> regardless of whether the context is your
> 10 line scripts or my large modules]
If the syntax for passing "it" to a sub
remains as verbose as it currently is,
you are probably right that "it" won't
be used to achieve brevity! I think it's
a pity given that the core point of "it"
is to achieve brevity.
Why do you think your estimate of Perl 6
usage of "it" is so much lower than is
true for the standard Perl 5 functions?
Btw, can I just confirm that one can't do:
sub f ($a = ) { ... }
or
sub f (;$_ = ) { ... }
where is the upscope it and $_
is the sub's topic.
> > Can currying include the given topic?
>
> Maybe.
Naturally, I see this as another symptom
of the way upscope "it" is being treated
as a second class citizen, and that this
is leading things in the wrong direction.
> > And what about a topic placeholder:
> >
> > $foo = { print $^_ };
> >
> > such that $^_ is effectively converted
> > to an 'is given($^_)'.
>
> No, that doesn't work. The placeholder
> $^_ is entirely unrelated to $_.
Well, it is at the moment, but there is
clearly mnemonic value between $^_ and $_.
> Besides, what's wrong with:
>
> $foo = sub { print $_ } is given($_);
Compared with
$foo = sub { print $^_ };
The answer is brevity, or lack thereof.
Why bother with currying? Why bother with
the "it" concept? None of these are necessary.
They simplify code generation, but their more
general feature is enabling brevity.
--
ralph
