Re: RFC 174 (v1) Parse C as C

2000-08-30 Thread Michael G Schwern

My first reaction to reading this was "Eww!"  Upon thinking, its
really not a reaction to the RFC, but to indirect object syntax.  IMHO
I'd really like to see indirect object methods eradicated in Perl 6.
Too many precidence problems, too many special cases, too confusing to
teach.  Muddles up the otherwise simple function call.

Its syntactic sugar, and there's too much crap, not enough sugar.

However, as Damian said, dumping indirect objects is a seperate issue.
This RFC is about fixing them, so let's look at it like that.

I see a flaw.

The following order of function parsing should apply to Perl 6:

1. The current package should be checked for a function
by that name (including any imported ones), consistent
with current behavior.

2. Argument 1 should be checked to see if it is a valid
object reference. If so, the method should be checked
for existence as a member.

3. AUTOLOAD should be called.

The only new step here is step #2. Notice that this does NOT override
current-package functions. Only if a function is not found in the
current package is the translation attempted.

Okay, now look at this example...

$xa = abs($x); # main::abs($x) || $x->abs

Apparently, CORE will not be checked as part of the function parsing!
Here's a few cases where this will screw up...

- $x is an object with numerific convertion (0+) overloaded.  In this case,
  the programmer might not even be aware that $x is an object.  If 
  $x->can('abs') then instead of the expected CORE::abs($x), $x->abs will
  be called.  Unexpected behavior.  This can be generalized into any sort of 
  overloaded object.  It won't mix.

- $x is a normal object and writes this:

foo($x);

  Intending to call main::foo() with $x as the first argument.  However, he's
  forgotten to import foo(), a common mistake.  Normally, this would
  be a simple error found by Perl.  With this RFC, if $x->can('foo')
  its not an error anymore!  It becomes a method call.


Now, about that first comma.

It smells like allowing the first comma to be optional is a potential
nightmare for the parser.  

Worse yet, you're turning a common typo into syntax!  Accidentally
dropping a comma or a period is a fairly common mistake, but its also
a simple syntax error which Perl catches easily.  Now if it suddenly
has language meaning, the error messages can become mysterious.

foo($x @args);

This might call $x->foo(@args), or it might complain that $x is not an
object, or it might complain that foo() is not a method of $x.
Depends on the situation.  Problem is, you've taken a simple error and
turned it into a complicated on with potentially confusing messages.
Or worse, it becomes valid syntax!

(I'd like to note that the current error "Array found where operator
expected" isn't too great either.)

The caveats associated with:

$r = new(CGI @args);

also bother me.  The conflict between CGI being a function in the
current scope and it being a class is hairy.


Which all leads me to want to dump indirect object syntax altogether,
but I already said that. :)

-- 

Michael G Schwern  http://www.pobox.com/~schwern/  [EMAIL PROTECTED]
Just Another Stupid Consultant  Perl6 Kwalitee Ashuranse
Sometimes these hairstyles are exaggerated beyond the laws of physics
  - Unknown narrator speaking about Anime



Re: RFC 238 (v1) length(@ary) deserves a warning

2000-09-15 Thread Michael G Schwern

Interesting point you made about context.  $size = @array is typically
the first introduction of the idea of contexts to a new programer.


On Sat, Sep 16, 2000 at 03:38:47AM -, Perl6 RFC Librarian wrote:
> (2) require changes to the prototype system to permit length() to
> still be overridable.

I'm surprised there hasn't be a good overhaul of the prototyping
system proposeed yet.  Your length() propsal wouldn't be the only
think that can't be prototyped.  print() is the simplest example.  The
limitations of the prototyping system shouldn't be a reason to hold
back length(@array).  Your arguments about teaching context is enough,
though.

Perhaps we need prototype support for polymorphic functions? 
(Something like RFC 97).

-- 

Michael G Schwern  http://www.pobox.com/~schwern/  [EMAIL PROTECTED]
Just Another Stupid Consultant  Perl6 Kwalitee Ashuranse
Plus I remember being impressed with Ada because you could write an
infinite loop without a faked up condition.  The idea being that in Ada
the typical infinite loop would be normally be terminated by detonation.
-- Larry Wall in <[EMAIL PROTECTED]>



Re: RFC 238 (v1) length(@ary) deserves a warning

2000-09-15 Thread Michael G Schwern

On Sat, Sep 16, 2000 at 04:21:15PM +1100, Damian Conway wrote:
>> I'm surprised there hasn't be a good overhaul of the prototyping
>> system proposeed yet. 
> 
> What exactly didn't you like about RFC 128???

Ummm... the fact that its title doesn't match /proto/.  My bad.

Okay, its a proposal to overhaul prototyping, cool.  But I don't see
anything to allow C and C live
together.  Its a big RFC, I probably missed it.

-- 

Michael G Schwern  http://www.pobox.com/~schwern/  [EMAIL PROTECTED]
Just Another Stupid Consultant  Perl6 Kwalitee Ashuranse
Cheating is often more efficient.
- Seven of Nine