Return values declarations and the block/exception exception

[Carl Gay]

The syntax for the `exception` clause always throws me. I think it's the only place where a variable can be declare but the variable name is optional and the type is not. To be specific,

    block () ... exception (<error>)

does handle exceptions of type <error> and may be, but is not required to be specified as 

    block () ... exception (ex :: <error>)

In contrast, return value specifications of that same form are a mistake. That is,

    define function f() => (<time>)

is equivalent to

    define function f() => (<time> :: <object>)

On the plus side, the compiler gives us a nice warning for the incorrect form above:

    Warning - The untyped variable <time> in the parameter list of { define constant f } looks like a type.

but on the negative side, it is frequently necessary to provide names for return values even when it's sort of pointless.  Consider these examples I find in a quick search of the Open Dylan code:

// Predicate return values are probably the classic example.

define inline function upper-case-code? (code :: <integer>) => (true? :: <boolean>)

// Couldn't think of a better name than result.

define sealed method string-compare
    (string1 :: <byte-string>, start1 :: <integer>,
     string2 :: <byte-string>, start2 :: <integer>, count :: <integer>)
 => (result :: <integer>)

// Just repeating the function name in the return value name. Do not want.

define function as-iso8601-string (date :: <date>, #key precision :: <integer> = 0)
 => (iso8601-string :: <string>)

// The name adds no information above and beyond the return type.

// (In fact it's inaccurate.)
define method parse-date-string (date :: <string>, format :: <string>)
 => (date :: false-or(<date>))

I find myself more and more just using  underscore as the return value name in cases such as these.  So why not switch the semantics so that it's like block/exception?  <error> means type <error> and probably-a-network-error :: <error> gives it a more meaningful name when it's useful.

I believe that since there are so few users, and since the compiler currently produces a nice warning for the "mistake" above, and because we have no such warnings in our code, the transition would actually be quite easy.  Just change the semantics in the compiler and once we have a release that has the new semantics and can be used as a bootstrap compiler we allow the new semantics to be used in compiler code.

-Carl

ps. To clarify my intentions, I have a ton of issues like this that I've written down over the years. I'm not saying this is an urgent change at all; just a desirable change. I'd like to get feedback from the community (you're still out there, right?) and if there seems to be some agreement I'll write up a Dylan Enhancement Proposal that we can implement whenever we decide the time is right.

[Carl Gay]

On Monday, January 20, 2020 at 8:38:20 PM UTC-5, Carl Gay wrote:

I believe that since there are so few users, and since the compiler currently produces a nice warning for the "mistake" above, and because we have no such warnings in our code, the transition would actually be quite easy.  Just change the semantics in the compiler and once we have a release that has the new semantics and can be used as a bootstrap compiler we allow the new semantics to be used in compiler code.

Not quite that simple, of course. We would need to change parameter lists of the form (a, b, c) to (a :: <object>, b :: <object>, c :: <object>) and although I don't normally write code that way these days I believe that was much more common in the OD code so that could be a show-stopper for this idea.  There are possible solutions to make that transition, like adding a build option to assume a "type" without "<" and ">" is type "<object>".

In any case, I'm interested in the language design question regardless of practical considerations like this. :-)