Re: RFC 153 (v2) New pragma 'autoload' to load functions and modules on-demand
>>>>> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: PRL> New pragma 'autoload' to load functions and modules on-demand You must have missed all the discussion on -internal and the discussions about moving things out of the core. Even an autoload pragma will not be needed. Upon installation a module (and its exported services) could (note the could) be registered and perl will take it from there. No fuss, mess or bother. The actual mechanisms and what qualifies for registration are currently undecided. But all core (i.e. in the tarball) modules that are not judged as requiring a use will be in there. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 23 (v5) Higher order functions
>>>>> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>> Let me ask you:
>>
>> foo('a','b', 'c')
>>
>> Is 'b' the 1st parameter or the 2nd?
DC> This is the classical mistake of confusing indices and ordinals.
DC> The 1st argument is bound to the parameter whose index is [0],
DC> The 2nd argument is bound to the parameter whose index is [1], etc.
But why make it an index? It just reads better as an ordinal.
DC> Assuming they've read L, they'll know that ^1 is $_[1] is
DC> parameter [1] is the 2nd parameter. They'll know because at the very start
DC> of L I will write:
DC> ^1 means $_[1], NOT $_[0]
[snip. Last message repeated too many times.]
If you have to do that, that is a good argument to follow the 'natural'
inclination.
Again, why insist on an index when it really is closer to an ordinal when
reading the actual code.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 23 (v5) Higher order functions
>>>>> "AG" == Alan Gutierrez <[EMAIL PROTECTED]> writes: AG> Just like the the regex match placeholders, positional placeholders begin AG> with ^1 so that ^1 == $_[0]. If this doesn't make sense to it is AG> probably because you are new to Perl and are not familiar with regular AG> expressions, but we did things this may to make it easier for AG> you to understand (assuming you read the regex chapter of the Camel AG> before the curry chapter.) Just saying that makes my point. ^0 and $0 ^1 and $1 The ordinal concept onto the arguments matches much better. There is already a break between @foo = /(..) (..) ... / and $foo[0] and $1, ..., $foo[n] and $n I and several other folks made our point. We see this more akin in nomenclature and appearance to the regexp matches, then to a invisible offset into an array. All I ask is the Damian add our comments to the RFC. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 23 (v5) Higher order functions
>>>>> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> But I'm *never* going to take out ^0. Having ^1 mean $_[0] is Just
DC> Plain Wrong.
Though I see your point. I'm not sure how many would make the connection
between ^1 and $_[0].
I see ^1 as the _first_ argument not as the zero-th offset. To my eyes
a positional rather than an offset is more appropriate. It just reads
better.
Let me ask you:
foo('a','b', 'c')
Is 'b' the 1st parameter or the 2nd?
sub { ^1 + ^2 }
And when a newbie, not one of the oldtimers whose been part of perl6 since
Damian's RFC came out. Would they think that the second and third arguments
were added or the first and second?
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 75 (v2) structures and interface definitions
>>>>> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: PRL>%DataHash = unpack $mypic, $SomePackedCobolData; Does it unpack it into the hash? Or does it keep a pointer into the original structure? What happens when a new key is added to the hash? What happens if the underlying structure is overlayed? sysread(FOO, $SomePackedCobolData, $length); %DataHash = unpack $mypic, $SomePackedCobolData; sysread(FOO, $SomePackedCobolData, $length); -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 174 (v1) Parse C as C
Doesn't this move compile time work into run-time? >>>>> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: PRL> This should be made to work correctly. The following order of function PRL> parsing should apply to Perl 6: PRL>1. The current package should be checked for a function PRL> by that name (including any imported ones), consistent PRL> with current behavior. PRL>2. Argument 1 should be checked to see if it is a valid PRL> object reference. If so, the method should be checked PRL> for existence as a member. PRL>3. AUTOLOAD should be called. PRL> The only new step here is step #2. Notice that this does NOT override PRL> current-package functions. Only if a function is not found in the PRL> current package is the translation attempted. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, andwantarray() changes
What you want is a pre-condition on the overridden assignment operator.
What you want to do may involve having the suggested transactional
variables.
>>>>> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> Damian Conway writes:
>> pre mymethod : group("safe-coding practice") { @_ > 0 }
>> pre mymethod : group("debugging") { print @_, "\n"; }
NT> Using these for lvalue subs doesn't give you the behaviour you want:
NT> sub foo :lvalue { $foo }
NT> post foo { die if $foo == 5 }
NT> eval {
NT> foo() = 5;
NT> };
NT> Should not set the lvalue of foo to 5. But you can't test for
NT> bad values until after you've made the assignment.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, andwantarray() changes
>>>>> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> However, I have given thought to allowing conditions to be grouped,
DC> and de-activated by group. This would probably meet your need.
>>
DC> pre mymethod : group("safe-coding practice") { @_ > 0 }
DC> pre mymethod : group("debugging") { print @_, "\n"; }
>>
>> Makes it difficult to specify on the command line. Unless you have
>> another way of matching them to higherarchy or perhaps a cost level?
DC> There would be a 'contract' pragma:
DC> use contract qw("safe-coding practice");
DC> no contract qw("debugging");
DC> no contract;# turn everything off (production code)
One issue that bothers me with this. Even though it is a _minor_ edit,
I never like to twiddle a working piece of code. No contract should
be the default, and during testing it should be overridden from the
command line.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, andwantarray() changes
>>>>> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>> How would you handle differentiating between safe-coding practices and
>> debugging type (internal) pre/post conditions?
DC> Why would one bother?
There are two types, as I imagine them. Gatekeeper code. (Did the user
send me frobnitz?) and Internal consistency checkers. The internal
consistancy checkers would only be used perhaps during alpha, and
regression test phases (or even when a user has sent a complaint).
But the Gatekeeper code would be left around. But then for really
high performance it would be turned off.
I don't imagine that in the invariant you would want to do some of the
real and truly costly checks.
DC> A comment would serve to distinguish them, wouldn't it?
Not if one wanted to turn them off.
DC> However, I have given thought to allowing conditions to be grouped,
DC> and de-activated by group. This would probably meet your need.
DC> pre mymethod : group("safe-coding practice") { @_ > 0 }
DC> pre mymethod : group("debugging") { print @_, "\n"; }
Makes it difficult to specify on the command line. Unless you have
another way of matching them to higherarchy or perhaps a cost level?
"gatekeeper"=> 1
"safe-coding practice" => 4
"sanity checks" => 10
"debugging" => 30
Dr. Meyers seems to offer that with Eiffel.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 154 (v1) Simple assignment lvalue subs should be on by default
>>>>> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:
NW> If arrays are maintained "properly" (not flattened) in Perl, then they
NW> will remain separate, whether as parameters, across = assignments, etc,
NW> etc. The same goes true for mixing arrays and scalars and hashes:
NW> @stuff = docoolstuff(%hash, $var, @array);
NW> @stuff = docoolstuff(%hash, $var) = @array;
Then assignment arguments must be a the tail of the prototype. A bit
of limitation. If you do want to persue this, and it is acceptable
it should come in on a non-calling parameter. A seperate communication
channel.
Hmm, your proposal also make a non-lvaluable subroutine lvaluable. With
arbitrary values.
sub foo { launch_missles if $_[0] }
foo = 35;
The current thinking in -internals is that @_ will continue to flatten
the arguments. So any rvalues being pushed in will be lost.
>> By limiting it to only the programmer specified arguments, you reduce
>> complexity with no loss of generality.
NW> You do lose the ability to chain subs together, which is neat. For
NW> example, using a sub a middle value to a split():
NW>@user = ($uid, $x, $p->format) = split /:/, ;
This sounds like a valid reason. But again if a seperate channel is provided
then it is much clearer what is going on.
But if tieing were made simpler then this could be done (with a little
more syntax.
tie $magic, (something to do with $p->format)
@user = ($uid, $x, $magic) = split /:/, ;
Or perhaps something along the lines of ksh's <() syntax?
@user = ($uid, $x, >($p->format)) = ...
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 149 (v1) Lvalue subroutines: implicit and explicit assignment
>>>>> "JM" == James Mastros <[EMAIL PROTECTED]> writes:
JM> If those two paragraps (and the two after them) are replaced with < what's still wrong with the RFC?
JM> Therefore, return values of lvalue subs stay as their final GV, which is
JM> passed into the assignment, and is then assigned to the rvalue.
JM> CUT
JM> (Note that "stay as their final GV" is equivlent to that whole long
JM> paragraph, I think. I'm not too good at internals yet (but I'm trying to
JM> learn).)
Stay away from implementation, specify the semantics. The internals will
probably have nothing to do with the old perl5 internals. I think all
of the SV, etc will probably go away. (A GV is a glob I believe not
something that holds a value. SV is a scalar, AV, is an array)
Perhaps you could simply specify that perl will take the return value
and treat it as a 'pointer', 'reference', 'lvalue' if it can.
I think of it as the return value being translated
sub foo { return %hash }
foo = %other;
as being
%hash = %other
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 154 (v1) Simple assignment lvalue subs should be on by default
>>>>> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:
NW> Can be called as any of these forms by default:
NW>$old = assign($var, $val);
NW>$old = assign($var) = $val;
NW>$old = assign = $var, $val;
NW> Make sense? This RFC doesn't address true lvalue subs, rather that
NW> rvalue subs should be able to be used in an lvalue assignment context by
NW> default. It is a limited but valuable syntactical tool.
I don't think that the assigned values should be moved by perl into
the argument list.
By limiting it to only the programmer specified arguments, you reduce
complexity with no loss of generality.
You are reintroducing another version of the list flattening problem.
"Where do the arguments belong"
foo((1,2,3),(4,5))
foo((1,2),(3,4,5))
I don't think we want to go there. One of the thoughts currently on
-internals is that the original lists/arrays would be maintained on
the stack so that it would be easier to split them for the
named/positional arguments.
Larry may also allow
(@foo, @bar) = (@bar, @foo)
to work as most would expect.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 154 (v1) Simple assignment lvalue subs should be on by default
>>>>> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
PRL> The key to the proposal is this: lvalue and rvalue versions of a sub
PRL> would work I, and both would be enabled by default.
PRL> I, assignment is the only valid operator for these default
PRL> lvalue subs. Attempts to use other operators, such as ++ or s/// on
PRL> these subs would yield an error like:
PRL>Attempt to modify simple lvalue sub, only = is allowed
Why this limitation?
Once perl has the object/reference/pointer to the lvalue, perl should
be free to modify it at will.
If the lvalue is a fundemental type (whatever that is) everything works
as if the lvalue were actually in place
sub foo { return $a }
foo =~ s///;# same as $a =~ s///;
If $a is a user defined object, then the same _as if_ rule would apply
and the object would mediate the operation.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 149 (v1) Lvalue subroutines: implicit and explicit assignment
>>>>> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
PRL> Therefore, the definition of the return function must be changed
PRL> such that it is lazy.
PRL> Additionally, the definition of assignment must not normally
PRL> evaluate a lazy expression, but rather evaluate it to the point
PRL> where its value would become the value of a B, and then
PRL> assign to that variable. If the expression cannot be evaluated
PRL> to that point, (for example, C<$x+3>), then it may be an error to
PRL> assign to it.
If I understand you correctly the actual target of the assignment
would be delayed.
Which leads me to ...
{
my $foo = lvalue_with_lazy_return;
$foo = 42;
}
I wouldn't want the 42 going, who knows where. I want the value of $foo
replaced with 42.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, andwantarray() changes
How would you handle differentiating between safe-coding practices and
debugging type (internal) pre/post conditions?
>>>>> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>> I would have assumed that a pre/post/invariant would not be used regularly,
>> but rather under optional control. So this would lose that feature.
DC> The option is to opt out of preconditions, not opt in.
DC> Besides, I intend to propose an attribute that makes them un-opt-out-able:
DC> sub new { bless {}, $_[0] }
DC> sub x { lreturn $_[0]->{x} }
DC> post x : mandatory { $_[0]->{x} >= 0 }
DC> Damian
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, andwantarray() changes
I would have assumed that a pre/post/invariant would not be used regularly,
but rather under optional control. So this would lose that feature.
>>>>> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>> So if all I want to do is make sure that certain attributes are positive
>> integers, I have to do this:
>>
>> [ admittedly ungainly solutions snipped ]
>>
>> I'd much prefer a solution where the positive-only logic was in a method
>> belonging to the class, rather than being attached to afflicted attributes.
>> The only ways I can see of doing this are like Gnat or Andy's RFCs.
DC> TMTTWTDO! ;-)
DC> What you really want is a postcondition or class invariant.
DC> One that asserts that x is always positive:
DC>sub new { bless {}, $_[0] }
DC>sub x { lreturn $_[0]->{x} }
DC># and one of...
DC>post x { $_[0]->{x} >= 0 } # post condition on x attribute
DC>ensure { $_[0]->{x} >= 0 } # class invariant
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 23 (v4) Higher order functions
To Damian and all other RFC authors. Please add a CHANGES section. Would you be kind to us lost souls that are trying to read these things. >>>>> "DC" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: DC> This and other RFCs are available on the web at DC> http://dev.perl.org/rfc/ DC> =head1 TITLE DC> Higher order functions DC> =head1 VERSION DC> Maintainer: Damian Conway <[EMAIL PROTECTED]> DC> Date: 4 August 2000 DC> Last Modified: 20 August 2000 DC> Version: 4 DC> Mailing List: [EMAIL PROTECTED] DC> Number: 23 -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 132 (v1) subroutines should be able to return an lvalue
>>>>> "JV" == Johan Vromans <[EMAIL PROTECTED]> writes: >> These two should have different actions. >> >> $foo = &foo; >> &foo = $foo; >> >> Perl needs a value for one, and a reference for the other. JV> I'm not sure I understand what you trying to say here. Please explain. The difference between RHS and LHS. RHS, perl is manipulating values. With LHS perl is manipulating locations, storage areas. Where to put those values from the RHS. So RHS are values (even if a reference, it's meaning as a value is of interest) LHS are pointers. Where to save the value from RHS. So an lvalue sub on the RHS should be returning a _value_ an lvalue sub on the LHS should be tell Perl where to shove^w put the value. (Hey, perl, I want that dohickey put into my array at position 42.) JV> - make it unfeasable for methods. >> >> Why? All methods for the same OO hierarchy should have the same signature. JV> Assume class Foo has a method m that returns a scalar lvalue, and JV> class Bar has a method m that returns an array lvalue. The following JV> code is now perfectly legal (though weird): JV> my $o = $some_condition ? Foo::->new() : Bar::->new(); JV> $o->m = another_sub(); JV> 'another_sub' calls wantarray. What should it return? That's the point. Perl has to examine $o->m 's return to determine what is going on. So $o-> has to be called first. And the resulting reference queried about it's type. And then the want() will return the correct context. In the another_sub( lvalue_sub ), lvalue_sub has to be defered until the first time it is called. (Unless Damian thinks that reaccessing it each time will make more sense.) -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 132 (v1) subroutines should be able to return an lvalue
>>>>> "JV" == Johan Vromans <[EMAIL PROTECTED]> writes: JV> An attribute would JV> - require the sub to be consequent in what it returns; I can't parse that line. JV> - require the sub to be predeclared before it can be used; lvalueness seems to be appropropriate. These two should have different actions. $foo = &foo; &foo = $foo; Perl needs a value for one, and a reference for the other. JV> - make it unfeasable for methods. Why? All methods for the same OO hierarchy should have the same signature. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 132 (v1) subroutines should be able to return an lvalue
Perhaps foo should be lazily evaluated. Then the want would return the correct usage. Though once the value is returned, it should stay that way on all subsequent usages until the call stack is unwound. >>>>> "DC" == Damian Conway <[EMAIL PROTECTED]> writes: >> > Besides, context can't always tell: >> > >> >bar ( foo ); >> > >> > Should foo return a copy or an alias? >> >> want() obviously needs an additional parameter: how deep to go >> back in the call stack. Which begs also for a way to find out how >> deep is the call stack. DC> That wouldn't help in this case, since it's a matter of whether the DC> programmer intended to pass by copy or alias here, and that isn't encoded DC> *anywhere* on the call stack. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 132 (v1) subroutines should be able to return an lvalue
What about?
sub foo { lreturn ($one, $two, $three); }
foo = (0..10);
or
foo = &bar;
The compiler needs to know what foo is returning. The attribute tells
perl evaluate foo to determine the context (i.e. where to put the
dirty laundry) and the goes ahead and does the rest.
If you do it as scalar only. You lose a lot of useful possiblities.
Why do you mind having an attribute?
Is there anyting in perl that defines the order of evaluation?
$foo[$a] = $bar[$a++];
If there isn't, then we should be free to invoke the left hand side
to determine the context.
And the attribute allows the compiler to build an optimized optree
in the non-lvalue case.
>>>>> "JV" == Johan Vromans <[EMAIL PROTECTED]> writes:
JV> Damian Conway <[EMAIL PROTECTED]> writes:
>> [EMAIL PROTECTED] (Randal L. Schwartz) writes:
>>
>> > So is that something we've agreed, that lvalue subs are *always*
>> > scalars? That'd mean we can move on to the various implementation
>> > details. :)
>>
>> Err, I for one would like to see *any* data types lreturn-able.
JV> So do I. But, as Randal pointed out, there seems to be a catch here.
JV> With the "scalar lreturn" proposal the sub definition does not need
JV> something special (like an :lvalue attribute) and, more important, the
JV> compiler need not know whether a sub call might involve an lvalue
JV> returning sub, or a sub that chooses to actually do an lreturn.
JV> A sub is not lvalued by declaration, it may return an lvalue if it
JV> decides to do so.
JV> All other proposals I've seen not only require special attributes
JV> and/or parameter specs for the subroutine definition (which is not a
JV> problem per se), but also seem to require that the compiler knows it's
JV> compiling an lvalue sub call, and hence this sub must be predeclared
JV> or otherwise made known to the compiler. A sub is lvalued or not, and
JV> the compiler must know. And this seems to be virtually impossible when
JV> method calls are involved.
JV> -- Johan
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 128 (v1) Subroutines: Extend subroutine contexts to include name parameters and lazy arguments
Or the lack of a %rest? >>>>> "DC" == Damian Conway <[EMAIL PROTECTED]> writes: DC> * Label an argument such that there is no corresponding named DC> parameter. >> >> Could this be eased slightly? How about a %rest hash, if supplied >> in the prototype would absorb the unused named parameters? DC> Yes, I've been rethinking that in light of my immediately previous posting DC> about C. DC> I suspect that this constraint should only be applied under use strict, DC> or better yet under the influence of a 'strict_args' subroutine attribute. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, and wantarray() changes
>>>>> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
GB> On Fri, Aug 18, 2000 at 12:25:42AM -0400, Chaim Frenkel wrote:
>> As Graham pointed out, is an lvalue sub supposed to act like a tie or
>> like a variable.
GB> Both.
GB> As Damian points out the lvalue sub must return something that can
GB> be used as an lvalue. Normal assignment hen happens.
GB> So the result will be the same as assigning to a variable, if that
GB> variable is tied it can change the resutl value of the assign.
I think we agree.
$foo is a tied variable
$bar is a normal variable
sub zap : lvalue { return $_[0] ? $foo : $bar }
zap(1) = 5; # Goes to tied variable
zap(0) = 5; # Normal store
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 128 (v1) Subroutines: Extend subroutine contexts to include name parameters and lazy arguments
>>>>> "DC" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: DC> * Label an argument such that there is no corresponding named DC> parameter. Could this be eased slightly? How about a %rest hash, if supplied in the prototype would absorb the unused named parameters? DC> =head1 IMPLEMENTATION DC> Definitely S.E.P. What does that mean? -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, and wantarray() changes
Then assignment is the gatekeeper? But what information will the lvalue sub have for deciding what to make lvaluable? >>>>> "DC" == Damian Conway <[EMAIL PROTECTED]> writes: DC> And I keep pointing out that this is only one aspect of lvalue subroutines. DC> The point of an lvalue subroutine is not to make assignment to the return value DC> work, it is to make the return value an *lvalue*. That's a much more general DC> thing, because it allows every other type of modification to work too. DC> The lvalue accessor *shouldn't* be doing the assignment (what if an assignment DC> isn't what I want?). DC> The (overloaded) operator = should do the assignment. To whatever lvalue DC> the lvalue subroutine returns. DC> Or the "assignment" should be done by operator += or operator++ or DC> whatever mutator I'm actually applying to the returned lvalue. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, and wantarray() changes
As Graham pointed out, is an lvalue sub supposed to act like a tie or
like a variable.
If it acts like a variable it can't be a gatekeeper.
Hmm, what if the sub gets a chance to look at the value before acting.
Checks the value. If good returns a reference to the correct variable
to save it in.
If it needs to twiddle some frobs, does the frobing and then returns
undef to tell perl to pass on the original value as the value of
the assignment. Otherwise, the value returned (possibly a dummy
variable) is passed on as the value.
What about += That's a double access...
Oh, well, perhaps thinkging of it as a tie would be better.
>>>>> "JV" == Johan Vromans <[EMAIL PROTECTED]> writes:
JV> However, if an lvalue sub is an lvalue, it must be an lvalue in _all_
JV> respects.
JV> $cgi->param($var) = ...
JV> $cgi->param($var) += ...
JV> $cgi->param($var) =~ s///
JV> for ( $cgi->param($var) ) {
JV> $_ = ...
JV> }
JV> sysread($fh,$cgi->param($var),...)
JV> and so on.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, and wantarray() changes
During -internals discussions, we seem to have come up with, that the flattenting will not be required by the implementation. (It might actually be a win.) All arrays/lists would be actually have a single reference on the data stack. For backwards compatiblity, @_ would iterate of all arguments. But if a perl user level mechanism were made available then a routine that wishes to access the original unadulterated arguments would have it available. >>>>> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: PRL> Subroutines may be called with multiple values. Lvalue subroutines PRL> may be assigned multiple values. Simple passing on the argument PRL> list conflates the two: PRL> foo(@args) = @rvalues; PRL> would be identical to: PRL> foo(@args, @rvalues); PRL> Perl's list flattening would prevent the subroutine from knowing where PRL> one began and the other ended. Better would be if the rvalue were PRL> passed as a last or first argument, making it equivalent to: -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 97 (v1) prototype-based method overloading
>>>>> "EH" == Evan Howarth <[EMAIL PROTECTED]> writes: EH> Chaim Frenkel <[EMAIL PROTECTED]> writes: >> Why would anyone want to select a different method based upon the >> arguments. EH> The classic example is event dispatch. Say a generic event EH> handler knows how to handle an event base class. It dispatches EH> handling to some class that registered interest in the events. EH> Somewhere the code has to select the right event handler per EH> event type. Having "multimethod" support simplifies such code: EH> It reduces to method declarations. Without it, each registered EH> class needs to include the code to determine which event EH> occurred and where its handler is found. Sounds like action at a distance. And this would be done at compile time (for a language like C++), no? EH> Another example is the exception catching being discussed on EH> perl6-language-flow. An IO exception contains different data EH> and is handled differently than a out-of-memory exception. EH> Without multimethod support, the flow people are arguing EH> syntax and ways to distinguish among the many exception types EH> so that the correct handler code is invoked. That still doesn't seem to by why I should hide it in the signature. EH> Although not as common a need as polymorphism, multimethod EH> support would be useful. I'll wait and see. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 97 (v1) prototype-based method overloading
>>>>> "PC" == Piers Cawley <[EMAIL PROTECTED]> writes: PC> Chaim Frenkel <[EMAIL PROTECTED]> writes: >> Why would anyone want to select a different method based upon the >> arguments. PC> Have you seen Class::Multimethods? This kind of despatch can be very PC> useful. Of course, the existence of Class::Multimethods proves that it PC> can be done already so there may be no need to put it in the core. You answered the HOW, not the WHY. The question for the audience is WHY, I would want to do this. (As a counterpoint. Dr. Myers argues very strongly against this.) -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 98 (v1) context-based method overloading
And what will aSub decide is it's context? @foo = (1, 2, 3, aSub) If I have to write scalar(aSub) then I see no point in this RFC. And why shouldn't the caller decide? What is the gain in having perl do the dirty work. >>>>> "ABH" == Ask Bjoern Hansen <[EMAIL PROTECTED]> writes: >> =head1 ABSTRACT >> >> The other way C++ allows you to overload a named function is >> by return type. This document is a companion piece to >> a similarly named one about protoypes. It replaces old Perl's >> "wantscalar" and "wantarray" kluges, which can now be deprecated, >> with a cleaner interface allowing decisions which are possible to >> make at compile time to be made then. >> >> =head1 DESCRIPTION >> >> Defining multiple subroutines with both the same name and the same calling >> interface that explicitly return items of differing types is now >> allowed. subject to the following: >> >> =over >> >> =item compile-time >> >> the return-type expectation of all method calls meaning to take advantage >> of this feature must be clear from explicit type tags available at compile time. >> >> =item what constitutes a context? >> >> We are familiar with "scalar context" and "array context" from perl5 and >> previous. Perl6 gives us user-defined contexts as well as user defined >> types or all sorts. Any unique string can be a context, for the purposes >> of context-based method overloading, and Perl will attempt to guess a >> reasonable base class for the given "context." Use of undeclared context >> specifiers will of course generate warnings. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 97 (v1) prototype-based method overloading
>>>>> "ABH" == Ask Bjoern Hansen <[EMAIL PROTECTED]> writes:
>> =head1 ABSTRACT
>>
>> When I read the chapter on OO in the second edition camel book I
>> was saddened that C++ style method overloading was not explicitly
>> described. Ever hopeful, I wrote some quick code that I hoped would
>> do what I meant and discovered that it didn't. This document is
>> an attempt to remedy the situation.
>>
>> =head1 SUMMARY
>>
>> $frog_t = qs(frog);
>> sub listargs($){ print "One arg, $_[0]"}
>> sub listargs($$){ print "Two args, $_[0] and $[1]"}
>> sub listargs($$frog_t){ print "$_[0] and a frog $[1]"}
>> sub listargs { throw argsyntax, "odd arguments to listargs" }
Please do not do this.
It is a mess.
Action at a distance.
There are otherways to solve the same problem.
Why would anyone want to select a different method based upon the arguments.
The calling routine can easily dispatch differently.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 57 (v1) Subroutine prototypes and parameters
>>>>> "DC" == Damian Conway <[EMAIL PROTECTED]> writes: DC> I'd be inclined to drop the prefixes: DC> bar(z: 30, t: (1, 2, 3)); And what if t were a scalar? Would it end up with 3 or 3? :-) -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 57 (v1) Subroutine prototypes and parameters
>>>>> "BL" == Bart Lateur <[EMAIL PROTECTED]> writes:
BL> p.s. Has anybody already proposed Lisp's delayed evaluation of argument
BL> expressions? We could create our own shortcut functions, then. :-)
Way back on p5p, a while ago
lazy
as in
grep { ... } lazy &foo, &bar, &zed
The opinion seemed to be going toward having the caller determine
laziness.
The alternative (or simultaneous capablity) was
sub foo :lazy () {}
It might be acceptable to have it as an attribute of the argument/parameter.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 57 (v1) Subroutine prototypes and parameters
Think about the possiblity that flattening shouldn't be the default.
So that to get the flattening effect one would have to specify it
(or use @_ which would do the work.)
So perhaps an attribute
sub bar ($first, @rest :rest) { ... }
Then an introspective sub may be able to infer what was actually
sent on the stack.
It may be an overall win, by not flattening. It may make the work
for -internals easier. I can see it helping Damian's lazy evaluation
proposal.
>>>>> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
PRL> Here are two more examples specifying a scalar followed by an
PRL> array/hash array to gobble up all remaining arguments.
PRL> sub bar ($first, @rest) {
PRL>... # my ($first, @rest) = @_;
PRL> }
PRL> sub baz ($first, %rest) {
PRL>... # my ($first, %rest) = @_;
PRL> }
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 31 (v1) Co-routines
Would you please explain the difference (if any) between co-routine generator closure (I vaguely recall, that a co-routine was a set of mutually invoking routines.) Actually, this seems more generic. This might be perfect for an iterator. As for language implications, what would you do with a yield within a map/grep (or future reduce), or is that an implementation detail? >>>>> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: PRL> =head1 TITLE PRL> Co-routines PRL> =head1 ABSTRACT PRL> This RFC proposes the addition of a new function return command: PRL> C. Unlike C, C preserves the execution state of PRL> the subroutine in which it's called, allowing the execution to be PRL> resumed at the following statement, next time the subroutine is called. PRL> It is also proposed that C may nest, to simplify the PRL> construction of recursive co-routines and iterators. PRL> =head1 BACKGROUND PRL> Normally, when a subroutine returns, its execution terminates PRL> and it final context is completely lost. The next time the subroutine PRL> is invoked, it recommences executing from its first statement. PRL> In a coroutine, a value may be returned in such a way that the PRL> execution of the routine is I, along with all its PRL> local context. The next time the routine in invoked, its execution PRL> resumes from the statement after the previous point of return. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
