Currying questions (take 2)
Ralph Mellor
Thankyou Damian and Allison for S6.
Larry has previously noted that assumptions should
probably be a binding rather than a value assignment:
$text = "fooo"; print $textfrom(1); # displays 'ooo'
$text = "bahh"; print $textfrom(1); # displays 'ahh'
Is that the final call on this? Or is it controllable:
(use IO::Logging).assuming(logfile=>$file); # copied
(use IO::Logging).assuming(logfile:=>$file); # bound
Or perhaps copied for sub level assumptions and bound
for file level assumptions?
Can one override an assumption by passing the relevant
argument in an actual call (by name, obviously)? (Being
able to do such an override would be pretty pointless
for routine level currying but potentially very handy
in the context of file level currying.) If not, does one
get an error message if one supplies such an argument
to a routine that has a slurpy hash?
File level assumptions will be thread local, right?
--
ralph
Luke Palmer
>
> Thankyou Damian and Allison for S6.
I thank you to. S6 is rather easier to digest than A6 (which was the
point, so, uh, good).
> Larry has previously noted that assumptions should
> probably be a binding rather than a value assignment:
>
> $text = "fooo"; print $textfrom(1); # displays 'ooo'
> $text = "bahh"; print $textfrom(1); # displays 'ahh'
I think it should. In general, [constant]? binding should be used
unless you want it to actually copy the value. And very few
language-level features should do copying (because you might specify
that there's no copy routine).
> Is that the final call on this? Or is it controllable:
>
> (use IO::Logging).assuming(logfile=>$file); # copied
> (use IO::Logging).assuming(logfile:=>$file); # bound
:=> ... there's a new smily. I don't think that should be an
operator. If you want copying, copy it yourself:
{
my $tempfile = $file;
(use IO::Logging).assuming(logfile => $tempfile);
}
(Is that (use Foo).assuming(...) syntax real?)
Which is another good argument for using binding, because you couldn't
emulate binding with copying. (Well, you could, but it would involve
another level of indirection)
> Can one override an assumption by passing the relevant
> argument in an actual call (by name, obviously)? (Being
> able to do such an override would be pretty pointless
> for routine level currying but potentially very handy
> in the context of file level currying.) If not, does one
> get an error message if one supplies such an argument
> to a routine that has a slurpy hash?
I don't think that should be allowed. It should be the precise same
semantic as:
sub foo($bar) {...}
foo(bar => 10, bar => 20);
It would indeed be handy to be able to override file level
assumptions. Maybe the
(use IO::Logging).assuming(...)
syntax is wrong. Perhaps this is in order:
use IO::Logging;
package MyLog ::= IO::Logging.assuming(...)
Although I don't know enough about what file level currying is
supposed to do.
> File level assumptions will be thread local, right?
Who knows, at this point. A17 :=>
Luke
Paul
> >
> > (use IO::Logging).assuming(logfile=>$file); # copied
> > (use IO::Logging).assuming(logfile:=>$file); # bound
>
> :=> ... there's a new smily. I don't think that should be an
> operator. If you want copying, copy it yourself:
>
> {
> my $tempfile = $file;
> (use IO::Logging).assuming(logfile => $tempfile);
> }
Wouldn't the use() go out of scope along with the my()?
> > Can one override an assumption by passing the relevant
> > argument in an actual call (by name, obviously)? (Being
> > able to do such an override would be pretty pointless
> > for routine level currying but potentially very handy
> > in the context of file level currying.) If not, does one
> > get an error message if one supplies such an argument
> > to a routine that has a slurpy hash?
>
> I don't think that should be allowed. It should be the precise same
> semantic as:
>
> sub foo($bar) {...}
> foo(bar => 10, bar => 20);
>
> It would indeed be handy to be able to override file level
> assumptions. Maybe the
>
> (use IO::Logging).assuming(...)
>
> syntax is wrong. Perhaps this is in order:
>
> use IO::Logging;
> package MyLog ::= IO::Logging.assuming(...)
>
> Although I don't know enough about what file level currying is
> supposed to do.
Maybe we need an "is override"? (I'm JOKING! :)
Though the concept is useful, if someone could figure a way to do it.
Hell, maybe I'm not entirely joking. I kinda doubt it's worth another
keyword, but then, that's not my call to make, is it? :) I just toss
out ideas, lol...
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
Austin Hastings
--- Luke Palmer <fibo...@babylonia.flatirons.org> wrote:
> > [Sorry about pipe symbol junk in my last post. Mozilla, mumble...]
> >
> > Thankyou Damian and Allison for S6.
Can someone point me at S6 -- I can't seem to find it on perl.org.
(For that matter, A6 doesn't seem to be there, either. Luckily I saved
it locally, but still: what gives?)
=Austin
gre...@focusresearch.com
A6: http://www.perl.com/pub/a/2003/03/07/apocalypse6.html
S6: http://www.perl.com/pub/a/2003/04/09/synopsis.html
Regards,
-- Gregor Purdy
Austin Hastings <austin_...@yahoo.com>
04/11/2003 11:44 AM
Please respond to Austin_Hastings
To: perl6-l...@perl.org
cc:
Subject: Re: Currying questions (take 2)
Paul
> Can someone point me at S6 -- I can't seem to find it on perl.org.
> (For that matter, A6 doesn't seem to be there, either. Luckily I
> saved it locally, but still: what gives?)
lol -- I had the same problem. Look at http://www.perl.com/ where it's
the big green thing at the top of the page, and A6 is a little further
down. :)
Will Coleda
>
> --- Luke Palmer <fibo...@babylonia.flatirons.org> wrote:
> > > [Sorry about pipe symbol junk in my last post. Mozilla, mumble...]
> > >
> > > Thankyou Damian and Allison for S6.
>
>
> Can someone point me at S6 -- I can't seem to find it on perl.org.
>
> (For that matter, A6 doesn't seem to be there, either. Luckily I saved
> it locally, but still: what gives?)
>
> =Austin
>
---------------------------------------------
This message was sent using Road Runner's Web-based
e-mail.
Me
I'd like to see rw binding for file level assumptions.
(Rationale later.)
> (Is that (use Foo).assuming(...) syntax real?)
It's from S6.
> > Can one override an assumption by passing the relevant
> > argument in an actual call (by name, obviously)?
> ...
> It would indeed be handy to be able to override file level
> assumptions. ... Perhaps this is in order:
>
> use IO::Logging;
> package MyLog ::= IO::Logging.assuming(...)
Maybe. This would allow one to accept all the assumptions
or none of them. Any state kept by one 'use' would not be
shared with any other use(s).
> Although I don't know enough about what file level
> currying is supposed to do.
If you mean implementation details, I'm in the same boat.
If you mean their raison d'etre, then the two main uses
I'm interested in are as evil avoidance alternates for
globals and for $CALLER::foo black magic.
--
ralph
Damian Conway
> Thankyou Damian and Allison for S6.
You're most welcome. :-)
> Larry has previously noted that assumptions should
> probably be a binding rather than a value assignment:
>
> $text = "fooo"; print $textfrom(1); # displays 'ooo'
> $text = "bahh"; print $textfrom(1); # displays 'ahh'
>
> Is that the final call on this?
Anything Larry says is the final call on anything Perl-related.
For this week, at least ;-)
Or is it controllable:
No. It's always by binding, but if you want it by copy then bind a copy:
(use IO::Logging).assuming(logfile=>"$file");
> (use IO::Logging).assuming(logfile=>$file); # copied
> (use IO::Logging).assuming(logfile:=>$file); # bound
Not unless your scope has previously monkeyed with the parser somehow.
Perl 6 doesn't have a :=> operator (nor a postfix colon).
> Or perhaps copied for sub level assumptions and bound
> for file level assumptions?
I doubt it.
> Can one override an assumption by passing the relevant
> argument in an actual call (by name, obviously)?
Kinda. You'd have to call the original subroutine from the original module
(rather than the one that the assumptive C<use> imported to the current
package). That is:
# Called imported, assumptions adhered to...
log_me(text=>"oh baby oh baby"); # logfile already bound to $file
# Call original, no assumption...
IO::Logging::log_me(text=>"oh baby oh baby", logfile=>$other);
> (Being
> able to do such an override would be pretty pointless
> for routine level currying but potentially very handy
> in the context of file level currying.) If not, does one
> get an error message if one supplies such an argument
> to a routine that has a slurpy hash?
Presumably, since it's illegal to pass two named args of the same name, and
that would be effectively what you were doing.
> File level assumptions will be thread local, right?
No idea. We haven't gotten to threads yet. :-)
Damian
Brent Dax
# Kinda. You'd have to call the original subroutine from the
# original module
# (rather than the one that the assumptive C<use> imported to
# the current
# package). That is:
#
# # Called imported, assumptions adhered to...
# log_me(text=>"oh baby oh baby"); # logfile already
# bound to $file
#
# # Call original, no assumption...
# IO::Logging::log_me(text=>"oh baby oh baby", logfile=>$other);
How does this bind things to methods, where nothing's being imported?
Oh, and a general question about .assuming:
sub x($foo, $bar) { ... }
&y := &x.assuming(foo => 1);
y(3, foo => 2); #OK?
In other words, does .assuming a parameter delete it completely from the
parameter list, or does it just move it to the named zone and give it an
appropriate default? (The use of the phrase 'assuming' makes me think
of it being an overridable assumption, for some reason...)
--Brent Dax <bren...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
>How do you "test" this 'God' to "prove" it is who it says it is?
"If you're God, you know exactly what it would take to convince me. Do
that."
--Marc Fleury on alt.atheism
Damian Conway
> # IO::Logging::log_me(text=>"oh baby oh baby", logfile=>$other);
>
> How does this bind things to methods, where nothing's being imported?
It doesn't. The question was: "can I *call* an imported sub but pass the
assumed argument explicitly". That's what the above example is doing.
>
> Oh, and a general question about .assuming:
>
> sub x($foo, $bar) { ... }
> &y := &x.assuming(foo => 1);
> y(3, foo => 2); #OK?
No. Definitely an error. That's exactly what the previous question was asking.
> In other words, does .assuming a parameter delete it completely from the
> parameter list, or does it just move it to the named zone and give it an
> appropriate default? (The use of the phrase 'assuming' makes me think
> of it being an overridable assumption, for some reason...)
I would prefer to see it delete the parameter from the parameter list, but
retain enough knowledge so that it can generate smarter error messages. Namely:
Cannot pass argument to parameter ($foo) that has already been assumed
rather than:
No such parameter ($foo)
Damian
Luke Palmer
>
>
> > Thankyou Damian and Allison for S6.
>
> You're most welcome. :-)
>
>
> > Larry has previously noted that assumptions should
> > probably be a binding rather than a value assignment:
> >
> > $text = "fooo"; print $textfrom(1); # displays 'ooo'
> > $text = "bahh"; print $textfrom(1); # displays 'ahh'
> >
> > Is that the final call on this?
>
> Anything Larry says is the final call on anything Perl-related.
> For this week, at least ;-)
>
>
> Or is it controllable:
>
> No. It's always by binding, but if you want it by copy then bind a copy:
>
> (use IO::Logging).assuming(logfile=>"$file");
That syntax just bothers me. I would like it better as an adverb call
on C<use>:
use IO::Logging where assuming(logfile => "$file");
(And I like C<where> better as an adverb specifier than : ).
Really, if .assuming on subs returns a new sub, why would .assuming on
modules have side-effects? Another possibility could be:
use IO::Logging.assuming(logfile => "$file);
Which would seem to make more sense (using the modified module, not
modifying the used one, because .assuming shouldn't have
side-effects).
Luke