-
-
Notifications
You must be signed in to change notification settings - Fork 34
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
Beauty Contest for Various Syntaxes #485
Conversation
Co-authored-by: Stanisław Małolepszy <[email protected]>
- number the options - add a mixed option - clean up some of the options
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if this is still relevant, as I missed the last call, but added some fixes and clarifications at least for posterity's sake.
I think 3, 5, 5a, and 6 are all unworkable as currently presented, as they would require escaping #
or [
in addition to {}
in patterns. If that's an additional cost we're willing to consider, or if there's a way to mitigate that cost, it should be explicitly noted here.
Only the line comments with suggestions are intended as blocking here.
Removing numbering per discussion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aphillips I added Option 1a directly on the branch, and fixed the Option 0 syntax.
I've also ported and expanded on my previous line comments that got obsoleted by the file name change. All of the syntax proposals except for 1a have requirements that need to be taken into account when deciding between them. For example, needing to escape [
or ;
in any pattern is a pretty significant requirement.
I also spotted a couple of inconsistencies in the examples; suggested fixes for those are also included.
input $foo :function option=value | ||
}{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm presuming from the preceding example that the match
statement may also go in the block. Or does it need a separate block, and does that also start with {#
?
input $foo :function option=value | |
}{ | |
input $foo :function option=value |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The original theory was: "declaration block" and "body block". The body block only needs to be bracketed when it contains code (i.e. a match
). There's no reason to have blocks if they aren't separate (that would just be option 2 then)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, ok. Then I think lines 257 and 259 may need fixing, because together with this we've got all of:
{ match
{#match
match
I can't tell which of these three is the proposed syntax here.
Co-authored-by: Eemeli Aro <[email protected]>
Co-authored-by: Eemeli Aro <[email protected]>
Co-authored-by: Eemeli Aro <[email protected]>
Co-authored-by: Eemeli Aro <[email protected]>
Fix the syntax to be workable. Change "inside a pattern" to "in a pattern" because "inside" implies interior to the pattern, not necessarily on the ends.
Co-authored-by: Eemeli Aro <[email protected]>
Co-authored-by: Eemeli Aro <[email protected]>
Co-authored-by: Eemeli Aro <[email protected]>
Co-authored-by: Eemeli Aro <[email protected]>
Co-authored-by: Eemeli Aro <[email protected]>
Co-authored-by: Eemeli Aro <[email protected]>
063d558
to
1993659
Compare
Co-authored-by: Eemeli Aro <[email protected]>
Co-authored-by: Eemeli Aro <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this could be merged now, so that it can have better visibility.
Merging this in preparation for the stackranking exercise. |
This was discussed in the 2023-09-25 call.
This is creating a scratch pad for different syntax options for starting in text mode, with an eye towards choosing one of them to proceed. The goal here is to choose an "operating theory" of what kinds of messages users want to write, so the choice of sigils and keywords and such are mutable. Bring what you've learned in that past few years of working on this problem.