Re: Yadda yadda yadda some more
Austin Hastings wrote:
So, how wrong is this:
class VerticalYadda
{
extends Yadda;
multi method coerce:as($what) {
say Coercing VerticalYadda to ~ ($what as Str);
next METHOD;
}
}
sub *\U{VERTICAL ELLIPSIS}()
{
return new VerticalYadda;
}
=Austin
macro \N{VERTICAL ELLIPSIS} :parsed«term» {
return '...';
}
Re: Yadda yadda yadda some more
Luke Palmer wrote:
Aaron Sherman writes:
Ok, so in the case of:
my int $i = ...;
we should apply Cconvert:as(..., ::int) and fail at run-time,
correct? There's nothing wrong with TRYING to do the conversion, just as
there should not be anything wrong with:
my int $i = 4;
which has some pretty simple semantics in Perl.
Right. Though, constant folding at CHECK time might be able to tell when
you're *going* to do an invalid conversion and complain about it right
then.
In the case of ..., give it type error semantics. That is, any
expression involving ... gets type Except instead of reporting
at the end of the statement, just suppress the errors and move on.
Huh? Um, no, your ideas as to what happens don't give the desired
semantics for ..., and don't make other desired semantics fall out
naturally.
The basic semantic for ... is that use of it gives an error at runtime,
when the code has been hit. Unless a pragmata changes things, it
should not be possible to trigger an error from use of ... without the
code being actually run.
Thus, I propose the following: A convert routine should be able to tell
if it's being run at runtime or compile time, and do a fail with reason
matching :i/not yet/ or :i/too early/, to defer the conversion until
runtime.
This gives the desired semantics for ... -- an error at runtime, not
compile time. It also allows for desired semantics elsewhere. Say I
have two classes, Net::IP::Addr and Net::HostName. It should be
possible to convert a Net::HostName to a Net::IP::Addr, but that
conversion should not happen until runtime (because I may be keeping
around the bytecode for a long time, and the hostname-IP mapping may be
different by then).
(Note: Aaron Sherman's syntax above doesn't match A12#Overloading. Was
the syntax changed, or is he wrong?)
multi sub *coerce:as (Net::HostName $name, Net::IP::Addr ::to) {
fail 'Too early to convert hostname to IP address' if
(we_are_in_compile_time);
$name.lookup;
}
(Yes, I know those parens around the condition of the if are optional --
even in perl5. I like them.)
What I don't know is how to write Cwe_are_in_compile_time. A property
of the object that Ccaller gives?
I don't really like using fail with regex matching here, but we need to
be able to return a real undef (we don't mind converting early, but the
correct conversion is to undef -- C0 as bool), should be able to
really fail (it's not a valid conversion, and waiting won't help
anything -- Csqrt(-1) as Real).
BTW, since that example above isn't the hottest, imagine defining a
conversion from a hostname to a DNS lookup, that saves the expiry time,
and defining a second coercion from that to an IP address, that reruns
the lookup if the TTL has expired. The first coercion should take place
at compile time, the second not until runtime.
-=- James Mastros
Re: Yadda yadda yadda some more
James Mastros writes: In the case of ..., give it type error semantics. That is, any expression involving ... gets type Except instead of reporting at the end of the statement, just suppress the errors and move on. Huh? Um, no, your ideas as to what happens don't give the desired semantics for ..., and don't make other desired semantics fall out naturally. The basic semantic for ... is that use of it gives an error at runtime, when the code has been hit. Unless a pragmata changes things, it should not be possible to trigger an error from use of ... without the code being actually run. People were talking about what type ... should be. So at static type analysis time (if we even do that; I think we do, otherwise we wouldn't have static type declarations), you give ... type error semantics, but then don't die until you actually run the my int $foo = ...; # ... my int $bar = 34;# int $bar += $foo;# ... That's the correct solution to the type analysis problems. I wasn't trying to address anything else. The problem was that people were trying to derive it/make it a role/give it some type that could go anywhere. I'm just saying it should be a special case. That special case is already used when there's a type error, except that the type error dies after the current statement finishes processing. Luke
Re: Yadda yadda yadda some more
--- Luke Palmer [EMAIL PROTECTED] wrote:
People were talking about what type ... should be. So at static
type analysis time (if we even do that; I think we do, otherwise we
wouldn't have static type declarations), you give ... type error
semantics, but then don't die until you actually run the
my int $foo = ...; # ...
my int $bar = 34;# int
$bar += $foo;# ...
That's the correct solution to the type analysis problems. I wasn't
trying to address anything else.
The problem was that people were trying to derive it/make it a
role/give it some type that could go anywhere. I'm just saying it
should be a special case. That special case is already used when
there's a type error, except that the type error dies after the
current statement finishes processing.
How do I extend ...?
That is, I want to code \U{VERTICAL ELLIPSIS} as a code goes here
alternative to ... with some additional semantics.
So, how wrong is this:
class VerticalYadda
{
extends Yadda;
multi method coerce:as($what) {
say Coercing VerticalYadda to ~ ($what as Str);
next METHOD;
}
}
sub *\U{VERTICAL ELLIPSIS}()
{
return new VerticalYadda;
}
=Austin
Re: Yadda yadda yadda some more
On Tue, 2004-05-18 at 05:23, James Mastros wrote: (Note: Aaron Sherman's syntax above doesn't match A12#Overloading. Was the syntax changed, or is he wrong?) Aaron Sherman was arm-waving as the important bits were not related to the specific syntax of coerce overloading. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Yadda yadda yadda some more
On Fri, 2004-05-14 at 18:53, Luke Palmer wrote: Aaron Sherman writes: or did Larry mention a way to define a converter and I missed it? Yep, that's what happened. See Apocalypse 12 under Overloading. Ok, so in the case of: my int $i = ...; we should apply Cconvert:as(..., ::int) and fail at run-time, correct? There's nothing wrong with TRYING to do the conversion, just as there should not be anything wrong with: my int $i = 4; which has some pretty simple semantics in Perl. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Yadda yadda yadda some more
Aaron Sherman writes: On Fri, 2004-05-14 at 18:53, Luke Palmer wrote: Aaron Sherman writes: or did Larry mention a way to define a converter and I missed it? Yep, that's what happened. See Apocalypse 12 under Overloading. Ok, so in the case of: my int $i = ...; we should apply Cconvert:as(..., ::int) and fail at run-time, correct? There's nothing wrong with TRYING to do the conversion, just as there should not be anything wrong with: my int $i = 4; which has some pretty simple semantics in Perl. Right. Though, constant folding at CHECK time might be able to tell when you're *going* to do an invalid conversion and complain about it right then. In the case of ..., give it type error semantics. That is, any expression involving ... gets type Except instead of reporting at the end of the statement, just suppress the errors and move on. Luke
Re: Yadda yadda yadda some more
Larry Wall [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
: does that mean that this use of yada yada yada is already decided on and
allowed?
Yes, with the proviso that it only works that way where a term is
expected. (As a postfix operator it's short for C..Inf.)
So, C... is a syntactically valid term which dies when evaluated at
run-time (or throws an exception, if they're not the same thing). It seems
to me then that the Yada operator has to have 2 special properties beyond,
say, a macro which returns the closure C{ die }. And it raises two
questions for me. Also, we should get used to calling it the Yada Yada Yada
term, or perhaps even the Yada literal, since it is not operating on
anything (outside its postfix unary form).
[Special Property #1]
If the Yada operator is valid anywhere a term is expected, it must
syntactically valid in all these cases:
my $id = ...;
my Int age = ...;
my Str $name = ...;
my DbHandle $db = ...;
my Int of Hash @array = ...;
Therefore, the compile-time type of the term must be assignment-compatible
with any and all lvalues. This will have to be true at least in those
contexts that ask for strict type-checking, even if other scopes don't care.
This reminds me of Java's Cnull literal reference value which can be
validly assigned to any reference type. (Technically, it's not a keyword,
but try giving that answer on an interview at your own peril.)
I don't see any functional problem with this special property as long as it
can be implemented in the core language. Seems like it would have to be a
special rule of type checking. So we'd have generic Scalar as the universal
recipient, and now the Yada literal as the universal donor. (Any association
of strong type-checking with the extraction of blood is purely imaginary.
;-)
[Special Property #2]
As mentioned in A6, redefining a function (subroutine, method, etc.) which
has only been declared with the Yada Yada Yada closure does not generate a
warning. It seems like Perl 6 will have to take some special note, then,
when we declare a function as:
sub foo($bar, $baz) {...}; # pre-declaring sub foo()
as opposed to:
sub foo($bar, $baz) { die }; # defining sub foo() to throw an exception
(mod throwing syntax)
so that the first case can be redefined without a warning, while the second
case would warn on redefinition.
[Question #1]
I'd like to understand how Aaron Sherman's initial example would work:
class Foo {
has $.a;
has $.b;
...;
}
We know that the class will compile fine, but when exactly would it pitch a
fit (or exception)? I'm unsure of the meaning of this idiom, because the
only time the C... line gets evaluated is at class compilation time, which
is when we don't want any complaints in this case.
[Question #2]
Does C... know when it's being called during compilation and when it's
being used at run-time? I.e., how would it behave in a compile-time block
such as BEGIN:
BEGIN { our IO $server = ...; };
The rhs value is evaluated here at compile-time. Is C... smart enough to
know that and keep quiet?
Regards,
-Dov
Re: Yadda yadda yadda some more
--- Matthew Walton [EMAIL PROTECTED] wrote:
Dov Wasserman wrote:
my $id = ...;
my Int age = ...;
my Str $name = ...;
my DbHandle $db = ...;
my Int of Hash @array = ...;
Therefore, the compile-time type of the term must be
assignment-compatible with any and all lvalues. This will have to
be true at least in those contexts that ask for strict type-
checking, even if other scopes don't care.
This reminds me of Java's Cnull literal reference value which can
be validly assigned to any reference type. (Technically, it's not a
keyword, but try giving that answer on an interview at your own
peril.)
I don't see any functional problem with this special property as
long as it can be implemented in the core language. Seems like it
would have to be a special rule of type checking. So we'd have
generic Scalar as the universal recipient, and now the Yada
literal as the universal donor. (Any association of strong type-
checking with the extraction of blood is purely imaginary.
As far as the compiler's concerned at that point, it might behave
something like Cundef. For the purposes of the type checker that
would probably be sufficient. Worrying about the actual value
wouldn't be a problem until runtime, at which time it's quite safe
for C... to do what it's supposed to do and complain.
I think of this as very much like the typed-undef we discussed last
month or so: ... should return an unthrown exception wrapped in
undef-ness.
The type returned by ... should just have a multitude of type-casting
tricks associated:
my int $i = ...; # Fails at compile time -- no good conversion.
my Int $i = ...; # Warns at compile time, fails at runtime.
[Special Property #2]
As mentioned in A6, redefining a function (subroutine, method,
etc.) which has only been declared with the Yada Yada Yada closure
does not generate a warning. It seems like Perl 6 will have to
take some special note, then, when we declare a function as:
sub foo($bar, $baz) {...}; # pre-declaring sub foo()
as opposed to:
sub foo($bar, $baz) { die }; # defining sub foo() to throw an
exception (mod throwing syntax)
so that the first case can be redefined without a warning, while
the second case would warn on redefinition.
I would guess again that the body of the sub not being actually
executed until the sub is called means that C... passes through
the compile phase without a problem. The compiler would have to
special-case it though, to allow the redefinition.
Perhaps not. If {...} evaluates to C(Code)(undef but something), the
transition from Cdefined(foo) == FALSE to Cdefined(foo) == TRUE
might not be grounds for a redef warning.
I'm going to assume that if you tried
my Int $number = ...;
$number = 5;
it would still die at run time on the first C I really hope it
would anyway, because if you really want to do something like that
we've already got Cundef.
This is wrong. The purpose of Cundef is I declare that I've thought
about the issue and at this point in the code $number should have no
value. The purpose of C... is I declare that there should be
something here, but I haven't thought about it yet.
IOW, C... is a form of literate programming that's relatively
self-explanatory and highly compatible with Agile development:
class foo {
has $.x = ...;
method bar() {...}
method baz($a)
{
if ($a)
{
.bar();
}
say Hello;
}
}
class foo_test
{
is UnitTestCase;
has $.foo;
method test_empty_baz()
{
$.foo = new foo;
$.foo.baz(undef);
}
}
This code should work okay -- no Yadda ever gets executed.
Then when I add:
method test_valid_baz()
{
$.foo = new foo;
$.foo.baz(1);
}
there should be a failure, because $.foo.baz calls $.foo.bar, which is
defined C{...}, which evaluates to an unspecified value exception.
[Question #1]
I'd like to understand how Aaron Sherman's initial example would
work:
class Foo {
has $.a;
has $.b;
...;
}
We know that the class will compile fine, but when exactly would it
pitch a fit (or exception)? I'm unsure of the meaning of this
idiom,
because the only time the C... line gets evaluated is at class
compilation time, which is when we don't want any complaints in
this case.
I thought class closures 'ran' at object creation time. I'm probably
wrong about that. Object creation time would be a good time for that
particular yada yada yada to start complaining though. I suspect
C... is going to be considerably more sophisticated than a macro
that replaces it with C{ die }.
I think the metaclass class assembler function will behave like this:
If only a Yadda is provided, just return a typed Yadda object.
If anything other than a Yadda:
If you provide a definition of any name, it goes in.
If you provide a Yadda, it gets recorded.
When wrapping up, if any methods are provided,
Re: Yadda yadda yadda some more
Austin Hastings wrote:
I think of this as very much like the typed-undef we discussed last
month or so: ... should return an unthrown exception wrapped in
undef-ness.
The type returned by ... should just have a multitude of type-casting
tricks associated:
my int $i = ...; # Fails at compile time -- no good conversion.
my Int $i = ...; # Warns at compile time, fails at runtime.
I don't get the reasoning here. If Yada Yada Yada is to indicate code
that you haven't written yet, it should never fail at compile time
unless it's impossible to compile the program without knowing what that
code is, so
my int $i = ...;
should compile. The problem would arise when you actually tried to run
that particular bit of code, which may well look to Parrot like 'die
horribly'.
If Yada Yada Yada is not to indicate code that you haven't written yet,
then what is it really for?
I would guess again that the body of the sub not being actually
executed until the sub is called means that C... passes through
the compile phase without a problem. The compiler would have to
special-case it though, to allow the redefinition.
Perhaps not. If {...} evaluates to C(Code)(undef but something), the
transition from Cdefined(foo) == FALSE to Cdefined(foo) == TRUE
might not be grounds for a redef warning.
That would make sense... if ... gave you an indefined code block (rather
than code which returns an undefined value, which we all know and love,
or at least I love it), it would actually make a LOT of sense.
I'm going to assume that if you tried
my Int $number = ...;
$number = 5;
it would still die at run time on the first C I really hope it
would anyway, because if you really want to do something like that
we've already got Cundef.
This is wrong. The purpose of Cundef is I declare that I've thought
about the issue and at this point in the code $number should have no
value. The purpose of C... is I declare that there should be
something here, but I haven't thought about it yet.
IOW, C... is a form of literate programming that's relatively
self-explanatory and highly compatible with Agile development:
class foo {
has $.x = ...;
method bar() {...}
method baz($a)
{
if ($a)
{
.bar();
}
say Hello;
}
}
class foo_test
{
is UnitTestCase;
has $.foo;
method test_empty_baz()
{
$.foo = new foo;
$.foo.baz(undef);
}
}
This code should work okay -- no Yadda ever gets executed.
Then when I add:
method test_valid_baz()
{
$.foo = new foo;
$.foo.baz(1);
}
there should be a failure, because $.foo.baz calls $.foo.bar, which is
defined C{...}, which evaluates to an unspecified value exception.
Yes, that's more or less as I would expect it to work.
I thought class closures 'ran' at object creation time. I'm probably
wrong about that. Object creation time would be a good time for that
particular yada yada yada to start complaining though. I suspect
C... is going to be considerably more sophisticated than a macro
that replaces it with C{ die }.
I think the metaclass class assembler function will behave like this:
If only a Yadda is provided, just return a typed Yadda object.
If anything other than a Yadda:
If you provide a definition of any name, it goes in.
If you provide a Yadda, it gets recorded.
When wrapping up, if any methods are provided, then a special
yadda-on-not-found dispatcher is provided. If no methods are
provided, a special yadda-on-not-inherited dispatcher is provided.
A similar data member access is provided.
So that:
class Foo {
has $.a;
has $.b;
...
}
Becomes:
class Foo {
AUTOMETH {
if inherited($method_name), run it.
else return sub {...};
}
has $.a;
has $.b;
AUTOMEMBER {
if inherited($member_name), return it.
else return \...;
}
}
So you can have objects made from class Foo, but if you try and get at a
method which doesn't exist you get Yada instead of 'that method doesn't
exist'... that makes sense, I think, because you can use any method
names you like in your code, and the effect is basically 'this method
hasn't been written yet'.
I would expect that to run and complain at compile time. That might
be irritating, but I'm not sure how else it could be done, because
BEGIN blocks are run then, and when they're run you need to know what
values you're going to assign to the variables.
Unless you gather it up inside some sort of lazy evaluation construct
that keeps delaying the evaluation of it until you hit run phase, at
which point you've probably got the entire BEGIN block ready to go,
with everything that comes after it also hanging around, and... no,
doesn't sound good does it?
Again, I like it. A partially defined object isn't fatal unless you
actually need that part.
If Yada is actually a value with a special type as you've said here,
then it falls out quite well. You can put it into anything you like, you
just get a problem the moment you
Re: Yadda yadda yadda some more
--- Matthew Walton [EMAIL PROTECTED] wrote: I don't get the reasoning here. If Yada Yada Yada is to indicate code that you haven't written yet, it should never fail at compile time unless it's impossible to compile the program without knowing what that code is, so my int $i = ...; Right. This goes back to the notion that lowercase basic types (int, str, bool) are storage efficient and therefore cannot contain values outside the domain, like Cundef. I've argued in the past that it should be possible to put undef into lctypes, to no avail. So, since no special values can go into lctypes, I presume this applies to Yadda as well -- trying to stuff a Yadda object into an lctype will result in a compile time (BEGIN time, more probably) failure. =Austin
Re: Yadda yadda yadda some more
[EMAIL PROTECTED] wrote: Austin Hastings wrote: my int $i = ...; # Fails at compile time -- no good conversion. my Int $i = ...; # Warns at compile time, fails at runtime. I don't get the reasoning here. If Yada Yada Yada is to indicate code that you haven't written yet, it should never fail at compile time unless it's impossible to compile the program without knowing what that code is, so my int $i = ...; should compile. The problem would arise when you actually tried to run that particular bit of code, which may well look to Parrot like 'die horribly'. Or. not so horribly. If I'm in the perl debugger, I'd want that to be a breakpoint and give me the option to type in a evaluable string to replace it. So it should throw a properly marked exception that an outer context can do something with. Good point.
Re: Yadda yadda yadda some more
On Fri, May 14, 2004 at 07:48:52AM -0700, Austin Hastings wrote: : : --- Matthew Walton [EMAIL PROTECTED] wrote: : I don't get the reasoning here. If Yada Yada Yada is to indicate : code that you haven't written yet, it should never fail at compile : time unless it's impossible to compile the program without knowing : what that code is, so : : my int $i = ...; : : Right. This goes back to the notion that lowercase basic types (int, : str, bool) are storage efficient and therefore cannot contain values : outside the domain, like Cundef. : : I've argued in the past that it should be possible to put undef into : lctypes, to no avail. So, since no special values can go into : lctypes, I presume this applies to Yadda as well -- trying to stuff a : Yadda object into an lctype will result in a compile time (BEGIN time, : more probably) failure. But the stuffing is not happening at compile time. Assignment happens at run time. Larry
Re: Yadda yadda yadda some more
Austin Hastings wrote: my int $i = ...; # Fails at compile time -- no good conversion. my Int $i = ...; # Warns at compile time, fails at runtime. I don't get the reasoning here. If Yada Yada Yada is to indicate code that you haven't written yet, it should never fail at compile time unless it's impossible to compile the program without knowing what that code is, so my int $i = ...; should compile. The problem would arise when you actually tried to run that particular bit of code, which may well look to Parrot like 'die horribly'. Or. not so horribly. If I'm in the perl debugger, I'd want that to be a breakpoint and give me the option to type in a evaluable string to replace it. So it should throw a properly marked exception that an outer context can do something with. -- Mark Biggar [EMAIL PROTECTED]
Re: Yadda yadda yadda some more (2)
Austin Hastings wrote:
Maybe this is how they'll teach perl at religious schools:
#! /usr/bin/perl6 -w
#
# TEMPLATE.P6 -- standard template for programs at Abstemious U.
#
use no ...;
sub usage() {...}
sub main() {...}
Aha, this is where the DWIM::AI module I suggested on 01-Apr comes in.
Create a template like the above and then DWIM::AI::Yadda will
join the dots and create the program for you !
R.
--
Richard Nuttall
Nuttall Consulting
01353 649878
www.nuttall.uk.net
Re: Yadda yadda yadda some more
--- Larry Wall [EMAIL PROTECTED] wrote: On Fri, May 14, 2004 at 07:48:52AM -0700, Austin Hastings wrote: : I've argued in the past that it should be possible to put undef : into lctypes, to no avail. So, since no special values can go : into lctypes, I presume this applies to Yadda as well -- trying : to stuff a Yadda object into an lctype will result in a compile : time (BEGIN time, more probably) failure. But the stuffing is not happening at compile time. Assignment happens at run time. Larry I don't know what I was thinking. Probably something about static vars. It's still invalid to try to fill an lctype with Yadda because of the domain issue, right? =Austin
Re: Yadda yadda yadda some more
On Fri, May 14, 2004 at 10:56:52AM -0700, Austin Hastings wrote: : It's still invalid to try to fill an lctype with Yadda because of the : domain issue, right? That's correct. It would in theory be possible to store a defined bit off to the side somewhere, but that pretty much defeats the purpose of having the lctypes in the first place. Larry
Re: Yadda yadda yadda some more
On Thu, 2004-05-13 at 15:35, Dov Wasserman wrote:
[Special Property #1]
If the Yada operator is valid anywhere a term is expected, it must
syntactically valid in all these cases:
my $id = ...;
Since I presume C... is going to be of type Object or whatever the
universal base class was (I think it was Object), this should compile
fine, and issue a run-time exception.
my Int age = ...;
Same deal. There WOULD be a small difference with:
my int $age = ...;
which is actually:
my int $age = (...).prefix:+();
which is still valid, and produces a run-time exception.
Therefore, the compile-time type of the term must be assignment-compatible
with any and all lvalues.
Easy enough.
[Special Property #2]
As mentioned in A6, redefining a function (subroutine, method, etc.) which
has only been declared with the Yada Yada Yada closure does not generate a
warning. It seems like Perl 6 will have to take some special note, then,
when we declare a function as:
sub foo($bar, $baz) {...}; # pre-declaring sub foo()
Yes, that would have to be a special-case, and that means that ... is
smarter that just a macro (or perhaps that subroutine definition is
smarter than I'm giving it credit for. No biggie.
[Question #1]
I'd like to understand how Aaron Sherman's initial example would work:
class Foo {
has $.a;
has $.b;
...;
}
We know that the class will compile fine, but when exactly would it pitch a
No we don't know that, but I think it's fair to say that class should
probably catch the Yadda exception, and define the metaclass with some
kind of property like $thenewclass.meta does Exception::Yadda or
something like that.
[Question #2]
Does C... know when it's being called during compilation and when it's
being used at run-time? I.e., how would it behave in a compile-time block
such as BEGIN:
BEGIN { our IO $server = ...; };
No, I don't think it should know or care. BEGIN should probably
propagate the exception (or just ignore it), since there's no graceful
way to recover here.
The rhs value is evaluated here at compile-time. Is C... smart enough to
know that and keep quiet?
I don't see the value in keeping it quiet. You've already executed the
code the one and only time you're going to, there's no sense in not
throwing the exception.
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Yadda yadda yadda some more
On Fri, 2004-05-14 at 10:48, Austin Hastings wrote:
my int $i = ...;
Right. This goes back to the notion that lowercase basic types (int,
str, bool) are storage efficient and therefore cannot contain values
outside the domain, like Cundef.
Nope, not at all.
You can say:
my int $i = $complex_high_level_cool_object;
any time you like, and that should compile clean (unless the object does
something special at compile-time to exclude such a conversion from even
being attempted).
The question I have is: how do classes control their conversion? In C++
you can overload the casting operator for any time and/or define a
constructor for the receiving type.
I can imagine how you would define the constructor on the receiving type
in Perl 6, but there's no casting syntax in Perl 6. Should we pretend
there is for purposes of defining a conversion and allow:
class foo {
...
sub prefix:IO::Socket(foo $f) returns(IO::Socket) {...}
}
or did Larry mention a way to define a converter and I missed it?
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Yadda yadda yadda some more
Aaron Sherman wrote:
I can imagine how you would define the constructor on the receiving type
in Perl 6, but there's no casting syntax in Perl 6. Should we pretend
there is for purposes of defining a conversion and allow:
class foo {
...
sub prefix:IO::Socket(foo $f) returns(IO::Socket) {...}
}
or did Larry mention a way to define a converter and I missed it?
From A12:
**
New Grammatical Categories
The current set of grammatical categories for operator names is:
CategoryExample of use
--
coerce:as 123 as BigInt, BigInt(123)
self:sort @array.=sort
term:...$x = {...}
prefix:++$x
infix:+ $x + $y
postfix:++ $x++
...
**
It's not exactly clear how that's used, considering that you can't do
multi-dispatch on the return type (right?)...perhaps like
multi sub coerce:as(Int $dest is rw, MyObj $src) {...}
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Re: Yadda yadda yadda some more
Aaron Sherman writes:
The question I have is: how do classes control their conversion? In C++
you can overload the casting operator for any time and/or define a
constructor for the receiving type.
I can imagine how you would define the constructor on the receiving type
in Perl 6, but there's no casting syntax in Perl 6. Should we pretend
there is for purposes of defining a conversion and allow:
class foo {
...
sub prefix:IO::Socket(foo $f) returns(IO::Socket) {...}
}
or did Larry mention a way to define a converter and I missed it?
Yep, that's what happened. See Apocalypse 12 under Overloading.
Specifically, it's defined by the operator coerce:as. So:
class Foo {...}
multi sub *coerce:as (Foo $foo, ::Bar $class) {
say Converting to $class.name()
}
my Bar $bar = Foo.new; # Converting to Bar
You can do it explicitly, too:
my $bar = Foo.new as Bar;
Luke
Re: Yadda yadda yadda some more
On Thu, May 13, 2004 at 08:02:13AM +0100, Matthew Walton wrote: : Larry Wall wrote: : : On Wed, May 12, 2004 at 11:37:44PM +0200, Juerd wrote: : : Aaron Sherman skribis 2004-05-12 17:30 (-0400): : : I like C... I like it a LOT. In fact, I'm partial to the idea that : : it should be usable anywhere : : : : I agree. It'd make even more of my pseudo code (#perlhelp and : : perlmonks.org) valid syntax :). : : Er. Why are you guys using the subjunctive? : : Straining my brain to remember what the subjunctive is (and I only ever : learned it in German anyway), does that mean that this use of yada yada : yada is already decided on and allowed? Yes, with the proviso that it only works that way where a term is expected. (As a postfix operator it's short for C..Inf.) : If so, fantastic. Glad you like it. Larry
Re: Yadda yadda yadda some more
Larry Wall wrote: On Wed, May 12, 2004 at 11:37:44PM +0200, Juerd wrote: : Aaron Sherman skribis 2004-05-12 17:30 (-0400): : I like C... I like it a LOT. In fact, I'm partial to the idea that : it should be usable anywhere : : I agree. It'd make even more of my pseudo code (#perlhelp and : perlmonks.org) valid syntax :). Er. Why are you guys using the subjunctive? Straining my brain to remember what the subjunctive is (and I only ever learned it in German anyway), does that mean that this use of yada yada yada is already decided on and allowed? If so, fantastic.
Re: Yadda yadda yadda some more
Aaron Sherman skribis 2004-05-12 17:30 (-0400): I like C... I like it a LOT. In fact, I'm partial to the idea that it should be usable anywhere I agree. It'd make even more of my pseudo code (#perlhelp and perlmonks.org) valid syntax :). Juerd
Re: Yadda yadda yadda some more
On Wed, May 12, 2004 at 11:37:44PM +0200, Juerd wrote: : Aaron Sherman skribis 2004-05-12 17:30 (-0400): : I like C... I like it a LOT. In fact, I'm partial to the idea that : it should be usable anywhere : : I agree. It'd make even more of my pseudo code (#perlhelp and : perlmonks.org) valid syntax :). Er. Why are you guys using the subjunctive? Larry
