DEP-0010: Defaulted Element Reference Syntax

[Peter Housel]

Also requesting comments on the following standards-track Dylan Enhancement Proposal. Please send your comments to this group.

Abstract

The Dylan language currently provides bracketed element reference syntax as a shorthand for calls to the element and aref functions. This DEP proposes an element reference syntax for providing default values for element calls.

Full proposal

https://opendylan.org/proposals/dep-0010-element-otherwise.html

Reference implementation

https://github.com/dylan-lang/opendylan/pull/1195

[Carl Gay]

I would prefer to see "c[k] default d" as I mentioned on Gitter.  I do like that "otherwise" is used elsewhere already, but I think "c[k] otherwise d" looks a lot like "use d if c[k] is #f". I realize that interpreting it that way wouldn't make a huge amount of sense because "c[k] | d" already exists, I'm just trying to think of how a Dylan beginner might see it. Also "default" is exactly what it does.

If we used "default", what would it mean for the use of the name "default" as a local variable / parameter name, if anything?

[Carl Gay]

On Tuesday, March 5, 2019 at 2:01:12 AM UTC-5, Carl Gay wrote:

If we used "default", what would it mean for the use of the name "default" as a local variable / parameter name, if anything?

Sorry, I think this answer my question:

"The addition of this new legal syntax does not affect the interpretation of existing programs."

[peter...@gmail.com]

I think the answer to this is "yes", but just to be sure:

Is the 'otherwise-operand' always evaluated even when the element is present?

e.g.

let x = collection[i] otherwise (some-function())

would call some-function and discard its result if collection did have an element i

[peter...@gmail.com]

Is there any effect on execution order, say if you did something weird like

let i = "b"

collection[i := "a"] otherwise i

or

collection[i] otherwise (i:="c")

[Peter Housel]

Since this construct is syntactic sugar, it's exactly equivalent to element(collection, i:="a", default: i), and the order of execution for function calls (as defined in the DRM chapter 4) is first the function, then each of the arguments in order. So the order is one[two] otherwise three.

It would probably be good to add a paragraph laying out the execution order in the manner of the Execution Order Within Expressions section (pp 44-45 in the printed DRM).

 -Peter-

[Dustin Voss]

I would agree that “c[k] default d” makes more sense than “c[k] otherwise d”, but since “otherwise” is already a reserved word, it might be safer to use that.

But I am concerned that this:

c[3] otherwise (a * a)

would be fine, but this:

c[3, 2] otherwise (a * a)

would be a syntax error (because “aref” does not include “default:” in its generic function).

That seems a confusing symmetry break, and I’m tempted to vote against this on that basis.

-- 
You received this message because you are subscribed to the Google Groups "dylan-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dylan-lang+...@googlegroups.com.
To post to this group, send email to dylan...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dylan-lang/ce0e8c18-6e3e-4ea0-bdb8-767c1d4bb33f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dustin Voss]

Also, I really don't like how error-prone the otherwise-expression is.

let inc-square = (squares[a] otherwise a * a) + 1

is not going to do what it looks like it is going to do—especially since the reason for this DEP would be to shorten expressions where the spelled-out element call would be too obtrusive.

[Peter Housel]

On Thursday, March 7, 2019 at 2:02:23 PM UTC-8, Dustin Voss wrote:

Also, I really don't like how error-prone the otherwise-expression is.

let inc-square = (squares[a] otherwise a * a) + 1

is not going to do what it looks like it is going to do—especially since the reason for this DEP would be to shorten expressions where the spelled-out element call would be too obtrusive.

This is a valid point, one I don't have an answer for at the moment. Using this construct in any context beyond a simple let-expression or function argument might be error prone, especially if you're not expecting it.

Other things we thought about included c[a, default: a * a] and c[a; a * a] but those mix things that belong to the domain (the key) and things that belong to the range (the default value) in the same brackets. I didn't find that to be acceptable.

If no one can think of any better approaches I'm fine with tabling this proposal.

-Peter-