Variable/value type syntax

[Ralph Mellor]

[Sorry about pipe symbol junk in my last post. Mozilla, mumble...]

When I first saw the variable/value type syntax, it didn't
feel quite right to me. This feeling hasn't left me in the
month or two since I first saw it and when I reflected on
what's buggin' me I realized others might feel the same way.

my Foo $spot is Bar;

Even though I know that Foo is the value type and Bar is the
variable type, my intuition continues to suggest it ought to
be the other way around.

I think this is because the C<my> and $spot are to do with
the variable, so Foo feels like it ought to be as well.
(Another strong possibility is that it's because of what I'm
used to in typed languages I've used in the past, but I find
it odd that I haven't gotten past that yet.) Does anyone else
find the same (mild but persistent) cognitive dissonance?

I'm also mildly bugged by the many exceptions related to when
and how you can use the "prefix" syntax for declaring the
value type returned by a routine.

So, what about a syntax more like:

my FastArray @array int;
my FastArray @array int = 6;
my sub Foo int { ... };

--
ralph

[Luke Palmer]

> [Sorry about pipe symbol junk in my last post. Mozilla, mumble...]
>
> When I first saw the variable/value type syntax, it didn't
> feel quite right to me. This feeling hasn't left me in the
> month or two since I first saw it and when I reflected on
> what's buggin' me I realized others might feel the same way.
>
> my Foo $spot is Bar;
>
> Even though I know that Foo is the value type and Bar is the
> variable type, my intuition continues to suggest it ought to
> be the other way around.
>
> I think this is because the C<my> and $spot are to do with
> the variable, so Foo feels like it ought to be as well.
> (Another strong possibility is that it's because of what I'm
> used to in typed languages I've used in the past, but I find
> it odd that I haven't gotten past that yet.) Does anyone else
> find the same (mild but persistent) cognitive dissonance?
>
> I'm also mildly bugged by the many exceptions related to when
> and how you can use the "prefix" syntax for declaring the
> value type returned by a routine.

There's not many exceptions. The typing declarations are very
TMTOWTDI, however.

Basically, you can only declare the return type of a sub before its
name if there's a declarator in front of it. That's mostly for
parsing, I presume.

> So, what about a syntax more like:
>
> my FastArray @array int;
> my FastArray @array int = 6;
> my sub Foo int { ... };

Your word order is fairly close to using the is/of syntax:

my @array is FastArray of int;
my @array is FastArray of int = (6);
my sub Foo returns int { ... };

Oh, I love the anonymous declarator. Now all we need is the specific
determiner.

the sub foo {
# do stuff
}
#later
sub foo { # Illegal. Can't redefine symbol foo.
# different stuff
}

C<the> subs can be inlined and optimized because they will never be
redefined. I don't know whether or not this would be a good idea
(regardless of whether we use C<the>).

On one hand, it'd be good, because this kind of behavior is wanted
sometimes. On the other, it'd be bad, because speed-hungry module
writers would end up writing modules that aren't flexible to certain
needs.

We have the posessive determiners, signified with C<::>. We even have
demonstratives, namely the unary operators that operate on the topic.
We have indefinites, named as sub parameters with types.

Sweet!

Luke

[Me]

> > my Foo $spot is Bar;
> >
> > Even though I know that Foo is the value type and Bar is the
> > variable type, my intuition continues to suggest it ought to
> > be the other way around.

I assume you don't feel the same sense of things being the wrong
way around?

> > So, what about a syntax more like:
> >
> > my FastArray @array int;
> > my FastArray @array int = 6;
> > my sub Foo int { ... };
>
> Your word order is fairly close to using the is/of syntax:
>
> my @array is FastArray of int;
> my @array is FastArray of int = (6);
> my sub Foo returns int { ... };

My inner cognitive psychology student tells me that, overall,
most coders would find the rearranged syntax that I suggested
more intuitive than the current syntax, when keywords are left
out. And that the suggested syntax avoids the gotta-have-a-name
and gotta-have-a-declarator constraints when declaring value
types for routines. And it puts the value type near an initial
or default value if one is specified. And avoids the slight
oddity of 'FastArray of int'. And so on.

--
ralph

[Luke Palmer]

> > > my Foo $spot is Bar;
> > >
> > > Even though I know that Foo is the value type and Bar is the
> > > variable type, my intuition continues to suggest it ought to
> > > be the other way around.
>
> I assume you don't feel the same sense of things being the wrong
> way around?

Nope. That's why I'm being conservative toward the current way.

> > > So, what about a syntax more like:
> > >
> > > my FastArray @array int;
> > > my FastArray @array int = 6;
> > > my sub Foo int { ... };
> >
> > Your word order is fairly close to using the is/of syntax:
> >
> > my @array is FastArray of int;
> > my @array is FastArray of int = (6);
> > my sub Foo returns int { ... };
>
> My inner cognitive psychology student tells me that, overall,
> most coders would find the rearranged syntax that I suggested
> more intuitive than the current syntax, when keywords are left
> out. And that the suggested syntax avoids the gotta-have-a-name
> and gotta-have-a-declarator constraints when declaring value
> types for routines. And it puts the value type near an initial
> or default value if one is specified. And avoids the slight
> oddity of 'FastArray of int'. And so on.

I agree with the idea of putting the variable type near the variable
and the value type near the value. That makes sense. (I don't see
what is odd at all about 'FastArray of int')

But we have to look at Huffman and our C heritage (which we are
liberally throwing out the window at every turn, but there's still
something to be said for it). Presumably:

my Type @var;

Will be much more commonly said than:

my @var is SuperVariable;

And C-ers will be much more comfortable with:

my Type @var;

Than

my @var Type;

(Although Pascalers would like us. But honestly, who writes in
Pascal?)

Not to mention it reads better in english:

my Dog $spot is Lazy;

Compared to

my Lazy $spot is Dog;

I would agree with your syntax, however, because it doesn't overload
C<is> as heavily, C<is> overloading being one of my pet peeves. Then
there's a clear distinction between container classes and trai....

Woah!

I get it!

class constant {
sub STORE { die "You'll burn for this!" }
}
class LazyFoo {
has $.cache;
sub FETCH { $.cache //= foo() }
}

my $var is constant is LazyFoo;

I think I finally grok ties being unified with traits. It's
delegation! To find FETCH, look in LazyFoo, and then in constant, and
then in Scalar.

That rocks, because then you don't have to fulfill all the Scalar
access methods, because they would just delegate down into Scalar
itself. And you can layer container types if they're designed to be
layered.

In this case, I entirely reject your proposed syntax, because it
I<doesn't> unify traits with containers.

Or is this a pseudogrok?

Luke

[Me]

> > > > my Foo $spot is Bar;

> > ...

> > I assume you don't feel the same sense of things being the wrong
> > way around?
>

> Nope. ...

> I agree with the idea of putting the variable type near the variable
> and the value type near the value. That makes sense.

Ok. And presumably you agree that the C<my> and the C<$spot> are
to do with the variable so at least your left brain hemisphere
sees an issue with stuffing the value type in the middle?

> > > > So, what about a syntax more like:
> > > >
> > > > my FastArray @array int;
> > > > my FastArray @array int = 6;
> > > > my sub Foo int { ... };
>

> But we have to look at Huffman and our C heritage
>

> my Type @var;
>
> Will be much more commonly said than:
>
> my @var is SuperVariable;
>
> And C-ers will be much more comfortable with:
>
> my Type @var;
>
> Than
>
> my @var Type;
>
> (Although Pascalers would like us. But honestly, who writes in
> Pascal?)

I spent over a year doing mostly Delphi coding recently.
This is perhaps the root cause of my feeling it's wrong.

What are the C equivalents of the following:

my ValueType @var;
my @var is VariableType;

?

> I would agree with your syntax, however, because it doesn't overload
> C<is> as heavily, C<is> overloading being one of my pet peeves. Then
> there's a clear distinction between container classes and trai....
>

> [epiphany about unifying container classes and traits]

>
> In this case, I entirely reject your proposed syntax, because it
> I<doesn't> unify traits with containers.

What I'm proposing doesn't alter that aspect of the existing variable
type syntax. You could still say:

my @array is FastArray is Lazy;

--
ralph

[Austin Hastings]

--- Me <m...@self-reference.com> wrote:
> > (Although Pascalers would like us. But honestly, who writes in
> > Pascal?)

Nicki Wirth, but he calls it Modula, now.

>
> I spent over a year doing mostly Delphi coding recently.
> This is perhaps the root cause of my feeling it's wrong.
>
> What are the C equivalents of the following:
>
> my ValueType @var;
> my @var is VariableType;
>

C doesn't explicitly differentiate between value and variable type. The
closest you can come is pointers to things, or type modifiers like
unsigned or constant:

unsigned int foo; /* Is "unsigned" a value type? */
const int bar = 1; /* Is "const" a variable type? */

[auto] ValueType *var[]; /* Array of pointers to ValueType things */
/* or */
[auto] ValueType var[];

[auto] VariableType var[];

[Paul]

--- Luke Palmer <fibo...@babylonia.flatirons.org> wrote:
> . . . .

> I would agree with your syntax, however, because it doesn't overload
> C<is> as heavily, C<is> overloading being one of my pet peeves. Then
> there's a clear distinction between container classes and trai....
>
> Woah!
>
> I get it!
>
> class constant {
> sub STORE { die "You'll burn for this!" }
> }
> class LazyFoo {
> has $.cache;
> sub FETCH { $.cache //= foo() }
> }
>
> my $var is constant is LazyFoo;
>
> I think I finally grok ties being unified with traits. It's
> delegation! To find FETCH, look in LazyFoo, and then in constant,
> and then in Scalar.
>
> That rocks, because then you don't have to fulfill all the Scalar
> access methods, because they would just delegate down into Scalar
> itself. And you can layer container types if they're designed to be
> layered.
>
> In this case, I entirely reject your proposed syntax, because it
> I<doesn't> unify traits with containers.
>
> Or is this a pseudogrok?
>
> Luke

That *does* rock pretty hard. Damn, this language really writes itself,
lol.... Oh, the Toys!

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com

[Larry Wall]

On Fri, Apr 11, 2003 at 04:27:53PM -0600, Luke Palmer wrote:
: Woah!

:
: I get it!
:
: class constant {
: sub STORE { die "You'll burn for this!" }
: }
: class LazyFoo {
: has $.cache;
: sub FETCH { $.cache //= foo() }
: }
:
: my $var is constant is LazyFoo;
:
: I think I finally grok ties being unified with traits. It's
: delegation! To find FETCH, look in LazyFoo, and then in constant, and
: then in Scalar.
:
: That rocks, because then you don't have to fulfill all the Scalar
: access methods, because they would just delegate down into Scalar
: itself. And you can layer container types if they're designed to be
: layered.
:
: In this case, I entirely reject your proposed syntax, because it
: I<doesn't> unify traits with containers.
:
: Or is this a pseudogrok?

It might be pseudogrok of the specifics, but it's definitely the
case that properties are intended to tweak or overlay the semantics
in a particular order, one way or another. I can see arguments that
earlier properties take precedence, and arguments that later properties
take precedence. I lean toward the latter, insofar as:

0 but true but false

should probably be considered false...

Larry

[Me]

Piers, a thread summary for you. Of course it's long enough that
you'll have to summarize further:

1. Ralph argued that the current variable and sub declaration
syntax:

<var declarator> <val type> <var> <var type> <traits> = <val>;

contains an aspect that is counter intuitive and illogical,
namely the placement of the value type. Luke responded:

"I agree with the idea of putting the variable type
near the variable and the value type near the value."

2. Ralph suggested a syntax along the lines of:

<var declarator> <var type> <var> <traits> <val type> = <val>;

Leading to examples such as:

my FastArray @array is Blah; # FastArray is a variable type
my @array is FastArray is Blah; # Same thing said differently
# (nb: a vartype is a trait)

my FastArray @array int; # int is a value type
my @array is FastArray of int; # Same thing said differently

my @array int = (3); # int appears next to value
my @array of int = (3); # Same thing said differently

3. Luke raised some arguments in support of the current syntax:

First, variable types must be specified in the form of C<is Foo>.
This is consistent with traits in general which is a good thing.
Ralph agreed, but noted that the changed syntax he had proposed
retained the C<is Foo> syntax, rendering this argument largely
moot.

Second, Huffman argues for the most common sort of type (value
or variable) to be specifiable without use of an extra keyword.
Again, Ralph agreed, but noted that the changed syntax he had
proposed achieved this.

Third, C convention has the type appear before the identifier.
Ralph noted that, in his proposed syntax, type info still
appeared in the same syntax slot; the only difference being
that it was now variable type info rather than a value type.

--
ralph

[Austin Hastings]

Larry,

If sequence implies layering, then what happens when I say

my $x is Dog is Friend;

$x.call;

is determined by the order: Speech::Speak("Here, $x") or
Telephony::Dial($x.phone)
depending on which is "last".

So the evaluation rules for is/of/returns need to be specified:

my $a is Array of Int;

shouldn't invoke Int::value, but rather Array::length when put into numeric
context.

my $x is Dog is Friend returns Hash of Slobber is Favorite;

What's the order?

=Austin

[Luke Palmer]

Austin writes:

> Larry wrote:
> > It might be pseudogrok of the specifics, but it's definitely the
> > case that properties are intended to tweak or overlay the semantics
> > in a particular order, one way or another. I can see arguments that
> > earlier properties take precedence, and arguments that later properties
> > take precedence. I lean toward the latter, insofar as:
> >
> > 0 but true but false
> >
> > should probably be considered false...
>

> If sequence implies layering, then what happens when I say
>
> my $x is Dog is Friend;
>
> $x.call;

With C<is>, you are specifying variable types. I don't think method
calls delegate into the variable type, for the same reason I don't
think proerty access syntax should be the same as method call syntax.
I would prefer something like Perl5's C<tied>, but less ugly.

Anyway, presuming that I<does> access the variable methods, the Friend
one would probably be called first. But in reality, Friend::METHOD or
whatever would be the one called, not Friend::call.

> is determined by the order: Speech::Speak("Here, $x") or
> Telephony::Dial($x.phone)
> depending on which is "last".
>
> So the evaluation rules for is/of/returns need to be specified:
>
> my $a is Array of Int;

No they don't. Array knows that when it's indexed into it returns
ints. It tells the compiler this. That's all it needs to know.

> shouldn't invoke Int::value, but rather Array::length when put into numeric
> context.
>
>
> my $x is Dog is Friend returns Hash of Slobber is Favorite;
>
> What's the order?

First, let's see if I get the precedence right:

my $x (is Dog is (Friend returns (Hash of Slobber)) is Favorite)

In that case, presumably Favorite would be looked in for variable
access methods, then Friend, then Dog. Whatever method Friend
specifies for dereferencing it is the only way you can get at the Hash
of Slobber.

But I can't really know. It's not likely the design team knows either
(though they probably have a better idea than I).

Luke