Open/close design: A familiar HTML-like syntax as an alternative

[stasm]

My goal is, as usual, to avoid adding new sigils to the syntax. Instead, I’d like to leverage the fact that we already have the concept of keywords in the syntax. Furthermore, with #469, we were able to find a good solution by adding a new keyword (input). I think we can try to do the same here.

This PR is a slightly expanded version of my comment in #470 (comment).

[aphillips]

Still digesting...

[aphillips]

openclose is weird. How about span (for spannables) and tag (for standalone tags)?

[stasm]

I like the suggestions.

(I may have become a connoisseur of intended ugliness at the design stage ;) )

[eemeli]

This part is pretty much orthogonal to the design doc objective:

Describe the use cases and requirements for expressions
that enclose parts of a pattern
and develop a design that satisfies these needs.

If/as we should discuss packaging options to a message-local tag, that should be separate from this doc.

If we go with {+foo} / {-foo}, then something like

local +foo = ...

is probably considerable. On the other hand, with {foo} / {/foo}, a separate keyword or two is probably a right answer:

tag foo = ...

In that case, I do believe that you'll find that a single tag is quite sufficient, rather than needing a wholly separate one for standalone tags. We do not need to build congruence into the language at this level to guarantee that a local {foo} will never be used as {foo/}; that's properly handled via the registry.

As far as I've understood, the design docs are meant to rationalize decisions, rather than discussions. So we can have a discussion spanning more than one doc leading to two related conclusions.

[stasm]

On the other hand, with {foo} / {/foo}, a separate keyword or two is probably a right answer:

tag foo = ...

In that case, I do believe that you'll find that a single tag is quite sufficient, rather than needing a wholly separate one for standalone tags. We do not need to build congruence into the language at this level to guarantee that a local {foo} will never be used as {foo/}; that's properly handled via the registry.

You're right, two declarations duplicate some of the responsibilities of the registry. I originally started out with just a single declaration, but then decided that it was better to be overly specific rather than too generic for the purpose of the design process.

I'll push an update later today. tag? markup? element?

[stasm]

Also, I think you're also right that adding declarations addresses a different set of problems. I'm okay with moving declarations to another proposal ("open/close declarations") and keeping this doc focused on "open/close expressions".

[eemeli]

I'll push an update later today. tag? markup? element?

I'd prefer at most 5 characters, given that that's the max otherwise.

[aphillips]

I'd prefer tag, since it isn't opinionated that the tag is markup, but not so unopinionated (element) that it has little meaning. Also, it's short. I can add this to the list for a captive audience today.

[eemeli]

Having originally proposed {foo}...{/foo}, I would be happy to accept it. But in addition to that, this PR is scope-creeping the design doc beyond its reasonable limits.

[eemeli]

This part is pretty much orthogonal to the design doc objective:

Describe the use cases and requirements for expressions
that enclose parts of a pattern
and develop a design that satisfies these needs.

If/as we should discuss packaging options to a message-local tag, that should be separate from this doc.

If we go with {+foo} / {-foo}, then something like

local +foo = ...

is probably considerable. On the other hand, with {foo} / {/foo}, a separate keyword or two is probably a right answer:

tag foo = ...

In that case, I do believe that you'll find that a single tag is quite sufficient, rather than needing a wholly separate one for standalone tags. We do not need to build congruence into the language at this level to guarantee that a local {foo} will never be used as {foo/}; that's properly handled via the registry.

As far as I've understood, the design docs are meant to rationalize decisions, rather than discussions. So we can have a discussion spanning more than one doc leading to two related conclusions.

[stasm]

I've removed the declarations; I'll create a new design doc for them. This PR is now much more tame.

What else should I add here? Right now it's just listed as an alternative, so I think it should be more or less ready to merge.

[aphillips]

I think this is relatively difficult to contemplate. We will want unquoted literals for keys. Is unquoted literals for operands different enough a use case?

[gibson042]

Hmm, I think I agree. Expressions basically break down into

• literal with optional function
• variable with optional function
• operand-free function
• spannable open/close

If both variables and functions use a sigil, then I think spannables should as well, leaving literals as the sole sigil-free expression contents (and with consistent quoting requirements regardless of where they appear).

[stasm]

I filed #518 to discuss this further, orthogonally to this PR.

[aphillips]

If we required the namespace prefix for spannables, that eliminates the problem with unquoted literals (at the cost of some lookahead when parsing). But it would make for some confusion in the regular syntax. Don't forget that we allow {:function no=operand} and this looks like an open (is it a syntax error to omit the / at the end?)

[eemeli]

Merging this into the proposal for ease of presentation, as it's still "proposed" and this is one of the two serious options being considered.