Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
On Sun, Oct 01, 2000 at 08:51:04AM +1100, Jeremy Howard wrote: A prototypeless-function call. get rid of them all!! Please no! Anything that makes it harder to write 'quick-and-dirty' scripts is never going to fly--this is part of what makes Perl special. Why? I see no problem in making -Mstrict and -Wall the defaults. Then make '-E' option to mean what '-e' means today, and '-e' mean -M-strict -Wnone -E Ilya
Re: Perlstorm #0040
==
I lie: the other reason qr{} currently doesn't behave like that is
that
when we interpolate a compiled regexp into a context that requires
it be
recompiled,
Interpolated qr() items shouldn't be recompiled anyway. They should
be treated as subroutine calls. Unfortunately, this requires a
reentrant regex engine, which Perl doesn't have. But I think it's the
right way to go, and it would solve the backreference problem, as well
as many other related problems.
==
The REx engine is reenterant enough right now. All you need to do is
to add the //p switch (or, meanwhile, rewrite each $qrn into (?p{ $qrn })).
Ilya
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
On Mon, Sep 25, 2000 at 06:30:22PM -0400, Karl Glazebrook wrote: Well, this shows that you entirely miss the problem of cryptocontexts. Context is determined by the "environment" of the operation, not by the operation. Context is propagated: the-left-hand-side-of-assignment --- the-right-hand-side-of-assignment so what is wrong with the statement '@y = 3*@x;' then ? That other constructs *also* create an array context, in which the behaviour of multiplication you propose is not appropriate. Changing Perl in this respect will make one particular mode of operation a tiny bit simpler, but (without major changes to cryptocontexting - PLUG see for example my interview on perl.com /PLUG) will make life much harder in other modes of operation. I think major changes are what we aree talking about here. I did not see any viable proposal on changing things in a major way. To design such a change is a *major* work. We need to keep a lot of possible combinations with other features in mind, and understand all the ramifications and desired/undesired interaction. We need insight. We need to balance the tradeoffs. I do not think we made *any* step in the correct direction yet. Remember: do you do your system mainainance in Mathematica? Why? Remember that Wolfram *wanted* you to do this? Perl5 is much better balanced. You are pulling the blanket to your side of the bed. I am not sure what point you are trying to make about Mathematica? I have read intevrviews with Woldfram ,he is clearky an egomanica and thinks everything should be an expression, but I am not sure he was arguing for system management in Mathematica. I did not mean interviews. 10 years ago I read the manual. It was clearly there. Ilya
Re: RFC 244 (v1) Method calls should not suffer from the action on a distance
On Mon, Sep 25, 2000 at 09:10:49PM -0700, Nathan Wiger wrote:
if ( want-{count} 2 ) { return $one, $two }
Will that be interpreted as:
'want'-{count}
want()-{count}
To be consistent, it should mean the first one. That is, the infix
operator - should always autoquote the bareword to the left. Am I
correct in assuming that's what you meant?
Yes. Use want()-{count} instead. Or, better,
use want;
wantCount;
Ilya
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
On Fri, Sep 22, 2000 at 11:17:40AM -0400, Karl Glazebrook wrote:
[Cryptocontext is:]
f(3*@a)
would typically be a list context - and suddently instead of 3*(1+$#a)
you get Cmap 3*$_, @a.
This is true, what I would propose is we declare 3*(1+$#a) outmoded and
always have it mean Cmap 3*$_, @a in all contexts.
You are trading a frequently used shortcut @a == 1 + $#a for a
rarely-used-but-beautiful/intuitive semantic. I'm not sure it is a win.
Moveover,
$x = 3 * @_;
suddently being equivalent to
$x = @_;
does not look very promising...
Why? Currently you can make them look like references to array. See
Math::Pari for an implementation. Overloading '@{}' gives yet another
way to do this.
True but the user has to remember 'owe I am now using a special PDL
array which means I have to always use a reference to it rather than
treat it like a perl array'. Not good.
No, you do not use "a special PDL array", you use "a vector".
A subtle change in wording - and no conflict.
This is true, but inelegant. If perl @x arrays are not considered useful
why not get rid of them and always use references?
Actually, this is what Perl is using internally (they are
softreferences==globs, but who cares?).
Ilya
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
On Fri, Sep 22, 2000 at 05:24:55PM -0400, Karl Glazebrook wrote: It's now boiling down to a matter of opinion and we'll have to agree to differ. Of course I use array arithmetic all the time as a heavy PDL user. ...Do you say you are confused by using vectors (=scalars) instead of arrays? Moveover, $x = 3 * @_; suddently being equivalent to $x = @_; does not look very promising... But would it not be easy to catch and warned by a p5tp6 converter? Why converters? I'm discussing Perl6 now, not converters. No, you do not use "a special PDL array", you use "a vector". A subtle change in wording - and no conflict. sure, but vector to me means 1D and also some sort of transformation properties whereas a PDL array is just a N-dim square container. An N-dim container is just a vector which contains vectors... Ilya
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
On Sat, Sep 23, 2000 at 09:52:51AM +1100, Jeremy Howard wrote: $x = 3 * @_; suddently being equivalent to $x = @_; does not look very promising... Why are these equivalent? RFC 82 only applies in list context. Am I missing something? Yes, the proposal to make map 3*$_ semantic to work in a scalar context too (to avoid cryptocontext). Ilya
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
On Sat, Sep 23, 2000 at 10:01:11AM +1100, Jeremy Howard wrote:
It's now boiling down to a matter of opinion and we'll have to agree to
differ. Of course I use array arithmetic all the time as a heavy PDL
user.
It's not just for number-crunchers either. Array notation greatly simplifies
many frequently used operations. For instance (from RFC 82):
@people = ('adam', 'eve ', 'bob ');
@scores = (7,9,5); # Score for each person
@histogram = '#' x @scores; # Returns ('xxx','x','x')
print join("\n", @people . ' ' . @histogram);
adam xxx
eve x
bob x
Are you trying to convince me/us that is going to be used often?
Array notation is not 'rarely used' in languages that support it--in fact,
operations are applied to arrays and lists at least as often as scalars in
most code I see written for Mathematica, J, PDL, and so forth.
a) You can *already* use vectors as scalars in Perl;
b) What we are discussing is Perl, not Mathematica, J, PDL, and so
forth. These languages have a very narrow niche.
Ilya
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
On Sat, Sep 23, 2000 at 10:41:07AM +1100, Jeremy Howard wrote: a) You can *already* use vectors as scalars in Perl; That's not what RFC 82 is proposing. Who cares? This already works... b) What we are discussing is Perl, not Mathematica, J, PDL, and so forth. These languages have a very narrow niche. That's because few such languages provide strong general purpose programming features as well. They are either limited maths-oriented languages (like Mathematica) or add-ons to general purpose languages that aren't fully integrated (Python/NumPy; Perl/PDL; C++/Blitz++). Many Perl users operate on lists of data. Requiring explicit loops every time a programmer wants to operate on a list is asking the programmer to fit in with how a computer thinks. That's not right. Well, this is your opinion agains mine... ;-) Ilya
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
On Thu, Sep 21, 2000 at 03:26:39PM -0400, Karl Glazebrook wrote:
[Aside: Why not make ternary-range operator into 10 :: 20 :: 2 ?]
That would work. My point is that having a stride is a fundamental
feature in other array languages (IDL, Matlab, PDL) and would be
useful in the perl core.
Did not use any steps more than 1 for a decade or so. But in 80's,
when people did not believe in 10^4..10^7 speedups my algos were
claiming, I needed to actually code them in Fortran ;-). I think I
used larger-than-1 steps that time.
But with Fortran such things are not *needed*. Compilers are smart
enough to convert (equivalents to)
map 3*$_, 34..67
into efficient code...
A proposal like this would make a nuisance into a nightmare. Yes, it
looks nice, but it contradicts many rules, so in the long run it is
going to be a significant step back.
...Unless the whole idea of cryptocontext is turned to become something else...
I am not sure what you mean by "cryptocontext"?
See p5p archives. (Significant) switching of the meaning of operations
basing on the context looks good on paper and for small examples, but
it breaks badly in slightly more complicated situations. The problem
is that the context is not always what you think. Say,
f(3*@a)
would typically be a list context - and suddently instead of 3*(1+$#a)
you get Cmap 3*$_, @a.
I guess the motivation here is to make non-core arrays (such as PDL
objects) look as much as possible like Perl arrays to simplify the
appearance to users.
Why? Currently you can make them look like references to array. See
Math::Pari for an implementation. Overloading '@{}' gives yet another
way to do this.
It's really hard to explain why people should use @x[1..10] for
perl arrays and $x-slice("1:10") for PDL arrays!
Use
$x-[1..10]
for both.
Ilya
Re: RFC 243 (v1) No special UPPERCASE_NAME subroutines
On Tue, Sep 19, 2000 at 08:05:50PM -0700, Nathan Wiger wrote:
$_ is not ALLCAPS. @EXPORT_OK should die (see RFC 233). @ISA is on
its way to its grave already, see Cuse base.
Yeah, but you're still just sidestepping my point. Your position seems
poised on the hope that no more special variables get introduced, or
that some of the existing ones go away.
Why not? This is going to be a very good thing too.
As for the different namespace for subs thing, I don't think that's the
way to go. You do have to call special subs directly, at the very least
from other special subs. And what if you wanted to provide an OO and
tied interface?
sub STORE {
# store data
}
*store = \STORE;
If I call $object-store, what will happen if STORE is a special method
like you propose?
I do not understand what your message is. If you need to share a
handler and a method, you can always do it like this (as I already explained):
sub store {
# store data
}
use tie STORE = \store;
Ilya
Re: RFC 243 (v1) No special UPPERCASE_NAME subroutines
==
No special UPPERCASE_NAME subroutines
Whoa! What about ALLCAPS variables? Should we axe all of them as well?
They're the exact same idea.
==
What ALLCAPS variables?
==
Then how would Perl differentiate between your proposed types here:
$obj = tie '@array', 'Tie::Array';
$obj-STORE(1,2);
When I call them directly?
==
You should not call handlers directly.
If a need like this arises, then
use tie STORE = \store_handler;
allows
$obj-store_handler(1,2);
==
Are you proposing a new method namespace? What about object-based
polymorphic overloading? What about DESTROY, BUILD, TIESCALAR, etc,
etc?
==
Exactly my point. All these names should not pollute the namespace.
==
And really, who writes normal routines in ALLCAPS? I never have.
==
"Who writes 3.14 if they are not meaning PI? Let us make 3.14 a
shortcut for 4*atan(1)" mentality...
==
use tie STORE = sub { ... };
not
sub STORE { ... }
Hmmm... this sounds like a less efficient approach. I think it's less
==
What do you think this has to do with efficiency? As I explained, it
can only be *more* efficient, since tie.pm could register things and
modify caching data etc.
==
I think it's less clean, too: we'd be moving away from pure integrated
language, back into a hack.
==
My point is that ALLCAP names are hacks.
==
* supposing UPPERCASE subs are still used for such speial functions
(callbacks, event handlers), Perl should warn if you use a sub with an
all uppercase name that isn't a registered callback. For example, in
using a tied filehandle, I made a sub CLOSE, and I wondered why it was
never called. It turned out that CLOSE wasn't a callback at the
time...
(It is now.)
==
What next? Spellchecking names and rejecting misspellings? But you
are right in the sense than my proposal addresses this problem as well.
Ilya
Re: RFC 244 (v1) Method calls should not suffer from the action on a distance
== Please show me how to write: print STDERR @stuff; without it, while keeping it a method of the STDERR filehandle, and without requiring -. == Why not use -? $IO::STDERR-print @stuff; print $IO::STDERR @stuff; == This would cause about 80% of Nathan's RFCs to die screaming, since they nearly all rely on indirect object syntax. == This is why I stole my time from other things to write this RFC. Additional remark: There is no conflict (I know of) in the method $var @args; syntax. Given that some people may consider this syntax to be cleaner than $var-method @args; (beats me why), it may be desirable to keep it. Ilya
Re: RFC 243 (v1) No special UPPERCASE_NAME subroutines
On Tue, Sep 19, 2000 at 04:22:31PM -0700, Nathan Wiger wrote: What ALLCAPS variables? Well, @ARGV comes to mind. I see, and @INC, %INC, %ENV, %SIG. Maybe we should provide a special namespace for these as well, besides main::? This is a nice possible solution. There may be many others as well... On the other hand, there are only 5 names, not hundreds of them, and they do not "get in the way", as ADD would do (prohibiting a method named ADD). So letting them be may be also a solution... Ilya
Re: RFC 244 (v1) Method calls should not suffer from the action on a distance
On Tue, Sep 19, 2000 at 04:26:47PM -0700, Nathan Wiger wrote: $IO::STDERR-print @stuff; print $IO::STDERR @stuff; Ok, something here is extreme confused. Is not the second form an instance of indirect object syntax? It is not with a bareword at the second place, so is not causing the action on the distance. (There are some other problems with this, such as having two frequently used constructs disambiguated by a hard-to-notice comma.) As I mentioned in the message you are answering to, there may be argument both pro and contra having IO syntax with variables stay, why IO syntax with barewords go. == This would cause about 80% of Nathan's RFCs to die screaming, since they nearly all rely on indirect object syntax. == This is why I stole my time from other things to write this RFC. Please explain what you mean. I browsed through the database, and saw that a lot of proposals rely on the syntax which should better go. Ilya
Re: RFC 243 (v1) No special UPPERCASE_NAME subroutines
On Tue, Sep 19, 2000 at 04:50:04PM -0700, Nathan Wiger wrote: Ilya Zakharevich wrote: On the other hand, there are only 5 names, not hundreds of them, and they do not "get in the way", as ADD would do (prohibiting a method named ADD). So letting them be may be also a solution... Uhhh, I think you should check the Camel. These variables certainly do get in the way, you can't create your own %ENV any more than you can create your own STORE without it drastically affecting your program. The presence of a method STORE is visible outside of the module, and may be required* if the module follows some published (non-Perl) API. Variables are of different ilk. Say, monk:~-perl -wle '@foo::ARGV = (1..5); print @ARGV' Name "foo::ARGV" used only once: possible typo at -e line 1. So you can have module variables with any names - @ARGV does not get in the way of APIs. And as for "5 names", there are a few more than that: $a, $ACCUMULATOR, $^A, $ARG, $_, @ARG, @_, $ARGV, @ARGV, $b, $BASETIME, $^T, $CHILD_ERROR, $?, You do not get these unless you request them. And they are not forced into the current package, so do not matter much. Ilya
Re: RFC 244 (v1) Method calls should not suffer from the action on a distance
On Tue, Sep 19, 2000 at 04:52:12PM -0700, Nathan Wiger wrote: Ok, you should clarify this. You're not suggesting that indirect object syntax be removed. You're suggesting that it should not accept barewords. These are two separate things. Agreed. I realized the ambiguity only after I posted it. Again, I think your RFC is far too terse and needs clarification. Make sure that you provide for telling people that this: $q = new CGI; needs to now be written as this: $q = CGI-new; in all cases. Thanks. Ilya
Re: RFC 243 (v1) No special UPPERCASE_NAME subroutines
On Tue, Sep 19, 2000 at 06:39:49PM -0700, Nathan Wiger wrote: The presence of a method STORE is visible outside of the module, and may be required* if the module follows some published (non-Perl) API. Variables are of different ilk. I think you're overlooking they can both be equally visible: $Foo::DEBUG = 1; Foo::STORE(5); depending on how you call them. As I said, special ALLCAPS variables cannot get in the way here. Or did I misunderstand what you wanted to say? So you can have module variables with any names - @ARGV does not get in the way of APIs. That's not really true. Try changing @ISA or @EXPORT_OK. Lots of stuff changes. And other variables like $_ do get pushed onto you involuntarily. $_ is not ALLCAPS. @EXPORT_OK should die (see RFC 233). @ISA is on its way to its grave already, see Cuse base. Ilya
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
On Sat, Sep 16, 2000 at 11:08:18AM +1100, Jeremy Howard wrote: proposes a convenient syntax to slice multi-dimensional arrays; It is hard to evaluate this proposal without more context. In particular: - How does it relate to RFC 204? Is it an alternative, or an addition? 204 cannot be implemented since it prohibits usage of overloaded objects as array indices. - How does it relate to RFC 81? The semantics of '..' seems to conflict. What I say conserns the usage of '..' inside an index only. It cannot conflict with anything else. - Why is it better to make ';' "special inside a hash/array index only" Because ',' is already special there. There is little chance that ';' operator is created as a general-purpose operator. - Why is a special token for a separator necessary "to avoid the (giant) overhead of creation of anonymous arrays"? Don't RFC 203 arrays and RFC 81/205 lazy generation avoid this? a) "Lazy generation" is not defined, as stated it is a good wish only. What is @a = (0, 2..99, 200..9998, 100); f(@a); ? My proposal has completely defined behaviour (AFAICS). [Yes, I was proposing lazy evaluation for a long time. But I know that it can be further than it appears.] b) The call for $a[2,3;5,6] is *) Put already-available SV pointers for $a, 2,3,4,5 and the cashed SV* for tie::multi::separator() on stack; *) Put the (cached) CV* for the method on stack; *) invoke the call frame; This is not *very* quick, but at least it may be "not that slow". While all the alternatives require creation of anonymous lists, which (I expect) will slow things down 7..10 times for the call above. For $a[1..100;1..100] it may easily be 100..1000 times slower. Your way was my way when I was designing Math::Pari. When I *implemented* Math::Pari, it took some time to determine why it was so much slower than what I expected. My proposal is based on this experience. Creation of [1,2,3] is *very* slow. - Overall, what is the problem in the existing array RFCs that this is designed to solve? *) They are not compatible with overloading (unless overloaded things are dramatically changed); *) They create a lot of temporary anonymous arrays the only purpose of which is to group arguments; *) They go very high on the bizzareness scale. - Can we incorporate a solution into the existing RFCs without creating a new conflicting one? If there are implementation challenges around the existing RFCs, I would rather make changes required to overcome them within those RFCs. I see no way how the existing RFC can be accepted. (No, I could not read the "include all the PDL" proposal to the end, so I cannot comment on this.) That we we get the benefit of the thought we've all put into the syntax of these RFCs, plus the benefit of Ilya's deep understanding of Perl internals. Thank you for suggesting that I do not need to think to create a RFC. Ilya
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
On Sat, Sep 16, 2000 at 07:15:34PM +1100, Jeremy Howard wrote:
Why is it important for overloaded objects to be used as array indices?
Overloaded objects should behave the same way as non-objects.
Why
does RFC 204 rule that out? RFC 204 simply specifies that a list reference
as an index provides multidimensional access:
$a[ [1,1] ] == $a[1][1];
I repeat: what does
$a[ $ind ]
does if $ind is a (blessed) reference to array (1,1), but behaves as
if it were 11 (due to overloading)?
RFC 81 expands on the existing operator '..' in a list context to allow more
generic list generation. It is particularly useful to generate lists to act
as array slices:
@a[ 1..5 : 3] == @a[1,3,5];
This would seem to conflict with the meaning of '..' outlined in RFC 231.
Sorry, I see no conflict. (Assuming that ternary '..' is allowed, the
token tie::multi::range() would be followed by 3 numbers, not 2.)
These calls will result in
tied(@a)-FETCH_RANGE(tie::multi::range(), 1, 5, 3)
tied(@a)-FETCH_RANGE(1, 3, 3)
If FETCH_RANGE uses tie::multi::inline() to preprocess the keys, this
*by definition* will result in the same array of keys. If not, it
is the responsibility of FETCH_RANGE to insure the equivalence.
And $a[ 1..5e6 ] would not need to create 5e6 Perl objects the only
purpose of which is to inform the range extractor that it needs to
create an object representing the slice.
Because ',' is already special there. There is little chance that ';'
operator is created as a general-purpose operator.
When we first discussed ';' on the list, we looked at making it special in
an index only. But the more generic approach of making it a cartesian
product operator seems cleaner--it avoids 'special' meanings in favour of
providing a generic operator.
No, it is not a generic operator. Its behavior depends on whether it
is used *inside parens*, or not. Additionally, the behaviour of
cartesian product makes very little sense: if you did not want it 3
times, you should not insert it into the language.
a) "Lazy generation" is not defined, as stated it is a good wish only.
What is
@a = (0, 2..99, 200..9998, 100);
f(@a);
Lazy generation is a well understood concept in other languages.
Maybe. But it is not defined in the corresponding RFC nevertheless.
At least: all I could deduce was that the following constructs are
made synonymous:
@a = ($a .. $b);
tie @a, Array::Range, $a, $b;
No other usage of .. is covered.
b) The call for $a[2,3;5,6] is
*) Put already-available SV pointers for $a, 2,3,4,5 and the cashed SV*
for tie::multi::separator() on stack;
*) Put the (cached) CV* for the method on stack;
*) invoke the call frame;
This is not *very* quick, but at least it may be "not that slow".
While all the alternatives require creation of anonymous lists, which
(I expect) will slow things down 7..10 times for the call above. For
$a[1..100;1..100] it may easily be 100..1000 times slower.
Lists of lists of known simple type are proposed by RFC 203 to be stored as
true arrays (i.e. contiguously in memory). Their overhead is not the same as
Perl 5 lists of lists.
Maybe. But you still need to create 200-elements temporary array
the only purpose of which is to inform the tied array that you need
the upper-left 1000x1000 submatrix.
*You do not want to create new values uncessesarily*. This is too
slow. Quick operations should reuse already available values
instead. See how scratchpads work...
Even if it is creation of a "streamlined" array, creation still will
takes much more time than operation dispatch - which is in turn
painfully slow.
The index in $a[1..100;1..100] should be generated lazily.
This is *exactly* what my proposal is doing. The difference is that
it defines what "lazily" means.
*) They are not compatible with overloading (unless overloaded things
are dramatically changed);
There are a number of RFCs proposing substantially changing overloading.
What specific changes would we need to ensure were incorporated in P6 to
avoid this incompatibility?
I see no way how they can be made compatible. Overloading allows
objects to behave *both* as numbers and as array references.
Well, maybe there is a solution: 2 new overloaded accessors in
addition to '""', '0+', 'bool', '@{}', '${}' etc: "extract the value
as the array/hash index", defaulting to '0+' and '""' correspondingly.
*) They go very high on the bizzareness scale.
Bizzare??? Which RFC?
Binary ';'.
RFCs 90 and 91: These builtins are in almost all languages with rich array
functionality. 'merge' and 'demerge' are more frequently called 'zip' and
'unzip', but those terms were almost universally rejected on -language.
These are convenience functions. I do not see what they have to do
with the language design...
RFC 204: Isn't it fairly intuitive that:
$a[ [1,1] ] == $a[1][1];
It may be - for people who do not
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
On Sun, Sep 17, 2000 at 11:07:09AM +1100, Jeremy Howard wrote:
I repeat: what does
$a[ $ind ]
does if $ind is a (blessed) reference to array (1,1), but behaves as
if it were 11 (due to overloading)?
How $ind is implemented (ie the actual structure that is blessed) does not
matter. What matters is what interface its class provides.
As I said: it provides *both* numeric value and list reference
interface (as complex values may do).
quote
When a lazy list is passed to a function it is not evaluated. The function
can then access only the elements it needs, which are calculated as
required. Furthermore, the arguments that generated the list are available
as attributes of the list, and can therefore be used directly without
actually accessing the list
/quote
f(1, 10..1e6, 1e8..2e8, 1e9)
How can the body of f() query the "attributes" to see that it got
something lazy?
Furthermore, RFC 81 proposes syntax beyond just ($start..$stop: $step).
Implementing it using tie::multi::range() followed by 3 numbers would not be
enough.
Another example of "bizzare" (and not completely defined) interface.
I would think it stands a very little chance to become reality.
Apparently, the authors of RFC81 assume that iterators become better
integrated if they are introduced by a funny syntax. Since what they
want to accomplish is exactly this...
my $iter = new iterator start = $a, next = sub {};
foreach my $i (each $iter) {...}
Here an iterator is something which overloads '' (in Perl5 speak).
A way to integrate iterators would be very convinient indeed. As you
see, in principle it does not need any funny syntax...
Anyway, we're defining a language interface here, not an
implementation, so we don't really need to nail this down immediately.
No, an interface without a feasible implementation in mind is not viable.
# Slice syntax extension
@2d_slice = (0..1 ; 0..1); # ([0,0],[0,1],[1,0],[1,1])
This is very expensive. Do you know any example when such a list is
needed as a final result, not as a temporary?
@a = ($a .. $b);
tie @a, Array::Range, $a, $b;
No other usage of .. is covered.
RFC 81 defines 4 uses of C...
Sorry, the only context which I could find is the one above.
The index in $a[1..100;1..100] should be generated lazily.
This is *exactly* what my proposal is doing. The difference is that
it defines what "lazily" means.
Except that your proposal changes the language interface. In particular, it
doesn't allow the creation of contiguous slices, AFAICS. @a[1..100;1..100]
should refer to the whole box bounded by (1,1) and (100,100).
I have no idea what you are talking about. What else can it *mean*
but the whole box? Having different calling conventions does not mean
that the *results* are different.
It's very important. It shows that a particular syntax is intuitive enough
that it is understand by people with a wide range of backgrounds. Intuitive
syntax is an important language design goal.
The syntax and the access-semantic of RFC81 and of RFC231 are the same.
However, RFC231 explain how this semantic can be achieved via simple
tie() interfaces.
RFC 231 does not (yet) effectively cover the same range of problems that the
array RFCs do. We need multidimensional slicing (not just multiple
indexing)
Is in RFC231.
flexible list generation,
This is orthogonal. And I do not see why this is needed to be in the
core language at all. I would guess that an appropriate module with
interfaces to generate efficient arrays is a better place for this
(see the example above).
multiple levels of indirection,
Do not know what you mean here.
and fast and compact reshaping.
If we want the reshaping to be supported by builtin arrays *and*
transparently by overloaded arrays, then yes, it is needed to be in
the core. But I see no need for this.
Again, this looks as belonging to a module, not to the core.
Ilya
Re: RFC 232 (v1) Replace AUTOLOAD by a more flexible mechanism
On Fri, Sep 15, 2000 at 03:11:47PM -0600, Nathan Torkington wrote:
Perl6 RFC Librarian writes:
This RFC proposes two-stage autoloading: one stage may be registered
to act when the symbol is encountered at compile time, the other
when the subroutine is called. Autoloading on the second stage does not
Icall the subroutine, only Iloads it.
You have a beautiful mind, Mr Zakharevich. I'd like to frame it on my
wall.
I can see that the nail that attaches it to my wall is already shaky...
When it is falls down, feel free to pick it...
Actually, I think I'd like to see this extended. I'd like to be able
to hook into the parser so that when it sees a function call:
foo()
I can have it call my subroutine.
foo_handler( $token_stream )
foo_handler can access the token stream that may or may not be part of
the argument list, decide what is, and then return the code to be
executed at runtime (normally just a call to foo()):
sub foo_handler {
return sub { foo() }; # *not* an infinite loop, please
}
This is just a user-defined operator (which see on p5p). You register
foo() as a user-defined operator (with the precedence/etc of a
function call - or of a unary or nullary function). Then your handler
gets the OP trees for the arguments.
By the way, if you do not need to inspect the argument OP trees at
compile time, you may extend the discussed proposal to allow the
compile-time action to return EITHER prototype, OR a subroutine
reference.
Getting arguments at compile time is tricky: you cannot get them
unless you know the prototype already. RFC18 and user-defined
operators avoid this since they specify the prototype *before* the
call is encountered.
Context-coercion:
sub foo_handler {
my $token_stream = shift;
my $arg_1 = $token_stream-next; # assuming passed as strings?
return eval "sub { scalar($arg_1) }";
This is the part of my proposal for user-defined-operators: you can
force context for your arguments. Keep in mind that UDO are at least
partially orthogonal w.r.t. RFC18: they see already compiled trees
(but can modify them if needed), and not the string arguments.
This is the problem with RFC18: you cannot "partially compile"
things. How many arguments for f() in
f($a, $b, g my $c, $d);
3 or 4? This depends on the arity of g(). But you cannot find this
arity until you compile the call frame for g(), and then lexical $c is
already introduced! So you cannot make f() to be a "comment", just
the act of determining the arguments to f() has side-effects.
Ilya
Re: Proposal for \v and \V, the small- and large- cut regex opera tors.
On Thu, Aug 10, 2000 at 11:12:28AM +0200, Johan Vromans wrote:
Of course, we need group names (trivial), and group temporaries.
I needed the latter to define a generic pattern to match quoted strings:
you need to store the starting quote somewhere to find the ending quote,
but I didn't want this to have impact on the pattern as a whole. E.g.,
$qp = qr/((['"]).*?\2)/;
@a = $str =~ /$qp/g;
and have @a contain only the quoted strings, and not (also) the individual
quotes.
$quoted = qr/(['"]).*?\2/;
@a = $str =~ /($quoted)/gp;
Here //p is the "postponed" flag. Put (?p{$quoted}) instead of
$quoted to get this semantic now (or some other char).
Ilya
