Re: overloading the variable declaration process

[Audrey Tang]

On 2/6/06, Darren Duncan <[EMAIL PROTECTED]> wrote:
> Speaking briefly, I would like it if Perl 6 provided a way for a
> class (or role, or meta-class, etc) to declare that all variables
> declared to be of that type are automatically/implicitly set to a
> particular value at declaration time, so that they are not undefined
> if the programmer using them doesn't explicitly set a value.

In a somewhat related note, Perl 6 allows this form:

my Dog $fido .= new;

which may be treated as a special form (as is currently the case with Pugs).
However if it's not, it would desugar to:

my Dog $fido;
$fido = $fido.new;

which seem to imply that $fido is set to ::Dog (the dog class) as its
initial value.
However, that would potentially make this a no-op:

my Dog $fido = Dog;

which may make sense except that defined($fido) may need to be regulated
as true even for the "my Dog $fido" case.

If so, your use case can be satisfied by declaring that ::NumType (the
class object)
numifies to 0, and ::StrType stringifies to "", via the coerce form.

Audrey

overloading the variable declaration process

[Darren Duncan]

All,

Speaking briefly, I would like it if Perl 6 provided a way for a 
class (or role, or meta-class, etc) to declare that all variables 
declared to be of that type are automatically/implicitly set to a 
particular value at declaration time, so that they are not undefined 
if the programmer using them doesn't explicitly set a value.


Here are usage examples:

  my NumType $foo; # implicitly contains a defined NumType of value 0
  my StrType $bar; # implicitly contains a defined StrType of value ''

Sure, the user could say ".= new()" or such, but I wanted a fallback 
if they didn't do that.


Then when they come to just use that not explicitly set variable, it 
contains some type-defined reasonable default value.


Presumably, the object meta-model would have an appropriate function 
defined for use at that time, which returns undef by default, and 
this function is what individual classes can override.


Part way through writing this, I had a brief chat on #perl6 with 
stevan (and apparently the meta-model is still quite in flux) and he 
said my question was related to Larry's "class but undef" idea, and 
that Larry should talk more about the subject.


Thank you. -- Darren Duncan

Re: Is S05 correct?

[Andrew Savige]

--- Larry Wall wrote:
> Yes, that's a typo.

Which reminds me, I noticed some Synopsis typos as follows.

S03:

1) "List flattening" section, sixth paragraph:

  ... call semantics as is does in scalar context

Change "is" to "it".

S04:

1) "The do-once loop" section, last paragraph:

  ... followed by a statment label

Change "statment" to "statement".

2) "Control Exceptions" section, third paragraph:

  ... or by falling of the end of it

Change "of" to "off".

3) "Control Exceptions" section, last paragraph:

  ... in current subroutine. then a fallback search

Change "then" to "Then".

S06:

1) "Parameter and arguments" section, last paragraph:

  ... need to be kept in the list until bound. an implementation

I assume "an" should be "An".

2) "Polymorhpic Types" section, second paragraph:

  Fancier type constrains ...

I assume "constrains" should be "constraints".

3) "Generic Types" section, first paragraph, last sentence:

  It declares the new type name in whatever scope the
  surrounding declaration is associated lexical scope.

I found this phrasing unclear.

4) "Return Types" section, fifth paragraph:

  ... but outside the sub it just we don't know anything

I found this phrasing unclear.

5) "Pairs as lvalues" section, second paragraph:

  ... provided you write hte left side

Change "hte" to "the".

S11:

Though only an example, in the interests of historical
accuracy, I'd like to see:

  use perl5:ACME::Bleach-1.0-DCONWAY;

changed to:

  use perl5:Acme::Bleach-1.12-DCONWAY;

Only Casey West (erroneously) spelled Acme as ACME (to annoy
Leon Brocard). And there never was an Acme::Bleach-1.0; it
was moved from Bleach to Acme::Bleach at version 1.12.

S12:

1) "Methods" section, eleventh paragraph:

  However, you can turn extend any of the legal forms...

I found this phrasing unclear.

2) "Types and Subtypes" section, sixth paragraph:

  ... (takes away capabiliites)

Change "capabiliites" to "capabilities".

S13:

1) "Fallbacks" section, second paragraph:

  That is, you're specify the abstract operation...

I found this phrasing unclear.



Send instant messages to your online friends http://au.messenger.yahoo.com 

Universal Roles, and deriving these roles for any class

[Yuval Kogman]

Background:

At work we have a big C++ project. I just added a new object, and
now $boss asked me to add the send/receive interface. These two
methods allow an object to be serialized to and from a stream.
Essentially it means

// superclass methods for core types
sendInt(int_member);
sendString(string_member);

// all object members need to also inherit Serializable
obj->send(socket);

and

receiveInt(int_member);
receiveString(string_member);
obj = new Object();
obj->receive(socket);

etc for each member, in the right order with the right type.

This is a dump example since we just do .perl, but let's say pretend
for a moment that we don't.

Perl 6 has some advantages over C++ that make this trivial (or so I
hope):

* a meta model (iterate attributes, know their type, etc)
* roles (no need to inherit Serializable, this is a bit cleaner)
* attitude (this is up for discussion ;-)

I'd like to be able to declare my serializable role as a univeral
role.

This basicaally means:

role Serializable {
method send ( Stream $fh ) {
# iterate all attrs
my Serializable $attr = $?SELF.meta.get_attr;
...
}

method receive ( Stream $fh ) {
# iterate all attrs
...
}
}

# core types
Num does Serializable {
method send ( Stream $fh ) {
$fh.print( "$?SELF" );
}
}

and then to never say that any class does it. Instead, i'd like to
have a duck typing like approach:

my Serializable $x = Monkey.new();
# or
my $x = Monkey.new but Serializable;

# and then
$x.send( $socket ); # no ambiguity

And then I'd like to have these features:

* Have type inferrencing type check the send and receive methods
* have it automatically infer that all the attrs of Monkey
  are also Serializable, due to the fact that send iterates
  them and declares that
* get nice errors that tell me that Moneky can't be
  Serializable because the member $stream deep inside an object
  within Monkey (for example, if Anus has Stream ;-) is not
  Serializable, nor can the Serializable role be
  automatically applied to it because it has opaque
  internals.

This probably makes more sense for other interfaces.

This also reminds me a bit of attribute grammars - i'd like to be
able to automatically derive node roles inside AGs by just
specifying a generic universal behavior, and behavior for the
leaves.

Err, comments please =)

-- 
 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: : neeyah!



pgpbl8D1sTOqm.pgp
Description: PGP signature