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 %dictionary<sees> lookup where
:key.does(English)?
</slightly off-topic>
--
$TSa.greeting := "HaloO"; # mind the echo!
