Re: Unify cwd() [was: Re: $*CWD instead of chdir() and cwd()]
Chip Salzenberg [EMAIL PROTECTED] writes: According to Michael G Schwern: In the same way that we have open() not fopen, fdopen, freopen... we can choose the safest and most sensible technique for determining the cwd and use that. And there is more than one open. Perl does have fopen/fdopen/freopen, but they're accessed through other techniques besides the name of the operator. For example, Perl spells Cfh = fdopen(5, r) as Copen $fh, =5). The unique technique is there, just pushed out of the operator name and into its parameters. And then there's sysopen(). This is exactly the point (I think) Schwern is trying to make. There is 'open', that will do most of the time. If a novice user asks how to open a file, you can say Well, just 'open $fh, $file'. If you want more than vanilla file access, there are all the other forms of open and open parameters. From the perspective of 'current directory' there should also be a simple and elegant way that will do in most cases. Advanced tricks can be made possible using separate modules and such. Maybe the basic problem is that 'current directory' is a system dependent file system location that is not a fixed string, although it usually can be represented as a string. Similar to a simple 'open', I think the most common use of 'cwd' (or whatever) is to return a file system location that can be returned to later, much in the sense of 'tell' and 'seek'. I think this can be implemented in a quite fail safe way on most platforms. -- Johan
Re: [pugs]weird thing with say ++$
Paul Johnson [EMAIL PROTECTED] writes: I think I understand the implementation details leading to each behaviour, but rather than saying which was right, I think I'd be quite happy to see Perl6 copy (the ideas behind) C's rules regarding sequence points and undefined behaviour. I'm not so sure about implementation defined and unspecified behaviour. Isn't this the old prefix-++ problem: @a = (++$i,++$i,++$i); print @a;# prints 3 3 3 -- Johan
Re: :=: (OT)
Aaron Sherman [EMAIL PROTECTED] writes: http://www.cs.tut.fi/~jkorpela/emacs-iso.html Coincidentally, last week the emacs developers decided to declare iso-accents mode (dated 1998) obsolete. Emacs 21 (out for several years now) has native support for language encodings. -- Johan
Re: CLI signature?
Hi Juerd,
[Quoting Juerd, on February 5 2005, 16:57, in CLI signature?]
signature (
Rule $pattern,
bool +$help:short('h'),
Int +$verbose :short('v'),
Str [EMAIL PROTECTED] = -
);
The actual parsing still has to happen 'somewhere else', exactly like
it is now (in module Getopt::Long). So basically what you are trying
to design is a new way to tell the future Getopt::Ultimate[tm] what
options are expected/allowed.
There seems to be one advantage: the creation of the lexicals.
However, I thing this is a very minor advantage since usually these
lexicals need to be initialized first anyway.
This does not mean that I would not encourage designing a new syntax
for Getopt::Ultimate, a syntax that sticks closely to the native perl6
syntax.
-- Johan
Re: String interpolation
Larry Wall [EMAIL PROTECTED] writes:
: my $d=a;
: print --$d--{my $d = b }--$d--\n;
Yes, that is correct.
I'm afraid things like this will keep many popular editors and IDEs
from implementing perl6 support...
-- Johan
Re: Compatibility with perl 5
Gregor N. Purdy [EMAIL PROTECTED] writes: ... that I would be perfectly happy to be required to start all my Perl 6 programs with #!/usr/bin/perl6 instead of #!/usr/bin/perl, Ten years ago I was perfectly happy to start all my perl programs with /usr/bin/perl5. Today, I would be quite unhappy if I *still* needed to do it that way. -- Johan
Re: Allison Randal is the new Project Manager
Nathan Torkington [EMAIL PROTECTED] writes: Hi, folks. As has probably been obvious to most of you, I've been really busy with my O'Reilly day job and haven't had time to attend to Perl 6 and Parrot business. With no prompting, Allison Randal stepped forward and has been taking on more and more of the day-to-day running of the show. I'm so impressed with how she's been doing that I'm officially stepping down and handing the reins to her. Best of luck to all! Thanks, Nat, and thanks, Allison! -- Johan
Re: as long as we are discussing 'nice to have's...
Dave Storrs [EMAIL PROTECTED] writes: I discovered today that I had forgotten to put 'use strict' at the top of one of my modules...it was in the script that _used_ the module, but not in the module itself. Putting it in instantly caught several annoying bugs that I'd been trying to track down. It would be nice if there was a use strict 'recursive'; Good reasoning, although this occurs to me as trying to kill a fly with a nuclear bomb. The essence of modules is that they are independent, and are unaffected by outside pragmata. This is what makes them reusable. A 'recursive' pragma would break that. -- Johan
Re: 'is' and action at a distance
Larry Wall [EMAIL PROTECTED] writes: That's part of why I named it btw in the first place. The problem with prop is it's not quite obscure enough. In the Netherlands, we have a value added tax named BTW. So it's not unlikely for financial programs to implement a btw property or method... -- Johan
Re: Apo2: \Q ambiguity
[Quoting Michael G Schwern, on May 6 2001, 22:58, in Re: Apo2: \Q ambigui] Hmmm, maybe you can point out the compose key on my keyboard, I can't find it. ;) Pick whatever you find convenient. I use the right control key. From my .Xmodmap: ! Compose key keycode 109 = Multi_key I know what Larry went through. I had to do quite a bit of work just to be able to type a £ symbol. I wound up remapping my 'option' key (that's 'alt' to you non-Mac people) to £. Compose L - for me. I still haven't managed to get my xterms to display it right and had to switch from my normal Clean font in emacs because it doesn't support high ascii to Neep. My favourite font is -dec-terminal-medium-r-normal--14-140-75-75-c-80-iso8859-1 but -misc-fixed-medium-r-normal--10-*-75-75-*-*-iso8859-1 will do as well. Note that these support ISO-8859-1. Stupid American Computers aren't quite ready for the Unicode invasion. And this is only just Latin-1... Back to Perl6! -- Johan
Re: Larry's Apocalypse 1
Graham Barr [EMAIL PROTECTED] writes:
I have not looked at SelfTest, but I have always done this with
unless (defined wantarray) {
# Self Test
}
This works because whenever a file is use'd, require'd etc. it is
evaluated in a scalar context. The main file is in a void context.
Nice. I use
if ( ! caller ) {
# selftest
}
-- Johan
Re: Schwartzian Transform
Adam Turoff [EMAIL PROTECTED] writes:
We're all for making easy things easy, but the complexities of
"map {} sort {} map {} @list" has always been befuddling to newbies,
especially when reading the code left-to-right.
I've always thought that the purpose of the Schwartzian transform was
to separate newbies from Real Programmers.
:-)
-- Johan
Re: The binding of my (Re: Closures and default lexical-scope for subs)
John Porter [EMAIL PROTECTED] writes: As someone else said before me, Perl should not be changed Just Because We Can. Aspects which have proven usefulness and are deeply engrained in the Perl mindset should not be tampered with just because some recent convert finds them un-Algol-like. Very true. But we are all familiar with Perl. While teaching Perl classes I often encounter people that have a hard time getting used to the peculiarities _we_ are familiar with. If a Perl construct does not suffer from a slight change that makes it easier to accept by new programmers, I think such changes should be seriously considered. After all, the trainees of today are the Perl programmers of the future. -- Johan
Re: assign to magic name-of-function variable instead of return
Bart Lateur [EMAIL PROTECTED] writes:
The place where it would be put, would be irrelevant.
sub readit {
POST {
close F;
}
open F, " $f" ...
scalar(F)
}
Would the POST be executed if the open fails? Why? Why not?
sub readit {
POST {
close F;
}
open F, " $f" or die;
scalar(F)
}
But I think this is getting ridiculous. $slightly_joking++; I'd
propose a much nicer and cleaner concept:
sub readit {
open F ... ;
prog1 {
scalar(F);
close F;
}
}
'prog1' executes all expressions in the block, and returns the result
of the first expression. Of course, we also need prog2, prog3, and so
on ... $slightly_joking--;
All that POST and such do, is obfuscate the flow of control. I doubt
that outweighs the small benefits.
-- Johan
Re: assign to magic name-of-function variable instead of return
James Mastros [EMAIL PROTECTED] writes:
On Thu, Feb 01, 2001 at 07:36:59PM -0600, David L. Nicol wrote:
And I always hated that about VB and Pascal -- you can assign to the magic
variable, but can't modify it.
That was before the invention of auto-assignment operators. In the
70s, Burroughs Extended Algol did it this way. So it would be
perfectly okay to write
sub foo {
foo = ...;
...;
foo += 5;
}
-- Johan
Re: Really auto autoloaded modules
Dan Sugalski [EMAIL PROTECTED] writes: The module loaded can define the routines as either regular perl subs or opcode functions (the difference is in calling convention mainly) [...] Difference in calling convention at the user level or just internal? -- Johan
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
Jonathan Scott Duff [EMAIL PROTECTED] writes: I'll just add my voice to the others. POD is more readable than XML. Don't forget: more _writable_ as well. -- Johan
Re: RFC 292 (v1) Extensions to the perl debugger
[Quoting Dave Storrs, on September 26 2000, 11:47, in "Re: RFC 292 (v1) Ext"] I'm confused...are you suggesting that the debugger should no longer be integrated into perl? Absolutely not! What I wanted to indicate is that the input and output handling of the debugger, currently line input and line output, should not be turned into a sophisticated user interface with command line recall/editing and fancy output paging (e.g. two independently scrollable windows, one for input and one for output). External tools should manage that. I mentioned the way the perl debugger runs under Emacs, ptkdb is another good example. BTW: the debugger already has command line recall/editing using Term::ReadLine. -- Johan
Re: RFC 292 (v1) Extensions to the perl debugger
Perl6 RFC Librarian [EMAIL PROTECTED] writes: The ability to easily retrieve and edit your N most recent commands to the debugger (much like a bash_history). and A better default pager. The default pager should assume a 24x80 term window ... To me, these clearly indicates that the debugger should be run as a subsystem of some other tool that takes care of this. It is not part of the debugger itself. For example, take a look at how emacs runs the debugger. -- Johan
Re: perl6storm #0050
Philip Newton [EMAIL PROTECTED] writes: so fewer "cluttering" parentheses are needed to make things readable while still being correct. Since when do parentheses make things less readable? What is your definition of readable? -- Johan
Re: perl6storm #0050
Philip Newton [EMAIL PROTECTED] writes: so fewer "cluttering" parentheses are needed to make things readable while still being correct. By the same reasoning, you can reduce the use of curlies by using indentation to define block structure. -- Johan
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
Tom Christiansen [EMAIL PROTECTED] writes:
keys %HASH = LIST;
is really
@HASH{ LIST } = ();
Hmm, is it?
I'd expect the first form to set the keys, meaning that the hash will
have _only_ the indicated keys.
The second form will only add the keys, making sure they exist, and
not affect other, already existing keys.
One can wonder what should happen to the values of existing keys.
-- Johan
Re: RFC 120 (v2) Implicit counter in for statements, possibly $#.
John McNamara [EMAIL PROTECTED] writes:
As far as I can see the current consensus is as follows:
1. Implicit variable: nice but not really worth the trouble.
2. Explicit variable between foreach and the array: might conflict
with other proposals.
3. Explicit counter in the body of the for/each loop: a clean
solution but requires a new or reused function.
What happened to the --nice, elegant and sparse array friendly--
extension of each/keys/values?
for ( ($i,$v) = each(@a) ) {
print "Value $v at index $i\n";
}
foreach ( keys @a ) {
print "Value $a[$_] at index $_\n";
}
-- Johan
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 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.
Nathan Torkington [EMAIL PROTECTED] writes: Read my lips: GOOD THING. Do we have an RFC yet that proposes Perl to be easier parsable? Damian? -- Johan
Re: RFC 132 (v1) subroutines should be able to return an lvalue
[Quoting David L. Nicol, on August 21 2000, 23:06, in "Re: RFC 132 (v1) sub"] Looks like a case for automatic dereferencing! Which Perl has always stated it would _never_ do. Well, this could be the time of changes. -- Johan
Re: Subroutines: Extend subroutine contexts to include name parameters and lazy arguments
If the C? modifier is used for a particular parameter, that parameter
is lazily evaluated. This means that it is only evaluated when the
corresponding named parameter (see below) -- or the corresponding element
of @_ -- is accessed in some way. Passing the parameter to another
subroutine or returning it as an lvalue does not count as an access.
Can this be used to implement a Jensen device:
sub work($i,?$j) {
for $i ( 1..10 ) {
print "$i: $j\n";
}
}
my $foo;
work($foo, $foo*$foo);# prints 1 4 9 16 ...
-- Johan
Re: RFC 132 (v1) subroutines should be able to return an lvalue
[EMAIL PROTECTED] (Randal L. Schwartz) writes: How do you indicate to the compiler at the time of compiling: lvsub() = FOO that FOO should be evaluated in list context? Or scalar context? In all cases but one the context is scalar anyway. The only case when the context could be list context is with lvsub() = ( ...listy thingy... ); So always enforce scalar context would not cause real pain. Or do you imagine invoking your subroutine before evaluating the right side of the code (so it can return a scalar/list flag of some kind), thereby breaking the normal model of assignment where the right side gets run first? Why not? I couldn't find in the Camel that the right side must be evaluated first (at least not where the assignment operator = is discussed according to the index). -- Johan
Re: implied pascal-like with or express
Damian Conway [EMAIL PROTECTED] writes:
Okay, what if Cwith simply aliased its hash argument to a
localized %_ (remember that one?):
with (%ws) {
print $_{height}; # prints $ws{height}
print $height; # perl5 visibility rules
};
That's only two extra characters compared to your proposal, and
*much* more Perlish.
Yes, and the gain would be zero.
IMHO, the 'with' issue is related to the 'struct' issue. The gain
would be twofold: less to type and speed of access. Personally, I
think the latter is more important. With pseudo-hashes (or structs, do
we have structs yet?) the compiler can compile the field reference into
a direct access.
-- Johan
Re: Ideas that need RFCs?
"Stephen P. Potter" [EMAIL PROTECTED] writes: * Socket functions (such as Caccept, Cbind, etc) should be moved from the core to modules/libraries. * Math functions (such as Cabs, Catan2, Ccos, etc) should be moved from the core to modules/libraries. * IPC functions (such as Cmsgctl, Csemctl, Cshmctl, etc) should be moved from the core to modules/libraries. * "User" functions (Cgetpw*, endpw*, Csetpw*, Cgetlogin) should be moved from the core to modules/libraries. * Group functions (Cgetgr*, Cendgr*, Csetgr*) should be moved from the core to modules/libraries. * Network functions (Cgetnet*, Cgethost*, Cgetproto*, etc) should be moved from the core to modules/libraries. * Process functions (Cgetpgrp, Cgetppid, Cgetpriority, Csetpgrp, Csetpriority) should be moved from the core to modules/libraries. I don't think this has anything to do with the language. Whether a function is built-in, known, loadable, findable, user-defined, or whatever makes no difference from language perspective. See RFC26. From implementation perspective, yes, it makes sense. -- Johan
Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)
Jarkko Hietaniemi [EMAIL PROTECTED] writes: Access details like this are largely independent of the logical manipulations made with pathnames. I can claim that there is "/foo/bar/zap.txt" and I can say that file directory part is "/foo/bar", but whether such an entity really exists, is a different matter. @parts = qw(sy $ foo bar 262); Now, create a file in the same directory with the same type, and name blech. Any idea? -- Johan
Re: Portable upper/lower case regexp matches
Jason Elbaum [EMAIL PROTECTED] writes:
Perl regexps support the following features, though they're a bit
obscure to my tastes...
(from perlre:)
\l lowercase next char (think vi)
Actually, this has little to do with regexes, it a string issue.
...but Perl doesn't offer a regexp pattern to match all alphabetical
characters of a particular case. Something like:
\x match lowercase alpha char
\X match uppercase alpha char
Well, take your pick:
[:lower:] and [:upper](POSIX, e.g., /[[:islower:]]+/)
\p{IsLower} and \p{IsUpper} (UNICODE, e.g., /\p{IsLower}+/)
It's all in 5.6. See PP3, pp 167 and up.
-- Johan
Re: Proposal for \v and \V, the small- and large- cut regex opera tors.
On Thu, Aug 10, 2000 at 07:04:50AM -0400, Ilya Zakharevich wrote:
$quoted = qr/(['"]).*?\2/;
@a = $str =~ /($quoted)/gp;
Here //p is the "postponed" flag. Put (?p{$quoted}) instead of
$quoted to get this semantic now (or some other char).
$quoted = qr/(['"]).*?\1/;
@a = $str =~ /(??{$quoted})/g;
does the trick, thanks!
-- Johan
Re: Proposal for \v and \V, the small- and large- cut regex opera tors.
On Thu, Aug 10, 2000 at 04:42:56AM -0400, Ilya Zakharevich wrote:
These are just user-defined ops. You should be able to overwrite the
normal ops, as in:
sub match_all {
use re_ops 'overload_usual_ops';
"(" . group(1, [ 'a' .. 'z' ] * [3,5] ) . ")"
}
Will this go?
I think so.
Of course, we need group names (trivial), and group temporaries.
I needed the latter to define a generic pattern to match quoted strings:
you need to store the starting quote somewhere to find the ending quote,
but I didn't want this to have impact on the pattern as a whole. E.g.,
$qp = qr/((['"]).*?\2)/;
@a = $str =~ /$qp/g;
and have @a contain only the quoted strings, and not (also) the individual
quotes.
Variable interpolation can be handled using Damian's curried expressions.
On XRay:
Summary for query "curried;Damian":
found 0 matches in 0 files.
http://tmtowtdi.perl.org/rfc/23.pod
-- Johan
Re: Proposal for \v and \V, the small- and large- cut regex opera tors.
On Wed, Aug 09, 2000 at 04:20:32PM -0400, Ilya Zakharevich wrote:
It is not clear though how to design concise-but-no-line-noise
notation for \w etc. But qr/ \( ( [a-z]{3,5} ) \) / may become
"(" (.) group(1, [[ 'a' .. 'z' ]] (*) [3,5] ) (.) ")"
here (.) is the ASCII substitution for the UNICODE "REx concatenate"
char, similarly for [[. ]] and (*). (The chars may be borrowed from
the math repertoire.)
Hmm. Looks nice. How about pattern functions, e.g.,
sub match_all : pattern {
"(" . group(1, [ 'a' .. 'z' ] * [3,5] ) . ")"
}
Variable interpolation can be handled using Damian's curried expressions.
-- Johan
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
On Sun, Aug 06, 2000 at 01:10:23PM -0700, Nathan Wiger wrote:
So you see why we need a persistent format() function. However, I think
your real issue is a one-time call that just changes the format
temporarily:
print $date-strftime('%H:%M'); # print the time
print "$date"; # without touching this
Indeed.
I'll put strftime() back in, I think that's probably the best thing for
this.
strftime sounds like a real Unixism to me. 'set_format' and 'format' looks
more neutral and at least as effective.
-- Johan
Re: RFC 37 (v2) Positional Return Lists Considered Harmf
The solution is simple: return hashes instead of lists.
Hash ref, I may hope?
localtime-{year}
-- Johan
Re: @a = @b || @c
Peter Scott [EMAIL PROTECTED] writes:
@a = @b || @c should 'work'. In P5 it puts @b in scalar context and
thus evaluates as the number of elements in @b if there are any.
Define 'work'.
if (@b) { @a = @b } else { @a = @c }
$a[$_] = $b[$_] || $c[$_] foreach (0..max(@a,@b,@c))
...other...
-- Johan
Re: RFC 48 (v1) Replace localtime() and gmtime() with da
Perl6 RFC Librarian [EMAIL PROTECTED] writes:
I like this proposal, although I do have a lot of remarks.
Consider them constructive!
The C$time specifier can be followed by a C$timezone argument,
s/$time/$format/
which returns the date relative to that timezone. By default, the time
is returned relative to the local timezone. You can get UTC, for
example, by specifying CUTC or CGMT as the timezone.
Allow numeric (e.g. minutes? seconds?) displacement?
This would also allow
$tomorrow = date(undef,undef,24*60*60);
$object = date time, undef, 'GMT';# return object in UTC
s/UTC/GMT/
GMT is not UTC (although it is equal for most practical purposes).
$hour = 0 .. 24
$min = 00 .. 59 # 0-padded
$sec = 00 .. 59 # 0-padded
Why 0-padding? The only reason to add this is out of frustration due
to localtime's behavior. With the new date function you'll never need
to call
sprintf("%02d/%02d/%04d", $tm[3], $tm[4]+1, $tm[5]+1900);
since you can do
date(undef,"%d/%m/%Y")
or something alike.
Also, why not space-pad the mday?
$isutc = 1 or undef; # is UTC? (see below...)
$tz= PST|UTC|...; # timezone
Isn't $isutc identical to ($tz eq 'UTC')?
A list of date/time values is returned. The ordering and format of these
values has been radically changed to reflect what most of us probably
view as "ordinary":
($mday, $mon, $year, $hour, $min, $sec, $msec, $nsec,
$wday, $yday, $isdst, $isutc, $tz) = date;
This ordering is very easy to remember, in my opinion,
I'd argue that
($year, $mon, $mday, $hour, $min, $sec, $msec, $nsec,
is much easier to remember, since it is a series of continuous
decrasing magnitudes.
$t-mon # based at 1
$t-_mon # based at 0
Why? Is it so hard to write $t-mon-1?
$t-year # based at 0 (year 0 AD is, of course 1 BC).
$t-_year # year minus 1900
What would year minus 1900 be good for?
$t-wday # based at 1 = Sunday
$t-_wday # based at 0 = Sunday
Same here.
$t-hms # 01:23:45
AM or PM? Or 24h clock?
And why is the hour padded with a leading zero, while that is not the
case with the $hour value in list and other contexts.
$t-ymd # 2000/02/29
$t-mdy # 02/29/2000
$t-dmy # 29/02/2000
Hmm. A lot of duplicate information. And how about
$t-hms # 01:02:33
Wouldn't it be better to have a formatting method, like
$t-format("%m/%d/%Y")# 29/02/2000
$t-format# uses preset format, same as "$t"
and rename your $t-format to $t-set_format?
$t-isutc # in UTC time?
$t-tz# timezone (also $t-timezone)
Again, 'isutc' looks superfluous to me.
But I would like to have 'tzsec' (the #seconds displacement for this
timezone).
The C$tz variable might seem hard at first. It's not. There are only 2
possible values:
1. UTC or other timezone (user specified)
2. Local timezone (none specified)
So, all that would have to happen is Cdate() would have to store the
correct value in the return object, in the precendence above.
Huh? If the user specifies 'PST' you have to _know_ what 'PST' means.
-- Johan
Re: RFC 42 (v1) Request For New Pragma: Shell
Perl6 RFC Librarian [EMAIL PROTECTED] writes: There are times when one may need (or desire) to change the shell used for interpretation, as well as force shell interpretation, regardless of optimization, for consitency's sake. print `fancysh -c 'your uninterpreted and unoptiomized shell command'`; Or am I overlooking something? -- Johan
Re: New Group proposed: subs (was Re: named parameters)
"Kyle R . Burton" [EMAIL PROTECTED] writes: use self = 'self'; use self = 'this'; Of course, if you _really_ want to avoid religious wars, you would need a non-selfish pragma name in the first place. -- Johan
Preprocessing (Was: Re: Recording what we decided *not* to do, and why)
Russ Allbery [EMAIL PROTECTED] writes: However, cpp has the significant advantage that its active syntax is designed to be embedded in a programming language and are Perl comments. This is *not* true of m4, which would be horribly, horribly confused by a Perl script. I fail to see this point. Having a program depend on a preprocessing stage that, if skipped, would still result in valid but erroneous source seems dangerous to me. m4 was not designed with embedding in a programming language in mind, and lots of things like macro invocation syntax and default quoting characters would interact very poorly with Perl. I wouldn't classify the cpp language (#ifdef #define #include) friendly to C either. It looks as if they happily co-exist since invoking the C compiler automatically invokes the preprocessor. But let's not put energy in a cpp versus m4 discussion. External macro processors exist and can be applied by suffienciently skillful people anyway. I think the question we must ask ourselves is: what kind of preprocessing would we like perl to provide automatically. Also, I think that preprocessing only plays a relevant role if we have byte compiling. There a few advantages of a preprocessor if preprocessing/compilation/execution are _always_ done together. -- Johan
Sublist auto*
[The original subject was: Sublist autosubscribe, but that was rejected by the mailing list manager.] I would plea for autosubscribing perl6-language list members to every sublist that gets spawned. The reason is continuity. Currently, when a new sublist is announced, it takes some time to get subscribed (usually my first 3 or 4 attempts fail since the list does not exist yet) and when I wait a while and the subscription succeeds, I already have missed several messages. Autosubscribing would solve this, especially since it is trivial to unsubscribe when one is not interested in a particular thread. An alternative solution is to automatically sent all messages that have been posted to the sublist so far, upon subscription. -- Johan
Re: RFC 25 (v1) Multiway comparisons
John Porter [EMAIL PROTECTED] writes: I think this should mean what it means in Icon, namely, that $x $y evaluates to false if $x = $y, and evaluates to "$y (but true)" if $x $y. Icon also allows $x == ( 1 | 2 ), meaning ($x == 1) || ($x == 2). -- Johan
Re: Recording what we decided *not* to do, and why
John Porter [EMAIL PROTECTED] writes: But a standardized macro facility would be nice. Although -- wouldn't it have to parse perl? Or else have a wholly distinct grammar? Several macro processors exist and are easily available. I do not see the need to duplicate (parts of) their functionality in perl. Personally, I'd even trow out -P. -- Johan
Re: Recording what we decided *not* to do, and why
Tom Christiansen [EMAIL PROTECTED] writes: While a function style or quoted form comment might seem clever, and even Perlish due to its syntax, it doesn't help the author of the code/comments readily distinguish them. What good are comments if you can't find them when you need them? Sounds like an argument for :10,20s/^/###/ style comments. Hurray! -- Johan
Ops versus subs (Was: Re: RFC: Higher resolution time values)
Larry Wall [EMAIL PROTECTED] writes: Theoretically, we'd like to make subs run as fast as ops. I'd say that the distinction between subs and ops should be dropped completely. Ops can be used as subs, subs as ops. The only distinction in the way either is used. We may need a better way to define function prototypes, though. -- Johan
Redesigning regex syntax (Was: Re: RFC for recursive regexps)
Damian Conway [EMAIL PROTECTED] writes: Of course, that example might in itself be sufficient reason to completely redesign the regex syntax! Perl uses the term "pattern matching" since day one. This opens the possibility of extending pattern matching with other, not neccessarily regex based, mechanisms. In particular, I'd like to be able to tack variables and functions to pattern elements. For example (the syntax is irrelevant): (:func($x1,$x2,$x3): # will be called if this pattern succeeds (:$x1:...pattern...) # $x1 gets the value of this sub match ...maybe more... (:$x2:...pattern...) # $x2 gets the value of this sub match (:$x3:...pattern...) # $x3 gets the value of this sub match ...you get the idea by now... ) Two cases are possible: one that does the assignments and calls only when the complete pattern succeeds, and one that does it when the sub-pattern succeeds (which may be multiple times is backtracking is involved). SNOBOL lovers will recognize the behavior of the '.' and '$' operators that tie variables to pattern elements. -- Johan
Re: Expanding the language primitives (was: Re: Reduce [was: Re: Random items (old p5p issues)])
Dan Sugalski [EMAIL PROTECTED] writes: More importantly, the more primitives that perl provides, the wilder and more useful things people will be able to do. Not quite. Its the functions that are provided that matter, not whether they are primitives or not[1]. A small set of primitives with a large set of functions is more powerful than just a moderate set of primitives. Compare with Emacs: a relatively small set of powerful built-ins and a plethora of lisp functions for everything else. -- Johan [1] Tentative terminology: primitive: a function built directly into perl function: a function loadable into perl module:a (collection of) functions written in Perl
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: 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
