develooper Front page | perl.perl6.language | Postings from March 2005

Re: Parameter and trait questions - just how 'only' _is_'read-only'?

Thread Previous | Thread Next
Uri Guttman
March 26, 2005 21:04
Re: Parameter and trait questions - just how 'only' _is_'read-only'?
Message ID:
>>>>> "LW" == Larry Wall <> writes:

  LW> As I mentioned in my other message, I think we should not assume that
  LW> Perl 6 works the same in this regard as Perl 5 does.  There needs to be
  LW> something we can return that not only means (), but means also means
  LW> "You're hosed! (And here's why.)"  And I think we can make undef mean
  LW> that if we make it lazily sensitive to scalar/list context (much like @a
  LW> itself can be lazily sensitive to context).

  LW> Hmm, maybe it would simpler to just tell everyone undef is a special empty
  LW> lazy array that refuses to produce a value no matter how you ask.

why use undef for the error code? isn't this what exceptions are for? or
setting $!? i actually use naked return as a postive thing in stem
(string return values are bad and have the error string. it is
consistant so it works). the problem with returning undef (or naked
return) is that it is in-band data. now you could do a naked return but
error thing. and then the called has to check for that property each
time. but what does that mean when you do this (bad p6 code):

	sub return_error { return but error }
	my @a = return_error() ;

is @a empty or what? how do you see the error in @a?

i just don't like seeing undef used for error handling as it has too
many other uses (even if i did it in stem). just make undef a scalar
value and not a function nor a error marker.


Uri Guttman  ------  --------
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs  ----------------------------

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About