Re: RFC 168 (v1) Built-in functions should be functions
Tom Christiansen wrote: I don't know what's happening with indirect objects, but the nastiness whereby you can only use unsubscripted scalars is quite the crock. You know, where you can say print $fh "stuff\n"; and $fh But are not (well, in the second you can, but it's wrong) able to say print $fh[$i] "stuff\n"; and $fh[$i] Definitely worth a clean-up--at the least. Definitely! I'm not sure if this is the cause, or even related, but when the prototype is \$, only an actual scalar variable can be passed, when actually any scalar, or at least any reffable scalar, should be allowable. -- John Porter We're building the house of the future together.
Re: RFC 168 (v1) Built-in functions should be functions
Damian Conway wrote:
I intend to extend the parameter lists RFC to cover optional
(non-tailing) arguments. Personally, I would like to see the
indirect object syntax removed in all contexts, inclusing
this one, and filehandles simply passed as a first argument.
Well, "indirect object syntax", maybe; but then, eh...
comma-less-ness can be very nice in many situations.
I think this should be allowable whenever it's unambiguous to
the compiler, based on the prototype. IOW, given
sub foo($$$);
should not the following be legal?
foo $x ( $y, $z ) { ... }
--
John Porter
We're building the house of the future together.
Re: RFC 168 (v1) Built-in functions should be functions
Tom Christiansen [EMAIL PROTECTED] writes: I intend to extend the parameter lists RFC to cover optional (non-tailing) arguments. Will this include having typed variadic functions, allowing you, for example, to say something like This function takes any number of arrays, all passed by reference. I keep thinking of a * or a ... to say "repeat the previous thing", but that's stepping on other toes. Doesn't that tend to lead us in the direction of pack madness where we end up with yet another 'sub language' within perl. We've already got pack specifiers and regexen and the 'old' prototyping stuff. I'm not arguing *against* these things you understand, I'm just vaguely worried. -- Piers
Re: RFC 168 (v1) Built-in functions should be functions
Peter Scott [EMAIL PROTECTED] writes: I think you can't just leave it at that; the implication of this requirement is that there should be a prototype for print's optional filehandle. I count on Larry's promise to do something about the indirect object stuff. -- Johan
Re: RFC 168 (v1) Built-in functions should be functions
John Porter [EMAIL PROTECTED] writes: Damian Conway wrote: Well, as I mentioned in another recent parallel thread, if Cfor is to be properly functionalized, I deliberately stated "built-in functions", not "keywords". Please consult Tom's list and my addendum: Tom Christiansen [EMAIL PROTECTED] writes: Keywords that *cannot* be overridden are chop, defined, delete, do, dump, each , else, elsif, eval, exists, for, foreach, format, glob, goto, grep, if, keys, last, local, m, map, my, next, no, package, pop, pos, print, printf, prototype, push, q, qq, qw, qx, redo, return, s, scalar, shift, sort, splice, split, study, sub, tie, tied, tr, undef, unless, unshift, untie, until, use, while, and y. Johan Vromans added: Hmm. Quite a few of these should no longer be special: chop, defined, delete, dump, each, exists, glob, grep, keys, map, pop, pos, print, printf, prototype, push, scalar, shift, sort, splice, split, study, tie, tied, undef?, unshift, untie. -- Johan
RE: RFC 168 (v1) Built-in functions should be functions
John Porter writes: Ah, the old "If you want Tcl, you know where to find it" non-argument. "Closures?""No! This is Perl, not Lisp!" "Objects?" "No! This is Perl, not Smalltalk!" "Patterns?""No! This is Perl, not Snobol!" "Subroutines?" "No! This is Perl, not Basic!" "Upvars?" "No, and for the following well-understood technical reasons..." Well, I for one don't understand what is to be gained by making control structures into functions. Could you please give us some examples where control structure functions would be significantly more powerful than the current control structures? Mark Leighton FisherThomson Consumer Electronics [EMAIL PROTECTED] Indianapolis, IN, USA "Display some adaptability." -- Doug Shaftoe, _Cryptonomicon_
Re: RFC 168 (v1) Built-in functions should be functions
Doesn't that tend to lead us in the direction of pack madness where we end up with yet another 'sub language' within perl. We've already got pack specifiers and regexen and the 'old' prototyping stuff. I'm not arguing *against* these things you understand, I'm just vaguely worried. As you have observed, nestled lightly within the language of Perl there are many sub-languages. I don't know how to have a rich and powerful enough prototype syntax without well, inventing some syntax, you know? :-) Now, it may be that [such prototypes] are not desirable. But that's another matter. I think it's valuable to be able to say "this function takes any number of BLAH", where BLAH might be something like "arrays that will be passed by reference". I don't mean any number of hashes, scalars, or whatnot. Given that, one must come up with something. I'm sure Damian will have it tastefully covered. --tom
Re: RFC 168 (v1) Built-in functions should be functions
Tom Christiansen wrote: Well, as I mentioned in another recent parallel thread, if Cfor is to be properly functionalized, Whoa -- why? Syntax keywords (eg if, unless) certainly need not be expressible as functions.This isn't tcl! Ah, the old "If you want Tcl, you know where to find it" non-argument. "Closures?""No! This is Perl, not Lisp!" "Objects?" "No! This is Perl, not Smalltalk!" "Patterns?""No! This is Perl, not Snobol!" "Subroutines?" "No! This is Perl, not Basic!" "Upvars?" "No, and for the following well-understood technical reasons..." -- John Porter
Re: RFC 168 (v1) Built-in functions should be functions
Tom Christiansen wrote: Well, as I mentioned in another recent parallel thread, if Cfor is to be properly functionalized, Whoa -- why? Syntax keywords (eg if, unless) certainly need not be expressible as functions.This isn't tcl! Ah, the old "If you want Tcl, you know where to find it" non-argument. "Closures?""No! This is Perl, not Lisp!" "Objects?" "No! This is Perl, not Smalltalk!" "Patterns?""No! This is Perl, not Snobol!" "Subroutines?" "No! This is Perl, not Basic!" Fine. Explain why it is that a syntactic keyword governing normal flow of control, such as for, foreach, if, while, return, next, etc., should have the properties of a function. For example, Why should it be referenceable, as in \CORE::if? What does dereferencing it mean? How can the compiler do what the compiler has to do if you hide it? Why should it have a prototype? What are you going to do with that prototype? Why should it be overridable? What are you planning to to with it? What are you going to do about things like if/elsif/elsif/.../else? I see nothing broken. Yet. --tom
Re: RFC 168 (v1) Built-in functions should be functions
One function that takes an optional leading commaless arg: sub print(handle? $FH, @) or Two functions differentiated by their prototypes sub print(@); sub print(handle,@); I'm always forgetting the comma after the handlename in Copen statements because I learned "no comma after file handle names" for Cprint We could rectify this situation by giving Copen the same header.
Re: RFC 168 (v1) Built-in functions should be functions
I intend to extend the parameter lists RFC to cover optional (non-tailing) arguments. Will this include having typed variadic functions, allowing you, for example, to say something like This function takes any number of arrays, all passed by reference. I keep thinking of a * or a ... to say "repeat the previous thing", but that's stepping on other toes. Personally, I would like to see the indirect object syntax removed in all contexts, inclusing this one, and filehandles simply passed as a first argument. I don't know what's happening with indirect objects, but the nastiness whereby you can only use unsubscripted scalars is quite the crock. You know, where you can say print $fh "stuff\n"; and $fh But are not (well, in the second you can, but it's wrong) able to say print $fh[$i] "stuff\n"; and $fh[$i] Definitely worth a clean-up--at the least. --tom
Re: RFC 168 (v1) Built-in functions should be functions
Basically, it "fixes" the indirect notation by making all of these Do The Right Thing: $r = new CGI (@args); # CGI-new(@args) $r = new(CGI, @args); # CGI-new(@args) $r = new(CGI @args); # CGI-new(@args) It's all in the details (I'm sure you see the edge cases already, but they're addressed), so I invite people to read it. I posted it to -subs. That's hardly the problem with indirect object syntax. Besides what I just mentioned, there is the fact that it's acting in a fashion that you could call stronger than a unary operator in terms of precedence. --tom
Re: RFC 168 (v1) Built-in functions should be functions
I intend to extend the parameter lists RFC to cover optional (non-trailing) arguments. Will this include having typed variadic functions, allowing you, for example, to say something like This function takes any number of arrays, all passed by reference. I keep thinking of a * or a ... to say "repeat the previous thing", but that's stepping on other toes. Yes, I'll definitely be including that facility. Personally, I would like to see the indirect object syntax removed in all contexts, including this one, and filehandles simply passed as a first argument. I don't know what's happening with indirect objects, but the nastiness whereby you can only use unsubscripted scalars is quite the crock. Definitely worth a clean-up--at the least. At least. Damian
Re: RFC 168 (v1) Built-in functions should be functions
Tom Christiansen wrote: That's hardly the problem with indirect object syntax. Besides what I just mentioned, there is the fact that it's acting in a fashion that you could call stronger than a unary operator in terms of precedence. This is also mentioned in the RFC, although probably not clearly enough. I also wasn't claiming to fix *the* problem, just *a* problem. If you read the RFC, I think you'll see this opens doors to a lot of benefits. It probably has to be fleshed out considerably, but I'm sure the people on -subs will definitely be able to help there. -Nate
Re: RFC 168 (v1) Built-in functions should be functions
At 07:32 PM 8/27/00 +, Perl6 RFC Librarian wrote:
=head2 Prototypes
Currently, several built-ins do not provide prototype information.
prototype("CORE::abs") == ;$
prototype("CORE::shift") == undef
This must be fixed. One might even call this a bug, although the
current prototype mechanism is not powerful enough to cope with all
built-ins.
I think you can't just leave it at that; the implication of this
requirement is that there should be a prototype for print's optional
filehandle. Not only is there no prototype for that right now, there's no
way for user code (AFAIK) to recognize such a beast. As long as the
optional filehandle syntax survives to P6, you'll have to address it.
I think it would be a good thing for user prototypes to be able to handle
this case and I wholeheartedly support the RFC; but it opens a can of worms
that should be addressed. Perhaps in another RFC. Do any other (Damian)
RFCs on (Damian) prototyping impact (Damian) this area?
--
Peter Scott
Pacific Systems Design Technologies
Re: RFC 168 (v1) Built-in functions should be functions
Damian Conway wrote:
I think it would be a good thing for user prototypes to be able to
handle this case and I wholeheartedly support the RFC; but it opens
a can of worms that should be addressed. Perhaps in another RFC. Do
any other (Damian) RFCs on (Damian) prototyping impact (Damian)
this area?
I'll need to think about that issue. Can anyone think of an optional left
argument that *isn't* really an indirect object?
Well, as I mentioned in another recent parallel thread, if Cfor is to
be properly functionalized, provision must be made in the prototype for
its optional iterator:
for ( @a ) {
for $i ( @b ) {
And we could lose the parens, too.
sub for($?@); # shweet.
--
John Porter
We're building the house of the future together.
Re: RFC 168 (v1) Built-in functions should be functions
Well, as I mentioned in another recent parallel thread, if Cfor is to be properly functionalized, Whoa -- why? Syntax keywords (eg if, unless) certainly need not be expressible as functions.This isn't tcl! --tom
RFC 168 (v1) Built-in functions should be functions
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Built-in functions should be functions
=head1 VERSION
Maintainer: Johan Vromans [EMAIL PROTECTED]
Date: 27 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 168
=head1 ABSTRACT
RFC 26 proposes to eliminate the distinction between functions and
operators from a language perspective.
This RFC proposes that all Perl built-in functions should be usable in
all ways normal functions can be used. It is part of a big consipracy
to remove the number of cases with exceptional behaviour in Perl.
=head1 DESCRIPTION
Named operators, like Cabs, can be called like functions in which
case they behave like functions. However, that's where the similarity
ends. You cannot override most builtins, and cannot tack a reference
to them.
There is no reason why the built-ins should be treated differently. A
famous Perl saying reads "if it looks like a function, it Bis a
function." So be it.
In particular, it is desired that every built-in
=over 4
=item *
can be overridden by a user defined subroutine;
=item *
can have a reference taken;
=item *
has a useful prototype.
=back
=head2 Overriding
The principle of least surprise dictates that
sub Ifoo { return 10 }
print Ifoo();
should call Ifoo() and print "10" for all Ifoo.
Currently, most built-ins are excluded from this. For example:
sub system { return 10 }
print system();
Instead of calling the user defined system(), the built-in is used.
The second line may give a warning, but only if warnings are enabled:
Ambiguous call resolved as CORE::system(), qualify as such or use
=head2 References
You can call a built-in, but not take a reference.
$a = \system;
print $a-(-1)
This gives an error:
Undefined subroutine main::system called
This should return a reference to the built-in instead.
Since CIfoo implicitly refers to the current package, it would be
acceptible to require
$a = \CORE::system;
Note that this currently (5.7.0 DEVEL6806) results in the error:
Undefined subroutine CORE::system called
which is surprising, if not misleading.
=head2 Prototypes
Currently, several built-ins do not provide prototype information.
prototype("CORE::abs") == ;$
prototype("CORE::shift") == undef
This must be fixed. One might even call this a bug, although the
current prototype mechanism is not powerful enough to cope with all
built-ins.
=head1 REFERENCES
RFC 26: Named operators versus functions
Tom Christiansen in 12231.967154045@chthon (perl6-internals, Aug 24, 2000).
