Re: [TCLCORE] TIP#239 Try/Catch/Finally syntax

[Twylite <tw...@cr...>]

Hi,
> Please do not require lots of nested parsing of lists and things like
> that either (especially lists of scripts) since working with those
> things in the compiler is really unpleasant.
>   
I take it from your proposal for "as {msgvar optsvar}" that this isn't 
considered "nested parsing of lists"?
> Out Of Scope! If someone needs something that complicated, they'll have
> to write their own code.
>   
Having to write your own control structure just because the existing one 
doesn't do what you need (or at least doesn't do it in a pretty way) is 
what this exercise is all about, and what we're trying to avoid 
happening again.

> I write quite a lot of Java code, and I don't think there's anything
> really worth it to be gained from OO exceptions. A list that folks can
> match against is good enough, and they can add their own complexity if
> they really want. We're building a bikeshed, not an aircraft carrier!
>   
Oh dear ... I was building a Jeep.

> Too complicated by far. Glob is enough. If people want to match by ouija
> board, they can write their own command. (To be clear, that's an example
> of a carrier deck, undoubtedly useful to some but not part of any
> sensible bikeshed...)
>   
It occurs to one that once upon a time there was a need for a simpler, 
prettier alternative to 
if/then/elseif/elseif/elseif/elseif/elseif/else.  And so [switch] was 
born.  It also occurs to me that in C a switch is over a set of integer 
values.  In Tcl it was obvious to make [switch] operate on strings, but 
not just that - it would be able to match against wildcard patterns _and 
regular expressions_.  And to do so it would add interface complexity 
and sacrifice performance (in particular it was necessary to specify the 
order of evaluation).

Are you _sure_ glob is enough?  I'm not.  So I want a syntax that 
doesn't preclude extension (in a pretty) to handle other options in the 
future.  And I'd like a syntax that allows developers to create these 
extensions outside the core, so that these options can evolve in future 
rather than end up in a length discussion that really has few facts and 
figures to back up things like "most developers" and "common case".
> I feel that you're chasing off in the wrong direction. Try this:
>
>    try script ?as {msgvar optvar}? ?handler...? ?finally script?
>
> Each handler is one of these:
>
>    on code script
>    trap glob script
>   
Versus:
  on code ?-howtomatch whattomatch? script

I cannot comment on the implications of byte-coding that, but I do feel 
that it is more consistent (on error vs trap), more flexible, etc.

Your proposal is of course extensible by adding new handler keywords in 
future (assuming the TIP proposers at the time can agree on the 
keyword), but this would have to be done in the core.

Regards,
Twylite