Re: Removing/fixing $[line noise here] variables

2000-08-01 Thread John Porter
$perl::core{warnings} $perl::formats{name} $perl::deprecated{mod}{foo} -- John Porter Aus tiefem Traum bin ich erwacht.

Re: RFC: multiline comments

2000-08-01 Thread John Porter
ht now; but those result in a value, which under some circumstances causes a warning issuance. -- 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
could be declared 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
e > > 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: RFC: lexical variables made default

2000-08-02 Thread John Porter
what the $ is for. They're not semantically identical. "var" would be a declaration. And yes, maybe we can dispense with $. (But that's for another RFC.) -- John Porter

Re: RFC: Highlander Variables

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

Re: multiline comments

2000-08-02 Thread John Porter
Michael Mathews wrote: > > At the risk getting too exotic how about: > > #< some > comments > EOC Just introduce a new function which is a bit bucket: # works in perl5. sub comment(@) { } comment q{ comments... }; comment <

Re: RFC: Highlander Variables

2000-08-02 Thread John Porter
n the rule gets longer, it gets harder to teach. And if it's > harder to teach, it's probably harder to learn. Here's a simple rule: all symbols must be unique*, regardless of "type". It's a rule that most other languages have. *except for hiding, which is orthogonal to this point. -- John Porter

Re: RFC: Highlander Variables

2000-08-02 Thread John Porter
H.Merijn Brand wrote: > > But perl's not any other language. Perl's fun. most other languages are not. Perl5 is not going away. Let's make a better language while we have the opportunity. -- John Porter

Re: RFC: lexical variables made default

2000-08-02 Thread John Porter
rations' which would require all variables to be declared with one of > the above three before first use (or be package-qualified). I'm not arguing for anything there, other than the more-or-less agreed-upon Make "Use Strict" The Default. -- John Porter

Re: RFC: multiline comments

2000-08-02 Thread John Porter
"total:\n" . qc{ show total } . # replaced with empty string by compiler $total; -- John Porter Aus tiefem Traum bin ich erwacht.

Re: RFC: Filehandle type-defining punctuation

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

Re: multiline comments

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

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: multiline comments

2000-08-02 Thread John Porter
your Way the first qc > would after line 3, at the first "*/;" encountered (bad too). Of course, like all the other q.// operators, the actual delimiters are selectable. E.g. 1qc(* # heh, old Pascal style comments! 2added this comment on 08/02/2000 3qc/* this is a nested comment */; 4*); -- 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
ice, 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: multiline comments

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

2000-08-02 Thread John Porter
Tom Christiansen wrote: > > I still like this solution prototype: > > sub comment($) { } > > comment <<"END OF FIRST COMMENT"; > asdf > asdf > asdf > asdf > asdf > END OF FIRST COMMENT So do I. Actually, here-docs can be a bit unwieldy, what with the requirement for the e

Re: multiline comments

2000-08-02 Thread John Porter
Michael Mathews wrote: > > > 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. TIMTOWTDI. -- John Porter

Re: RFC: multiline comments

2000-08-02 Thread John Porter
Tom Christiansen wrote: > > comment < > Smack--the lexer cowers before you! Well, hey, while we're daydreaming... :-) -- John Porter

Re: RFC: lexical variables made default

2000-08-03 Thread John Porter
on the merit of it's being fun is probably at odds with the goal of make Perl more widely acceptable. -- John Porter

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

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

Re: perl 6 requirements

2000-08-03 Thread John Porter
Tom Christiansen wrote: > return 3 after print $string1, $string2 if $cond; It's true, perl can learn from intercal too: do come from (10) -- John Porter

Re: RFC: Filehandle type-defining punctuation

2000-08-03 Thread John Porter
t another way, I see "a/a"! -- 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 increas

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: A Unicode fallacy [Was: Re: RFC: multiline comments]

2000-08-03 Thread John Porter
er do what she wants. Anyway, allowing the use of unicode characters in syntactic constructions (such as in q{} ) does not make it hard to adhere to a coding discipline which forbids them. -- John Porter

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

2000-08-03 Thread John Porter
ine comments might be very useful, and not breaking anything else, the status could be "Good". On this particular RFC, you probably want to summarize all the alternatives suggested, along with the pros and cons of each. You can ignore the ideas that no one seemed to like (if any). -- John Porter

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

2000-08-03 Thread John Porter
e tokens. This is precisely what I had in mind, except s/macro facility/the compiler/, since qw() is handled there, if I'm not mistaken. But a standardized macro facility would be nice. Although -- wouldn't it have to parse perl? Or else have a wholly distinct grammar? -- John Po

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

2000-08-03 Thread John Porter
Buddha Buck wrote: > I suggest that the last be > "Status: postponed" instead of "Status: tabled". "deferred" -- John Porter

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

2000-08-03 Thread John Porter
Michael Fowler <[EMAIL PROTECTED]>: > > use typing; # place your fingers on the home row.. > > my integer $quux = 4; I believe that would have to be integer my $quux = 4; at least in perl5... -- 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

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

2000-08-04 Thread John Porter
Glenn Linderman wrote: > > What good are comments if you can't find them when you need them? There's not thinging to stop you from writing qc/*** MAGIC HERE */; Nor from typing /qc in vi (if you use vi). -- John Porter

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

2000-08-04 Thread John Porter
e > is included standard. I don't mind cpp too much; but I'd really like something much more powerful than cpp. Hmm -- cpp++?? -- John Porter

Re: RFC: Drop distinction between user-defined and built-in functions

2000-08-04 Thread John Porter
Gisle Aas wrote: > > foo(\&print, "foo"); I think it's critical that built-ins be reference-takeable, just like user-defineds. -- John Porter

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

2000-08-04 Thread John Porter
ay love it, but I'm a programmer and I don't. I'm both, and I 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
Steve Simmons wrote: > On Fri, Aug 04, 2000 at 12:07:00PM -0400, John Porter wrote: > > > I don't mind cpp too much; but I'd really like something much > > more powerful than cpp. Hmm -- cpp++?? > > m4. > > m4 is better than cpp, I don't much car

Re: RFC: Drop distinction between user-defined and built-in functions

2000-08-04 Thread John Porter
Tom Christiansen wrote: > > I think it's critical that built-ins be reference-takeable, > > just like user-defineds. > > But they [dw]on't work right. Um -- why not? Why can't we make then work right in perl6? -- John Porter

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

2000-08-04 Thread John Porter
s it matter that one is gobs more powerful than the other? -- John Porter

Proto-RFC: A Standard Always-Live Preprocessor

2000-08-04 Thread John Porter
t, because not many 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 29 (v1) unlink() should be left alone

2000-08-04 Thread John Porter
links now (or does it?) doesn't mean it won't in the future. -- John Porter

Re: Proposed sublist: flowcontrol

2000-08-04 Thread John Porter
Uri Guttman wrote: > i think damian's influence on perl6 > is our real triple top secret weapon. This realization has hit me on the head really hard. My prediction is that Perl6 will have to be dual-credited. -- John Porter

Re: RFC 22 (v1) Builtin switch statement

2000-08-04 Thread John Porter
last ~= break next ~= continue (not in switch, since it's not a loop) Hey, doesn't while need an otherwise? while ( foo ) { } otherwise { # do this if the while predicate was never true. } -- John Porter

Re: Different points of view, a little perspective.

2000-08-04 Thread John Porter
We're here to work on perl6. Let's stay focused. -- John Porter

Re: RFC 25 (v1) Multiway comparisons

2000-08-04 Thread John Porter
namely, that $x < $y evaluates to false if $x >= $y, and evaluates to "$y (but true)" if $x < $y. This allows the operators to be nested, i.e. $x < $y < $z would be ( $x < $y ) < $z, which performs the $y < $z comparison iff $x < $y. But this is all off the top of my head; the Icon references should be consulted on this. -- John Porter

RFC: "Empty But True" Special String Value (was Re: RFC 25)

2000-08-04 Thread John Porter
-- John Porter

Re: RFC 30 (v1) STDIN, STDOUT, and STDERR should be rena

2000-08-04 Thread John Porter
> STDIN, STDOUT, and STDERR should follow suit and be renamed > $STDIN, $STDOUT, and $STDERR. $TDIN, $TDOUT, $TDERR -- John Porter

Re: RFC 22 (v1) Builtin switch statement

2000-08-04 Thread John Porter
with appropriate ramifications/extensions, so that ppl can write switch-like constructs however they want. -- John Porter

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

2000-08-07 Thread John Porter
le to quickly distinguish the > comments using my eyeballs and brain, without the need to involve my > fingers and editor Bogus arguments both, at least wrt #<...># vs qc<...>. Same number of characters overhead, same LACK of obviosity to the eyeball. -- John Porter

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 >

Re: RFC: Rename local() operator

2000-08-07 Thread John Porter
special^Wlocalized variables are scoped in time, not space, so: now $/ = "\n"; -- John Porter

Re: RFC: Rename local() operator

2000-08-07 Thread John Porter
you get modification *regardless* of whether you assign something or not. -- John Porter

Re: RFC 23 (v1) Higher order functions

2000-08-07 Thread John Porter
be overloaded yet again? $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 . 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
t '_' is a valid identifier character. '__' 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 44 (v1) Bring Documentation Closer To Whatever I

2000-08-07 Thread John Porter
ers if x > 0.1); my $x = shift; # ... } Please check out RFC 5 and its discussions in the archive. -- John Porter

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

2000-08-07 Thread John Porter
> Compilation: Remove requirement for final true value in require'd and do'ed files Do not. I use this feature. -- 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" instea

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

2000-08-07 Thread John Porter
Nathan Torkington wrote: > John Porter writes: > > Throw an exception in order to return a (0|'')-but-true value? > > If you want to indicate that there was an error in the code, why not > die()? What am I missing? I'm talking about the case where the requir

Re: DRAFT RFC: Enhanced Pack/Unpack

2000-08-07 Thread John Porter
> > VAX is either big or little. I can't remember which off the top > > of my head. Right, VAX is strictly little-endian. I.e. the address of a *word is the address of its least significant byte. (That's little-endian, isn't it?) -- John Porter

Re: RFC 54 (v1) Operators: Polymorphic comparisons

2000-08-07 Thread John Porter
>> language. > > ROTFL. But it's true. 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 ortho

Re: ISA number

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

Re: ISA number

2000-08-07 Thread John Porter
Hildo Biersma wrote: > Having said that, it doesn't need to live in the core - and even today > it should be relatively easy to write an XS module for this. It should no more NOT live in the core than, say, scalar() (or whatever scalar() might become in 6). -- John Porter

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

2000-08-07 Thread John Porter
dal might tell you in day 1 of his perl course. -- John Porter

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

2000-08-08 Thread John Porter
s the result of the Foo->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
rl thinks it's the first > 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
f you wanted to make that 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
27;re not in a string context > print context '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: AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

2000-08-08 Thread John Porter
. I, for example, want a New, Better language, and I don't care if all my scripts need rewriting. (I predict that that will happen anyway.) My old stuff will continue to work with perl5. -- 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
$r = 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) C changes.

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

Re: RFC 58 (v1) C changes.

2000-08-09 Thread John Porter
Dan Sugalski wrote: > > unless you think we should require arrays to be passed by reference. > > It's an op. Arrays can be passed in any way we want. But as I already pointed out, we don't want to pass just arrays, we need to be able to pass any LIST. -- John Porter

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

2000-08-09 Thread John Porter
( .. -1 ) { $i++; last if $i > 2; print } If the answer is (as I suspect), "This never prints anything; it goes into an infinite loop just trying to generate the first number", then the proposal is absurd and should be scrapped. -- John Porter

Re: RFC 58 (v1) C changes.

2000-08-09 Thread John Porter
ibe, and then it turns out that there are cases where I needed the > chomp, and I forgot to add a newline. Strawman. There are times I forgot to increment the count of frobnitzes, and had to go edit the code. -- 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; > >

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

2000-08-09 Thread John Porter
dit-string, string-to-ref sequence allows? Um, no... )-: -- John Porter

Re: RFC 58 (v1) C changes.

2000-08-09 Thread John Porter
elevant timings of perl5 code snipped] -- John Porter

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

2000-08-09 Thread John Porter
Michael Mathews wrote: > > This ... underlines why POD is not a good way to comment code. > ... > This RFC would seem to address the issue quite neatly. So, are you saying that if this RFC is implemented, POD would be an good way to comment code? -- John Porter

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

2000-08-09 Thread John Porter
e problem: how to get 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
really is. It does 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
27;m on it -- perhaps the RFC should be phrased in terms of LP, as in: "Perl On-line Documentation (:-) should more fully support LP". -- John Porter

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

2000-08-09 Thread John Porter
The subroutine is defined 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>

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
uld catch lists of types: 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
illy to use "otherwise" there. You could make it 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
t generated 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
erl doesn't, and personally I think it's a better paradigm. If you really want to rethrow unhandled exceptions, you can always catch { die } -- John Porter

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

2000-08-11 Thread John Porter
} catch { handle_error_assuming_invariants_restored(); } -- John Porter

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

2000-08-11 Thread John Porter
> On Fri, Aug 11, 2000 at 10:34:00AM -0400, John Porter wrote: > > I support the idea of renaming the block eval as die, and leaving eval Crimonentlies! I meant "try", of course. :-/ Freudian slip? -- John Porter

  1   2   3   4   5   6   >