3 ms·

You can actually use ";" as an alias for "end" in Pyret, so you could write: data BinTree: | leaf | node(value, left, right); We use "end" or ";" in order

by jpolitz 13y ago

You can actually use ";" as an alias for "end" in Pyret, so you could write: data BinTree: | leaf | node(value, left, right); We use "end" or ";" in order to have unambiguous delimiters for the ends of syntactic forms and avoid needing to depend on whitespace (we added some discussion on pyret.org about our philosophy on indentation and why we don't want to depend on whitespace). Making that leading pipe optional is a good idea. I made an issue for it, we'll think about if it'll break or confuse anything and add it if it doesn't: https://github.com/brownplt/pyret-lang/issues/106

e12e 13y ago
I realize it's a trade-off -- but I think having ";" as an alias for "end" (or vice-versa) is a pretty bad idea. I personally prefers python's indentation-for-blocks syntax, but I understand why you want semantics to be decoupled from indentation. But when using explicit end-markers, I'd prefer to match them to the start, maybe even introducing some verboseness, like: end-case, end-if etc -- maybe taking it further and allow/demand naming of blocks: check: 4 + 5 is 9 1 / 3 is 2 / 6 9 - 3 is 6 5 > 4 is true end Then becomes, not wrapped in end-check, but: check(arithmethic-test): 4 + 5 is 9 1 / 3 is 2 / 6 9 - 3 is 6 5 > 4 is true end(arithmethic-test) Or something similiar. This makes mis-matching "end"s (either typos or artifacts from cut'n'paste coding) explicit errors that are easy to spot, and identify. It would add a lot of verbosity, of course. As for ";"/"end", consider (the presumably valid): check: 4 + 5 is 9 1 / 3 is 2 / 6 9 - 3 is 6 5 > 4 is true ; That trailing ";" is going to trip someone up. Also consider (cut'n'paste-with-quick-edit): check: 4 + 5 is 9 1 / 3 is 2 / 6; 9 - 3 is 6 5 > 4 is true; end Is this valid?
- fgoodman 13y ago
  Having ; on a new line is valid, but having both ; and end on a block is invalid.
- skrishnamurthi 13y ago
  I have wrestled with "uniform closing" vs "non-uniform closing" designs for ages. For those not clear on what I mean here's an example: Lispy syntaxes have a uniform close (it's always ")"), whereas XML syntaxes don't (you have to put the name of the opening tag in the closing token). So e12e is making an argument for XML-y over Lispy. However, choosing good words is really, really hard. If you pick a different word for each construct, there's a needless mental burden; if you pick a uniform strategy ("end-<kwd>") you potentially get less readable code. And either way it's far more verbose, as you point out. Some of our target audiences are middle- and high-school students, some of whom have weak typing skills (we know from numerous workshops we run). Increasing even the raw number of characters is a real problem for them. My preference is to use ; for one-liners, but end where you have a multi-clause entity and you want to be able to clearly tell where it ends. If we find that there is general agreement on this, we can make it a context-sensitive check, à la indentation. Then, a program generated by a tool can do something consistent and ignore all these checks, whereas human-facing environments would enforce them (by checking or correcting). As for your examples, to my Pyretical eye, the third of your examples (with the dangling ";") looks just wrong. However, your fourth example is syntactically incorrect.
  - e12e 13y ago
    > Some of our target audiences are middle- and high-school students, some of whom have weak typing skills (we know from numerous workshops we run). Increasing even the raw number of characters is a real problem for them. I certainly understand this argument, and I generally favour simple syntax over smart tools -- but how much of a difference would this make in an editor/IDE that automatically inserts the closing-tag? (you type case, the editor appends esac (but below the point you're typing)): 1: | #your cursor at | 2: case| 3: case: | # you hit enter or something, ready to fill in esac # editor has closed block/statement I imagine typing-skills isn't much of an issue when editing/copying text -- as opposed to typing in new code?
    - skrishnamurthi 13y ago
      An express design goal is to not bake in assumptions about an editor. Programmers really like their editing tools. I've lived through the waves from vi to Emacs to vim to Sublime Text to what-have-you. We'd really, really like to make the language pleasing to work with without depending on an editor (indeed, each of us seems -- perhaps by accident -- to be using a different editor for Pyret, which may be influencing our decision). When editing/copying, it's not typing skills but editing skills, which are arguably subtler and even harder.

by jpolitz 13y ago

e12e 13y ago

I realize it's a trade-off -- but I think having ";" as an alias for "end" (or vice-versa) is a pretty bad idea. I personally prefers python's indentation-for-blocks syntax, but I understand why you want semantics to be decoupled from indentation. But when using explicit end-markers, I'd prefer to match them to the start, maybe even introducing some verboseness, like: end-case, end-if etc -- maybe taking it further and allow/demand naming of blocks: check: 4 + 5 is 9 1 / 3 is 2 / 6 9 - 3 is 6 5 > 4 is true end Then becomes, not wrapped in end-check, but: check(arithmethic-test): 4 + 5 is 9 1 / 3 is 2 / 6 9 - 3 is 6 5 > 4 is true end(arithmethic-test) Or something similiar. This makes mis-matching "end"s (either typos or artifacts from cut'n'paste coding) explicit errors that are easy to spot, and identify. It would add a lot of verbosity, of course. As for ";"/"end", consider (the presumably valid): check: 4 + 5 is 9 1 / 3 is 2 / 6 9 - 3 is 6 5 > 4 is true ; That trailing ";" is going to trip someone up. Also consider (cut'n'paste-with-quick-edit): check: 4 + 5 is 9 1 / 3 is 2 / 6; 9 - 3 is 6 5 > 4 is true; end Is this valid?

fgoodman 13y ago
Having ; on a new line is valid, but having both ; and end on a block is invalid.
skrishnamurthi 13y ago
I have wrestled with "uniform closing" vs "non-uniform closing" designs for ages. For those not clear on what I mean here's an example: Lispy syntaxes have a uniform close (it's always ")"), whereas XML syntaxes don't (you have to put the name of the opening tag in the closing token). So e12e is making an argument for XML-y over Lispy. However, choosing good words is really, really hard. If you pick a different word for each construct, there's a needless mental burden; if you pick a uniform strategy ("end-<kwd>") you potentially get less readable code. And either way it's far more verbose, as you point out. Some of our target audiences are middle- and high-school students, some of whom have weak typing skills (we know from numerous workshops we run). Increasing even the raw number of characters is a real problem for them. My preference is to use ; for one-liners, but end where you have a multi-clause entity and you want to be able to clearly tell where it ends. If we find that there is general agreement on this, we can make it a context-sensitive check, à la indentation. Then, a program generated by a tool can do something consistent and ignore all these checks, whereas human-facing environments would enforce them (by checking or correcting). As for your examples, to my Pyretical eye, the third of your examples (with the dangling ";") looks just wrong. However, your fourth example is syntactically incorrect.
- e12e 13y ago
  > Some of our target audiences are middle- and high-school students, some of whom have weak typing skills (we know from numerous workshops we run). Increasing even the raw number of characters is a real problem for them. I certainly understand this argument, and I generally favour simple syntax over smart tools -- but how much of a difference would this make in an editor/IDE that automatically inserts the closing-tag? (you type case, the editor appends esac (but below the point you're typing)): 1: | #your cursor at | 2: case| 3: case: | # you hit enter or something, ready to fill in esac # editor has closed block/statement I imagine typing-skills isn't much of an issue when editing/copying text -- as opposed to typing in new code?
  - skrishnamurthi 13y ago
    An express design goal is to not bake in assumptions about an editor. Programmers really like their editing tools. I've lived through the waves from vi to Emacs to vim to Sublime Text to what-have-you. We'd really, really like to make the language pleasing to work with without depending on an editor (indeed, each of us seems -- perhaps by accident -- to be using a different editor for Pyret, which may be influencing our decision). When editing/copying, it's not typing skills but editing skills, which are arguably subtler and even harder.