Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

changed behavior of return in TIP90

62 views
Skip to first unread message

phil...@gmail.com

unread,
Jul 20, 2018, 1:01:45 PM7/20/18
to

Hi,

We are noticing another change in the behavior of Tcl that I think traces back to changes in TIP90 in Tcl 8.5.

We used to see an error thrown for a malformed return statement, but now, the malformed return is tolerated.

In the below interpreter sessions, return_an_expr is defined as:

proc return_an_expr {} {
return expr { 1 / 1 }
}
---------------------------------------------------------------
% puts $tcl_version
8.4
% source proc_test.tcl
% return_an_expr
bad option "expr": must be -code, -errorcode, or -errorinfo
% set x return_an_expr
return_an_expr
% $x
bad option "expr": must be -code, -errorcode, or -errorinfo
% catch return_an_expr
1


% puts $tcl_version
8.6
% source proc_test.tcl
% return_an_expr
% set x return_an_expr
return_an_expr
% $x # Empty string
%
% catch return_an_expr
0


It seems like, perhaps, some error handling that used to be buried down in the interpreter's internal handling of return was removed and it wasn't replicated inside of the return command itself?

This isn't a high priority problem - we can tolerate the new behavior, but we are wondering if there is an oversight there?


Eric

unread,
Jul 20, 2018, 4:40:05 PM7/20/18
to
On 2018-07-20, phil...@gmail.com <phil...@gmail.com> wrote:
>
> Hi,
>
> We are noticing another change in the behavior of Tcl that I think traces
> back to changes in TIP90 in Tcl 8.5.
>
> We used to see an error thrown for a malformed return statement, but now,
> the malformed return is tolerated.

This is no longer an error. From TIP 90:

Specification
The return command shall have syntax:

return ?option value ...? ?result?
There can be any number of option value pairs, and any value at all is
acceptable for an option argument.
>
> In the below interpreter sessions, return_an_expr is defined as:
>
> proc return_an_expr {} {
> return expr { 1 / 1 }
> }

So in the above, expr is an option and { 1 / 1 } is its value.

8>< --------

and everything you are seeing is as expected. Instead of

> % catch return_an_expr

try

% catch return_an_expr resultvar optvar

and look at the value of optvar.

Eric
--
ms fnd in a lbry

phil...@gmail.com

unread,
Jul 25, 2018, 1:34:37 AM7/25/18
to
Thanks for the update!
0 new messages