Re: Prototypes

[Bryan C . Warnock]

On Sunday 02 September 2001 07:49 pm, Dan Sugalski wrote:
> On Sun, 2 Sep 2001, Bryan C. Warnock wrote:
> > Are prototypes going to be checked at runtime now?
>
> For methods, at least. Dunno about subs, that's Larry's call. I could make
> a good language case for and against it. It adds overhead on sub calls,
> which is a bad thing generally. (I'd be OK with the declaration "All
> prototyped subs must have their prototypes known before the BEGIN phase is
> done"... :)

Well, here's a simple, yet stupid, idea.  (And I'd be content with having 
prototype declarations being a compile-time only requirement, too.)

Code injection, a la Perl's -p and -n switch.

sub foo (protoype) {
code
}

is compiled as

sub foo { {
my $proto = prototype;
# prototype checking code here.  Must be non-destructive on @_
}
code
}

- It only affects the specific subroutines that declared prototypes in the 
first place.  

- With the ability to inject lexical variables up a scope, prototype 
assignment would work...

sub foo (my $bar, my Dog $baz, my @array) {
# $bar, $baz, and @array are all visible
}

- It's certainly pluggable.  It could even be written in Perl.  That means 
powerful prototyping capabilities.

- Automagically works with named subs and code references, subroutine 
replacement a la 'goto &cref', and any other way you could think of calling 
the subroutine.

- If the subroutine is ever replaced, the prototypes magically go away.  (Or 
are replaced by ones in the new code.)

- It could be standard enough (from an opcode generation perspective, that 
B::Deparse would be able to reconstruct the original subroutine code.

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: Prototypes

[Dan Sugalski]

On Sun, 2 Sep 2001, Bryan C. Warnock wrote:

> Are prototypes going to be checked at runtime now?

For methods, at least. Dunno about subs, that's Larry's call. I could make
a good language case for and against it. It adds overhead on sub calls,
which is a bad thing generally. (I'd be OK with the declaration "All
prototyped subs must have their prototypes known before the BEGIN phase is
done"... :)

Dan

Re: LangSpec: Statements and Blocks [first,last]

[Bryan C . Warnock]

On Sunday 02 September 2001 06:27 pm, raptor wrote:
> ]- yep I didn't thougth about that I can be sure I'm at the last
> iteration only with some sort of 'callback' which will be called at the
> exit of the loop... but not as some sort of generalised-check condition..

Umm, it's simpler than that.

iterator (list) {
code;
}
# <- If you are here, you just completed your last iteration.
# (Unless you goto'd somewhere else, obviously.  But that would
# skip the callback, too.)

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: Prototypes

[Bryan C . Warnock]

On Sunday 02 September 2001 08:18 pm, Michael G Schwern wrote:
> On Sun, Sep 02, 2001 at 07:47:37PM -0400, Bryan C. Warnock wrote:
> > Are prototypes going to be checked at runtime now?
> >
> > The following parses, but doesn't do anything, including warn.
> >
> > my $a = sub ($) { print };
>
> Warning because you said you take an argument and then did nothing
> with it... that could be useful (I can actually think of a few
> situations where you'd want to do that, but they're rare) but it would
> involve scanning the subroutine at compile time to see if you use @_
> and what bits of it you use and if they're the right bits, etc...
>
>
> But since the current prototyping system... has a highly positive
> pressure gradient compared to the surrounding air, hopefully we
> won't be saddled with it in Perl 6 and will be able to write something
> more sensible, like RFC 57 suggests:
>
> my $a = sub ($foo) { print }
>
> then it's simply a matter of seeing if that declared variable is ever
> used in the sub.

Oh.  That's not even what I was talking about, but I see your point.  I 
shall file that question away for later.

I was referring to the prototype not being checked at all.

my $a = sub ($) { my $b = shift; print $b, "\n" };
$a->();

Nothing (other than the undefinedness of $b).  I would expect either
   a) a prototype mismatch error, or
   b) A "prototype is useless with an anonymous subroutine" warning.






-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: LangSpec: Statements and Blocks [first,last]

[raptor]

| I don't know if (and if so, how) you would see if you were on the last
| iteration.  (And would that be last, as in the very last argument passed
in,
| or last, as in you're not going to iterate again?)
]- yep I didn't thougth about that I can be sure I'm at the last
iteration only with some sort of 'callback' which will be called at the exit
of the loop... but not as some sort of generalised-check condition..
=
iVAN
[EMAIL PROTECTED]
=

Re: Prototypes

[Michael G Schwern]

On Sun, Sep 02, 2001 at 07:47:37PM -0400, Bryan C. Warnock wrote:
> Are prototypes going to be checked at runtime now?
> 
> The following parses, but doesn't do anything, including warn.
> 
> my $a = sub ($) { print };

Warning because you said you take an argument and then did nothing
with it... that could be useful (I can actually think of a few
situations where you'd want to do that, but they're rare) but it would
involve scanning the subroutine at compile time to see if you use @_
and what bits of it you use and if they're the right bits, etc...


But since the current prototyping system... has a highly positive
pressure gradient compared to the surrounding air, hopefully we
won't be saddled with it in Perl 6 and will be able to write something
more sensible, like RFC 57 suggests:

my $a = sub ($foo) { print }

then it's simply a matter of seeing if that declared variable is ever
used in the sub.


-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]>   Kwalitee Is Job One
I'm not actually Kevin Lenzo, but I play him on TV.

Prototypes

[Bryan C . Warnock]

Are prototypes going to be checked at runtime now?

The following parses, but doesn't do anything, including warn.

my $a = sub ($) { print };

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Redo the next to last goto (was Re: LangSpec: Statements and Blocks)

[Bryan C . Warnock]

A thread from last July, WRT bug ID 2717.003 [1], suggested that we may 
want to revisit the behavior of flow control expressions within the context 
of a subroutine. 

The current behavior is to find the closest (labelled) enclosing loop 
(dynamically, not lexically), and treat that as the target for the flow 
control expression - unwinding any stacks necessary.  It does 
produce a warning with '-w'.

The following code demonstrates:

#!/usr/bin/perl -w
$a = 'a'; $c = 0;

sub frok {
return gork(@_);
}

sub gork {
my ($a) = @_;
redo if $a eq 'd' && ! $c++;
next if $a eq 'h';
last if $a eq 'o';
return ++$a;
}

while ( $a++ ) {
print "1. $a\n";
$a = frok($a);
print "2. $a\n";
}
continue {
print "3. $a\n";
}

print "Done\n";

The suggested alternative was to treat loop control expressions which would 
exit the subroutine to be equivalent to 'return;'

The main argument against the current behavior related to "action at a 
distance", and code needing to protect itself from poorly written callbacks.

FWIW, here's my opinion.  (I'm in favor of the current behavior.)

1) The current behavior, however heinous, actually has a use.  There's no 
value added in having five ways to return undef.

2) It reflects the intended use.  The programmer was most likely trying to 
execute *some* form of loop control, however misguided they may have been.  
Perhaps the subroutine was originally code in a larger loop, and the code 
was shuffled off to a subroutine to make the loop simpler.  Perhaps the 
coder mistakenly thought the subroutine was a loop.  The current behavior 
allows the preservation of the first if it were intended, and warns on the 
second, if it weren't.

Most likely, if a coder intends to return, they actually return.  Granted, 
there's an implicit return off the end of a function, and perhaps the coder 
thought 'last' may get them there.  But instead of returning the value of 
the last statement, you return nothing.  And with no warning.  And that 
helps 'last', but not the other three. 'next' is nonsensical, 'redo' even 
more so, and a 'goto' that doesn't just doesn't seem right.

3) It's consistent.  The same behavior currently happens within an eval 
block.  If you were to define 'return;', you'd have to also redress eval 
behavior.

Does anyone wish to argue for any other behavior, or may we consider this 
revisited?
  
[1] http://www.mail-archive.com/perl5-porters@perl.org/msg12899.html
-- 
Bryan C. Warnock
[EMAIL PROTECTED]

RE: LangSpec: Statements and Blocks [first,last]

[Sterin, Ilya]

> -Original Message-
> From: raptor [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, September 02, 2001 1:47 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: LangSpec: Statements and Blocks [first,last]
>
>
> hi,
>
> As we read in Damian Conway- Perl6-notes, there will by a
> var-iterator that
> can be used to see how many times the cycle has been "traversed" i.e.
>
> foreach my $el (@ary) {
>.. do something 
>  print $#;  <--- print the index (or print $i )
> }
>
> shall we have :
>
> foreach my $el (@ary) {
>  print $# if $#.first();  <--- print the index on the first iteration

I personally don't like the .first() .last() method implementation, this
means we'll have .second .third, etc...  Why not just check the var iterator
$# == 0, means the first iteration, or have a special var that is not set to
the index, but rather the iteration number 1..end, in case the there is a
way to start iteration at different points.

Ilya


> i.e. 1
>.. do something 
>  print $# if $#.last();  <--- print the index on the first iteration
> i.e. $#ary
> };
>
> note : we can iterate on something else not only array
> OR :
>
> foreach my $el (@ary) {
>  print $# if first;
>.. do something 
>  print $# if latest;
> };
>
>
> =
> iVAN
> [EMAIL PROTECTED]
> =
> PS. One place where TT is before Perl :")
>

Re: LangSpec: Statements and Blocks [first,last]

[Bryan C . Warnock]

On Sunday 02 September 2001 01:47 pm, raptor wrote:
> As we read in Damian Conway- Perl6-notes, there will by a var-iterator
> that can be used to see how many times the cycle has been "traversed" i.e.
>
> foreach my $el (@ary) {
>.. do something 
>  print $#;  <--- print the index (or print $i )
> }
>
> shall we have :
>
> foreach my $el (@ary) {
>  print $# if $#.first();  <--- print the index on the first iteration

I think it's just a simple counter.

print $# if $# == 0;

> i.e. 1

0

>.. do something 
>  print $# if $#.last();  <--- print the index on the first iteration

I don't know if (and if so, how) you would see if you were on the last 
iteration.  (And would that be last, as in the very last argument passed in, 
or last, as in you're not going to iterate again?)

-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: LangSpec: Statements and Blocks [first,last]

[raptor]

hi,

As we read in Damian Conway- Perl6-notes, there will by a var-iterator that
can be used to see how many times the cycle has been "traversed" i.e.

foreach my $el (@ary) {
   .. do something 
 print $#;  <--- print the index (or print $i )
}

shall we have :

foreach my $el (@ary) {
 print $# if $#.first();  <--- print the index on the first iteration
i.e. 1
   .. do something 
 print $# if $#.last();  <--- print the index on the first iteration
i.e. $#ary
};

note : we can iterate on something else not only array
OR :

foreach my $el (@ary) {
 print $# if first;
   .. do something 
 print $# if latest;
};


=
iVAN
[EMAIL PROTECTED]
=
PS. One place where TT is before Perl :")

Re: !< and !>

[raptor]

|
| > !<  and !>
|
| How is !< different from >=?

]- the way of Expression or syntax-sugar if u like it :"), and is faster to
prononce :")

if, if not, unless
bigger, smaller, equal
less than or equal, bigger than or equal
not bigger, not smaller  ...etc.

Personally I almost always make error when type '>=',  my hands go faster
and I write '=>' insteadnot that this matter much..
=
iVAN
[EMAIL PROTECTED]
=

Re: !< and !>

[Ken Fox]

"Bryan C. Warnock" wrote:
> I'm waiting for someone to say that in tri-state logic, '!<' != '>='

That's what I thought it was. "$a !< $b" might be "!defined($a) || $a >= $b".
In SQL this is "$a IS NULL or $a >= $b".

- Ken

Re: Multiple-dispatch on functions

[Ken Fox]

Damian Conway wrote:
> Ken wrote:
>> The one thing I'm curious about is whether different syntactic
>> conventions affect the dispatcher or whether this is all just
>> sugar for a single dispatch.
> 
> Multiple dispatch is certainly not (practically) implementable via single
> dispatch.

Oops. I meant "sugar for one implementation of dispatch."

We could eliminate single dispatch and *only* use multi-dispatch.
The ":multi" attribute would just turn off the default behavior of
replacing an existing function.

> The only internal difference is that the first version has to do the
> normal Perl single dispatch look-up before it discovers that

Right. What if there wasn't a single dispatcher?

I think multi dispatch could eliminate single dispatch if we looked
for function matches in the current lexical scope *and* in the @ISA
packages for every argument.

Multi-dispatch is just as fast as single dispatch if only a single
function matches. The compiler could easily keep track of this.

- Ken

RE: !< and !>

[Sterin, Ilya]

> -Original Message-
> From: Russ Allbery [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, September 02, 2001 8:42 AM
> To: [EMAIL PROTECTED]
> Subject: Re: !< and !>
>
>
> Bart Lateur <[EMAIL PROTECTED]> writes:
>
> > Why is it ">=" and not "=>"?
>
> Because in English, it's "less than or equal to" not "equal to or less
> than," I presume.
>
> > Simply trying to remember the order of characters might be (a bit of) a
> > pain. That problem doesn't exist with "!<" and "!>".
>
> Every other programming language I've ever seen uses >= and <=.  I think

This is Perl.  Why should it be like every other langage?  what happens to
innovation?

> adding additional comparison operators not found in any other language and
> identical to (and harder to type than!) existing operators is a really bad
> idea.

I don't see anything bad about, don't like it don't use it.  I can tell you
quite a few things I don't particularly like in Perl, but what I like is
more than one way of doing things, so I choose my preference.  I can't
recall a langage with unless() either, but sure help is exression writting
sometimes.

Ilya

>
> --
> Russ Allbery ([EMAIL PROTECTED])
> 

Re: !< and !>

[Russ Allbery]

Bart Lateur <[EMAIL PROTECTED]> writes:

> Why is it ">=" and not "=>"?

Because in English, it's "less than or equal to" not "equal to or less
than," I presume.

> Simply trying to remember the order of characters might be (a bit of) a
> pain. That problem doesn't exist with "!<" and "!>".

Every other programming language I've ever seen uses >= and <=.  I think
adding additional comparison operators not found in any other language and
identical to (and harder to type than!) existing operators is a really bad
idea.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: LangSpec: Statements and Blocks

[Bryan C . Warnock]

On Sunday 02 September 2001 12:48 am, Uri Guttman wrote:
>
> i don't consider sort/map/grep blocks to be basic like the others. also
> sort/map can take espressions which is a different syntax.

Yes, I'm not addressing sort/map/grep/do as much as demonstrating a block 
that appears in one of those expressions.  I will note that.  They were 
grouped within basic constructs because, well, frankly I didn't have 
anywhere else to put them.  (Block Expressions, perhaps?)

>
> what about eval BLOCK? i think that is being renamed to throw/catch but
> it takes a code block too.

Yep.  Missed it.  And that's a big one.

>
>   BCW> Conditional Statement Modifiers
>
>   BCW>  6. [ LABEL: ] expr if expr;
>   BCW>  7. [ LABEL: ] expr until expr;
>^
> unless

Thanks.

>
>   BCW> Looping Statement Modifiers
>
>   BCW>  8. [ LABEL: ] expr while expr;
>   BCW>  9. [ LABEL: ] do { block } while expr;# Note 2
>
> i see the note, but that is not special. just a simple expression with a
> modifier. now, if the do BLOCK while() were to support loop semantics,
> it would be special here.

Evaluation order.

>
>   BCW> 10. [ LABEL: ] expr until expr;
>   BCW> 11. [ LABEL: ] do { block } until expr;# Note 3
>
>
>   BCW> Iterative Statement Modifiers
>
>   BCW> 12. [ LABEL: ] expr for[each] list;# Note 4
>
>
>   BCW> Conditional Block Constructs
>
>   BCW> 13. [ LABEL: ] if ( expr ) { block }
>   BCW>[ [ elsif  ( expr ) { block } ] ... ]
>   BCW>[ else  { block } ]
>   BCW> 14. [ LABEL: ] until ( expr ) { block }
>   ^
>
> unless (again :-)

Ugh.  What was I on?

>
>
>
>   BCW> A statement consists of zero or more expressions, followed by an
>   BCW> optional modifier and its expression, and either a statement
>   BCW> terminator (';') or a block closure ('}' or EOF).
>
> how do you have multiple expressions in a statement? when you combine
> expressions you just get one larger expression.

I was specifically addressing the statement modifiers (trailing ifs, 
UNLESSes, whiles, etc.).  The modifiers themselves aren't really 
expressions although they take them.  If they were, then
'expr if expr while expr' would be legal. 

>
> also perl has statement separators, not terminators. with that
> definition you don't need to mention block close or EOF.

I never really thought about it that way.  Excellent point.  I shall make 
that change.

>
>   BCW> Flow Control Expressions
>
>   BCW> A. goto
>   BCW> B.
>
> B. was intentionally left blank.

I got tired.  :-)


-- 
Bryan C. Warnock
[EMAIL PROTECTED]

Re: !< and !>

[Bart Lateur]

On 01 Sep 2001 14:40:40 -0700, Russ Allbery wrote:

>Sterin, Ilya <[EMAIL PROTECTED]> writes:
>>> From: Russ Allbery [mailto:[EMAIL PROTECTED]]
>
>>> How is !< different from >=?
...

>It's the same number of characters.  How can it be more convenient?

Why is it ">=" and not "=>"? Why "=<" and not "<="? Simply trying to
remember the order of characters might be (a bit of) a pain. That
problem doesn't exist with "!<" and "!>".

-- 
Bart.