Re: RFC 222 (v1) Interpolation of method calls

2000-09-15 Thread Bart Lateur

On Thu, 14 Sep 2000 18:37:22 -0500, David L. Nicol wrote:

   print "Today's weather will be ${weather-temp} degrees and sunny.";

which would follow the "You want something funny in your interpolated
scalar's name or reference, you put it in curlies" rule.

I too feel that an approach like this would be far more generically
useful than this "$weather-temp" special case. I have said it before, I
know, but calling a generic function, not a method call, happens more to
me than this object access.

print "You have to pay " . money($amount) ." dollars.";

But sacrificing the ${...} syntax doesn't feel right. Indeed, it *does*
execute the code in curlies, but it expects a scalar reference.

MJD has a "silly module" which can tie a hash to a function:
Interpolation.pm. I think I would like a special case, a specific hash
that is *always* tied to a function that returns the arguments. Make it,
for example, %$, %@ or %?. These are not in use now, are they?

print "You have to pay $?{money($amount)} dollars.";


Implementation in Perl 5:

tie %?, Hash::Eval;
sub money {
return sprintf '%4.2f', shift;
}
print "You owe me $?{money(12)} dollars.\n";

package Hash::Eval;
sub TIEHASH {
my $self = shift;
return bless {}, ref $self || $self;
}
sub FETCH {
my $self = shift;
return "@_";
}

-- 
Bart.



Re: RFC 222 (v1) Interpolation of method calls

2000-09-15 Thread Michael G Schwern

On Thu, Sep 14, 2000 at 05:31:44PM -0500, David L. Nicol wrote:
 A possibility that does not appear in RFC222.1 is to put tho whole
 accessor expression inside curlies:
 
   print "Today's weather will be ${weather-temp} degrees and sunny.";
 
 which would follow the "You want something funny in your interpolated
 scalar's name or reference, you put it in curlies" rule.  Since the contents
 of that expression is not strictly \w+ it does not get interpreted as
 the symbol table lookup ${'weather-temp'}, so that is not a problem, nor
 are the whitespace situations listed in the CAVEATS section.

Could you write up some practical examples where this might be useful
(slapping whitespace between the - and method name isn't practical or
useful).  I'm loathe to muddle the meaning of ${bareword}.

It did make me think of something else.  What about by-variable method
calls.  That is:

my $meth = 'species';
print "How much is that $pet-$meth() in the window?";

This should deparse to:

my $meth = 'species';
print "How much is that ".$pet-$meth()." in the window?";


-- 

Michael G Schwern  http://www.pobox.com/~schwern/  [EMAIL PROTECTED]
Just Another Stupid Consultant  Perl6 Kwalitee Ashuranse
I'm not cute, I'm evil.
-- Diablo  www.goats.com



Re: RFC 222 (v1) Interpolation of method calls

2000-09-15 Thread Michael Fowler

On Fri, Sep 15, 2000 at 10:58:26AM +0200, Bart Lateur wrote:
 MJD has a "silly module" which can tie a hash to a function:
 Interpolation.pm. I think I would like a special case, a specific hash
 that is *always* tied to a function that returns the arguments. Make it,
 for example, %$, %@ or %?. These are not in use now, are they?
 
   print "You have to pay $?{money($amount)} dollars.";

I always thought MJD's module was neat, but never had a real desire for
interpolated function calls.  If it was part of the core library I may be
inclined to use it more, but I doubt it.

Or maybe an alternative, using :

"foo foo(arg, arg, arg) bar"
"foo { foo(arg, arg, arg) } bar"

I suspect this has already been discussed and discarded at some point; I
sincerely doubt I'm the only one who came up with it.

Or maybe we need a more generic solution (as someone else suggested, I
forget who).  Something that allows the arbitrary execution of code, much
like @{[ ]}, but cleaner.  Unfortunately, I can't think of anything
suitable.


Whatever direction this discussion takes, I don't think it should impact the
interpolation of method calls.  It'd be nice to find a clean and simple
syntax for calling functions within double-quoted strings, but it's already
clean and simple to call methods.


Michael
--
Administrator  www.shoebox.net
Programmer, System Administrator   www.gallanttech.com
--



Re: RFC 222 (v1) Interpolation of method calls

2000-09-15 Thread Bart Lateur

On Fri, 15 Sep 2000 01:36:50 -0800, Michael Fowler wrote:

Or maybe an alternative, using :

"foo foo(arg, arg, arg) bar"
"foo { foo(arg, arg, arg) } bar"

Ah, yes, {...}, I kinda like that. Unfortunately, in regexes, /{1,3}/
means matching 1 to three ampersands. There's a slight compatibility
problem, there.

Or maybe we need a more generic solution (as someone else suggested, I
forget who).  Something that allows the arbitrary execution of code, much
like @{[ ]}, but cleaner.

I did, for one, including in the post you just replied to. That's what
the tied hash solution tried to emulate. Wasn't that obvious?  ;-) 

Unfortunately, I can't think of anything suitable.

Well, you said it yourself: "{...}".

-- 
Bart.



Re: RFC 222 (v1) Interpolation of method calls

2000-09-15 Thread David L. Nicol

Michael Fowler wrote:

 Or maybe we need a more generic solution (as someone else suggested, I
 forget who).  Something that allows the arbitrary execution of code, much
 like @{[ ]}, but cleaner.  Unfortunately, I can't think of anything
 suitable.
 
 Whatever direction this discussion takes, I don't think it should impact the
 interpolation of method calls.  It'd be nice to find a clean and simple
 syntax for calling functions within double-quoted strings, but it's already
 clean and simple to call methods.
 
 Michael

First, thanks for pointing out that ${something-something2} already
has a meaning.

Second, I think @{[ ... ]} is a plenty clean way to interpolate
absolutely anything.  with tieing, we can get method calls to look
like hash lookups can we not, so why not do that if your method is
supposed to support interpolation?

"the result of f($arg) is $mytiedfunction{$arg}"

Maybe some syntax that is more direct than Ctie to allow such things
would do the trick?

Or MJD's module, does it allow this:

tie %myfunction, THAT_MODULE, {some function which will be stuck into the 
FETCH method}


-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
   perl -e'map{sleep print$w[rand@w]}@w=' ~/nsmail/Inbox



Re: RFC - Interpolation of method calls

2000-09-15 Thread David L. Nicol


 The only decision, then, is to decide which context to use; if it deparses
 to concatenation then it seems logical to use scalar context.  This also
 makes sense in that you can force list context with @{[ $weather-temp ]} if
 you really wanted it.

$ perl -le 'sub w{wantarray?"WA":"WS"};print " attempt: ${\scalar(w)}"'
 attempt: WS


Maybe we just need a shorter synonym for Cscalar?



Re: RFC - Interpolation of method calls

2000-09-15 Thread Michael Fowler

On Fri, Sep 15, 2000 at 07:24:39PM -0500, David L. Nicol wrote:
  The only decision, then, is to decide which context to use; if it
  deparses to concatenation then it seems logical to use scalar context. 
  This also makes sense in that you can force list context with @{[
  $weather-temp ]} if you really wanted it.
 
 $ perl -le 'sub w{wantarray?"WA":"WS"};print " attempt: ${\scalar(w)}"'
  attempt: WS
 
 Maybe we just need a shorter synonym for Cscalar?

Or DWIM "${\foo()}" to force scalar context.  Everytime I come across that
construct I have to wonder why it's not called in scalar context.  The '$'
would seem to imply it should.

Or cause the foo() method in "foo $foo-bar bar" to be called in scalar
context by default, obviating the need for a specific scalar call.

I'd actually like both solutions to be implemented.


What's even more confusing:

sub foo { wantarray ? "list" : "scalar" }

print scalar("${\foo()}")   -- "list"
print scalar(${\foo()}) -- "list"
$foo = ${\foo()}; print $foo-- "list"

And yet:

sub foo { wantarray ? \"list" : \"scalar" }

print ${foo()}  -- "scalar"
print ${ ("bar", foo()) }   -- "scalar"

(These were all tested using 5.6.0.)

I have to assume \foo() is actually \(foo()) or some such.  IMHO, this is
entirely non-intuitive.  Can anyone enlighten me as to why this is as it is?
I believe there was a p5p discussion about this, but I dread delving into
the archives again..


Michael
--
Administrator  www.shoebox.net
Programmer, System Administrator   www.gallanttech.com
--