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 C and C 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 C and > C 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: 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]
CORE symboltable should behave like any other?
Hello
Before I write an RFC about that topic, is there anybody else who thinks
the CORE:: package should be consistent in it's behaviour (especially for
symbol table manipulations and access) with all other packages?
For comparison:
print Dumper(\%{*{"main::"}});
$VAR1 = {
'@' => *{'main::@'},
'stdin' => *::stdin,
}
print Dumper(\%{*{"CORE::"}});
$VAR1 = {
'GLOBAL::' => *CORE::GLOBAL::
};
Or are the problems this causes (we e.g. had problems with this in the tab
completion code of the perl shell) to exotic to be fixed?
--
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: RFC 139 (v1) Allow Calling Any Function With A Syntax Like s///
--On 23.08.2000 4:31 Uhr + Perl6 RFC Librarian wrote: > The calling syntaces of m()/s() should be consistent with other forms of > function call; this should be achieved not by eliminating the traditional > C form from m()/s(), but by allowing any function to be called with > C. I'm not so sure what the advantage of that approach is except that you could overload m and s (which could also be added to use overload)? To me, this looks as if this probably has lots of potential for perl poetry but not for programming... -- Markus Peter - SPiN GmbH [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]
