Re: RFC 279 (v1) my() syntax extensions and attribute declarations

2000-09-28 Thread Nathan Wiger

Alan Gutierrez wrote:
> 
> I still hope that it doesn't get as complicated as all this. I know
> there are arguments out there for specifying integer size and signedness
> but I can't imagine that adding this stuff is a good thing.

Key thing: This is all *optional*. This is *not* required. I cannot
stress that strongly enough.

These extensions are for those people that need to really care about
every bit, or that need to specify specific properties for variables and
subs.

> Here I'd prefer to see private and laccess as functions.
> 
> private $r->{name} = 'Nate';
> laccess $s->{VAL} = '';
> 

The problem is twofold:

   1. The proliferation of many many keywords
   2. Inability to group declarations

For example, you couldn't do this:

   my $r->{name} :private :laccess('first') = "Nate";

Plus, you aren't able to restrict your attributes to certain classes.
For example, what if you want ":fluffy" to only be an attribute for your
Dog class?

I just submitted an RFC on a common attribute system; check it out and I
think you'll agree this is a more flexible and extensible approach.

> And as far as the :shared modifier goes I much prefer the our keyword.

Where did you see a :shared modifier? Not in this RFC. :-)

our would have the same abilities as my, with the difference being the
scope of the variable, same as currently.

-Nate



Re: RFC 279 (v1) my() syntax extensions and attribute declarations

2000-09-26 Thread Alan Gutierrez

On 24 Sep 2000, Perl6 RFC Librarian wrote:

I still hope that it doesn't get as complicated as all this. I know
there are arguments out there for specifying integer size and signedness
but I can't imagine that adding this stuff is a good thing.

> Note that multiple types cannot be specified on the same line. To
> declare variables of multiple types, you must use separate statements:
> 
>my int ($x, $y, $z) :64bit;
>my string ($firstname, $lastname :long);
 
Not so bad if I don't have to worry about 64bit or long. I'd rather not
worry about integer versus string, but I assume there are some
performance gains in doing so.


>$a[0] :32bit = get_val;   # 32-bit
>$r->{name} :private = "Nate"; # privatize single value
>$s->{VAL} :laccess('data') = "";  # lvalue autoaccessor

Here I'd prefer to see private and laccess as functions.

private $r->{name} = 'Nate';
laccess $s->{VAL} = '';

And as far as the :shared modifier goes I much prefer the our keyword.

Alan Gutierrez




RFC 279 (v1) my() syntax extensions and attribute declarations

2000-09-24 Thread Perl6 RFC Librarian

This and other RFCs are available on the web at
  http://dev.perl.org/rfc/

=head1 TITLE

my() syntax extensions and attribute declarations

=head1 VERSION

  Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
  Date: 24 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 279
  Version: 1
  Status: Developing

=head1 ABSTRACT

This RFC fleshes out variable declarations with C, and also proposes
a way to assign attributes without the need for a C anywhere.

=head1 DESCRIPTION

Camel-3 shows some interesting hints of what's been proposed for C
declarations:

   my type $var :attribute = $value;

And we all know that you can use C to declare a group of variables:

   my($x, $y, $z);

Here's the issues:

   1. How do the two jive together?
  
   2. Should it be possible to assign attributes to individiual elements
  of hashes/arrays? (yes)

=head2 Cohesive C syntax

This RFC proposes that you be able to group multiple variables of the
same type within parens:

   my int ($x, $y, $z);
   my int ($x :64bit, $y :32bit, $z);

It seems most logical that:

   1. The type will be the same across variables; this is common
  usage in other languages because it makes sense.

   2. The attributes will be different for different variables.

As such, multiple attributes can be assigned and grouped flexibly:

   my int ($x, $y, $z) :64bit;   # all are 64-bit
   my int ($x, $y, $z :unsigned) :64bit; # plus $z is unsigned

Note that multiple types cannot be specified on the same line. To
declare variables of multiple types, you must use separate statements:

   my int ($x, $y, $z) :64bit;
   my string ($firstname, $lastname :long);

This is consistent with other languages and also makes parsing
realistic.

=head2 Assigning attributes to individual elements of hashes/arrays

This is potentially very useful. ":laccess", ":raccess", ":public",
":private", and others spring to mind as potential candidates for this.
This RFC proposes that in addition to attributes being assignable to a
whole entity:

   my int @a :64bit;   # makes each element a 64-bit int
   my string %h :long; # each key/val is long string

They can also be declared on individual elements, without the need for
C:

   $a[0] :32bit = get_val;   # 32-bit
   $r->{name} :private = "Nate"; # privatize single value
   $s->{VAL} :laccess('data') = "";  # lvalue autoaccessor

However, a problem arises in how to assign types to singular elements,
since this requires a C:

   my int $a[0] :64bit; # just makes that single element
# a lexically-scoped 64-bit int?

   my string $h{name} = ""; # cast $h{name} to string, rescope %h?

Currently, lexical scope has no meaning for individual elements of
hashes and arrays. However, assigning attributes and even types to
individual elements seems useful. There's two ways around this that I
see:

   1. On my'ing of an individual hash/array element, the
  entire hash/array is rescoped to the nearest block.

   2. Only the individual element is rescoped, similar
  to what happens when you do this:

  my $x = 5;
  {
 my $x = 10;
  }

Either of these solutions is acceptable, and they both have their pluses
and minuses. The second one seems more consistent, but is potentially
extremely difficult to implement.

=head1 IMPLEMENTATION

Hold on.

=head1 MIGRATION

None. This introduces a more flexible syntax but does not break old
ones.

=head1 REFERENCES

Camel for the C syntax.