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
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
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
--- 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
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
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(...,
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
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
I actually find myself having somewhat coherent thoughts on this matter.
Apologies if they seem rather obvious or naive, but I'm still new to all
this.
Dov Wasserman wrote:
my $id = ...;
my Int age = ...;
my Str $name = ...;
my DbHandle $db = ...;
my Int of Hash @array = ...;
Therefore, the
--- 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
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
Sorry for the broken reply, but my webmailer makes my life difficult.
--- Matthew Walton [EMAIL PROTECTED] wrote:
Might be nice to have a small checker that you can use on production
=== message truncated ===
Yes. Of course, I fully expect that according to the principle of
maximal surprise,
[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
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
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
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
--- 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
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
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
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
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
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
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
:
I like C...
I like it a LOT.
In fact, I'm partial to the idea that it should be usable anywhere:
class {
has $.a;
has $.b;
...;
}
or
my Foo $a = ...; # Ask Bob what this should be -Bill
In all cases, I'm a fan of C...
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
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
26 matches
Mail list logo
