new 'returns' keyword
David Storrs
Although if I squint really hard I can see how 'returns' applies here,
I do have to think about it, and it comes very close to conflicting
with 'return'. Is it too late to propose one of these keywords in its
place?
- holds
- contains
- gets
- stores
--Dks
Michael Lazzaro
I think it's mean to almost-conflict, because it's mainly used with
subs:
sub foo returns Dog {...}
... which looks pretty darn good. In practice, I think people will use
the synonym "of" almost exclusively in the var case, and not "returns":
my $spot of Dog;
Mmmmm... spot of Dog...
:-)
I suppose there could be another synonym. Dunno, I'm pretty happy with
it. I know people are proposing switching the types around in
declaration, but I like 'em fine, because there's so many alternatives.
my Dog $spot;
my $spot of Dog;
my $spot returns Dog;
my $spot is Scalar of Dog;
I like it because the language really does seem to build itself. You
can say things in lots of different ways, and they all just sorta work.
:-) Woo-hoo!
MikeL
Buddha Buck
>my $spot returns Dog;
>
>
>Although if I squint really hard I can see how 'returns' applies here,
>
"Don't do that then"
"returns" and "of" are synonymous, with the expectation that "returns"
will be used more with subs than with variables.
Does:
my $spot of Dog;
method Dog::whose_a_good_boy returns Dog { return $_; };
have any problems?
Both "returns" and "of" specify what you can expect to extract from the
variable/sub when you ask it for a value.
Me
> I know people are proposing switching the types around in
> declaration, but I like 'em fine, because there's so many
> alternatives.
The fact that there's several ways to write things that are
intuitive and logical is hardly a good defense for having
there be several ways to write things that are unnecessarily
counter intuitive and illogical!
> my Dog $spot;
> my $spot of Dog;
> my $spot returns Dog;
> my $spot is Scalar of Dog;
In the syntax I was proposing, those would be almost the
same:
my Scalar $spot;
my $spot of Dog;
my $spot returns Dog;
my $spot is Scalar of Dog;
> I like it because the language really does seem to build
> itself. You can say things in lots of different ways,
> and they all just sorta work.
> :-) Woo-hoo!
Then presumably you equally like the alternative I proposed?
--
ralph
Michael Lazzaro
> In the syntax I was proposing, those would be almost the
> same:
>
> my Scalar $spot;
> my $spot of Dog;
> my $spot returns Dog;
> my $spot is Scalar of Dog;
>
>
>> I like it because the language really does seem to build
>> itself. You can say things in lots of different ways,
>> and they all just sorta work.
>> :-) Woo-hoo!
>
> Then presumably you equally like the alternative I proposed?
I don't _dislike_ it -- I would be fine with it being either way.
But it is true that giving var implementation types like "Scalar" will
be very, very rare in practice, compared to giving value types like
"Dog" -- what, maybe less than 5% of all var declarations will probably
need to give an implementation type. So my own opinion is that, in
this case, brevity should win.
I will state that, speaking for myself, I don't expect to mix the two
styles very often, because of the potential for confusion. For
example, I'd frequently write either of:
my Dog $spot;
or
my $spot is Foo of Dog;
but I don't see myself writing
my Dog $spot is Foo;
thus mixing the put-it-before and put-it-after syntaxes, since that's a
tiny bit less clear than the other two. But I certainly might change
my mind on that, since it looks more clear every time I see it :-)
MikeL
Piers Cawley
Nope, I think it's vile and I wish to ghod you'd shut up about it.
--
Piers
Me
>
I'm in almost the same boat.
> [Huffman argument]
The syntax I proposed is /more/ Huffman encoded than the current
syntax. In addition to the many ways to say things that were in
the previous email there is also:
my $spot <traits> Dog = ...;
my $spot <traits> Dog;
my $spot Dog;
And providing an object variable with a type can use this:
my Dog $spot;
rather than the currently required:
my $spot is Dog;
But the above is almost beside the point. I'm looking to find out
if people even see the intuitive/logical aspects (especially for
newbies) behind keeping the variable type with the variable and
value type with the value. THEN we can get into discussion of
whether it is possible, how to try to ensure we have the same
or better Huffman etc. qualities as the current syntax, etc.
> I will state that, speaking for myself, I don't expect to mix the two
> styles very often, because of the potential for confusion. For
> example, I'd frequently write either of:
>
> my Dog $spot;
> or
> my $spot is Foo of Dog;
>
> but I don't see myself writing
>
> my Dog $spot is Foo;
One thing I've wondered is whether traits can/will be created
that combine a variable type with a value type. My expectation
was yes, and that these might well, in practice, turn out to
be pretty popular, perhaps being used more often than straight
value types alone. In the syntax I propose, they could appear
thusly:
my Dog $spot;
ie the exact same look, read and feel as existing examples,
and shorter than the currently required:
my $spot is Dog;
> thus mixing the put-it-before and put-it-after syntaxes, since that's
a
> tiny bit less clear than the other two. But I certainly might change
> my mind on that, since it looks more clear every time I see it :-)
The latter aspect is familiarity. I suspect that's a big part
of why there's more comfort than seems, er, seemly, with the
way it is now. (I can see it turning out that the current
syntax is the best choice, but I'm surprised at the lack of
engagement on taking a *serious* look at this issue. This
particular bit of syntax is going to be encountered by newbies
very early on, it deals with something that cries out for being
as simple as we can make it ("what, there's variable AND value
type systems?") and is going to be used a LOT by everyone.)
--
ralph
Luke Palmer
> > that's a tiny bit less clear than the other two. But I certainly
> > might change my mind on that, since it looks more clear every time
> > I see it :-)
>
> The latter aspect is familiarity. I suspect that's a big part of why
> there's more comfort than seems, er, seemly, with the way it is
> now. (I can see it turning out that the current syntax is the best
> choice, but I'm surprised at the lack of engagement on taking a
> *serious* look at this issue. This particular bit of syntax is going
> to be encountered by newbies very early on, it deals with something
> that cries out for being as simple as we can make it ("what, there's
> variable AND value type systems?") and is going to be used a LOT by
> everyone.)
I I<have> taken a serious look at it. And although I agree with you
main point, the things that I disagree with outweigh that (for me).
In the current way:
Student: "What, there's variable AND value type systems?"
Teacher: "Yes. You specify the variable type with the 'is' keyword,
putting it after the declaration. Any other type is a value type."
In the proposed way:
Student: "What, there's variable AND value type systems?"
Teacher: "Yes. You specify the variable type by either putting it
between the 'my' and the variable name, or after the the variable
name with 'is' in front. But if you don't put the 'is' in front, it's
a value type."
Don't tell me that's easier to learn. As it stands, if you forget the
'is', Perl croaks with a helpful syntax error.
But overall, I'm with Piers on this one. The design team has seen
your proposal (far too many times), and if they like it, they'll use
it. Let's sit back and let them decide.
Luke
Paul
--- Me <m...@self-reference.com> wrote:
> I couldn't resist hijacking this thread to a different end...
>
> > I know people are proposing switching the types around in
> > declaration, but I like 'em fine, because there's so many
> > alternatives.
>
> The fact that there's several ways to write things that are
> intuitive and logical is hardly a good defense for having
> there be several ways to write things that are unnecessarily
> counter intuitive and illogical!
I *strongly* disagree.
Do you suppose that your way of looking at things is the only logical
way? I doubt it -- you sound fairly reasonable.
Yet you say "there's several ways to write things that are intuitive
and logical". Don't discard existing syntax that you don't like from
the language -- just opt not to use it. Let's not be code police.
> > my Dog $spot;
> > my $spot of Dog;
> > my $spot returns Dog;
> > my $spot is Scalar of Dog;
>
> In the syntax I was proposing, those would be almost the
> same:
>
> my Scalar $spot;
> my $spot of Dog;
> my $spot returns Dog;
> my $spot is Scalar of Dog;
Then with so little difference, why force a rewrite?
Surely you agree that some people would prefer it one way, some the
other; just choose one that works for you.
> > I like it because the language really does seem to build
> > itself. You can say things in lots of different ways,
> > and they all just sorta work.
> > :-) Woo-hoo!
>
> Then presumably you equally like the alternative I proposed?
Not necessarily.
I, for one, would rather say
my Dog $spot is Scalar;
__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
Paul
--- Me <m...@self-reference.com> wrote:
> [snippage]
> One thing I've wondered is whether traits can/will be created
> that combine a variable type with a value type. My expectation
> was yes, and that these might well, in practice, turn out to
> be pretty popular, perhaps being used more often than straight
> value types alone. In the syntax I propose, they could appear
> thusly:
>
> my Dog $spot;
>
> ie the exact same look, read and feel as existing examples,
> and shorter than the currently required:
>
> my $spot is Dog;
I understand, but wonder which will be used more often.
I can see me typing
my Dog $spot is Dog;
which looks like "see spot run! run, spot, run!" but does do something
useful, sort of....
> > thus mixing the put-it-before and put-it-after syntaxes, since
> > that's a tiny bit less clear than the other two. But I certainly
> > might change my mind on that, since it looks more clear every time
> > I see it :-)
>
> The latter aspect is familiarity. I suspect that's a big part
> of why there's more comfort than seems, er, seemly, with the
> way it is now. (I can see it turning out that the current
> syntax is the best choice, but I'm surprised at the lack of
> engagement on taking a *serious* look at this issue. This
> particular bit of syntax is going to be encountered by newbies
> very early on, it deals with something that cries out for being
> as simple as we can make it ("what, there's variable AND value
> type systems?") and is going to be used a LOT by everyone.)
I'll readily admit that my *first* complaint is a knee-jerk reactionary
response. My second, however, is in fact more an aesthetic one:
my Scalar $spot is Dog;
just doesn't appeal to me, because it doesn't say "my Dog $spot" which
would go woof.
Could you present some examples that read better in English? I mean,
my Dog $spot is Barker;
$spot.sez("woof");
looks good, but could represent either proposed syntax, right?
In one case, a Dog variable holds a Barker value, and in the other, a
Barker variable holda a Dog value. Which has the .sez method? As long
as I can make it work it's fine, but to be honest, I like this syntax
better:
my Kennel @pound is Array of Dog;
Is that syntax right? I don't think so..... >:o/
Which would that be?
Piers Cawley
>> > In the syntax I was proposing
>>
>> I don't _dislike_ it -- I would be fine with it being either way.
>
> I'm in almost the same boat.
>
>
>> [Huffman argument]
>
> The syntax I proposed is /more/ Huffman encoded than the current
> syntax. In addition to the many ways to say things that were in
> the previous email there is also:
>
> my $spot <traits> Dog = ...;
> my $spot <traits> Dog;
> my $spot Dog;
>
> And providing an object variable with a type can use this:
>
> my Dog $spot;
>
> rather than the currently required:
>
> my $spot is Dog;
But it's established that 'is' says things about the *variable* in
every other case. Now you want it to say something about the *value*
in the variable as well? If you thought is was overly overloaded
before this suggestion proves it, at least the current multiple
meanings all come down to 'is says something about the container, but
says something about the value'. C<my Dog $spot> or C<my $spot of Dog>
is orthogonal to the is/but thing, saying something about what will be
put in a container in an easily distinguished way so that the compiler
can do some optimization without having to know about the semantics of
a particular property.
> But the above is almost beside the point. I'm looking to find out
> if people even see the intuitive/logical aspects (especially for
> newbies) behind keeping the variable type with the variable and
> value type with the value. THEN we can get into discussion of
> whether it is possible, how to try to ensure we have the same
> or better Huffman etc. qualities as the current syntax, etc.
You keep saying that it 'keeps the variable type with the variable and
the value type with the value', but, frankly, I don't see it. The
requirement to use 'is' in the common case becomes especially annoying
in the case of function signatures:
sub speak (Animal $critter) {...}
is just neater than
sub speak ($critter is Animal) {...}
at least to my eyes; no useless verbiage to much about with. This
becomes especially important because 'is' is used for so many other
things as well, pulling the value type out front is unambiguous and is
also by far the commonest thing you're likely to want to declare about
a parameter
sub speak ($critter is Animal is copy) {...}
or
sub speak (Animal $critter is copy) {...}
You can witter all you like about wanting to keep the type near the
value, but as soon as you introduce any further 'is' clauses in your
variable declaration, the whole rationale disappears.
--
Piers
Piers Cawley
> [off list]
Taken back to the list because that's where language discussion belongs.
>> But it's established that 'is' says things about the *variable* in
>> every other case. Now you want it to say something about the *value*
>> in the variable as well?
>
> No. I've not proposed making any change to C<is>.
Ah... oops, I misread your original post. Not that it helps much, your
actual proposed syntax is still pretty vile.
> (Fwiw, aiui, the current design team's definition of C<is> allows it
> to say something about both the container and its value.)
Nope. 'is' does the container, 'but' does the value. Of course, it may
well be that the underlying container class may have something to say
about what it expects to contain, but that's implementation dependent
not something in the language.
>> You keep saying that it 'keeps the variable type with the variable and
>> the value type with the value', but, frankly, I don't see it.
>
> Fwiw, I believe Luke came up with that phrase, not me.
>
> Here's a simplified "picture" of the current syntax:
>
> <var declarator> <val type> <var name> <traits> = <val>;
>
> where <traits> are of the form C<is xxx>.
>
> Perhaps you can now see the problem as clearly as Luke?
Okay, I see what you're driving at, but I don't see that it's a
problem. The <val type> is saying something about what kind of
value the variable expects, and will be used even when there's no
value around to assign to the variable.
> The <val type> sits in the midst of var stuff, away from
> the other val stuff that follows the C<=>.
>
> So I suggested:
>
> <var declarator> <var type> <var name> <traits> <val type> = <val>;
my Scalar $spot Dog
Okay, that reads aloud well. Not. Now interpose a trait and it starts
to get really ugly:
my Scalar $spot is Trait Dog
Now Dog looks like an argument to the Trait declaration. How is this
good again? What does it gain us over the current syntax apart from
making you happy because we've added some pseudo consistency by being
inconsistent with what's gone before?
> This was just my first suggestion; there are other
> possibilities, such as:
>
> <var declarator> <var type> <var name> <traits> = <val type> <val>;
>
> but that has its own special problems.
Yeah, like the fact that some people like to declare variables away
from where they're assigned to, and that grammar looks scarily
ambiguous. But, at least you saw the insanity of that and backed away.
> ---
>
> Your very last point touches on a valid possible
> disadvantage of my proposal compared to current syntax:
>
>> sub speak ($critter is Animal is copy) {...}
>>
>> or
>>
>> sub speak (Animal $critter is copy) {...}
>
> Assuming variable types aren't allowed in signatures,
> so at least one of your examples isn't valid (in both
> current and my proposed syntax), we can nevertheless
> compare value type syntax:
I'm not sure that you can make that assumption actually. Especially for
'is copy' parameters. But I take your point. Examples arose from a
misreading of what you were proposing.
> sub foo (Int $qux is copy = 10) {...} # current syntax
>
> or
>
> sub foo ($qux is copy Int = 10) {...} # my proposal
>
> That, imo, tends to demonstrate differing potential
> strengths of each syntax, but:
>
> sub foo (Int $qux is copy) {...} # current syntax
>
> or
>
> sub foo ($qux is copy Int) {...} # my proposal
>
> is, in my proposal, kinda ugly when I first saw it.
> Otoh, I have come to prefer it.
Okay, coming at this a slightly different way. For the reader, the two
important things about a subroutine parameter are its name and its
type. You propose separating these two things? Why?
>> You can witter all you like about wanting to keep the type near the
>> value, but as soon as you introduce any further 'is' clauses in your
>> variable declaration, the whole rationale disappears.
>
> I think the reverse is actually true.
>
> If there's a default value in a sub parameter declaration,
> or an init value in a variable declaration, the rationale
> becomes /more/ compelling the more C<is> clauses there are,
> because it puts the value type near the value.
Only if you accept your claim that it's better to have the expected
value type near the assigned value in the small proportion of cases
where declaration and assignment happen at the same time. I don't
accept that claim -- far better to have the expected value type and
the variable name kept nice and close together, especially in function
signatures.
You seem to be attempting to optimize for the uncommon case, and at
the same time taking a language construction that had the pleasantly
Perlish property of reading well as 'real' English and replacing it
with something that reads like gobbledegook. Personally, when faced
with a choice of two constructs that do the same thing, I choose the
one that reads well. As Damian said in a 'throwaway' remark during his
'Life, the Universe and Everything' talk, "Interface is everything";
your proposal ignores this maxim and that is why it fails.
--
Piers