next version of Perl, or that it can't be done
> better.
To extend that idea just a bit, it's been shown that you can write
object oriented systems in pure C, but you wouldn't want to do it!
Thus we have OO languages with innate OO-ness.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
y, I really don't see a need or use for this.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
ted.
This should probably go in its own RFC. Renaming local() is
orthogonal to creating all variables lexical bt default.
(I, for one, support renaming local() to Something Better (if only I
know what that was))
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
) of Time::Local. If we replace localtime() with
something saner, we'll have to find a sane inverse as well.
date2gmt() and gmt2date() any one?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
t
--
Jonathan Scott Duff
[EMAIL PROTECTED]
r even savetemp() or tempsave()
> >> or scopetemp().
>
> >How about deliver() or preserve()?
>
> I can slightly grok the latter, but not the former. What are you
> thinking there?
Ah, I was thinking of save() and how it could be deliverance.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
's what RFCs are for, no? :-)
> > That Perl should stay Perl
>
> Do we need an RFC for this? Seems like this is more of a "guiding
> concept" that should be intergrated into everything. Just my opinion.
Well, it can't hurt to have a document to look at every now and then
to remind us what Perl should look/feel like.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
object (I hate to use that term)
that's *always* false but has some state we can get at. This thing would
encapsulate $!, $?, and friends. Modules (like DBI) could even add state,
but it would still be false.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
r the shortened version, want()?
if(want eq 'hash') { return %hash }
elsif (want eq 'array') { return @{$hash{vector}} }
elsif (want eq 'scalar') { return $hash{vector]->[0] }
elsif (want eq 'handle') { return $hash{filehandle} }
/me patiently awaits a
) or die "$ERROR"; # assigned in Net::FTP
just brainstorming,
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
want = 'hash'; # tell the world I want a hash?
want = 'Foo'; # tell the world I want a Foo?
sub foo : want(Foo,hash,Dog), need(Foo) {
# foo() wants a Foo, hash, and Dog in that order
# foo() needs a Foo (must have)
}
okay, I've gone tangential ...
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
d horses.
BTW, I propose that RFCs have a Status: field as part of the VERSION.
Here are some possible values that I can see:
Status: accepted # we all agree that it should go in
Status: rejected # we all agree that it shouldn't go in
Status: tabled # shelved, put away for now
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
On Thu, Aug 03, 2000 at 02:13:20PM -0400, Michael Mathews wrote:
> Jonathan Scott Duff said
> > BTW, I propose that RFCs have a Status: field as part of the VERSION.
> > Here are some possible values that I can see:
> > Status: accepted # we all agree that it should go in
On Fri, Aug 04, 2000 at 01:37:09AM -0500, J. David Blackstone wrote:
> =head1 IMPLEMENTATION
>
> C
If I had my druthers, save() would be it.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Isn't this what source filters is all about?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
xecuted may have modified the switched variable, but we
want to continue evaluating the cases from this point rather than
starting again at the top of the switch.
> Long and bitter experience indicates that fallthrough is a poor default
> (but a good *option*).
Indeed.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
the
administrator of each site". I (and Johan) took that to mean "decided
when perl was compiled".
Letting administrators set a certain strictness level on *every*
program run sounds like we should make perl always read /etc/perlrc if
it exists.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
unds (scheme, lisp, Java, etc.) are surprised and
delighted when perl lowers the barrier to their entry and
understanding.
That said, if perl starts looking more like lisp than perl, I'll be
here to yell bloody murder! along with Simon :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
pelt "next" too? That would make sense to me,
but the semantics of "last odds" or "redo odds" escape me. Perhaps
"last odds" would me "evaluate the block labeled by odds, then exit
the switch" and "redo odds" would me "re-evaluate this case, then jump
to the block labelled odds".
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
(Although, we already have "0 but true" until someone
submits an RFC to remove it ;-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
e can use a language we
already know--Perl. We just need to make source filters part of the
language rather than a module (Perl 5 is already almost there).
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
On Sat, Aug 05, 2000 at 12:04:30PM +0200, Bart Lateur wrote:
> On Fri, 4 Aug 2000 10:54:16 -0500, Jonathan Scott Duff wrote:
>
> >> C
> >
> >If I had my druthers, save() would be it.
>
> I'm against it. Why? Because it suggests that all it does is save th
are
they used?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
TECTED]
>
> In the future, if you want to submit an RFC mail it to
> [EMAIL PROTECTED] only.
http://tmtowtdi.perl.org/rfc/meta/ says that you should send your RFCs to
[EMAIL PROTECTED] rather than [EMAIL PROTECTED]
Thanks for getting the RFC repository up an running Nat.
-Scott
--
hat's probably part of it's
problem.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
seful very often.)
Well perhaps that's what
$fh = open $fh;
does.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
ke they'd
slow it down.
> And since we already have one for $isdst, I figured it was useful.
> However, if there's a lot of counter-opinion, it can be removed.
The existence of $isdst doesn't make me want an $isutc; I'd prefer it
not be there.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
ime zone naming.
This makes an incredible amount of sense. We could even let the user
specify a coderef to a sub that implements their own particular
timezone oddities. (i.e. a sub to tell date() what the TZ offset is)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
nstruct and that got me thinking about python's
docstrings. It would be neat to have something similar in perl.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
ore.
Except that we still have positional and/or named parameters. I guess
_, _1, _2, _foo, _bar could still work though.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
On Mon, Aug 07, 2000 at 09:26:04AM -0700, Nathan Wiger wrote:
> As for the "need a verb" argument, my() and our() aren't verbs either.
They're also lexical rather than dynamic. Dynamic things need action
words (verbs) IMHO.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
> > sub *TIESCALAR { ... }
> > sub *FETCH { ... }
>
> Only half of those are subs.
What do you mean?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
ely in a different class,
> syntactically if nothing else.
Ah, but they *are* subs and you've stated my point exactly. They're
different beasts. They're special. Make them look special.
Radically special. :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Dog', give_me_an_animal();
print cast '*SCALAR', give_me_an_animal();
okay ... that's a bad example and I don't have any good ones.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
the subs it uses (that can be
determined at compile time))
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Any
> > objections?
>
> But what happens if you want multiple BEGIN blocks?
The same thing that happens now. As I understand it, perl compiles
and executes the BEGIN block then detroys it so that you may have as
many BEGIN blocks as you want and each time perl thinks it's the first
one.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
On Tue, Aug 08, 2000 at 09:27:24AM +0100, Piers Cawley wrote:
> > Proposal to utilize C<*> as the prefix to magic subroutines
>
> I freely accept that this is not anything approaching a reasoned
> critique but:
>
> Yecch!
That comment is as good as any :-)
-Sc
od to turn automatic addition of
newlines on and off. How about a new lexical pragma--newlines?
use newlines;
print "Hi"; # Automatically adds the newline
no newlines;
print "Hi"; # Does NOT automatically add the newline
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
omp() anyway if we make $/ per-filehandle because chomp()
acts on strings, not filehandles.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
thin the thread
of discussion following this RFC was proposed positional and/or named
currying with _1, _2, _3 and/or _foo, _bar, _baz.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
e chomp() go away and be replaced by
something like this:
$fh = open "foo" or die;
$fh->auto_chomp = 1;# Insert some appropriate syntax
$fh->newline = "\n";# Insert some appropriate syntax
while (<$fh>) {
nd returns the
what it removed? This could be useful if "end of line" varies while
reading from a single stream.
As an aside:
How do we get at the magic <> filehandle or its settings. Would we
usurp $ARGV to be the object and $ARGV->filename to do what $ARGV
currently does?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
OUT = $STDERR;
print "Oops!";
programmatically.
Of course we could define chomp() to have an optional first argument
that is the filehandle to do the chomping on too. These sorts of
decisions will have to be made on a per-subroutine basis rather than
having some global $/ that affects many different subroutines.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
andles which don't have private $/.
That word "global" bothers me. We can have default settings for
$STDIN, $STDOUT, $STDERR that vary as well as default settings on
filehandles opened by the user. But changing $/ shouldn't affect all
of them. $/ should go away.
MHO,
-Scot
per-filehandle thingy.
If the line it chomps isn't coming from a file, where does it come
from? (s/file/any form of IO/ because that's what we're really
talking about)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
hardcoded in %CONFIG or something like that. the global aspect was meant
> to show it was the default for ALL new handles. i don't care if it is in
> $/ or some new place.
Yes, yes, you are right ... I was suffering from perl 5 myopia.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
ome sort of explicit coercion anyway, but I
haven't thought this through obviously.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
On Tue, Aug 08, 2000 at 05:15:24PM -0400, John Porter wrote:
> Jonathan Scott Duff wrote:
> >
> > If we had a context coercion operator that was the opposite of want()
> > we could do something like this:
> >
> > print context '*STRING', $val
; looking for.
All of your programs may need translating anyway. They just might be
translated on-the-fly by perl6 and all you'd have to do is add a
command line switch or add "use Perl5;" or maybe absolutely nothing at
all.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
somehow provide an anonymous sub to date()
that will tell date() the proper offset from GMT for "localtime" if
we're going to support that concept at all.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
necessary to deep copy a CODE reference?
>
> It might not be necessary. I'm still learning how to write kosher Perl...
> elegance is a long way off for me.
Imagine storing your code along with your data in a database for use
later (persistent objects)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
ne.
Is it really a hierarchy? Must it be? Your strawman looks more like
an enumeration to me.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
written like this:
switch ($@->isa(^_)) {
case 'IO' { ... }
case 'Socket' { ... }
... # else code
}
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
ot.
utcdate() is fine with me as long as it really is UTC.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
d\n";
as calling the "toString" method for $id. We currently just don't
have a way to explicitly get at that method except by supplying the
proper context.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
well reuse those same names. If, however,
Perl's try/throw/catch/finally do something radically different (how,
I can't imagine) then we should be looking for new names.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
On Mon, Aug 14, 2000 at 01:46:55PM -0400, Lipscomb, Al wrote:
> While the implicit change works on most (if not all) situations it would be
> nice to have a way to control the conversion.
Sounds like an RFC to me :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
ill these other date-ish routines have
to be modified to understand mjdate() output?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
On Mon, Aug 14, 2000 at 02:42:39PM -0400, Dan Sugalski wrote:
> At 01:36 PM 8/14/00 -0500, Jonathan Scott Duff wrote:
> >On Mon, Aug 14, 2000 at 06:13:13PM -, Perl6 RFC Librarian wrote:
> > > =head1 TITLE
> > >
> > > Maintain internal time in Modified Juli
say yet.
As long as it Just Works from the language level, I don't care how
it's done :-)
my $i = 100_000_000_000_000_000;# big number!
$i += 100_000_000_000_000_000; # even bigger!
print "$i\n"; # Oh my
ather than using some weird
assignment operator to modify the attributes of a scalar (after all,
constancy is a property of the scalar), better the attributes should
be verbose and explicit.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
e could be done
> with thier punctuation defaults:
>
> cat /etc/passwd | perl '-$|=1' '-$\="\n"' -ne 'print((split/:/)[0])'
Ick.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
al time in another time zone?
You're right, there should be just one date/time routine. But it is
*extremely* difficult to incorporate time zones in a portable fashion.
They change at legislative whim. But if utcdate() (or whatever we
call it) had a way to specify an offset from UTC, that wou
omething ;-> How about we give
perl the ability to look for a .perlrc file? (Yes, I know the reasons
against, but everything is up for grabs now right? :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
On Tue, Aug 15, 2000 at 10:03:55AM -0700, Nathan Wiger wrote:
> Jonathan Scott Duff wrote:
> >
> > Well, now it's my turn to suggest something ;-> How about we give
> > perl the ability to look for a .perlrc file? (Yes, I know the reasons
> > against, but e
ists, interpolate it. If not, print it as
> it stands.
Isn't that the way perl4 did it? I don't know what agony lwall and
friends went through that made them change this behaviour though. It
would be good for someone who does to speak up about it.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
ever we call it) always; same with C. I'd hardly call that
"default" though.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
going to support backtracking like this, we'll
need to support the cut operator as well (! in prolog)
(Note the only prolog I've done was about 10 years ago for about 2 weeks
and about 2 years ago for 2 or 3 weeks in a programming languages class
at a university)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
On Tue, Aug 15, 2000 at 05:47:53PM -0600, Nathan Torkington wrote:
> I want
> @result = @a || @b;
> to be like:
> (@result = @a) or (@result = @b);
>
> That's what all my students keep expecting it to mean.
And that's what I keep wishing it meant too.
-Scott
--
I didn't see mentioned in the RFC.
It blocks backtracking so that something like this:
B1 andthen B2 andthen cut B3 andthen B4 andthen B5
wouldn't backtrack to B2 once it forwardtracked to B3.
Okay, the more I think about it, the more I think it should be a
module.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
implementation
detail. IF we implement our time values as 64-bit integers (for
instance), we'll long out-live the 2038 deadline.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
$_ "Here I come to save the day!\n" for ($PERL::STDOUT, $myfh);
And again, if you want to print different stuff to different
filehandles, you know how to use the
print FILEHANDLE LIST;
version of print.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
rl meets the rest of the world.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
t the point of this thread, but
@a = \($a, $b, $c);
is equivalent to
@a = (\$a, \$b, \$c);
rather than what you wrote.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
r than on accident. If lvalue subs are the default, then
they "accidently" work where maybe they shouldn't. Whether a sub
should be lvaluable should be a conscious decision made by the
subroutine author.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
oto B1 }
}
return "true"
As for examples where this would be of benefit ... I really can't think
of any.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
redefine what m//g means in a scalar context.
$_ = "foofoofoofoofoofoofoo";
$count = m/foo/g;
1 is just as true as 7.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
al language change if it were
adopted. There's just too much % history and those attributes become
*very* important rather quickly. But, if that's where we're headed
anyway, Perl 6 is a good time to make that decision.
still having reservations,
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
$evens] = $odds;
for ($i = 0; $i < scalar($list); $i+=2) {
$hash[list[$i]] = $list[$i+1];
}
Gee, I'd hate to lose simple assignment to a hash from a list.
What happens to $_ and @_? How do I get the arguments passed to a
sub?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
$LVALUE that contains the thing
being assigned. Are you saying that in
somesub = $value;
the subroutine C, being lvaluable by default is free to use
or ignore $LVALUE? If so, how does one detect errors? When
C is ignoring $LVALUE the above would silently fail, yes?
-Scott
--
Jonat
still a scalar. Where's the confusion?
I believe Mr. Porter is refuting the claim that "the punctuation is
part of the variable name". As both he and you have demonstrated,
it's not.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
On Wed, Aug 16, 2000 at 12:44:50PM -0400, John Porter wrote:
> Jonathan Scott Duff wrote:
> >
> > Gee, I'd hate to lose simple assignment to a hash from a list.
>
> foo %= bar;
>
> Hmm, I think I need to write an RFC!
I'll give you my comments righ
concrete examples that illustrate this point?
What would stop people from treating arrays and hashes differently if
the trivial notational differences are removed?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
number. To get a string, quotes
would be needed. As for $a[$something], if @a had been declared as
"my @a : assoc;", then perl should stringify $something, otherwise
numify. Hmm.. I guess this implies that all hashes need to be
pre-declared. :-(
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
t that import should
be spelled "IMPORT". The perl5 to perl6 translator would simply do
s/import/IMPORT/g (okay, not *simply*, but you get the drift)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
D can go away too! :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
programmer *wants* action-at-a-distance, Perl has never stood
in the way.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
ntion, but I don't see RFCs for. Am I missing them, or do they need
> to be written up?
RFC away!
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
ntext to possibly decide what to do with the
> argument.
Passing the lvalue via some other means eliminates this problem. I
forget who suggested it (Buddha Buck?) but
sub foo : lvalue($value) { ... }
where $value is a reference to the thing we're assigning seems like a
Good Idea to me.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Howdy, ", $person{$_[0]}, " ", $person{$_[1]};
}->('firstname', 'lastname');
# becomes
print "Howdy, ", $person{'firstname'}, " ", $person{'lastname'};
(If that's what people meant, I didn't see anyone actually say it).
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
ll Perl platforms
> on the UNIX epoch".
>
> Sound better?
Yep. Or more generally "Standardize Perl on all platforms to one
common time epoch" and reccommend the Unix epoch since it's so
widespread. :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
ount on it. But that won't be our fault as much as
Unix's :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
llions* of Jews for whom "0 AD"
is meaningless. s/Jews//
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
, the iterator would really be an each_alphabetic and #2 would really
be an each_crazy_order rather than a generic iterator. (Unless you really
want the iterator to compute the next in sequence on each iteration)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
ys, but using the ^ syntax
> would fail on this...
Good point. But who's to say that ^{total - female} doesn't work?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
x27;re that overloaded, farm out your ideas to
other willing souls who may be able to express them as you would in
the form of an RFC. Similar with the modules. It'd be a shame to
lose your (IMHO) valuable contributions to the Perl 6 effort.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
n a float and *bam* you've got <1 second precision as far
as your floats or doubles can carry you.
> But make the core language easily accessible to everyone.
Funny, that's the exact argument I would use *against* mjdate().
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
getting a warning whenever you execute
> such a stub.
Just to clarify, you're proposing that ellipsis do this in void
context only, right? I kind of like the existing ... operator just
the way it is (unless it has changed behind my back).
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Oops, just read this. Ignore my previoius email.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
eyable indices of
sparse array?
> Otherwise, work something like this:
>
> sub keys {
> my %hash = @_;
> return keys %hash;
> }
Ah, convert is argument to a hash then grab the keys of that hash.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
1 - 100 of 485 matches
Mail list logo
