Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[=ref=] syntax should work on abstract-op type definitions too #809

Closed
domenic opened this issue Sep 8, 2016 · 9 comments
Closed

[=ref=] syntax should work on abstract-op type definitions too #809

domenic opened this issue Sep 8, 2016 · 9 comments

Comments

@domenic
Copy link
Collaborator

domenic commented Sep 8, 2016

They're basically dfns that we want to preserve the case of.

@tabatkins
Copy link
Collaborator

I know I tried to do this once (unifying them under the supercategory "term"), but it turns out, for arcane and unnecessary reasons that are nevertheless hard to fix, that having both CS and CI categories in the same supercategory makes things screwy and terrible.

I should try it again, since I've forgotten all the details of what went wrong.

@jyasskin
Copy link
Collaborator

I'd be ok with a different shorthand too. <a></a> was actually fine for dfns; it's only 3 characters more than [==] anyway. It's <a abstract-op></a> that I want a shorthand for.

@tabatkins
Copy link
Collaborator

I can do that easy. I'd like to continue the syntax of square-bracket + something else; any suggestions for the something else? [|SomeFoo|], [$SomeFoo$], etc?

@domenic
Copy link
Collaborator Author

domenic commented Oct 12, 2016

Hmm, it'd be ideal if I didn't have to know the difference at the call site... I'd personally prefer to hold out until you can fix the architectural issues preventing [==] from working for both.

@tobie
Copy link
Contributor

tobie commented Nov 9, 2016

Actually, if we want to be passing args as in:

<a abstract-op>FooBar</a>(|arg|, |arg|, |arg|)...

Then having a different shorthand notation for abstract ops seems a better strategy.

It also would be nice to be able to include Ecmarkup "!" "?" prefixing without having to manually auto-link those.

All in all, I'd love for:

!FooBar(|x|) 

to just turn into:

<a data-link-type="dfn" href="https://tc39.github.io/ecma262/#sec-algorithm-conventions">!</a>
<a data-link-type="abstract-op" href="#FooBar" id="ref-for-FooBar-1">FooBar</a>(<var>x</var>).

No idea whether that's possible or not given your parser, etc.

@TimothyGu
Copy link
Contributor

TimothyGu commented Sep 9, 2017

I would be happy enough just to have a dedicated syntax for abstract ops because of #861.

[|ToString|](|val|) and [!ToString!](|val|) both look just fine to me.

@domenic
Copy link
Collaborator Author

domenic commented Oct 23, 2017

This is causing issues for the WebAssembly spec now as well; /cc @littledan. I believe he is categorizing abstract ops as dfns, understandably because <a abstract-op>X</a> is a lot longer than [=X=]

@littledan
Copy link

I'd also be happy with some other fancy bracket combination!

@tabatkins
Copy link
Collaborator

All right, I went with [$AbOp$] syntax.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants