Constants for catch return values? 
Author Message
 Constants for catch return values?

Hello,


http://www.*-*-*.com/ ), I saw, that the the error meaning return
value of catch was stored in a variable, to know this value:

|    set ::TCL_ERROR [catch error]

In C there are constants/defines for the possible tcl return values:
     * TCL_OK
     * TCL_ERROR
     * TCL_RETURN
     * TCL_BREAK
     * TCL_CONTINUE

What's about a possibilty in tcl to get rid of the numerical values of
catch, like there is no need while using the return option -code to
remember the numerical values?

What's about a dictionary or array inside the tcl namespace to access,
no, more or less to reference the numerical return values?

|    namespace eval ::tcl {
|        array set errorCodes [list \
|            ok 0 \
|            error 1 \
|            return 2 \
|            break 3 \
|            continue 4 \
|        ];
|    };

Or what's about letting catch return (optional) a tokens (ok, error,
return, break, or continue) instead of a numberical value (0-4)?

I know, I can do this on my own in my applications, but I start this
thread, because I think that there is an inconsistence between the tcl
command return and catch and the handling of return values.

Thanks for any thought, comment, etc.!

Best regards,

Martin Lemburg
UGS - Transforming the Process of Innovation



Sat, 28 Jun 2008 19:17:24 GMT  
 Constants for catch return values?

Quote:

> ...
> Or what's about letting catch return (optional) a tokens (ok, error,
> return, break, or continue) instead of a numberical value (0-4)?

This would break way too much existing code.  One of the features of Tcl has
been its high backward compatibility.


Sat, 28 Jun 2008 21:41:55 GMT  
 Constants for catch return values?
Hello Gerald,

sorry but I do not agree!

In tcl 8.5 we extended catch to allow a new optional parameter:

|    catch script ?resultVarName? ?optionsVarName?

Why not a syntax like this:

|    catch ?-tokenize? script ?resultVarName? ?optionsVarName?

Only if a script starts with "-\S" (RE) than a backward compability
would break.
Or to be much more tolerant, but not really tcl like (see switch) ...
if the first argument is not equal to "-tokenize", than it's the script
to be evaluated, but only if the count of arguments is not greater than
3!

We discuss sometimes matters about tcl 9.0 and some people try to
restrict language development to be always backward compatible, but
some things are perhabs better after breaking this compability.

In this case of the tcl command catch, I don't see really a real
backward compability problem.

Best regards,

Martin Lemburg
UGS - Transforming the Process of Innovation



Sat, 28 Jun 2008 21:57:51 GMT  
 Constants for catch return values?

Quote:

> Hello Gerald,

> sorry but I do not agree!

> In tcl 8.5 we extended catch to allow a new optional parameter:

> |    catch script ?resultVarName? ?optionsVarName?

> Why not a syntax like this:

> |    catch ?-tokenize? script ?resultVarName? ?optionsVarName?

> Only if a script starts with "-\S" (RE) than a backward compability
> would break.
> Or to be much more tolerant, but not really tcl like (see switch) ...
> if the first argument is not equal to "-tokenize", than it's the script
> to be evaluated, but only if the count of arguments is not greater than
> 3!

> We discuss sometimes matters about tcl 9.0 and some people try to
> restrict language development to be always backward compatible, but
> some things are perhabs better after breaking this compability.

> In this case of the tcl command catch, I don't see really a real
> backward compability problem.

Adding the -tokenize switch would preserve +99% backward compavility.

Sorry, did not think about that in the original posting.

Why don't you TIP this?



Sun, 29 Jun 2008 04:06:47 GMT  
 Constants for catch return values?

Quote:

> Why not a syntax like this:

> |    catch ?-tokenize? script ?resultVarName? ?optionsVarName?

Why a new option when a new command will serve you just as well:

proc exceptiontype code {
     set tokens [list ok error return break continue]
     if {$code < 0 || $code > [llength $tokens]} {
         return $code
     } else {
         return [lindex $tokens $code]
     }

Quote:
}

switch -exact [exceptiontype [catch ...]] {
     ok    { ... }
     error { ... }

Quote:
}

Commands are compositional (the big win of language), options are not.
Such an [exceptiontype] command has the potential for reuse, an option
is a special purpose piece of functionality.

-- Neil



Sun, 29 Jun 2008 04:58:46 GMT  
 Constants for catch return values?
You are right Neil!

Why not a command like yours exceptiontype?!

Just for one reason - if a programming language is alive, if enough
people think that it lacks something, than this issue has to be solved.

For sure, everybody can provide is own resolution for many issues.
But here, it is about tcl internals!

Programming with the tcl C-API, I never care for the numerical return
values! I always use the defines, like e.g. TCL_ERROR.
Programming within tcl using the command return I never care for the
numerical return values! I always use the defined tokens, the
replacements for the numerical return values, like e.g. error.
But using the command catch I always get numerical values and I have to
know the numerical representation of an "error" or "break". There is no
need for, and in my eyes this is a design "issue".
To solve this nobody should be forced to write a proc, to copy a proc
from the wiki into a package, to change the tcl library to contain such
a proc, etc..
It's about the language itself, which has to provide this support to
mask internal values with tokens at mostly every place where those
internal values occur, like already done in the return command.

That's the reason, why I asked for a discussion about this "issue"! Not
because I'm not able to create a selfmade, company or unique, evt.
"personal" resolution for this "issue"!

Best regards,

Martin Lemburg
UGS - Transforming the Process of Innovation

P.S.: Sorry, if the reply sounds harsh! I hope you don't feel flamed!



Sun, 29 Jun 2008 17:33:40 GMT  
 Constants for catch return values?
Hello Gerald,

I think about it, about to TIP this.

I'll take a look at the 8.5 sources, of the catch command and ... -
we'll see.

Best regards,

Martin Lemburg
UGS - Transforming the Process of Innovation



Sun, 29 Jun 2008 17:45:53 GMT  
 Constants for catch return values?
I think [exceptiontype] is less generic than it could (and should) be,
how about doing it like this:

proc listmap {list index} {
   set res [lindex $list $index]
   expr {$res eq ""? $index: $res}

Quote:
}

interp alias {} exceptiontype {} listmap {ok error return break
continue}

236 % exceptiontype 0
ok
22 % exceptiontype -1
-1
27 % exceptiontype 4
continue
23 % exceptiontype 5
5



Sun, 29 Jun 2008 18:01:18 GMT  
 Constants for catch return values?

Quote:

> You are right Neil!

Thanks!

Quote:
> Why not a command like yours exceptiontype?!

> Just for one reason - if a programming language is alive, if enough
> people think that it lacks something, than this issue has to be solved.

The point wasn't that the functionality shouldn't go into the core
(although, I don't think it should) but that implementing it as an
option (i.e. a special way of modifying the behaviour of a single
command) is the wrong way. Better to implement it as a command so that
it can potentially be reused (e.g. see Richard's elegant 2 line generic
version).

Quote:

> For sure, everybody can provide is own resolution for many issues.
> But here, it is about tcl internals!

> Programming with the tcl C-API, I never care for the numerical return
> values! I always use the defines, like e.g. TCL_ERROR.
> Programming within tcl using the command return I never care for the
> numerical return values! I always use the defined tokens, the
> replacements for the numerical return values, like e.g. error.
> But using the command catch I always get numerical values and I have to
> know the numerical representation of an "error" or "break". There is no
> need for, and in my eyes this is a design "issue".

> To solve this nobody should be forced to write a proc, to copy a proc
> from the wiki into a package, to change the tcl library to contain such
> a proc, etc..
> It's about the language itself, which has to provide this support to
> mask internal values with tokens at mostly every place where those
> internal values occur, like already done in the return command.

But Tcl already *does* provide a means to do this, as I pointed out on
the wiki (and you quoted at the start of this thread) [catch] will
itself let you hide the return code values:

set rc [catch { ... } res]
if {$rc == [catch error]} {
     # handle error

Quote:
} elseif {$rc == [catch break]} {
     # handle break
} elseif {$rc == [catch return]} {
     ... etc ...
}

-- Neil


Sun, 29 Jun 2008 19:57:19 GMT  
 Constants for catch return values?
Hi Neil,

thanks for your reply!

Quote:
> The point wasn't that the functionality shouldn't go into the core
> (although, I don't think it should) but that implementing it as an
> option (i.e. a special way of modifying the behaviour of a single
> command) is the wrong way. Better to implement it as a command so that
> it can potentially be reused (e.g. see Richard's elegant 2 line generic
> version).

I'm not of the opinion, that in this case a new command or procedure is
a better solution, than a new option to change the behaviour of this
command.

But this may be a more philosophical, than a technical discussion,
because my main point was to hide internals and to make it easier to
work in a congruent way with return codes.

But in the end your code example (if structure testing against [catch
...]) made me struggle, because ... you are right! There is already a
command to translate a return value token back into a return value!
Even if the return value token is not really a token, but the name of a
corresponding command!

I think I'll adapt this code pattern, but ... really I'm not really
satisfied with it.

Best regards,

Martin Lemburg
UGS - Transforming the Process of Innovation



Sun, 29 Jun 2008 20:29:54 GMT  
 Constants for catch return values?

Quote:

> |    catch ?-tokenize? script ?resultVarName? ?optionsVarName?

What would be the proposed handling of
  return -code 42 "The answer"
?

--



Sun, 29 Jun 2008 20:45:25 GMT  
 Constants for catch return values?
Hello Donald,

I would say, something that can not be tokenized, a catched return
value, that is out of the range of tcl internal return values, should
be returned without modification.

If I think more complex, than an application could perhabs register new
return codes (values and corresponding tokens), so that catch may look
after a matching return code and return the corresponding token.
The main problem, why I didn't mention it before, is, that 3rd party
packages may have problems with this. Package A expects the return
value 42 to be "theAnswer", but package B thinks 42 must be
"whatWasTheQuestion". A conflict I don't want to guilty for!

Richards procedure to return a value of a list - if indexable - or the
index - if out of range - answers your question, because that was the
not telled, but expected behaviour.

Best regards,

Martin Lemburg
UGS - Transforming the Process of Innovation



Sun, 29 Jun 2008 21:04:39 GMT  
 Constants for catch return values?
On 11 Jan 2006 04:29:54 -0800,

Quote:

> > The point wasn't that the functionality shouldn't go into the core
> > (although, I don't think it should) but that implementing it as an
> > option (i.e. a special way of modifying the behaviour of a single
> > command) is the wrong way. Better to implement it as a command so
> > that it can potentially be reused (e.g. see Richard's elegant 2
> > line generic version).
> I'm not of the opinion, that in this case a new command or procedure
> is a better solution, than a new option to change the behaviour of
> this command.

I rather agree.

We have [return -code break], so why should [catch] return a numeric
code?  I for one can never remember which is break and which is
continue.  I know they're 3 and 4, but I ALWAYS have to check the docs
to see which is which.  And what's worse, the main docs I use don't
actually say it, so I have it written down in a little note file.

Plus conversion from a numeric into a string on the existence of a
switch would likely be dirt-cheap to implement right there within the
[catch] command.  And vastly cleaner to read than having to wrap it in
another function call.  Especially when you're also involving [uplevel]
and other such uglies.  I'm all for a nice clean "-token(ize)" option!

Fredderic



Mon, 30 Jun 2008 00:19:20 GMT  
 Constants for catch return values?
On 11 Jan 2006 04:45:25 -0800,

Quote:

> > |    catch ?-tokenize? script ?resultVarName? ?optionsVarName?
> What would be the proposed handling of
>   return -code 42 "The answer"

Why is that an issue?  You can't specify the 42 by any other means, so
what does it matter if catch simply returns it as-is?

And if [return -code] is extended to accept names for other values, then
so would [catch -tokenize] be extended to return them.

Fredderic



Mon, 30 Jun 2008 00:24:25 GMT  
 Constants for catch return values?

Quote:

> Why is that an issue?  You can't specify the 42 by any other means, so
> what does it matter if catch simply returns it as-is?

> And if [return -code] is extended to accept names for other values, then
> so would [catch -tokenize] be extended to return them.

Each different -code should have distinct semantics, and the other parts
of the return system should be used to disambiguate them further if that
is so needed. Thus, 0 indicates success, 1 indicates error (and causes a
trace to be built), 2 indicates 'return' with all the handling of the
-level parameter that that implies, and 3 and 4 have very specific
meanings for things like loops... :-)

But what should these other values mean? Should we just have a single
new number (5) that indicates 'exception' and require people to use,
say, the errorCode value to disambiguate? (I suggest that because that's
intended to be a machine-readable list.)

Oh, the other tricky bit is that the space of error codes is universal
across all interpreters. :-)

Donal.



Mon, 30 Jun 2008 07:36:02 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Initialising a constant with a return value from a function

2. constant definition doesn't return value?

3. RETURN / RETURN-FROM and values

4. Line return in a (constant) string

5. return from catch

6. Return command inside a catch block?

7. problem with catch and return commands

8. catch/return: Is this the correct behaviour?

9. taking a constant value for variable data

10. "Lock constant value"

11. VARIABLE CONSTANT...VALUE ???

12. comparing variable width bus values with constants

 

 
Powered by phpBB® Forum Software