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.
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)
:::: 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
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
> : 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
> 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".)
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.
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.
$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.
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?
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)
>> 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)
> > 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: $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: 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.)
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: 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
> 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
> 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).
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
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: 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: ~ 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.)
Re: [OT] Re: Perl Doesn't Suck
All, of course, imho: > Were something dreadful to happen to Larry and his estate chose to > change the licensing terms of the current *implementation* Well they can only do that to a copy of their own, not existing copies. While the law isn't clear on a lot of nuances related to more complex open source licenses, perl's is clear enough that it is implausible that A) a non-corrupt modern judicial system is going to interpret it in a way that allows license changes to apply retroactively to existing copies and B) they can then enforce this in a manner that truly stops a fork. (And guess which version the book authors and gurus would follow? Consider Borland's Interbase, which had a far more restrictive license, not even remotely as open as perl. Borland mucked about, so the community forked. All the gurus immediately backed the fork and the new direction was established in less than a week. Now Borland seeks to merge its fork (the original set of sources, since further developed a little) back with the community fork. This will happen, and the pragmatic strength of freedom over self-serving manipulation will have asserted itself.) > Try writing a second Perl implementation from > scratch. Indeed, Perl 6 is, afaik, a rewrite, from scratch. All you need is a community willing and able to do it. > Perl's great blessing is also it's great curse; there's a single > implementation and that *implementation* happens to be > OpenSource. If anyone concludes that a particular language with a clear spec that stands free of any given implementation is a lesser strategic risk than perl, then I think they should adopt that other language. I very much doubt they will have much success convincing those working on perl that a commitment to a spec that stands free of the current implementation would be a good use of their time, because the license is sufficiently free, and a stand alone spec that kept up with a continuously evolving and pragmatically driven thing like perl would take an inordinate amount of effort.
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: Perl DOC BOF
> 2. Format (quick to read, quick to write docs that link together; > 2 paragraph intro that becomes a daily tip) Are thinking of making a wiki a key part of the overall picture?
Re: Perl DOC BOF
> I haven't finished this idea yet but, I was talking with Andy Wardley > and this may be the idea. Except it will be the Template Toolkit > interfacing with wiki which means we can build filters that translate > POD. Of course, if the wiki internal format isn't some type of > DocBook, it's not going to solve all our problems very well. I was really thinking more of the generic wiki concept (super lightweight online editable hypertext, very much a spiritual cousin of POD), than any particular wiki. I was also thinking about literate programming. Basically, it seems like great timing to make the attempt to partially integrate: 1. POD; 2, An online editable hypertext engine for development of POD; 3. An online editable hypertext engine for discussion of all things; 4. Literate programming; Someone created a literate programming perl wiki that builds itself out of the pages of its wiki. Might be a good thing to look at.
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.
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
Re: Unifying invocant and topic naming syntax
> You're confusing brevity of declaration
> with brevity of use.
One needs sufficient brevity of both call
and declaration syntax if the mechanism's
brevity is to be of use in short scripts.
> Making (limited) circumvention of [$_'s
> lexicality] depend on a verbose and
> explicit syntax will help too.
Sometimes verbosity doesn't matter, but
I don't see how it can ever help. I'd buy
"clarity".
More to the point, the declaration syntax
will not help with avoiding accidents at
the time of call. So what is driving you
guys to deliberately avoid a brief def
syntax?
> > $foo = sub { print $^_ }; # shorthand for
> > $foo = sub { print $_ } is given($_);
> If you're proposing that there be some special
> exemption for $^_ so that it (a) doesn't
> placehold a parameter and (b) aliases the
> caller's topic instead
Well it clearly does placehold something.
In
method f ($self : $a) { ... }
sub f ($a) is given ($line) { ... }
what do you call $self and $line? I am
talking about being able to placehold
these things, whatever you choose to call
them.
> > Why bother with currying?
>
> You mean placeholders.
I meant currying. (I was listing mechanisms
that I believed existed to enable coding
brevity.)
--
ralph
Re: Unifying invocant and topic naming syntax
> > method f ($self : $a) { ... }
> > sub f ($a) is given ($line) { ... }
> >
> > what do you call $self
>
> The "invocant".
>
> > and $line?
>
> A lexical variable that happens to be
> bound to the caller's topic.
The "invokit" perhaps?
> placeholders create subroutines, not methods.
Oh.
Are placeholders only usable with anonymous
subs, or named subs too?
Switching briefly to currying, can one curry
a method?
--
ralph
Access to caller's topic (was Re: Unifying invocant and topic naming syntax)
> "access caller's topic" is an unrestricted > licence to commit action at a distance. Right. Perhaps: o There's a property that controls what subs can do with a lexical variable. I'll call it Yours. o By default, in the main package, topics are set to Yours(rw); other lexicals are set to not Yours. o A mechanism exists for a sub to bypass this access control for use with library routines. -- ralph
Re: Control Structures I: given
> My complete knowledge comes from > archive.develooper.com/perl6-language... > (search for "superpositions"). I find google (rather than develooper's archive/search) the best tool for most searching of p6lang. Unfortunately even google only goes back so far, and doesn't search punctuation. Perl 6's analog to "superpositions" is currently called "junctions". > Since I don't understand what ~~ does, Polymorphic equals. Smart match. The old =~ operator was a specific variant of this general idea. More generally, based on an a table of what to do for the various LHS/RHS combinations, a value is picked from the LHS and compared with a value picked from the RHS. The overall hope is it just DWIMs. -- ralph
Re: Unifying invocant and topic naming syntax
Larry:
> > sub bar(; $foo = ) {...}
Damian:
> topic [would be] C.
I assumed implied an 'is given'.
I don't see why it couldn't.
Damian:
> Hm. Given that the topic is in some sense
> a property of the lexical scope of the subroutine
> body, this might be a possibility:
>
> sub bar($foo is MY.topic) is given($whatever) {...}
Isn't this confusing dynamic and lexical scopes?
Perhaps:
sub bar (;$foo = YOUR.topic) { ... }
sub bar (;$foo = CALLERS.topic) { ... }
> > sub bar(*@args = $) {...} # default to [$_]
> >
> > What might be is an interesting, er, topic.
>
Damian:
> I would argue it ought to be just $_
You seem to be saying one could write:
sub bar (;$foo = $_) { ... }
Btw, can one write any/all of these and
have DWIMery:
sub bar (;$_) { ... }
bar ( _ => 1 );
sub bar (;$_ = $_) { ... }
As other's have suggested, a mumble of
$CALLERS::_ makes sense:
sub bar (;$foo = $CALLERS::_) { ... }
but I can see the point of a different
syntax dedicated to just the upscope topic
to avoid encouraging wider use of $CALLERS.
Hmmm.
--
ralph
Re: Unifying invocant and topic naming syntax
> > my sub foo ($_ = $_) > > > > to just propagate the outer $_ inward. > > That only works when $_ can somehow be > shoe-horned into the parameter list. > Whereas: > >my sub foo is given($_) > > works for *any* parameter list. Other than the placeholder situation, I don't understand when one could do the 'is given($_)' and not do the ($_ = $_). > > Possibly we have something more evil than > > that, such as the notion that $? is a double > > sigil that pulls a name out of the dynamic > > context's lexical scope. > > 1. Do we really want to allow every lexical to >be accessible anywhere in its dynamic scope? It is intriguing. One only needs to know the def of a sub one is calling. One does not have to worry about subs that get called by the sub one is calling. Imo one should know the def of a sub one calls. In this case one needs to know the pertinent arg /names/, not just their position, but that is already somewhat the case for optional args. When writing in the, er, medium (as against small or large), one could develop a variable name vocabulary, rather as one does with globals, but without its dangers: A (horrible, but hopefully illustrative) example: my $filename = 'foobar'; my $buf; open; read; write; delete; I'm imagining a potential sweetspot between globals and lexicals. An extension of the power of "it", which is just a way to talk more succinctly when you can get away with assumptions about nearby nouns. No? > 2. If we *do* want to provide that mechanism, >do we really want to make it that easy/subtle If the sweetspot I theorize above exists, then I think my answer is 'yes' to easy. But, no matter what, NO to subtle. It would be important that people know that any given arg is, er, given, or one just ends up with something that is halfway to the usual global problem. I'm thinking the syntax should be, in order of priority, LOUD, short, pleasing. I'm also thinking it would be nice to be able to say that the called sub's lexical shares its name as well as value (copy or bound) with the calling sub's lexical, without having to say the name twice. Further, that this would be a good pick as the norm, with the syntax optimized for that, so that it may be more cumbersome when you want the formal and actual arg names to be different. Perhaps we need some Unicode? ;> -- ralph
Re: Unifying invocant and topic naming syntax
> > don't understand when one could do the > > 'is given($_)' and not do the ($_ = $_). > > Any time that the caller's topic isn't > supposed to be explicitly passed as an > argument, but is still used within the > subroutine. > > [example] > > And, yes, I could make it an optional > argument, but them I have no way of > preserving my chosen interface. Or > porting that code cleanly. Well, it would mean the interface gets the additional facet that the caller can /optionally/ explicitly pass $_. I'd call that a benefit, not a problem. What's the issue with porting cleanly? > Besides all that, ($_ = $_) where $_ > means something different from $_ > is Just Plain Wrong. ;-) Well, I don't see it in quite that strong a tone. One could argue that the context of the rhs of assignments in the arg list is /naturally/ the caller's. But I agree it might cause a good ppl to double-take, because of the way it looks. More importantly, it doesn't seem LOUD enough for what it's doing. Unless it doesn't need to be loud because one sorts out the issue of protecting against potential problems by requiring some explicit marking at the caller's end, as I suggested in my recent "Access to caller's topic" post. -- ralph
Re: Unifying invocant and topic naming syntax
> >> $_ # current topic
> >> $__ # outer topic
> >> $___ # outer outer topic
>
> [not sufficiently visibly distinct]
> [too much anyway]
Agreed.
Returning to the topic of binding/copying
from a caller to a callee, what about using
square brackets to mark implicit args thus:
sub bar ($a, $b)
[$_, $foo]
{ ... }
In the above, implicit args go inside the
square brackets and the topic and $foo of
the sub being def'd are the same as (aliased
to) the topic and $foo of the calling sub.
As I said before, if you call a sub you
really ought to know that sub's signature,
and the above would make it clear that $_
and $foo are shared between caller and callee.
Of course, you might then come back and
change your calling code, accidentally
clobbering a shared lexical. So, back at
the caller end of things, I suggest the
following (simplified from an earlier post):
o There's a property that controls whether
called subs can share a given lexical of
a callee. I'll call this property Yours.
o By default, topics are set to Yours(rw);
other lexicals are set to not Yours.
--
ralph
Re: Unifying invocant and topic naming syntax
> c) the ability to break lexical scope Well, I could argue that c) already exists in the form of passing parameters in parens. Of course, that doesn't feel like "breaking" anything. So instead I'll argue that the word "break" is perhaps prejudicially perjorative. I'd say, to steer away from being ppp: c) introducing 'locals' or 'yours' Where this terminology and perspective comes from: My view is that c) is about sharing vocabulary between a caller and a callee to retain much of the referential simplicity and brevity of globals (and hence I think it's a pretty large issue), and c) is also about the fact that this can be done while omitting /all/ the dangers of globals (short of dangers that also apply to ordinary lexicals). Elements of this shared vocabulary might be called 'locals' or 'yours'. -- ralph
Re: Unifying invocant and topic naming syntax
> inheriting a caller's topic isn't going to be > that common a thing that it needs such a short > name, is it? 15% of the perl 5 builtins do so. I have suggested that, in some extreme scenarios such as short scripts, perhaps as many as 50% of subs might do so. But then again I probably ate a lot of cheese just prior to suggesting that. Damian has estimated that 5% of perl 6 code will do so. I've heard he can wolf a lot of pizza. -- ralph
Re: Unifying invocant and topic naming syntax
> > Elements of this shared vocabulary might be > > called 'locals' or 'yours'. > > I like the 'yours' idea from the point of > view of the callee: > > my $inherited = your $_; I like that syntax, but I'm uncomfortable with an underlying principle, which is that one can reach in to the caller's lexical context from any place in a callee's body. It exacerbates the (mostly over-stated, imo) action-at-a-distance concerns about this. I know you can do what you wrote anyway with the $CALLER::foo syntax, but I don't like that either. Allison et al have already intimated that they too find a generic 'yours' (or $CALLER::foo) capability that can be fired off anywhere in a sub's body to be dangerously obscure, to say the least. So while they expect to provide the raw $CALLER::foo capability, they have suggested some sugar that's a lot prettier AND a lot less dangerous for common cases (probably just for dealing with $_, though I am currently thinking it could work rather nicely to have it work for any lexical). Hence my focus on putting any callee side 'yours' sugar in the sub preamble. > However, I also like the idea of having to > mark shareable lexicals explicitly in the > caller, and the "your" keyword doesn't work > as well from the caller's point of view: > > your $_; > somesub(); # this sub can see $_ > > It almost calls for "our"; too bad that's > taken. I was thinking of yours as in "yours too", and as in a property: my $foo is yours; $_ would be yours(rw) by default, all other lexicals are not yours by default. The ability to have yours(ro) and yours(rw) is part of why I was thinking in terms of a property rather than a, er, whatever C is. -- ralph
Re: Unifying invocant and topic naming syntax
> # I'm uncomfortable [that]
> # one can reach in to the caller's lexical
> # context from any place in a callee's body.
>
> We need that capability if we're going to
> have lexically-scoped exports:
I think I was a bit careless in how I worded
that.
My problem is not that one reaches in to the
caller's lexical context, but where one gets
to declare that that is going to happen.
I am thinking one should have to predeclare
in a sub's preamble that such a trick will
be going on.
Thus something like:
sub foo [&bar] { ... }
is (part of what is) required to be allowed
to create a bar sub in the context of the
caller of foo.
--
ralph
Re: Unifying invocant and topic naming syntax
> # I am thinking one should have to predeclare
> # in a sub's preamble that such a trick will
> # be going on.
> #
> # Thus something like:
> #
> # sub foo [&bar] { ... }
> #
> # is (part of what is) required to be allowed
> # to create a bar sub in the context of the
> # caller of foo.
>
> So how does Exporter declare its import() function?
Keeping things simple, something like:
method import [*] { ... }
is required if one is to use $CALLERS::
in the body.
Skip the rest unless you enjoy flights
of pure fancy.
=
Being really radical, perhaps [*] means
that all the lexicals in the caller are
mapped to an identical set of lexicals
in the called. Dangerous stuff, huh?
Entering the realms of the truly insane,
one could have something like:
method import (@symbols)
[ { @symbols } ]
{ ... }
to indicate run time eval of the locals
list, but the above ignores all sorts
of practical problems and is plainly
huge overkill for the situation.
(All of this would of course still be
subject to the Yours property that by
default restricts localization to the
topic, and to non-existent lexicals,
ones the called sub intends to /add/
to the caller's lexical context.)
--
ralph
Re: Unifying invocant and topic naming syntax
> $_ = 1; mumble { $_ = 2 }; print;
>
> will print 1 or 2?
Least surprise, visually, is obviously 2.
This would be true if bare blocks (even
those passed as args) just pick up from
the surrounding lexical context. And if
that were true, mumble presumably could
not do anything about this (without some
as yet undefined language support).
What does this mean:
$_ = 1; mumble -> { $_ = 2 }; print;
perhaps the '->' could imply that $_ /is/
going to be private to the block somehow?
Could mumble somehow be a continuation that
alternated between generating values to be
plugged in to the block and executing it?
> sub mumble (&block) {
> block()
> }
>
> Oddly, if we make the first argument the
> topic by default, the second block actually
> gets &block as its topic. That's...strange.
This would go away with the above scenario.
--
ralph
Re: Unifying invocant and topic naming syntax
> [perhaps]
> : bare blocks (even those passed as args) just
> : pick up from the surrounding lexical context.
This is definitely a significant simplification.
Is it a problem?
> Yes, that's the problem. A bare block would
> have to notice at run time that it was called
> with unexpected arguments and unbind its
> binding to the outer $_.
That would be ughly, but I don't understand why
you say it must necessarily be so.
> : What does this mean:
> :
> : $_ = 1; mumble -> { $_ = 2 }; print;
> :
> : perhaps the '->' could imply that $_ /is/
> : going to be private to the block somehow?
>
> As it stands now, explicitly telling it there
> are no arguments would have exactly the opposite
> effect, and bind $_ to the outer $_.
Oh.
I had the vague notion that (inline) bare blocks
don't do anything special beyond establishing
a nested lexical scope:
$_ = 1; { $_ = 2 }; print; # 2
whereas '->' means the topic gets set and is
private to the block (ignoring aliasing effects):
$_ = 1; for @foo -> $_ { $_ = 2 }; print; # 1
It seems to me that a logical conclusion would be
that a blank arg list after a '->' would mean the
topic remains private (and is set to undef).
Perhaps having bare blocks work the same simple
way whether or not they appear as an arg, and
have -> behave the same simple way whether or
not it is used with, say, a for, or as a sub
def, introduces problems or lost opportunities
elsewhere that nix the whole idea. But wait...
> I think C has to be able to wrap its own
> idea of $_ around the block at compile time somehow.
Perhaps.
But presumably you agree that it would be
nice if the calling syntax naturally made
it clear how $_ was being bound.
And documenting this by the '->' distinction
described above (ie -> means private $_ set
by mumble, no -> means $_ is just the outer
lexical) would look natural as well being
logical and strikingly simple.
> Perhaps we need to distinguish the type of
> a "thunk" from a "sub" in the signature of
> C.
This would not be necessary with the scenario
I describe above.
--
ralph
Re: Unifying invocant and topic naming syntax
> > Are you suggesting this?
> >
> > if($error) {
> > use visible '&croak';
> > require Carp;
> > import Carp: 'croak';
> > croak($error);
> > }
>
> No - that would be pointless as well as error-prone.
>
> My idea of "visible" is that it would make a lexically scoped thing
> accessible to an inner dynamic scope at run-time.
>
> By default that would only apply to $_, but the mechanism should be
> generalisable to any name.
Yes. Regardless of the exact syntax, the idea
is presumably that the default way in which a
called sub can see/modify its caller's lexical
space is that it can see $_, can't see other
existing lexicals, and can add new lexicals.
Or something like that.
--
ralph
Dynamic scoping (take 2)
First, I'd like to confirm I've understood C and C right: 1. C dynamically scopes changes to a variable's value to the enclosing block. It does not dynamically scope the name. The variable can obviously be a global. It can also make sense if it is lexical. Is the latter currently allowed? 2. C is a conditional C; it only restores a variable's value if, on exit from the enclosing block, the block is somehow considered to have "failed". It can be applied to a global or lexical. The above two features are basically sugar for what would otherwise be achieved with paired FIRST/LAST/UNDO blocks. Both must be applied to an existing variable. Next, I want to do a better job of stating a problem I wonder about: Consider "environmental" values such as "screen sizes, graphics contexts, file handles, environment variables, and foreign interface environment handles." [1] Consider a sub One that is going to call a 10 deep stack of subs such that sub Ten needs to access one of these environmental values. How do you pass the data? A. Globals. Bad. Disastrous in threads. B. Passed as args to all intervening subs. Verbose. Sometimes incredibly verbose. C. Aggregate info into objects. But then you still have to do either 1 or 2 above with the object references. And it's a shame to be forced to the object paradigm unnecessarily. D. Use $CALLERS::. Relatively succinct, but definitely error-prone and ugly. Given what I understand of Perl 6 syntax, Parrot, and Perl philosophy, I suspect P6 should, and could fairly easily, provide a good solution to the problem outlined above. Does anyone agree the problem I've outlined is inadequately addressed by $CALLERS::? In previous emails I've suggested: 1. The notion of something like attaching a C property on variables, and picking appropriate defaults for its args (not/ro/rw), to allow the writer of a sub to easily strictly limit what a called sub can access. 2. The notion of args that are explicitly defined in a sub's sig but implicitly passed. This kills most of the verbosity of B above, while, in combination with the previous point, being otherwise just as safe as passing args explicitly all the way down the call stack. [1] http://tinyurl.com/2yhl -- ralph
Re: Dynamic scoping (take 2)
> [temp] > [implicit args] Here's a snippet of conversation on a haskell list about implementation of implicit args : http://tinyurl.com/2ym1 -- ralph
Re: Dynamic scoping (take 2)
In summary, I am proposing that one marks
variables that are to be automatically
passed from sub to sub with 'is yours'
where appropriate.
An example of what I'm suggesting follows.
Code with brief comments first then explanation.
{
my $_; # $_ can't be touched
# unless it is passed
# to a sub explicitly.
my $foo;# same for $foo
my $baz is yours; # $baz will automatically
$baz = 10; # be passed to /directly/
# called subs that "ask"
# explicitly for $baz.
&waldo($foo);
}
sub waldo ($b ; $baz is yours)
{ print $baz; &emer; }
sub emer (;$baz is yours(no))
{ print $baz; &qux; }
sub qux { ... }
Running this prints '1010'. Here's why:
A property exists that can mark any lexical
as "yours". When a variable is marked yours
it is automatically passed to any directly
called sub (not nested subs) that mentions
it appropriately.
The "automatic" $_ (available without
declaring with a 'my') is marked "yours"
by default.
All other (ie declared) lexicals are, by
default, not yours, hence guaranteed to be
private lexicals unless explicitly passed
to a sub. This is safer than the current
perl 6 design in which use of $CALLER::,
and even builtins and subs that merely
use the topic, might accidentally clobber
one of my lexicals at any time.
Once execution reaches the body of waldo,
there is a new lexical called $baz that is
bound to the lexical with the same name in
the body of the caller.
The C in waldo's sig has two
effects:
1. It requires that any /caller/ has a
variable of the same name marked as
yours or must pass a variable/value
using the named arg syntax for that
arg name;
2. It propogates the marking of $baz as
a yours marked variable for any sub
called from this, the body of waldo.
Once execution reaches the body of emer,
there is a new lexical called $baz that is
bound to the lexical from waldo which is in
turn bound to the lexical within qux.
The '(no)' at the end of the C
means that $baz is private to emer -- it
will not be passed to called subs by the
yours mechanism.
In summary, you mark variables that are
to be automatically passed from sub to
sub with 'is yours' where appropriate.
--
ralph
Re: Dynamic scoping (take 2)
> you propose a mechanism of passing [vars]
> between desired subroutins by default
> through all the dynamical chain of sub
> calls "connecting them.
There's more, or rather, less to it than that.
The same mechanism also includes a clean way
to pass "it", something that needs to be done.
And a way to smoothly extend that for user
defined "pronouns" like $first, $rest and
$last, through to mini-vocabularies like
$source, $target, $user, ...
(Imagine you pull in fop1, fop2, fop3 that
are file ops written by three independent
authors that just agreed to conventions on
naming args. With the mechanism I propose
you can now do something like:
my $source, $target, $user;
...
fop1;
fop2;
fop3;
To get this sort of simplicity, you have
to decouple inter-sub interfaces in a
couple ways, including arg positions and
package names.)
So I'm addressing several idioms that range
from passing one or two pronouns around in
the local vicinity, between a caller and a
called sub, to passing a whole suite of
values (an "environment") to an execution
thread and the far away subs it will contain.
> anyway, my feeling is that once it is
> necessary to pass variable far enough
> it is clearer to do it with globals --
> which are restricted to be seen only
> in the restricted set of lexical scopes.
That's name restriction, not the container.
This doesn't help when dealing with threads.
Basically, global /containers/ is the root
of all evil, not so much global names.
> package ... ;
> sub a { our $x is shared ; ... } ;
> sub b { our $x is shared ; ... } ;
This isn't thread-safe.
There are other significant issues too, but
I'll move on.
> [accidentally aliasing vars to the same global]
> I dont know how to stop this source of errors.
Having lots of little local namespaces that
get chained across long distances does away
with this problem.
--
ralph
