8 ms·

The documentation notes that reserving braces for blocks makes it very ugly to deal with dict literals, but it’t also terrible for sets, set comprehensions, and

by teddyh 2y ago

The documentation notes that reserving braces for blocks makes it very ugly to deal with dict literals, but it’t also terrible for sets, set comprehensions, and dict comprehensions. You’d think they’d choose some other characters than braces in order to avoid this. I seem to recall that RPL used « and » for program blocks.

mwkaufma 2y ago
Why are braces-for-both-blocks-and-literals/etc a deal breaker here, but not in JS?
- throwitaway1123 2y ago
  Using braces in an arrow function that returns an object literal actually is ambiguous in JS, which is why you have to wrap it in parentheses, e.g.: const foo = () => ({foo: 'bar'}) If you omit the parentheses it gets interpreted as a block with a label and a string literal: const baz = () => {baz: 'bar'} https://astexplorer.net/#/gist/9a86e0b61fda312dce2ea9d10d37ff20/8e2d1443456d0a4724f24b18ae2f97b585c3bc03 https://astexplorer.net/#/gist/9a86e0b61fda312dce2ea9d10d37f...
- wfleming 2y ago
  Probably because that makes parsing much more complicated, and this being a half-joking hobbyist project they didn’t want to increase scope that much.
- jerf 2y ago
  Because bython is basically a glorified regular expression search and replace: https://github.com/mathialo/bython/blob/master/bython/parser.py#L159 https://github.com/mathialo/bython/blob/master/bython/parser... Rather than a real parser. A real parser knows about the context it is in, and as long as the grammar is unambiguous about some character, it can be reused in as many distinct parser constructions as you like. A pure regex-based approach to a first approximation can not. Whether or not it absolutely can or can't, without "approximation" and with regard to the exact re library in Python, would be something you'd have to work out through tedious effort. Regexes with backtracking can do a lot more than mathematical regexes, as well as all the other elaborations you could use. But even if Python's re can do it, you will be better off with a real parser. The "correct" solution, since by design Python and Bython share the same AST, is to take some existing code that can parse and re-emit Python code without changing it, tweak the incoming grammar to use braces instead, then emit the AST back out as Python. Then you wouldn't have this problem, or the problem with comments referenced in the source code (line 109 of the file I linked, just up a bit), or any of the probably other many little issues that would arise on real code if you tried to put this in real use. The only slight complication I can see is there may be a slight issue with comments around the braces. I'm not sure, and I'm not going to sit here & work it out fully for an HN post. Also, this is not a criticism of Bython. The author can do as they please with it. If nothing else you can always label this a prototype. Prototyping is good, right? Anyone who was rushing to slam this into production is just gonna learn a real valuable lesson worth its weight in gold, and not Bython's fault.
signaru 2y ago
begin/end might be more familiar. Some languages don't even have the equivalent of (Pascal's) "begin" since other keywords are already associated with starting a block.
- mrspuratic 2y ago
  A long time ago this type of thing ("make C look like pascal") used to be the subject of holy wars/trolling #define BEGIN { #define END } There is, to this day afaict, a warning suppression option in VisualStudio for pre-processor macros with unbalanced braces that uses exactly this as an example.

by teddyh 2y ago

mwkaufma 2y ago

Why are braces-for-both-blocks-and-literals/etc a deal breaker here, but not in JS?

throwitaway1123 2y ago
Using braces in an arrow function that returns an object literal actually is ambiguous in JS, which is why you have to wrap it in parentheses, e.g.: const foo = () => ({foo: 'bar'}) If you omit the parentheses it gets interpreted as a block with a label and a string literal: const baz = () => {baz: 'bar'} https://astexplorer.net/#/gist/9a86e0b61fda312dce2ea9d10d37ff20/8e2d1443456d0a4724f24b18ae2f97b585c3bc03 https://astexplorer.net/#/gist/9a86e0b61fda312dce2ea9d10d37f...
wfleming 2y ago
Probably because that makes parsing much more complicated, and this being a half-joking hobbyist project they didn’t want to increase scope that much.
jerf 2y ago
Because bython is basically a glorified regular expression search and replace: https://github.com/mathialo/bython/blob/master/bython/parser.py#L159 https://github.com/mathialo/bython/blob/master/bython/parser... Rather than a real parser. A real parser knows about the context it is in, and as long as the grammar is unambiguous about some character, it can be reused in as many distinct parser constructions as you like. A pure regex-based approach to a first approximation can not. Whether or not it absolutely can or can't, without "approximation" and with regard to the exact re library in Python, would be something you'd have to work out through tedious effort. Regexes with backtracking can do a lot more than mathematical regexes, as well as all the other elaborations you could use. But even if Python's re can do it, you will be better off with a real parser. The "correct" solution, since by design Python and Bython share the same AST, is to take some existing code that can parse and re-emit Python code without changing it, tweak the incoming grammar to use braces instead, then emit the AST back out as Python. Then you wouldn't have this problem, or the problem with comments referenced in the source code (line 109 of the file I linked, just up a bit), or any of the probably other many little issues that would arise on real code if you tried to put this in real use. The only slight complication I can see is there may be a slight issue with comments around the braces. I'm not sure, and I'm not going to sit here & work it out fully for an HN post. Also, this is not a criticism of Bython. The author can do as they please with it. If nothing else you can always label this a prototype. Prototyping is good, right? Anyone who was rushing to slam this into production is just gonna learn a real valuable lesson worth its weight in gold, and not Bython's fault.

signaru 2y ago

begin/end might be more familiar. Some languages don't even have the equivalent of (Pascal's) "begin" since other keywords are already associated with starting a block.

mrspuratic 2y ago
A long time ago this type of thing ("make C look like pascal") used to be the subject of holy wars/trolling #define BEGIN { #define END } There is, to this day afaict, a warning suppression option in VisualStudio for pre-processor macros with unbalanced braces that uses exactly this as an example.