Re: perl 6 requirements
Randal L. Schwartz writes: | "Chaim" == Chaim Frenkel [EMAIL PROTECTED] writes: | | Chaim It's the overloading of the ',' operator. | | Just like the overloading of the @ARRAY_NAME operator or the | getpwuid() operator. Perhaps you are back to merely complaining about | all context-sensitive things again. :-) Possibly, although I must ask: since everything is up-for-grabs, I ask (without implying any feeling one-way-or-tother): How useful is the , operator in it's C-style statement separator, as opposed to list separator guise? It seems to be a common cause of confusion. Mx. -- See, the stars are shining bright Everything's all right tonight -- (Martin L. Gore, Never Let Me Down Again)
Re: type-checking [Was: What is Perl?]
Damian Conway [EMAIL PROTECTED] writes: Peter Scott [EMAIL PROTECTED] (I think -- Piers) writes: Though a good post condition would benefit from some sort of unconditional catch of return, I suppose. Perhaps allowing continue on the outer sub block... Argh, no! A good postcondition is either invisible to the client code, or makes its presence felt only through the effect of turning a bad final state (or return value) into an exception. It does *not* offer a last chance to monkey with the return value! Yeah, if you want to do that sort of thing you need to mess with 'advising' your methods, a la emacs-lisp def-advice. But we can do that already. -- Piers
Re: type-checking [Was: What is Perl?]
On Wed, Aug 02, 2000 at 02:18:07PM +1000, Damian Conway wrote: Though a good post condition would benefit from some sort of unconditional catch of return, I suppose. Perhaps allowing continue on the outer sub block... Argh, no! A good postcondition is either invisible to the client code, or makes its presence felt only through the effect of turning a bad final state (or return value) into an exception. It does *not* offer a last chance to monkey with the return value! http://bumppo.net/lists/fun-with-perl/2000/08/msg0.html -- Life would be so much easier if we could just look at the source code. -- Dave Olson
Re: Reduce [was: Re: Random items (old p5p issues)]
On Tue, Aug 01, 2000 at 10:27:08PM +0300, Ariel Scolnicov wrote:
multimap operation list-of-lists # uurgh.
This made me think of something else that came up in a discussion with Larry
after the conference.
The discussion started off with the ability to do
for ($a,$b) (@list) { ... }
and go through the list in steps of two, or whatever the number of vars were.
But then went onto interators and something like
@list = interleave(@a,@b,@c);
which would interleave the lists given, and
foreach ($a,$b,$c) (interleave(@a,@b,@c))
which would iterate around all lists at the same time, but without flattening
the list. Maybe through some kind of hierarchy of iterators or something
Graham.
I really should get all these ideas into an RFC.
Re: Reduce [was: Re: Random items (old p5p issues)]
hi,
Why not some sort of functionality like LISP/Prolog i.e. working with lists.
("a",@x,"b",%y) - the list
head ("a",@x,"b",%y) # "a"
head(tile("a",@x,"b",%y)) #@x
head(head(tile("a",@x,"b",%y))) #$x[0]
head(tile(tile("a",@x,"b",%y))) #"b"
if you like it then "splice" etc... can this be done in the moment ??
I think moto of the Perl6, should be "Steal with Style" :")
On Tue, Aug 01, 2000 at 10:27:08PM +0300, Ariel Scolnicov wrote:
multimap operation list-of-lists # uurgh.
This made me think of something else that came up in a discussion with
Larry
after the conference.
The discussion started off with the ability to do
for ($a,$b) (@list) { ... }
and go through the list in steps of two, or whatever the number of vars
were.
But then went onto interators and something like
@list = interleave(@a,@b,@c);
which would interleave the lists given, and
foreach ($a,$b,$c) (interleave(@a,@b,@c))
which would iterate around all lists at the same time, but without
flattening
the list. Maybe through some kind of hierarchy of iterators or something
Graham.
I really should get all these ideas into an RFC.
Re: lexical variables made default
Thus it was written in the epistle of Jeremy Howard, J. David Blackstone said: Prior to version 5, all implementations of Perl were designed with only dynamic variables in mind. Perl5 provided lexical variables in a backward compatible way. Perl6 should make lexical variables the default. ... That's certainly a nice idea. However, a lot of scripts will break if you do this (we wouldn't reach the 80% of scripts 100% compatible, I'm pretty sure). Since compatibility is to be acheived through conversion of the code, I think that we could pretty easily write a converter which would remove the 'my' for my variables and add a 'dynamic $variable' for the ones which need it, reaching well over the 80%. Just my guess, Ted -- Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University == To arrive at the simplest truth, as Newton knew and practiced, requires years of contemplation. Not activity. Not reasoning. Not calculating. Not busy behaviour of any kind. Not reading. Not talking. Not making an effort. Not thinking. Simply bearing in mind what it is one needs to know. And yet those with the courage to tread this path to real discovery are not only offered practically no guidance on how to do so, they are actively discouraged and have to set abut it in secret, pretending meanwhile to be diligently engaged in the frantic diversions and to conform with the deadening personal opinions which are continually being thrust upon them. -- Brown, George Spencer (1923 - ) == Deep thoughts to be found at http://www.southern.edu/~ashted
Re: multiline comments
One argument *against* intra-token-sequence multiline comments is that they are harder to see, and thus render readers of the code more prone to misunderstand it. Is this worth really promoting? The extant pod-based multiline comment solution does not suffer from this, as it is quite easy to see, owing to its column-zero constraint. It also avoids the gnarly games that C programmers play of /* covertly placing */ comments midsequence in the token stream. However, as currently employed, these pod comments *do* suffer from a couple of potentially non-trivial problems in their own right. The more important of these is that when you're done with a "=for commentary" or an "=end commentary", you're not back in code mode. The other issue is that there is no standardly accepted target name indicative of comment status, which means that people's choices in this will not be predictable. Lack of predictability hampers machine analysis, which is desirable for easy extraction (perhaps for significant comments?) and so that the translators can casually ignore these without remonstration. Can we do something about this easily enough? I think so. Settling on one pod target for multiline comments, and then defining the =for and =end of that target to implicitly =cut back to code, would seem to address both of these issues. Is there some reason that these funky punctuational and easy-to-miss intra-sequential multiline comments are to be preferred over this strategy? As a quasi post script, that reminds me that *perhaps* pod is the way to go as far as significant comments are concerned. If we don't get sufficiently rich declarations of input and output types and ranges to happify the poor tiny-active-working-set people with their expert-hostile, user-obsequious IDEs, then we could probably painlessly stake out some structured pod territory for this explicit purpose. This would have the advantage of being backwards compatible, but perhaps one doesn't care so much in this particular arena. --tom
Re: RFC: multiline comments
John Porter wrote: Michael Mathews wrote: Using a two-character syntax to start and end a multiline comment seems to be a good way to satisfy both the desired similarity to "#" and the desired uniqueness to avoid collision with real single-line quotes. I would suggest a (# many lines of comment #) syntax: Nothing personal, but -- Barf. Very non-perlish, IMHO. qc( here's some text which will evaluate to "silent undef". ); I had much the same reaction to (# foo #). I would find qc( foo ) much more acceptable. We lose the "comments are always #" idea, but then there's other languages that have more than one character design used for comments. In the case of C/C++, # would map to //, and qc() would map to /* */. You can use either to simulate the other, but each has one or two things that it handles better than the other. On the other hand, the stated desire for this is for commenting out blocks of code. That might be more achievable with (I forget the right name for this) 'compile time directives' such as "#if", "#endif". We'd have to use a different opening syntax, since # is already taken for comments, but this might be of more general usefulnes than block comments. [I have a sneaking suspicion that this is another one of those 'hot topics'. I suspect that we could abuse pod to achieve the block comment effect, but that would clutter up the documentation rather badly.] E.W.
Re: Random items (old p5p issues)
Dan Sugalski [EMAIL PROTECTED] writes: continuations, generators and co-routines. Could someone point me to a reference on these, please? My CS text collection's rather spotty and doesn't cover this stuff. The Icon Programming Language Ralph E. Griswold, Madge T. Griswold Prentice Hall, ISBN 0-13-449777-5 The Implementation of the Icon Programming Language Ralph E. Griswold, Madge T. Griswold Princeton, ISBN 0-691-08431-9 -- Johan
Re: RFC: lexical variables made default
On Wed, Aug 02, 2000 at 08:45:04AM -0600, Tom Christiansen wrote: Anything one chooses potentially conflicts with the user's namespace, but probably save() or temp() would be better, or even savetemp() or tempsave() or scopetemp(). How about deliver() or preserve()? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: type-checking [Was: What is Perl?]
"DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS I think I'm missing the point. Why pull 'em out like that? Why not just put DS the code in the body of the sub? Though a good post condition would benefit DS from some sort of unconditional catch of return, I suppose. Perhaps DS allowing continue on the outer sub block... Because the pre, post, invariants should only be executed, if and only if, the user requests it. Further, they are _not_ part of the sub, they are an external contract between the caller and the callee. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC: lexical variables made default
On Wed, Aug 02, 2000 at 08:45:04AM -0600, Tom Christiansen wrote: Anything one chooses potentially conflicts with the user's namespace, but probably save() or temp() would be better, or even savetemp() or tempsave() or scopetemp(). How about deliver() or preserve()? I can slightly grok the latter, but not the former. What are you thinking there? --tom
Re: RFC: lexical variables made default
On Wed, Aug 02, 2000 at 09:15:38AM -0600, Tom Christiansen wrote: On Wed, Aug 02, 2000 at 08:45:04AM -0600, Tom Christiansen wrote: Anything one chooses potentially conflicts with the user's namespace, but probably save() or temp() would be better, or even savetemp() or tempsave() or scopetemp(). How about deliver() or preserve()? I can slightly grok the latter, but not the former. What are you thinking there? Ah, I was thinking of save() and how it could be deliverance. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC: Request For New Pragma: Implicit
"BCW" == Bryan C Warnock [EMAIL PROTECTED] writes: BCW =head1 ABSTRACT BCW Perl 6 should add a new pragma called Cimplicit. BCW =head1 DESCRIPTION BCW There should be an Cimplicit pragma that gives new life and meaning to BCW void context constructs. In my case, I want it to print to the default BCW filehandle, (which is also implicit, I might add.) No. chaim (Walks away shaking head, in wonder and amazement.) -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: multiline comments
Buddha Buck wrote: The one concern I would raise about this is that a common use of multi-line comments is to dyke out code. As such, it is handy to have the start and end markers different, and allow nesting I see your point. At the risk getting too exotic how about: #EOC; some comments EOC This is less backwards compatable, however. --Michael
Re: lexical variables made default
I believe that under the current proposal, any unqualified and
hitherto undeclared variables would be implicitly declared to be
lexicals in the current scope. This is to be contrasted with the
status quo, under which such variables are implicitly dynamics in
the current package.
I am not wholly convinced this is the best of all possible ideas.
(I am willing to hear reasoning why it is, however.)
For one thing, wouldn't one rather encourage *explicit* declaration?
How is it that the conditions of "use strict" are unsatisfactory?
This makes you say either my() or our(). Wouldn't it suffice for
your purposes to make strict mode the default instead?
Another matter is that having undeclared variables all be lexicals
by default would require a fair bit of code translation, not always
straightforward and clean. Consider the straightforward code
sequence:
my $a = 3;
package A;
$x = 1 + $a;
package B;
$x = 2 + $a;
And how you will now have to translate that.
Or what about this one:
perl -lane 'END{print $sum} $sum += $F[-1]'
Or even
BEGIN { $x = 20 }
print $x;
If you make lexical autodeclaration the default, it seems to me
that one could look at this as implicitly saying that Perl is to
be made less suitable for fast and convenient solution. Perl has
always been the king of convenience. I recognize that this hurts
in some circles because of scalability concerns. The argument could
easily be made that favoring scalability will help this. But the
cost to small-scale program(mer)?s must be weighed in the balance.
--tom
Re: date interface (was Re: perl6 requirements, on bootstrap)
Since perl6 will/should have a new Configure methodology[1] there could be a registry (hate that word) of all available function calls[2], developed during the build processes. Then the core would be able to infer a 'use' command. chaim [1] Where is the perl6-configure list? Did anyone request one? [2] perhaps extracted from the replacement of @EXPORT_* "NT" == Nathan Torkington [EMAIL PROTECTED] writes: NT Moving things to modules (a) does little for the size of Perl, and (b) NT promotes Pythonization of the language (i.e., all programs begin with NT 20 lines of `load this module, load that module, load the other NT module'). Your criteria for moving to a module can't simply be NT whether it's a system call or not, you must use something that takes NT into account the hindrance and the payoff. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: perl 6 requirements
"GB" == Graham Barr [EMAIL PROTECTED] writes: GB On Tue, Aug 01, 2000 at 07:41:59PM -0700, Randal L. Schwartz wrote: "Chaim" == Chaim Frenkel [EMAIL PROTECTED] writes: Chaim It's the overloading of the ',' operator. Just like the overloading of the @ARRAY_NAME operator or the getpwuid() operator. Perhaps you are back to merely complaining about all context-sensitive things again. :-) GB No, I think the main problem is that many do not graps the list vs GB array distinction and would possibly document the sub wrong, giving GB a surprise when it is used. Then perhaps, just get rid of the list/array distinction? Make everything an array? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
RE: RFC: lexical variables made default
Scott wrote: On Wed, Aug 02, 2000 at 08:45:04AM -0600, Tom Christiansen wrote: Anything one chooses potentially conflicts with the user's namespace, but probably save() or temp() would be better, or even savetemp() or tempsave() or scopetemp(). How about deliver() or preserve()? How about contain() or detach() or revalue()? Also, how about renaming my() to local()? Will this be too confusing? --Ala
Re: date interface (was Re: perl6 requirements, on bootstrap)
On Wed, Aug 02, 2000 at 11:37:06AM -0400, Andy Dougherty wrote: On Wed, 2 Aug 2000, Chaim Frenkel wrote: If it is decided (and I hope not) that localtime and its kin are verboten, it should not exists _at all_ in Perl6 and any existance at all would be only as a support module for Perl5 backward compatiblity. Well we should still have POSIX::localtime(). True, and hopefully in a more optimal form. Graham.
Re: RFC: lexical variables made default
How about contain() or detach() or revalue()? I might just throw out that the operator "let" does the job in Lisp. Also, how about renaming my() to local()? Will this be too confusing? I feel strongly that "my" and "our" should both be renamed, as well as "local". -- John Porter
Re: date interface (was Re: perl6 requirements, on bootstrap)
On Wed, Aug 02, 2000 at 09:41:06AM -0600, Tom Christiansen wrote: Well we should still have POSIX::localtime(). True, and hopefully in a more optimal form. Were you planning on updating the Standard? :-) Sure, everything is up for grabs right :) Actually I meant the way the POSIX module is so big but has little content as it is really just a API to the C library (or it should be). Graham.
Re: RFC: lexical variables made default
I feel strongly that "my" and "our" should both be renamed,
as well as "local".
What then do you propose? my() and our() were chosen for their brevity.
I might suggest that one look to Python's use of locals() and
globals(). Currently, globals() is something like keys %{ __PACKAGE__
. "::"}, more or less, but locals() is unfindable from the Perl
level. Perhaps this should be addressed. So too perhaps should
the inconvenience/kludginess of the globals() solution above. Then
again, I suppose that non-code-devel-tools folks seldom have cause
to muck about in these waters.
--tom
Re: RFC: lexical variables made default
Tom Christiansen wrote: I feel strongly that "my" and "our" should both be renamed, as well as "local". What then do you propose? my() and our() were chosen for their brevity. Well, "var" is pretty short. And perhaps globals could be declared with something like "var global". Extra verbosity required for globals might be A Good Thing. -- John Porter
Re: perl 6 requirements
"RLS" == Randal L Schwartz [EMAIL PROTECTED] writes: "Chaim" == Chaim Frenkel [EMAIL PROTECTED] writes: Chaim It's the overloading of the ',' operator. RLS Just like the overloading of the @ARRAY_NAME operator or the RLS getpwuid() operator. Perhaps you are back to merely complaining about RLS all context-sensitive things again. :-) I'm not complaining about it. I'm bringing it to the table. I've been doing perl for a number of years, and I still don't have the get*() scalar/list memorized. I keep looking it up. Its a useful feature. But not useful enough that I expedend the effort to memorize them. As Graham pointed out. It might simply be the list/array division. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Reduce [was: Re: Random items (old p5p issues)]
Graham Barr wrote:
But then went onto interators and something like
@list = interleave(@a,@b,@c);
which would interleave the lists given, and
foreach ($a,$b,$c) (interleave(@a,@b,@c))
sub interleave(\@;\@\@\@\@\@\@\@\@) {
my $m = -1;
for ( @_ ) { $m $#{$_} and $m = $#{$_} }
map { my $i = $_; [ map { $_-[$i] } @_ ] } 0..$m;
}
for ( map { @$_ } interleave( @a, @b, @c ) )
Gisle Aas wrote:
Python also has a map function that can take multiple lists and iterate
over them in sync. E.g.
map(func, list1, list2, list3)
where 'func' must be a function taking 3 arguments. Can't see how to
easily extend perl's map in that way. Perhaps we could introduce
map2, map3,... builtins? :-)
sub mapf(;\@\@\@\@\@\@\@\@\@) {
my $cr = shift;
my $m = -1;
for ( @_ ) { $m $#{$_} and $m = $#{$_} }
map { my $i = $_; $cr-( map { $_-[$i] } @_ ) } 0..$m;
}
I guess my question is, why do these need to be builtins?
There is no limit to the funky algorithms one can come up with;
not everyting should go in the core.
--
John Porter
Aus tiefem Traum bin ich erwacht.
Re: Don't you people sleep?!!
At 10:30 AM 8/2/00 -0400, Michael Mathews wrote: Okay, I'm impressed. 108 messages in my box this morning from the list. Shows spunk. But I'm concerned. Are you getting enough sleep? Of course not. :) Don't forget we've folks from England, North America, and Japan (that I know of, and I only know where a few folks are). That pretty much covers the whole day... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: date interface (was Re: perl6 requirements, on bootstrap)
On Wed, 2 Aug 2000 08:14:22 +0100 (BST), Matt Sergeant wrote: I used to be a C programmer myself (well OK, I was a C++ programmer...), but I'd rather any day type "localtime-year" than "(localtime)[5]". And what would you type instead of (localtime)[3, 4, 5] ? localtime-(day, month, year) ? -- Bart.
Re: perl 6 requirements
"Graham" == Graham Barr [EMAIL PROTECTED] writes: Graham You say "operator" and you are right. I think the issue is a sub Graham can return either. Really? How does a sub return "an array"? (Unless you're about to mutter something about "lvalue subs" :) a sub can return only an rvalue. An "array" as an rvalue is always a list. Unless we disagree on the meaning of array and list. In that case, let's get back to terminology. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: RFC: Highlander Variables
"John" == John Porter [EMAIL PROTECTED] writes: John Imho, this is A Bad Practice. Making it impossible would therefore John be Good, existing-script-breakage not withstanding. So you'll break $ARGV and @ARGV? Is that really OK? And will you extend this to ensuring that scalars, arrays, hashes, subroutines, filehandles, formats, directory handles, and labels all have distinct names? I don't see a teaching advantage in saying "the three variable namespaces are all one, but all the other namespaces are distinct". When the rule gets longer, it gets harder to teach. And if it's harder to teach, it's probably harder to learn. (Maybe we can just add something to that ever-increasing "-w" to do this. Make it a warning for beginners.) I'll argue the opposite... "related things" can have similar names. I do it all the time. I think it makes sense. It also makes glob-ish things similar, although I understand this is a separate issue up for grabs. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: perl 6 requirements
On Wed, Aug 02, 2000 at 09:42:09AM -0700, Randal L. Schwartz wrote:
"Graham" == Graham Barr [EMAIL PROTECTED] writes:
Graham You say "operator" and you are right. I think the issue is a sub
Graham can return either.
Really? How does a sub return "an array"?
There is a difference
sub abc { return (7,8,9) }
sub def { my @a = (9,8,7); return @a; }
print scalar abc(),"\n";
print scalar def(),"\n";
__END__
9
3
(Unless you're about to mutter something about "lvalue subs" :) a sub
can return only an rvalue. An "array" as an rvalue is always a list.
Unless we disagree on the meaning of array and list. In that case,
let's get back to terminology. :)
I am not refering to context, but what the user types. If an author
does not document the two subs above correctly as returning a list and an array
then a user may get surprised.
Graham.
Re: Reduce [was: Re: Random items (old p5p issues)]
On Wed, Aug 02, 2000 at 10:43:37AM -0600, Tom Christiansen wrote:
sub mapf(;\@\@\@\@\@\@\@\@\@) {
Steal from lisp:
map
maap
maaap
mapp
mappp
maappp
dwim
:)
Graham.
Re: multiline comments
Buddha Buck wrote:
The one concern I would raise about this is that a common use of multi-line
comments is to dyke out code. As such, it is handy to have the start and
end markers different, and allow nesting.
It nice to be able to bounce on % in vi, too:
=#{
comment
=#}
--
John Porter
Re: perl 6 requirements
"Graham" == Graham Barr [EMAIL PROTECTED] writes:
Graham There is a difference
Graham sub abc { return (7,8,9) }
That's returning either a list or a comma operator result, depending
on context.
Graham sub def { my @a = (9,8,7); return @a; }
That's not returning the array. That's returning a copy of the contents
of @a in a list context, and the number of elements of @a in a scalar
context, using the "@a" operator. You still haven't "returned the array".
Graham I am not refering to context, but what the user types. If an author
Graham does not document the two subs above correctly as returning a list and an array
Graham then a user may get surprised.
Yes, but the first part is getting the naming right. You don't
"return an array". :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
[EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: multiline comments
Michael Mathews wrote:
At the risk getting too exotic how about:
#EOC;
some
comments
EOC
Just introduce a new function which is a bit bucket:
# works in perl5.
sub comment(@) { }
comment q{ comments... };
comment EOF;
comment
EOF
--
John Porter
Re: RFC: Higher resolution time values
Graham Barr [EMAIL PROTECTED] writes: Well theres a difference there when you look at the op tree. That is a call to a sub, whereas otherwise it is a op. Isn't that an internals issue? -- Johan
Re: DRAFT RFC: Enhanced Pack/Unpack
The existing pack and unpack methods are dependent upon a simple yet complex 'format' structure, which is often difficult to get right, and which carries no information regarding the associated variable names. I know what you mean, but it reads like "black yet white". "simple grammar which leads to opaque format specifications, which are often" maybe. A whole new body of code, implementing an enhanced data description capability. Possibly with the following method design. [Note: Design is currently expressed in Perl5 syntax. At least I think it is. PROOFREADERS! ATTACK!] I'll leave that to others. My only comment is that pack and unpack are currently zippy: if going to an object-based interface slows them appreciably, people won't be happy. More incentive to the internals group to make method calls fast. -- Dominic Dunlop
Re: multiline comments
It nice to be able to bounce on % in vi, too:
=#{
comment
=#}
You easy to do this already:
=begin comment {
=end comment }
--tom
Re: RFC: Highlander Variables
On Wed, 2 Aug 2000 12:29:41 -0400, John Porter [EMAIL PROTECTED] wrote: H.Merijn Brand wrote: If I could, I would VETO! If I could, I would mandate this change. This is definitely in my Top 10 List of Perl 5 Suckinesses. So here we differ. That's what discussions are for. This would break about 90% of my scripts. Some large percentage of your scripts is going to break anyway. Hope not. I have grown a habit of pretty clean programming, using -w and use strict all the way. I use the same name for different type of variables to group them: Imho, this is A Bad Practice. Making it impossible would therefore be Good, existing-script-breakage not withstanding. I think you cannot say "A bad practice". It's a way of thinking. I'm glad Tom's with me on this, except that he refers to global variables that might be deemed anyway. We're not thinking like in C where every variable `should' be prefixed with it's type, like p_var for a pointer to a variable or t_var for defining the type for var. In perl I just LOVE the way $, @, % and unambiguously defines the type of the var. I just miss a prefix for formats (which will be dropped anyway) and IO. I'd hate to see my code being converted to (as suggested): $foo__array = qw(monday tuesday wednesday thursday friday saturday sunday); $foo = 4; print $foo__array[$foo], "\n"; YUK! -- H.Merijn Brand Amsterdam Perl Mongers (http://www.amsterdam.pm.org/) using perl5.005.03, 5.6.0 516 on HP-UX 10.20, HP-UX 11.00, AIX 4.2, AIX 4.3, DEC OSF/1 4.0 and WinNT 4.0 SP-6a, often with Tk800.022 and/or DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
Re: Reduce [was: Re: Random items (old p5p issues)]
Tom Christiansen wrote:
sub mapf(;\@\@\@\@\@\@\@\@\@) {
Steal from lisp:
map
maap
maaap
mapp
mappp
maappp
...
Should be feasible with an AUTOLOAD that takes a certain kind of regular
expression...
sub AUTOLOAD /^ma+p+$/ {
}
Some for the 'car' and 'cdr' variants, of course...
Hildo
Re: RFC: lexical variables made default
At 11:57 AM 8/2/00 -0400, John Porter wrote: Tom Christiansen wrote: I feel strongly that "my" and "our" should both be renamed, as well as "local". What then do you propose? my() and our() were chosen for their brevity. Well, "var" is pretty short. And perhaps globals could be declared with something like "var global". Extra verbosity required for globals might be A Good Thing. Argh, you're giving me Pascal flashbacks. P5 P6 local save my my our our Keep 'em short. As for making lexicals the default, I ain't giving up the typo-catching effect of use strict 'vars'. So you'd need something like use strict 'declarations' which would require all variables to be declared with one of the above three before first use (or be package-qualified). -- Peter Scott Pacific Systems Design Technologies
Re: multiline comments
On Wed, 2 Aug 2000 12:51:10 -0400, John Porter wrote:
At the risk getting too exotic how about:
#EOC;
some
comments
EOC
Just introduce a new function which is a bit bucket:
# works in perl5.
sub comment(@) { }
comment q{ comments... };
"Function"? Who needs a function?
END_OF_COMMENT;
This is comment!
And more...
END_OF_COMMENT
Apart from the warning "Useless use of a constant in void context", it
works.
--
Bart.
Re: multiline comments
Bart Lateur wrote: END_OF_COMMENT; This is comment! And more... END_OF_COMMENT Apart from the warning "Useless use of a constant in void context", it works. Yes; but it was precisely that warning which I was intending to address. Perhaps a better way would be a change in the semantics of scalar literals in void context, to be silently ignored. Then you can make a comment any way you want. -- John Porter
Re: DRAFT RFC: Enhanced Pack/Unpack
Edwin,
This writeup certainly is a great first draft for this RFC. I'll have to track down
those references.
I was surprised by the read/write operations, but have no objection to them.
New/get/set and the individual data member access functions are the critical pieces,
as the I/O could be done to normal variables, but it would take more steps that way,
so read/write are nice enhancements.
A few comments below, in context of the RFC, the parts of which I'm not commenting on
are elided for brevity.
Edwin Wiles wrote:
=head3 Data Definition
While we could use a C-ish 'struct' syntax, that would imply a
whole new parser capability. Something built up out of
existing perl syntax would be easier to implement?
For example, assume a set of C structs as follows:
struct foo {
int bar;
int baz;
int count;
};
Followed by 'count' copies of:
struct stroff {
int length;
int offset;
};
Followed by 'count' variable length, not necessarily null
terminated collections of bytes. Possibly strings, possibly
not, but we'll consider them strings for now.
[ 'bar', 'i', 'baz', 'i', 'count', 'i' ]
Three kinds of comment here.
The first kind: this list looks very paired, can we make that more explicit?
The second kind: Many of the "pack" code characters imply both type and length, and
that is useful and concise (vs. 2 parameters), and we could use those same character
codes here... but I'd rather see something more readable than single character
stuff... if other RFCs come up with sized type names for Perl variables, those same
names could be used here... that discussion seems to be continuing, so I don't know
how it will end. Another alternative would be to borrow type names from C, but
theirs are not fixed size. Another alternative would be to borrow type names from
some DDL or IDL type language.
The third kind: to be really, really flexible (want to read a FAT-12 data
structure?), bit sizes might be appropriate for integers and pad fields. And a
(non-IEEE) floating point number requires quite a few parameters to define: exponent
size, exponent base, mantissa size, implied leading 1 or not, etc. Doubt we want to
go that far in a basic implementation, but maybe some hooks would allow it.
So here's some ideas for consideration, that attempt to address all the above points:
1) make the list use = separators: the above example would become
[ 'bar' = 'i', 'baz' = 'i', 'count' = 'i' ]
2) use bigger names, and support standard types simply. Here are some examples,
starting with the same one, but using invented sized type names:
[ 'bar' = 'integer32', 'baz' = 'integer32', 'count' = 'integer32' ]
[ 'var1' = 'int32', 'var2' = 'int16', 'var3' = 'int8' ]
3) allow definitions to support odd-sized standard types
[ 'bar' = [ 'integer', 32 ], 'baz' = ['integer', 32 ], 'count' = ['integer',
32]]
[ 'var1' = 'int32', 'var2' = ['integer', 12 ], 'var3' = ['integer', 20]]
4) allow hooks to support non-standard types. The idea here is for the user to write
two subs to convert a funny type to or from a scalar perl variable (could be a ref,
of course) from its linear binary representation, and then tell the Structure
feature/module about them via a method of some sort. Then they can be converted just
like, and mixed with, regular types.
sub Structure::define ( type name, frombinarysub, tobinarysub )
sub from_funny ( type_params, binary_var, bit_offset )
# returns ( next_bit_offset, funny_var )
sub to_funny ( type_params, binary_var, bit_offset, funny_var )
# returns ( next_bit_offset )
Structure::define ( 'funny', \from_funny, \to_funny );
[ 'var1' = 'int32', 'var2' = ['funny', 6, 18, 12]]
type_params is the reference to the array defined in the definition, in this
example, it would be ['funny_type', 6, 18, 12] (it appears that the type 'funny' has
three parameters to define its storage characteristics).
Here's 'funny2' with no parameters for its storage characteristics:
sub from_funny2 ( type_params, binary_var, bit_offset )
# returns ( next_bit_offset, funny2_var )
sub to_funny2 ( type_params, binary_var, bit_offset, funny_var )
# returns ( next_bit_offset )
Structure::define ( 'funny2', \from_funny2, \to_funny2 );
[ 'var1' = 'int32', 'var2' = 'funny2']
This would do for the first structure. Arrays are used rather
than hashes to guarantee data order.
[ 'length', 'i', 'offset', 'i' ]
Or ['length' = 'int32', 'offset' = 'int32' ]
Will do for the second structure. Now how do we join these
two?
[ 'bar', 'i', 'baz', 'i', 'count', 'i',
repeat( 'count', [ 'length', 'i', 'offset', 'i' ] ) ]
Or ['bar' = 'int32', 'baz' = 'int32', 'count' = 'int32',
'struct_2' = ['array', 'count', [
[Fwd: New list charters]
Whoa! I'm far from convinced that I have a strong enough CS background to understand half of what'll go on on this list. I've already indicated on-list that I'd rather leave this position for someone else, if there is someone else. My $.02 worth ... It's been my experience that the stronger the technical background (in anything, not just CS) the more cryptic one becomes and less able to deal on a real world level with mere mortals. I don't think 'language' needs to focus on technical 'how is it done' but more 'this is what it looks like'. I don't think having a *strong* technical background is actually a hindrance for the chair of perl6-language. Again, worth what you paid for it! Alan
Re: perl 6 requirements
"Randal L. Schwartz" wrote:
Graham sub def { my @a = (9,8,7); return @a; }
That's not returning the array. That's returning a copy of the contents
of @a in a list context, and the number of elements of @a in a scalar
context, using the "@a" operator. You still haven't "returned the array".
So then in fact it is impossible to return an array - yes? You can
either return a single scalar or a list. The closest you can come to
returning an array as an entity is to return a reference to it - \@a.
Have I got that straight?
--
Alan Burlison
Re: multiline comments
Peter Scott wrote: At 02:53 PM 8/2/00 -0400, John Porter wrote: Perhaps a better way would be a change in the semantics of scalar literals in void context, to be silently ignored. No! It's a major typo/bug-catcher. Strange, my experience does not confirm that one whit. -- John Porter
Re: Removing/fixing $[line noise here] variables
Brust, Corwin wrote: messages.rfc - An RFC to discussing the wisdom of allowing run time error and warning messages to be modified at run time ... I want perl's error (and warning) messages to be specific to each program I write. Isn't this covered by locales? -- John Porter
Re: perl6 requirements
"TC" == Tom Christiansen [EMAIL PROTECTED] writes: Please explain what the utility of having unshared variables? I might as well just fork(). TC The only sane situation is to have safety by default. Things should not TC be shared unless you say they are. Err, I understood his comment to claim that there would be no shared no variables. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC: lexical variables made default
On Wed, Aug 02, 2000 at 08:45:04AM -0600, Tom Christiansen wrote: On Tue, 1 Aug 2000 23:43:24 -0500, Jonathan Scott Duff [EMAIL PROTECTED] wrote: (I, for one, support renaming local() to Something Better (if only I know what that was)) Anything one chooses potentially conflicts with the user's namespace, but probably save() or temp() would be better, or even savetemp() or tempsave() or scopetemp(). or saveval()# indicates it is about _values_, not about variables tempval() or saverestore()# name says what the operator does or myval() # my _value_, not my(variable) or even pushpop() # maybe not :-) -- Tad McClellan SGML consulting [EMAIL PROTECTED] Perl programming Fort Worth, Texas
Re: RFC: lexical variables made default
Tad McClellan wrote: or saveval()# indicates it is about _values_ tempval() or myval() # my _value_, not my(variable) or even pushpop() # maybe not :-) pushval() -- John Porter
C# Language and Programmer's Reference (URL)
http://msdn.microsoft.com/library/default.asp?URL=/library/prelim/csref/vcor iCReference.htm
Re: Removing/fixing $[line noise here] variables
On Wed, Aug 02, 2000 at 03:34:56PM -0400, John Porter wrote: Brust, Corwin wrote: I want perl's error (and warning) messages to be specific to each program I write. Isn't this covered by locales? Completely different beast. I don't claim to fully understand locales, but that's not what they're for.
RFC: variable usage warnings
Hey, this RFC stuff is fun! =head1 TITLE variable usage warnings =head1 VERSION Maintainer: Steve Fink [EMAIL PROTECTED] for now Date: 2 Aug 2000 Version: 0 (unreleased) Mailing List: [EMAIL PROTECTED] Number: (unassigned) =head1 ABSTRACT "VARIABLE used only once: possible typo" should be replaced with warnings on uses of uninitialized variables (including lexicals). =head1 DESCRIPTION Perl6 should distinguish between uses and assignments to variables, and warn only when a variable is used without being assigned. In perl5 the complete program $x = 3 complains, but $x = 3; $x = 3 does not, nor does my $x = 3 nor use vars qw($x $y); $x = $z; $y = $z; It would be more useful to have a complaint for both lexical and package variables, and only when a variable is used without ever being assigned to (or having its reference taken). The warning message "use of uninitialized value" should also disappear, to be replaced with "use of undefined value", and the warning for the purpose described in this RFC should be "use of uninitialized variable C$x". Note that if you currently depend on lexical variables having undefined values, you would need to change Cmy $x to Cmy $x = undef. This is a Good Thing. =head1 IMPLEMENTATION I have no idea how difficult this would be to implement. You just need to distinguish between lvalue and rvalue uses of a variable, I guess? But hey, this is a language RFC, not an internals RFC. :-) There's also the question of whether to properly track uses and definitions so that C$::z = $x; $x = 3 is a warning, as well as C$x = 3 if f(); print $x. Though the latter would require renaming the warning to "possible use of uninitialized variable C$x".
Re: date interface (was Re: perl6 requirements, on bootstrap)
Simon Cozens [EMAIL PROTECTED] writes: On Tue, Aug 01, 2000 at 09:39:28PM -0400, Dan Sugalski wrote: I like perl's smart built-in IO just fine, thanks. :) Don't mind making it better, but I do mind making it optional. If we're going to do line disciplines, we need a built-in stdio replacement. Full ground-up rewrite, like sfio but Perlish. I think that is almost a given - we have been on verge of doing it for perl5 for years. -- Nick Ing-Simmons
Re: RFC: Filehandle type-defining punctuation
On Wed, Aug 02, 2000 at 11:46:15AM -0700, Peter Scott wrote: =head1 TITLE Filehandles should use C* as a type prefix if typeglobs are eliminated. I could go for this, given the `if typeglobs are eliminated' caveat.
Re: RFC: Filehandle type-defining punctuation
Thus it was written in the epistle of Tom Christiansen, Hearing no outright derision in response to my trial balloon, here it is as an RFC: =head1 TITLE Filehandles should use C* as a type prefix if typeglobs are eliminated. Nope. A filehandle is a singular whatzitz. It thus mandatory takes the singular prefix; to wit, $. What's next? Integer and float and complex and string and char and bits prefixes? (Weighing in with the traditional "but Tom" message) But Tom, filehandles are different gadgets. They have been in perl up to this point and they are conceptually. I've appreciated and agreed with your linking the punctuation before a variable to parts of speech, but if the you decide that $ is the single singular whatzitz, then what is the plural whatzitz? We have two kinds because they're talking about two different gadgets. Letting * be another kind of singular whatzitz is a reasonable thing. Think of it as singular and plural nouns and verbs if that helps :-) (and yes, I know that analogy doesn't fit very well, so save your fingers on that one :-). Ted -- Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University == When Newton saw an apple fall, he found In that slight startle from his contemplation -- 'T is said (for I'll not answer above ground For any sage's creed or calculation) -- A mode of proving that the earth turn'd round In a most natural whirl, called "gravitation;" And this is the sole mortal who could grapple, Since Adam, with a fall or with an apple. -- Byron == Deep thoughts to be found at http://www.southern.edu/~ashted
Re: RFC: multiline comments
Thus it was written in the epistle of Michael Mathews, Ted Ashton wrote: The qc() proposal fits in well with the Perl "look-and-feel" and seems pretty comfortable to me. If there are concerns about obfuscatory potential, a use strict 'comments' could require that the qc( opening start in column one. Further, if qc were flexible about delimiters, those who prefer /* */ could write qc/* Here is a comment */; I think this may be the closest thing to being What Will Make Everyone Happy, but I'm afraid it fails in two very major ways: 1) Perl can't currently handle quote delimiters of arbitrary length. In other words the asterisks would currently be treated as part of the quote, not part of the delimiter. Any idea how to overcome this? I've no intention of overcoming this :-). The delimiter above is the / and should be understood so. The * is a warm fuzzy for C programmers, but as it might lead the masses astray should probably be avoided. 2) Also this proposition fails in one of my goals, which was to allow arbitrary nesting of multiline comments. I believe this would be true for any function based solution. Negative. If you use paired delimiters you're ok. qc( Here's a quick comment which actually contains qc( another comment ) within it ); Ted -- Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University == I advise my students to listen carefully the moment they decide to take no more mathematics courses. They might be able to hear the sound of closing doors. -- Caballero, James == Deep thoughts to be found at http://www.southern.edu/~ashted
Re: Reduce [was: Re: Random items (old p5p issues)]
Graham Barr wrote:
The upcoming Python (v2.0) introduces a builtin called zip() that does
the same thing:
for a,b,c in zip(aa,bb,cc):
...
There are also question on how long the resulting list should be if
@a, @b, @c is not of the same length. I think zip() was defined to
stop when the first list runs out.
I am sure that will be a debate. My first thought was to continue for the
longest and return undef's for the others. I am sure someone would suggest
use aa other cc and many more.
If this is implemented someone will just have to decide what make most sense
and implement that.
stopping at the shortest doesn't permit useful operations on the remainder of the
longer list entries.
Stopping at the longest with undef's seems more general, and people who want the
shorter could
for $a, $b, $c in zip (@aa, @bb, @cc)
{
last if ! defined $a || ! defined $b || ! defined $c;
}
--
Glenn
=
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
___
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html
Re: RFC: multiline comments
Ted Ashton wrote:
2) Also this proposition fails in one of my goals, which was to allow
arbitrary nesting of multiline comments. I believe this would be true for
any function based solution.
Negative. If you use paired delimiters you're ok.
qc( Here's a quick comment which actually contains
qc( another comment )
within it
);
This type of comment will not comment out arbitrary text. In particular, it
might
have problems with text containing mismatched (){}. And yet using non-paired
delimiters doesn't allow commenting out comments. My ideas, which address both,
were in a concurrent-in-time posting to this one I'm replying to.
And the choice of a single-character delimiter is hard for this sort of muliline
comment for use in commenting out blocks of code, considering the line-noise
nature of perl source code. A multi-character delimiter seems imperative for
commenting out code, just as for here documents.
--
Glenn
=
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
___
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html
Re: RFC: multiline comments
Glenn Linderman wrote: $foo = $a + $b # can this be an in-line comment? # + $c * $d; Note that with this scheme it would be possible to allow in-line comments to be multi-line comments, or possible to prevent that. I'd vote in favor of keeping in-line comments on a single line. Note that with this scheme it would be possible to allow multi-line comments to start in the middle of a line, or possible to prevent that. I'd vote in favor of making them start as the first thing on the line. This seems like an acceptable variation on what has been suggested so far. I deally one would be able to safely block comment any large section of a Perl 6 script and not worry about any other block comments within (the outermost block comment takes precedence). So this should work in Perl 6 code here; # # this is a single line comment $foo = $a + $b # here's an in-line comment # + $c * $d; # more code here; It is however, also necessary to avoid accidental collision with single line comments or other perl syntax. For example this example (valid in perl5) could confuse a compiler looking for block comments. Don't see anyway around this sort of thing though. print qq#isome html here/i#; --Michael
Re: RFC: Filehandle type-defining punctuation
Ted Ashton wrote: Thus it was written in the epistle of Tom Christiansen, Nope. A filehandle is a singular whatzitz. It thus mandatory takes the singular prefix; to wit, $. What's next? Integer and float and complex and string and char and bits prefixes? (Weighing in with the traditional "but Tom" message) But Tom, filehandles are different gadgets. Filehandles singular, atomic gadgets. Singular, atomic gadgets are called scalars in Perl. They have been in perl up to this point and they are conceptually. This is a historical accident. I've appreciated and agreed with your linking the punctuation before a variable to parts of speech, but if the you decide that $ is the single singular whatzitz, then what is the plural whatzitz? Arrays (and hashes) Jon -- Knowledge is that which remains when what is learned is forgotten. - Mr. King
Re: RFC: multiline comments
Glenn Linderman wrote:
qc( Here's a quick comment which actually contains
qc( another comment )
within it
);
This type of comment will not comment out arbitrary text.
In particular, it might have problems with text containing
mismatched (){}.
This is already an issue with the existing q.() operators --
which is to say, I don't think it's something we need to worry about.
That's not to say that we shouldn't have multi-char q.() delimiters;
being able to say qq({ }) might be nice, for example.
Also consider the impact of Unicode, which will allow any reasonable
pair of matching Unicode characters. I.e. instead of multi-char,
think wide-char.
And yet using non-paired
delimiters doesn't allow commenting out comments.
Since what I think this means is false, you probably mean
something else...
--
John Porter
Re: RFC: variable usage warnings
The warning message "use of uninitialized value" should also disappear, to be replaced with "use of undefined value", and the warning for the purpose described in this RFC should be "use of uninitialized variable C$x". What about if there's only an expr, not a variable? For example: print $$x-methop() If the return list of the object whose ref ref is in $x is (a, undef, b), what are you supposed to say? --tom
RFC: Reimplement Warnings and Tainting as Pragmas
Wanted to get this out as an idea that could encompass lots of the
concerns I'm seeing about warnings and such:
=head1 TITLE
Warnings and Tainting should be reimplemented as pragmas.
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 2 Aug 2000
Version: 1.0
Mailing-List: perl6-language
=head1 ABSTRACT
Currently, tainting and warnings are implemented as singular,
all-or-nothing command-line switches. These should be reimplemented as
pragmas (like strict) to give better control and more flexibility.
=head1 DESCRIPTION
There has been much talk about wanting finer-grained control over
warnings and possibly tainting as well. Currently, you can only turn
these completely on or off via the -T or -w flags. You can use $^W to
turn all warnings off inside code, but this results in awkward code:
{ local($^W) = 0; do_something() }
{ local($^W) = 0; sub redefine_something { ... } }
Also, *all* warnings are turned off, both "useless" ones (depending on
what you're doing) as well as some that you might actually want to know
about. What would be better is if we could use an approach that was
both:
1. more human readable
2. more flexible
I propose we make tainting and warnings into pragas like strict. This
would allow us to do something like this in the simplest case:
{ no warn; do_something() }
{ no taint 'checking'; $ENV{PATH} = possibly_unsafe() }
However, there is far more power in this approach than simply making a
prettier version of $^W. By making it into pragmas, this actually gives
us far more control over warnings. For example, we can split up warnings
into 'vars', 'subs', and so on just like for strict.
So, if we were going to write a module that redefined a whole bunch of
subs, we could just say:
use strict;
use warn qw(vars);
# no "sub redefined" warning, but still get
# warnings about unused variables and null vals!
sub redefine_something { ... }
This cleans up the code, and makes it more obvious what we're doing. It
also allows the flexibility of adding different classes of warnings
going forward (for example, lexical). Finally, as the comment above
shows, we would be able to weed out just certain warnings without
sacrificing them all.
This approach may also be suitable for extending to other areas as well.
=head1 IMPLEMENTATION
If accepted conceptually, I would propose two things:
1. -T and -w *NOT* go away, but rather act the same
as 'use taint' and 'use warn'.
2. That the pragmas be called "warn" and "taint" to
make them the same tense as "strict".
The warn() function and tainting system would have to be modified. There
are many possiblities for this, and I do not want to address these yet.
Rather, I am interested in the overall like/dislike of this idea.
Re: RFC: multiline comments
Michael Mathews wrote: So this should work in Perl 6 code here; # # this is a single line comment $foo = $a + $b # here's an in-line comment # + $c * $d; # more code here; If starting in column 1 is going to be magic, you may as well make the magic char #, so: # # this is a single line comment $foo = $a + $b # here's an in-line comment # + $c * $d; # And then, you may as well make it =, and use some meaningful verbiage instead of "" and "". So: =begin comment # this is a single line comment $foo = $a + $b # here's an in-line comment # + $c * $d; =end comment The pod solution is more or less obvious. Inlinable nestable comments are something else, and it should look like perl. qc() -- compiled to nothingness. -- John Porter
Re: RFC: multiline comments
This seems like an acceptable variation on what has been suggested so far. I
deally one would be able to safely block comment any large section of a Perl
6 script and not worry about any other block comments within (the outermost
block comment takes precedence).
I still like this solution prototype:
sub comment($) { }
comment "END OF FIRST COMMENT";
asdf
asdf
asdf
asdf
asdf
END OF FIRST COMMENT
--tom
Re: multiline comments
What is wrong with
if (0) {
}
1) what if the block contains syntax errors?
2) what if the bloack contains unmatched braces?
3) this is not easier to type or remember than the currently available
workarounds.
Re: multiline comments
What is wrong with
if (0) {
}
(and of course teaching op builder not to build them in this case).
Funny, I was going to mention that I always use
#if 0
...
#endif
in C for nesting, block comments. Which is rare anyway, rarer perhaps
than this discussion would seem to merit.
--tom
Multi-line comment sub list?
As in - maybe it's time for... -Corwin Corwin Brust Software Engineer Alliance Data Systems formerly Harmonic Systems, Inc. 701 Fourth Ave South, Suite-1600 Minneapolis, Minnesota 55415 Office (612) 672-3584 Mobil(612) 239-8073 Email[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Re: RFC: Filehandle type-defining punctuation
Thus it was written in the epistle of Jon Ericson, Ted Ashton wrote: Thus it was written in the epistle of Tom Christiansen, Nope. A filehandle is a singular whatzitz. It thus mandatory takes the singular prefix; to wit, $. What's next? Integer and float and complex and string and char and bits prefixes? (Weighing in with the traditional "but Tom" message) But Tom, filehandles are different gadgets. Filehandles singular, atomic gadgets. Singular, atomic gadgets are called scalars in Perl. They have been in perl up to this point and they are conceptually. This is a historical accident. I've appreciated and agreed with your linking the punctuation before a variable to parts of speech, but if the you decide that $ is the single singular whatzitz, then what is the plural whatzitz? Arrays (and hashes) But that, precisely, was my point: Arrays *and* hashes. If there is more than one plural whatzitz, then why can't there be more than one singular whatzitz? (and don't say, "because plural *means* more than one" :-). If having a filehandle character would make the code clearer, then let's do it. Ted -- Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University == To throw in a fair game at Hazards only three-spots, when something great is at stake, or some business is the hazard, is a natural occurrence and deserves to be so deemed; and even when they come up the same way for a second time if the throw be repeated. If the third and fourth plays are the same, surely there is occasion for suspicion on the part of a prudent man. -- Cardano, Girolamo (1501 - 1576) == Deep thoughts to be found at http://www.southern.edu/~ashted
Re: RFC: multiline comments
Proposal: here-docs specified with regexes, and no special meaning for newlines. comment /EOC/; this is an arbitrary comment. EOC Smack--the lexer cowers before you! --tom
Re: RFC: multiline comments
Tom Christiansen wrote: comment /EOC/; this is an arbitrary comment. EOC Smack--the lexer cowers before you! Well, hey, while we're daydreaming... :-) -- John Porter
Re: perl6 requirements
Chaim Frenkel [EMAIL PROTECTED] writes: "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS At 10:42 PM 8/1/00 -0400, Chaim Frenkel wrote: We may need that all variables are by default lexical. Without the explicit declaration of cross-thread visible variables, doing threading may well be difficult (on one's fingers) DS The two things are orthogonal. Threading doesn't place any sort of DS requirements on lexical or package variable visibility. We could do a deep DS clone ala 5.6.0's ITHREADS, or a partial clone, or start new threads with DS empty package stashes. Or any (or all) combinations of the above. Please explain what the utility of having unshared variables? Thread local storage - is often what you want most of. I might as well just fork(). That assumes you can fork() ... chaim -- Nick Ing-Simmons
Re: date interface (was Re: perl6 requirements, on bootstrap)
At 11:30 AM 8/2/00 -0400, Chaim Frenkel wrote: Since perl6 will/should have a new Configure methodology[1] there could be a registry (hate that word) of all available function calls[2], developed during the build processes. Then the core would be able to infer a 'use' command. Yes. What I'd like to have is a list of functions, prototypes, return type, calling type, shared libraries they reside in, and the C name. Whenever the lexer saw a name on the list it'd automagically mark that shared library for loading. So if the list had: localtime|$|@|op|time.so|localtime perl would know that the localtime function took a scalar, returned a list, is called like an opcode, and lives in time.so with a name of localtime. If (and only if) you used localtime, perl would load in time.so for you. In the optree (or bytecode stream or whatever) perl would have the I_cant_believe_its_not_an_opcode opcode with a pointer to the function we loaded in from time.so. This way it looks like an opcode, talks like an opcode, looks like an opcode, but isn't an opcode taking up valuable space. (Not to mention making the optimizer more complex--the fewer the opcodes the easier its likely to be) I've got an RFC started on this. The list would presumably be added to occasionally when a module is installed "NT" == Nathan Torkington [EMAIL PROTECTED] writes: NT Moving things to modules (a) does little for the size of Perl, and (b) NT promotes Pythonization of the language (i.e., all programs begin with NT 20 lines of `load this module, load that module, load the other NT module'). Your criteria for moving to a module can't simply be NT whether it's a system call or not, you must use something that takes NT into account the hindrance and the payoff. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183 Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: multiline comments
Hi Tom,
Of course you should consider that the programmer may be block commenting a
section of code precisely because it does contain sytax errors. I often do
so as a way of isolating hard to track bugs. I can't imagine how getting
more courteous error messages would be a Good Thing!
Lets face it -- comments in general are a luxury. Certainly "#" could be
eliminated from Perl and people could all invent workarounds using POD, or
stuff like $comment="check counter variable here" in their code. I just
don't understand why folks are so opposed to real block comments like other
languages have (yeh yeh, I know).
The way I see it Santa (aka Larry) has asked for our wish list. This is not
the time to dwell on all the ways we can make due with our old toys.
--Michael
PS I'm all for a new list. How do I get one?
- Original Message -
From: "Tom Christiansen" [EMAIL PROTECTED]
To: "Michael Mathews" [EMAIL PROTECTED]
Cc: "Nick Ing-Simmons" [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Wednesday, August 02, 2000 5:33 PM
Subject: Re: multiline comments
What is wrong with
if (0) {
}
1) what if the block contains syntax errors?
Then the compiler carefully and courteously notifies you of such.
2) what if the bloack contains unmatched braces?
See above.
3) this is not easier to type or remember than the currently available
workarounds.
Au contraire. It's *TRIVIAL* to remember, as it requires no new syntax
and hacks and features and scoot-arounds. Likewise most of the rest
of them.
--tom
Re: RFC: Reimplement Warnings and Tainting as Pragmas
Warnings and Tainting should be reimplemented as pragmas. What part of warnings(3) and perllexwarn(1) are you in disagreement with? Not yet fully-versed on everything having todo with 5.6, appears I made a bit of an oversight (i.e., as you mention 'use warnings' is already in 5.6)! So while not necessarily a bad idea, I guess I'm a little late here. :-) Is there any interest to do this in the community with tainting? Adding a 'use tainting' to Perl 6 (or 5.7, for that matter)? -Nate
Object oriented Perl6?
I'm interested in how OO Perl 6 will be. It's very hard to develop big project in a language without OO support, so I think OO should be a very important part of Perl6. Currently alot of languages support OO very well, e.g. C++/Java/Python/JavaScript. I know that Perl6 will support OO in kernel, but how much difference with other OO language? Just read spec of ECMAScript proposals, it's very clean OO spec, I hope it can be taken into consideration when design http://www2.hursley.ibm.com/tc39/dsrdec98.htm More infomation can be got from here: http://www2.hursley.ibm.com/tc39/ Netscape has implemented JavaScript in both C and Java conform to ECMAScript standard. However it seems that currently JavaScript is only be used in browser. http://mozilla.org/js/ -- Sincerely, Wei Ye
Re: Reduce [was: Re: Random items (old p5p issues)]
In message [EMAIL PROTECTED] Gisle Aas [EMAIL PROTECTED] wrote: The upcoming Python (v2.0) introduces a builtin called zip() that does the same thing: for a,b,c in zip(aa,bb,cc): ... There are also question on how long the resulting list should be if @a, @b, @c is not of the same length. I think zip() was defined to stop when the first list runs out. I believe zip is quite a common name for this operation in functional languages. Certainly Miranda uses it to turn a tuple of lists into a list of tuples, stopping as soon as any of the lists runs out. Python also has a map function that can take multiple lists and iterate over them in sync. E.g. map(func, list1, list2, list3) where 'func' must be a function taking 3 arguments. Can't see how to easily extend perl's map in that way. Perhaps we could introduce map2, map3,... builtins? :-) This is what Miranda calls zipwith. Combined with reduce you can do things like scalar products very simply: reduce(plus, zipwith(multiply, list1, list2)) Note that Miranda actually calls reduce fold though - well actually foldl or foldr depending on which end of the list you start at. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ...Hacking's just another word for nothing left to kludge.
Re: RFC: multiline comments
On Wed, Aug 02, 2000 at 03:00:04PM -0400, Michael Mathews wrote: Ted Ashton wrote: The qc() proposal fits in well with the Perl "look-and-feel" and seems pretty comfortable to me. If there are concerns about obfuscatory potential, a use strict 'comments' could require that the qc( opening start in column one. Further, if qc were flexible about delimiters, those who prefer /* */ could write qc/* Here is a comment */; I think this may be the closest thing to being What Will Make Everyone Happy, but I'm afraid it fails in two very major ways: 1) Perl can't currently handle quote delimiters of arbitrary length. In other words the asterisks would currently be treated as part of the quote, not part of the delimiter. Any idea how to overcome this? Well hey I am sure perl6 will allow scripts in utf8, so there are plenty of unused characters yet. Graham.
Re: multiline comments
The way I see it Santa (aka Larry) has asked for our wish list. This is not the time to dwell on all the ways we can make due with our old toys. I still think saying :10,20s/^/##XXX## / is the cleanest and most visually apparent block comment. PS I'm all for a new list. How do I get one? I see no reason to have per-sub-sub-sub-topic lists. --tom
Re: RFC: variable usage warnings
Tom Christiansen wrote: The warning message "use of uninitialized value" should also disappear, to be replaced with "use of undefined value", and the warning for the purpose described in this RFC should be "use of uninitialized variable C$x". What about if there's only an expr, not a variable? For example: print $$x-methop() If the return list of the object whose ref ref is in $x is (a, undef, b), what are you supposed to say? --tom "use of undefined value". You misunderstand; I am *not* addressing the perennial complaint that the "use of uninitialized value" doesn't identify the source of the undefined value. The only reason why I mentioned that warning is because it sounds too similar to the warning I'd be adding, so I renamed the existing warning to better reflect what it means. (And that's not a new proposal either -- didn't you suggest that once?) So, roughly "symbol $main::x used only once" - "use of uninitialized variable $main::x" "use of uninitialized value" - "use of undefined value" except that the semantics of the first are slightly different. I'm not touching the second other than to reword it to be more accurate. Personally, I think that it ought to be possible to provide more information there in limited cases, but that's for another RFC that I don't care enough about to write. I'll rephrase the RFC to make this more clear. On rereading it, it does sound like I'm implying changing the undef warning.
Re: RFC: variable usage warnings
. You misunderstand; I am *not* addressing the perennial complaint that the "use of uninitialized value" doesn't identify the source of the undefined value. Ok. "symbol $main::x used only once" - "use of uninitialized variable $main::x" "use of uninitialized value" - "use of undefined value" Perhaps then "use of uninitialized value" - "use of undef as discrete value" or "use of uninitialized value" - "discrete use of undef value" --tom
Re: RFC: variable usage warnings
Updated RFC. --- =head1 TITLE variable usage warnings =head1 VERSION Maintainer: Steve Fink [EMAIL PROTECTED] for now Date: 2 Aug 2000 Version: 0.2 (unreleased) Mailing List: [EMAIL PROTECTED] Number: (unassigned) =head1 ABSTRACT "VARIABLE used only once: possible typo" should be replaced with warnings on uses of uninitialized variables (including lexicals). =head1 DESCRIPTION Perl6 should distinguish between uses and assignments to variables, and warn only when a variable is used without being assigned. In perl5 the complete program $x = 3 complains, but $x = 3; $x = 3 does not, nor does my $x = 3 nor use vars qw($x $y); $x = $z; $y = $z; It would be more useful to have a complaint for both lexical and package variables, and only when a variable is used without ever being assigned to (or having its reference taken). The warning for the purpose described in this RFC should be "use of uninitialized variable C$x". This message is too close to the existing "use of uninitialized value", but that message is badly phrased anyway, so it will change to "use of undefined value" to better reflect its actual meaning. (The two are related; "use of undefined value" can be thought of as encompassing the runtime counterpart to the compile-time "use of uninitialized variable" proposed here.) Note that if you currently depend on lexical variables having undefined values, you would need to change Cmy $x to Cmy $x = undef. This is a Good Thing. =head1 IMPLEMENTATION I have no idea how difficult this would be to implement. You just need to distinguish between lvalue and rvalue uses of a variable, I guess? But hey, this is a language RFC, not an internals RFC. :-) There's also the question of whether to properly track uses and definitions so that C$::z = $x; $x = 3 is a warning, as well as C$x = 3 if f(); print $x. Though the latter would require renaming the warning to "possible use of uninitialized variable C$x".
Re: RFC: variable usage warnings
Tom Christiansen wrote: "symbol $main::x used only once" - "use of uninitialized variable $main::x" "use of uninitialized value" - "use of undefined value" Perhaps then "use of uninitialized value" - "use of undef as discrete value" or "use of uninitialized value" - "discrete use of undef value" --tom Maybe, but I prefer to think of undef as an operator rather than a value, and those message sound to me like they're implying that undef is a value. "Discrete" also misleads me; I would ask "so you'd rather I used undef as a list?"
Re: Reduce [was: Re: Random items (old p5p issues)]
On Wed, Aug 02, 2000 at 12:22:10PM -0400, John Porter wrote:
sub interleave(\@;\@\@\@\@\@\@\@\@) {
...
}
sub mapf(;\@\@\@\@\@\@\@\@\@) {
...
}
I guess my question is, why do these need to be builtins?
sub push (\@@) { @{$_[0]} = (@{$_[0]}, @_[1..@_]); }
--
Addi Just imagine we are meeting the aliens for the first time.
ton Most people would just shoot them to see how many points they are
worth.
RE: multiline comments
I thought that that was just the plan. Form sub lists to collect ideas that needed hashing, if that hashing got involved make sub-lists to reach consensus on those. You have a nice thread handeling mail client, don-ch tom? -Corwin -Original Message- From: Tom Christiansen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 02, 2000 4:58 PM To: Michael Mathews Cc: [EMAIL PROTECTED] Subject: Re: multiline comments The way I see it Santa (aka Larry) has asked for our wish list. This is not the time to dwell on all the ways we can make due with our old toys. I still think saying :10,20s/^/##XXX## / is the cleanest and most visually apparent block comment. PS I'm all for a new list. How do I get one? I see no reason to have per-sub-sub-sub-topic lists. --tom
Re: Removing/fixing $[line noise here] variables
On Wed, Aug 02, 2000 at 01:48:36PM -0600, Tom Christiansen wrote: Isn't this covered by locales? Unicode and locales are immiscible. In Perl 5. This is *by no means* a general statement. ICU is, for instance, a Unicode locale library. -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who, "Androids of Tara"
Re: RFC: Filehandle type-defining punctuation
No: lists are the plural whatzitzes, containing zero or more singular whatzitzes. They are ordered. Arrays hold lists. I tend to agree with Tom's argument here. open() is kind of funny anyways. Why couldn't it work like this, similar to FileHandle: $fh = open $filename; print $fh "some stuff"; close $fh; It does, actually: open my $fh, $filename; print $fh "some stuff"; close $fh; Cool, eh? :-) --tom
Re: Object oriented Perl6?
wei ye wrote: I'm interested in how OO Perl 6 will be. It's very hard to develop big project in a language without OO support, so I think OO should be a very important part of Perl6. Perl 5 supports OO quite well. Read the docs by typing 'perldoc section' where section is one of: perlbootPerl OO tutorial for beginners perltootPerl OO tutorial, part 1 perltootc Perl OO tutorial, part 2 perlobj Perl objects Also read Damien Conway's "Object Oriented Perl" if you want to go further. You'll find that you can develop big projects in perl 5.
Re: RFC: Highlander Variables
On Wed, Aug 02, 2000 at 04:32:40PM +0100, Andy Wardley wrote: This would permit the rationalisation and simplification of the syntax required to access individual elements or slices of arrays and hash arrays, while remaining backwardly compatible with Perl5 syntax. This is the rationale? Sounds a bit of assault on Perl's flexibility for this little gain. As Randal said, there's no teaching advantage in it. -- "The Amiga is the only personal computer where you can run a multitasking operating system and get realtime performance, out of the box." -- Peter da Silva
Re: RFC: Filehandle type-defining punctuation
On Wed, Aug 02, 2000 at 05:31:06PM -0400, Ted Ashton wrote: But that, precisely, was my point: Arrays *and* hashes. Scalars, hashes, arrays. There's actually more than one type of plural here, gramatically: scalars hashes arrays singulardualplural (Or am I the only one left who did Ancient Greek? :) (and don't say, "because plural *means* more than one" :-). If having a filehandle character would make the code clearer, then let's do it. If it would, yes. I'm not convinced that it would. But I do concede that people see filehandles as something conceptually different from an "ordinary" scalar. -- On our campus the UNIX system has proved to be not only an effective software tool, but an agent of technical and social change within the University. - John Lions (U. of NSW)
Re: perl 6 requirements
"Randal L. Schwartz" wrote:
"Martyn" == Martyn Pearce [EMAIL PROTECTED] writes:
Martyn Possibly, although I must ask: since everything is up-for-grabs, I ask
Martyn (without implying any feeling one-way-or-tother):
Martyn How useful is the , operator in it's C-style statement separator, as
Martyn opposed to list separator guise? It seems to be a common cause of
Martyn confusion.
I use it a lot, in places where I want two expressions executed,
especially as one part of "EXPR while EXPR" or "EXPR if EXPR".
Yeah, I could use a do-block on either side, but then I might
as well go to a full while statement.
warn("too much information"), return 3 if $some_condition;
Very handy.
warn("too much information") and return 3 if $some_condition;
works, but depends on the return value of warn. I bet it would cover
most uses, though. I'd love to eliminate the comma ambiguity.
We could add a 'then' keyword.
Re: perl 6 requirements
"Steve" == Steve Fink [EMAIL PROTECTED] writes: Steve We could add a 'then' keyword. We have one. It's called "comma in a scalar context". :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: RFC: Filehandle type-defining punctuation
Scalars, hashes, arrays. There's actually more than one type of plural here, gramatically: scalars hashes arrays singulardualplural (Or am I the only one left who did Ancient Greek? :) Nope: pudge and larry, at least. (and don't say, "because plural *means* more than one" :-). If having a filehandle character would make the code clearer, then let's do it. If it would, yes. I'm not convinced that it would. But I do concede that people see filehandles as something conceptually different from an "ordinary" scalar. What about regexes? $foo = qr/blech/; Should that be /foo instead? :-) Notice how even objects use $, not something else. --tom
Re: RFC: Filehandle type-defining punctuation
Thus it was written in the epistle of Tom Christiansen, What about regexes? $foo = qr/blech/; Should that be /foo instead? :-) Notice how even objects use $, not something else. *chuckle* Ok, point conceded. Ted -- Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University == The different branches of Arithmetic -- Ambition, Distraction, Uglification, and Derision. -- Carroll, Lewis == Deep thoughts to be found at http://www.southern.edu/~ashted
Re: RFC: Filehandle type-defining punctuation
If the prefix-less form of filehandles was absent from Perl 6, I would be far less enthusiastic about my RFC. I agree; they're a kind of scalar. (Just occurred to me that one could view the % prefix of hashes as denoting a key-value pair by virtue of looking like two o's separated by a divider. Never seen this interpretation before, though.) -- Peter Scott Pacific Systems Design Technologies
Re: RFC: Reimplement Warnings and Tainting as Pragmas
Nathan Wiger writes: : Is there any interest to do this in the community with tainting? Adding : a 'use tainting' to Perl 6 (or 5.7, for that matter)? Unfortunately, tainting is a data-flow/data-typing concept, and when you try to implement data-flow/data-typing concepts with lexical scopes, you run into the same kinds of problems we ran into with my first boneheaded implementation of utf8. About the only thing you could scope with a lexical scope is whether a given input source taints its input, but that sort of decision should really be done in an OO fashion as much as possible. That is, you set it on an input stream object, not on a chunk of code. Larry
Re: RFC: Filehandle type-defining punctuation
On Wed, Aug 02, 2000 at 02:51:20PM -0400, John Porter wrote: Peter Scott wrote: Filehandles should use C* as a type prefix if typeglobs are eliminated. I missed previous discussion of this (if there was any), but it's an idea I've already thought about. It has my vote, fwiw. I have to say I prefer the "filehandles are one thing - we do the work needed to make them work with a $ prefix" idea that (if I understood correctly), tom was proposing. It already almost works with stuff like IO::File, we just need to get rid of the OO part. It changes less than having every existing script that uses typeglobs behave very strangely - even more so than if we just removed typeglobs. I'd also like some 'what are you' introspection I can do on all scalars, on a more formal basis than 'ref'. Either an expansion of the 'ref' functionality to cover filehandles, or a more general system... (said in ignorance of the internals[1], just on the Be-Nice-If logic). [1] of course we don't _have_ internals yet, so that's not a problem.
Re: RFC: Filehandle type-defining punctuation
Peter Scott writes: : If the prefix-less form of filehandles was absent from Perl 6, I would be : far less enthusiastic about my RFC. I agree; they're a kind of scalar. In fact, they're a kind of object. : (Just occurred to me that one could view the % prefix of hashes as denoting : a key-value pair by virtue of looking like two o's separated by a : divider. Never seen this interpretation before, though.) Sorry, beat you to it, barely. Camel III, page 10: (If you look carefully at the % character, you can see the key and the value with a slash between them. It may help to squint.) Actually, that was one of the reasons I picked % in the first place. Larry
