Re: RFC 143 (v2) Case ignoring eq and cmp operators

fect 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.

available at http://sourceforge.net/projects/psh/ -- Markus Peter - SPiN GmbH [EMAIL PROTECTED]

Re: Are Perl6 threads preemptive or cooperative?

is that the lock command or whatever you'd use for locking works as fine-grained as desired, that means, in the current block, so we needn't lock the variable in the whole subroutine. -- Markus Peter - SPiN GmbH [EMAIL PROTECTED]

Re: Are Perl6 threads preemptive or cooperative?

rl 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: Are Perl6 threads preemptive or cooperative?

oes not have that problems due to a lack of state, but don't nail me on that statement) or to offer fine grained synchronization techniques/mutexes which at least leave the programmer in full control. -- Markus Peter - SPiN GmbH [EMAIL PROTECTED]

Re: Are Perl6 threads preemptive or cooperative?

programmer-years to do well. (Or at least less poorly... :) Writing an own threading library also forces you to use cooperative threading as on many system emulating preemptive threads without system support is rather hard or impossible (especially blocking I/O is an issue there on some syste

Re: Are Perl6 threads preemptive or cooperative?

ten seen cooperative threading implemented with a higher "performance" (meaning speed) than preemptive, but cooperative is simply not as reliable as preemptive threading -- Markus Peter - SPiN GmbH [EMAIL PROTECTED]

Re: RFC 143 (v1) Case ignoring eq and cmp operators

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?

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]

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: PROTOPROPOSAL FOR NEW BACKSLASH was Re: impliedpascal-like"with" or "express"

al slashes would look even better but then we'd run into troubles if you use variables instead of bare words and those variables contain numbers ;-) -- Markus Peter - SPiN GmbH [EMAIL PROTECTED]

Re: RFC 139 (v1) Allow Calling Any Function With A Syntax Like s///

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]

Re: On the case for exception-based error handling.

;fatal => { ... } Agreed. That one is better than the different class :-) -- Markus Peter - SPiN GmbH [EMAIL PROTECTED]

Re: On the case for exception-based error handling.

for an exception which might be a problem but not very serious and Error for the real, usually always fatal problems. -- Markus Peter - SPiN GmbH [EMAIL PROTECTED]

Re: PROTOPROPOSAL FOR NEW BACKSLASH was Re: implied pascal-like"with"or "express"

real sense, so forget my objections about the backslash -- Markus Peter [EMAIL PROTECTED]

Re: On the case for exception-based error handling.

se who could still not see any sense in my words ;-): use no fatal; bla; bla; # should any of the above code throw an exception it gets ignored try { # from this point on i handle exceptions - use fatal is implied foo; } catch ...; # handle exception bar; ... bar; # exceptions automatically ignored again -- Markus Peter [EMAIL PROTECTED]

RE: On the case for exception-based error handling.

nline RFC 88 - what version are we talking about? 2) It's still fatal even if the program used 'no fatal' at the beginning of the program, but outside the try block? -- Markus Peter [EMAIL PROTECTED]

Re: On the case for exception-based error handling.

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]

Re: $ME in a method called as a subroutine

object handles? These are loads of side effects. Such a feature is probably ok if it's optional for a method but not by default... -- Markus Peter - [EMAIL PROTECTED]

Re: $ME in a method called as a subroutine

mes, but either way, we'd need an additional variable then - either one which holds specifically the last object (like $LAST_ME or whatever) or one which holds information about the way the sub was called. I'd still prefer the first alternative then as it appears cleaner to me somehow.

Re: On the case for exception-based error handling.

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.

error modes), so that I can check exceptions when I want to -- Markus Peter - SPiN GmbH [EMAIL PROTECTED]

Re: Time core object and localtime() again

lations? Well - after all it's just an implementation detail... My question is what's wrong to only supply the information on perl ports where systems do not have zoneinfo ? But I've to admit that I don't really care as long as we finally have complete standard support for time/date operations. -- Markus Peter - SPiN GmbH [EMAIL PROTECTED]

Re: Time core object and localtime() again

s probably better than re-doing everything. For those systems not having timezone information or complete timezone information those zones would not be available until somebody installs a zoneinfo package or whatever - where exactly is the problem there? -- Markus Peter - SPiN GmbH [EMAIL PROTECTED]

Time core object and localtime() again

ivalents to POSIX::mktime and POSIX::strftime - that module is simply too large if I only need time operations and it's nice to have everything in one place. Another interesting way to construct a Time object would be from a string scalar looking like an SQL date: 'MMDDhhmmss' as thi

New syntactic sugar builtin: in

uot;,"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]

Re: PROTOPROPOSAL FOR NEW BACKSLASH was Re: implied pascal-like"with" or "express"

anning perl-language but gave up after some time... ) -- Markus Peter - SPiN GmbH [EMAIL PROTECTED]