Re: Variable attributes (was Re: RFC 355 (v1) Leave $[ alone.)

2000-10-01 Thread John Porter
Jeremy Howard wrote: I haven't got around to RFCing the more generic version (that all attributes are inherited inside nested data types), but that would certainly be a nice approach. Not to confuse, let's call it cascading instead of inheritance. -- John Porter

Re: English language basis for throw

2000-08-16 Thread John Porter
, especially wrt Perl. :-/ -- John Porter

Re: $a in @b (RFC 199)

2000-09-14 Thread John Porter
be confused or conflated. We just need to clear up what kind of block grep/map use: either a true sub (which I favor), or a distinct kind, with its own early exit keyword(s). -- John Porter We're building the house of the future together.

Re: RFC 69 (v2) Standardize input record separator (for

2000-08-10 Thread John Porter
of people; and the majority of people reading text files are reading platform-native text files. -- John Porter

Re: RFC 101 (v2) Handlers and Pseudo-classes

2000-09-13 Thread John Porter
. Just MHO. -- John Porter

Re: RFC 144 (v1) Behavior of empty regex should be simple

2000-09-13 Thread John Porter
John Porter wrote: Mark Dominus [EMAIL PROTECTED]: This behavior should be changed. If the PATTERN is empty, Perl should look for the empty string. (That is, if the PATTERN is empty, it should always match.) Except perhaps for undef loperands? (matchees? bindees?) What did you

Re: RFC 98 (v1) context-based method overloading

2000-08-15 Thread John Porter
David Nicol [EMAIL PROTECTED]: The other way C++ allows you to overload a named function is by return type. This is explicitly incorrect. The return type is not used in the resolution of an overloaded function. That's not to say that it wouldn't be nice to have in perl... -- John Porter

Re: RFC: lexical variables made default

2000-08-02 Thread John Porter
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: RFC: lexical variables made default

2000-08-02 Thread John Porter
with something like "var global". Extra verbosity required for globals might be A Good Thing. -- John Porter

Re: Reduce [was: Re: Random items (old p5p issues)]

2000-08-02 Thread John Porter
{ $_-[$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: multiline comments

2000-08-02 Thread John Porter
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

Re: multiline comments

2000-08-02 Thread John Porter
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: multiline comments

2000-08-02 Thread John Porter
semantics of scalar literals in void context, to be silently ignored. Then you can make a comment any way you want. -- John Porter

Re: multiline comments

2000-08-02 Thread John Porter
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

2000-08-02 Thread John Porter
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: RFC: lexical variables made default

2000-08-02 Thread John Porter
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

Re: RFC: multiline comments

2000-08-02 Thread John Porter
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: multiline comments

2000-08-02 Thread John Porter
nt # + $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

2000-08-02 Thread John Porter
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: Reduce [was: Re: Random items (old p5p issues)]

2000-08-03 Thread John Porter
the other guy who made an argument like this in seriousness earlier gets the point...] -- John Porter

Re: A Unicode fallacy [Was: Re: RFC: multiline comments]

2000-08-03 Thread John Porter
Glenn Linderman wrote: Stick with characters in the normal character set of the author of the script, except for forays into the language of the users of the script. Good advice for the programmer, perhaps; but it should not be perl's job to enforce that discipline. -- John Porter

Re: RFC: lexical variables made default

2000-08-03 Thread John Porter
Tom Christiansen wrote: OTOH, being fun (which I admit it is) is one of the reasons many people don't want to think Perl is a serious language. So we shouldn't argue for a feature simply because it's fun, especially when the counterargument includes increased acceptability. -- John Porter

Re: RFC stuff

2000-08-03 Thread John Porter
..at least if new newsgroups appear, you get notified about it! Speaking of which, I believe the plan was to announce new list creations on perl6-announce; can someone confirm that this is actually happening? -- John Porter

Re: RFC: lexical variables made default

2000-08-04 Thread John Porter
Bart Lateur wrote: On Thu, 3 Aug 2000 10:48:17 -0400, John Porter wrote: OTOH, being fun (which I admit it is) is one of the reasons many people don't want to think Perl is a serious language. I don't agree. The problem is somewhere else, namely the problem that Ilya Z. brought up

Re: RFC 28 (v1) Perl should stay Perl.

2000-08-04 Thread John Porter
think Perl would be Better for having it. -- John Porter Aus tiefem Traum bin ich erwacht.

Re: Recording what we decided *not* to do, and why

2000-08-04 Thread John Porter
powerful than the other? -- John Porter

Proto-RFC: A Standard Always-Live Preprocessor

2000-08-04 Thread John Porter
programmers want to bother with the extra two keystrokes! Or perhaps more the point, -P is essentially never used in any of the canonical code examples, books, etc. -- John Porter Aus tiefem Traum bin ich erwacht.

Re: RFC 15 (v1) Stronger typing through tie.

2000-08-07 Thread John Porter
Nick Ing-Simmons wrote: John Porter [EMAIL PROTECTED] writes: my integer $quux = 4; I believe that would have to be integer my $quux = 4; at least in perl5... Well Larry has been using my Dog $spot; for a while. O.k., I see that now; I was thinking 'integer

Re: RFC 23 (v1) Higher order functions

2000-08-07 Thread John Porter
? $root-traverse({$sum += __}); That has mnemonic value, since it looks kinda like an anonymous sub... -- John Porter

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

2000-08-07 Thread John Porter
Jeremy Howard wrote: Yes, I change my mind sounds of gears clicking I like the '^' prefix too. The difficulty of reading __ would be a pain. But what happens here? /^__foo/ Or here? /^{__}foo/ Is the latter sufficiently unambiguous? -- John Porter

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

2000-08-07 Thread John Porter
. '__' is already a valid package name, or sub name, for examples. -- John Porter

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

2000-08-07 Thread John Porter
Has anyone suggested '*'? Since its use for typeglobs is (repsumably) going away, it's available (right?). It the "wildcard" mnemonic value is consistent with "placeholder". -- John Porter

Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)

2000-08-07 Thread John Porter
Jeremy Howard wrote: Yes, they're not identical. What I mean of course is: (..-1) == reverse(map -__ (1..)); WHAT? So the semantics of .. are magically different in the context of (..$n) so as to produce numbers in descending order? I don't think so. -- John Porter

Re: RFC 55 (v1) Compilation: Remove requirement for fina

2000-08-07 Thread John Porter
Nathan Torkington wrote: John Porter writes: Compilation: Remove requirement for final true value in require'd and do'ed files Do not. I use this feature. Is there any reason you couldn't use "die" instead? ??? Throw an exception in order to return a (0|'')-but-

Re: RFC 54 (v1) Operators: Polymorphic comparisons

2000-08-07 Thread John Porter
. The semantics of == vs eq is currently very well defined and distinct. The proposal muddies the distinctions. The thing that allows you to LOL is precisely the thing which should motivate us to not reduce Perl's already low orthogonality quotient without very compelling reasons. -- John Porter

Re: ISA number

2000-08-07 Thread John Porter
the RFC is even issued! -- John Porter

Re: RFC 55 (v1) Compilation: Remove requirement for fina

2000-08-07 Thread John Porter
y 1 of his perl course. -- John Porter

Re: RFC 55 (v1) Compilation: Remove requirement for fina

2000-08-08 Thread John Porter
-import('bar'); which implicitly occurs? -- John Porter

Re: RFC 59 (v1) Proposal to utilize C* as the prefix t

2000-08-08 Thread John Porter
one. That's sort of a special case. What happens with multiple END blocks? perl must compile them and stash them in the END symbol, chained somehow. -- John Porter

Re: sub optional for BEGIN: bad idea

2000-08-08 Thread John Porter
t parsable, pretend that BEGIN and END are the names of functions with prototype () which register callbacks. I agree ... except that, in perl5 at least, you'd need a terminating semicolon if that analogy were 100% accurate. -- John Porter

Re: RFC 48 (v2) Objects should have builtin stringifying

2000-08-08 Thread John Porter
'MyClass', $val; # we're not in a string context We already have scalar(). We should also have string(), void(), etc. for the "intrinsic" contexts. -- John Porter

Re: RFC 64 (v1) New pragma 'scope' to change Perl's defa

2000-08-08 Thread John Porter
Ariel Scolnicov wrote: I rarely use a `now' scope, Well, 'now' is a declaration; the scope is "temporal", aka "dynamic". Variable declaration is good (except for some trivial programs)! I agree 1000%! -- John Porter

Re: RFC 48 (v2) Objects should have builtin stringifying

2000-08-08 Thread John Porter
Jonathan Scott Duff wrote: And what about user-defined contexts? (my Dog $spot = some_func();) I think a context coercion operator would do just fine. Oh, I agree entirely! But the intrinsic contexts should have concise operators (e.g. scalar()). -- John Porter

Re: RFC 48 (v2) Objects should have builtin stringifying

2000-08-09 Thread John Porter
= bless {}, 'Foo'; $s = "$r"; ref($s); # True. $s-bar; # call method of Foo. I guess that means the deref operator would have be implicitly overloaded for strings... -- John Porter

Re: RFC 58 (v1) Cchomp() changes.

2000-08-09 Thread John Porter
chomp; $x{ $_ . $y }; } } -- John Porter

Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)

2000-08-09 Thread John Porter
Ted Ashton wrote: John Porter: What would be the output of the following program: $\ = "\n"; $i = 0; for ( .. -1 ) { $i++; last if $i 2; print } If the answer is (as I suspect), "This never prints an

Re: RFC 79 (v1) Code which is both executable and POD.

2000-08-09 Thread John Porter
executable code into a commenmt, rather than how to get executable code out of the program That's a very astute observation; and it's why the solutions may reasonably be independent. -- John Porter

Re: RFC 79 (v1) Code which is both executable and POD.

2000-08-09 Thread John Porter
not attempt to address the in-line comments issue -- and would fail if it did try, because that is a issue with the whole of POD, even in the absence of RFC 79. -- John Porter

Re: RFC 79 (v1) Code which is both executable and POD.

2000-08-09 Thread John Porter
as =for perl-code pod sub foo($\@%) { #... } The latter type: print =for perl-string pod Help is on the way. ; -- John Porter Aus tiefem Traum bin ich erwacht.

Re: chomp unchomp

2000-08-09 Thread John Porter
Bryan C. Warnock wrote: Chomp removes one or more line separators from the end. It does? You're using a different version of Perl than I am. -- John Porter

Re: RFC 79 (v1) Code which is both executable and POD.

2000-08-09 Thread John Porter
Uri Guttman wrote: "JP" == John Porter [EMAIL PROTECTED] writes: JP Maybe what's needed is two distinct perl pod processor types, one JP which passes on the text literally to the compiler, and one which JP wraps it up like a string literal. JP pri

Re: RFC 73 (v1) All Perl core functions should return ob

2000-08-09 Thread John Porter
Johan Vromans wrote: Be reminded that Perl++ will increment Perl, but return the _current_ value. Heh, at least we're not python = python + 1 -- John Porter

Re: RFC 80 (v1): Exception objects and classes for builtins

2000-08-10 Thread John Porter
: try { } catch Exception::Thingy, Exception::Whingy with { -- John Porter

Re: RFC 80 (v1) Exception objects and classes for builti

2000-08-10 Thread John Porter
t so "catch" takes a list of 0 or more exception class names. -- John Porter

Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)

2000-08-10 Thread John Porter
in the opposite order. (..-1) should generate -INF first, but obviously it can't do that. (..$n) is an impossible construct, and should be a fatal error -- presuming it even gets past the lexer... -- John Porter

Re: RFC 80 (v1): Exception objects and classes for builtins

2000-08-11 Thread John Porter
to rethrow unhandled exceptions, you can always catch { die } -- John Porter

Re: RFC 76 (v1) Builtin: reduce

2000-08-11 Thread John Porter
Damian Conway wrote: More and more I lean towards a scalar-only reduce. Yep! Simpler semantics and you can always ref a L(OL(OL(OL...etc.))) if you need multidimensionals. Combined with highlander variables, and there ceases to be a problem. -- John Porter

Re: RFC 76 (v1) Builtin: reduce

2000-08-11 Thread John Porter
ly. Huh? It's significantly shorter. It's one statement vs. three, and requires no temporary variables. Would it be faster? I doubt it. What do you base that on? The fact that the reduce() version would involve so many more costly perl OPs? -- John Porter

Re: Against overloading || and (RFC 20) -- we just need lazy evaluation

2000-08-11 Thread John Porter
Bart Lateur wrote: Actually, we don't need it. All we need, is lazy evaluation. The idea comes from Lisp, No, that's no good; lazy evaluation was necessitated by functional programming, which of course perl should avoid like the plague... -- John Porter

Re: RFC 90 (v1) Builtins: zip() and unzip()

2000-08-11 Thread John Porter
Andy Wardley wrote: cleave()? Note that cleave is its own antonym! :-) -- John Porter

Re: RFC 90 (v1) Builtins: zip() and unzip()

2000-08-11 Thread John Porter
, @args, %hey; (Well, I guess that's two: the assignment is an op also.) -- John Porter

Re: RFC 79 (v2) Perl Compiler is Just Another Pod Proces

2000-08-11 Thread John Porter
ed by pod processors, but maybe I'm out of it: =begin data =end foo more data =end data Now, I suppose that =data would be a synonyms for =end all begin data, and would be a replacement for __DATA__ -- John Porter

Re: RFC 84 (v1) Replace = (stringifying comma) with =

2000-08-11 Thread John Porter
Nathan Wiger wrote: ...if the "key" and "value" builtins were the only ways to get to the data. You should be able to get to the data directly. How about: $array[0].k $array[0].v -- John Porter

Re: RFC 84 (v1) Replace = (stringifying comma) with =

2000-08-11 Thread John Porter
an assoc. array, with no extra support required in the core; deep and special-case comparisons can be supplied by the user. -- John Porter Aus tiefem Traum bin ich erwacht.

Re: RFC 80 (v1): Exception objects and classes for builtins

2000-08-11 Thread John Porter
Chaim Frenkel wrote: Let the object determine the calling convention for the method. I see very little reason to have two methods with different signatures. Yes! That's the Perl philosophy! Right on! -- John Porter

Re: RFC 83 (v1) Make constants look like variables

2000-08-14 Thread John Porter
"I hate that in ..." type comments. You forget... There have been numerous cases of people saying things like "that's what Python [or Java] calls those functions, so we should call them something else." -- John Porter

Re: RFC 102 (v1) Inline Comments for Perl.

2000-08-15 Thread John Porter
t, e.g. "eat me", than the tiny bit of syntax that creates the comment. And ## is surely a tiny bit of syntax. (Or else I let my editor look for comments; and /qc is no harder to type than /#.) Plus it has the advantage of not introducing any new syntax, only the qc// operator. But this has all been said before, and I apologize. -- John Porter

Re: RFC 104 (v1) Backtracking

2000-08-15 Thread John Porter
, "andthen" doesn't seem like a good choice. Other possibilities: therefore implies segue seq so -- John Porter

Re: RFC 84 (v1) Replace = (stringifying comma) with =

2000-08-15 Thread John Porter
Stephen P. Potter wrote: Lightning flashed, thunder crashed and John Porter [EMAIL PROTECTED] whispered : | Here's a counter-proposal: throw out hashes as a separate internal | data type, and in its place define a set of operators which treat | (properly constructed) arrays as associative

Re: RFC 105 (v1) Downgrade or remove In string @ must be \@ error

2000-08-15 Thread John Porter
relaxation of strictness in a special context (interpolation) makes me uneasy... -- John Porter

Re: RFC 109 (v1) Less line noise - let's get rid of @%

2000-08-15 Thread John Porter
at the lexical level. Get rid of "$" too. x is a symbol; perl can look up what it means. -- John Porter

Re: RFC 109 (v1) Less line noise - let's get rid of @%

2000-08-15 Thread John Porter
which would eliminate distinguishing symbols, and/or the things they distinguish, is on the wrong track, eh? Yep. -- John Porter

Re: RFC 109 (v1) Less line noise - let's get rid of @%

2000-08-15 Thread John Porter
ially zero information. "We want to get rid of linenoise because the other language X does not have linenoise" is kind of poor argument because it easily draws the retort "Well, you know where to find X is, then. This is Perl." I agree. I've never used that argument. At le

Re: RFC 109 (v1) Less line noise - let's get rid of @%

2000-08-15 Thread John Porter
Dan Sugalski wrote: Tossing the worthless and confusing ones is good. Tossung the useless and distinguishing ones is bad. Uh, which ones did you have in mind, by "useless and distinguishing"? ;-) -- John Porter

Re: RFC 109 (v1) Less line noise - let's get rid of @%

2000-08-15 Thread John Porter
represent, the LESS information it carries; and there will come a point -- when perl6 is released, if not sooner -- when the symbol will be essentially content-free. So get rid of it. It's a waste. -- John Porter

Re: RFC 84 (v1) Replace = (stringifying comma) with =

2000-08-15 Thread John Porter
inherent capabilities give you faster response times, and quicker comprehension. Sure. But "instinct and inherent capabilities" do not apply here. -- John Porter Aus tiefem Traum bin ich erwacht.

Re: RFC 109 (v1) Less line noise - let's get rid of @%

2000-08-15 Thread John Porter
Dan Sugalski wrote: If the symbol becomes content-free, perhaps the problem is with what made it useless, not with the symbol itself... Yes! -- John Porter

Re: RFC 109 (v1) Less line noise - let's get rid of @%

2000-08-15 Thread John Porter
John Porter wrote: Dan Sugalski wrote: If the symbol becomes content-free, perhaps the problem is with what made it useless, not with the symbol itself... Yes! But that's not to say I agree that certain proposals which would have the effect of rendering the symbol useless

Re: RFC 104 (v1) Backtracking

2000-08-16 Thread John Porter
Damian Conway wrote: So how is that different from: do BLOCK1 until do BLOCK2 ??? Because if BLOCK1 ever evaluates to False, the operation terminates. It's more like do { r = f1() } until ( not r or f2() ); -- John Porter

Re: RFC 84 (v1) Replace = (stringifying comma) with =

2000-08-16 Thread John Porter
actic cues -- [] vs {} -- is so limited, it would be better to have just one, and let the user bind the indexing scheme to the variable. -- John Porter

Re: RFC 84 (v1) Replace = (stringifying comma) with =

2000-08-16 Thread John Porter
some pathological behavior of the hashing function. -- John Porter

Re: English language basis for throw

2000-08-16 Thread John Porter
Peter Scott wrote: At 05:33 PM 8/15/00 -0400, John Porter wrote: The thing I don't like about C++/Java try/catch syntax is the way the blocks are daisychained. That is not intuitive to the flow. I find it quite intuitive :-) I note the smiley. What interpretation should be placed

Re: RFC 104 (v1) Backtracking

2000-08-16 Thread John Porter
Johan Vromans wrote: So how is that different from: do BLOCK1 until do BLOCK2 It's the same. No, not quite. See my other post. -- John Porter

Re: RFC 109 (v1) Less line noise - let's get rid of @%

2000-08-16 Thread John Porter
hould all be equally reasonable: $s = "$obj"; # convert to string $n = $obj+0; # convert to number $x = $obj[1]; # convert to array $x = $obj{y}; # convert to hash -- John Porter

Re: RFC 109 (v1) Less line noise - let's get rid of @%

2000-08-16 Thread John Porter
dexed by string" is not. -- John Porter

Re: RFC 109 (v1) Less line noise - let's get rid of @%

2000-08-16 Thread John Porter
a myth. The punctuation imposes context on the variable expression. $foo[0] accesses an array. Where's the "@"? -- John Porter

Re: RFC 109 (v1) Less line noise - let's get rid of @%

2000-08-16 Thread John Porter
Jonathan Scott Duff wrote: Gee, I'd hate to lose simple assignment to a hash from a list. foo %= bar; Hmm, I think I need to write an RFC! -- John Porter

Re: RFC 109 (v1) Less line noise - let's get rid of @%

2000-08-16 Thread John Porter
eminently feasible. sub FETCH { my( $self, $key ) = @_; my @indices = split $;, $key; ... } (I do something like this in my Tie::Multidim module :-) -- John Porter Aus tiefem Traum bin ich erwacht.

Re: RFC 109 (v1) Less line noise - let's get rid of @%

2000-08-16 Thread John Porter
John Barnette wrote: John Porter wrote: The punctuation imposes context on the variable expression. $foo[0] accesses an array. Where's the "@"? It accesses an *element* of the array, which is a scalar. Still, the "$" does not describe the type of

Re: RFC 109 (v1) Less line noise - let's get rid of @%

2000-08-16 Thread John Porter
so stringize the key: my $index = "$_[0]"; ... -- John Porter

Re: RFC 109 (v1) Less line noise - let's get rid of @%

2000-08-16 Thread John Porter
Nathan Torkington wrote: John Porter writes: foo $= ( bar, quux ); # provide scalar context to both sides foo @= ( bar, quux ); # provide list context to both sides I assume you've dropped this idea as well, given the argument that you would be dropping prefix symbols

Re: RFC 109 (v1) Less line noise - let's get rid of @%

2000-08-16 Thread John Porter
personal taste is not a valid rhetorical device in this forum. Or at least it shouldn't be allowed to be. Clearly we all stand by RFC0. That should go without saying, just like RFC0 itself. /soapbox -- John Porter

Re: RFC 109 (v1) Less line noise - let's get rid of @%

2000-08-16 Thread John Porter
ow it does. It doesn't help anyone to write "@var". Similarly, in bar = unshift(hats, foo); "Okay, Chats is obviously a list, but is it shifting in a scalar or a list of things? And is it assigning to another list or a scalar to get the new list lenghth?" You are ask

Re: RFC 109 (v1) Less line noise - let's get rid of @%

2000-08-17 Thread John Porter
Ariel Scolnicov wrote: John Porter [EMAIL PROTECTED] writes: foo = bar; foo could be just about anything: a string, a hashref, some other blessed ref (with op"=" possibly overloaded!), or even an lvalue sub. Do you know? Should you care? I don't know, but I think I s

Re: RFC 109 (v1) Less line noise - let's get rid of @%

2000-08-17 Thread John Porter
Mike Pastore wrote: On Wed, 16 Aug 2000, John Porter wrote: grep() always treats its "second" arg as a list, even if it's a scalar, or some other list-of-one (or none); and grep() always returns a list, even if it's a list of one (or none). True on the first part, false on

Re: RFC 109 (v1) Less line noise - let's get rid of @%

2000-08-17 Thread John Porter
Jon Ericson wrote: John Porter wrote: ...all variable types (scalar, array, hash) are simply objects. Not in Perl. Yes, in perl. $dog and $cat are objects. $dog can bark and $cat can scratch. The author of the module (Zoo::Animal?) should have documented these methods

Re: pascal-like with was Re: Default filehandles(was Re: command line option: $|++)

2000-08-17 Thread John Porter
ell, maybe that'll be different in perl6?) -- John Porter

Re: ... as a term

2000-08-22 Thread John Porter
Piers Cawley wrote: You forgot: print (1, 11, 21, 1211, ...) print( 'M', 'MI', 'MIU', ... ) ALso, Larry, how about making the various common emoticons meaningful? please do come from 10; :-) I.e. "belay that command". -- John Porter We'r

Re: functions that deal with hash should be more liberal

2000-08-22 Thread John Porter
Casey R. Tweten wrote: sub func { return qw/KeyOne Value1 KeyTwo Value2/; } print "$_\n" foreach keys func(); Please. There are ways -- well, just one way -- to do this, even in perl5. print "$_\n" foreach keys %{{ func() }}; -- John Porter

Re: Things to remove

2000-08-22 Thread John Porter
of interpreter state (code, data). -- John Porter We're building the house of the future together.

  1   2   3   4   5   >