Re: 184 (v3): Perl should support an interactive mode
Christian Soeller wrote: Very little discussion was generated by this RFC. Several people noted that perl -de 42 and the Perl shell psh already provide some of what the RFC requests; this is noted in the RFC. The RFC is not being withdrawn, since 2 other people expressed (mild) interest in it. I'd like to add that multiline shell capabilities would be *extremly* useful for the perldl shell Well, the psh shell could use some additions, too. Right now psh does some rather primitive parsing for completeness of a line and has to guess wether some input is intended to be Perl or e.g. calling of an executable or whatever. To be more specific, the functionality we could need is. - Determine wether an expression could be a complete Perl expression (that means, no more open braces, qq blocks etc.) - The ability to check via the symboltable wether a certain core function exists without using a hard coded list, as well as gaining a string representation of their prototypes - Syntax checking perl code without forking and execing a new perl instance with -c - Ability to store and later retrieve all eval sideeffects like $1,$2,... current package etc. without handling every variable/condition yourself. One could argue that we should use the existing parser modules to gain the necessary information as far as possible, on the other hand these facilities are already there somewhere, hidden in the Perl executable. I have to admit though that I somehow doubt that only one applications(psh and perhaps the perldl shell, too) justifies such additions to perl. -- Markus Peter - SPiN GmbH [EMAIL PROTECTED]
Re: RFC 143 (v2) Case ignoring eq and cmp operators
"David L. Nicol" wrote: Perl currently only has Ceq and Ccmp operators which work case-sensitively. It would be a useful addition to add case-insensitive equivalents. As I recall, the consensus the last time this came up was that Ccmpi and Ceqi would be perfect examples w/in a RFC proposing a way to declare a function to take it's arguments in infix instead of prefix manner. Well - it only came to the list again as I retired the RFC as most people thought this was not important enough :-) -- Markus Peter - SPiN GmbH [EMAIL PROTECTED]
Re: RFC 184 (v1) Perl should support an interactive mode.
--On 31.08.2000 23:54 Uhr + Perl6 RFC Librarian wrote: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Perl should support an interactive mode. Most of what you want is already implemented in the perl shell available at http://sourceforge.net/projects/psh/ -- Markus Peter - SPiN GmbH [EMAIL PROTECTED]
Re: Are Perl6 threads preemptive or cooperative?
--On 25.08.2000 20:02 Uhr -0400 Steven W McDougall wrote: Others have pointed out that code inside sub-expressions and blocks could also assign to our variables. This is true, but it isn't our problem. As long as each assignment is carried out correctly by the interpreter, then each variable always has a valid value, computed from other valid values. Depends on who 'our' is, if you're an internals guy you need not care, that's true, but as a user of the language you care about how much sync-ing you have to do yourself in your perl code - the preemptive vs. cooperative discussion is there valid as well though it would probably be good to seperate these discussions :-) -- Markus Peter - SPiN GmbH [EMAIL PROTECTED]
Re: RFC 143 (v1) Case ignoring eq and cmp operators
--On 24.08.2000 10:56 Uhr -0600 Tom Christiansen wrote: The probably worst about these statements is that they look ugly. To the contrary: in the case (ahem) of the application of lc() on the comparison's operand, they look especially beautiful. Depends on taste I guess... Also, they further complicate statements and they are counter-intuitive for beginners - why should I change the case of variables if I only want to compare them? Again, I reach the contrary conclusion: they say exactly what they are doing, rendering them clear and obvious to all involved. By your argument, one should not have to say abs($a) == abs($b) either, but should invent a sign-insensitive equality comparison instead of knowing how to use the extant == operator and abs function. With the same argument we can drop -- and ++, and while we're at it, the arithmetic minus in favor of +(-$num). In my consideration, a case-insensitive equality check is a rather common operation in Perl programs so it deserves its own operator. Power derives not from uncountably many special-purpose functions and syntax, but rather from the ability to combine primitive features *algorithmically* to arrive at the desired functionality. The factorial powers of combinatorics put to shame a merely linear increase in the number of available functions. I'd use C then if I'd agree completely with this statement. $a eq/i $b $a cmp/i $b You want ugly, I'll give you ugly. That's ***UGLY***. It's a syntactic anomaly that does not fall out of anything else in the language. The analogy to m//i or s///g is a false one, as those are not functions I still say it looks familiar even if it's a false analogy. Another possibility would be to use cmpi and eqi -- Markus Peter - SPiN GmbH [EMAIL PROTECTED]
Re: Exception handling [Was: Re: Things to remove]
--On 23.08.2000 17:26 Uhr -0700 Glenn Linderman wrote:
Thanks for reminding me of this, Bart, if RFC 88 co-opts die for non-fatal
errors, people that want to write fatal errors can switch to using "warn
...; exit ( 250 );" instead of "die ...;" like they do today. [Tongue
firmly planted on cheek.]
I can only hope this is pure irony...
There is no such thing as an ultimately fatal error - it should always be
up to the user of a module wether the program should die, but I guess you
see that the same and will answer me with "use eval" then ;-)
and from another mail:
While nothing in RFC 88 precludes die and throw from sharing the same
underlying code, or similarly catch/eval, doing so isn't a good idea: it
forces people that want to use exceptions for non-fatal error handling to
suddenly have to also handle fatal errors as well.
In which way are they forced? You simply need not catch the fatal
exceptions.
try {
...
}
catch ! $@-fatal = { ... }
That might be a bit longer to type than eval { }; do_stuff_with($@) but I
think consistency in handling is more important here.
and another mail:
Once a (more appropriate than die) non-fatal throw/catch mechanism exists,
the use of die for non-fatal exceptions would hopefully wither away over
time... and if not, appropriate wrappers could be written.
I don't see why I should want that - sure, that's a way to cope with a
distinction between die and throw but without the distinction we simply do
not have the problem. And I definitely do NOT want to have a dozen wrapper
modules or whatever till that usage withered away in CPAN in 95% of the
modules after 1 year.
--
Markus Peter - SPiN GmbH
[EMAIL PROTECTED]
Re: On the case for exception-based error handling.
--On 22.08.2000 10:48 Uhr -0700 Glenn Linderman wrote:
This probably won't work. What would you return exactly? Also, there's
plenty of chance that the return value could interfer with the regular
return values of that function... This will never be possible without
work done by the module author so the return value plays nicely.
...
Hence, exception handling (with or without catch phrases) allows the
normal, non-error case to be coded more simply both when you don't care
about catching errors (die), and when you do.
Hmm.. I don't know how this paragraph relates to my comments (even though
it's a nice overview of the advantages from exceptions - which I'm already
convinced of after being forced to program in Java for several years.) What
I was talking about is that I cannot imagine that the perl core itself
magically transforms exceptions into return values as someone else
requested.
"enabling/disabling fatality for exceptions with a pragma"... if the idea
is that control continues linearly past a throw, then sub/module authors
must write twice the error handling logic, which is painful. If it means
No - the sub returns as if it has correctly thrown the exception, but if
the exception really propagates to the top most level, it will be ignored
instead of die'ing. This is really the same as a try/catch block around my
whole program just not that ugly.
that the destination of the throw is bounded to some boundary, that
boundary must be defined... so I guess that's a scoped pragma, so the
syntax would be something like
{ use no_fatal_throws;
ignore_my_errors ( @params );
}
That's just about exactly the same length and complexity as the null catch
phrase above, which does exactly the same job.
What I was actually requesting was a small pragma which simply turns off
all fatality, in the whole program, similar to what $SIG{__DIE__} currently
is able to do, without the need to span a try/catch block across my whole
main program - I simply do not like the look and feel of that. Even though
this has global effects, it's not necessarily evil, we should only ensure
that it cannot be used from within a .pm
--
Markus Peter - SPiN GmbH
[EMAIL PROTECTED]
Re: On the case for exception-based error handling.
On Tue, 22 Aug 2000, Glenn Linderman wrote: I'm suddenly intuiting that maybe you want to continue execution after the sub call that caused the throw. But if you continue, you won't have the return values from the sub call. Where should the continuation take place for something like: l1: $a = foo ( bar ( $b )); l2: baz ( $a ); l3: in the two different cases that bar throws, and that foo throws? If you continue "immediately after" the sub call, and bar throws, foo is likely to get bad parameters and also fail. And if you say the next statement after a Yes, that's true, but I'm not talking about such cases. Your above example would result in garbage in, garbage out which is ok if I want to circumvent the exception system. Maybe it's easier to understand if I explain what I do not want to have ;-) I'd normally use such a pragma when I want to write a small hack, not a large project. What I fear are that certain modules will die on me even on stuff comparable to e.g. unlink in side effects - as they simply want to throw an exception as a means of reporting "file is not there anyway" - which I absolutely do not care about... E.g. in Java writing small hacks is impossible because you'll spend half your time adding try/catch blocks around stuff... Perl is a bit better in that respect - it allows me the choice to forget completely about exceptions or having the same trouble as in Java What I request is probably similar to the no Fatal pragma someone proposed. The only thing I dislike about no fatal is that modules are supposed (are they really?) to return error return values then - and what I'd like to have is still that I CAN catch exceptions at some points, but I need not to. If I don't check it, I'll simply get an undef return value, but I still have the choice to check one or two possible exceptions without enabling/disabling all that myself. The current definition of use fatal/no fatal would not allow this I think as suddenly those modules could stop throwing exceptions, so I'd end up enable/disabling use fatal all the time... Another way to achieve the same result would be to NOT get rid of the try part of try/catch and then try automatically implies use fatal for that block... -- Markus Peter [EMAIL PROTECTED]
New syntactic sugar builtin: in
I'd like to see a new builtin named "in" which does the same as "in" in SQL.
Basically,
print "OK!" if $val in ("foo","bar","bla");
is the same as
print "OK!" if grep { $_ eq $val } ("foo","bar","bla");
or
print "OK!" if $val eq "foo" or $val eq
except it's a lot more compact, intuitive to use and readable...
--
Markus Peter - SPiN GmbH
[EMAIL PROTECTED]
