On 2010-05-26, at 1:53 am, Moritz Lenz wrote:
> After playing with the first submission, the hash of types is what I found
> most useful.
> See
> http://github.com/moritz/process-cmd-args/blob/master/process-cmd-args.p6#L256
> for some code that actually generates it by introspecting the signature of
> sub MAIN.
I was looking at that after I posted my code (and the cute work-around for "but
False" too). I love seeing the things that P6 will make possible. (I had
actually been thinking of passing the types as strings... how P5 of me!)
> Great to hear that. Is there anything (except better error reporting) that
> Rakudo could do to further ease the learning?
I figure that any obvious things -- like the error messages -- can't be easy,
or they'd already be done! Although sometimes the errors didn't even include a
line number; I can see that it might be difficult to know even which line the
"real" error occurred on, but is it feasible at least to report the last
"known" (good) line number? That would help narrow it down sometimes.
The difficulties in keeping a list of what does and doesn't work have been
mentioned before, but I wonder if some of that could be included in a partial
way in the error messages we do have.
For example, the error from trying to use "but False" mentioned "does", so
Rakudo understood at least part of what I was trying to say. If the error had
a broad message tacked on the end ("... [does/but not yet implemented]") or
something like that, it would provide a clue as to whether I or Rakudo was the
more confused.
Such messages could be helpful even if they weren't very specific, and having
them in the code would be easier to maintain than a separate list that needs to
be kept in synch. ....or maybe not!
-David
