Re: RFC 48 (v1) Replace localtime() and gmtime() with da

[Johan Vromans]

On Sun, Aug 06, 2000 at 01:10:23PM -0700, Nathan Wiger wrote:
> So you see why we need a persistent format() function. However, I think
> your real issue is a one-time call that just changes the format
> temporarily:
> 
>   print $date->strftime('%H:%M');  # print the time
>   print "$date";   # without touching this

Indeed.

> I'll put strftime() back in, I think that's probably the best thing for
> this.

strftime sounds like a real Unixism to me. 'set_format' and 'format' looks
more neutral and at least as effective.

-- Johan

Re: RFC: Rename local() operator

[Ariel Scolnicov]

Buddha Buck <[EMAIL PROTECTED]> writes:

> > > What about C ?
> > 
> > Here's yet another one - how about "here"?
> > 
> >{
> >   here $/ = "\n";   # what it is in here
> > 
> >}
> > 
> > Not really any confusion on this - $/ is "\n" 'in here', but maybe
> > something else outside.
> > 
> > Unlike "hide" or others, this doesn't connote it's necessarily any
> > different from somewhere else - just that it's this value inside the
> > current block (which is what we're after, I think).
> 
> But it isn't "here" that's the problem.  If we just wanted to change 
> the value "here", we could use my().  The problem is that local() 
> changes the value for somewhere else as well as here.  Other names 
> suggested (like "shadow", or "mask") convey that idea better than 
> "here".

It doesn't have the value "\n" I, it has the value "\n" I!

{
now $/ = "\n";

call_complicated_sub;   # Now $/ is still "\n"...
}
# Now it's back to what it was before


-- 
Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED]
Compugen Ltd.  |Tel: +972-2-6795059 (Jerusalem) \ We recycle all our Hz
72 Pinhas Rosen St.|Tel: +972-3-7658514 (Main office)`-
Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels

Re: Treating filehandles like strings

[Johan Vromans]

On Mon, Aug 07, 2000 at 12:16:22AM -0400, Michael Mathews wrote:
> Here's a thought. Wouldn't this be cool (see below)? The idea is that in 
> Perl 6 you should be able to read from a file handle one character or one
> line at a time (just like you can in Perl 5) BUT if you just go ahead and
> use the filehandle, directly, in a scalar context then perl will read it in
> as a string most efficiently, and allow you to perform your rgex, or
> whatever without creating a temporary variable just to hold the contents of
> that file.

Cute. This more or less the way SNOBOL handled I/O.
For input, this wouldn't be too hard: just overload the stringification
of the input object (we're going to have objects, yes?) with the
readline operation.
But for symmetry, you would want to do output as well, by just assigning
values to the file object. This seems harder to me.

I would settle for $fh->readline provided it would be at least as
efficient as <$fh>.

-- Johan

Re: Treating filehandles like strings

[Damian Conway]

...and as for matching regexen against streams, I have a more general
proposal for matching against subroutines that should allow for that
as a special case.

Damian

Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)

[Leon Brocard]

Damian Conway sent the following bits through the ether:

> Rather than continue to argue the details, why don't people post some
> examples of code where they feel these lazy lists might be useful, and
> let's see if there aren't already good alternatives.

It should be noted that "infinite" lazily-evaluated lists can be used
in Perl 5 in a perlish way with careful use of Tie::Array and
closures.

I've got an example of this in my poorly-coded Functional module[1],
which allows things like: 

  take(10, filter("prime", integers))

[yes, that is perl ;-] ... (which is done lazily)

Anything to make this easier to do in Perl 6 is welcomed ;-)

Leon

[1] http://www.astray.com/Functional/
-- 
Leon Brocard.http://www.astray.com/
yapc::Europe - September 22-24 London - http://yapc.org/Europe/

... Error 404: .signature generator ran out of tuits

Re: RFC 52 (v1) List context return from filesystem func

[Leon Brocard]

Perl6 RFC Librarian sent the following bits through the ether:

> affected files.  I suggest that in a list context, they return the I 
> of the I affected files.

This seems the wrong way around to me. Surely it should instead return
the name of the successfully affected files? Hm.

Leon
-- 
Leon Brocard.http://www.astray.com/
yapc::Europe - September 22-24 London - http://yapc.org/Europe/

... Error 404: .signature generator ran out of tuits

Re: Safer OO inheritance

[Jean-Louis Leroy]

Bart Lateur <[EMAIL PROTECTED]> writes:

> The problem is that you can't safely subclass a class, without examining
> it's source, just to make sure that your instance fields don't clash
> with any private fields of the mother class.

Well...let's think twice. What has the reputatin of being a bug or a
shortcoming in Perl is actually a feature in CLOS.

In the C++ View of the World you should be able to derive from a class
without examining the bases - especially the indirect bases. I thought
it made sense for years.

Until I realized that the 'miraculous reuse by accident' is a complete
lure. Which did a lot of harm to the reputation of OO. I now believe
that reuse is the consequence of ad-hoc design and cooperation between
the involved classes, that it has to be planned for and that it has a
cost - typically two or three times the cost of a non-reusable
design. Someone even said that the word 'reuse' made it look too
simple and suggested using the word 'polybloodyhardreuse' instead 

Thus, regardless of the issue about field inheritance, I believe that
"you can't safely subclass a class, without examining it's source" (or
its documentation, which should spell out the existence and purpose of
each field).

Also, consider what happens in presence of multiple inheritance,
particularly in the 'mixin' style. Typically you want to share a
single base sub-object even if a class is inherited more than once
(iow you want what C++ calls 'virtual inheritance'). Currently, in
Perl you get that by default. If you introduce scoped fields (by
default), you'll also have to introduce two kinds of inheritance:
shared and repeated.

I'm more in favor of a mechanism that makes it easy to build field
names from the package name, for those rare cases where you want
scoped fields. There were discussions about this a couple of years ago
on p5p. For example:

package Foo;

sub new
{
bless { "${CURRENT_PACKAGE}name" => 'Simpson' ...
}

...where $CURRENT_PACKAGE is a special variable automatically set
to...guess what? ;-)

-- 
Jean-Louis Leroy
http://users.skynet.be/jll

Re: RFC 50 (v1) BiDirectional Support in PERL

[Roman M . Parparov]

On Sun, Aug 06, 2000 at 09:36:12PM -0400, Ken Fox wrote:
> Perl6 RFC Librarian wrote:
> > BiDirectional Support in PERL
> 
> I know nothing about bi-directional output. It doesn't seem
> like Perl has any assumption of left-to-right at all. What's
> the difference between right-to-left support in Perl and just
> editing/using Perl in an xterm that does right-to-left?
> 
> - Ken

The main application of this is going to be CGI field, for the people
who fill and submit forms containing RTL language and expects to receive
the RTL output.

I wrote a WWW mail program with hebrew support once. Pain in the ass to
invent and reinvent functions for printing Hebrew correctly. Moreover, a
lot of self-written reversing and replacing reduces the performance from
what it would be if we just had it implemented in the core of Perl.

-- 
Roman M. Parparov - NASA EOSDIS project node at TAU technical manager.
Email: [EMAIL PROTECTED]   http://www.komkon.org/~romm
Phone/Fax: +972-(0)3-6405205 (work), +972-(0)54-629-884 (home)
--
The economy depends about as much on economists as the weather does on
weather forecasters.
-- Jean-Paul Kauffmann

Re: RFC 49 (v1) Objects should have builtin string SCALA

[Bart Lateur]

On Sun, 6 Aug 2000 18:28:29 -0800, Michael Fowler wrote:

>>print $pw;
>>print scalar $pw;
>  
>These resulting in a $pw->STRINGIFY or $pw->TO_STRING call is also
>confusing; neither are being used as strings.

Oh yes they are.

$^W = 1;
my $x;
print $x;

This complains of a "use of uninitialized value". When does this happen?
When the undef is converted to a string.

$y = 2*3;
print $y;

Does this print a number, or a string? It prints the result of the
calculation, a number, as a string. After this, the string value of $y,
"6", will even be cached as a string inside $y.

I could go on. Printing a list will convert every single list item into
a string.

This also clearly points out another reason why "turning into a scalar"
and "turning into a string", or into a list of strings, is not the same
thing.

-- 
Bart.

Re: RFC 22 (v1) Builtin switch statement

[Graham Barr]

On Sat, Aug 05, 2000 at 04:10:20AM +1000, Damian Conway wrote:
>> If a switch is considered like a loop then next would be the same
>> as 'break' in C, as would last and redo would repeat the switch.
> 
> But a switch is not a loop.

True, but in perl any block is considered to be a loop that
executes only once.

> Long and bitter experience indicates that fallthrough is a poor default
> (but a good *option*).

I guess it's what your used to.

Graham.

Re: RFC 48 (v1) Replace localtime() and gmtime() with da

[Bart Lateur]

On Sun, 06 Aug 2000 13:10:23 -0700, Nathan Wiger wrote:

>With the new date function you'll never need
>> to call
>> 
>>  sprintf("%02d/%02d/%04d", $tm[3], $tm[4]+1, $tm[5]+1900);
>>
>> since you can do
>> 
>>  date(undef,"%d/%m/%Y")
>
>True, but notice that you have to specify a format.

>> Also, why not space-pad the mday?
>
>Actually, given what I just said above - good point! This is actually a
>whole issue by itself. Here's the question: how should day/month/year
>look:
>
>   02/05/0982# 0-padded
>   2/5/982   # not 0-padded
>
>Geez, I can really see it both ways (although I probably prefer the
>former because it's easier to work with).

You can adapt some stuff from (s)printf:

  date(undef,"%02d/%02m/%Y")zero padded

  date(undef,"%2d/%2m/%Y")  space padded

  date(undef,"%d/%m/%Y")not padded


We should give an option of using 4 or 2 digit years. Or 3, for the
truely bizarre... ;-)


>   $backup_suffix = join '', ((date)[0..6]);
> 
>This is why I think 0-padding is invaluable. 

I like that. Only, zero padding should not be done if an explicit format
is given, as above.

-- 
Bart.

Re: Deep copy

[Piers Cawley]

Dan Sugalski <[EMAIL PROTECTED]> writes:

> At 05:31 AM 8/7/00 +1000, Damian Conway wrote:
> >> >Another one for my wish list: deep copying support built in.  A devil
> >> >inside me thinks this should be a new assignment
> >> >operator.  Damian?  Sounds like this is up your alley.  I want to do a
> >> >sanity check before taking up RFC space.
> >>
> >> Regardless of how this looks, it has some pretty significant 
> > ramifications
> >> for the internals. What, for example, should happen if you deep-copy 
> > a DBI
> >> object attached to an Oracle database?
> >
> >I would say that encountering an "external component" such as a file handle
> >during a clone() should either shalow copy the component or else throw an
> >exception.
> 
> That's cool. I can also see calling a package's CLONE sub if you're cloning 
> something blessed into it. Presumably it'd get the original as a parameter 
> and return the new thing, or something of the sort.

With a UNIVERSAL::CLONE that does the Right Thing for a 'typical'
object representation. (eg: blessed hash currently, but possibly
something more efficient in Perl 6)

-- 
Piers

Re: Deep copy

[Mark-Jason Dominus]

Lisp, which you might expect would have a 'deep copy' operator,
doesn't have one.  The Lisp folks have apparently thought about this
very carefully, and decided that the semantics are unclear, and that
the obvious options are all wrong; I've read a number of articles
about this in the past.  

I don't remember all the details, unfortunately.  But I think it's
worth paying attention to prior art where there is some.  This article

http://world.std.com/~pitman/PS/EQUAL.html

discusses this in some detail.  I haven't thought about this in the
context of Perl yet, so I'm not sure if all the reasons apply.   Also
if you do a Deja search in comp.lang.lisp for the phrase "deep copy",
you'll find an extensive discussion of why it doesn't make sense, at
least in Lisp.

I'll also note the the same problems comes up when comparing for
equality; if you want a deep copy operator, you should also want a
deep compare oprator.  But Lisp has not one but *five* equality
comparison operators, and part of the proliferation is for the reason
that the 'deepness' of the desired comparison varies from application
to application.  Perl has two equality comparison operators and people
aready complain that that is too many.

Mark-Jason Dominus   [EMAIL PROTECTED]
I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for details.

AGAINST RFC 48 (v1) Replace localtime() and gmtime() with da

[John Tobey]

On Mon, Aug 07, 2000 at 01:44:28AM -0500, Jonathan Scott Duff wrote:
> On Sun, Aug 06, 2000 at 11:07:02AM -0700, Russ Allbery wrote:
> > Basically, you don't want to go anywhere near this mess; it eats people.
> 
> I agree.
> 
> > I see two reasonable options to go with instead.  One is to just use a
> > binary flag that says use UTC or not; this is the simplest and most
> > reliable to explain.  The other is to allow a timezone offset; this
> > doesn't deal with daylight savings time and historic time zone changes,
> > but it provides enough power for most of what people want to do and if you
> > want to deal with the rest you have to deal with time zone naming.

I agree completely with Russ, and I would further state that I don't
want this C feature in the core.  Dates, times, timezones, leap
seconds, month and day names, localized formats, etc., are too
complex.  No one here has thought out the complexity enough to say
"this is what Perl will support from now on".

Currently, there isn't even an adequate (in my opinion) module on CPAN
that gives dates a proper abstract interface.  Time::Object may be
okay as a lightweight localtime/strftime interface, but it does not
support date, as opposed to time/date, arithmetic, or rather, it
mis-supports it.

Since we really don't understand dates here, I don't want us commiting
to a certain interface without a `use' directive in the program.
Distribute Time::Object as a standard module, but keep it a module,
and don't force its quirks on people.  Certainly, don't force the
complex, quirky, and untested interface being developed here now on
anyone without a long, patient discussion period.

> 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)

Gross.  Put it in a module.

-John

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

[Bart Lateur]

On Sun, 06 Aug 2000 17:35:17 -0700, Nathan Wiger wrote:

>I
>think the concept's great, just that the notation is really hard to
>read, and doesn't necessarily scream "function" to me (especially since
>_ is from stat already).

I don't see why you can't simply use _. From the context, you clearly
see that it's not a filehandle. And if all filehandles will have a '$'
prefix anyway, the filehandle _ won't even exist any more.

-- 
Bart.

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

[Bart Lateur]

On Sun, 06 Aug 2000 21:54:47 -0700, Nathan Wiger wrote:

>Seems to me that a leading _ is worse for this than ^

Whatever prefix you choose, it should NEVER EVER be a \w character.

And the general rule, until now at least, is that only characters from
the ASCII repertoire are acceptable for progamming language syntax. (I
merely have reservations WRT variable names, using accented characters
or something.)

-- 
Bart.

Re: Recording what we decided *not* to do, and why

[John Porter]

Glenn Linderman wrote:
> 
> When using an inline comment, I want to spend my character budget mostly
> on the comment, and just enough on the delimiters to see it
> effectively.  #< magic here ># would do quite nicely
> 
> When reading a script, I'd like to be able to quickly distinguish the
> comments using my eyeballs and brain, without the need to involve my
> fingers and editor 

Bogus arguments both, at least wrt #<...># vs qc<...>.
Same number of characters overhead, same LACK of obviosity to the eyeball.  

-- 
John Porter

Re: RFC 15 (v1) Stronger typing through tie.

[John Porter]

Nick Ing-Simmons wrote:
> John Porter <[EMAIL PROTECTED]> writes:
> >> my integer $quux = 4;
> >
> >I believe that would have to be 
> >
> > integer my $quux = 4;
> >
> >at least in perl5...
> 
> Well Larry has been using 
> 
>   my Dog $spot;
> 
> for a while.

O.k., I see that now;  I was thinking 'integer', in this case,
would be syntactically analogous to 'tie'.

-- 
John Porter

Re: RFC: Rename local() operator

[John Porter]

Buddha Buck wrote:
> 
> But it isn't "here" that's the problem.  If we just wanted to change 
> the value "here", we could use my().  The problem is that local() 
> changes the value for somewhere else as well as here.  

Well, as has been pointed out, special^Wlocalized variables are
scoped in time, not space, so:

now $/ = "\n";


-- 
John Porter

Re: RFC 48 (v1) Replace localtime() and gmtime() with da

[Andy Dougherty]

On Mon, 7 Aug 2000, Johan Vromans wrote:

> strftime sounds like a real Unixism to me. 'set_format' and 'format' looks
> more neutral and at least as effective.

strftime is and will likely continue to be available through the POSIX
module (or its successor).  I see no point in re-inventing strftime
(perhaps well, perhaps badly) as a perl language core element. 

I certainly see great benefit in including a nice date/time module, but
that's a topic for [EMAIL PROTECTED], not this list.

-- 
Andy Dougherty  [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042

Re: RFC: Rename local() operator

[John Porter]

Nick Ing-Simmons wrote:
> 
> > In PostScript, [gsave] allows you to save the current state of
> > the graphics output device, on a stack, but it doesn't modify it. 
> 
> Neither does local - it is the = "\n" that does the modifying.

Oh, not really. Because you get modification *regardless* of 
whether you assign something or not.

-- 
John Porter

MLC has its own sublist: WAS: Re: Recording what we decided *not* to do, and why

[Michael Mathews]

Please post further MLC remarks to the MLC sublist:
[EMAIL PROTECTED]

I can't guarentee that any MLC comments posted under a different subject,
and on a different list will make it into the final Multiline Comments  RFC!
Not to mention that this specific argument is already addressed in the
current RFC posted there.

--Michael

John Porter said:
> Glenn Linderman wrote:
> > When using an inline comment, I want to spend my character budget mostly
> > on the comment, and just enough on the delimiters to see it
> > effectively.  #< magic here ># would do quite nicely
> >
> > When reading a script, I'd like to be able to quickly distinguish the
> > comments using my eyeballs and brain, without the need to involve my
> > fingers and editor
>
> Bogus arguments both, at least wrt #<...># vs qc<...>.
> Same number of characters overhead, same LACK of obviosity to the eyeball.

Re: RFC: Filehandle type-defining punctuation

[Ted Ashton]

Thus it was written in the epistle of Bart Lateur,
> On Fri, 4 Aug 2000 10:03:28 -0400, Ted Ashton wrote:
> 
> >If we've decided that chomp isn't going to return the clippings, would it not
> >seem prudent to make
> >  while (chomp()) 
> >
> >work like
> >  while ()
> 
> You mean, like, the -l command line switch? (see perlrun)
> 
> chomp() on input, append newlines on print (though $\).

Related, I suppose.  Currently 'while ()' means 'while ($_ = )'.
I propose making 'while (chomp())' mean 
  while () {
 chomp;
 . . .
  ]

Ted
-- 
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
  ==   
For a physicist mathematics is not just a tool by means of which phenomena
can be calculated, it is the main source of concepts and principles by means
of which new theories can be created.
-- Dyson, Freeman
  ==   
 Deep thoughts to be found at http://www.southern.edu/~ashted

Re: RFC 48 (v1) Replace localtime() and gmtime() with da

[Jarkko Hietaniemi]

> Whatever you do, don't use those timezone names.  Is EST Eastern US time
> or Eastern Standard Time in Australia?  The same abbreviation is used in
> both places.
> 
> Naming of time zones is a *huge* rathole that you probably just don't want
> to crawl into.  The short abbreviations are *not* standardized and are
> quite frequently ambiguous.  There are three other prevelant time-zone
> naming schemes:  the POSIX one (EST5EDT, for example) is completely
> insufficient to actually represent time zone variations as they occur in
> the real world, the "old Olson" found in most Unix operating systems these
> days with names like US/Pacific doesn't offer enough granularity, and the
> "new Olson" method (the best of the lot) uses names that most people don't
> know (America/Los_Angeles for US Pacific for example).
> 
> Basically, you don't want to go anywhere near this mess; it eats people.

Heartily agreed.  Having just parsed through several hundreds of
megabytes of mailing list archives and having reported to Graham on
which various date formats Date::Parse chokes on or returns zero from,
I can say with some certainty that one should stay away from timezone
names if at all possible.  There are many unambiguous/nonstandard/unknown
timezone names out there.

> I see two reasonable options to go with instead.  One is to just use a
> binary flag that says use UTC or not; this is the simplest and most
> reliable to explain.  The other is to allow a timezone offset; this
> doesn't deal with daylight savings time and historic time zone changes,
> but it provides enough power for most of what people want to do and if you
> want to deal with the rest you have to deal with time zone naming.
> 
> -- 
> Russ Allbery ([EMAIL PROTECTED]) 

-- 
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

[Jonathan Scott Duff]

On Mon, Aug 07, 2000 at 02:53:17PM +0200, Bart Lateur wrote:
> On Sun, 06 Aug 2000 17:35:17 -0700, Nathan Wiger wrote:
> 
> >I
> >think the concept's great, just that the notation is really hard to
> >read, and doesn't necessarily scream "function" to me (especially since
> >_ is from stat already).
> 
> I don't see why you can't simply use _. From the context, you clearly
> see that it's not a filehandle. And if all filehandles will have a '$'
> prefix anyway, the filehandle _ won't even exist any more.

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]

Re: RFC: Rename local() operator

[Bart Lateur]

>The C operator of Perl5 and earlier does not do what it claims
>to and should be renamed.

How about:

override

meaning: ignore the value you've seen so far, for now, you'll use my
value.

I can't say that any of the proposed new names actually "clicks". But
"hide" and "save" are to much involved with how this feature is
implemented, and not with what's its purpose. "shadow" or "mask" come
closer, but to me, these ring too many bells of other applications
("shadow blocks" in FORTH, wich is documentation associated with code,
or cache, as in "shadow RAM"; and bitmasks, respectively).

I definitely do not agree that the word should be a verb. Why not?
Because it's supposed to describe a situation: a variable's temporal
scope; and not an action, stuffing variable values under the carpet.
"local" works nicely as a word, apart from the implied meaning of
spatial scope. But the same kind of word would be nice.

-- 
Bart.

Re: RFC 23 (v1) Higher order functions

[John Porter]

Ken Fox wrote:
> 
> I think we need a curry context and that all curries must be surrounded
> by parens. 
> .
>   sub traverse ($_);
>   my $sum = 0;
>   $root->traverse(($sum += __));

I think parens may be problematic, since nested lists flatten.
Maybe curlies could be overloaded yet again?

$root->traverse({$sum += __});

That has mnemonic value, since it looks kinda like an anonymous sub...

-- 
John Porter

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

[John Porter]

Jeremy Howard wrote:
> Yes, I change my mind . I like the '^' prefix
> too. The difficulty of reading __ would be a pain.

But what happens here?

/^__foo/

Or here?

/^{__}foo/

Is the latter sufficiently unambiguous?

-- 
John Porter

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

[John Porter]

Nathan Wiger wrote:
> 
> Yeah, I personally can read this much clearer. Peter also mentions that
> __ is hard to distinguish from _, unless they're right next to each
> other, and I think this is a very valid point.

This biggest problem with '__', imho, is that '_' is a valid identifier
character.  '__' is already a valid package name, or sub name, for examples.

-- 
John Porter

Re: Different higher-order func notation? (was Re: RFC 23 (v1) Higher order functions)

[John Porter]

Has anyone suggested '*'?  Since its use for typeglobs is (repsumably)
going away, it's available (right?).

It the "wildcard" mnemonic value is consistent with "placeholder".

-- 
John Porter

Re: Infinite lists (was Re: RFC 24 (v1) Semi-finite (lazy) lists)

[John Porter]

Jeremy Howard wrote:
> Yes, they're not identical. What I mean of course is:
>   (..-1) == reverse(map -__ (1..));

WHAT?  So the semantics of .. are magically different in the context
of (..$n) so as to produce numbers in descending order?

I don't think so.

-- 
John Porter

Re: RFC 53 (v10) Built-ins: Merge and generalize C

[Piers Cawley]

Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> =head1 DESCRIPTION
> 
> At present C only returns the index of the first occurrence of a
> specified substring. It is proposed that C take a fourth parameter
> telling it which occurrence of a specified substring to locate:
> 
> $first = index $string, $substring, 0, 1; # first occurrence
> $first = index $string, $substring, 0, 2; # second occurrence
> $first = index $string, $substring, 0, 3; # third occurrence
> 
> If omitted, this fourth parameter would default to 1, thus preversing
> the current behaviour.
> 
> The C function would be unnecessary, being replaced by:
> 
> $last = index $string, $substring, -1, -1;# last occurence

Err... shouldn't that be 

$last  = index $string, $substring, 0, -1  # last occurrence
$first = index $string, $substring, -1, -1 # first occurrence found
   # in a perverse way

Or am I seeing double negatives where I shouldn't?

-- 
Piers

Re: RFC 44 (v1) Bring Documentation Closer To Whatever I

[John Porter]

> Consider this (upcoming) Perl6 code:
> 
> sub foo {
>   "Snarf the frobnitzers if x > 0.1";
>   my $x = shift;
>   # ...
> }

Have you guys totally missed the discussions on multi-line comments?

I argued for qc//, as in

  sub foo {
qc(Snarf the frobnitzers if x > 0.1);
my $x = shift;
# ...
  }

Please check out RFC 5 and its discussions in the archive.

-- 
John Porter

Re: RFC17

[Dan Sugalski]

At 10:55 PM 8/6/00 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > But, if we toss refcounts, and split GC cleanup and
> > end of scope actions anyway, we need to have a mechanism to hoist things
> > out of the current scope.
>
>Why say hoist when we can say return? I can think of several ways of
>returning values that don't require the caller to allocate a binding for
>the return value. Variants of the existing perl 5 stack push would work
>fine. We could also use a special "register" variable that return values
>are shoved into.

I'm not proposing any perl-level syntax. I'm just saying that, if we toss 
refcount gc we'll need an alternate method of handling end-of-scope 
cleanup, one that allows us to inject things into an outer level of scope 
somehow. I don't much care if we make that visible in any sort of generic 
way to perl code. That's not my decision.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Different points of view, a little perspective.

[Michael Mathews]

John Porter said:
> that long post contained nothing that anyone
> reading perl6-language isn't already
> fully conscious of.  At least, IMHO.

I admit I took artistic license with my point. I should have expected
programers to prefer short, logical statements (preferably ending with
semicolons).

Try again...

Much discussion here (even still) is about how to make Perl easier for
others to learn and use, witness change "unlink" to "remove" discussion,
among others. Turns-out that *is* a valid point. Most people who use Python
(a language that considers itself an alternative to Perl) would agree too.
You could say they wanted Python and they knew where to find it. Should we
care?

In the MLC discussion I have read many comments about how various "C-style"
features would be easier for people to learn, remember, and use. In fact the
MLC discussion itself was inspired by a desire to make Perl more C-like
(actually Java-like) in how it handles comments. Is this a worthwhile
argument, even on its own?

Should we care if more people are using Python, TCL, or ASP this month? Is
this a popularity contest? Many here (it seems) will say that Perl is great
already, lets worship it. But in my opinion being popular *should* be a goal
of Perl. Afterall, would I use Perl if I couldn't find a job that required
it, or a book written about it, or a website explaining it, or a module
available for it? Honestly, no -- I don't have enough time to waste. Once
that happens a language is as good as dead, and no further discussion is
necessary. That leaves the question however: How far are we willing to (or
should we) go, "just to be popular"? Are we already there?

I do realize this has already been touched upon here, though I don't think
it was resolved, and I was just trying to approach it in a novel way. Its a
shadow that rightfully should hang over every discussion here.

Re: Different points of view, a little perspective.

[Dan Sugalski]

At 11:40 AM 8/7/00 -0400, Michael Mathews wrote:
>In the MLC discussion I have read many comments about how various "C-style"
>features would be easier for people to learn, remember, and use. In fact the
>MLC discussion itself was inspired by a desire to make Perl more C-like
>(actually Java-like) in how it handles comments. Is this a worthwhile
>argument, even on its own?

Perl is one of the very few languages geared towards a conceptual model 
which is essentially people. Pretty much all the other languages I can 
think of target a conceptual model where a person isn't central. That's 
something I don't think perl should lose. Becoming more C-like (or 
Lisp-like, or APL-like, or Prolog-like, or...) is moving in the wrong 
direction. Snagging things they do, sure. Just not the way they do it, 
unless that way maps well to the way that normal human beings (and let's 
face it, that does *not* target your average programmer dead-on) think of 
things.

Human brains work very differently from computer brains. At this point we 
no longer need to cater to the computer--we have the power and the 
technology to make people the central focus and still perform well.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 55 (v1) Compilation: Remove requirement for fina

[John Porter]

> Compilation: Remove requirement for final true value in require'd and do'ed files

Do not.  I use this feature.

-- 
John Porter

RE: Deep copy

[Garrett Goebel]

$want_deep_copy++; 
$want_deep_equal++;

From: Mark-Jason Dominus [mailto:[EMAIL PROTECTED]]
> 
> Lisp, which you might expect would have a 'deep copy' operator,
> doesn't have one.  The Lisp folks have apparently thought about this
> very carefully, and decided that the semantics are unclear, and that
> the obvious options are all wrong; I've read a number of articles
> about this in the past.  

I should start by stating that I'm ignorant of Perl's internals, and a great
deal of other knowledge that most people on this list take for granted. So
if I sound stupid, please give me the benefit of the doubt, and assume it is
ignorance to be cured (until I prove otherwise).

Correct me where I'm wrong. There's got to be lots of material to work with
here ;)

Assumptions: 
- Larry wants to cultivate ideas from C#
  > C# has very few types... word4, word8, etc. and float4, float8, etc.
  > C# more or less infers the type from what is pushed on the stack.
- People in the Perl community are requesting the ability to add new
  types for mathematical or other reasons. 

Wouldn't discussion of deep copying be tied to whatever is determined to be
the best course for handling extensible types and data structures?

I get a little confused when trying to distinguish the type of data from the
structure of data in Perl. My assumed truth: Perl's "types" are hidden away
in scalars and automagically managed and taken for granted by Perl
programmers like myself. Scalars are both the data and a singular structure
for holding a unit of data. Arrays and hashes are data structures for
holding scalars.

Shouldn't the scalar be able to copy and perform casts and comparisons
between different types of data under the scalar hood?

'a' != 'b'
'A' == 65;

And shouldn't the data structures be responsible iterating through the
scalars to perform shallow and deep copies and comparisons. -Where the
difference is whether or not to look at the reference or what the reference
points to. Is ignorance letting me see clarity where it is really dark,
complex, and murky? Data types handle copy and comparison operators. Data
structures handle navigating themselves both shallow and deep.

Why are things like objects, code, file handles, etc not scalars? Shouldn't
every fundamental data type be hidden away behind the benevolent scalar?
Then if someone decides to add a new type, it is their responsibility to
define their copy and comparison operators right.

> Perl has two equality comparison operators and people already
> complain that that is too many.

Yes, but when you need to do a deep copy, and you aren't a Perl guru... you
really start to wish someone would provide one for you. --I've got a half
functional deep copy subroutine that does most of what I need it to do, but
it's not elegant... I'd rather see a more elegant solution and a couple more
obscure operators so that working with deeply nested data structures would
be easier.

Garrett

Re: RFC 55 (v1) Compilation: Remove requirement for fina

[Nathan Torkington]

John Porter writes:
>> Compilation: Remove requirement for final true value in require'd and
>> do'ed files
> 
> Do not.  I use this feature.

Is there any reason you couldn't use "die" instead?

Nat

Re: RFC: Rename local() operator

[Nathan Wiger]

> > But it isn't "here" that's the problem.  If we just wanted to change
> > the value "here", we could use my().  The problem is that local()
> > changes the value for somewhere else as well as here.
> 
> Well, as has been pointed out, special^Wlocalized variables are
> scoped in time, not space, so:
> 
> now $/ = "\n";

Personally, I like this alot, actually. It emphasizes what's going on
really well. And it's short!

As for the "need a verb" argument, my() and our() aren't verbs either.

-Nate

P.S. We really should get a list for this!

Re: RFC 37 (v1) Positional Return Lists Considered Harmf

[Chaim Frenkel]

Fixed hashes, such as the return from stat() can be handled in the
compiler. (Ala perl5's pseudo hash.)

This could possibly be combined with the proposed direct pack/unpack
handling of structures. So that the stat buffer would be transformed
into a hash refering to a structure buffer. 

$stat{ino} could directly access the structure.
$stat{$field} would go via the hash interface.




> "SS" == Steve Simmons <[EMAIL PROTECTED]> writes:

>> =head1 IMPLEMENTATION

SS> I strongly support Damiens suggestion on a hashref, and would go so
SS> far as to say it should be a pseudo-hash, with all the attendant
SS> misspelling protections and speed obtained.

SS> Passing lists around can be expensive, manipulating hashes can be
SS> expensive.  I'd extend Damiens suggestion to allow the programmer
SS> to specify only the sub-data desired, eg:

SS> # undef context, store results in passed hashref

SS> my %data_wanted = \(mode => 0, nlink => 0);
SS> stat( $filename,\$data_wanted);

SS> This could even be done in a list context, with a possible
SS> implementation suggested:

SS> # List context, return only the two values requested in order

SS> ($mode,$nlink) = stat($filename,\('mode','nlink'));


-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183

Re: RFC: Rename local() operator

[Piers Cawley]

Nathan Wiger <[EMAIL PROTECTED]> writes:

> > > But it isn't "here" that's the problem.  If we just wanted to change
> > > the value "here", we could use my().  The problem is that local()
> > > changes the value for somewhere else as well as here.
> > 
> > Well, as has been pointed out, special^Wlocalized variables are
> > scoped in time, not space, so:
> > 
> > now $/ = "\n";
> 
> Personally, I like this alot, actually. It emphasizes what's going on
> really well. And it's short!
> 
> As for the "need a verb" argument, my() and our() aren't verbs either.

$/ = "\n" now;

feels more English somehow. Would almost certainly be a bugger for
perl to parse though.

As for the 'need a verb' argument, it doesn't apply here because the
assignment is the verb.

-- 
Piers

Re: RFC 55 (v1) Compilation: Remove requirement for fina

[John Porter]

Nathan Torkington wrote:
> John Porter writes:
> >> Compilation: Remove requirement for final true value in require'd and
> >> do'ed files
> > 
> > Do not.  I use this feature.
> 
> Is there any reason you couldn't use "die" instead?

???

Throw an exception in order to return a (0|'')-but-true value?

-- 
John Porter

Re: Treating filehandles like strings

[Peter Scott]

Just a quick tangential comment: it should be possible to specify the 
maximum number of characters that a readline() will do on a filehandle.  I 
couldn't find this in IO::Handle which seems to be where the user-defined 
line disciplines are inheriting their methods?  Anyway, obvious application 
is to harden scripts against DoS attacks with endless inputs filling up the 
memory buffers while still allowing programmer to use <>.
--
Peter Scott
Pacific Systems Design Technologies

Re: RFC: Rename local() operator

[Bart Lateur]

On 07 Aug 2000 17:26:14 +0100, Piers Cawley wrote:

>$/ = "\n" now;

$/ = "\n" for now;

Very English-like.

OTOH, now() sounds like a synonym for the built-in time().

-- 
Bart.

Re: RFC 55 (v1) Compilation: Remove requirement for fina

[Nathan Torkington]

John Porter writes:
> > >> Compilation: Remove requirement for final true value in require'd and
> > >> do'ed files
> ???
> Throw an exception in order to return a (0|'')-but-true value?

If you want to indicate that there was an error in the code, why not
die()?  What am I missing?

Nat

Re: RFC 53 (v10) Built-ins: Merge and generalize C

[Chaim Frenkel]

I don't see the point. What makes you want to do this?

And if you are changing it, why not make it return the list of matches
in a list context?

$last = (index $string, $substring)[-1]

(These type of translations/idioms might be candidates for optimization.)



> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:

PRL> =head1 ABSTRACT

PRL> This RFC proposes that the C and C functions be merged
PRL> and generalized, by adding a fourth parameter to C.

PRL> =head1 DESCRIPTION

PRL> At present C only returns the index of the first occurrence of a
PRL> specified substring. It is proposed that C take a fourth parameter
PRL> telling it which occurrence of a specified substring to locate:

PRL> $first = index $string, $substring, 0, 1;  # first occurrence
PRL> $first = index $string, $substring, 0, 2;  # second occurrence
PRL> $first = index $string, $substring, 0, 3;  # third occurrence

PRL> If omitted, this fourth parameter would default to 1, thus preversing
PRL> the current behaviour.

PRL> The C function would be unnecessary, being replaced by:

PRL> $last = index $string, $substring, -1, -1; # last occurence

-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183

RE: Deep copy

[Dan Sugalski]

There are a wide range of tricky problems associated with deep copy and 
deep compare. I like the idea, but circular references can make this 
problematic even without external things (filehandles, dirhandles, objects 
from non-perl sources) are thrown in. That needs to be taken into account 
when putting together the RFC for it, if someone even does.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 54 (v1) Operators: Polymorphic comparisons

[Chaim Frenkel]

This seems to be adding a special case. (I.e. only if _both_ are
non-numeric will it switch to a cmp operation.)

I currently fail to switch to 'eq' many times when I should, but the
failure mode is obvious. Her the failure mode will be really strange.

(And how does one tell if the string is numeric or not?

eg. "35abc" == "n37c"

)

Would modifying the waya number is converted to string be more
satisfactory? I generally look at the 'cmp' amily as doing a lexical
ordering. While the '<=>' as doing a numerical ordering. 

So I'm not sure that your generic insertion is generic enough. One still
has to decide on the ordering.

Enlighten me O' prolific one.



> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:

PRL> =head1 ABSTRACT

PRL> This RFC proposes that numeric comparison operators default to stringwise
PRL> comparison when both arguments are non-numeric strings.

PRL> =head1 DESCRIPTION

PRL> Currently the expression:

PRL>"cat" == "dog"

PRL> returns true. 

PRL> It is proposed that if I argument of a numeric comparison
PRL> operator can be converted to a number, rather than both being converted
PRL> to zero, the two operands should be compared using the equivalent
PRL> stringwise comparison operator.

-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183

Re: RFC 55 (v1) Compilation: Remove requirement for fina

[Piers Cawley]

Nathan Torkington <[EMAIL PROTECTED]> writes:

> John Porter writes:
> >> Compilation: Remove requirement for final true value in require'd and
> >> do'ed files
> > 
> > Do not.  I use this feature.
> 
> Is there any reason you couldn't use "die" instead?

Is there any reason that both couldn't be used at the same time?

-- 
Piers

Re: RFC 56 (v1) Optional 2nd argument to pop() and shift

[Chaim Frenkel]

PRL>3) C would then act as C and C would
PRL>   act as C

I'll take door #3, Jonathan.


-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183

Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t

[Peter Scott]

At 04:43 PM 8/7/00 +, Perl6 RFC Librarian wrote:
> sub *BEGIN  { ... }
> sub *END{ ... }
> sub *INIT   { ... }
> sub *AUTOLOAD   { ... }
> sub *TIESCALAR  { ... }
> sub *FETCH  { ... }

Only half of those are subs.

--
Peter Scott
Pacific Systems Design Technologies

RE: Deep copy

[Peter Scott]

At 12:53 PM 8/7/00 -0400, Dan Sugalski wrote:
>There are a wide range of tricky problems associated with deep copy and 
>deep compare. I like the idea, but circular references can make this 
>problematic even without external things (filehandles, dirhandles, objects 
>from non-perl sources) are thrown in. That needs to be taken into account 
>when putting together the RFC for it, if someone even does.

I don't want it to go undocumented; I can write an RFC since I started the 
thread, or Damian can write it since he brought up clone() before that.  I 
defer to Damian.

I don't think it's impossible to do something useful, if we think 
sufficiently Perlish.

--
Peter Scott
Pacific Systems Design Technologies

Re: RFC 54 (v1) Operators: Polymorphic comparisons

[Peter Scott]

At 02:27 PM 8/7/00 +, you wrote:
>This RFC proposes that numeric comparison operators default to stringwise
>comparison when both arguments are non-numeric strings.

What happens when one is a string that can't be numerified and the other is 
a number?  Why don't you convert the number to a string and do a stringwise 
eq in this case?

--
Peter Scott
Pacific Systems Design Technologies

RE: Deep copy

[Dan Sugalski]

At 10:07 AM 8/7/00 -0700, Peter Scott wrote:
>At 12:53 PM 8/7/00 -0400, Dan Sugalski wrote:
>>There are a wide range of tricky problems associated with deep copy and 
>>deep compare. I like the idea, but circular references can make this 
>>problematic even without external things (filehandles, dirhandles, 
>>objects from non-perl sources) are thrown in. That needs to be taken into 
>>account when putting together the RFC for it, if someone even does.
>
>I don't want it to go undocumented; I can write an RFC since I started the 
>thread, or Damian can write it since he brought up clone() before that.  I 
>defer to Damian.
>
>I don't think it's impossible to do something useful, if we think 
>sufficiently Perlish.

That's fine. I'm not against it (I like it), I just want to know what needs 
to be done under the hood, and we need to document the pitfalls to folks 
that'll use it.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 55 (v1) Compilation: Remove requirement for fina

[John Porter]

Nathan Torkington wrote:
> John Porter writes:
> > Throw an exception in order to return a (0|'')-but-true value?
> 
> If you want to indicate that there was an error in the code, why not
> die()?  What am I missing?

I'm talking about the case where the require should "succeed" but
the return value is one which would evaluate to false, i.e.

package Foo;
initialize_myself();
my $n = how_many_frobnitzes_loaded();
$n;  # may be 0

and then

my $n_frobs = require Foo;

But I admit this could be regarded as an edge case.

-- 
John Porter

Re: DRAFT RFC: Enhanced Pack/Unpack

[Glenn Linderman]

Tom Hughes wrote:

> In message <[EMAIL PROTECTED]>
>   Edwin Wiles <[EMAIL PROTECTED]> wrote:
>
> > Endianness:
> >
> > /d - default, whatever your system uses normally
> > /n - network
> > /b - big
> > /l - little
> > /v - vax
> >
> > (??vax is sufficiently different to require it's own??  Or is this to do
> > with bit order?)
>
> VAX is either big or little. I can't remember which off the top
> of my head.
>
> You may be getting confused here with the middle-endian system
> used by the PDP machines which goes 3412 or something rather than
> the 1234 or 4321 that most machines use.

Yes!!!  And you are saying that VAX didn't inherit that when VAX replaced PDP?  I
think I recall multiplatform code in a system I used to work on (but not that
part of) still claiming that VAX used middle-endian... perhaps VAX is little
endian, with compatibility flags settable to make it middle-endian?

I think middle-endian was approximately defined as: 16-bit words are big endian,
and anything bigger uses little endian order of big endian chunks of 16-bits.  In
other words, middle-endian is little endian based on 16-bit chunks, but when
looked at via 8-bit chunks becomes different than little endian.

> Tom
>
> --
> Tom Hughes ([EMAIL PROTECTED])
> http://www.compton.nu/
> ...It now costs more to amuse a child than it once did to educate his father.

--
Glenn
=
There  are two kinds of people, those
who finish  what they start,  and  so
on... -- Robert Byrne



NetZero Free Internet Access and Email_
Download Now http://www.netzero.net/download/index.html
Request a CDROM  1-800-333-3633
___

Re: Deep copy

[Uri Guttman]

> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:

  DS> At 10:07 AM 8/7/00 -0700, Peter Scott wrote:
  >> At 12:53 PM 8/7/00 -0400, Dan Sugalski wrote:
  >>> There are a wide range of tricky problems associated with deep copy and 
  >>> deep compare. I like the idea, but circular references can make this 
  >>> problematic even without external things (filehandles, dirhandles, 
  >>> objects from non-perl sources) are thrown in. That needs to be taken into 
  >>> account when putting together the RFC for it, if someone even does.
  >> 
  >> I don't want it to go undocumented; I can write an RFC since I started the 
  >> thread, or Damian can write it since he brought up clone() before that.  I 
  >> defer to Damian.
  >> 
  >> I don't think it's impossible to do something useful, if we think 
  >> sufficiently Perlish.

  DS> That's fine. I'm not against it (I like it), I just want to know
  DS> what needs to be done under the hood, and we need to document the
  DS> pitfalls to folks that'll use it.


the biggest pitfalls are circular structures. i see two opposing ideas
here. 

the first is to allow deep copying but caveat coder. if you are
doing circles, override with your own clone method. i know some here do
circles a great deal and have to deal with it in DESTROY and other messy
place. but the majority of perl data structures are plain trees which
can be cloned easily. i also know that lisp tends to more circular stuff
(since they HAVE to :) so they never did a generic deep copy.

second, is we do a deep copy like someone mentions with Storable like
semantics. it handles circles already. but again caveat coder as it can be
a dangerous call to make.

as for tied objects and databases, a hornets' nest awaits.

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t

[Nathan Wiger]

> With the proliferation of special subroutine names (BEGIN, END, INIT,
> CHECK, etc.) the all capital subroutine names available to the
> programmer has steadily shrunk.  Rather than stealing subroutines from
> the programmer, we should create a space just for Perl.
> 
> sub *BEGIN {
> # do compile-time stuff
> # Perl-special
> }

I think this is a very valid point, but I don't think a special
character should be chewed up for this. In particular, I really don't
see typeglobs going away (they do some things you can't do otherwise).
Besides, subs already have a magic character - the word "sub".

Maybe just a convention like a leading underscore or two + CAPS?

   sub _TIESCALAR {}
   sub _FETCH {}
   sub _STORE {}
   sub _DESTROY {}

-Nate

Re: RFC 48 (v1) Replace localtime() and gmtime() with da

[Glenn Linderman]

Me too, and I'm _not_ an astronomer.

Tim Jenness wrote:

> Also, I would vote for a method to return the Julian date (yes I am an
> astronomer...) :-)

--
Glenn
=
There  are two kinds of people, those
who finish  what they start,  and  so
on... -- Robert Byrne



_NetZero Free Internet Access and Email__
   http://www.netzero.net/download/index.html

Re: RFC: Rename local() operator

[Jonathan Scott Duff]

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]

Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t

[Nathan Wiger]

> If you're going to use a convention, rather than a syntax, then the current
> convention of all CAPS reserved to Perl is easier to understand, more
> pleasing to the eye, and backwards compatible.

Good point. Maybe we're getting a little "fix-happy". :-)

-Nate

Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t

[Peter Scott]

At 10:29 AM 8/7/00 -0700, Nathan Wiger wrote:
> > With the proliferation of special subroutine names (BEGIN, END, INIT,
> > CHECK, etc.) the all capital subroutine names available to the
> > programmer has steadily shrunk.  Rather than stealing subroutines from
> > the programmer, we should create a space just for Perl.
> >
> > sub *BEGIN {
> > # do compile-time stuff
> > # Perl-special
> > }
>
>I think this is a very valid point, but I don't think a special
>character should be chewed up for this. In particular, I really don't
>see typeglobs going away (they do some things you can't do otherwise).
>Besides, subs already have a magic character - the word "sub".
>
>Maybe just a convention like a leading underscore or two + CAPS?
>
>sub _TIESCALAR {}
>sub _FETCH {}
>sub _STORE {}
>sub _DESTROY {}

If you're going to use a convention, rather than a syntax, then the current 
convention of all CAPS reserved to Perl is easier to understand, more 
pleasing to the eye, and backwards compatible.

--
Peter Scott
Pacific Systems Design Technologies

Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t

[Jonathan Scott Duff]

On Mon, Aug 07, 2000 at 10:04:15AM -0700, Peter Scott wrote:
> At 04:43 PM 8/7/00 +, Perl6 RFC Librarian wrote:
> > sub *BEGIN  { ... }
> > sub *END{ ... }
> > sub *INIT   { ... }
> > sub *AUTOLOAD   { ... }
> > sub *TIESCALAR  { ... }
> > sub *FETCH  { ... }
> 
> Only half of those are subs.

What do you mean?

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: RFC 48 (v1) Replace localtime() and gmtime() with da

[Andy Dougherty]

On Mon, 7 Aug 2000, Glenn Linderman wrote:

> Me too, and I'm _not_ an astronomer.
> 
> Tim Jenness wrote:
> 
> > Also, I would vote for a method to return the Julian date (yes I am an
> > astronomer...) :-)

But surely not as a part of the core language?

-- 
Andy Dougherty  [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042

Re: DRAFT RFC: Enhanced Pack/Unpack

[John Porter]

> > VAX is either big or little. I can't remember which off the top
> > of my head.

Right, VAX is strictly little-endian.
I.e. the address of a *word is the address of its least significant byte. 
(That's little-endian, isn't it?)


-- 
John Porter

Re: RFC 55 (v1) Compilation: Remove requirement for fina

[Nathan Torkington]

John Porter writes:
> But I admit this could be regarded as an edge case.

Yeah, you could easily make this part of the module's interface.
Removing the eval-to-true requirement would be one less arbitrary
thing for people writing modules to do, and I'm very in favour of
that.

Nat

Re: RFC: Rename local() operator

[Nathan Wiger]

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

A valid distinction. Though, "now" has an action-like ring to it, even
though it's not truly a verb. "NOW this var is this value"

Even some other action verbs, like "assign", "put", "place", and so on
have less of an action content, to me.

As for this:

$/ = "\n" for now;

That is English-like, but no more that the leading version, and very
odd, even for Perl. I'm pretty sure I prefer the shorter, more
consistent leading way:

   my $bob = 'jim';
   our $stuff = 'this';
   {
  now $stuff = 'that';
   }

Seems to flow really well, in my opinion.

-Nate

Re: RFC 48 (v1) Replace localtime() and gmtime() with da

[Nathan Wiger]

> > > Also, I would vote for a method to return the Julian date (yes I am an
> > > astronomer...) :-)
> 
> But surely not as a part of the core language?

Exactly. In fact, I'm going to chop a lot of the original proposal out.
It's too bloated for core. 

There's a lot of cool time/date stuff, but there's plenty of chance for
external modules for that (including backwards localtime()
compatibility).

-Nate

Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t

[Jonathan Scott Duff]

On Mon, Aug 07, 2000 at 10:56:40AM -0700, Peter Scott wrote:
> I meant that BEGIN, END, and INIT aren't declared as subs at present but 
> named blocks.  I was surprised to discover that they're put in the symbol 
> table anyway though.  But they're definitely 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]

Re: RFC 59 (v1) Proposal to utilize C<*> as the prefix t

[Peter Scott]

At 12:55 PM 8/7/00 -0500, Jonathan Scott Duff wrote:
>On Mon, Aug 07, 2000 at 10:04:15AM -0700, Peter Scott wrote:
> > At 04:43 PM 8/7/00 +, Perl6 RFC Librarian wrote:
> > > sub *BEGIN  { ... }
> > > sub *END{ ... }
> > > sub *INIT   { ... }
> > > sub *AUTOLOAD   { ... }
> > > sub *TIESCALAR  { ... }
> > > sub *FETCH  { ... }
> >
> > Only half of those are subs.
>
>What do you mean?

I meant that BEGIN, END, and INIT aren't declared as subs at present but 
named blocks.  I was surprised to discover that they're put in the symbol 
table anyway though.  But they're definitely in a different class, 
syntactically if nothing else.


--
Peter Scott
Pacific Systems Design Technologies

Re: DRAFT RFC: Enhanced Pack/Unpack

[Tom Hughes]

In message <[EMAIL PROTECTED]>
  Glenn Linderman <[EMAIL PROTECTED]> wrote:

> Tom Hughes wrote:
>
> > VAX is either big or little. I can't remember which off the top
> > of my head.
> >
> > You may be getting confused here with the middle-endian system
> > used by the PDP machines which goes 3412 or something rather than
> > the 1234 or 4321 that most machines use.
>
> Yes!!!  And you are saying that VAX didn't inherit that when VAX replaced PDP?

Definately. I forgot to check the VAXen at work today but I know
for a fact that they aren't middle endian as our code base has no
support for that.

> I think middle-endian was approximately defined as: 16-bit words are big
> endian, and anything bigger uses little endian order of big endian chunks
> of 16-bits.  In other words, middle-endian is little endian based on 16-bit
> chunks, but when looked at via 8-bit chunks becomes different than little
> endian.

>From /usr/include/endian.h on my linux box:

#define __LITTLE_ENDIAN 1234
#define __BIG_ENDIAN4321
#define __PDP_ENDIAN3412

Basically PDP or middle endian is low byte first within each word
but high word first in the overall longword.

Tom

-- 
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/
...Never insult an alligator until you have crossed the river.

RFC17 (v1) comments and responses

[Steve Simmons]

This is an omnibus response to those who've commented on RFC17 (v1).
The version I'm about to submit to the librarian is now available
as html at .

General note -- please look over the abstract.  Some folks have made
really good suggestions to change things which are (IMHO) outside of the
scope of this effort.  RFC focuses on a suggestion to the developers
that a naming scheme be adopted which is more mnemonic and which
makes it immediately visible which variables are related.

Ted Ashton <[EMAIL PROTECTED]> kindly provided the formal
objection to:

> An at least %800 increase in the characters used to make up these names.
> For quick hacks, this is a pain and from my experience with English.pm,
> I had to spend just as much time looking up which word I have to use as
> I ever did looking up which punctuation.

Not to disagree with Teds claim of what he spends his time on, but
*this* programmer is far less likely to turn to the manual when he
sees
$WARNING = 0;
than when he sees
$^W = 0;
And $^W is one of the more mnemonic ones (shudder).  But regardless of
*my* opinion, his comments are now incorporated into the about-to-be
submitted new version of the RFC.


"J. David Blackstone" <[EMAIL PROTECTED]> wrote:

> ...Larry implied that there might not be much left when all these
> variables are cleaned up...

Yes.  Renaming is only proposed for what's left.
If not much is left, that's a Good Thing.

> I suggest that the most productive thing to do right now is go
> through the special variables manpage and make a list of how the
> *feature* provided by each variable should be re-implemented to
> avoid action-at-a-distance problems.  Any volunteers?

I'm of two minds on this.  On one hand, it would be useful for us to set
some sort of direction for the language developers to follow.  On the
other, they're the ones who are going to have to decide what lives and
dies, and how the remaining ones should be grouped.  IMHO the proposal
as it stands describes the policy sufficiently; the the developers are
the ones


Bart Lateur <[EMAIL PROTECTED]> asks responsed to a suggestion by
David Blackstone:

> > As another example, at work we are in love with the $/ variable,
> > since we often deal in multi-line records delimited with control-Y's.
> > However, changing this variable affects _everything_, meaning modules
> > you want to use might not work unless you only modify $/ with local()
> > within a subroutine.  The solution is for the concept of $/ to become
> > a per-filehandle value, as in, encapsulation and object-orientation.

> I have only one problem with this solution, and that is with the <>
> magic file handle. Would it's private $/ stick across files?  Well, er,
> yes...

This RFC is on the reorganization and potential renaming of these
variables, not on changing their function.  IMHO this suggestion (while
interesting) belongs elsewhere.  It's a suggestion on modifying the
scope of modified settings in perl.  Each of those needs to be discussed
in some topic relative to the feature which is modified by the variable,
not in their renaming and potential removal.


Tom Christiansen <[EMAIL PROTECTED]> writes:

> If we were selecting dubious features to shoot (and I think we are),
> then the fact that $^F and $^F are the same is one I'd kill--by zapping
> the latter, too.

Again, grist for the mill for the folks who work on those particular
features.


William Setzer <[EMAIL PROTECTED]> made a comment on loss of
distinctiveness which I have taken almost in its entirety into the
new document.


Mark-Jason Dominus <[EMAIL PROTECTED]> kicked off an excellent discussion on
the general wisdom of having these variables at all.  I tend to agree with
his core points, and have added a small section on the topic to the RFC.
It concludes with ``Notwithstanding, should the core team continue to
allow global variables for these purposes, the names and categorization
should be improved.''


Many thanks to all.

Re: RFC 53 (v10) Built-ins: Merge and generalize C

[Damian Conway]

   > Can anyone come up with a good example when you'd want to use both these
   > parameters at the same time?

Second "foo" after the last "bar":

index $text, "foo", index($text,"bar",0,-1), 2);
   
Damian

Re: RFC 54 (v1) Operators: Polymorphic comparisons

[Damian Conway]

   > > This RFC proposes that numeric comparison operators default to stringwise
   > > comparison when both arguments are non-numeric strings.
   > > 
   > The problem with this, is that we're removing orthogonality from the
   > language.

ROTFL.


   > Do we want to say:
   >   $num1 == $num2 works
   >   $string1 == $string2 works
   >   $string1 eq $string2 works
   >   $num1 ==  works
   >   $num1 eq  breaks?

No, this last one still works.

Damian

Re: RFC 54 (v1) Operators: Polymorphic comparisons

[Damian Conway]

   > This seems to be adding a special case. (I.e. only if _both_ are
   > non-numeric will it switch to a cmp operation.)

Well, I'd prefer it to always switch, but I thought that might be argued
against. Since, *this* is being argued against, maybe I'll extend my proposal
:-)

   > I currently fail to switch to 'eq' many times when I should, but the
   > failure mode is obvious. Her the failure mode will be really strange.

I would claim that the failure mode is not obvious: "dog"=="cat" is true

I often need a generic comparison test (typically for equality of less-than),
and to get it one has to jump through hoops:

sub generic_eq {
my $failed;
local SIG{__WARN__} = { $failed = 1 };
return $_[0] eq $_[1] || $_[0]==$_[1] && !$failed;
}

I want generic equality to DWIM. I.e. are these the same (for some
reasonable value of "same").

And "dog"=="cat" is not a reasonable value of "same".

Damian

Re: RFC 52 (v1) List context return from filesystem func

[Hildo Biersma]

Leon Brocard wrote:
> 
> Perl6 RFC Librarian sent the following bits through the ether:
> 
> > affected files.  I suggest that in a list context, they return the I
> > of the I affected files.
> 
> This seems the wrong way around to me. Surely it should instead return
> the name of the successfully affected files? Hm.

You only want the names of the failures, becuase those are the ones you
want to report / try remedial action for, etc.

Now, Damian could of course extend his 'want' RFC to include a
'want-success' or 'want-failure' option :-)

Hildo

Re: RFC 53 (v10) Built-ins: Merge and generalize C

[Hildo Biersma]

Perl6 RFC Librarian wrote:
> 
> This and other RFCs are available on the web at
>   http://dev.perl.org/rfc/
> 
> =head1 TITLE
> 
> Built-ins: Merge and generalize C and C
> 

Sounds good - but having both the third and fourth arguments feel
counter-intuitive to me.  It certainly seems relatively hard to explain
to newbies...

Can anyone come up with a good example when you'd want to use both these
parameters at the same time?

Otherwise, I'd rather see two different functions, one using a character
offset (as in current index/rindex) and once counting occurrences.

Hildo

Re: RFC 54 (v1) Operators: Polymorphic comparisons

[Hildo Biersma]

Perl6 RFC Librarian wrote:
> 
> This and other RFCs are available on the web at
>   http://dev.perl.org/rfc/
> 
> =head1 TITLE
> 
> Operators: Polymorphic comparisons
> 
> =head1 VERSION
> 
>   Maintainer: Damian Conway <[EMAIL PROTECTED]>
>   Date: 7 August 2000
>   Version: 1
>   Mailing List: [EMAIL PROTECTED]
>   Number: 54
> 
> =head1 ABSTRACT
> 
> This RFC proposes that numeric comparison operators default to stringwise
> comparison when both arguments are non-numeric strings.
> 
> =head1 DESCRIPTION
> 
> Currently the expression:
> 
> "cat" == "dog"
> 
> returns true.
> 

The problem with this, is that we're removing orthogonality from the
language.

Do we want to say:
  $num1 == $num2 works
  $string1 == $string2 works
  $string1 eq $string2 works
  $num1 ==  works
  $num1 eq  breaks?

I'd rather have it break in a generic way (as it does now), and teach
people what happens, than introduce a more hidden case of failure.

Or do we want to generate syntax errors for the last case above?

Hildo

Re: RFC 56 (v1) Optional 2nd argument to pop() and shift

[Aaron J Mackey]

proposed:

@b = pop @a, $n;

should this be equivalent to:

@b = splice @a, -$n; # no longer a LIFO queue

or :

@b = reverse splice @a, -$n; # still a LIFO queue


I guess it all depends on what you then do with @b, but you get my drift.
This should be addressed, one way or another.

-Aaron

ISA number

[Peter Scott]

Have often wanted a way to tell whether a scalar was a number, and rolling 
a regex each time seemed wasteful given that Perl knew what it was 
anyway.  So a user-friendly way to get at the SvIOK and SvNOK results would 
be great.

The pedestrian way would be a builtin: isnum() or similar.  But we have 
enough creativity here I'm sure we can come up with something far more 
obfusc^Wconcise :-)
--
Peter Scott
Pacific Systems Design Technologies

Re: RFC 54 (v1) Operators: Polymorphic comparisons

[John Porter]

Damian Conway wrote:
>> > This RFC proposes that numeric comparison operators default to stringwise
>> > comparison when both arguments are non-numeric strings.
>> > 
>> The problem with this, is that we're removing orthogonality from the
>> language.
> 
> ROTFL.

But it's true. 
The semantics of == vs eq is currently very well defined and distinct. 
The proposal muddies the distinctions. 

The thing that allows you to LOL is precisely the thing which should
motivate us to not reduce Perl's already low orthogonality quotient
without very compelling reasons.

-- 
John Porter

Re: ISA number

[Hildo Biersma]

Peter Scott wrote:
> 
> Have often wanted a way to tell whether a scalar was a number, and rolling
> a regex each time seemed wasteful given that Perl knew what it was
> anyway.  So a user-friendly way to get at the SvIOK and SvNOK results would
> be great.
> 
> The pedestrian way would be a builtin: isnum() or similar.  But we have
> enough creativity here I'm sure we can come up with something far more
> obfusc^Wconcise :-)

Agree here.  I've seen people resort to DBI.pm's 'looks_like_number' or
using tricks like ($a + 0 eq $a), but really this should be easier. 
Having said that, it doesn't need to live in the core - and even today
it should be relatively easy to write an XS module for this.

Hildo

Re: ISA number

[John Porter]

Peter Scott wrote:
> Have often wanted a way to tell whether a scalar was a number, ...
> So a user-friendly way to get at the SvIOK and SvNOK results would 
> be great.

This is one of those rare proposals which can safely be assumed to
be proposed, discussed, and accepted without dissent -- before the RFC
is even issued!

-- 
John Porter

Re: ISA number

[Dan Sugalski]

At 12:27 PM 8/7/00 -0700, Peter Scott wrote:
>Have often wanted a way to tell whether a scalar was a number, and rolling 
>a regex each time seemed wasteful given that Perl knew what it was 
>anyway.  So a user-friendly way to get at the SvIOK and SvNOK results 
>would be great.

The Sv?OK macros will likely go away in the new internals, or at least be 
different. It'd be better to figure out what you really want to know. Those 
macros tell you whether a scalar has already been changed to an integer, 
float, or string, rather than whether it can be an int, float, or string, 
for example.

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: ISA number

[John Porter]

Hildo Biersma wrote:
> Having said that, it doesn't need to live in the core - and even today
> it should be relatively easy to write an XS module for this.

It should no more NOT live in the core than, say, scalar() (or whatever
scalar() might become in 6).

-- 
John Porter

Re: ISA number

[Peter Scott]

At 08:31 PM 8/7/00 +0100, Hildo Biersma wrote:
>Peter Scott wrote:
> >
> > Have often wanted a way to tell whether a scalar was a number, and rolling
> > a regex each time seemed wasteful given that Perl knew what it was
> > anyway.  So a user-friendly way to get at the SvIOK and SvNOK results would
> > be great.
> >
> > The pedestrian way would be a builtin: isnum() or similar.  But we have
> > enough creativity here I'm sure we can come up with something far more
> > obfusc^Wconcise :-)
>
>Agree here.  I've seen people resort to DBI.pm's 'looks_like_number' or
>using tricks like ($a + 0 eq $a), but really this should be easier.
>Having said that, it doesn't need to live in the core - and even today
>it should be relatively easy to write an XS module for this.

Hmm.  It seems pretty core-ish to me, but if you're thinking frequency of 
use, I agree.  I thought I'd mention it here in case it turns out to fall 
out naturally of one of Damian's mind-twisting syntactical voyages of 
discovery.


--
Peter Scott
Pacific Systems Design Technologies

Re: Deep copy

[Dan Sugalski]

At 01:27 PM 8/7/00 -0400, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>   DS> At 10:07 AM 8/7/00 -0700, Peter Scott wrote:
>   >> At 12:53 PM 8/7/00 -0400, Dan Sugalski wrote:
>   >>> There are a wide range of tricky problems associated with deep copy 
> and
>   >>> deep compare. I like the idea, but circular references can make this
>   >>> problematic even without external things (filehandles, dirhandles,
>   >>> objects from non-perl sources) are thrown in. That needs to be 
> taken into
>   >>> account when putting together the RFC for it, if someone even does.
>   >>
>   >> I don't want it to go undocumented; I can write an RFC since I 
> started the
>   >> thread, or Damian can write it since he brought up clone() before 
> that.  I
>   >> defer to Damian.
>   >>
>   >> I don't think it's impossible to do something useful, if we think
>   >> sufficiently Perlish.
>
>   DS> That's fine. I'm not against it (I like it), I just want to know
>   DS> what needs to be done under the hood, and we need to document the
>   DS> pitfalls to folks that'll use it.
>
>
>the biggest pitfalls are circular structures. i see two opposing ideas
>here.
>
>the first is to allow deep copying but caveat coder. if you are
>doing circles, override with your own clone method. i know some here do
>circles a great deal and have to deal with it in DESTROY and other messy
>place. but the majority of perl data structures are plain trees which
>can be cloned easily. i also know that lisp tends to more circular stuff
>(since they HAVE to :) so they never did a generic deep copy.

Well, if we provide a primitive for this (a big if) I expect it can be 
piggy-backed onto the GC code somehow, which needs to do the same sorts of 
things.

>as for tied objects and databases, a hornets' nest awaits.

No doubt. This is where the interesting work resides, which is why I'm all 
up for passing the buck to the mythical CLONE sub. :0

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: RFC 48 (v1) Replace localtime() and gmtime() with da

[Andy Dougherty]

On Mon, 7 Aug 2000, Philip Newton wrote:

> On Mon, 7 Aug 2000, Tim Jenness wrote:
> 
> > Is localtime() used often enough to justify being part of
> > the language?
> 
> You're kidding, right?

No, not at all.
 
> We wouldn't have had all those script kiddies complaining about year 19100
> bugs and month-being-off-by-one errors if localtime() wasn't being used
> all of the time, whether in CGI code or not.

Yes, obviously it has been used by many.  That means that the equivalent
functionality needs to be provided somehow in the complete standard perl6
distribution.  It doesn't mean localtime() has to be a keyword with its
very own opcode that is part of the core language.  It could be part of a
module.  In fact it already is in perl5:  POSIX::localtime.

POSIX::localtime() (or some descendent of it) will almost surely continue
to be available.  It's quite possible that other date/time functions may
be part of the standard library too.

-- 
Andy Dougherty  [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042

Re: Deep copy

[Uri Guttman]

> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:

  DS> Well, if we provide a primitive for this (a big if) I expect it
  DS> can be piggy-backed onto the GC code somehow, which needs to do
  DS> the same sorts of things.

the tree/structure scanner could be shared. in fact since GC has to
detect loops with the mark pass, you get a clean copy as well.


  DS> No doubt. This is where the interesting work resides, which is why
  DS> I'm all up for passing the buck to the mythical CLONE sub. :0

what about this approach: we provide a UNIVERSAL::CLONE (damian's idea
as usual!) which does a clean deep copy if possible. when it detects
wacko things like tied objects, it tries to skip them cleanly or invoke
some method to clone it. any class can provide a CLONE method to allow
local overloading of the CLONE method.

if that class method invocation occurs within a single perl op (assuming
deep copy is written internally and not in perl), it is like a thread
and that brings up issues. it is more like reentering the interpreter or
even recursing. is this something to think about when creating the
internals. i said in the async I/O RFC that the entire interpreter
should be fully reentrant to support threads cleanly.

it all ties together. that is the perlish way.

better GC begets better cloning which is supported by needing threads.

uri

-- 
Uri Guttman  -  [EMAIL PROTECTED]  --  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  ---  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  --  http://www.northernlight.com

Wither scalar() (was Re: ISA number)

[Jonathan Scott Duff]

On Mon, Aug 07, 2000 at 03:35:25PM -0400, John Porter wrote:
> Hildo Biersma wrote:
> > Having said that, it doesn't need to live in the core - and even today
> > it should be relatively easy to write an XS module for this.
> 
> It should no more NOT live in the core than, say, scalar() (or whatever
> scalar() might become in 6).

Is someone proposing to morph scalar() into something else?  I hadn't
thought of it though it does sort-of make sense to have a "casting"
operator if we're going to have want().

my $obj = cast '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]

RE: Deep copy

[Damian Conway]

   > >There are a wide range of tricky problems associated with deep
   > >copy and deep compare. I like the idea, but circular references
   > >can make this problematic even without external things
   > >(filehandles, dirhandles, objects from non-perl sources) are
   > >thrown in. That needs to be taken into account when putting
   > >together the RFC for it, if someone even does.
   > 
   > I don't want it to go undocumented; I can write an RFC since I
   > started the thread, or Damian can write it since he brought up
   > clone() before that. I defer to Damian.

I'm polluting the mailing list enough, as it is! :-)
Why don't you write it up and run it by me.

Damian

PS: I'd like to see it correctly handle cyclic data structures too!

Re: RFC 48 (v1) Replace localtime() and gmtime() with da

[Jonathan Scott Duff]

On Mon, Aug 07, 2000 at 03:52:07PM -0400, Andy Dougherty wrote:
> That means that the equivalent
> functionality needs to be provided somehow in the complete standard perl6
> distribution.  It doesn't mean localtime() has to be a keyword with its
> very own opcode that is part of the core language.  It could be part of a
> module.  In fact it already is in perl5:  POSIX::localtime.

Especially as the gap between opcodes and regular subs gets smaller.
(I can imagine all sorts of things like each "compiled" perl program
gets its own local set of opcodes for the subs it uses (that can be
determined at compile time))

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: RFC 37 (v1) Positional Return Lists Considered Harmf

[Glenn Linderman]

An excellant idea, in my opinion.

It would be a very appropriate use of structure handling to address system APIs
with structures as parameters or returns.  Indeed, stat, localtime, and other
firends could be handled via predefined structure definitions.  This is not to say
that we should eliminate -M (and friends), and not to say that we shouldn't have a
built-in date feature that is friendlier than the localtime system call.

Chaim Frenkel wrote:

> Fixed hashes, such as the return from stat() can be handled in the
> compiler. (Ala perl5's pseudo hash.)
>
> This could possibly be combined with the proposed direct pack/unpack
> handling of structures. So that the stat buffer would be transformed
> into a hash refering to a structure buffer.
>
> $stat{ino} could directly access the structure.
> $stat{$field} would go via the hash interface.
>
> 
>
> > "SS" == Steve Simmons <[EMAIL PROTECTED]> writes:
>
> >> =head1 IMPLEMENTATION
>
> SS> I strongly support Damiens suggestion on a hashref, and would go so
> SS> far as to say it should be a pseudo-hash, with all the attendant
> SS> misspelling protections and speed obtained.
>
> SS> Passing lists around can be expensive, manipulating hashes can be
> SS> expensive.  I'd extend Damiens suggestion to allow the programmer
> SS> to specify only the sub-data desired, eg:
>
> SS> # undef context, store results in passed hashref
>
> SS> my %data_wanted = \(mode => 0, nlink => 0);
> SS> stat( $filename,\$data_wanted);
>
> SS> This could even be done in a list context, with a possible
> SS> implementation suggested:
>
> SS> # List context, return only the two values requested in order
>
> SS> ($mode,$nlink) = stat($filename,\('mode','nlink'));
>
> --
> Chaim FrenkelNonlinear Knowledge, Inc.
> [EMAIL PROTECTED]   +1-718-236-0183

--
Glenn
=
There  are two kinds of people, those
who finish  what they start,  and  so
on... -- Robert Byrne



NetZero Free Internet Access and Email_
Download Now http://www.netzero.net/download/index.html
Request a CDROM  1-800-333-3633
___

Re: RFC: Rename local() operator

[Glenn Linderman]

Bart Lateur wrote:

> >The C operator of Perl5 and earlier does not do what it claims
> >to and should be renamed.
>
> How about:
>
> override
>
> meaning: ignore the value you've seen so far, for now, you'll use my
> value.

This is the sort of thing I was looking for when I proposed "redef" (for
redefine) as a "local" replacement.  "override" is better.  Thank you,
Bart.
--
Glenn
=
There  are two kinds of people, those
who finish  what they start,  and  so
on... -- Robert Byrne




___
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html

Re: RFC 50 (v1) BiDirectional Support in PERL

[Bart Lateur]

On Mon, 7 Aug 2000 12:04:11 +0300, Roman M . Parparov wrote:

>I wrote a WWW mail program with hebrew support once. Pain in the ass to
>invent and reinvent functions for printing Hebrew correctly. Moreover, a
>lot of self-written reversing and replacing reduces the performance from
>what it would be if we just had it implemented in the core of Perl.

That doesn't sound like it should be. The start of a sentence should
come first, i.e. substr($_, 0, 1) should return the first character.
Whether this should appear on the left or on the right of the screen, is
not Perl's concern.

Granted, I've heard of primitive output devices which a re blissfully
unaware of the correct graphical output of such text strings, and which
would print them from left to right anyway. But a silly patch that
remedies the symptoms while ignoring the underlying false assumptions,
does not seem right.

What if you encounter a display device that correctly displays Hebrew
text from right to left?

-- 
Bart.

Re: RFC 48 (v1) Replace localtime() and gmtime() with da

[Glenn Linderman]

Andy Dougherty wrote:

> On Mon, 7 Aug 2000, Glenn Linderman wrote:
>
> > Me too, and I'm _not_ an astronomer.
> >
> > Tim Jenness wrote:
> >
> > > Also, I would vote for a method to return the Julian date (yes I am an
> > > astronomer...) :-)
>
> But surely not as a part of the core language?

It isn't that hard/big; dates are an extremely useful type of value to
manipulate; Julian dates are much easier to manipulate than year/month/day.

That said, I really don't care if it is core, as long it is available in the
standard distribution.

--
Glenn
=
There  are two kinds of people, those
who finish  what they start,  and  so
on... -- Robert Byrne



NetZero Free Internet Access and Email_
Download Now http://www.netzero.net/download/index.html
Request a CDROM  1-800-333-3633
___

Re: Safer OO inheritance

[Damian Conway]

   > I'm more in favor of a mechanism that makes it easy to build field
   > names from the package name, for those rare cases where you want
   > scoped fields. There were discussions about this a couple of years ago
   > on p5p. For example:
   > 
   > package Foo;
   > 
   > sub new { bless { "${CURRENT_PACKAGE}name" => 'Simpson' ... }
   > 
   > ...where $CURRENT_PACKAGE is a special variable automatically set
   > to...guess what? ;-)

See the Tie::Securehash module for a variation on this theme.
Also note that I will be proposing something similar in my
general revamp of Perl OO (RFCs galore, probably next week).

Damian

Re: RFC 55 (v1) Compilation: Remove requirement for fina

[Bart Lateur]

On 7 Aug 2000 14:28:03 -, Perl6 RFC Librarian wrote:

>Compilation: Remove requirement for final true value in require'd and do'ed files

Er... "do'ne" files?

Anyway, There is at least one case where you need this true value: if
the file accidently is empty (or equivalent). I've had that happen.

A true value indicates that the file is indeed valid Perl.

-- 
Bart.

Re: RFC 53 (v10) Built-ins: Merge and generalize C

[Damian Conway]

   > > $last = index $string, $substring, -1, -1;   # last occurence
   > 
   > Err... shouldn't that be 
   > 
   > $last  = index $string, $substring, 0, -1  # last occurrence
   > $first = index $string, $substring, -1, -1 # first occurrence found
   ># in a perverse way
   > 
   > Or am I seeing double negatives where I shouldn't?

No. You're missing the fact that the third argument of rindex specifies
the last character at which the match can be found (as opposed to index's
third arg which specifies the *first* character from which to search)

Damian