Re: list changes: perl6-language-objects added, perl6-language-unlink closed

[skud]

On Tue, Aug 15, 2000 at 09:27:23PM -0700, Ask Bjoern Hansen wrote:
>LIST:   perl6-language-objects
>CHAIR:  Nathan Wiger <[EMAIL PROTECTED]>
>MISSION:Develop RFCs related to objects and OO programming in
>Perl, possibly rationalising existing RFCs where they
>cover the same ground.
>DEADLINE:   As long as it takes.  Report fortnightly (first report
>August 29th).

Nathan, as a first task, could you figure out a list of which existing
RFCs belong on the -objects list?

K.

-- 
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949  Fax: +61 3 9614 0948  Mobile: +61 410 664 994

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

[skud]

Please take this discussion to perl6-language-datetime.  Thanks!

K.

-- 
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949  Fax: +61 3 9614 0948  Mobile: +61 410 664 994

Array notation (was Re: RFC 104 (v1) Backtracking)

[Jeremy Howard]

Mark Cogan wrote:
> At 11:11 PM 8/15/00 -0400, Chaim Frenkel wrote:
> >You are missing the beauty of vector/matrix operations.
>
> No, I'm not; I'm opining that the vast majority of Perl users don't need
to
> do vector/matrix ops, and that they don't belong in the core.
>
The vast majority of Perl 5 users don't, because it's a pain in Perl 5. They
use other languages instead, but those other languages aren't nearly as nice
as Perl in almost every other way. Why not open up Perl for a whole new
class of folks?
>
> >The math folks
> >really would like to be able to describe the operation wanted and have
> >perl do the optimization.
>
> Then maybe they should use a dedicate math extension to Perl, like PDL.
>
You've got to be joking! You think PDL is a simple convenient add-on to Perl
that provides these features? It's not! PDL is an astonishing hack by some
incredibly clever people, but it still _does_not_ support array notation,
and optimised loops have to be written in yet *another* language named PP,
which is compiled into C by a special compiler, and linked into the program.
This is the absolute best that can be done right now, and the PDL folks
deserve a medal for what they've achieved. But really, no-one should have to
jump through these kinds of hoops!

> >Would adding another character be helpful
> >
> > @result = @a x|| @b?
> >
> > @result = @a ||| @b?
> >
> >or perhaps a modifier?
> >
> > @result = @a || @b forall;
> >
> >(Blech, that just doesn read right.)
>
> Perhaps we just need a two-list map, which aliases $a and $b like sort():
>
> @result = map {$a || $b} @a,@b;
>
No. It would need to be n-list, and it would have to handle slices and
lazily generated lists incredibly cleverly. map is too generic to easily
make the kinds of optimisations required for array notation.

I don't know how to convince you here. There's a feature that, if added to
Perl, would make my life and many of my collegues lives easier. I know this
for a fact because I've used it elsewhere. I doesn't break much that can't
fairly easily be incorporated into P52P6, it's a generic abstraction that
applies to many things other than numeric programming (it's great for string
manipulation!), and it's proved itself elsewhere.

I'm not ruling out a modifier, as Chaim outlined, although I agree that the
word 'blech' comes to mind. But this is too good an opportunity to see it
just disappear. Have a look at the examples in RFCs 23, 76, 81, 82, 90, and
91, which combine together to provide as strong a data manipulation language
as you'll find anywhere. Over the next few days I'll be updating these to
include more examples, particularly non-numeric ones.

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

[Russ Allbery]

Damien Neil <[EMAIL PROTECTED]> writes:

> Arrays are ordered.  Hashes are not.  Sure, you can iterate over a hash,
> but add an element to one and you can change the order of everything in
> it.

Formally, I believe it's permissable for a hash implementation to return a
different order the second time you iterate through it from the first
time, even if you haven't touched the hash inbetween.  That's the
definition of an iterable but unordered data structure; there's some way
of getting all of the members one and only one time, but each time you
look at it the order in which the members show up may be different (maybe
garbage collection happened behind the scenes, the hash was reorganized
due to an observation of how you were using it, etc.).

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: RFC 82 (listops in list context)

[Damien Neil]

On Tue, Aug 15, 2000 at 11:15:03PM -0700, Peter Scott wrote:
> No, || is half-consistent at the moment: the left hand side is forced into 
> scalar context but the result context propagates down the right hand 
> side.  I challenge anyone to come up with a rationalization for this that 
> does not invoke implementation expediency.

By extension with

  $a = $a || "default";

you get

  @a = @a || qw(default values);

   - Damien

Re: RFC 82 (listops in list context)

[Peter Scott]

At 04:02 PM 8/16/00 +1000, Jeremy Howard wrote:
>Nathan Torkington wrote:
> > Your [Jeremy's] RFC says:
> > > Currently, operators applied to lists in a list context behave
> > > counter-intuitively:
> >
> > Counter-intuitively is different from consistently.  Your title is
> > misleading.  Perl's ops *are* applied consistently: they consistently
> > give their arguments scalar context (except for the short-circuiting
> > logops, which I'd like to fix by making them return the useful lists
> > instead of possibly a list or a scalar).
> >
>You're right. If RFC 45 is implemented they would however be inconsistent.

No, || is half-consistent at the moment: the left hand side is forced into 
scalar context but the result context propagates down the right hand 
side.  I challenge anyone to come up with a rationalization for this that 
does not invoke implementation expediency.

>Anyway, I'll change the title in the next version.
>
> > > The proposal to handle functions is tricky, since there is currently no
> > > obvious way to see whether a function is going to return a list. Either
>we
> > > need some kind of more advanced prototyping (or other way of creating a
> > > signature), or we need to manually change functions provided with Perl
>to
> > > check for list context and Do The Right Thing.
> >
> > I assume you're talking about:
> >
> >   @r = func1() + func2();
> >
>No, I'm talking about:
>
>   @r = abs(@r);

I know what you want that to do, and even though I haven't wanted to do 
that since I was writing a 3-D object manipulation program in PerlTk I can 
appreciate the elegance of it; but it just don't read right to me at first 
glance.

This is like trying to define obscenity: some ends of the spectrum are 
pretty clear:

   @a = @b * @c;

clearly reads as matrix multiplication.  This is a 1958 Playboy cover.

   @a = @b ? @c : @d;

Making *that* distributive would be something written on a bathroom wall at 
Venice beach.
In between we have

   @a = @b || @c;

which goes according to taste.  Mebbe a slightly cleaned-up version of 
Flesh Gordon (which has been airing on the Space Channel in Canada, but 
would never see the light of day on the equivalent cable tier in the US).

--
Peter Scott
Pacific Systems Design Technologies

Uses for array notation (was Re: RFC 104 (v1) Backtracking)

[Jeremy Howard]

Mark Cogan wrote:
> At 12:39 PM 8/16/00 +1000, Jeremy Howard wrote:
> >It seems obvious that @a should be the whole array @a, not the size of
the
> >array. If I want to check the size of @a, I should have to do so
explicitly,
> >with scalar or $#.
> >
> >This is non-obvious if you think that || is a flow control statement, so
> >think about * for a moment:
> >
> >   @c = @b * @a;
>
> But, to me at least, arrays aren't something you multiply. Multiplication
> applies to numbers (scalars), and returns a scalar, so when you see
>
> @c = @b * @a
>
> it should be clear that something funny is going on.
>
Well, they're not something you multiply in Perl now. But there's plenty of
languages where you can, and it's ever so convenient.

> And, really, what is wrong with:
>
> @c = map {$a[$_] * $b[$_]} (0..$#a);
>
Numerical programming is all about manipulating arrays (or n-dim tensors,
but they're just order array slices really). Writing such programs in a
language that requires explicit loops is not only a pain, but creates code
that bears no resemblance to the numeric algorithm it's implementing.
Furthermore, it's out of the question in anything other than low-level
languages, because the looping and array dereferencing is much too slow.

It also makes easy things easy:

  @full_names = @first_names . @surnames;

and with the extension to scalars as one operand (coming in v2!):

  @quoted_lines = '> ' . @raw_lines;

or

  @histogram = '#' x @num_recs;
>
> >It's pretty clear what working on 'the whole array' means here, I think.
>
> I disagree. In particular, think of it from the point of view of someone
> who hasn't studied computer science.
>
> What should:
>
> @a = defined @a;
>
> return?
>
defined() is a function. Under the proposed extension of RFC 82 from
operators to functions, this example should return a list of booleans, where
each is true if the corresponding element of the original list was defined.
Under Perl 5.6, 'defined @a' is deprecated. This RFC would give it a useful
meaning (in a list context).

> >Treating || as a special case is asking for trouble. If you want a flow
> >control statement, use one:
> >
> >   @result = @b unless @result = @a;
>
> || may be a suboptimal example, but I think the idea that a @-variable
> without an iteration function refers to the array as a whole, and not its
> elements is an intuitive one, and having array iteration magically happen
> when you're not looking is dangerous.

It seems funny if you're not used to it. But that's because we learn that
lists are hard, and computers have to loop. After just a little unlearning
it actually becomes quite intuitive, and is generally picked up with no
additional trouble by new students. Programmers shouldn't have to know how a
computer implements things behind the scenes--which is really what requiring
explicit looping forces.

Re: Component wise || and RFC 82 (was Re: RFC 104 (v1) Backtracking)

[Damien Neil]

On Tue, Aug 15, 2000 at 10:26:13PM -0600, Nathan Torkington wrote:
> I like the idea of adding the context-aware operators, but I don't
> think I'd use them as often as I use "the number of things in the
> array".  I think most Perl programmers would be in the same camp.
> Unless you can show a couple of cool things that this makes possible,
> that is.
> 
> So I'd say: option, yes.  Default, no.

I also like the idea of context-aware operators.  I don't know if I
like them enough to want to break with former practice, but I do know
that I don't like the idea of making them optional.  This would be
the mother of all action-at-a-distance hells:

  set_size(@elts * 5);   # size = Five times the number of elements.

  set_size(@elts * 5);   # $size = The number of elements -- someone
 # turned on context-sensitive operators,
 # 2000 lines above here.

I don't know what the right thing to do is.  Context is crypto enough
these days, without shifting the rules on operator contexts around.
Perhaps the benefits outweigh the breakage that will occur.

- Damien

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

[Damien Neil]

On Tue, Aug 15, 2000 at 11:46:04PM -0400, Stephen P. Potter wrote:
> Why is it silly?  Hashes and arrays are *conceptually* very similar (even
> if they are extremely different implementation-wise).  One of them has
> implicit key, the other has an explicit key.  They both provide some sort
> of ordered collection (plural), even if it is difficult to understand what
> the order is of hashes.  Seems to me we could eliminate arrays and just
> keep hashes.

Arrays are ordered.  Hashes are not.  Sure, you can iterate over a hash,
but add an element to one and you can change the order of everything in
it.  You are guaranteed that won't happen with an array.

Looking up a value in an array is faster than doing so with a hash.
Appending a value to an array is usually faster than adding an element
to a hash, but inserting elements into the middle of a large array will
generally be slow.

Hashes consume more space than arrays containing the same number of values.

Plenty of other differences.  Sure, most of them are connected to the
implementation and efficiency, not the abstract concept of arrayness and
hashness -- but Perl is a Practical language, and practical programmers
like to know these things.

You can change a lot of these things by twiddling with the internal
implementations, but at the end of the day "ordered set" and "mapping"
are conceptually and practically different beasts.  I don't think there
is any reason for Perl to want to toss away the distinction.

 - Damien

Re: RFC 82 (listops in list context)

[Jeremy Howard]

Nathan Torkington wrote:
> Your [Jeremy's] RFC says:
> > Currently, operators applied to lists in a list context behave
> > counter-intuitively:
>
> Counter-intuitively is different from consistently.  Your title is
> misleading.  Perl's ops *are* applied consistently: they consistently
> give their arguments scalar context (except for the short-circuiting
> logops, which I'd like to fix by making them return the useful lists
> instead of possibly a list or a scalar).
>
You're right. If RFC 45 is implemented they would however be inconsistent.
Anyway, I'll change the title in the next version.

> > The proposal to handle functions is tricky, since there is currently no
> > obvious way to see whether a function is going to return a list. Either
we
> > need some kind of more advanced prototyping (or other way of creating a
> > signature), or we need to manually change functions provided with Perl
to
> > check for list context and Do The Right Thing.
>
> I assume you're talking about:
>
>   @r = func1() + func2();
>
No, I'm talking about:

  @r = abs(@r);

It would be nice if we could see from a function's signature that it did not
provide a list context return, and accepted scalar parameters, so that we
could automatically make this kind of notation 'just work'. Another approach
would be to add explicit context checks into all scalar functions that come
with Perl, and have them behave in this way. This seems a bit Non-Lazy
though...
>
> Can anyone else think of existing code that would break?
>
No, but I'm probably not trying hard enough ;-)

Re: English language basis for "throw"

[Tony Olekshy]

"Stephen P. Potter" wrote:
> 
> I think fail() and handle() are good.  Something fail()ed and
> it was handle()d by an exception.

Fail is no good, because exceptions can be used to indicate success.
Just because you don't isn't a counter-argument.  Exceptions are
*not* the same as errors, that's just one semantic mapping.

Consider the following case.  You've got some complicated algorithm
that doesn't normally succeed in finding an answer.  When it does
find an answer, it can be all over the place, but no matter what,
you want to stop the algorithm and return the answer.

When you succeed, you want to say

throw Exception::MySuccess object => $answer_object;
not
fail  Exception::MySuccess object => $answer_object;

and then invoke the whole algorithm under:

my $answer;

try { my_algorithm; }

catch Exception::MySuccess { $answer = $@->object; }

If my_algorithm finds the answer then $answer contains the answer,
otherwise $answer is undef.  If my_algorithm throws anything but an
Exception::MySuccess (such as an otherwise uncaught internal Perl
error), the statement after the catch is not executed at all.

That's why all the other words with negative connotation are bad
choices for throw.  It's up to the catcher to determine what's good
and what's bad, not the thrower.

The "classical" uses of try/throw/catch/finally have been around
for many years.  During that time, many languages have incorported
the concepts, and after much heat and little light, the terminology.
Could it be that's because, *all* things considered, it is good
terminology?

Consider "finally" vs. "always".  Always?  Even if force majeur?
Finally simply means, "as the final act of the unwind processing".

By the way, this discussion has moved to perl-language-errors, so
the good folks here at perl-language-flow can concentrate on finding
silly words for other Perl flow-control constructs ;-)

Yours, &c, Tony Olekshy

Re: Array storage (was Re: RFC 84 (v1) Replace => (stringifying comma) with =>)

[Jeremy Howard]

Dan Sugalski wrote:
> At 05:55 PM 8/15/00 -0500, Jarkko Hietaniemi wrote:
> > > > > No, neither proposal makes sense. Arrays can be stored compactly
and
> > > >
> > > > $a[1_000_000_000] = 'oh, really?' # :-)
> > > >
> > >   my int @a: sparse;
> >
> >I see: you have a time machine and I don't.  So very unfair...
>
> Need to upgrade to that new machine with the Pentium UltraMegaPro IV 2000
> processor. (Now with thiotimoline! :)
>
> > >   $a[1_000_000_000] = 'Yes, really!' # :P
> > >
> > > OK, so I cheated... I haven't submitted my RFC for a 'sparse'
attribute
> > yet.
> > > My point is that arrays *can* be stored compactly, not that they
always
> >
> >I smell...n-level bitmaps?
>
> Nah, you smell vapor. The shapes in the vapor may well be n-level bitmaps,
> though. (Or possibly hashes with fixed keys optimized for integer key
> hashing for *real* sparse arrays...)
>
The shape and feel of the vapor will be described in the RFC. The actual
chemical makeup of the vapor will not.

Re: RFC 65 (v1) Add change bar functionality to pod

[Nathan Torkington]

[EMAIL PROTECTED] writes:
> I don't think this is a language issue.  However, I don't believe
> there's a -doc working group yet, either.
> 
> Is it time for a -doc group to form?

Not unless there's a significant interest in doc issues, as reflected
in RFCs.

Nat

Re: RFC 104 (v1) Backtracking

[Nathan Torkington]

Jeremy Howard writes:
> It seems obvious that @a should be the whole array @a, not the size of the
> array. If I want to check the size of @a, I should have to do so explicitly,
> with scalar or $#.

It depends.  Which interpretation depends on which action you'll want
most often.

>   @result = @b unless @result = @a;

I think this is much more common than or-ing individual values.  I can
think of many times in my programs where I've written:

  @foo = @a ? @a : @b;

The only time I can think of a distributive || being useful is:

  ($a, $b, $c) ||= ($a_default, $b_default, $c_default);

I think the logops should be special-cased.

That said, given that both have utility, and if no convincing cases of
breakage can be found, I wouldn't mind it too much.  It'd just be
another weird context-dependent thing to explain to students.

Nat
(I seem to have talked myself around 90 degrees :-)

Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument

[Buddha Buck]

> I assume you meant that :lvalue() takes a parameter list.  Either a
> singleton named variable $, @, or %. 

I'm proposing that an lvalue subroutine have access to the rvalue 
assigned through a channel other than the standard argument list @_.  I 
used, as an example, an explicit named parameter to lvalue, but I could 
also see a "line-noise" variable used ($= would be perfect, but it's 
taken).

I'm proposing that that rvalue be passed by perl as a reference instead 
of as a straight $, @, or %.

I'm proposing that subs in lvalue slots that aren't lvalue subs 
generate errors.

I think that that is all I'm proposing now...

By having the rvalue passed through a separate channel, the function 
does not have to worry about wondering which of @_ (if any) is the 
rvalue.  This prevents the confusion some are worried about with the 
idea that the assigned rvalue is simply tacked onto the end.  
Specifically:

$p->name = 'Mithrandir';

would not be directly equivilant to 

$p->name('Mithrandir');

as $p->name() would be able to tell in the first case that it is called 
in lvalue-context, with 'Mithrandir' as an rvalue to assign.  It may be 
that $p->name() uses its first argument as a value to assign, but not 
necessarily.

Consider, for example, $mytensor->index(2,3,4,5,6).  Should that return 
the value of cell[2][3][4][5][6], or should it set cell[2][3][4][5] to 
6?

> Or If it makes sense even a more complex parameter list could be
> demanded.

I don't think that's necessary.  I like the idea of passing the rvalue 
in as a reference because a) references can maintain their own type 
information (as per ref()), and b) the rvalue being passed in as 
"undef" would unambiguously indicate that it was not lvalue context (a 
reference to undef is defined).  Besides, I can't imagine the rvalue 
being multiple things -- an object, yes.  A reference, yes.  An array, 
yes, a hash even.  But not multiple objects, multiple references, 
multiple arrays, or multiple hashes.

> 
> sub foo :lvalue(Dog $fido, int @array, %hash) {}
> 
> foo() = ($name, 0..10, %bar);
> 
> 
> 
> > "BB" == Buddha Buck <[EMAIL PROTECTED]> writes:
> 
> BB> sub foo : lvalue($newval) {
> BB>   # $newval is a lexical scaler in this block, initialised with a 
> BB> reference
> BB>   # to the value to be assigned to $self{foo}
> BB>   my $self = shift;
> BB>   return $self{foo} unless defined $newval; # rvalue context
> BB>   # lvalue context
> BB>   # verify new foo is in correct range
> BB>   return $self{foo} if $$newval < $MINFOO;
> BB>   return $self{foo} if $$newval > $MAXFOO;
> 
> 
> 
> -- 
> Chaim Frenkel  Nonlinear Knowledge, Inc.
> [EMAIL PROTECTED] +1-718-236-0183

-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

RFC 82 (listops in list context)

[Nathan Torkington]

Your RFC says:
> Currently, operators applied to lists in a list context behave
> counter-intuitively:

Counter-intuitively is different from consistently.  Your title is
misleading.  Perl's ops *are* applied consistently: they consistently
give their arguments scalar context (except for the short-circuiting
logops, which I'd like to fix by making them return the useful lists
instead of possibly a list or a scalar).

> The proposal to handle functions is tricky, since there is currently no
> obvious way to see whether a function is going to return a list. Either we
> need some kind of more advanced prototyping (or other way of creating a
> signature), or we need to manually change functions provided with Perl to
> check for list context and Do The Right Thing.

I assume you're talking about:

  @r = func1() + func2();

If so, this isn't a problem.  This code would result in func1 and
func2 being called in list context.  You've got an addition in list
context (thanks to the assignment), and that would put func1() and
func2() into list context.

+ wouldn't look to its arguments to decide what to do.  + would look
at its context.  This would make it behave like reverse().

Note that this context inheritance confuses the bejaysus out of
people, c.f. the bugreports on

  print reverse("is broken");

I did try to come up with some counter-examples, some code where this
new behaviour would make hard something that's currently easy.  The
fact that list context is only really surprising in function calls
eliminated most of them.  The objection I thought I had:

  $matrix_size = @across * @down;

isn't valid because $matrix_size would dictate the current behaviour
for @across and @down.  However:

  print "You'll need ", @across*@down, " cells.\n";

would break.

Can anyone else think of existing code that would break?

Nat

Re: RFC 82 (scalar ops consistent in list context)

[Nathan Torkington]

Chaim Frenkel writes:
> You are missing the beauty of vector/matrix operations. The math folks
> really would like to be able to describe the operation wanted and have
> perl do the optimization.

Fine, but make it an option.

> Would adding another character be helpful
> 
>   @result = @a x|| @b?
>   @result = @a ||| @b?

No.  Triple-punctuation operators are scary, says Python Barbie.
We have a lot of operators.  Matrix multiplication et al is *not*
a convincing excuse to add more.

Modifiers also miss the point.  How can matrix ops and regular ops be
in the same language?  Both are useful, but in different situations.
How about:

  use matrix_ops;

to enable this 'consistent' behaviour of the binary ops in list
context?

Nat

Re: Component wise || and RFC 82 (was Re: RFC 104 (v1) Backtracking)

[Nathan Torkington]

Jeremy Howard writes:
> Note that RFC 82 (http://tmtowtdi.perl.org/rfc/82.pod) proposes that _all_
> operators behave the same way in a list context. To me, this consistancy
> would be a real win.

I don't know.  Perl has been all for breaking consistency when it made
the programmer's life easier, and || is definitely one of those cases.

The RFC would break:
  $num_stories = @characters * @plots;  # scalar context
in favour of:
  @totals  = @raw * @weights;   # implicit loop

Right now, Perl's logops *are* consistent when applied to arrays.
They're consistent with respect to the rule that they give scalar
context to their operands (left-operand only with the boolean ops).

I like the idea of adding the context-aware operators, but I don't
think I'd use them as often as I use "the number of things in the
array".  I think most Perl programmers would be in the same camp.
Unless you can show a couple of cool things that this makes possible,
that is.

So I'd say: option, yes.  Default, no.

Nat

list changes: perl6-language-objects added, perl6-language-unlinkclosed

[Ask Bjoern Hansen]

Subscribe by sending mail to
[EMAIL PROTECTED]

More details at http://dev.perl.org/lists.shtml

LIST:   perl6-language-objects
CHAIR:  Nathan Wiger <[EMAIL PROTECTED]>
MISSION:Develop RFCs related to objects and OO programming in
Perl, possibly rationalising existing RFCs where they
cover the same ground.
DEADLINE:   As long as it takes.  Report fortnightly (first report
August 29th).


 - ask

-- 
ask bjoern hansen - 
more than 70M impressions per day, 

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

[Nathan Torkington]

Stephen P. Potter writes:
> Why is it silly?  Hashes and arrays are *conceptually* very similar
> (even if they are extremely different implementation-wise).

If that were the case, I think students would have an easier time
grasping hashes.  It seems very common (yes yes, you all got them
immediately, but merely by piping up and saying so, you do not
invalidate my point, so please don't) that beginners take a long time
to use hashes because they find them hard to get their heads around.

This isn't why it's silly, just a comment on the idea that hashes
and arrays are conceptually very similar.

> # Same thing, using explicit
> %hash = (fn => "Bob", ln => "Smith", 0 => 10, 1 => 15, age => 35);

I have never wanted this kind of structure.  It seems a ridiculous
data structure to want.  Keys are almost always heterogeneous in my
world.  I like Perl being able to optimize internally based on my
simple one-character data typing (%).

What are you trying to make easy with this?

Nat

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

[Buddha Buck]

Chaim Frenkel said:
> BB> Unfortunately, the valid range of time supported is easily determined, 
> BB> and disturbingly short:
> 
> BB> Into the future:  to next December 31st or June 30th, whichever is 
> BB> closer.
> BB> Into the past  :  to past January  1st  or July  1st, whichever is 
> BB> closer.
> 
> Sorry, this makes no sense.

I am assuming that the system clocks are set accurately to UTC (or some 
derivative, like (US) Eastern Standard Time).  UTC is what time-servers 
report. UTC has leap seconds, which are inserted (or, theoretically, 
deleted) at the end of December 31st and June 30th, as needed.

This means that 86400 seconds (one day) after 2000 Dec 31, 12:00:00 UTC 
is not necessarily 2001 Jan 1, 12:00:00 -- it could be 11:59:59 or 
12:00:01 as well.  And there is no way to know that ahead of time.

Any attempt to convert from a time-from-epoch representation to a 
date-time representation has to deal with leap seconds, or it's not 
computing UTC.  MJD, for instance, is specifically not supposed to work 
with UTC, because of leap seconds (it's based on UT, which doesn't have 
leap seconds).

What happens on UNIX systems is that localdate() ignores leapseconds, 
and as such there is a slow, subtle skewing of when the epoch is 
(relative to UTC) -- a skewing that is time-dependent.  A timestamp 
made in mid-1990 has a different epoch (00:00:15 UTC 1 Jan 1970) than a 
timestamp made in early 1999 (00:00:22).  Most people ignore this 
skewing, and get away with it.  After all, it is a little less than one 
second/year.  But it is still there.

> 
> BB> Leap-seconds are a PITA for generic time routines.
> 
> Why?

Because they are inserted in a non-deterministic way.

According to httP//tycho.usno.navy.mil/leapsec.html, the Bureau 
International des Poids et Mesures (BIPM) recommends that systems which 
cannot handle leapseconds use TAI (International Atomic Time) instead.

If we have to pick and epoch in an OS-neutral way, I think I for one 
would be happy with something like this in the docs for the time 
functions:


All date and time functions, unless otherwise documented, assume the 
use of the International Atomic Time (TAI) timescale. TAI differs from 
standard time (UTC) in that TAI does not have "leapseconds".

It is likely that the OS clock was set to UTC, not TAI.  This slight 
difference (22 seconds as of 2000) should not cause any problems unless 
date computations of over 6-months with second accuracy are needed.

time() returns the number of seconds elapsed since the beginning of the 
International Atomic Time (TAI) timescale, 00:00:00 UTC 1 January 1958.

date($) returns a year-month-day-hour-minute-second representation of 
the time passed to it (in seconds since the TAI epoch).  The 
representation assumes the TAI timescale.
-

> 
> 
> 
> -- 
> Chaim Frenkel  Nonlinear Knowledge, Inc.
> [EMAIL PROTECTED] +1-718-236-0183

-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

[Nathan Torkington]

(Reply-to set to -datetime list)

Chaim Frenkel writes:
> NT> Epoch seconds are a convenient representation for dates and times.
> NT> Varying epochs make it an unreliable representation when data are
> NT> shared.  A consistent epoch would fix this.
> 
> Sorry, I don't buy that. Not every program will be perl.

Bogus argument.  This is a non-issue.  I'm talking about it being
easy to run the same program on different platforms but share data.
Optimize for Perl.

> The only valid interchange would be to specify the date unambiguously,
> for example the ISO   MMDDHHMMSS.fff

This is good for comparison but bad for math.  Epoch seconds are
good for both.  That's why *I* use them.  You can continue to use
ISO mumble and have it work for you.  I'm not breaking your code.

There's also the issue that Perl code should (where practical) be
portable by default.  Perl tries to cover up operating system
oddities.  This is one oddity that can (and, I think, should) be
covered up.

Nat

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

[Nathan Torkington]

NOTICE: reply-to set to the -language-datetime list.

Ted Ashton writes:
> Well then, why 1970?  If we're defining our own, why buy into one
> which is scheduled to blow up in 2038?  Why not at the very least
> start with Jan 1, 2K?

This works, provided epoch seconds are stored in some form of big
integers (either arbitrary precision, or 64-bit).  The epoch change
would then be fine by me.  But epoch changes don't solve the 2038
problem, Unix already tried that before the move to 32-bit integers
(they moved the epoch from 1970 to 1971, I think, when their previous
size of integer was about to run out of space, then when it ran out
again next year they said "yeah, ok, wrong solution" :-). 

Nat

Re: RFC 104 (v1) Backtracking

[Mark Cogan]

At 11:05 PM 8/15/00 -0500, Jonathan Scott Duff wrote:
>On Tue, Aug 15, 2000 at 08:59:25PM -0700, Mark Cogan wrote:
> > At 11:43 PM 8/15/00 -0400, Chaim Frenkel wrote:
> > >Counter example:@a = \($a, $b, $c);
> >
> > I guess I'm missing the point; how is this different from
> >
> > @a = [$a,$b,$c];
>
>Well, I've lost the point of this thread, but
>
> @a = \($a, $b, $c);
>
>is equivalent to
>
> @a = (\$a, \$b, \$c);
>
>rather than what you wrote.

Ah, so it is. I'd argue that that's broken and should be handled with map 
or for.
---
Mark Cogan[EMAIL PROTECTED] +1-520-881-8101 
ArtToday  www.arttoday.com

Re: RFC 90 (v1) Builtins: zip() and unzip()

[Stephen P. Potter]

Lightning flashed, thunder crashed and "Jeremy Howard" <[EMAIL PROTECTED]> whispered:
| @unzipped_list2 should not be([X,Y,Z], [A,B,C], [M]). The RFC's proposed
| behaviour makes it work as the inverse of zip(), which is the desired
| behaviour.

The reason I used letters instead of the actual values is because I
couldn't make it make any sense when it meant the length of each list.
When it means the number of lists to break into, ([1,4,7], [2,5], [3,6])
makes perfect sense.

-spp

Re: RFC 104 (v1) Backtracking

[Jonathan Scott Duff]

On Tue, Aug 15, 2000 at 08:59:25PM -0700, Mark Cogan wrote:
> At 11:43 PM 8/15/00 -0400, Chaim Frenkel wrote:
> >Counter example:@a = \($a, $b, $c);
> 
> I guess I'm missing the point; how is this different from
> 
> @a = [$a,$b,$c];

Well, I've lost 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]

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

[Jonathan Scott Duff]

On Tue, Aug 15, 2000 at 11:17:16PM -0400, Chaim Frenkel wrote:
> Sorry, I don't buy that. Not every program will be perl. Plus you are
> assuming that epoch seconds are good everywhere. And even if it were
> why should any other program use the same epoch.

Well, we're not talking about *every* program...just those written in
Perl.  And epoch seconds *are* good everywhere if we make them good in
Perl.

> The only valid interchange would be to specify the date unambiguously,
> for example the ISO   MMDDHHMMSS.fff

That's an interface problem where perl meets the rest of the world.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: RFC 104 (v1) Backtracking

[Mark Cogan]

At 11:43 PM 8/15/00 -0400, Chaim Frenkel wrote:
> > "MC" == Mark Cogan <[EMAIL PROTECTED]> writes:
>
>MC> What should:
>MC> @a = defined @a;
>MC> return?
>
>Counter example:@a = \($a, $b, $c);

I guess I'm missing the point; how is this different from

@a = [$a,$b,$c];

which works to be the same as

push @a, [$a,$b,$c];

?

[]

>MC> || may be a suboptimal example, but I think the idea that a @-variable
>MC> without an iteration function refers to the array as a whole, and not its
>MC> elements is an intuitive one, and having array iteration magically happen
>MC> when you're not looking is dangerous.
>
>Not unless you are coming from a math background or are an old basic
>programmer, and would like to have matrix operations built in.

But we're trying to decide what is best for perl as a whole, not just what 
is good for math people who use perl. I don't think that the requirement 
that a relatively small portion of the user base put :

use magical_array_iteration;

at the top of their code is too outre.

(and, for that matter, it might be nice to have an environment variable 
that implicitly sets -M command line options in the same way that PER5LIB 
sets -I. That way, math types can just set their perls to preload all the 
modules they want.)

---
Mark Cogan[EMAIL PROTECTED] +1-520-881-8101 
ArtToday  www.arttoday.com

Re: English language basis for "throw"

[Stephen P. Potter]

Lightning flashed, thunder crashed and Dan Sugalski <[EMAIL PROTECTED]> whispered:
| At 04:03 PM 8/15/00 -0500, Jarkko Hietaniemi wrote:
| > > open, you fall through, someimes through several floors, until somewhere
| > > you encounter a safety net: you were caught. You can continue from
| > > there. If there was no safety net, you keep falling, well, into the
| > > water, out of the castle (er, "program".)
| >
| >Hmmm...trip() and trap()?  fail() and deal()?
| 
| freak() (or panic) and cope().

I think fail() and handle() are good.  Something fail()ed and it was
handle()d by an exception.

-spp

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

[Stephen P. Potter]

Lightning flashed, thunder crashed and Dan Sugalski <[EMAIL PROTECTED]> whispered:
| > > Doesn't it make more sense to get rid of arrays and just use hashes?
| >
| >I guess it depends on what you think makes sense; but it seems to me
| >that an array is a more fundamental data type; that it's easier (i.e.
| >more efficient) to build associative arrays from arrays, than vice versa.
| 
| It's silly to throw either of them out. Perl might be many things, but a 
| reductionist language it ain't...

Why is it silly?  Hashes and arrays are *conceptually* very similar (even
if they are extremely different implementation-wise).  One of them has
implicit key, the other has an explicit key.  They both provide some sort
of ordered collection (plural), even if it is difficult to understand what
the order is of hashes.  Seems to me we could eliminate arrays and just
keep hashes.  We could promote "=>" to be a key/value constructor while
elements that don't have the "=>" use a sequential number.  Think of it
like this:

# Example "array"
%array = qw/foo bar blah blech/;
# Same thing, but explicit, a hash
%array = (0 => "foo", 1 => "bar, 2 => "blah", 3 => "blech");
# A combination using implicit values
%hash = (fn => "Bob", ln => "Smith", 10, 15, age => 35);
# Same thing, using explicit
%hash = (fn => "Bob", ln => "Smith", 0 => 10, 1 => 15, age => 35);

-spp

Re: RFC 104 (v1) Backtracking

[Chaim Frenkel]

> "MC" == Mark Cogan <[EMAIL PROTECTED]> writes:

MC> What should:
MC> @a = defined @a;
MC> return?

Counter example:@a = \($a, $b, $c);

(Not really a full fledged counter example since it is a liter list.)

>> Treating || as a special case is asking for trouble. If you want a flow
>> control statement, use one:
>> 
>> @result = @b unless @result = @a;

MC> || may be a suboptimal example, but I think the idea that a @-variable 
MC> without an iteration function refers to the array as a whole, and not its 
MC> elements is an intuitive one, and having array iteration magically happen 
MC> when you're not looking is dangerous.

Not unless you are coming from a math background or are an old basic 
programmer, and would like to have matrix operations built in.


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

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Dan Sugalski]

At 10:28 PM 8/15/00 -0400, Ted Ashton wrote:
>I don't know for sure what Perl's main goal is, but it's definitely 
>significant to Perl to make life easier and it has done that.

It seems to be the language to Fix Things That Annoy Us. :) Or so it's 
always seemed to me. (And it seems to be the driving force behind a lot of 
the stuff in perl...)


Dan

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

Re: Array storage (was Re: RFC 84 (v1) Replace => (stringifying comma) with =>)

[Dan Sugalski]

At 05:55 PM 8/15/00 -0500, Jarkko Hietaniemi wrote:
> > > > No, neither proposal makes sense. Arrays can be stored compactly and
> > >
> > > $a[1_000_000_000] = 'oh, really?' # :-)
> > >
> >   my int @a: sparse;
>
>I see: you have a time machine and I don't.  So very unfair...

Need to upgrade to that new machine with the Pentium UltraMegaPro IV 2000 
processor. (Now with thiotimoline! :)

> >   $a[1_000_000_000] = 'Yes, really!' # :P
> >
> > OK, so I cheated... I haven't submitted my RFC for a 'sparse' attribute 
> yet.
> > My point is that arrays *can* be stored compactly, not that they always
>
>I smell...n-level bitmaps?

Nah, you smell vapor. The shapes in the vapor may well be n-level bitmaps, 
though. (Or possibly hashes with fixed keys optimized for integer key 
hashing for *real* sparse arrays...)

Dan

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

Re: Default filehandles(was Re: command line option: $|++)

[Jonathan Scott Duff]

On Tue, Aug 15, 2000 at 06:53:30PM -0400, Chaim Frenkel wrote:
> What if you want to print to a default file handle and also to STDOUT?
> 
>   select(OTHERFH);
>   print "This goest to OTHERFH\n";
>   print STDOOUT "This went to STDOUT\n";

print $_ "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]

Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument

[Chaim Frenkel]

I assume you meant that :lvalue() takes a parameter list.  Either a
singleton named variable $, @, or %. 

Or If it makes sense even a more complex parameter list could be
demanded.

sub foo :lvalue(Dog $fido, int @array, %hash) {}

foo() = ($name, 0..10, %bar);



> "BB" == Buddha Buck <[EMAIL PROTECTED]> writes:

BB> sub foo : lvalue($newval) {
BB>   # $newval is a lexical scaler in this block, initialised with a 
BB> reference
BB>   # to the value to be assigned to $self{foo}
BB>   my $self = shift;
BB>   return $self{foo} unless defined $newval; # rvalue context
BB>   # lvalue context
BB>   # verify new foo is in correct range
BB>   return $self{foo} if $$newval < $MINFOO;
BB>   return $self{foo} if $$newval > $MAXFOO;



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

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

[Jonathan Scott Duff]

On Tue, Aug 15, 2000 at 10:38:23PM -0400, Ted Ashton wrote:
> Well then, why 1970?  If we're defining our own, why buy into one which is 
> scheduled to blow up in 2038?  Why not at the very least start with Jan 1, 2K?

Um, it's not guaranteed to blow up in 2038.  That's an 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]

Re: command line option: $|++

[Chaim Frenkel]

> "s" == skud  <[EMAIL PROTECTED]> writes:

s> Command line options aren't really a language issue, however I'm not
s> sure that there is a better list for them.  Anyone on bootstrap got any
s> good ideas?

shove it over onto -internals.

They will have to implement it anyway.

The only other choice would be to start a -environment (or some such)
list, but I don't think there will be that much traffic.

Actually, it might be appropriate for horos(?) complaint list.

(How's that coming along?)


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

Re: RFC 104 (v1) Backtracking

[Jonathan Scott Duff]

On Wed, Aug 16, 2000 at 08:54:28AM +1000, Damian Conway wrote:
>> As I understand things:
>> 
>>  BLOCK1 andthen BLOCK2
>> 
>> evaluates BLOCK1 and then if BLOCK1 evaluates to "true" evaluates
>> BLOCK2.  If BLOCK2 evaluates to "true" we're done.  If BLOCK2
>> evaluates to "false", then BLOCK1 is re-evaluated. 
> 
> So how is that different from:
> 
>   do BLOCK1 until do BLOCK2

I guess it's not, but you can't (currently) chain those together like
so:

do BLOCK1 until do BLOCK2 until do BLOCK3 until do BLOCK4

Yes, I know this can be implemented in today's perl, but I think the
gist of the RFC is to provide the syntactic shorthand.  Perhaps this is
so special purpose that it should be in a module.

There's also the cut operator which 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]

Re: RFC 104 (v1) Backtracking

[Mark Cogan]

At 11:11 PM 8/15/00 -0400, Chaim Frenkel wrote:
>You are missing the beauty of vector/matrix operations.

No, I'm not; I'm opining that the vast majority of Perl users don't need to 
do vector/matrix ops, and that they don't belong in the core.


>The math folks
>really would like to be able to describe the operation wanted and have
>perl do the optimization.

Then maybe they should use a dedicate math extension to Perl, like PDL.

>Would adding another character be helpful
>
> @result = @a x|| @b?
>
> @result = @a ||| @b?
>
>or perhaps a modifier?
>
> @result = @a || @b forall;
>
>(Blech, that just doesn read right.)

Perhaps we just need a two-list map, which aliases $a and $b like sort():

@result = map {$a || $b} @a,@b;



---
Mark Cogan[EMAIL PROTECTED] +1-520-881-8101 
ArtToday  www.arttoday.com

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

[Chaim Frenkel]

> "RA" == Russ Allbery <[EMAIL PROTECTED]> writes:

RA> Buddha Buck <[EMAIL PROTECTED]> writes:
>> Leap-seconds are a PITA for generic time routines.

RA> Unix time ignores leap seconds.  POSIX basically says "don't worry about
RA> them" and by and large that works.  It means your system clock drifts a
RA> little over time and then gets corrected back by xntpd or something, but
RA> in practice time on a Unix clock is monotonic.

Hmm, that means, some seconds were really 2x as long as others.



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

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

[Chaim Frenkel]

> "BB" == Buddha Buck <[EMAIL PROTECTED]> writes:

>> Why? What is the gain? Perl only runs on the local machine.
>> 
>> As long as one can increment and take the difference what difference
>> does the epoch make?
>> 
>> What is of more interest would be knownig the valid range of time
>> supported on each platform. Even if you standardize the epoch, the
>> platform may be unable to calculate to the epoch.

BB> Unfortunately, the valid range of time supported is easily determined, 
BB> and disturbingly short:

BB> Into the future:  to next December 31st or June 30th, whichever is 
BB> closer.
BB> Into the past  :  to past January  1st  or July  1st, whichever is 
BB> closer.

Sorry, this makes no sense.

BB> Leap-seconds are a PITA for generic time routines.

Why?



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

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

[Chaim Frenkel]

> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:

NT> Chaim Frenkel writes:
>> Why? What is the gain? Perl only runs on the local machine.

NT> Epoch seconds are a convenient representation for dates and times.
NT> Varying epochs make it an unreliable representation when data are
NT> shared.  A consistent epoch would fix this.

Sorry, I don't buy that. Not every program will be perl. Plus you are
assuming that epoch seconds are good everywhere. And even if it were
why should any other program use the same epoch.

The only valid interchange would be to specify the date unambiguously,
for example the ISO MMDDHHMMSS.fff


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

Re: RFC 104 (v1) Backtracking

[Chaim Frenkel]

You are missing the beauty of vector/matrix operations. The math folks
really would like to be able to describe the operation wanted and have
perl do the optimization.

Would adding another character be helpful

@result = @a x|| @b?

@result = @a ||| @b?

or perhaps a modifier?

@result = @a || @b forall;

(Blech, that just doesn read right.)



> "MC" == Mark Cogan <[EMAIL PROTECTED]> writes:

MC> At 05:47 PM 8/15/00 -0600, Nathan Torkington wrote:
>> Jeremy Howard writes:
>> >   @result = @a || @b;
>> >
>> > Which applies '||' component-wise to elements of @a and @b, placing the
>> > result in @result.
>> 
>> *Ptui*  That's not how *I* want || to behave on lists/arrays.
>> 
>> I want
>> @result  = @a || @b;
>> to be like:
>> (@result = @a) or (@result = @b);
>> 
>> That's what all my students keep expecting it to mean.

MC> Seconded.

MC> It seems obvious that @a should be the whole array @a, not an iteration 
MC> over its elements. If I want to iterate over @a, I should have to do so 
MC> explicitly, with a for() or map().





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

Re: command line option: $|++

[skud]

Command line options aren't really a language issue, however I'm not
sure that there is a better list for them.  Anyone on bootstrap got any
good ideas?

K.

-- 
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949  Fax: +61 3 9614 0948  Mobile: +61 410 664 994

Re: English language basis for "throw"

[skud]

Please take this discussion to the new -errors sublist.  Thanks in
advance!

K.


-- 
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949  Fax: +61 3 9614 0948  Mobile: +61 410 664 994

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

[skud]

On Tue, Aug 15, 2000 at 08:03:44PM -, Perl6 RFC Librarian wrote:
>=head1 TITLE
>
>Standardize ALL Perl platforms on UNIX epoch
>
>=head1 VERSION
>
>  Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
>  Date: 14 Aug 2000
>  Last-Modified: 15 Aug 2000
>  Version: 2
>  Mailing List: [EMAIL PROTECTED]
>  Number: 99
>  Status: Developing

Please discuss this RFC on the datetime sublist.  Thanks in advance :)

K.

-- 
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949  Fax: +61 3 9614 0948  Mobile: +61 410 664 994

Re: use strict

[skud]

On Tue, Aug 15, 2000 at 07:12:08AM -0700, Syloke Soong wrote:
>Yes it should be
>use strict qw(..);
>
>It would be wonderful if someone could invest in an RFC or two to propose the use of 
>strict. 
>I didn't intend to propose the use of such terms. I simply needed to put a handle on 
>some things.
>- primitive data types; I used char, varchar, int, double as an SQL addict.
>- const or constant or whatever

This discussion should be happening on perl6-language-strict, please,
not on the main language list.

K.

-- 
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949  Fax: +61 3 9614 0948  Mobile: +61 410 664 994

Re: RFC 104 (v1) Backtracking

[Mark Cogan]

At 12:39 PM 8/16/00 +1000, Jeremy Howard wrote:
>Mark Cogan wrote:
> > At 05:47 PM 8/15/00 -0600, Nathan Torkington wrote:
> > >Jeremy Howard writes:
> > > >   @result = @a || @b;
> > > >
> > > > Which applies '||' component-wise to elements of @a and @b, placing
>the
> > > > result in @result.
> > >
> > >*Ptui*  That's not how *I* want || to behave on lists/arrays.
> > >
> > >I want
> > >   @result  = @a || @b;
> > >to be like:
> > >   (@result = @a) or (@result = @b);
> > >
> > >That's what all my students keep expecting it to mean.
> >
> > Seconded.
> >
> > It seems obvious that @a should be the whole array @a, not an iteration
> > over its elements. If I want to iterate over @a, I should have to do so
> > explicitly, with a for() or map().
>
>It seems obvious that @a should be the whole array @a, not the size of the
>array. If I want to check the size of @a, I should have to do so explicitly,
>with scalar or $#.
>
>This is non-obvious if you think that || is a flow control statement, so
>think about * for a moment:
>
>   @c = @b * @a;

But, to me at least, arrays aren't something you multiply. Multiplication 
applies to numbers (scalars), and returns a scalar, so when you see

@c = @b * @a

it should be clear that something funny is going on.

And, really, what is wrong with:

@c = map {$a[$_] * $b[$_]} (0..$#a);

?

(or, for that matter:

push @c, $a[$_] * $b[$_] for (0..$#a);

)

in both cases it's clear that you're iterating over the elemnts in the array.

>It's pretty clear what working on 'the whole array' means here, I think.

I disagree. In particular, think of it from the point of view of someone 
who hasn't studied computer science.

What should:

@a = defined @a;

return?

>Treating || as a special case is asking for trouble. If you want a flow
>control statement, use one:
>
>   @result = @b unless @result = @a;

|| may be a suboptimal example, but I think the idea that a @-variable 
without an iteration function refers to the array as a whole, and not its 
elements is an intuitive one, and having array iteration magically happen 
when you're not looking is dangerous.

---
Mark Cogan[EMAIL PROTECTED] +1-520-881-8101 
ArtToday  www.arttoday.com

Re: RFC 104 (v1) Backtracking

[Jeremy Howard]

Mark Cogan wrote:
> At 05:47 PM 8/15/00 -0600, Nathan Torkington wrote:
> >Jeremy Howard writes:
> > >   @result = @a || @b;
> > >
> > > Which applies '||' component-wise to elements of @a and @b, placing
the
> > > result in @result.
> >
> >*Ptui*  That's not how *I* want || to behave on lists/arrays.
> >
> >I want
> >   @result  = @a || @b;
> >to be like:
> >   (@result = @a) or (@result = @b);
> >
> >That's what all my students keep expecting it to mean.
>
> Seconded.
>
> It seems obvious that @a should be the whole array @a, not an iteration
> over its elements. If I want to iterate over @a, I should have to do so
> explicitly, with a for() or map().

It seems obvious that @a should be the whole array @a, not the size of the
array. If I want to check the size of @a, I should have to do so explicitly,
with scalar or $#.

This is non-obvious if you think that || is a flow control statement, so
think about * for a moment:

  @c = @b * @a;

It's pretty clear what working on 'the whole array' means here, I think.
Treating || as a special case is asking for trouble. If you want a flow
control statement, use one:

  @result = @b unless @result = @a;

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

[Ted Ashton]

Thus it was written in the epistle of Nathan Torkington,
> Chaim Frenkel writes:
> > Why? What is the gain? Perl only runs on the local machine.
> 
> Epoch seconds are a convenient representation for dates and times.
> Varying epochs make it an unreliable representation when data are
> shared.  A consistent epoch would fix this.

Well then, why 1970?  If we're defining our own, why buy into one which is 
scheduled to blow up in 2038?  Why not at the very least start with Jan 1, 2K?

Ted
-- 
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
  ==   
God ever arithmetizes.
-- Jacobi, Carl
  ==   
 Deep thoughts to be found at http://www.southern.edu/~ashted

Re: RFC 104 (v1) Backtracking

[Jonathan Scott Duff]

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
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Ted Ashton]

Thus it was written in the epistle of Russ Allbery,
> 
> This falls firmly in the category of things that are powerful for
> experienced users of the language but may be somewhat difficult to learn.
> I don't think Perl has being easy to learn as it's primary goal, nor
> should it.

Russ,
  Would mind saying that again?  It's been said much too seldom around here
and it's really refreshing to heard it put into works.

  Being easy to learn is not Perl's main goal.
 
That goes in with
 
  Being a perfect CS language is not Perl's main goal.

I don't know for sure what Perl's main goal is, but it's definitely significant
to Perl to make life easier and it has done that.  The prefixes and context
sensitivity make Perl easier to read and to write and the fact that it makes
better use of the entire printable set is an asset and not otherwise :-).  



I had a long discussion on another list with folks who were preaching that
regexen were good because they were really powerful despite being difficult to
read.  I say that they don't have to be difficult to read.  They're a language
just like everything else.  How long did it take before you could read your
native language?  Years.  But it doesn't seem so difficult now.  Why do folks
feel that if they have to put out a little effort to learn something that it's
a horrible thing?  



Ted
-- 
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern Adventist University
  ==   
It is true that Fourier had the opinion that the principal aim of
mathematics was public utility and explanation of natural phenomena; but a
philosopher like him should have known that the sole end of science is the
honor of the human mind, and that under this title a question about numbers
is worth as much as a question about the system of the world.
-- Jacobi, Carl
  ==   
 Deep thoughts to be found at http://www.southern.edu/~ashted

Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument

[Buddha Buck]

> Damian Conway wrote:
> > 
> >> Now, if this is what you want, add a :readonly attribute:
> > 
> > So the proposal is: make the dangerous one the default.
> > I don't think that's a good idea.
> 
> You're going to have to explain to me how these differ in their
> dangerousness:
> 
>$r->func = $x; # this more dangerous
>$r->func($x);  # than this somehow?
> 
> I know that the current implementation of :lvalue subs is broken.
> However, if this is fixed and $x is just a regular argument (so that the
> two examples above are equivalent in every way), then it seems there is
> no difference.

As an alternative, I'd rather see something like:

package Foo;

sub new {
  my %foo = (foo => 0, bar => 0, bat => 0);
}

sub foo : lvalue($newval) {
  # $newval is a lexical scaler in this block, initialised with a 
reference
  # to the value to be assigned to $self{foo}
  my $self = shift;
  return $self{foo} unless defined $newval; # rvalue context
  # lvalue context
  # verify new foo is in correct range
  return $self{foo} if $$newval < $MINFOO;
  return $self{foo} if $$newval > $MAXFOO;

  # invarient:  foo == phi*bar == phi*phi*bat
  $self{foo} = $$newval;
  $self{bar} = $self{foo} / $PHI;
  $self{bat} = $self{bar} / $PHI;
  
  return $self{foo};
}
sub bar {
  $self{bar};
}
sub bat {
  return $self{bat};
}

package main;

$myfoo = Foo::new();
$myfoo->foo = 1;
print "(foo,bar,bat) = ($myfoo->foo,$myfoo->bar,$myfoo->bat)\n";
   # prints "(foo,bar,bat) = (1,1.6180339887,2.6180339887)
print 1/$myfoo->bar; #prints "0.6180339887"
$myfoo->bar = 2;  #error -- $myfoo->bar is not an lvalue

Does that example make sense?
-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

[Russ Allbery]

Buddha Buck <[EMAIL PROTECTED]> writes:

> Leap-seconds are a PITA for generic time routines.

Unix time ignores leap seconds.  POSIX basically says "don't worry about
them" and by and large that works.  It means your system clock drifts a
little over time and then gets corrected back by xntpd or something, but
in practice time on a Unix clock is monotonic.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument

[Nathan Torkington]

Nathan Wiger writes:
> > So the proposal is: make the dangerous one the default.
> > I don't think that's a good idea.
> 
> You're going to have to explain to me how these differ in their
> dangerousness:

Nathan, you misunderstand Damian.  What's dangerous is making every
subroutine lvaluable.  He's all for making lvaluable subroutines work
intelligently is one thing.  He thinks it's not a good idea to make
all subs lvaluable.

Not every subroutine corresponds to a method call exposing
object-internal data.  Most of my subroutines *do* something and make
no sense to be called lvaluably.  Explicit marking the compiler pick
up assignments to non-lvaluable subroutines.  It makes sense to
explicitly mark the rare cases (:lvalue), rather than the common
(:no_assignment).

Nat

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

[Tim Jenness]

On Tue, 15 Aug 2000, Buddha Buck wrote:

> Leap-seconds are a PITA for generic time routines.
> 

Not really. They don't happen very often so you simply have a subroutine
that has them all (this is how SLALIB does it). The pain is that you have
to release a new version of perl each time a new leap second is added :-)

-- 
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

[Nathan Torkington]

Chaim Frenkel writes:
> Why? What is the gain? Perl only runs on the local machine.

Epoch seconds are a convenient representation for dates and times.
Varying epochs make it an unreliable representation when data are
shared.  A consistent epoch would fix this.

Nat

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

[Buddha Buck]

> Why? What is the gain? Perl only runs on the local machine.
> 
> As long as one can increment and take the difference what difference
> does the epoch make?
> 
> What is of more interest would be knownig the valid range of time
> supported on each platform. Even if you standardize the epoch, the
> platform may be unable to calculate to the epoch.

Unfortunately, the valid range of time supported is easily determined, 
and disturbingly short:

Into the future:  to next December 31st or June 30th, whichever is 
closer.
Into the past  :  to past January  1st  or July  1st, whichever is 
closer.

Leap-seconds are a PITA for generic time routines.


> 
> 
> 
-- 
 Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: RFC 105 (v1) Downgrade or remove "In string @ must be \@"error

[Nathan Torkington]

Peter Scott wrote:
> I have often wished that digraphs were not bundled with variables in this
> respect, i.e., I wanted to put a string containing \n inside single quotes
> just 'cuz it didn't contain variables to be interpolated.  Whether there's
> a way of improving this behavior or not I don't know.

How odd, I've only very rarely needed this.  I don't mind the extra
typing in the few situations it has come up.  I'd rather the extra
typing than YAQO (yet another quoting operator).

Nat

Re: RFC 104 (v1) Backtracking

[Mark Cogan]

At 05:47 PM 8/15/00 -0600, Nathan Torkington wrote:
>Jeremy Howard writes:
> >   @result = @a || @b;
> >
> > Which applies '||' component-wise to elements of @a and @b, placing the
> > result in @result.
>
>*Ptui*  That's not how *I* want || to behave on lists/arrays.
>
>I want
>   @result  = @a || @b;
>to be like:
>   (@result = @a) or (@result = @b);
>
>That's what all my students keep expecting it to mean.

Seconded.

It seems obvious that @a should be the whole array @a, not an iteration 
over its elements. If I want to iterate over @a, I should have to do so 
explicitly, with a for() or map().
---
Mark Cogan[EMAIL PROTECTED] +1-520-881-8101 
ArtToday  www.arttoday.com

Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument

[Nathan Wiger]

Damian Conway wrote:
> 
>> Now, if this is what you want, add a :readonly attribute:
> 
> So the proposal is: make the dangerous one the default.
> I don't think that's a good idea.

You're going to have to explain to me how these differ in their
dangerousness:

   $r->func = $x; # this more dangerous
   $r->func($x);  # than this somehow?

I know that the current implementation of :lvalue subs is broken.
However, if this is fixed and $x is just a regular argument (so that the
two examples above are equivalent in every way), then it seems there is
no difference.

Isn't that the goal of the RFC? To fix lvalue subs so they work just
like regular subs? That's what I read it as:

> It is proposed that lvalue subs should be called with the rvalue
> passed as a regular argument.  Thus,
>
>$p->name = 'Mithrandir';
>
> would be directly equivalent to
>
>$p->name('Mithrandir');

Note the part that says "directly equivalent".

If the two are really made equivalent there can't be any difference
between them by definition. At that point I think :lvalue should go
away, since it would be superfluous.

Does what I'm getting at make sense?

Now whether :readonly or :constant or some other modifier, which adds a
different meaning here (inability to pass in @_), is added is probably a
separate issue.

-Nate

Component wise || and RFC 82 (was Re: RFC 104 (v1) Backtracking)

[Jeremy Howard]

Nathan Torkington wrote:
> Jeremy Howard writes:
> >   @result = @a || @b;
> >
> > Which applies '||' component-wise to elements of @a and @b, placing the
> > result in @result.
>
> *Ptui*  That's not how *I* want || to behave on lists/arrays.
>
> I want
>   @result  = @a || @b;
> to be like:
>   (@result = @a) or (@result = @b);
>
> That's what all my students keep expecting it to mean.
>
Note that RFC 82 (http://tmtowtdi.perl.org/rfc/82.pod) proposes that _all_
operators behave the same way in a list context. To me, this consistancy
would be a real win.

The behaviour you're discussing is described in RFC 45. RFC 45 proposes a
special case for the || operator, which is only using its short-circuiting
functionality, not its 'or' functionality. In this case I would think that
using an explicit 'if' would be more appropriate. I'm working with the
maintainer of RFC 45 at the moment to see if we can get the consistency of
component-wise behaviour in a list context without losing the ability to
short-circuit in an assignment.

A potential compromise would be to say that RFC 82 only applies to operators
that do not short-circuit. However, my view is that the loss of consistency
through such a step would be a substantial source of confusion. It would
also mean that overloaded operators with a lazily evaluated parameter would
not work in a consistent manner.

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

[Nathan Torkington]

John Porter writes:
> I think as long as equivalent (and better!) functionality is available,
> through equivalently terse syntax, who's to care?  Why is 
> 
>   $h{'foo'} = 'bar';
> 
> instrinsically preferable to
> 
>   assoc( %h, 'foo', 'bar' );

I'm horrified you have to ask this question.

Perl makes easy things easy.  Hashes are bloody useful, as the last
decade of Perl has borne out.  They deserve syntactic support because
they're used a lot and are worthy of a shorthand.

Anybody who seriously suggests that something that is commonly used in
Perl should become *harder* (also aka longer to type) needs mental
realignment.

There are many bad ways to do things, and I think this is one of them.

Nat

Re: English language basis for "throw"

[Nathan Torkington]

John Porter writes:
> Heh, that's not OO-like syntax!  That's a switch statement!  :-(
> 
> Maybe this is "OO":
> 
>   attempt = new Try { cough "outa here"; };
>   attempt.catch( matawba => { sustain } );
>   attempt.catch( ebola => { overrule } );
>   attempt.catch( { punt } );
>   attempt.try();
> 
> Off I go...

Another thread spirals out of control.

The naming of 'catch' and 'throw', and an imagined 'true' OO
language's implementation of catch and try are both tragically
useless.

Collect the list of *serious* suggestions for catch and throw names,
include catch and throw, and let Larry sort it out.  I strongly
suspect we'll end up with catch and try/throw because they are widely
used elsewhere in the industry.  And if I know our $Larry, it'll be
'try' because it's shorter than 'eval'.  :-)

(and don't even make me suggest that 'catch' be named 'else').

Nat
 

Re: RFC 105 (v1) Downgrade or remove "In string @ must be \@" error

[Chaim Frenkel]

> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:

>> I want this to *always* print out the _value_ of @stuff, even if it's
>> unititalized.

PS> Arrays aren't uninitialized.  They contain zero or more scalars, some of 
PS> which may be uninitialized.

I don't know if it is still true. But at one point in perl's life
defined(@arr) was false before anything was assigned to the array.

At this point this is highly frowned upon.


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

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[J. David Blackstone]

> =head1 TITLE
> 
> Less line noise - let's get rid of @%

  I understand that with the pervasiveness of object-orientation we
are now more than ever seeing objects that behave like arrays and
hashes and that it seems strange to see these listlike or hashlike
objects represented as scalars.  However, this is what the tie
interface was designed for.  If your object works like an array or a
hash, by all means, provide the ability to tie it to an array or a
hash.

  Having once lived in darkness before the marvels of OO enlightened
me (meaning I used to just think object-oriented was a useless
buzzword), I am still very sympathetic towards allowing people to come
to Perl without any requirement that they learn OO.  While this
proposal certainly does not require OO, it seems to be assuming the
universal use of it.

  I find the standard prefix symbols so intuitive I find it hard to
articulate the reasons why I balk at giving them up.  It's like
explaining breathing or the ability to distinguish colors.

  I strongly disagree with the assertion that the Perl type prefixes
are line noise.  I think that phrase is very emotionally charged but
carries little objective fact, and I think you would do better to come
up with a different title.

  I noticed that the examples you cited in a later example about
"cluttered" code all seemed to include references.  May I suggest that
perhaps you would be happy if there were just a cleaner syntax for
dealing with references?

J. David

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Nathan Torkington]

Perl6 RFC Librarian writes:
> =head1 TITLE
> 
> Less line noise - let's get rid of @%

I have some problems with this RFC:

 * you misunderstand the purpose of $ and @, which is to indicate
   singular vs plural.  You say a $ indicates a string or number,
   but really it indicates a single thing.  Similarly @ isn't just
   a variable marker, it's used to indicate that you get multiple
   things:
 @foo[2..10]
 @$foo

 * current typing provides rudimentary compile-type checking.
   Saying:
 $foo = (1,3,5);
   gives a warning.  Saying:
 %foo = "Nat";
   gives a warning.  You'd lose that.  To get it back you'd need
   verbally-typed variables:
 $foo :scalar = (1,3,5);# to get the warning
   and even then it's not necessarily going to be possible to make
   that elicit a warning at compile-time.

 * no sample code.  If you're proposing something as big as this,
   I *really* want to see how it's going to change the language.
   Take an existing 30 line program that does lots of work with
   variables and convert it.  Show me how it affects things like
   slices.  I want to make sure that code that is currently easy
   doesn't become hard.

 * you complain that @foo will become more meaningless once we have
   different data structures that act as collections.  You don't
   consider using @foo for those, though:
 my @foo : FIFO = (4,5);
   This fits in with my personal vision of how Perl6 will handle
   new data types: better support for tie, basically.  You can plug
   in your own C or Perl code to implement new types that masquerade
   as scalars, arrays, or hashes.  Someone else suggested this in
   the thread, and you treated it as already dealt with in the RFC,
   but I don't think it's dealt with at all.  I can't see how saying
 my @foo : SOME_TYPE_THAT_IMPLEMENTS_ARRAY_OPERATORS = (4,5);
   is going to debase the meaning of '@'.

Nat 

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Bryan C . Warnock]

On Tue, 15 Aug 2000, John Porter wrote:
> Yes.  OTOH, if it doesn't add *enough* information, it's not cost-
> effective.  Most of proposals, such as highlander types and this 109,
> reduce the amount of info carried by the symbol to the point that it
> isn't worth having.  Furthermore, if the OO nature of perl, as 
> foreshadowed by perl5's tie-ing and lvalue subs, realizes its full
> potential, then being a "scalar", as indicated by a $, conveys
> essentially zero information.

Composer::Post.assumes(Iterator.each(Iterator.all(List)=="Programmers")
->programs=(Language::Programming.uses("Perl")==true &&
Methodology.implemented(Style.OO==true,Time.all==true)))==true;


-- 
Bryan C. Warnock
([EMAIL PROTECTED])

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Nathan Torkington]

(-internals removed from the CC list)

[EMAIL PROTECTED] writes:
> All calendar systems are arbitrary.

Yup.  So let's use Larry's birthdate-and-time as the epoch marker.

Seriously, stick with 1970 (if we need an arbitrary marker, no reason
it can't be a familiar one) and extend date/time values to be
BigSoddingInts.  That'll mean we're not screwed by the +/- 69.summat
year problem that will hit the rest of civilization in 2038, and we
can do useful calculations like "number of days since Queen Victoria
ascended to the throne" without wrapping around in our int space.

Nat
(BigInts are not an internals headache, so I'm not bothering the
internals list, which is right now debating the difference between
arrays and matrices)

Re: RFC 99 (v1) Maintain internal time in Modified Julian (not epoch)

[Bryan C . Warnock]

On Tue, 15 Aug 2000, Nathan Wiger wrote:
> Jarkko Hietaniemi wrote:
> > 
> > > Is Perl currently using different epochs on different platforms?  If so, I
> > 
> > Yes.  MacOS and VMS.  (Though VMS' localtime() uses the UNIX definition,
> > just to be portable.)  MacOS' epoch zero is 1900 (or was it 1901?),
> > VMS' epoch zero is 17-NOV-1858 00:00:00.00, for some astronomical
> > reason IIRC.
> 
> This is the real point I'm trying to address. Nothing else. :-)
> 
> There seems to be a groundswell against this idea, which is fine by me
> (heck, just because it's my idea doesn't me it's a GOOD one!).
> 
> Here's a different proposal, same vein: "Standardize all Perl platforms
> on the UNIX epoch".
> 
> Sound better?

Only if all the OSes are rewritten to use the standard UNIX epoch as
well.

Internally, you should use whatever the platform you're running on uses.
Externally, you can use whatever you'd like.

> 
> -Nate
-- 
Bryan C. Warnock
([EMAIL PROTECTED])

Re: RFC 104 (v1) Backtracking

[Nathan Torkington]

Jeremy Howard writes:
>   @result = @a || @b;
> 
> Which applies '||' component-wise to elements of @a and @b, placing the
> result in @result.

*Ptui*  That's not how *I* want || to behave on lists/arrays.

I want
  @result  = @a || @b;
to be like:
  (@result = @a) or (@result = @b);

That's what all my students keep expecting it to mean.

Nat

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Bryan C . Warnock]

On Tue, 15 Aug 2000, Karl Glazebrook wrote:
> or one could just *use* english plurals...
> 

I tried this once with filters. It sort of worked.
(With the obvious bombs, of course.)

> my $speaker = 'Jim';
> my $speakers = ('Fred','Bill','Sally','Betty');
> 
> my $male_speakers = $speakers[0:1]; # If perl supported this style of range - see 
>RFC coming soon
> 
> # BUT:
> 
> my $image = read_huge_2d_list_of_numbers('file');
> 
> my $favorite_pixels = $image[10:20,50:100]; 
> my $best_pixel  = $image[11,55]; 
> 
> 
> Karl
-- 
Bryan C. Warnock
([EMAIL PROTECTED])

Re: Default filehandles(was Re: command line option: $|++)

[Peter Scott]

At 12:57 PM 8/15/00 -0700, Nathan Wiger wrote:
>This is a succinct summary of the basic conclusions thus far:
>
>1. a default filehandle IS needed sometimes, but only
>   for stuff like print
>
>2. $|, $\, $/, etc will probably go away entirely in
>   favor of object methods such as $handle->autoflush
>
>That's the current thinking. As always, this is subject to change.
>However, most everyone seems to agree that "having global $| vars that
>aren't really global but actually depend on what the currently selected
>filehandle is which depends on what select() was called on" is bad. So,
>setting stuff like autoflush will probably be object methods only.
>Setting stuff like the default for print will probably still be via the
>default filehandle.

Okay, so I guess it makes sense to define some command-line options that 
change the line characteristics for STDOUT and STDIN, which is what it 
boils down to.

While you're at it, mebbe you could come up with something better than @F 
for -a  :-)


--
Peter Scott
Pacific Systems Design Technologies

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Russ Allbery]

Steve Fink <[EMAIL PROTECTED]> writes:

> I would very much hate to see the prefixes go away or merge into a
> single one, but I'm not so sure I agree with Russ. I've had to teach
> lots of beginners that even though $x refers to scalar x, $x{...} refers
> to %x, but don't think of it that way because the $ is saying what value
> you're getting back, not which variable you're using, unless you're
> calling a function, or...

This falls firmly in the category of things that are powerful for
experienced users of the language but may be somewhat difficult to learn.
I don't think Perl has being easy to learn as it's primary goal, nor
should it.

> I'll just say I wouldn't mind having a stricture forbidding $x and %x in
> the same package.

Ugh.  I'll definitely never use it.  I don't object *provided* that it
doesn't become like the other strictures, things that people expect all
Perl scripts to use; I think it's an essentially worthless constraint.

> I've fairly frequently used code like the above, but I don't really like
> that code in the first place because the only purpose for the $args and
> @args is as temporaries. I like the way mjd describes it:  this is
> "synthetic" code. If you really did have distinct long-lived variables
> with the same name, then I bet it would be confusing.

I do this all the time and I don't find it confusing.  Please let's not
mandate programming style.  Often times the difference between the
variables changes some as the program proceeds, but context makes it quite
clear what's going on.

This strikes me as the same sort of meaningless style guideline as "all
variables must have names that are at least five characters long."

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Steve Fink]

Russ Allbery wrote:
> 
> > All variables should be C<$x>. They should behave appropriately
> > according to their object types and methods.
> 
> No thanks.  I frequently use variables $foo, @foo, and %foo at the same
> time when they contain the same information in different formats.  For
> example:
> 
> $args = 'first second third';
> @args = split (' ', $args);
> my $i = 0;
> %args = map { $_ => ++$i } @args;
> 
> This is very Perlish to me; the punctuation is part of the variable name
> and disambiguates nicely.  I'd be very upset if this idiom went away.

It's already withered away some in perl5. Functions can return lists or
scalars with no distinguishing marks, which was harmless until the
advent of lvalue subs. Now you have $object->listmember = (1,2,3);
$object->scalarmember = 42;. Anyone up for an RFC on allowing a leading
@, $, or (?) % to set the context of a function call? ;-) (Maybe there's
one already, I haven't been keeping track.)

I would very much hate to see the prefixes go away or merge into a
single one, but I'm not so sure I agree with Russ. I've had to teach
lots of beginners that even though $x refers to scalar x, $x{...} refers
to %x, but don't think of it that way because the $ is saying what value
you're getting back, not which variable you're using, unless you're
calling a function, or...

I'll just say I wouldn't mind having a stricture forbidding $x and %x in
the same package. I've fairly frequently used code like the above, but I
don't really like that code in the first place because the only purpose
for the $args and @args is as temporaries. I like the way mjd describes
it:  this is "synthetic" code. If you really did have distinct
long-lived variables with the same name, then I bet it would be
confusing. Either you're maintaining some consistency invariant between
them, and you have to do that manually, or they're unrelated and they'll
collide in readers' brains.

Re: RFC 105 (v1) Downgrade or remove "In string @ must be \@"error

[Glenn Linderman]

Peter Scott wrote:

> I have often wished that digraphs were not bundled with variables in this
> respect, i.e., I wanted to put a string containing \n inside single quotes
> just 'cuz it didn't contain variables to be interpolated.  Whether there's
> a way of improving this behavior or not I don't know.

We could invent

   qv/interpolate variables/
   qd/interpolate digraphs/
   qs/interpolate scalars/
   qa/interpolate arrays/
   qh/interpolate hashes/
   qr/intepolate ->/
   qx/replace with stdout of execution of string as command/

Then, define

   qvd/same as qq interpolate variables and digraphs/

   qvdsahr/interpolate everything/

One possible problem with this solution is that it potentially consumes quite
a few symbols that start with q.  Maybe it should be:

   q/interpolate variables/v
   q/interpolate digraphs/d
   q/interpolate scalars/s
   q/interpolate arrays/a
   q/interpolate hashes/h
   q/intepolate ->/r

   q/same as qq: interpolate variables and digraphs/vd

   q/interpolate everything/adhrsv

In that case, qq// and qx// should be translated to

   q/interpolate variables and digraphs/vd
   q/replace with stdout of execution of string as command/x

by p52p6, I suppose.

--
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: English language basis for "throw"

[Glenn Linderman]

John Porter wrote:

> So, instead of "throw": "throwup".

That leads me down the path of "puke" and "scrub" instead of "throw" and
"catch".  Actually, I rather liked the "oops" Scott suggested, but used in
place of "throw" instead of a rename of "exception".  So how about "oops" and
"recover" instead of "throw" and "catch"?

And, like Mr. Nicol, I see no need to "try" keywords from other languages.
"Finally" we've found someone who is producing some results from innovative
thinking to the exception handling problem, instead of just picking some
other language's nose^Wsemantics.

Perhaps we can "continue" such discussions, "except" that maybe the
moderators will shut down this thread to avoid misuse of keywords.

More seriously, I agree there is no need for a "try" keyword... it just
starts a block, which could just as well be any other block.  So using oops
to throw, and recover to catch, no try needed... and no exception objects
needed either, but they could be used if people want them...

{ # so called "try" block... just another block, or even a simple statement
   # here's an example of an "oops"

   if ( $flibberty < $gibbet ) {

  oops ( 43 #< error code >#, $flibberty, $gibbet, @moreparams );
   }
}
recover {

#

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Damien Neil]

On Tue, Aug 15, 2000 at 05:45:04PM -0400, Karl Glazebrook wrote:
> I hope people will actually read the RFC before coming back with these
> canned responses which I (and presumably everyone else on this list)
> am completely familiar with. I used to believe that too! Honest...

I think you do a significant disservice to brush off criticism so
blithely.  Complaining that anyone who disagrees with you has not read
the RFC is unlikely to garner much support.


Line noise or not, I like the type prefixes.

I like being able to treat arrays and hashes differently from other
things.

  snrub($a);
  snrub(@a);
  snrub(%a);
  snrub(@$a)
  snrub(%$a)

Each one of these does something different.  I know, just by looking
at the expression, with absolutely no further knowledge of what the
function and variable involved are, the general nature of what is
going on.  I know whether the function is receiving one argument or
several.  I can make reasonable assumptions about what will happen
to the contents of the variable.  I know something about what
operations I can perform on the variable.

If your proposal goes through, how will I perform these operations?
What will "snrub(@a)" become?  If we just turn all the @%s into $s,
then it becomes "snrub($a)" -- and now snrub is being passed a
variable number of arguments, and I have no way to tell this without
more context.  Maybe we can keep the @{} syntax -- but now you need
to say @$a where you before said @a, and the line noise has increased,
not decreased.

The real problem in the above is context -- when I see @a or %a, I
know that it will behave in one fashion in list context, and another
in scalar context.  $a, on the other hand, may be trusted to remain
the same no matter what the context.  Indeed, I'd say that all the
line-noise puncuation is one of the things that makes context
bearable.

Perhaps we should remove context?  Sure, you won't be able to test
for @a == 5 any more, but we can just rewrite that as $a->length == 5.
At this point, there isn't much need for the $, though, so we
can just say a->length == 5.  That -> is ugly, though; maybe we can
turn it into a . like the rest of the world, at which point we're
every bit as good as Python!

Y'know, I like Python.  Lot of nice things in that language.  Maybe
we should all jump over to their mailing lists rather than wasting
our time with Perl 6.

   - Damien

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

[Chaim Frenkel]

Why? What is the gain? Perl only runs on the local machine.

As long as one can increment and take the difference what difference
does the epoch make?

What is of more interest would be knownig the valid range of time
supported on each platform. Even if you standardize the epoch, the
platform may be unable to calculate to the epoch.



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

PRL> =head1 ABSTRACT

PRL> Currently, internal time in Perl is maintained via C, which is
PRL> highly system-dependent. On some systems, this is relative to the UNIX
PRL> epoch, while others use their own epochs (MacPerl uses 1904, for
PRL> example).

PRL> All versions of Perl on all platforms should maintain time both
PRL> internally and externally as seconds since the UNIX epoch (00:00:00 01
PRL> Jan 1970 UTC).


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

Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument

[Damian Conway]

   > Now, if this is what you want, add a :readonly attribute:

So the proposal is: make the dangerous one the default.
I don't think that's a good idea.

Damian

Re: Array storage (was Re: RFC 84 (v1) Replace => (stringifying comma) with =>)

[Jarkko Hietaniemi]

> > > No, neither proposal makes sense. Arrays can be stored compactly and
> >
> > $a[1_000_000_000] = 'oh, really?' # :-)
> >
>   my int @a: sparse;

I see: you have a time machine and I don't.  So very unfair...

>   $a[1_000_000_000] = 'Yes, really!' # :P
> 
> OK, so I cheated... I haven't submitted my RFC for a 'sparse' attribute yet.
> My point is that arrays *can* be stored compactly, not that they always

I smell...n-level bitmaps?

> *are*. Another type of array storage is that required for lazily generated
> lists (see RFC 81)

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

Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument

[Nathan Wiger]

Damian Conway wrote:
>
> Ah, but there's definitely a confusion as to whether it's *meant*
> to be assignable.
> 
> What if I (as the class designer) want to give you read access but not
> write access to an object's name?

I think this misses the mark. We're talking about functions, right?
:lvalue won't save you from the situation you describe:

   $r->func = $x; # whew! no :lvalue saves us
   $r->func($x);  # but not from this! oh no!

What you have to do is write the function correctly:

   sub func {
   die "assigning to func attempted" if @_;
   $ME->{STATE}->{func};   # return "func" value
   }

Now, if this is what you want, add a :readonly attribute:

   sub func : readonly {
   # auto-die if @_ seen
   $ME->{STATE}->{func};
   }

This saves you from both:

   $r->func = $x; # whew! having :readonly
   $r->func($x);  # dies for both of these

-Nate

Re: subroutines ==? methods

[Damian Conway]

   > The difference is one of use, not one of meaning. Why not extend
   > "method" to be any subroutine, just as we have apparently extended
   > "subroutine" to include "function" by not acknowledging any
   > distinction there either?

In fact, Class::Multimethods *doesn't* distinguish methods and subroutines.
Neither will my forthcoming multiple dispatch RFC.

Damian

Re: Default filehandles(was Re: command line option: $|++)

[Chaim Frenkel]

> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:

NW>2. $|, $\, $/, etc will probably go away entirely in
NW>   favor of object methods such as $handle->autoflush

It think they will still be needed as lexical variables used as an
initializer for the corresponding per-filehandle value.


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

Re: RFC 104 (v1) Backtracking

[Damian Conway]

   > As I understand things:
   > 
   >BLOCK1 andthen BLOCK2
   > 
   > evaluates BLOCK1 and then if BLOCK1 evaluates to "true" evaluates
   > BLOCK2.  If BLOCK2 evaluates to "true" we're done.  If BLOCK2
   > evaluates to "false", then BLOCK1 is re-evaluated. 

So how is that different from:

do BLOCK1 until do BLOCK2

???

Re: Default filehandles(was Re: command line option: $|++)

[Chaim Frenkel]

> "JSD" == Jonathan Scott Duff <[EMAIL PROTECTED]> writes:

JSD> On Tue, Aug 15, 2000 at 12:57:46PM -0700, Nathan Wiger wrote:
>> This is a succinct summary of the basic conclusions thus far:
>> 
>> 1. a default filehandle IS needed sometimes, but only
>> for stuff like print

JSD> Well, I think that C should always print to $PERL::STDOUT (or
JSD> whatever we call it) always; same with C.  I'd hardly call that
JSD> "default" though.

Err, no.

What if you want to print to a default file handle and also to STDOUT?

select(OTHERFH);
print "This goest to OTHERFH\n";
print STDOOUT "This went to STDOUT\n";

STDOUT is _not_ the default filehandle. It is the currently selected
filehandle when perl starts.


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

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

[Peter Scott]

At 05:41 PM 8/15/00 -0500, Jarkko Hietaniemi wrote:
> > No, neither proposal makes sense. Arrays can be stored compactly and
>
>$a[1_000_000_000] = 'oh, really?' # :-)

Now, now, there have been credible proposals for sparse arrays, you know 
that...

--
Peter Scott
Pacific Systems Design Technologies

Array storage (was Re: RFC 84 (v1) Replace => (stringifying comma) with =>)

[Jeremy Howard]

Jarkko Hietaniemi wrote:
> On Wed, Aug 16, 2000 at 08:37:21AM +1000, Jeremy Howard wrote:
> > Stephen P. Potter wrote:
> > > Lightning flashed, thunder crashed and John Porter <[EMAIL PROTECTED]>
> > whispered
> > > :
> > > | Here's a counter-proposal: throw out hashes as a separate internal
> > > | data type, and in its place define a set of operators which treat
> > > | (properly constructed) arrays as associative arrays.  It's the
> > >
> > > Doesn't it make more sense to get rid of arrays and just use hashes?
> > >
> > No, neither proposal makes sense. Arrays can be stored compactly and
>
> $a[1_000_000_000] = 'oh, really?' # :-)
>
  my int @a: sparse;
  $a[1_000_000_000] = 'Yes, really!' # :P

OK, so I cheated... I haven't submitted my RFC for a 'sparse' attribute yet.
My point is that arrays *can* be stored compactly, not that they always
*are*. Another type of array storage is that required for lazily generated
lists (see RFC 81)

  http://tmtowtdi.perl.org/rfc/81.pod

Re: RFC 105 (v1) Downgrade or remove "In string @ must be \@" error

[Peter Scott]

At 02:44 PM 8/15/00 -0700, Nathan Wiger wrote:
> > Better yet, DWIM.  If I write
> >
> >   print "[EMAIL PROTECTED]";
> >
> > and no array @southern exists, I probably mean I want it to print
> >
> >   [EMAIL PROTECTED]
> >
> > I'd say, if the variable exists, interpolate it.  If not, print it as
> > it stands.

Less DWIM, please.

>I initially was thinking this too, but there's a major problem:
>
>print "Your stuff is: @stuff\n";
>
>I want this to *always* print out the _value_ of @stuff, even if it's
>unititalized.

Arrays aren't uninitialized.  They contain zero or more scalars, some of 
which may be uninitialized.

>Perl's already smart enough. I think getting in the habit
>of writing:
>
>$email = '[EMAIL PROTECTED]';
>
>Is the better thing to do.

Yes!  I think of the quotes as:

' - for strings not doing any variable interpolation
" - for strings doing interpolation, or including digraphs

I have often wished that digraphs were not bundled with variables in this 
respect, i.e., I wanted to put a string containing \n inside single quotes 
just 'cuz it didn't contain variables to be interpolated.  Whether there's 
a way of improving this behavior or not I don't know.

--
Peter Scott
Pacific Systems Design Technologies

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Peter Scott]

At 03:14 PM 8/15/00 -0700, Russ Allbery wrote:
> > All variables should be C<$x>. They should behave appropriately
> > according to their object types and methods.
>
>No thanks.  I frequently use variables $foo, @foo, and %foo at the same
>time when they contain the same information in different formats.  For
>example:
>
> $args = 'first second third';
> @args = split (' ', $args);
> my $i = 0;
> %args = map { $_ => ++$i } @args;
>
>This is very Perlish to me; the punctuation is part of the variable name
>and disambiguates nicely.  I'd be very upset if this idiom went away.

What he said.  Several things have occasionally struck me as standing 
improvement in Perl; this has never been one of them.  It's always been 
very intuitive and easy to understand for me.

Methinks the language list is starting to hit the ozone layer.

--
Peter Scott
Pacific Systems Design Technologies

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Nathan Wiger]

> I hope people will actually read the RFC before coming back with these
> canned responses which I (and presumably everyone else on this list)
> am completely familiar with. I used to believe that too! Honest...
> 
> I am looking forward to reading some *real* criticisms...

Ok, here goes. First off, I *did* read the RFC. I never respond before
reading. Personally, I wish people would quit coming up with these silly
"let's drop the prefixes" RFC's that everyone on this list is completely
familiar with.

> Also in modern programming, lists are not longer simple
> lists, neither are hashes, we have multidimensional arrays,
> FIFO stacks, LIFO stacks, semi-infinite lists, etc. 

Yeah, and isn't it cool that Perl gives you easy access to using and
understanding such complex data structures:

   print @{ $cars->{$model} };

That "junk" makes it easy to see that you're derefencing a hashref that
contains a key which is pointing to an array. How is this:

   print cars->model;

any clearer? Nicer to look at? Maybe for some. Not for me, I like the
former. Maybe it doesn't let you know exactly what you're getting, but
you're a lot closer. And this:

   print "Welcome back, $fullname, to $website!\n";

is MUCH better than this:

   print "Welcome back " . fullname . " to " . website . "!\n";

Ugly. Plus, is fullname a scalar? Array? Hash? Sub? Builtin? Well, it
looks like you have to guess, unless you wrote the whole program, which
you probably didn't.

Don't overlook the simple benefits of prefixes.

> Those days are gone. Perl 5 introduced the idea of Objects
> and now any variable can be one of ten million possible
> types all of very different behaviours.

Not true!! Only $scalars can hold objects. Now, @arrays and %hashes can
hold groups of objects, but only $scalars can hold objects.

I used to think this was bad also, and that objects should have their
own prefix, like *. So:

   *object = new CGI;
   print *object->param($name);

That makes it easier to see what objects are, true. But that's not the
real problem.

The real problem is that we lack true object polymorphism. That is,
objects are useless in number and string contexts. This is the problem
that needs to be addressed. I've submitted RFC's 49 and 73 on this, and
have another one coming. I hope you'll read them.

Please, nobody submit an RFC on the * idea. It's bad, and here's why:

   @stuff = (*object, $number, *filehandle);
   foreach ( @stuff ) {
  print "Got $_\n";
   }

If you have a separate prefix and type for objects, then this will have
to fail with "Attempt to stick object whatzitz in scalar whatzitz". Bad.

However, if you have object polymorphism, then you don't have this
problem. Objects are automatically converted to numbers and strings
on-demand. The internals people are doing some really interesting stuff
along these lines.

To summarize, you should read RFC's 49, 73, 28, and the link to TomC's
email I sent you. These address the real problems, and not the symptoms.

Maybe the prefix system isn't perfect, and maybe needs improvement. But
I don't see how eliminating it can possibly count as improvement.

-Nate

subroutines ==? methods

[David L. Nicol]

Jonathan Scott Duff wrote:
> 
> On Mon, Aug 14, 2000 at 09:40:07PM -0500, David L. Nicol wrote:
> > Jonathan Scott Duff wrote:
> > >
> > > > context-based method overloading
> > >
> > > I think you should s/method/subroutine/ everywhere in this document.
> > > What you say of methods is equally as true of ordinary subroutines.
> >
> > Hmm.
> >
> > They're nearly synonymous.
> 
> Nearly but not.  "methods" are always used in an object oriented
> context.  You don't hear the C folk talk about "methods" in C do you?
> But you hear those C++ folk talk about them all the time.  :-)
> 
> So I would argue that "subroutine" is the more general form of
> "method" as it includes the non-OO versions as well as the OO
> versions.
> 
> Just MHO,
> 
> -Scott


The difference is one of use, not one of meaning. Why not extend
"method" to be any subroutine, just as we have apparently extended
"subroutine" to include "function" by not acknowledging any
distinction there either?

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

[Jarkko Hietaniemi]

On Wed, Aug 16, 2000 at 08:37:21AM +1000, Jeremy Howard wrote:
> Stephen P. Potter wrote:
> > Lightning flashed, thunder crashed and John Porter <[EMAIL PROTECTED]>
> whispered
> > :
> > | Here's a counter-proposal: throw out hashes as a separate internal
> > | data type, and in its place define a set of operators which treat
> > | (properly constructed) arrays as associative arrays.  It's the
> >
> > Doesn't it make more sense to get rid of arrays and just use hashes?
> >
> No, neither proposal makes sense. Arrays can be stored compactly and

$a[1_000_000_000] = 'oh, really?' # :-)

> accessed and iterated through quickly, because they can take advantage of
> the fact that they are always indexed by an integer.

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

Re: RFC 104 (v1) Backtracking

[Jonathan Scott Duff]

On Wed, Aug 16, 2000 at 08:26:26AM +1000, Jeremy Howard wrote:
> Doesn't RFC 82 (Make operators behave consistantly in a list context)
> provide this functionality? This is perfectly valid under that proposal:
> 
>   @result = @a || @b;
> 
> Which applies '||' component-wise to elements of @a and @b, placing the
> result in @result.
> 
> I'm no Prolog guru, so feel free to correct me if I'm missing something
> here.

I think you're missing the backtracking part (I'm no guru either).
As I understand things:

BLOCK1 andthen BLOCK2

evaluates BLOCK1 and then if BLOCK1 evaluates to "true" evaluates
BLOCK2.  If BLOCK2 evaluates to "true" we're done.  If BLOCK2
evaluates to "false", then BLOCK1 is re-evaluated.  Er, let me see if
I can write the logic better:

1. eval BLOCK1
2. if "false", stop, else goto 3
3. eval BLOCK2
4. if "true", stop, else goto 1

It's kind of an all-or-nothing expression with side effects
(evaluating the blocks).  This sort of logic can be extended to N
blocks too.

Though I think if we're 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]

Re: English language basis for "throw"

[Peter Scott]

At 05:33 PM 8/15/00 -0400, John Porter wrote:
>The thing I don't like about C++/Java try/catch syntax is the way
>the blocks are daisychained.  That is not intuitive to the flow.

I find it quite intuitive :-)

>The exception handlers should be more closely bound -- syntactically --
>to the try block.  A switch statement would be closer; but I think an
>OO syntax would be better.  You know, something like
>
> try {
> cough "outa here";
>
> catch {
> matawba => { sustain; },
> ebola => { overrule; },
> { punt; }
> }
> }

What interpretation should be placed on statements in the try block 
following a catch block?

--
Peter Scott
Pacific Systems Design Technologies

Re: RFC 84 (v1) Replace => (stringifying comma) with =>

[Jeremy Howard]

Stephen P. Potter wrote:
> Lightning flashed, thunder crashed and John Porter <[EMAIL PROTECTED]>
whispered
> :
> | Here's a counter-proposal: throw out hashes as a separate internal
> | data type, and in its place define a set of operators which treat
> | (properly constructed) arrays as associative arrays.  It's the
>
> Doesn't it make more sense to get rid of arrays and just use hashes?
>
No, neither proposal makes sense. Arrays can be stored compactly and
accessed and iterated through quickly, because they can take advantage of
the fact that they are always indexed by an integer. You could remove the
array/list data type and rely on Perl to try and implement hashes indexed by
integers as a list, but that would introduce a lot of complexity for little
real benefit.

Re: English language basis for "throw"

[Peter Scott]

At 05:06 PM 8/15/00 -0400, John Porter wrote:
>I think about the word some OO gurus use: "raise".

I think that came from the kernel or hardware people before OO was 
around.  Something about raising and lowering IPLs.

--
Peter Scott
Pacific Systems Design Technologies

Re: Default filehandles(was Re: command line option: $|++)

[Nathan Wiger]

Jonathan Scott Duff wrote:
> 
> On Tue, Aug 15, 2000 at 12:57:46PM -0700, Nathan Wiger wrote:
> > This is a succinct summary of the basic conclusions thus far:
> >
> >1. a default filehandle IS needed sometimes, but only
> >   for stuff like print
> 
> Well, I think that C should always print to $PERL::STDOUT (or
> whatever we call it) always; same with C.  I'd hardly call that
> "default" though.

Read the link I sent out. There's a reason this doesn't work.

-Nate

Re: RFC 90 (v1) Builtins: zip() and unzip()

[Jeremy Howard]

Stephen P. Potter wrote:
> | If the list to be unzipped is not an exact multiple of the partition
size,
> | the final list references are not padded--their length is one less than
> | the list size. For example:
> |
> |   @list = (1..7);
> |   @unzipped_list2 = unzip(3, \@list);   # ([1,4,7], [2,5], [3,6])
>
> This wording is confusing.  Is $list_size or "the partition size" supposed
> to be the length of each list, or the number of lists?  The way it is
> described leads me to think it should be the length of each list, but this
> example shows it being the number of lists. I would expect the
> @unzipped_list2 would return ([X,Y,Z], [A,B,C], [M]), although I can't
wrap
> my mind around which values should go where yet.
>
> It makes more sense for it to be the number of lists, in which case
> @unzipped_list should be ([1,4], [2,5], [3,6]) not ([1,3,5], [2,4,6]).
>
You're right, Stephen, it is confusing the way I wrote it. Sorry--I'll
redraft it today to try and make it more clear (and yes, I'm changing their
names too!)

I agree that the 2nd param would be more intuitive if it was the number of
lists. I'll make that change as well.

@unzipped_list2 should not be([X,Y,Z], [A,B,C], [M]). The RFC's proposed
behaviour makes it work as the inverse of zip(), which is the desired
behaviour.

Re: RFC 109 (v1) Less line noise - let's get rid of @%

[Michael Fowler]

On Tue, Aug 15, 2000 at 05:10:34PM -0400, Dan Sugalski wrote:
> The ultimate target of a program's source code is the *programmer*. 
> Programmers, being people (well, more or less... :), work best with symbols 
> and rich context. Stripping contextual clues out of code does the 
> programmer a disservice. We're at the point where we don't have to cater to 
> the limitations of the computer hardware. That means we'll be better off if 
> we cater to the limitations (and strengths!) of people's wetware.
> 
> Let's not move backwards and force people to work like machines. Instead, 
> lets force machines to work like us.

Exactly!

I would also like to remind everyone that, despite abandoning backwards
compatibility with programs, we should by no means abandon backwards
compatibility with Perl programmers.  Removing the special symbols would be
quite a shock to most Perl programmers (including me), and we don't want to
alienate those who know Perl.

I say these things for purely selfish reasons; I like Perl, and want it to
look much the same as it does now.  Perl is a wonderful language.


Michael
--
Administrator  www.shoebox.net
Programmer, System Administrator   www.gallanttech.com
--