Re: Stringification, numification, and booleanification of pairs
Juerd wrote: I think separating stringification and interpolation leads to unpredictability, and is a very bad thing. I disagree. I think it's likely that people will think of ~$val and +$val the same way (i.e. as coerce the value), but that they will think of $val quite differently (i.e. as interpolate a useful string representation of the entire value). More importantly, as we have already seen with regexes, inconsistent numerification and stringification is an even more serious problem. Damian
Re: Stringification, numification, and booleanification of pairs
Damian Conway skribis 2005-09-22 23:04 (+1000):
I disagree. I think it's likely that people will think of ~$val and +$val
the same way (i.e. as coerce the value), but that they will think of
$val quite differently (i.e. as interpolate a useful string
representation of the entire value).
But will they also see foo ~ $bar as something different from
foo$bar? And what context does foo{ $bar } use?
In my opinion, making the string value in interpolation different from
the value in Str context is madness.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Stringification, numification, and booleanification of pairs
On Thu, Sep 22, 2005 at 11:59:32AM -0400, Matt Fowles wrote:
Well said! I completely agree that string interpolation should be
handled exactly the same as stringification. I would like C (foo is
$foo of course) eq (foo is ~ $foo ~ of course) at all times.
Yes.
S03 states:
Unary ~ now imposes a string context on its argument, and + imposes a
numeric context (as opposed to being a no-op in Perl 5). Along the
same lines, ? imposes a boolean context, and * imposes a list context.
That seems to indicate that ~$foo eq $foo.
If however, you want $foo to interpolate to something else, you can do
that in several ways:
hello { +$foo }
hello { $foo.as(...) }
Or when concatenating:
~ +$foo ~
~ $foo.as(...) ~
-kolibrie
Re: skippable arguments in for loops
I'm not sure we've reached consensus here, so I will try to summarize what everyone said so far in order to clear my own head a bit. :) Sorry in advance if i horribly misrepresent anyone's opinions. Luke: Thinks the _ syntax is no joke, since every language with pattern matching abilities has it. Further, using undef won't work because it means this has to be undef in signature unification. Dks: Replies to Luke. Thinks that undef is more perl5ish, and that _ can disappear too easily, and is too Huffmanized. Doesn't think _ is obvious, but is sure we will end up using it if this feature is added. TSa: Prefers to rely on lazy evaluation, and says both tounge-in-cheek and philosophically that if I don't want to care about some elements, I should do so, and let Perl6 optimize. Proposes several ways of not giving a name to a variable. Yuval Kogman: Replies to David. Seems to repeat Luke's point about value binding in signatures. Shows an example of value binding in action. Argues for the _ or __ syntax. Thinks that making this feature easy encourages reuse of calling code, not only callee code. So, in summary, it's not obvious that this feature is needed at all because things can be optimized away. Also, neither the undef nor the _ syntax have 100% support, and undef seems to have problems related to signature unification. Hm. For the time being I will assume that this functionality is not sufficiently wanted to deserve its own syntax. But I must admit I'm actually starting to like _ in subroutine signatures... not sure if it works well with positionals and the like, however. // Carl
Re: Stringification, numification, and booleanification of pairs
HaloO Juerd,
you wrote:
Damian Conway skribis 2005-09-22 23:04 (+1000):
I disagree. I think it's likely that people will think of ~$val and +$val
the same way (i.e. as coerce the value), but that they will think of
$val quite differently (i.e. as interpolate a useful string
representation of the entire value).
Aha, that to me implies three things
1) the circumfix operator has an arity = 1 with the not yet
interpolated string beeing the only non-invocant parameter
(that is somewhat untrue because the string is sliced into
a list of strings of the stuff between the variable data
interleaved with links to the enteties what replaces it
---in other words there is a parser macro that converts ...
to a call of a printf like multi dispatched on all the variables
and code literals mentioned in the string)
2) The arity 1 part is dispatched according to SMD/MMD in effect
at the call site or according to the definition the compiler
knows about when compiling it. Question: which is it?
3) there's an arity == 1..Inf catch-all implementation that (eagerly?)
iterates the incoming arglist and invokes the stringification
prefix op ~ on them---these are of course dispatched as well
If that does not give enough rope the users have to switch from
operator to output formatters or whatever.
But will they also see foo ~ $bar as something different from
I might *not* be representative but nonetheless I try to explain what
I perceive. Sorry, if that is intimidating this list. And please tell
me if that is the case---thanks.
That beeing said here I come:
We have: foo ~ $bar
I see: a juxtaposition of two operators and an item,
all three separated by whitespace
At that point I start to wonder: What do I know about these three things?
And I guess the compiler does the same ;)
foo$bar? And what context does foo{ $bar } use?
We have: foo$bar
I see: a single invocation of operator with a string and an item.
(In other words, a parametric string!)
In my opinion, making the string value in interpolation different from
the value in Str context is madness.
I would call it late binding!
The decision what difference it makes is deferred :)
But I agree that the catch-all case from 3) above should
result in whatever you mean with the value in Str context.
Actually, the outcome then still depends on what is bound lately
to the implicit, dispatched calls of prefix ~ and again I agree
that the default behaviour shouldn't have any surprises in store.
Or in yet another way: all the MTOWTDIs should yield the same
result unless the hooks on particular ways are bound to something
non-standard.
If you feel at unease with these multiple levels of lately bound
uncertainties when you write your code, then just put in more
type constraints. Unfortunately the enforcement level of such
contraints seems to be bound lately as well---and that puts me
at unease *before* I have even started writing Perl6 code =8)
slighty off-topic
What could $someone.sees($helicopter) mean?
Think e.g.
$someone := 'vietnamese child in the sixties';
$someone := 'insured person waiting for the rescue team';
$someone := 'paraglider flying high in the air';
$someone := your_pick();
Questions I pose myself while flying in
my TSa $helicopter;
through spacetime are for example:
Does the vietnamese child expect medical help?
How does the rescue team arrive? By car?
What sex does the paraglider have?
What type of action does the .sees method do
with my $helicopter, when invoked
on the return type of your_pick?
Should I be carefull and allow only read access to my $helicopter?
What $word.does(German) yields a %dictionarysees lookup where
:key.does(English)?
/slightly off-topic
--
$TSa.greeting := HaloO; # mind the echo!
Re: Stringification, numification, and booleanification of pairs
TSa skribis 2005-09-23 15:42 (+0200):
1) the circumfix operator has an arity = 1
I think it's parsed, not having specific arity.
We have: foo ~ $bar
I see: a juxtaposition of two operators and an item,
all three separated by whitespace
I can only hope you mean two items and one operator.
At that point I start to wonder: What do I know about these three things?
foo$bar? And what context does foo{ $bar } use?
We have: foo$bar
I see: a single invocation of operator with a string and an item.
I see a shorter way to write foo ~ $bar, as implemented by the
circumfix operator.
$TSa.greeting := HaloO; # mind the echo!
echo off
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: skippable arguments in for loops
HaloO Carl, you wrote: TSa: Prefers to rely on lazy evaluation, and says both tounge-in-cheek and philosophically that if I don't want to care about some elements, I should do so, and let Perl6 optimize. Proposes several ways of not giving a name to a variable. This hits home. And I did at no point impute carelessness on your part ---unless of course if you don't want to, err? ... care! Sorry, couldn't resist ;) Hm. For the time being I will assume that this functionality is not sufficiently wanted to deserve its own syntax. But I must admit I'm actually starting to like _ in subroutine signatures... not sure if it works well with positionals and the like, however. And could easily give a type markup with sigils and get $_, _, @_ and %_ ignored. I here $Yoda speak funny that is :) -- $TSa.greeting := HaloO; # mind the echo!
Re: Stringification, numification, and booleanification of pairs
On 2005-09-23 06:08, Juerd [EMAIL PROTECTED] wrote: In my opinion, making the string value in interpolation different from the value in Str context is madness. Hear, hear! I agree 100%. This is another place where we should move the Rubyometer down rather than up, I think (to_s vs. to_str, anybody?).
Re: Stringification, numification, and booleanification of pairs
TSa skribis 2005-09-23 19:11 (+0200):
We have: foo ~ $bar
I see: a juxtaposition of two operators and an item,
all three separated by whitespace
I can only hope you mean two items and one operator.
So, at last there is hope somewhere. But I fear I'm hopelessly
drowned in my own misconceptions and really meant two ops and an
item. But I hope---ahh hope again---that the optimizer boils down
the foo invocation to 'foo' at compile time. Which immediately
raises the question whether I consider ' ' as an operator or not :)
Ah, the operator. But still, foo as a whole is an item too. (The
entire expression is too, but I'm not considering that, for simplicity)
OTOH, I think we agree that a foo $bar is parametric with respect
to $bar and as such requires some code to evaluate it? The same applies
to matches /foo.*/ which are backed by some code that is build from
the text between the //. And how is this creation process of a match
closure parameterizable other then giving the resulting code a parameter
from which a new closure is created at runtime? And why is this not the
case for string interpolation? To a certain extent I see these two
closure manipulations as inverse operations. Interpolation creates
strings while matching analyzes them. But they don't guarranty mutual
round-trip invariance.
I have a hard time parsing this. Are you suggesting that interpolation
is somehow translated to a sub call like i(foo , $bar)?
Just ranting again a bit of my difficulties of integrating junctions
into my mental picture. How many times do you expect foo and ~ in
{foo} ~ $bar
beeing called? Consider ($bar = 42) versus ($bar = any(1,2,3)).
Once. The foo is not part of the junction, so it is not changing in
different iterations of autothreading.
Consider:
sub foo { @_.join(:) }
my $bar = 2;
my $baz = foo($bar *= 2, 1|2|3);
say $bar;
The foo call line evaluates to:
my $baz = foo(4, 1) | foo(4, 2) | foo(4, 3);
# Except that the 4 is really $bar, the lvalue return value of *=
not to:
my $baz = foo($bar *= 2, 1) | foo($bar *= 2, 2) | foo($bar *= 2, 3);
So eventually, 4 is said, not 16, and there is no question of which
$bar *= 2 is evaluated first.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
