Re: In defense of zero-indexed arrays.

2002-12-06 Thread Damien Neil
On Thu, Dec 05, 2002 at 02:45:39AM -0800, Michael G Schwern wrote:
 Explain how having indexes (arrays, substr, etc...) in Perl 6 start at 0
 will benefit most users.  Do not invoke legacy. [1]

Answer 1: Ignoring legacy, it won't.

Answer 2: Because C uses 0-based indexes, Parrot is written in C, and
it would be just painful to switch back and forth when working on
different layers of the system.  (Not a legacy argument, unless you
want to argue that Parrot is a legacy system.)

Answer 3: In a lower-level language than Perl, an array is usually a
block of memory divided into array elements.  The index is the offset
from the start of the array.  In languages like C which allow pointer
arithmetic, it makes sense for the array index to be the element offset,
to allow a[i] to be equal to *(a + i).  Higher level languages should
follow this convention, for consistency.  (Again, not a legacy argument,
since it offers a first-principles rationale for 0-based arrays in
certain contexts.)

- Damien



Re: Loop controls

2002-05-02 Thread Damien Neil

On Wednesday, May 1, 2002, at 02:27  PM, Aaron Sherman wrote:
   unless my $fh = $x.open {
   die Cannot open $x: $!;
   } else while $fh.getline - $_ {
   print;
   } else {
   die No lines to read in $x;
   }

I think you need a better example--given that the unless clause throws 
an exception, the else while can just as easily be written as a 
while, no else.  (Which I, personally, would find far clearer.)

 - Damien




Re: Some Apocalypse 4 exception handling questions.

2002-01-24 Thread Damien Neil

On Wed, Jan 23, 2002 at 06:00:21PM -0500, Melvin Smith wrote:
 final and private are completely different concepts as I understand
 them.
 
 I wouldn't say completely different. They are both used for enforcement
 of similar means, but you are correct, they are different.

I view final as being most useful in an optimization sense.  A final
method may be safely inlined, and does not require a vtable entry.

   - Damien



Re: finalization

2001-08-28 Thread Damien Neil

On Tue, Aug 28, 2001 at 09:07:03PM -0400, Sam Tregar wrote:
 Well, there's the Perl 5 reference counting solution.  In normal cases
 DESTROY is called as soon as it can be.  Of course we're all anxious to
 get into the leaky GC boat with Java and C# because we've heard it's
 faster.  I wonder how fast it is when it's halfway under water and out of
 file descriptors.

Speaking purely for myself, I'd rather have a non-refcounting GC
because I'm rather tired of going through elaborate tricks to avoid
ever creating circular data structures.

- Damien



Re: Anyone actually experienced with object inheritance?

2001-07-02 Thread Damien Neil

On Mon, Jul 02, 2001 at 12:59:51PM -0700, David Whipp wrote:
 Its not quite the same thing, but Java does have the concept of
 anonymous classes (it names them 'inner' classes): Is Perl6 going
 to have a similar concept?

Inner classes and anonymous classes are actually different in Java.
(Anonymous classes are always inner classes; inner classes are not
always anonymous.) An inner class is a class contained within a
class; only the containing class may use the contained class.  An
anonymous inner class is an unnamed instantiation of an interface;
these are often used in places where Perl coders would use a closure.
(Java doesn't have closures.)

Both inner classes and anonymous inner classes exist for reasons
fairly specific to Java; they're very useful in a certain context,
but Perl has other ways to accomplish the same things.

  - Damien



Re: Properties and stricture

2001-06-05 Thread Damien Neil

On Tue, Jun 05, 2001 at 11:14:29PM +0100, Michael G Schwern wrote:
 my $meth = foo;
 $obj-$meth();  # $obj-foo();
 
 I'm probably using the wrong terms.
 
 This definately can't work if $obj is of a class which is strongly
 typed.

You would do that in Java by using reflection.  There's nothing about
strong typing which prevents dynamic method calls like this, although
you obviously can only verify the sanity of the call at runtime.

   - Damien



Re: a modest proposal Re: s/./~/g

2001-04-27 Thread Damien Neil

On Thu, Apr 26, 2001 at 04:46:48PM -0700, Larry Wall wrote:
 And I'm tired of hearing the argument that Perl programmers can't get
 used to a different operator for concatenation.  I know better--after
 all, Perl is probably what got them used to . in the first place.  If
 you can teach dogs to salivate at a bell, you can probably teach them
 to salivate at a dog biscuit.  :-)

I think many of us are resigned to losing . for concatination; I know
I can live with that.  I just don't want to have this result in ~, ^,
or any other C-style punctuation operator getting renamed.  I like the
fact that Perl follows the same operator conventions as C, C++, Java
and others in this area; breaking with tradition here for the sake of
aligning . feels inelegant.

Renaming . to cc wouldn't bother me half so much.

- Damien



Re: Tying Overloading

2001-04-24 Thread Damien Neil

On Mon, Apr 23, 2001 at 11:31:18AM -0700, Larry Wall wrote:
 There are many people who would prefer . to -, if for no other reason
 than it's cleaner looking and is one less character to type.  The fact
 that it's become the industry standard for method call syntax is also
 a point in its favor.
 
 Incidentally, Perl 6 will not require . everywhere that Perl 5 requires
 -.  The deref will be assumed before (), [], and {} (where an operator
 is expected).  We're only talking about method calls here, really.

Something in my gut feels wrong about needing to relearn all my operators
to use Perl 6.  When I write Perl, . MEANS concatination to me.  It's
spread through all my code.  I know that Perl 6 is going to evolve...but
this is attacking something fundamental to the way I perceive the language.

Change what ., ~, and ^ mean in Perl 6, and I'll need to keep two
operator maps in my head whenever I look at Perl code.  OK, this is
some old Perl 5, so ~$foo is a bitwise negat...oh, wait, it's really
new Perl 6, and this is a concatination...

I'm a neophile, and I'd balk at switching to a Perl 6 that did that.
I know my coworkers would revolt; they're already dubious about Perl's
level of complexity.

I'd really rather just make method calls with -.

If you're dead-set on reassigning ., please consider leaving it at
that, rather than juggling all the other operators around.  Make
concatination be $a cat $b.  (eq and friends already provide
precedent for string operators being words rather than symbols.)

   - Damien



Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

2000-10-04 Thread Damien Neil

On Wed, Oct 04, 2000 at 03:15:22AM -0600, Tom Christiansen wrote:
 POD, presumably.  Or maybe son-of-POD; it would be nice to have better
 support for tables and lists.
 
 We did this for the camel.   Which, I remind the world, was 
 written in pod.

What kinds of things got added for the camel?

Personally, my largest complaint with POD is that lists eat far too
much vertical whitespace.  It takes four lines to write a one line
checklist item.

SDF does lists in a simple fashion that is both easy to read and write:

* Item one of a bulleted list.
* Item two.
* Item three.

. Item one of a numbered list.
^ Item two.
. Start of a new numbered list.

This breaks POD's use of blank lines as paragraph separators, however.

Perhaps POD could get a =list directive?  (=over is evil, IMO.  You
shouldn't be specifying the number of columns to indent ("=over 4"),
you should be specifying logical indentation depth.)

=list
* Item.
* Item.
* Item.

=endlist

   - Damien



Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

2000-10-03 Thread Damien Neil

On Tue, Oct 03, 2000 at 03:42:49PM +0100, Graham Barr wrote:
 On Mon, Oct 02, 2000 at 12:58:37PM -0700, Damien Neil wrote:
  What?  I don't think people should be writing either XML or HTML
  as the source documentation format.  I said that, quite clearly.
 
 Then what are they going to write it in ? And don't tell me to get
 some fangle dangled editor. Which would have the disadvantage of not
 being able to be inline, which is a huge advantage with pod.

POD, presumably.  Or maybe son-of-POD; it would be nice to have better
support for tables and lists.

 - Damien



Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

2000-10-02 Thread Damien Neil

On Mon, Oct 02, 2000 at 09:21:51AM -0700, Glenn Linderman wrote:
 Indeed, this is the key problem with human use of XML.  HTML was originally
 simple enough to be human writable, its later, more powerful incarnations
 start losing that (but you can always use a subset for simple things, and
 XML never had human writable simplicity and never will.

XML is intrinsically no more or less difficult to write than HTML.
Comparing XML to HTML is pointless, however; they are not the same
thing.  Rather, compare XML to SGML, and specific XML DTDs (XHTML,
for example) to HTML.

XHTML is certainly no more difficult to write than plain HTML.  The
only real difference is that tags like hr become hr/ -- hardly
a major difference.  Indeed, I would consider the XHTML version to
be a bit simpler to understand.

- Damien



Re: RFC 357 (v1) Perl should use XML for documentation instead of POD

2000-10-02 Thread Damien Neil

On Mon, Oct 02, 2000 at 01:24:37PM -0600, Tom Christiansen wrote:
 XML is intrinsically no more or less difficult to write than HTML.
 
 Wrong.

I beg your pardon?


 Comparing XML to HTML is pointless, however; they are not the same
 thing.  
 
 Wrong.  And you only say that because you will not like the answer.
 
 Go back to the posted example and count bytes of data versus
 bytes of meta data.  

Did you read what I wrote?

XML is like SGML.  It specifies a generic means of writing structured
text; it says nothing about what that structure is.  In particular,
neither XML nor SGML specifies a particular set of tags.  HTML is a
particular SGML dialect; as such, it can only be compared to a specific
XML dialect, not XML as a whole.

  exampleThis wordis/word XML./example

It is also SGML.  It is not, obviously, HTML.

  This is ttHTML/tt.
  This is ttXHTML/tt.

No difference, really.  You do see differences with things like the
hr tag; SGML allows the DTD to define certain tags as being atomic,
and XML does not.  This means that hr must be written as hr/ in
XHTML.

Now, if you want to compare an XML DTD like DocBook to HTML, you have
a point.  DocBook contains whole heaping piles of complexity.  I'd
certainly rather write HTML than DocBook by hand.


 I guarantee you that you will drive people away with this crap.

What?  I don't think people should be writing either XML or HTML
as the source documentation format.  I said that, quite clearly.

 - Damien



Re: RFC 328 (v2) Single quotes don't interpolate \' and \\

2000-09-30 Thread Damien Neil

On Fri, Sep 29, 2000 at 07:24:38PM -0400, Dan Sugalski wrote:
$foo = """Things like ', ", and \ have no special meaning in here.""";
 
 Argh! *NO*! That way lies madness, or at least DCL's quoting mania. My 
 record, in a command procedure that wrote other command procedures that 
 submitted command procedures to batch, was 13 quotes in a row. Let's *not* 
 go there, thanks.

Python doesn't allow that degree of quoting.  You can just use triple
quotes as an alternative to single quotes.

Certainly no more insane than qq{}, qq[], qq(), qq##, , qq!!, ...

  - Damien



Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-20 Thread Damien Neil

On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote:
 Add null() keyword and fundamental data type

I think that this is better done as a special overloaded object used
by database modules which wish to implement SQL-style tri-state logic.
Given that making overloaded objects fast appears to be a major
design goal of Perl6, there should be no serious performance problems
to this.

The one thing which this requires that Perl5 does not have is the
ability to overload the defined() operation on an object.  Other
than that, the following code produces a usable null object:

  package Null;

  use overload '""' = sub { undef },
   bool = sub { undef },
   '0+' = sub { undef },
   nomethod = sub { bless {} };

  sub null() { bless {}; }

  print "   1 +1 = ", (   1 +1), "\n";  #1 +1 = 22
  print "null +1 = ", (null +1), "\n";  # null +1 =
  print "   1 + null = ", (   1 + null), "\n";  #1 + null =
  print "null + null = ", (null + null), "\n";  # null + null =

  print "defined(null) = ", defined(null), "\n"; # defined(null) = 1  (error)

I don't think that we would be well served by confusing the state of
truth in core Perl any further than it is now, especially when the
desired functionality does not need to be in the core.

Incidentally, I'm surprised that DBI hasn't added an option to use
an overloaded null object, if this feature is in demand.

- Damien



Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-20 Thread Damien Neil

On Wed, Sep 20, 2000 at 11:58:08AM -0700, Glenn Linderman wrote:
  I think that this is better done as a special overloaded object used
  by database modules which wish to implement SQL-style tri-state logic.
 
 It could be done as an overloaded object.  You'd have to be able to overload all
 the operators, both numeric and string.

This can be done.  "perldoc overload".


  The one thing which this requires that Perl5 does not have is the
  ability to overload the defined() operation on an object.
 
 And what about overloading the ternary ?: operator?  Of course, that one can be
 avoided.

Overload conversion to bool, and you have this trivially.


 Not usable, I get lots of "Use of uninitialized value in print" warnings, and do
 not have use strict.

I suggest that you read up on the difference between "use strrict" and
"use warnings"/-w.

Furthermore, you may wish to take the five seconds necessary to
understand WHY it prints that message when you print a null value
in that code.  I defined null as stringifying to undef, with the
specific intention of producing that warning message.  If you
would prefer that it stringify to "", or to "null", this would be
a trivial change.


  Incidentally, I'm surprised that DBI hasn't added an option to use
  an overloaded null object, if this feature is in demand.
 
 Performance.

For an optional, off-by-default feature?  If a SQL-style null is
so useful, I'm certain there are people who would be happy to
accept the performance hit.

When you consider that this would be used in conjunction with database
code which often must perform transactions via the network, I strongly
suspect that in many cases the performance overhead of overloading
would be nearly invisible.

   - Damien



Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-20 Thread Damien Neil

On Wed, Sep 20, 2000 at 01:21:52PM -0700, Russ Allbery wrote:
 No offense to Damian, but I tried to read and understand his documentation
 and I thought I was back in grad school.  I don't think it's the fault of
 the writing either; I think that Quantum::Superpositions is trying to do
 something that's rather too complicated to explain clearly to the average
 programmer.
 
 It's a neat idea, but I don't expect to see it ever widely used.

I disagree.  I think that, ignoring the documentation, the operations
performed by Quantum::Superpositions are intuitive and elegant.

  print "$a is between 1 and 10" if ($a == any(1 .. 10));

The above is simple and clear.  The any() and all() operations are,
perhaps, surprising to experienced programmers (we aren't used to
languages that provide them), but will be instantly understood by
most novices.

If I could be assured that the performance penalty was minimal, I'd
be delighted to write

  if ($errno == any(EAGAIN EINTR)) { ... }

over

  if ($errno == EAGAIN || $errno == EINTR) { ... }

The former is less typing and reads more clearly (to me, at least).


I am of two minds about the documentation.  On one hand, it's
highly theoretical bent will be intimidating to many.  On the other
hand, I found that it clearly described what was going on, and
nicely explained the complexities underlying the simple interface.

I do wonder whether there isn't a better name for eigenstate().

  - Damien



Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-20 Thread Damien Neil

On Wed, Sep 20, 2000 at 02:47:01PM -0600, Tom Christiansen wrote:
 In Perl, this is the null character: "\0"
...
 It's a shame you don't like it, but this is the way we speak.

Well, it's the way you speak.  Myself, I'd call that the NUL
character.  :

 - Damien, exercising a pet peeve.



Re: RFC 76 (v2) Builtin: reduce

2000-09-19 Thread Damien Neil

On Tue, Sep 19, 2000 at 08:14:24PM -0600, Tom Christiansen wrote:
 Following Glenn's lead, I'm in the process of RFC'ing a new null()
 keyword and value 
 
 As though one were not already drowning in a surfeit of subtly
 dissimilar false values.

Hear, hear.

Three-valued logic is enough.  Make it four-valued, and my head is
going to explode.

  - Damien



Re: $a in @b

2000-09-07 Thread Damien Neil

On Fri, Sep 08, 2000 at 09:45:54AM +1100, Damian Conway wrote:
 I would propose that the Cgrep operation should short-circuit if the
 block throws an exception, with the value of the expection determining
 whether the final invocation of the block should accept the element it
 was filtering:

I don't think Cgrep should be able to eat unintentional exceptions.
Perhaps it could short-circuit if the exception is 1 or false, as
opposed to true or false?

  - Damien



Re: why not just use C /* ... */ ?

2000-08-23 Thread Damien Neil

On Thu, Aug 24, 2000 at 06:53:31AM +1000, iain truskett wrote:
 /* File: C:\user\jv\demo.java */
 
  t.java:1: Invalid escape character.
  /* File: C:\user\jv\demo.java */
 
 In that situation, I would say that the java compiler isn't really doing
 what it should be doing. i.e. That looks like a bug, not a feature.  gcc
 does no such thing with its comments.

That would be because gcc is a C compiler, not a Java compiler.

Java permits you to write Unicode characters as escape sequences
like this: \u1234.  This translation can occur within comments, and
the above comment contains an illegal \u escape sequence.

  - Damien



Re: why not just use C /* ... */ ?

2000-08-23 Thread Damien Neil

On Thu, Aug 24, 2000 at 08:41:46AM +1000, iain truskett wrote:
 Does it try to parse other escape sequences (such as \t, \n, \r etc.) or
 just the Unicode one?

No, just the Unicode escapes.  Think of it as trigraphs in C -- it's
there so you can translate code from a more-featureful character set
into less-expressive one, without losing information.

 If just the Unicode one then I'd say the problem is a feature, not a
 bug (reversing my stance), but one we probably don't have to worry about
 since it's peculiar to Java. Right?

This might have some relevance to Unicode handling in Perl, but that's
a whole other can of fish.

- Damien



Re: $!

2000-08-17 Thread Damien Neil

On Thu, Aug 17, 2000 at 01:19:22PM -0500, Jarkko Hietaniemi wrote:
 I recently suggested in p5p that for many system calls it could be
 checked in *consta...darn, *compile* time whether they are used in
 void contect, and _abort_.  "No, I'm not going to let you get away
 with doing a chdir() and not caring."  For some other system/library
 calls, like print() and close(), this may too strict, but for those a
 run-time check could be made: if they either return an error (-1, or
 somesuch), or the errno flips (before the call errno would explicitly
 reset to zero), we would die.  Or warn.  Whatever.  As long as there
 would no way to completely ignore errors.  Though I suggested this in
 a p5p thread, this is definitely more like p6 fodder.

This is, of course, one of the main reasons that exceptions exist --
you can ignore exceptions, but you have to explicitly ask for it.

This is one of the nice things about Python, in my opinion.  Every
error is an exception, so you can feel free to completely ignore
errors when writing a quick one-off, safe in the knowledge that if
anything gets wrong, you'll be told.

Java combines what you're talking about (enforced error checking)
with exceptions; since every method that throws an exception must
declare the exception thrown, the compiler can (and does) enforce
that the caller explicitly deal with any exceptions that might
happen.  I find this quite nice under some situations, but I think
it's a bit more bondage-and-discipline than suits Perl.

Hmm.  It just occurred to me that you could combine your idea with
exceptions quite nicely: All core functions throw exceptions on
error, but only when called in a void context.  (As well as, perhaps,
when a given pragma is in effect.)  This way, old code which correctly
checks errors will run without modification.  Old code which
incorrectly ignores errors will get error checking.  (And old code
which correctly ignores errors breaks, which is probably enough of
a problem to torpedo the whole idea.  Alas.)

  open(FD, "foo") or die;   # Scalar context, no exception thrown.
  open(FD, "foo");  # Void context, exception thrown on error.

  - Damien



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

2000-08-16 Thread 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: Component wise || and RFC 82 (was Re: RFC 104 (v1) Backtracking)

2000-08-16 Thread 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 109 (v1) Less line noise - let's get rid of @%

2000-08-16 Thread Damien Neil

On Wed, Aug 16, 2000 at 10:24:09AM -0400, Karl Glazebrook wrote:
 It was the response which was blithe, it just re-iterated arguments we
 are all completely familar with and did not address my point in the RFC.

Then perhaps we need to agree to disagree.  I feel that a number of
people have addressed your points.

 and this is supposed to be good?
 
 presumably snrub() has a first line like my($apples, $oranges, $price)=@_
 and it would be far clearer to call it that way.

What makes you presume this?  Perhaps snrub() is something like this:

  sub snrub {
foreach (@_) {
  frobnicate $_;
}
  }

You appear to arguing that expressions in function argument lists should
not be evaluated in a list context.  Is this really what you mean?

  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!
 
 Python is really nice and we should endeavour to learn why a lot of people
 like it so much rather than telling them 'good riddance'. 

Certainly, we should steal whatever nice features it has that Perl lacks.
Perl should never try to BE Python, though; the world already has Python.
We don't need another Python, we need a better Perl.

One of the fundamental concepts in Perl is context.  Would you care to
address the point of what happens to context when you remove @ and %
prefixes?

- Damien



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

2000-08-16 Thread Damien Neil

On Wed, Aug 16, 2000 at 12:31:23PM -0400, John Porter wrote:
 Sorry, this is exactly the argument we get from the C/C++/Java heads,
 who find perl's lack of discrimination between strings and numbers so
 distasteful.  But if we can gloss over the difference between a string
 and a number, we could (not that we should) also gloss over the difference
 between an array and an associative array... or between an array and a
 ref-to-array.  Etc, etc.

You're right, it is pretty much the same argument.

Every language decides on a fundemental set of types to support.
In C/C++/Java, this boils down to scalars, arrays, and objects.
In LISP, you have lists and atoms.  Perl has settled on scalar/array/
hash.  (Well, OK, and typeglob, but that was always a bit odd.)

Each of these languages has good reasons for the choice it made.
I'm not saying that Perl's choices are better than everyone else's;
they are, however, Perl's.  I object to changing them and confusing
everyone without a very good reason indeed.

  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, context is everything.  There is no reason to expect (or demand)
 that $ variables are any more or less "trustworthy" than other variables.
 In fact, with tying, such trust is completely unwarranted.  Not to mention
 overloading.

Are you saying that a tied $a should be able to return a list in list
context?  I would hope not; this rather seriously breaks the principle
of least surprise.

 So, using $ and @ to impose context is a reasonable thing to do.
 Using @ to say "this variable can not be indexed by string" is not.

This is a reasonable statement.  (I was, you realize, arguing against
the removal of $ and @, not against alternate indexing mechanisms for
arrays.)

I'm not certain that I like the idea of string-indexed arrays; I don't
know that I like the thought that $a[5] and $a[05] might suddenly
mean something different.  I could probably be convinced that it isn't
a bad idea, though.

   - Damien



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

2000-08-16 Thread Damien Neil

On Wed, Aug 16, 2000 at 05:34:51PM -0400, Karl Glazebrook wrote:
  You appear to arguing that expressions in function argument lists should
  not be evaluated in a list context.  Is this really what you mean?
 
 I guess I do. I guess I just hate contexts!

Context is a fundemental part of Perl.  If you take out context, you
don't have Perl any more.  I'm not certain what you have, but it will
be a quite different language.

Perl 6 will be PERL 6.  A Perl 5 expert should not feel as if she is
learning a whole new language when she starts using it.  If you want
to create a whole new language that is almost, but not entirely,
unlike Perl, I think that this is not the correct place for it.

 If a function does stuff to lists it should take a list prototype.

This is certainly not the case in Perl 5.  I suppose this could
change.

Of course this would mean that every single Perl program in the world
would need to be rewritten in order to work with Perl 6.  This isn't
the sort of thing you can do automatically, either.

I really don't understand why you seem to want to make Perl 6 into
something that bears no resemblance to Perl 5.  This feels like
saying that the C9X standard should have made C into something like
Haskell, or that the Java 1.4 standard should turn that language
into a LISP clone.  If you didn't like the language in the first
place, why do you care what the next version is like?

   - Damien



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

2000-08-16 Thread Damien Neil

On Wed, Aug 16, 2000 at 09:04:00PM +0200, Kai Henningsen wrote:
 And context dependency is bad for people.

Actually, people deal very well with context dependency.

  "Have you paid Bill?"
  "Have you paid that bill?"
  "It looks like a duck's bill."
  "The President vetoed the bill."

 A rose is a rose is a rose. Human minds really don't like context  
 dependancy.

  "Rose rose to the rosy glow of dawn.  On the pillow beside her
   was a rose."

The context dependency in Perl is intentional.  It isn't an accident,
and it isn't a mistake.  You may not like it; that's perfectly OK.
But if you don't like it, you may well be best served by finding
another language.  Arguing that it should be removed will simply waste
your time and that of other people.

 - Damien



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

2000-08-11 Thread Damien Neil

On Fri, Aug 11, 2000 at 06:41:52PM +0100, Graham Barr wrote:
 I think I like plow() or maybe just weave()

weave() and ravel()?

  - Damien



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

2000-08-08 Thread Damien Neil

On Tue, Aug 08, 2000 at 09:46:04AM -0700, Nathan Wiger wrote:
 The RFC doesn't mention localtime() for just this reason. The idea would
 be localtime would be GONE in Perl 6, instead moved to Time::Local.
 date() would replace it.

Why is this a good idea?  Perl programs have been using localtime() for
over a decade.  Why do we suddenly want to make them all obsolete?  Is
the goal of Perl 6 really to require that every Perl program in creation
be rewritten?

I'm all for adding a new and improved time mechanism with a bit less
of the oddness localtime() carries, but does it really hurt us to leave
the old style in the core?

   $ ./p52p6 mydatescript
   localtime() no longer in core - use date() instead [importing
 Time::Local]

It would be a horrible idea to have every existing Perl program spit
out reams of warnings whenever running under Perl 6.

Let's keep Perl Perl.  Clean up the internals, yes.  Remove deprecated
features, yes.  Add nifty new functionality, yes.  Change everything
that looks the slightist bit ugly?  Please, no.

I would humbly offer that Perl 6 should run at least 90% of all old
Perl 5 scripts, without translation or compatability modules.  If it
doesn't, how can it be called Perl?

- Damien