"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<.
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 com
--- 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 a
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 ti
--- 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 = ...;
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 fa
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
> 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 a
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 com
--- 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
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 purpo
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 w
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 C.
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 prefix:IO::Sock
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 t
16 matches
Mail list logo
