Re: TIL redux (was Re: What will the Perl6 code name be?)
"AS" == Ariel Scolnicov [EMAIL PROTECTED] writes:
AS Another advantage of a TIL that you seem to lose by compiling Perl to
AS it is the ease of defining new words. Forth-like systems are
AS programmed by compiling myriads of very small "words", in gradually
AS increasing levels. Perl code is not like that. So almost all the
AS things you'll be threading will be words from the Perl core (rather
AS than words defined in the program).
Err, and what is
sub foo { bar; bash }
sub bash { builtin }
sub bar { another_builtin}
If that isn't dynamic words, what is it?
Let alone
sub foo { bar sub { ... } }
sub bar { {$_[0]} }
I don't see how a TIL stands in the way of getting all this done. The
TIL is simply the mechanism for dispatching the ops. Were Perl5 used
the C inner loop, the TIL could have a tighter asm loop, or even direct
machine calls.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Accessing perl's command line switches
In a perl program I found the need to determine the command line swithches passed to perl to be used to invoke the program. But I couldn't find anything that gave this. There is $^X but that's limited. I needed to reinvoke perl with all the -S and -I etc. commands. (I needed a daemon that could reload itself, but without the -S and -I commands the runtime environment is not fully reflected. And if running under -T the enviornment is not trusted.) Is there something there already? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: A common event loop
"DLN" == David L Nicol [EMAIL PROTECTED] writes: DLN This too is something that would be very easy to do in DLN everything-is-an-exception world. All events throw "EVENT-whatever" DLN exceptions, and there you are. That is a nasty and expensive way of doing something 'simple'. And I can't imagine how this would work. Any statement could be interupted with an exception, but there is no mechanism to restart. This is just plain wrong. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 23 (v5) Higher order functions
"DC" == Damian Conway [EMAIL PROTECTED] writes:
Let me ask you:
foo('a','b', 'c')
Is 'b' the 1st parameter or the 2nd?
DC This is the classical mistake of confusing indices and ordinals.
DC The 1st argument is bound to the parameter whose index is [0],
DC The 2nd argument is bound to the parameter whose index is [1], etc.
But why make it an index? It just reads better as an ordinal.
DC Assuming they've read Lperlcurry, they'll know that ^1 is $_[1] is
DC parameter [1] is the 2nd parameter. They'll know because at the very start
DC of Lperlcurry I will write:
DC ^1 means $_[1], NOT $_[0]
[snip. Last message repeated too many times.]
If you have to do that, that is a good argument to follow the 'natural'
inclination.
Again, why insist on an index when it really is closer to an ordinal when
reading the actual code.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 23 (v5) Higher order functions
"AG" == Alan Gutierrez [EMAIL PROTECTED] writes: AG Just like the the regex match placeholders, positional placeholders begin AG with ^1 so that ^1 == $_[0]. If this doesn't make sense to it is AG probably because you are new to Perl and are not familiar with regular AG expressions, but we did things this may to make it easier for AG you to understand (assuming you read the regex chapter of the Camel AG before the curry chapter.) Just saying that makes my point. ^0 and $0 ^1 and $1 The ordinal concept onto the arguments matches much better. There is already a break between @foo = /(..) (..) ... / and $foo[0] and $1, ..., $foo[n] and $n I and several other folks made our point. We see this more akin in nomenclature and appearance to the regexp matches, then to a invisible offset into an array. All I ask is the Damian add our comments to the RFC. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 85 (v2) All perl generated errors should have a unique identifier
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
TC Ok, so you want message catalogues, and not solely on Perl but anything
TC in the distribution. You should say that.
No. That is independent of what I'm suggesting. What I'm suggesting is
an enabler.
I've seen code that actually looks at the value of $@
eval { ... }
$@ !~ //;
Why not make it simpler
eval { }
$@ !~ any( ); # Damian's Superpositions.
# I keep reading Superstition :-)
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: \z vs \Z vs $
"TC" == Tom Christiansen [EMAIL PROTECTED] writes: Could you explain what the problem is? TC /$/ does not only match at the end of the string. TC It also matches one character fewer. This makes TC code like $path =~ /etc$/ "wrong". Sorry, I'm missing it. $_ = "etc\n"; /etc$/; # true $_ = "etc"; /etc$/; # true In what way is this _wrong_? Is it under /m? But then wouldn't longest match cover the situation? And doesn't it only trigger at the end of a string? Within the string it eats the "\n". chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 85 (v2) All perl generated errors should have a unique identifier
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
Currently many programs handle error returns by examining the text of
the error returned in $@. This makes changes in the text of the error
message, an issue for the backwards compatibility police.
TC eval { fn() };
TC if ($@ == EYOURWHATHURTS) { }
TC sub fn { die "blindlesnot" }
I don't understand what you are trying to say.
The RFC was for perl core messages, so I can't see what a user
level error has to do with this.
Issuing a unique error id for non-core modules will be a nightmare.
And I don't think we want to start up a IANA.
The $@-facility, $@-id pair could be considered unique for non-core
errors.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 85 (v2) All perl generated errors should have a unique identifier
"TC" == Tom Christiansen [EMAIL PROTECTED] writes: TC I'm saying that you can't know what to check for, because you don't TC know who generated the exception. Can you use your fancy constants? Then please tell me how anyone has ever coded $@ =~ // They don't know what to look for? I just want to replace the examination of the textual error message with a fixed value. TC And what is "core"? Compiler? Interpreter? Utilities? Pragmata? TC Modules? Anything that came in the TARBALL, anything that p6p will be responsible for. TC Citing IBM as a reference is enough to drive a lot of us away screaming. Why? TC Try errno.h or sysexits.h Notice how much nicer this is. Few TC values, but usable in varied places. Sometimes it is acceptable to collapse different errors into one. But then sometimes losing the direct error makes things difficult to decide what really happened and how to handle it. Your issue could be handled by supplying a classification, either mapping to use warnings, or a different set (or all of them. I really don't care.) But the examination of the textual string, locks away any possiblities of adjusting the text of the message or even making the error string localizable. Consider allowing perl to emit error messages in French, Latin, or Klingon without breaking the code. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 246 (v1) pack/unpack uncontrovercial enhancements
How about a Base64 to match with uuencode? chaim "PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes: PRL =head1 ABSTRACT PRL This RFC proposes simple enhancements to templates of pack/unpack builtins. PRL These enhancements do not change the spirit of how pack/unpack is used. PRL The semantic is enhanced as much as possible under this constaint. PRL Additional changes to pack/unpack are listed in other proposals. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 230 (v1) Replace Cformat built-in with pragmatically-induced Cformat function
"DC" == Damian Conway [EMAIL PROTECTED] writes:
DC This would work:
DC footer = sub { "$From - $To" }
DC except there's no way of setting the $From and $To variables as
DC each page is formatted. I don't think Cformat by itself is the
DC right solution for this problem, unless I add some kind of weird
DC monitoring option.
DC That's probably beyond the scope of this RFC at present.
Why not add it? The formating code is seeing all the values going
through. So why not save them?
If you don't want to do the monitoring, then some hook that is called
just after the header or before the first line, and just after the
last or before the footer.
I must of missed it but what is the mechanism to force a page break?
And is there a way of keeping a format emission either together or
to allow them to be spread across a page break? (keep together/ widow
control)
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: pack/unpack is damn unperlish. Explain them as Perl.
"ST" == Sam Tregar [EMAIL PROTECTED] writes: ST I think you're talking about unpack() here, which I've only used once. I ST think unpack() is usually replaceable by substr() or regexes. Contrast ST that with pack() for which no equivalent replacement is possible, as far ST as I know. Actually not. You need to do some extra nasties to get an integer from a binary record into a perl scalar and have it be a number. If you use substr it will be a string. Useless. Pack takes binary data chops it into bitesize pieces so that perl can use it correctly. binary integers stay integers if they are in the wrong endiness the bits get flipped properly. un so weiter. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 213 (v1) rindex and index should return undef on failure
"GL" == Glenn Linderman [EMAIL PROTECTED] writes:
GL There is a difference between "undefined" and "unknown".
GL Perl undefined is a different concept--that of an uninitialized
GL variable. This is proven from its earliest versions where the
GL value is coerced to 0 or '' (specific values) when used (without
GL warnings on).
Sorry, as far as I'm concerned
$foo = undef
and
select @foo = NULL
Are both initialized.
And what do you consider
sub foo { ; return }
$status = foo;
Uninitialized? Very clearly initialized.
And lets look at the name and functions
defined($foo)
undef($foo)
Both seem clearly to mean _undefined_ or perhaps unknown or NULL
The use of undef meaning 0 or '' is quite useful.
But under some programing styles having tristate logic and NULL propogation
would make some programming task a bit more straightforward.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 213 (v1) rindex and index should return undef on failure
"JP" == John Porter [EMAIL PROTECTED] writes:
JP Chaim Frenkel wrote:
Removing -1 as a valid result, could be a breakage (if someone is
doing something weird with a negative result)
JP What, like using it as an index into a substr?
JP Bad Code is its own reward, my friend.
Is that a for or an against.
$foo = "flabergasted";
substr($foo, index($foo, 'abc'), 20);# Returns undef
JP One should never do this, regardless of what index() returns on
JP failure. Now, if index() threw an exception on failture, you'd
JP be o.k. But I don't think we want that...
I do this _all_ the time. (Well in my SQL.) The correct translation
for untranslatable items is NULL (or undef in perl-speak). Yes,
sometimes it isn't, for those extra coding is required.
Having substr (or other functions) generate an undef is a quite
reasonable way to handle this scenerio. This isn't any different
than$bar = $hash{$foo} wher $foo doesn't exist.
If you must have a value, then check for it. If an undef is acceptable
then check for that.
I would find checking the final result somehow much clearer to read.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: Beefier prototypes (was Re: Multiple for loop variables)
"BL" == Bart Lateur [EMAIL PROTECTED] writes:
BL I'll give one example.
BL sub min {
BL my $min = shift;
As I proposed, @_ would flatten the incoming arguments.
But a sub with a prototype (that includes a non-trailing '@') would then
be able to see the raw arguments.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 230 (v1) Replace Cformat built-in with pragmatically-induced Cformat function
"PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes:
PRL Likewise, if the "footer" option is specified with a string value, that
PRL string is used as the footer of every page generated. If it is specified
PRL as a reference to a subroutine, that subroutine is called at the Istart
PRL of every page and its return value used as the footer string. When called,
PRL the footer subroutine is passed the current page number.
I can see why. But is there someway to be able to do dictionary like
from - to in a header/footer?
Magic Variables? Point the format at which variable(s) to watch
range = qw(name other)
footer = "$From{name} - $To{name}";
Would it be worthwhile to have a quick and dirty way of having the
formatter determine the max width and then allow the header/footer
to simply indicate left|center|right text?
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 229 (v1) Variable interpolation on demand.
"SC" == Simon Cozens [EMAIL PROTECTED] writes:
SC On Fri, Sep 15, 2000 at 05:56:36AM -, Perl6 RFC Librarian wrote:
There is no way to turn obtain the value of $x from the value of $y.
In other words, while $foo and $bar were interpolated into $x, they
were not interpolated into $y. It would be nice to get Success! from:
SC sub interpolate {eval "\"@_\""}
SC Never say "there is no way". There's *always* a way, and 99% of the time it
SC doesn't need to go in core.
I thought he was asking for evaluating until nothing is left to interpolate.
Something akin to:
$x = eval "$x" while $x =~ /[$@]/;
But more intelligent.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Multiple random number generators (was Re: RFC 208 (v2) crypt() default salt)
"BL" == Bart Lateur [EMAIL PROTECTED] writes: BL Therefore, crypt() should have it's own pseudo-random generator. A BL simple task, really: same code, but a different seed variable. Should rand be extended to be able to support multiple random number generators? =item srand EXPR, RANDGEN_REF =item srand EXPR =item srand Srand would now return a reference to a random number generator. Calling srand in a void context would effect the global default random number generator. But in a non-void context would create a new random number generator, and return a reference to the generator allowing reseting or extraction of the next number via rand =item rand EXPR, RANDGEN_REF =item rand EXPR =item rand chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 213 (v1) rindex and index should return undef on failure
"GL" == Glenn Linderman [EMAIL PROTECTED] writes: GL That's exactly why it would be nice if index _did_ throw an exception on GL failure, then you could write code this way, and catch the failures GL without needing to check return values for the error code case before GL proceeding with the real case. But you would still have to catch the exception. Not a nice thing to terminate the program just because an expected mismatch occured. Not finding something is not exceptional. Neither is EOF on a file, or working with an empty list. Adding all these exceptions for non-exceptional and quite common scenerios is bothersome. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch
"CN" == Chris Nandor [EMAIL PROTECTED] writes: CN No, that won't really work. When my offset from GMT changes for daylight CN savings time, it will break. The point of having a module is that epoch CN conversions are more complicated than that. For example, Mac OS epoch CN begins at Jan 1 1904 00:00:00 _local time_. That is why the timezone CN offset from GMT was passed to the Time::Epoch functions. I'm confused. How do you expect the program to know the timezone if the OS doesn't? And if the program knows it and can track it, then we can hand off the responsibility to Perl. Then the epoch would 'vary' according to whatever nonsense is necessary. But if the values wander so badly, what does the OS use? If perl has to convert away, then it can easily use Unix epoch. CN Also, you might want to convert between other epochs; what if you get an CN epoch value FROM Mac OS on a Unix box, and want to convert it? That's a different problem than we are trying to solve. This is a wider problem then a fixed epoch for perl. Let's turn this around. What if we are on a platform that doesn't use perl's epoch and we need to write a value to a file? I think I've just gotten very confused. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch
"CN" == Chris Nandor [EMAIL PROTECTED] writes: This is a wider problem then a fixed epoch for perl. Let's turn this around. What if we are on a platform that doesn't use perl's epoch and we need to write a value to a file? CN Yes. What if? That's what we're addressing. Right now, you need to use CN something like Time::Epoch to do a conversion, or you use a non-ambiguous CN representation, such as you get with Date::Manip (which, BTW, I believe is CN broken in respect to MacPerl's epoch; that is, I think I needed to convert CN to Unix epoch before doing something with it). You misundertood me. You have to know several different facts. The current epoch, the machine epoch, the epoch that the file requires. I really don't see that we need more than what is the difference between the timestamp returned from the syscalls, and the unix (or whatever) epoch. If you want to adjust for timezones just calculate the constant. Which since you are giving it in HHMM format you might as well just calculate directly. So what am I missing. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 213 (v1) rindex and index should return undef on failure
"NT" == Nathan Torkington [EMAIL PROTECTED] writes:
NT Chaim Frenkel writes:
Somehow I find
if (40 == ($foo = substr($bar, index($bar, 'xyz' {
}
NT I don't understand your hypothetical code. substr() returns the
NT substring of $bar from the position retutned by index, onward.
NT When would this be 40, if index is going to return the position
NT of 'xyz'?
NT I guess I can't understand your idea of safe failure until I
NT see an example, and this doesn't seem to be it.
Whoops, I was tired.
$to = "010 020 030 047";
$from="AAA BBB CCC DDD";
print substr($to,index($from,"BBB"),3);
print substr($to,index($from,"XXX"),3);
__END__
020
7
I would like to have an undef returned.
(Now it would have been interesting if it returned "047", then having
index return an undef and then having substr() propgate the undef
would make things workable.)
If you are familiar with Sybase's version of sql. Invalid arguments
to various functions return NULL.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 213 (v1) rindex and index should return undef on failure
"PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes: PRL In perl5, index() and rindex() return -1 if the PRL substring isn't found. This seems out of step with PRL the rest of Perl's functions, which return Cundef PRL on error. I propose changing index() and rindex() PRL to return Cundef if the substring isn't found. PRL This would also cause warnings to be issued when PRL programmers use the results of index() or rindex() PRL assuming the substring was found. Removing -1 as a valid result, could be a breakage (if someone is doing something weird with a negative result) Would it be reasonable to ask that passing undef into the offset or start of substr have substr return an undef? This would break the undef == 0 under normal circumstance, but it would prevent an error from propogating. $foo = "flabergasted"; substr($foo, index($foo, 'abc'), 20); # Returns undef If this is too much breakage what about only if it is the argument? $foo = "flabergasted"; $x = index($foo, 'abc'); substr($foo, $x, 20); # starts from the end chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 213 (v1) rindex and index should return undef on failure
"NT" == Nathan Torkington [EMAIL PROTECTED] writes:
Would it be reasonable to ask that passing undef into the offset
or start of substr have substr return an undef?
NT Wouldn't you get a warning anyway, if you were treating undef like
NT a number?
Aha, but I don't want a warning, I want the code to 'fail' reasonably.
Somehow I find
if (40 == ($foo = substr($bar, index($bar, 'xyz' {
}
much nicer than
if (defined ($offset = index($bar, 'xyz'))
(40 == substr($bar, $offset))) {
}
I use this style of safe failure when working in SQL.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
Basically a hash with
only the keys, no other baggage.
TC If you don't want but the keys, don't use but the keys.
Does that mean, that none of the other bookeeping for the values will
be done?
Is this "@hash{@keys};" valid?
Would it be possible to make push(%hash, @keys) work? Doesn't look likely
is @keys the keys, the values, or both?
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: $a in @b
"RLS" == Randal L Schwartz [EMAIL PROTECTED] writes:
RLS We really need a clean way to distinguish those four cases:
RLS "yes" and keep going
RLS "no" and keep going
RLS "yes" and abort after this one
RLS "no" and abort after this one
RLS What would you have "last" do? And how would you distinguish "the
RLS other one"?
Either last has to be extended with a return value or a new keyword
is needed. I'm quite partial to yield. Which might be overloaded
to work with lazy lists, continuations, and short-circuiting.
yield EXPR - stop what I am doing now and give something else a
a chance to do its things. And while you are doing
that please take this EXPR from me.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
"TC" == Tom Christiansen [EMAIL PROTECTED] writes: TC General cases should be preferred over special ones. TC We've never had named aggregate functions in Perl before that work TC like infix operators. What is the general proposal out of which this TC would intuitively decend? Sorry, I'm not understanding your question. 1+2 = 3 2*2 = 4 (1,2,3) U (2,3,5) = (1,2,3,5) (1,2,3) ^ (2,3,5) = (2,3) (1,2,3) x (2,3,5) = ((1,2),(1,3), (1,5), (2,2), (2,3), (2,5) ...) # yes, no nested lists. But what about # n-dim arrays/matrices/tensors/whatevers Seems just as useful as sin, cos, tan, **, and the other mathematical operations. And the proposals to make matrix operations ala Basic's MAT. Unless you want to go with my Set (@a, @b, @c);# Is the type distributive? @c = @a - @b; @c = @a + @b; @c = @a * @b; # cross product ? I'm not understaning your position. I could have used such an operation rather than rolling my own. And a module would be too heavy handed for such a simple concept. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 195 (v1) Retire chop().
"RP" == Richard Proctor [EMAIL PROTECTED] writes: Perhaps $/ and $\ should become per-filehandle variables, and there should be some way to set autochomp-on-read per filehandle, and auto-newline-on-output per filehandle. RP I can see a small benefit for autochomp-on-read but none whatsoever RP for auto-newline-on-output (even if you could decide when to send it). Use this all the time. perl -wl (or #!/usr/local/bin/perl -wl) It autochomps and then adds back the newline on the way out. Great for one liners, and in general when doing line at a time filter processing. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
-a and @F autospliting
Is there a fundemental reason (other than performance) that when using -a that the $1,...$n fields should not be populated in parallel? Yes, after a match they would be destroyed, but I find typing $1,$2 a lot easier than $F[0]. (And for one-liners, if a reference to @F is not seen or $1 before a regex operation, one or the other wouldn't have to be populated.) Thoughts? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Beefier prototypes (was Re: Multiple for loop variables)
"DC" == Damian Conway [EMAIL PROTECTED] writes: How would the parser handle this? Some '}' would need ';' some don't. DC The trailing C parameter specification tells the parser that there DC the last argument will be a raw block and that it need not be a followed DC by a semicolon. It's no harder than parsing an Cif, Cwhile, or Cfor, DC except that parser has to update itself when it sees the parameter DC specification. An excersize left for the student, eh? Sounds messy. That next brace could be one of many things. Does the prototype help guide the decision that it is a block and not an anon-hash? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: $a in @b
"AS" == Ariel Scolnicov [EMAIL PROTECTED] writes: AS Chaim Frenkel [EMAIL PROTECTED] writes: yield EXPR - stop what I am doing now and give something else a a chance to do its things. And while you are doing that please take this EXPR from me. AS When you put it this way, isn't Cyield spelled Creturn in Perl5? AS (Except, of course, that Creturn inside a Cgrep does a whole lot AS more nowadays). Err, no. return is much stronger. It goes to the caller of the sub. Yield would be relative to a much tighter scope. I think Randal would reject this, but if we make it an error to have a last/next/redo reach outside of a visible lexical scope, then last,next,redo would be 'weakest', followed by yield, return, die (and whatever is used for exceptions.) chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
The underlying problem is that arrays don't make SENSE as an
implementation for sets.
TC And even in those rare places where they do, to use them as such
TC is gratuitously counter-efficient.
Why? How is
@main_list = ;
@more_stuf = ;
@just_to_do_a_job{@main_list} = ();
@just_to_do_a_job{@more_stuff} = ();
@main_list = keys %just_to_do_a_job;
more or less efficient than
@main_list union= @more_stuff;
Both have to go through the same amount of work ("work is conserved")
but one is more efficient in terms of the user's brainpower.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
"AS" == Ariel Scolnicov [EMAIL PROTECTED] writes: AS They're going to be useful to a tiny minority of users: math folks AS whose application matches the use of a hash-based implementation. AS (Actually, all uses I've seen of set datatypes were strictly outside AS mathematics, but that doesn't alter your argument or mine). The AS problem is that the desired semantics (in the sense, e.g., of AS worst-case, average-case, and "my-case" complexity) of the "set" AS datatype vary greatly with application. Tiny minority? I'm no mathematician, but I've used set operations to avoid redoing known work. And I've used hashes simply because I have no other 'lazy' choice. But the code becomes harder to read. From a conceptual level, when looking at the code (not the surrounding application) I'm no longer working with the data, but rather with a side effect. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
"TC" == Tom Christiansen [EMAIL PROTECTED] writes: Thanks for the summary. (I wish you would be able or have the time to exand more often on your positions.) TC I think you still have some big hurdles here, however. Lists are TC crappy set reps. I don't want a set representation. I want set operations. And somehow for this having to add a use statment and who knows what overhead for what seems to be a simple operation is a pain. From an efficiency standpoint, all of the hash overhead (allocating buckets, assigning values, etc.) can be chucked all I would need is the key management part. Which could probably be boiled down to converting the hash key into a bit. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
"TC" == Tom Christiansen [EMAIL PROTECTED] writes: TC The overhead is not that it should be a module, but rather, TC the sillily/evilly inefficient thing that *you* are doing. TC Or trying to do. Why, For example, I need it as a sorted array 90% of the time. Some of the time I need/want to add a unique element. So, what do I do, keep it as an array and sort every time I access it? Keep two copies one as the hash the other as an array? TC We have modules to do this. We have hashes to do this. TC We have the technology. It is ignored. Ignorance of TC technology is no excuse for adding strange basic types TC and operations on them into the very heart of a programming TC language. I'm not ignorant of the technology. But having a method that directly represents my thought process, and does something that I need would be a win for me. Time for another missive in language design of why pop and push, shift and unshift are in, but union and intersection are not. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 90 (v3) Arrays: Builtins: merge() and demerge()
"DC" == Damian Conway [EMAIL PROTECTED] writes: DC I *still* think it should be "unmerge"! ;-) Hrmpf. It should be reshape. (Which would be its own inverse and saves a keyword.) chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 114 (v2) Perl resource configuration
"TC" == Tom Christiansen [EMAIL PROTECTED] writes: but that is the user's to set. PERL_PRELOAD TC is there for the user to unset. allows the admin to globally set (in the system shell rc file) the rc files that perl will load. TC And what sorts of things might the admin care to globally set? I actually might have found it useful as a way of avoiding a . ~/.profile in a crontab. A perl program would be externally customized based upon the machine/ user/whatver running it. A single 'executable' that can have itself configure. Yes, one could do it in the shell/program, but a simple 'standard' method might be worthwhile. use perlrc qw(:system :user); Though the range of options and settings are probably so vast that a single module capable of handling all scenerios would be so large and slow that all gains would be lost just in the invocation. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: $a in @b
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
grep { $_ == 1 } 1..1_000_000
grep doesn't short-circuit.
TC I never did figure out why "last" {w,sh,c}ouldn't be made to do
TC that very thing.
Hey, I suggested that a while ago, but Randal shot it down.
Something about the block not being a loop, I think.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: $a in @b
"DC" == Damian Conway [EMAIL PROTECTED] writes: DC I would propose that the Cgrep operation should short-circuit if the DC block throws an exception, with the value of the expection determining DC whether the final invocation of the block should accept the element it DC was filtering: Why not spell it 'yield'? It seems to have all the right connotations. A sort of soft return. Gives of itself. Very polite. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context
"NT" == Nathan Torkington [EMAIL PROTECTED] writes: NT Actually, the only refinement I'd like to see is that boolean operators NT (==, , ||) be excepted from the distributive rule. NT This is to permit: NT if (@a == @b) # shallow comparison NT and NT @a = @b || @c;# @a=@b or @a=@c; # ish NT The math operations are fine to apply to each element. I have no NT problem with those being distributive, but I think || for default NT values and == for comparison are too ingrained and they'd be too NT useful (as opposed to a distributive || or , which is much less NT useful). Then how would one get the distributed effect? An apply operator? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Beefier prototypes (was Re: Multiple for loop variables)
"PS" == Peter Scott [EMAIL PROTECTED] writes:
for ($x,$y,$z) (@a1,@a2,4..12,@a4) { ... }
Probably we'll have to say that the user must explicitly zip if that
is what is desired.
PS Yes, please. I view the flattening of lists as a feature, not a bug, and
PS it has made Perl a lot easier to understand IMHO.
I view it as a mis-feature. One is unable to return multiple arrays,
or to pass through multiple arrays without resorting to messy extra
punctuation characters.
It makes it 'necessary' to explode items onto the stack to operate properly.
(Yes, this can be optomized away, but retrofiting iterators and other
handling is probably a mess.)
The special case where the number of loop variables and the number of
supplied lists are equal should be either made explicit or optomized
if zip/merge/whatever is used.
Or
for ($x,$y,$z) ( (@x,@y,@z) )
an extra set of parenthesis could do the flattening. (only one list
is 'visible' as the argument to the for.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: Beefier prototypes (was Re: Multiple for loop variables)
"DC" == Damian Conway [EMAIL PROTECTED] writes:
my_while { pred() } { # don't gimme no Tcl flac.
...
} # no semicolon needed here!
DC Just added to the RFC :-)
How would the parser handle this? Some '}' would need ';' some don't.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 52 (v2) List context return from filesystem functions
Would returning the array of status be sufficient? @foo = chmod 755, "bar", "baz", "quux"; # @foo == (0, 2, 0); How to convert them to error messages would be a challenge. Unless passing them through $! would do the trick. Hmm, perl -wle '$!=3; print $!' No such process Yup, works. chaim "PS" == Peter Scott [EMAIL PROTECTED] writes: PS At 06:40 AM 8/30/00 -0600, Tom Christiansen wrote: My worry is that it seems like this would return an empty list on success, so: @foo = chmod 755, "bar", "baz", "quux" or die "Whoops, died on success!"; This seems to me to go contrary to the way perl tends to work... are there any other functions (beside system) that do this? Am I misunderstanding this? No, you've hit on the biggest flaw of the RFC. I am less enamored of it now than I once was. I'd still like to get those individual failure reasons but I am beginning to think it is not worth the cost. Anyone got a brainwave on how to have the cake and eat it too? I'm also concerned about all the separate errnos for each of those failures. PS where PerlLIO_chmod is defined as chmod on most righteous systems. So it PS would be a matter of squirreling away the errno for each bad result. PS I just can't get over the result in the successful case being an empty PS list, though. And conversely. Maybe this isn't itching enough to be worth PS scratching this hard, but it seemed like a good direction :-( Anyone got PS any brilliant ideas before I withdraw it? -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 39 (v3) Perl should have a print operator
"ABH" == Ask Bjoern Hansen [EMAIL PROTECTED] writes: Oh, why not? Does anybody actually *ever* check the return value of print? I think it's not as if we'd break a lot of code. ABH uh, what? you don't do much socket programming now, do you? sockets ABH breaks all the time. Disks runs out of space while you write to ABH files. and so on and so on. Could someone enlighten this poor soul and tell me what I _can_ do with an error return from a print or close? Reporting it may be useless (disk full). While I'm asking, what does one do while switching around file descriptors and an error is returned. Is there anywhere to report it? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: The distinction between do BLOCK while COND and EXPR while COND should go
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
TC Oh. You want lists to act like arrays. That's a very big change.
Do you have any objection? The intended avoidance of flattening to as
late as possible might have that effect.
You are letting the scalar context of the caller to bleed through the return
and effect the _syntatic_ meaning of the comma.
TC So what?
I just find it jarring. If scalar fn( (1,2,3) ) doesn't make the comma
into the comma operator, (This one is galling) nor does
sub fn {scalar(return (1,2,3)) }
why should $x = fn() do the same?
TC return @ENV{HOME,USER,TERM};
TC had jolly well not be returning 3. I'm returning a LIST, dang it.
TC I don't ever expect a list to be an array. Try popping it, for
TC example.
You are confusing me. In perl5 can a routine return an array? So
what is the difference?
@a = @ENV{HOME,USER,TERM};
return @a
It still can't be popped. Please tell me what we lose by throwing away
the distinction between lists and arrays? Why not simply make them,
for perl6, into an anonymous array?
Any reason $foo = pop fn Shouldn't be valid?
Then perhaps
@foo = unshift(fn, 12)
might also become reasonable.
TC Yes, I object.
TC The comma is NOT changed. It's doing exactly what a list does.
TC It never returned an array. You now want (1,2,3) to be an array!!
Then please explain why scalar(return (1,2,3)) doesn't do what at first
glance it seems it should.
And for the life of me I can't see how
$x=(1,2, (3,4,fn,6) )
fn ends up in scalar context.
I'm able to accept that $x=(...) has the inside of the parenthesis in
a scalar context . But with $x=(, (), ...), why shouldn't the
nested set of parenthesis make its insides into a list.
Perhaps that's my block. For me the return takes away the thrust of the
outside scalar context.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: The distinction between do BLOCK while COND and EXPR while COND should go
"TC" == Tom Christiansen [EMAIL PROTECTED] writes: TC You will be miserable until you learn the difference between TC scalar and list context, because certain operators know which TC context they are in, and return a list in contexts wanting a TC list, but a scalar value in contexts wanting a scalar. TC It sounds that you've not yet eradicated the misery of, well, if TC not ignorance, then at least of misunderstanding as far as it TC goes to how this context thing works. I think we are in the edge cases here. I've been doing perl since sometime in the mid perl4's and clearly I haven't run into something that depended upon this. I wonder how much it would hurt the -internals work. I think I'm not alone in wanting to make the list/array dichotomy go away. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: functions that deal with hash should be more liberal
"NT" == Nathan Torkington [EMAIL PROTECTED] writes: NT Casey R. Tweten writes: Wow. Now that, that, is lame. You're saying that keys() expects it's first argument to begin with a %? Why should it care what it's argumen begins with? NT The keys function changes its arguments' data structure. keys resets NT the each iterator (see the documentation for these functions). Wouldn't this have to change to support iterators and threading. All functions recieve their arguments in a LIST via @_. NT The hash functions are prototyped as \%, meaning they are passed a NT reference to the hash named as an argument. The reference-taking: NT * permits them to change the data structures NT * is faster (one value, not all the key/value pairs) What if keys were extended to operate on arrays? Then keys $foo might be an acceptable extension. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: The distinction between do BLOCK while COND and EXPR while COND should go
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
I don't want to jam a list into anything. I want it to remain a list.
TC Then it won't fit. Don't you understand? YOU CANNOT LET IT REMAIN
TC A LIST AND PUT ALL THOSE THINGS IN A SCALAR SLOT.
sub fn { return (3,5,7) }
$x = fn; # I want $x==3
Let me try once more. I want that fn() to act like
sub fn { my @a = (3,5,7); return @a}
You are letting the scalar context of the caller to bleed through the return
and effect the _syntatic_ meaning of the comma.
TC This is not a new concept, nor an isolated one. Here's another list:
TC $x = @ENV{HOME,USER,TERM};
Not the same. I'm only interested in action-at-a-distance. Where there
is a sub and a return in between. I have no objection to that.
TC Sure, there are functions that can do those things, but these
TC aren't functions who get to be quirky. This is completely
TC expected.
To you perhaps. I feel that the syntactical change is unexpected.
But do you any objectsions to making this limited change? When the
EXPR of a return is a literal list, it should not have its comma
changed?
Will my proposal bleed into anything else in the language?
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: The distinction between do BLOCK while COND and EXPR while COND should go
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
It might be worthwhile enough to kill
sub fn { return (7,8,9,10) }
$x = fn(); # $x == 10
TC But this happens many places. What about @foo[4,1,9,-2]?
TC It's just a listish thing. One should learn.
I don't want that to change. I simply want that return (I'm not sure
how to phrase this) be able to return only a scalar or an aggregate.
It should be immune from having a scalar context pushed through from
the caller and change the commas from a list seperator into the comma
operator.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 178 (v1) Lightweight Threads
"SWM" == Steven W McDougall [EMAIL PROTECTED] writes: Not unless it is so declared my $a :shared. SWM Sure it is. SWM Here are some more examples. SWM Example 1: Passing a reference to a block-scoped lexical into a thread. Depends on how locking/threading is designed. There is a fundemental issue on how values are passed between threads. Does the value leave one thread and enter the other or are they shared. The idea tossed around -internals was that a value that crosses a thread boundary would have a wrapper/proxy attached to handle the mediation. The mediation would be activated only if the value is passed via a shared variable. In your case the shared variable is the argument being passed through the thread creation call. SWM Example 2: Declaring one subroutine within the scope of another If we don't require a :shared on variable anything and everything has to have protection. If you want the variable to be shared declare it. SWM Example 3: Closures (Ken's example) Aha, I get it. -internals has been assuming that one _must_ specify the sharing. You want it to be infered. I think that's asking for too much DWIMery. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: The distinction between do BLOCK while COND and EXPR while COND should go
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
TC Well, that depends. Often you must delay till run-time. When Perl
TC simply sees something like:
TC sub fn { return @blah }
TC it can't know whether you'll use that as:
TC $x = fn();
TC or
TC @x = fn();
TC or
TC fn();
I think with the -internals idea of pushing a thingee on the stack
rather than flattening the list, the actual effect of the assingment
can easily be delayed with little cost to runtime.
Though Randal will jump all over me. It might be worthwhile enough
to kill
sub fn { return (7,8,9,10) }
$x = fn(); # $x == 10
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 120 (v2) Implicit counter in for statements, possibly$#.
This is making the index variable into an a wrapper object.
Since the underlying value can't (or shouldn't) know which of the n
containers it is in.
chaim
"JSD" == Jonathan Scott Duff [EMAIL PROTECTED] writes:
JSD Interesting. I must have missed this. I'm not wild about the syntax,
JSD but I like the idea. If everything become objects under-the-hood,
JSD then we could have:
JSDfor $a (@array) { print "$a is at $a-index\n"; }
JSD No, I'm not wild about that either, but it's an idea.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: Pre-RFC: Require a warning on spaces after here-document terminator
"LW" == Larry Wall [EMAIL PROTECTED] writes: LW : This can be very hard to discover. I find it hard to see myself doing LW : this on purpose. I would like to see a compiler warning for this: LW : "Spaces detected after apparent here document terminator", but LW : preferably phrased better. LW : LW : Are there any objections? LW I object, vaguely. I think it should just Do The Right Thing. LW (I suspect it should ignore spaces on the left to.) This was suggested a while back in p5p. But it was shot down. I can't remember the reason offered. (Speed?) I can see a possible issue print EOF;# or 'EOF' The following is not the end EOF But this one is EOF Though I don't really see a very good use for having trailing invisible characters. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Threads and run time/compile time
I wish I knew why you are discussing in -internals issue on this list. You should be specifying behaviour not how it is implemented. A mention of implementation is reasonable but _don't_ spend too much time. If Larry wants it. -internals will give it to him. Anyway, please recall that because of threading concerns, the final internal form of any compiled piece of code will be as immutable as possible. So that if another thread needs to reslurp a module, the compiled form will be available. Of course, some initializations would have to be rerun, but that is minor compared to the other costs. Remember specify _as if_ it would do X. -internals will make it so. As fast as possible. chaim (Of course some requests will not be doable and some revisitin will have to be performed but the first cut should not be too concerned.) c "SWM" == Steven W McDougall [EMAIL PROTECTED] writes: SWM Based on your examples, I have to assume that you are serious about SWM RFC1v3 item 6: SWM 6. Modules should be loaded into the thread-global space when used SWM[...] SWMSubsequent threads should then reslurp these modules back in on SWMtheir start up. SWM[...] SWMeach thread needs to reuse the original modules upon creation. SWM[...] SWMThis, of course, could lead to massive program bloat SWM This is a non-starter for me. Right now, I am working on apps that may SWM create 10 threads per *second*. I cannot possibly get the performance SWM I need if every thread has to recompile all its own modules. SWM We could either discuss alternate approaches for RFC1, or I could SWM submit a new RFC for a thread architecture that gives me the SWM performance I want. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Something akin to ksh's () and () syntax
With threading coming, would having a () and () syntax be useful?
So within the () and () constructs STDIN and STDOUT (or perhaps only
the default filehandle) would be redirected.
sub proc_arg1 { while() { } }
sub proc_arg2 { while() { } }
while() {
({proc_arg1}, {proc_arg2}) = split;
}
Damian, You have coroutines/generators out there. What about a data sink?
Anything you have currently proposed that would do this neatly.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
"NT" == Nathan Torkington [EMAIL PROTECTED] writes: NT This is good for comparison but bad for math. Epoch seconds are NT good for both. That's why *I* use them. You can continue to use NT ISO mumble and have it work for you. I'm not breaking your code. NT There's also the issue that Perl code should (where practical) be NT portable by default. Perl tries to cover up operating system NT oddities. This is one oddity that can (and, I think, should) be NT covered up. I really don't care. As long as I can _easily_ convert it to the system native format. So are you proposing that perl carry/develop/borrow/steal its own date/time library? Because if you do pick an epoch, the native library may not be able to carry you far enough. So pick your poison, are we subject to the whims of the platform or should we stand on our own two feet? Strange thought just crossed my mind. Would having a time object that is understood by perl be sufficient? It would smell and taste like an integer but would otherwise be magical. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
JH "The first operation done on the return value of open() shall be defined()
JH or you shall regret your pitiful existence."? (a flag on the scalar coming
JH from open that makes any other op than defined() to die and defined() clears
JH the flag)
Ala, taint? Except the variable is tainted with death?
Hmm, this would make two types of undef. Actually, if a callee could
death-taint a variable then the return death_tainted(42) would make
the caller check his values on first use.
But the drawback would be that the actual victim may not be the primal
cause.
sub foo {
my $fh = open();
... Lots more code ...
return $fh;
}
$victim = foo;
print $victim "I'm helpless";
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
But the drawback would be that the actual victim may not be the primal
cause.
sub foo {
my $fh = open();
... Lots more code ...
return $fh;
}
$victim = foo;
print $victim "I'm helpless";
JH Tough.
Not a nice attitude. The failure is not close to the cause. Neither in
time or space.
If it were closer to the open, at least an intellegent message might
be displayed. Your way, nothing but.
*ARRGGHHH*, tainted data, in Foo.pl at line 37 chunk 12
(Why does that remind me of rogue?)
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 127 (v1) Sane resolution to large function returns
I'm missing what you are trying to say. Are you suggesting that $foo = @bar no longer mean ($foo = scalar(@bar)) == 3 ? I wasn't suggesting going that far. Just a little more DWIM. So that ($foo, @bar, $baz) = (1,2,3) # $foo = 1 @bar=(2,3), $baz = undef # or # $foo = 1 @bar=(2), $baz = 3 ($foo, @bar, $baz) = (1,(2,3),4) # $foo = 1 @bar=(2,3), $baz = 4 But ($foo, $baz, @bar) = (1,(2,3),4) # $foo = 1 $baz=2, @bar=(3,4) Actually, looking at it like that makes it an ugly situation. The 'new' expectation would be to have it become # $foo=1 $baz=2 @bar=(4) *blech*, I'm glad that you're doing the thinking. chaim "LW" == Larry Wall [EMAIL PROTECTED] writes: LW Chaim Frenkel writes: LW : LW P.S. I think we *could* let @foo and %bar return an object ref in scalar LW : LW context, as long as the object returned overloads itself to behave as LW : LW arrays and hashes currently do in scalar context. LW : LW : Isn't this an internals issue? LW Not completely. The scalar value would visably be a built-in object: LW @bar = (0,1,2); LW $foo = @bar;# now means \@bar, not (\@bar)-num LW print ref $foo, $foo-num, $foo-str, ($foo-bool ? "true" : "false"); LW ^D LW ARRAY3(0,1,2)true LW One implication of this approach is that we'd break the rule that says LW references are always true. Not clear if that's a problem. It's basically LW already broken with bool overloading, and defined still works. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 127 (v1) Sane resolution to large function returns
"LW" == Larry Wall [EMAIL PROTECTED] writes: LW Dan Sugalski writes: LW : And do we want to consider making this (and its ilk) Do The Right Thing? LW : LW :(@foo, @bar) = (@bar, @foo); LW We certainly want to consider it, though perhaps not in -internals. LW You can talk about passing @bar and @foo around as lazy lists, and LW maybe even do lazy list-flattening, but I don't see how that works yet, LW even in the absence of overlap. The basic issue here may come LW down to whether the LHS of an assignment can supply a prototype for the LW entire assignment that forces everything to be treated as objects LW rather than lists. LW That is, right now, we can only have a scalar assignment prototype of ($), LW and a list assignment prototype of (@). We need a prototype (not just LW for assignment) that says "all the rest of these arguments are objects", LW so we don't have to use prototypes like (;\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@). LW Or (\@*) for short. Isn't that what Damian's named (whatever, formerly known as prototypes) does? @_ in the absence of a named argument list would continue to act _as if_ the argument list were flattened. With a named argument list, it would make the actual refs on the stack visible. The question that I think Dan proposed is how much breakage would infering (@foo, @bar) = (@bar, @foo) to mean treat RHS as objects, cause. Wouldn't having and @ anywhere but the last position in the list would be a useful indicator. I can see someone (Probably Randal or Tom) wanting to initialize a list that way. But for the rest of us, it isn't that useful. LW P.S. I think we *could* let @foo and %bar return an object ref in scalar LW context, as long as the object returned overloads itself to behave as LW arrays and hashes currently do in scalar context. Isn't this an internals issue? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: On the case for exception-based error handling.
"PS" == Peter Scott [EMAIL PROTECTED] writes:
PS From the reactions on this thread so far I am wondering whether the
PS message I sent out about it when it had a different name got
PS through. Relevant excerpt:
PS Well, you could certainly have a pragma that makes throw set $! to the
PS message and does a return undef. But that will only return from the
PS current subroutine; there could be a bunch of module subroutines between
PS that one and the module user. Asking module programmers to keep straight
PS two possible flows of control in error situations, no less, is asking for
PS trouble. If you think it can be made easier, can you show an example?
Actually, why not simply unwind the call stack to the routine that
has the pragma active.
sub foo {use exception; baz()}
sub baz { throw "a fit" }
sub bar {
no exception;
foo();
}
The unwind logic would treat a scope with no exception set _as if_
each call were wrapped in at try block.
PS ***But it's entirely up to each programmer whether or not they use
PS Fatal-checking*** This is the Perl way anyway.
Fatal checking, is for core functions. And optional for module authors.
Then Fatal.pm and exception.pm could possibly be consolidated.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 132 (v1) subroutines should be able to return an lvalue
"JV" == Johan Vromans [EMAIL PROTECTED] writes: These two should have different actions. $foo = foo; foo = $foo; Perl needs a value for one, and a reference for the other. JV I'm not sure I understand what you trying to say here. Please explain. The difference between RHS and LHS. RHS, perl is manipulating values. With LHS perl is manipulating locations, storage areas. Where to put those values from the RHS. So RHS are values (even if a reference, it's meaning as a value is of interest) LHS are pointers. Where to save the value from RHS. So an lvalue sub on the RHS should be returning a _value_ an lvalue sub on the LHS should be tell Perl where to shove^w put the value. (Hey, perl, I want that dohickey put into my array at position 42.) JV - make it unfeasable for methods. Why? All methods for the same OO hierarchy should have the same signature. JV Assume class Foo has a method m that returns a scalar lvalue, and JV class Bar has a method m that returns an array lvalue. The following JV code is now perfectly legal (though weird): JV my $o = $some_condition ? Foo::-new() : Bar::-new(); JV $o-m = another_sub(); JV 'another_sub' calls wantarray. What should it return? That's the point. Perl has to examine $o-m 's return to determine what is going on. So $o- has to be called first. And the resulting reference queried about it's type. And then the want() will return the correct context. In the another_sub( lvalue_sub ), lvalue_sub has to be defered until the first time it is called. (Unless Damian thinks that reaccessing it each time will make more sense.) chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: yoda 2
"DLN" == David L Nicol [EMAIL PROTECTED] writes: DLN =head2 eval/die remains perfectly workable DLN as "die" is a perfectly serviceable method or raising an exception. Actually, die is pretty nasty. Modules can't use it. Another mechanism that means, short circuit, but let the user know why. That selects either a non-local goto or a return mechanism depending upon context. (Dynamically within the control of a try/eval, or under pragmatic control requesting the non-local mechanism.) chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Dual nature (was Re: Exceptions and Objects)
"PS" == Peter Scott [EMAIL PROTECTED] writes:
PS At 07:00 PM 8/16/00 -0400, Chaim Frenkel wrote:
Perhaps, throw can carry a return value?
throw {"return value"} $exception;
If there is an active try/catch context then the $exception would
be propogated, otherwise $@ would get loaded with $exception and
the return value would be the specified value.
If not specified then it would be the same as a return with no
arguments.
PS But what of RFC 70, which wants the option for exceptions in system calls
PS to cause program death?
PS Also I don't like code deciding to do something different depending on a
PS context that's possibly miles away.
That would be a choice of the main program, Either wrap itself in a try.
or a pragma that probably would look nicer.
Actually, this would be no worse than any other perlian context. If
the effect of a scalar context could make a remote literal ',' become
a comma operator, than this can't be any worse.
Another way to look at it, is that it _doesn't_ effect the callee. The
callee wishes to terminate the function, and the next
statement/expression will not be executed. The callee supplies the
result. The caller is deciding how the results will be delivered.
Hmm, I'm sure that some authors who like the error return style would
like the pragma to force return context so that they don't have
to wrap everything in a try.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: Towards a reasonable unwinding flow-control semantics.
"PS" == Peter Scott [EMAIL PROTECTED] writes:
PS At 07:10 PM 8/16/00 -0400, Chaim Frenkel wrote:
"PS" == Peter Scott [EMAIL PROTECTED] writes:
PS 1. When an exception is thrown perl looks for the enclosing try block; if
PS there is none then program death ensues.
Err, if there isn't one. Don't throw the exception. Stop processing but
don't throw. You are imposing a style on your caller.
PS ??? I don't get this at all.
Consider a module A uses try all over the place. Module B uses procedural
call, and accepts callbacks from A.
The callbacks from A raise/throw around B. B's author would like to
be able to do some cleanup, restore invariants, whatever, after a
callback fails. By allowing the caller to determine how the errors
are delivered we are allowing the author more freedom in his design.
So all he would need to add would be a lexical pragma, use exception 'return'
A message would be appropriate (ala, die or warn)
Also a use (within main or if it can work lexically) that would mean
die_if_exception_thrown. Would treat the main routine as if it were
wrapped in a try block that doesn't catch any exceptions.
PS RFC 63 already states this. Uncaught exceptions at the outermost
PS level are dies. (And there is a very close relationship between
PS die and throw.)
But I don't want that. Why? Throws are error returns not death.
A module author should _never_ invoke die. How does the module author
know what the caller wants to be done.
I just don't want to be forced into scattering lots of little try{}
just to get back to my error return style of coding.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 104 (v1) Backtracking
"MC" == Mark Cogan [EMAIL PROTECTED] writes: is equivalent to @a = (\$a, \$b, \$c); rather than what you wrote. MC Ah, so it is. I'd argue that that's broken and should be handled with map MC or for. Err, That's not an accident. Larry designed that in. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Default filehandles(was Re: command line option: $|++)
I'm not sure if you are disagreeing with me or not. The context was the statment that $STDOUT is the _default_ filehandle. I was pointing out that by _overriding_ the instantaneous meaning of $STDOUT to the default fail handle, one would lose the immediate access to the previous value. I.e. $STDOUT should always mean one and only one file at a time. Unless one wants to have a $DEFAULT filehandle and get rid of single arg select. chaim "JSD" == Jonathan Scott Duff [EMAIL PROTECTED] writes: JSD On Tue, Aug 15, 2000 at 06:53:30PM -0400, Chaim Frenkel wrote: What if you want to print to a default file handle and also to STDOUT? select(OTHERFH); print "This goest to OTHERFH\n"; print STDOOUT "This went to STDOUT\n"; JSD print $_ "Here I come to save the day!\n" for ($PERL::STDOUT, $myfh); JSD And again, if you want to print different stuff to different JSD filehandles, you know how to use the JSDprint FILEHANDLE LIST; JSD version of print. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
"BB" == Buddha Buck [EMAIL PROTECTED] writes: BB I am assuming that the system clocks are set accurately to UTC (or some BB derivative, like (US) Eastern Standard Time). UTC is what time-servers BB report. UTC has leap seconds, which are inserted (or, theoretically, BB deleted) at the end of December 31st and June 30th, as needed. Oh, I was under the impression that they only occur at Dec 31. BB This means that 86400 seconds (one day) after 2000 Dec 31, 12:00:00 UTC BB is not necessarily 2001 Jan 1, 12:00:00 -- it could be 11:59:59 or BB 12:00:01 as well. And there is no way to know that ahead of time. Hmm, there are negative leap seconds? BB If we have to pick and epoch in an OS-neutral way, I think I for one BB would be happy with something like this in the docs for the time BB functions: BB BB All date and time functions, unless otherwise documented, assume the BB use of the International Atomic Time (TAI) timescale. TAI differs from BB standard time (UTC) in that TAI does not have "leapseconds". BB It is likely that the OS clock was set to UTC, not TAI. This slight BB difference (22 seconds as of 2000) should not cause any problems unless BB date computations of over 6-months with second accuracy are needed. BB time() returns the number of seconds elapsed since the beginning of the BB International Atomic Time (TAI) timescale, 00:00:00 UTC 1 January 1958. BB date($) returns a year-month-day-hour-minute-second representation of BB the time passed to it (in seconds since the TAI epoch). The BB representation assumes the TAI timescale. BB - So if I understand you, the instantaneous time is correct. But calculating backwards to what the instantaneous time would have been, or calculating what the instanataneous time will be will not work. But your blurb would be a lie. How would one ensure the correct difference to the TAI? And what would be the translation to the system time? What do we do with stat(), utime(), sleep(), select(), events, etc. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 82 (listops in list context)
(Not feasible yet, but...) Would Unicode reduce the problem? Take some operators from the math symbols and make them the matrix op versions? Then the 'ascii' versions would remain the scalar ops. I can see that this would give problems for current editors and displays, but by the time perl6 comes out, perhaps the situation would be better. (Now, if we add all that APL symbols ...) Thoughts? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
"BB" == Buddha Buck [EMAIL PROTECTED] writes: BB stat() returns time stamps (made in the past). utime() sets time BB stamps. They should be compatible with time(). e.g., "utime BB time,time,@files" should still set the modify and access times of BB @files to "now". With or without a translation? BB sleep(), select() both take intervals. The time scale is irrelevant. It does matter, depending upon what an external system may supply. BB Will events need time stamps, intervals, or other (please specify)? Why ever not? I don't think the epoch matters. What matters is that all parties to a programatic communication agree or we can illustrate that it doesn't matter. But if it really doesn't matter, then why have something different than the system epoch. Either one or both of: Perl - Perl cross system will break. Perl - other program same system will break. Pick your poison. I'd rather have cross system break. But if the epoch were available then an adjustment could be made intellegently. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 111 (v1) Whitespace and Here Docs
"MF" == Michael Fowler [EMAIL PROTECTED] writes: MF So what's insufficient about: MF print "EOF"; MF Stuff MF More stuff MF Even more stuff MF EOF Counting spaces, why make the programer work. Are those tabs or spaces? And it doesn't strip the leading whitespace. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 84 (v1) Replace = (stringifying comma) with =
"KH" == Kai Henningsen [EMAIL PROTECTED] writes: KH Hashes and arrays, OTOH, really aren't different for people. The concept KH of an index needing to be a nonnegative number is a computer concept. I don't know about that. Good old PL/I had arbitrary ranges for array indices. Hmm, I feel an RFC coming on my @arr :low(-32000) :high(+32000); my @population :low(1900) :high(2039); $population[1923] = 323000; How about my @population[1900:2039]; Looks funny though. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 83 (v2) Make constants look like variables
"JS" == John Siracusa [EMAIL PROTECTED] writes: JS On 8/16/00 12:37 PM, Perl6 RFC Librarian wrote: It is proposed that a new syntax for declaring constants be introduced: my $PI : constant = 3.1415926; my @FIB : constant = (1,1,2,3,5,8,13,21); my %ENG_ERRORS : constant = (E_UNDEF='undefined', E_FAILED='failed'); Constants can be lexically or globally scoped (or any other new scoping level yet to be defined). JS I'm not crazy about the "attribute" syntax's use for constants. I prefer JS this: JS constant $PI = 3.1415926; Propose it but I believe that Larry has already semi-blessed the attribute version. The problem with the prefix version is that that is already reserved for my/our/local. And constant-ness in my mind is an attribute or modifer of the value or perhaps of the container. It has no bearing on the scoping or type of the value. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Make lvalue subs the default (was Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument)
"NW" == Nathan Wiger [EMAIL PROTECTED] writes: NW The concept isn't that hard ":lvalue makes it so you can assign to NW subs". But the hard part is deciding *where* it should be used. I think NW it puts an unfair burden on a CPAN author to try and forsee all the NW possible uses of a sub. I'm sorry but this doesn't make sense? $foo-twiddle = 42; What if twiddle is my scramble eggs routine? Why are you assigning a value. The author decides how his routines are to be used. You the client likes it great. You think there is a better _approach_ then tell the author. You are limited by what the author wrote. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument
"CN" == Chris Nandor [EMAIL PROTECTED] writes: CN Can we please cut down on the traffic to perl-announce, maybe make it CN moderated? Thanks, Perhaps, the esteemed Librarian could make the -announce a Bcc? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 63 (v3) Exception handling syntax
"PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes:
PRL RFC 80 proposes standard exception classes and methods for core exceptions.
PRL This RFC doesn't need to repeat those, but it can expound upon the
PRL semantics that exception classes ought to have. Assume wlog that they
PRL all inherit from a base class, CException. Some people think that
PRL exceptions should not be rethrown implicitly. We can provide a boolean flag
PRL in the class or even the exception object itself to be checked for this:
PRL sub Exception::IO::implicit_rethrow { 0 }# One class
PRL sub Exception::implicit_rethrow { 0 }# All classes
PRL throw Exception::Socket(implicit_rethrow = 0); # Just this exception
PRL [Note: it had been proposed that this functionality would be provided by a
PRL method Cuncaught_handler which would be called if an exception wasn't
PRL caught.
PRL But if that routine decided to rethrow the exception, the Ccontinue block
PRL would not get called at the right time.]
Please include the comments about global variables and action at a distance.
PRL =head2 Exception classes - ignoring
PRL Note that we could also make it possible to selectively or globally ignore
PRL exceptions, so that perl continues executing the line after the Cthrow
PRL statement. Just import a Cignore function that takes a class name:
PRL ignore Exception::IO; # Ignore all I/O exceptions
PRL ignore Exception; # Ignore all exceptions
PRL and when perl sees the Cthrow, it just does nothing. (Or do it by
PRL overriding a base class method as for Cimplicit_rethrow if you don't want
PRL to put another function in the namespace.) Since Cthrow and Cdie
PRL should be essentially identical, this would allow any kind of exception to
PRL be ignored, not just the ones that were Cthrown. This is not necessarily
PRL a good thing, of course.
Oh, no! Are you really suggesting that after
open (FOO, "nonesuch") or throw "file not found"
The next statement continues??
How in $DIETY's name do you expect to protect code?
PRL =head2 $SIG{__DIE__}
PRL $SIG{__DIE__} needs to be triggered only as a Ilast resort
PRL instead of firing immediately, since it messes with the mind of this and
PRL every other decent exception handling mechanism. Perhaps it should be axed
PRL altogether. Please.
$SIG{DIE} should die. Action at a distance. Global. Can't know what
other threads or modules want done here.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: Default filehandles(was Re: command line option: $|++)
"JSD" == Jonathan Scott Duff [EMAIL PROTECTED] writes: JSD On Tue, Aug 15, 2000 at 12:57:46PM -0700, Nathan Wiger wrote: This is a succinct summary of the basic conclusions thus far: 1. a default filehandle IS needed sometimes, but only for stuff like print JSD Well, I think that Cprint should always print to $PERL::STDOUT (or JSD whatever we call it) always; same with Cprintf(). I'd hardly call that JSD "default" though. Err, no. What if you want to print to a default file handle and also to STDOUT? select(OTHERFH); print "This goest to OTHERFH\n"; print STDOOUT "This went to STDOUT\n"; STDOUT is _not_ the default filehandle. It is the currently selected filehandle when perl starts. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Default filehandles(was Re: command line option: $|++)
"NW" == Nathan Wiger [EMAIL PROTECTED] writes: NW2. $|, $\, $/, etc will probably go away entirely in NW favor of object methods such as $handle-autoflush It think they will still be needed as lexical variables used as an initializer for the corresponding per-filehandle value. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
Why? What is the gain? Perl only runs on the local machine. As long as one can increment and take the difference what difference does the epoch make? What is of more interest would be knownig the valid range of time supported on each platform. Even if you standardize the epoch, the platform may be unable to calculate to the epoch. chaim "PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes: PRL =head1 ABSTRACT PRL Currently, internal time in Perl is maintained via Ctime, which is PRL highly system-dependent. On some systems, this is relative to the UNIX PRL epoch, while others use their own epochs (MacPerl uses 1904, for PRL example). PRL All versions of Perl on all platforms should maintain time both PRL internally and externally as seconds since the UNIX epoch (00:00:00 01 PRL Jan 1970 UTC). -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 105 (v1) Downgrade or remove In string @ must be \@ error
"PS" == Peter Scott [EMAIL PROTECTED] writes: I want this to *always* print out the _value_ of @stuff, even if it's unititalized. PS Arrays aren't uninitialized. They contain zero or more scalars, some of PS which may be uninitialized. I don't know if it is still true. But at one point in perl's life defined(@arr) was false before anything was assigned to the array. At this point this is highly frowned upon. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 104 (v1) Backtracking
You are missing the beauty of vector/matrix operations. The math folks really would like to be able to describe the operation wanted and have perl do the optimization. Would adding another character be helpful @result = @a x|| @b? @result = @a ||| @b? or perhaps a modifier? @result = @a || @b forall; (Blech, that just doesn read right.) chaim "MC" == Mark Cogan [EMAIL PROTECTED] writes: MC At 05:47 PM 8/15/00 -0600, Nathan Torkington wrote: Jeremy Howard writes: @result = @a || @b; Which applies '||' component-wise to elements of @a and @b, placing the result in @result. *Ptui* That's not how *I* want || to behave on lists/arrays. I want @result = @a || @b; to be like: (@result = @a) or (@result = @b); That's what all my students keep expecting it to mean. MC Seconded. MC It seems obvious that @a should be the whole array @a, not an iteration MC over its elements. If I want to iterate over @a, I should have to do so MC explicitly, with a for() or map(). -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch
"BB" == Buddha Buck [EMAIL PROTECTED] writes: Why? What is the gain? Perl only runs on the local machine. As long as one can increment and take the difference what difference does the epoch make? What is of more interest would be knownig the valid range of time supported on each platform. Even if you standardize the epoch, the platform may be unable to calculate to the epoch. BB Unfortunately, the valid range of time supported is easily determined, BB and disturbingly short: BB Into the future: to next December 31st or June 30th, whichever is BB closer. BB Into the past : to past January 1st or July 1st, whichever is BB closer. Sorry, this makes no sense. BB Leap-seconds are a PITA for generic time routines. Why? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 104 (v1) Backtracking
"MC" == Mark Cogan [EMAIL PROTECTED] writes: MC What should: MC @a = defined @a; MC return? Counter example:@a = \($a, $b, $c); (Not really a full fledged counter example since it is a liter list.) Treating || as a special case is asking for trouble. If you want a flow control statement, use one: @result = @b unless @result = @a; MC || may be a suboptimal example, but I think the idea that a @-variable MC without an iteration function refers to the array as a whole, and not its MC elements is an intuitive one, and having array iteration magically happen MC when you're not looking is dangerous. Not unless you are coming from a math background or are an old basic programmer, and would like to have matrix operations built in. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)
"RA" == Russ Allbery [EMAIL PROTECTED] writes:
RA Is Perl currently using different epochs on different platforms? If so, I
RA can definitely see the wisdom in doing something about *that* and
RA off-loading the system-local time processing into modules (although I can
RA also see the wisdom in leaving well enough alone). But why not go with
RA the most commonly used and most widely analyzed epoch?
Folks, the only problem that everyone seems to be arguing about is
what the EPOCH is. Who cares what the epoch is?
Create $Perl::Time{EPOCH} and be done with it.
As long as I can add and subtract a reasonable range of time values and
get a reasonable result I'm happy.
There should be no assumption that 0 is the epoch. It might well be
that some other arbitrary number is the limit of valid time. So unless
perl is going to distribute portable time and date calcuations, as
part of the core, we will have to live with whatever the system
libraries give us.
(I don't want to think about Leap Seconds just yet.)
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: errors and their keywords and where catch can return toand stuff like that
I think folks are forgetting that there are more than one client for
any class. Global settings should be restricted to a single setter.
The only logical single setter is main. All other clients should
be using something local.
Another reason to avoid globals, is we are designing perl6 to be thread
friendly. Adding globals (this includes read-mostly access) adds overhead,
cost and yet another variable that increases deadlock potential.
Just say no to globals (as much as possible)
chaim
"PS" == Peter Scott [EMAIL PROTECTED] writes:
PS Everyone seems to have started thinking about the implication of
PS inheritance in exception classes at the same time. Whatever the default
PS behavior is, we can easily change it on a global basis (using Chaim
PS Frenkel's sub name here);
PS sub Exception::uncaught_handler { maybe rethrow, maybe not }
PS Or a per-class basis:
PS sub Exception::IO::uncaught_handler { ... }
PS Or a per-object basis (gross as I find this):
PS my $e = Exception::SQL-new(...);
PS $e-uncaught_handler = sub { ... }
PS throw $e; # or maybe throw Exception::SQL(uncaught_handler = sub { ...
PS }, ... );
PS And the dispatcher would look first in the object, then in the class for
PS uncaught_handler.
PS I think it's cool how this process is converging :-)
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 97 (v1) prototype-based method overloading
"ABH" == Ask Bjoern Hansen [EMAIL PROTECTED] writes:
=head1 ABSTRACT
When I read the chapter on OO in the second edition camel book I
was saddened that C++ style method overloading was not explicitly
described. Ever hopeful, I wrote some quick code that I hoped would
do what I meant and discovered that it didn't. This document is
an attempt to remedy the situation.
=head1 SUMMARY
$frog_t = qs(frog);
sub listargs($){ print "One arg, $_[0]"}
sub listargs($$){ print "Two args, $_[0] and $[1]"}
sub listargs($$frog_t){ print "$_[0] and a frog $[1]"}
sub listargs { throw argsyntax, "odd arguments to listargs" }
Please do not do this.
It is a mess.
Action at a distance.
There are otherways to solve the same problem.
Why would anyone want to select a different method based upon the arguments.
The calling routine can easily dispatch differently.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)
"JV" == Johan Vromans [EMAIL PROTECTED] writes: JV @parts = qw(sy $ foo bar 262); JV Now, create a file in the same directory with the same type, and name JV blech. Any idea? I don't like this but how about $resource = File::Generic "." $resource-name = "new name with all other parts left alone"; $fh = open $resource-asNativeFormat() Blech, but possible. chaim (Stolen parphrased but liberally from the Symbolics manual) -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes: Please explain why internally it needs to be represented as anything other than what the user passed in. JH A flat string is a pain to handle because then you have to know JH in which platform it was originally created: what semantics does JH it obey, how to parse it. I don't see how your proposal solves the problem. It still has to know what the source/intended/target platform is. Why do all those acts have to be performed to do an open? Hmm, unless you are planning to have a direct perl - os layer. (A rewrite/stealing^wborrowing from sfio?) chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 85 (v1) All perl generated errors should have a
I'm leaning to splitting identifier from the classification. A pure monotonically increasing integer would ensure the non-reuse. And the classification scheme could evolve seperately. Using numbers for the classification scheme would require a translation table. So why not just use alphanumerics. At a minimum I can see, the originator, the severity, and some class. I'm leaning to having the class tie in with lexical warnings. chaim "AS" == Ariel Scolnicov [EMAIL PROTECTED] writes: =item As a floating point number AS Since you're anyway not using a _floating_ point, here are 2 AS alternatives: AS 1. Error codes are integers, but with an implied decimal point (fixed ASpoint). E.g. 1234567 represents error 4567 in class 123. AS 2. Error codes as digit strings with decimal point. So "123.4567" AS(_not_ 123.4567) represents error 4567. People will still try ASstupid floating-point math tricks to get at the suberror code, but ASat least we'll know they didn't read the bit in the documentation ASwhere it will specifically warn _not_ to do this. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Data type and attribute syntax (was Re: RFC 89 (v1) Controllable Data Typing)
Someone on this list (TomC?) has supplied a major diatribe against const. chaim "JH" == Jeremy Howard [EMAIL PROTECTED] writes: JH Dan Sugalski wrote: The syntax is actually: my type $varname; This is in perl 5.6.0. Modifiers go as attributes after the colon: my Dog $spot : constant = new Dog; JH Yes. But what about types and attributes within complex types? JH - Constant refs vs refs to constants? JH - Types of hash (or 'pair') keys and elements? JH - Attributes (e.g. constantness) of hash keys and elements? JH - Ditto for arrays/lists... JH I left this out of v1 of the RFC because I wanted to get some feedback on JH syntax. If we can flesh this out I'll incorporate it into v2. JH Also, do we want to be able to specify types and attributes within a sub JH prototype? It would be nice to guarantee that subs don't mutate particular JH parameters, that certain data will not be aliased, etc, so that appropriate JH optimisations can be done. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 80 (v1): Exception objects and classes for builtins
"PC" == Piers Cawley [EMAIL PROTECTED] writes: PC The (continue|always|finally|whatever) clause will *always* be PC executed, even if one of the catch clauses does a die, so you can use PC this to roll back the database transaction or whatever else was going PC on and restore any invariants. Err, how does one differentiate between a 'good' entry and a 'bad' entry. PC Note too that we don't need to do any case based magic, we can and PC should use polymorphism for that. Why? Just because? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Data type and attribute syntax (was Re: RFC 89 (v1) Controllable Data Typing)
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS At 10:58 AM 8/11/00 -0400, Chaim Frenkel wrote:
Someone on this list (TomC?) has supplied a major diatribe against const.
DS Maybe, but I don't see what's wrong with:
DS my $foo :const = 12;
DS A nice, named, lexically scoped constant. The optimizer should be able to
DS make reasonably good use of that.
Err, I was addressing the issue of having
const this
this const
sub foo ($name :const)
etc.
A nice way of making a value read-only is lovely. And let it be a
runtime error to modify it.
The caller can easily do a foo eval{$const_item} to remove the
read-only attribute.
Hmm, perhaps we should rename the attribute
:read-only
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 80 (v1): Exception objects and classes for builtins
"PC" == Piers Cawley [EMAIL PROTECTED] writes: PC Good OO programming practice. Use polymorphism to replace switches. Then PC when you subclass one of your classes you don't have to go 'round PC rejigging the switch statements. I haven't used OO in anger. But for me polymorphism is action-at-distance of the worst stripe. Its the cheap and dirty way of doing OO. Let the object determine the calling convention for the method. I see very little reason to have two methods with different signatures. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 94 (v1) Rename @ARGV to @ARGS
This one is off-base. Too much history with @ARGV. I'll be constantly having a typo. This one is anti-"current community". chaim "PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes: PRL This and other RFCs are available on the web at PRL http://dev.perl.org/rfc/ PRL =head1 TITLE PRL Rename @ARGV to @ARGS PRL =head1 VERSION PRLMaintainer: Nathan Wiger [EMAIL PROTECTED] PRLDate: 11 Aug 2000 PRLVersion: 1 PRLStatus: Developing PRLMailing List: [EMAIL PROTECTED] PRLNumber: PRL 94 PRL Perl isn't C. Time to get over it. :-) -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 85 (v1) All perl generated errors should have a
"NW" == Nathan Wiger [EMAIL PROTECTED] writes: NW Also, how about just $@-id? Shorter and I would argue the "unique_" is NW really redundant (id's are usually unique, hence the name NW "identifiers"). Not really. Consider: Chaim is an identifier. But not unique. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 88 (v1) Structured Exception Handling Mechanism
See Graham Barr's previous email on this topic.
eval {}
else {}
continue {}
Very few new keywords, and rather than add something a complex mechainism
to the catch section, why not use Damian's switch internally. This
gives full flexibility to the user with little extra overhead.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 69 (v2) Standardize input record separator (for
I completely disagree. How do you know that I want 5 lines. Perhaps I want only 3? You are assuming that within my file I will want all possible line endings to be line endings. That is simply not true. You might want to argue for the perl IO subsystem to intuit the line ending (note the singular) in use and then handle it correctly. But there is no way that I want under, any circumstance, _all_ line endings active at the same time. chaim "PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes: PRL Given this input file (in UTF-8): PRL D O S CR LF0044 004F 0053 000D 000A PRL U n i x LF0055 006E 0069 0078 000A PRL M a c CR 004D 0061 0063 000D PRL l i n e LS006C 0069 006E 0065 2028 PRL p a r a PS0070 0061 0072 0061 2029 PRL This should work as expected on as many platforms as possible: PRL my @lines = FH; PRL The @lines array should contain five elements. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 73 (v1) All Perl core functions should return ob
Why push it through a user subroutine. Might as well make it part of the
core language.
Why add another keyword non_lazy. though it isn't an antonym, eval{}
has the right meaning and effect.
I can see the utility of having the callee specify the alacrity of the
parameter. But this would put quite a burden on the parser/runtime engine.
Package A and B both define a function foo. A-foo has non-lazy arguments
B-foo has lazy arguments. Then
$fooA = new A;
$fooB = new B;
$fooA-foo
$fooB-foo
What is a poor perl parser to do?
chaim
"DC" == Damian Conway [EMAIL PROTECTED] writes:
DC But, of course, lvalue subroutines give you the ability to impose the
DC choice externally as well. If you need to pass a lazy argument to a
DC normally non-lazy subroutine, you could just write:
DC sub enervate (?$) : lvalue { $_[0] }
DC And then:
DC non_lazy( a(), enervate(b()), c() );
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 80 (v1) Exception objects and classes for builti
(I'm not quite in favour. But assuming this flys...)
Why not use Damien's switch syntax. Much more powerful and the flow
is better controlled.
And why add another keyword. Just extend eval{} to accept two blocks.
eval {
}
catch {
}
finally {
}
With the catch block setting the lexical $@ to the exception.
Though, I'm sure that Larry will come up with a better synonym.
chaim
"JP" == John Porter [EMAIL PROTECTED] writes:
JP Peter Scott [EMAIL PROTECTED]:
try {
# fragile code
} catch Exception::IO with {
# handle IO exceptions
} catch Exception::Socket with {
# handle network exceptions
} otherwise {
# handle other exceptions
};
JP I'd like to recommend just "catch" instead of "otherwise",
JP because sometimes you'll do this:
JP try {
JP # fragile code
JP }
JP catch {
JP # handle other exceptions
JP };
JP And it would look silly to use "otherwise" there.
JP You could make it so "catch" takes a list of 0 or more exception
JP class names.
JP --
JP John Porter
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 80 (v1): Exception objects and classes for builtins
Nice.
The continue clause, I assume would re-raise an uncaught exception.
But, a big but. How does the 'else' clause indicate that the exception
was handled?
A couple of possiblities
1. Undef $@. But that's a bit of extra work in each leg.
2. switch is 'slightly' special in an eval/else block. If the case
selects the error, then it is considered handled unless a die or
redo is encountered.
3. If continue is not being used by Damian's switch, then a continue
continues onto the continue block, and marks the successful handling
of the exception.
chaim
"GB" == Graham Barr [EMAIL PROTECTED] writes:
GB I was more thinking of
GB eval {
GB # fragile code
GB }
GB else { # catch ALL exceptions
GB switch ($@) {
GB case __-isa('IO') { ... }
GB case __-isa('Socket') { ... }
GB else { ... }
GB }
GB }
GB continue {
GB# code always executed (ie finally)
GB }
GB And the only new keywords are for the switch statement.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
