Re: RFC: [] as the solitary list constructor

[Trey Harris]

In a message dated Sun, 6 Oct 2002, Noah White writes:

>
> On Sunday, October 6, 2002, at 01:50  AM, Brent Dax wrote:
>
> > Parens don't construct lists EVER!  They only group elements
> > syntactically.  One common use of parens is to surround a
> > comma-separated list, but the *commas* are creating the list, *not* the
> > parens!
> >
>
> Following this rule would mean that
>
>   $a = ();# $a is a list reference with 0 elements
>
> should not be a list reference at all and would appear inconsistent.

No, because there are zero commas.  Squint and you can see them. :-)

Trey

Re: RFC: [] as the solitary list constructor

[Smylers]

Larry Wall wrote:

> Parens don't construct lists in Perl 6.  They merely group.
> The only difference from Perl 5 is that if they happen to group a
> comma in scalar context, the comma acts differently, not the parens.

Do parens still provide list context on the left side of an assignment?
What do these two do:

  my $x = @ARGS;
  my ($y) = @ARGS;

Parens just grouping suggests that C<$x> and C<$y> should be the same
(which may well be good, as it's a subtle distinction which trips up
many beginners in Perl 5).  If so, what's the preferred way of getting
the 'other' behaviour?

Smylers

Re: RFC: [] as the solitary list constructor

[Luke Palmer]

> Do parens still provide list context on the left side of an assignment?
> What do these two do:
>
>   my $x = @ARGS;
>   my ($y) = @ARGS;
>
> Parens just grouping suggests that C<$x> and C<$y> should be the same
> (which may well be good, as it's a subtle distinction which trips up
> many beginners in Perl 5).  If so, what's the preferred way of getting
> the 'other' behaviour?

Maybe:?

my ($y) ^= @ARGS;

Luke

Re: RFC: [] as the solitary list constructor

[Smylers]

Luke Palmer wrote:

> >   my $x = @ARGS;
> >   my ($y) = @ARGS;
> 
> Maybe:?
> 
>   my ($y) ^= @ARGS;

Or (presumably equivalently):

  my $y ^= @ARGS;

But that's horrible.  Presumably with two or more variables the comma
would denote list context, so the caret is only needed for exactly one
variable.  That's an awkward special-case to have to introduce.

Though thinking about this more, it may not be too much of a problem.  A
main use of this in Perl 5 is with C<@_>.  Since Perl 6 will have named
sub params this will be much less common and may not be something to
worry about.

Smylers

Re: RFC: [] as the solitary list constructor

[Glenn Linderman]

Larry Wall wrote:

>I cringe every time someone says "Parens construct lists in Perl 6."
>Parens don't construct lists in Perl 6.
>
>: Additionally, parentheses have one inconsistency which brackets do not:
>: This is the following case, already shown on perl6-language:
>: 
>:  $a = ();# $a is a list reference with 0 elements
>:  $a = (10);  # $a is the scalar 10
>:  $a = (10, 20);  # $a is a list reference with 2 elements
>:  # ...
>: 
>: If the ability to construct lists with parentheses is removed, so is this 
>: inconsistency.
>
>I don't think that's an important inconsistency.
>  
>
So is it even true that

 $a = ();  # is this really a list reference with 0 elements?  Or is 
this just undef?  There is no comma...

-- 
Glenn
=
Not everything that is counted counts,
and not everything that counts can be counted.
 -- A. Einstein

Re: Draft Proposal: Attributes: "public" vs. "private"

[Dan Sugalski]

At 4:29 PM -0600 10/5/02, John Williams wrote:
>On Sat, 5 Oct 2002, Michael Lazzaro wrote:
>
>>  Dan Sugalski wrote:
>>  >
>>  > There won't be any direct access to attributes outside class methods
>>  > of the class that defines the attributes, unless Larry changes his
>>  > mind in a big way. (And, honestly, probably not even then) Instead
>>  > it'll all be accessed via lvalue methods. If an attribute is exposed
>>  > there's just an lvalue method created, if it's not exposed there
>>  > isn't.
>>
>>  Ack!  Hold on, there:  I'm being told that Damian thinks lvalues are
>>  probably out, and that Larry thinks that pseudo-attributes will be made
>>  accessed through the use of lvalues.  Please confirm, which is it?  I
>>  don't particularly care, I just want to write an example down in
>>  best-guess form.
>
>I think everyone agrees that some sort of simple accessor syntax will be
>included (instead of the getX/setX hack).  But will accessors _look_ like
>attributes or methods?

They'll look like methods, since attributes don't look like either of 
your alternatives. :) Besides, they'll *be* methods. Only class 
methods get to look directly at attributes and the syntax is 
different. I'd expect lvalue methods, but there are reasons to do it 
other ways.

>Personally, I hope they look like attributes.  But if they do, the perl5
>lvalue subs are not the way to do it.

Right, but since this isn't perl 5, there's not much of a problem 
there. Just because things are sub-optimal in perl 5 doesn't mean 
we're doomed in perl 6 to reimplement it the same suboptimal way. 
This is our chance to make brand new mistakes.
-- 
 Dan

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

Perl 6 summary for week beginning 2002-09-30

[Leon Brocard]

Perl 6 summary for week beginning 2002-09-30
This is yet another Perl 6 summary, documenting what has happened over
on the perl6-internals (where Parrot, the virtual machine that will run
Perl 6 is discussed) and perl6-language (where Perl 6 language design is
discussed) mailing lists. Piers is off on holiday (snowboarding and
parachuting, no doubt), so I will be your host for the next two weeks. A
particularly average week, so let's start off with the perl6-internals
list as usual.

  Getting started guide
Erik Lechak offered to help write a getting started guide to Parrot - he
thought (correctly) that there may be "a pressing need for a document
helping newbie developers figure out how to get started".

Unfortunately, Erik isn't a big fan of POD and attempted to code up a
better replacement. While POD may not be perfect, an awful lot of Parrot
developers are also Perl developers and POD is simple and good enough
for Parrot for now.



  Debugger debugged
Juergen Boemmels noticed that hitting the Enter key in the Parrot
debugger (pdb) caused a segfault and that this wasn't quite ideal
behaviour. He provided a patch which ignored empty lines, and after a
nudge from Aldo Calpini provided another patch which followed the
suggested behaviour in "docs/debugger.pod", instead repeating the last
command entered.



  Patch Master
The main patcher these recent weeks has been Leopold Toetsch, and he
kept it up this week as well. He provided patches to stop Parrot
permanently allocating increasing amounts of memory, fix a parser error
in imcc, add stats to life.p6 and more. In fact, so many patches that I
have a feeling he'll get CVS write access soon ;-)

  New allocator
Leopold had a play with plugging in the Doug Lea memory allocator,
providing a patch to configure in support for the current Parrot malloc,
the Doug Lea malloc, or ptmalloc in libc. He also attempted to plug in
Perl 5's malloc and found similar speed results. Later on, he created a
document to explain memory internals, continuing the recent trend for
more docs.







  Patches, patches everywhere
There have been a lot of pending patches recently, and Robert Spier
prodded us about them and hopes to have an automated weekly email nudge
too.



  Library name collisions
Steve Fink reported a problem with library name collisions. For example,
having "intlist.c" as well as "classes/intlist.c" and "key.c" as well as
"classes/key.c". Dan proposed a naming convention where classes start
with a CL_prefix, encodings with an EN_ prefix and character set stuff
with a CS_prefix, although it looks like a simpler solution may be
taken.



  core.ops ate my (miniscule) RAM
David Chan is using an itty bitty box (Cyrix with 32 MB of RAM) and
found that compiling Parrot failed due to lack of memory. Nicholas Clark
reminded us that you can disable the (faster, but needs more memory to
compile) computed goto core at configure time using "./Configure.pl
--cgoto=0".



  Parrot file list
There are a great number of source files in the Parrot distribution and
Mark Sparshatt gathered ideas for how to have a file list which
explained what each actually does.



  Interfaces
Over in perl6-language, Michael Schwern was asked at a recent Java
conference whether Perl 6 will support interfaces. He tried to describe
a likely interface and raised some problems with interfaces. This
spawned a huge thread about OO, interfaces, and some of the weirder OO
languages. Do we enforce strict interfaces? Are some methods allowed to
be optional?

One of the more interesting ideas would be to move from just using
prototypes to using Design-By-Contract features: pre- and
post-conditions and invariants. Dave Whipp seemed a big fan of the
Eiffel model, where it is possible to rename methods in a derived class.
There was lots of scary Perl 6 pseudocode including cars, MP3 players,
birds, and wings.

A little later, Schwern came back and worried about enforcing interfaces
on subclasses. One interesting approach is to follow Eiffel and only
allow subclasses to weaken the preconditions or strengthen the
postconditions of the parent. Weakening involves adding ORs,
strengthening ANDs. (More Foo and Bar pseudocode. Oh, and apparently
Schwern only has 2 toes).

There was a short sidetrack on having multiple versions of modules
running at the same 

Re: RFC: [] as the solitary list constructor

[John Williams]

On Sun, 6 Oct 2002, Luke Palmer wrote:

> > Do parens still provide list context on the left side of an assignment?
> > What do these two do:
> >
> >   my $x = @ARGS;
> >   my ($y) = @ARGS;
> >
> > Parens just grouping suggests that C<$x> and C<$y> should be the same
> > (which may well be good, as it's a subtle distinction which trips up
> > many beginners in Perl 5).  If so, what's the preferred way of getting
> > the 'other' behaviour?
> 
> Maybe:?
> 
>   my ($y) ^= @ARGS;

That's like saying 
$y = @ARGS[$_] for 0..+@ARGS;
so $y will probably end up with the _last_ element of @ARGS.

I suggest:

my $y = shift;   # if this still works in perl6
my $y = @ARGS[0];

~ John Williams

Re: Interfaces

[Nicholas Clark]

On Tue, Oct 01, 2002 at 04:01:26PM -0700, Michael Lazzaro wrote:
> 
> >On Tue, Oct 01, 2002 at 03:43:22PM -0400, Trey Harris wrote:
> >>You want something like
> >>
> >>  class Car is Vehicle renames(drive => accel)
> >>is MP3_Player renames(drive => mp3_drive);
> 
> I *really* like this, but would the above be better coded as:
> 
>   class Car is Vehicle renames(drive => accel)
>   has MP3_Player renames(drive => mp3_drive);
> 
>  implying a "container" relationship with automatic delegation?  
> Among the other considerations is that if you simply said
> 
>   class Car is Vehicle has MP3_Player;
> 
> the inheritance chain could assume that Car.drive === Vehicle.drive, 
> because is-a (inheritance) beats has-a (containment or delegation).  If 
> you needed to, you should still be able to call $mycar.MP3_Player.drive 
> to DWYM, too.

I don't think I like this. Assume that instead of an mp3 player my car
has a 007 CD autochanger.

then $car.drive is as we expect, Vehicle.drive, because inheritance beats
containment or delegation.

But I could get a nasty shock when I want to open the tray on the CD player,
call $car.eject, and the car fires me out through the sunroof.

I think that the first syntax

class Car::Q is Car renames(eject => ejector_seat)
is CD_Player renames(drive => cd_drive);

makes it more clear that I'd like to pick and choose which methods
the composite object gets from which parent.

Nicholas Clark
-- 
Even better than the real thing:http://nms-cgi.sourceforge.net/

Re: Interfaces

[Michael G Schwern]

On Sun, Oct 06, 2002 at 01:49:26AM -0400, Noah White wrote:
> >OTOH, Java interfaces have a loophole which is considered a design 
> >mistake.
> >An interface can declare some parts of the interface optional and then
> >implementors can decide if they want to implement it or not.  The 
> >upshot
> >being that if you use a subclass in Java you can't rely on the optional
> >parts being there.
> 
> Say what?!? I don't think so. If a JAVA class which implements an 
> interface does not declare all of the methods of the interface then 
> that class will be abstract and you won't be able to instantiate a 
> concrete instance of it. You are guaranteed that any concrete instance 
> of a class which implements an interface will contain ALL methods 
> defined by the interface.

This came up durning a talk at JAOO by Kevlin Henny entitled "Minimalism: A
Practical Guide to Writing Less Code" which is a nice talk, Java or not.
http://www.two-sdg.demon.co.uk/curbralan/papers.html

Slide 7, which is about obeying contracts, says:

Subclassing and implemented interfaces should follow substitutability

Unsupported operations or operations that do a 
little less or expect a little extra add complexity

and he went off on a short tangent during the talk about optional operations
in Java.

It is possible in Java to declare methods to be an "optional operation".
This means the subclass may or may not implement that method and if you try
to use an unimplemented method an UnsupportedOperationException is thrown.

Effectively, this means that for every optional method you want to use,
you've got to wrap it in a try block to catch the
UnsupportedOperationException, recover and try to do something else if it's
not there.  Makes using an optional operation complicated and error prone.

In effect, an optional interface is declaring "this method may or may not
exist" which ain't that useful.

I can't find the syntax or this or when it was introduced, might be 1.2, but
I see it mentioned in the Collection API and tutorial docs:

http://java.sun.com/docs/books/tutorial/collections/interfaces/collection.html

The Collection interface is shown below:
public interface Collection {
// Basic Operations
int size();
boolean isEmpty();
boolean contains(Object element);
boolean add(Object element);// Optional
boolean remove(Object element); // Optional
Iterator iterator();

http://java.sun.com/docs/books/tutorial/collections/interfaces/

To keep the number of core collection interfaces manageable, the JDK
doesn't provide separate interfaces for each variant of each collection
type. (Among the possible variants are immutable, fixed-size, and
append-only.) Instead, the modification operations in each interface are
designated optional: a given implementation may not support some of
these operations.  If an unsupported operation is invoked, a collection
throws an UnsupportedOperationException .  Implementations are
responsible for documenting which of the optional operations they
support.  All of the JDK's general purpose implementations support all
of the optional operations.

http://java.sun.com/j2se/1.4.1/docs/api/java/util/Collection.html

Method Summary

 boolean add(Object o)
  Ensures that this collection contains the specified element 
  (optional operation).

 boolean addAll(Collection c)
  Adds all of the elements in the specified collection to this 
  collection (optional operation).

 void clear()
  Removes all of the elements from this collection (optional 
  operation).

 boolean contains(Object o)
  Returns true if this collection contains the specified element.


I don't know basic Java syntax worth a damn, but I know its dirty little
secrets. ;)


-- 

Michael G. Schwern   <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance  <[EMAIL PROTECTED]> Kwalitee Is Job One
It's Absinthe time!

Re: Perl6 summary for week beginning 2002-09-30

[esp5]

> Someone mysteriously known only as "Ed" asked what the favored syntax would be
> to match negative multi-byte strings in Perl 6. It wasn't entirely clear
> what the question was, but one thing is sure: the Perl 6 pattern matching
> engine will have a lot of scope for optimisation.

Oops, sorry, just realized my mailing header info didn't contain my full name
(Ed Peschko). 

Anyways, the point was that multi-byte non-matching support was abysmal, 
and to propose a new syntax.  The fact that the best thing people could come
up with was:

(?:(?!union).)*

after a long brainstorming session of false starts and false solutions just 
points out to the fact that it could be simpler.

And I think that by making the concept of "character class" more generic 
(into a 'string class' as it were, where alternations can take 
arbitrary-length strings) matches a class of real world problems closely.
Ex: nested begin/end loops, ie 

BEGIN
<-['BEGIN''END'>+ |

END

as well as giving strong hints to the optimiser to do the match fast.

Ed

Re: Interfaces

[Noah White]

On Sunday, October 6, 2002, at 06:17  PM, Daniel B. Boorstein wrote:
[SNIP]

> I think there may be some confusion here. In java, there's no special 
> syntax
> to declare a method an optional part of the interface. All concrete 
> classes
> that implement the Collection interface still must define full-bodied
> C methods. It just so happens that by convention 
> some
> classes simply throw an UnsupportedOperationException, perhaps like so:
>
> public class MyStaticCollection implements Collection {
>   ...
>   public boolean add (Object element) {
> throw new UnsupportedOperationException("add not supported");
>   }
>   ...
> }

Yes, this is true and is a common way to stub out methods you may 
choose not to provide functionality for. For example, your code 
implements a JDK 1.2 interface, then you subsequently switch to the 1.4 
VM implementation for which that interface's API has changed and there 
are now 14 more methods to be implemented for which you don't care 
about :-) You still need to provide the method signatures in your 
concrete class, but as in your example above you can throw an 
UnsupportedOperationException within that method.  Or as Michael 
pointed out in the Collections interface, the add() method of a 
read-only Collection implementation will throw an 
UnsupportedOperationException.

I wouldn't call it a dirty little secret as Michael put it :-).  This 
is the right thing to do within the context of a contract. The contract 
does not guarantee that method functionality implemented by a concrete 
class does exactly a certain thing a certain way ( I'd like to see the 
language that does!). It only guarantees return type, optional 
parameters to accept and any CHECKED exceptions that need be thrown 
(and _importantly_, caught by the invoker), not actually what goes on 
in the method. If it did it wouldn't be an interface :-) Now, an 
UnsuppoertedOperationException is an UNCHECKED (subclass of 
RuntimeException) exception.

The weakness if any lies here. It would be nice for the compiler to 
tell me that I've invoked a method which is going to throw that 
exception, so I would know that I used a method that I probably 
shouldn't be using before it actually gets tapped at runtime which is 
too late and goes *boom*.

-Noah