Damian Conway <[EMAIL PROTECTED]> writes:

> Piers wrote:
>
>> Over on use.perl, someone spotted what looks like a bug in the example
>> program which (if it *is* a bug) is fixed by using unary '*', but
>> that's not what I'm writing about here.
>
> I'll admit I'm not sure whether it is a bug or not. I've asked Larry for
> clarification and will post an update as soon as he responds.

Good oh. BTW, (and apologies for repeating the question I asked
elsewhere) are we going to see an updated Apocalypse 4 incorporating
all the changes made to get E4 to work?

>> In the discussion of the yadda yadda yadda operator, Damian says that
>> 
>>    ... in this example, Err::BadData is *never* completely defined. So
>>    we'd get a fatal compile-time error ...
>> 
>> Surely it would be better to make it a 'CHECK' time error (or whatever
>> CHECK's equivalent will be in perl 6. ie, it happens after compilation
>> has finished, but before runtime starts. That way, the likes of
>> B::Deparse can still do useful work.
>
> Well, I consider C<CHECK> to be part of of compile-time,
> so I don't think we're disagreeing. :-)

Heh. Okay.

>> Also, some sort of pragmatic control would be nice, say
>> 
>>    use incomplete;
>
> or perhaps:
>
>       no strict 'definitions'.

Ah, now that's better.

>>        when IgnoreableException {
>>            redo; # Hmm... how do I say 'redo the block containing the
>>                  # block containing the block containing the redo'?
>>                  # Labels are one way I guess, but how about 'redo 2'
>>                  # meaning 'go up two blocks from here'
>>        }
>>    }
>
> As described in E4, you make the block containing the block
> containing the block containing the C<redo> a C<loop> block (or a
> labelled block).

Dang, being able to redo arbitrary blocks would be really neat. Though
possibly scary to implement...

>> Then one could also use
>> 
>>     method abstract_method {...}
>> 
>> in abstract, or semi abstract class definitions, then again
>> 
>>     method abstract_method is abstract;
>> 
>> might well be a better bet, but that depends on whether a method
>> definition without a block is going to be legal syntax in perl 6 (and
>> reading between the lines of E4, I don't think it will be).
>
> Larry indicated to me that blockless declarations of methods and subs
> would be illegal. So you'd probably have to write:
>
>       method abstract_method is abstract {...}
>
> And the C<is abstract> would absolve your method from the
> compile-time "method 'abstract_method' was never defined" error.

That makes sense. Solves the 'intention revealing code' problem quite
neatly too; you don't have to worry about whether a particular
C<method foo {...}> was left unfinished by the coder or whether it's
*deliberately* unfinished and is actually an abstract method. (Yeah, I
know you can use a comment, but I prefer executable comments like C<is
abstract>, which can survive perl -MO=Deparse)

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

Reply via email to