[HN Gopher] Parentheses Are Just Typechecking ___________________________________________________________________ Parentheses Are Just Typechecking Author : azhenley Score : 15 points Date : 2021-06-23 12:13 UTC (1 days ago) (HTM) web link (adam.nels.onl) (TXT) w3m dump (adam.nels.onl) | taeric wrote: | The parentheses are just one of the more portable ways of showing | structure. Yes, sometimes they can be dropped, but then moving an | expression might become ambiguous. This is easily seen in | languages like yaml where moved code is not put with the intended | invention level. | | Which isn't really contradicting anything here. At least, not | intending to. Structure is a part of typing. And sometimes the | structure is the least interesting part of the type. | RodgerTheGreat wrote: | Logo is close to "a lisp with no parentheses", and it also | doesn't have any special forms. You can have parens, but they are | optional. Compare: item random size :list :list | (item (random (size :list)) :list) | | It poses challenges for making parse-trees, though, especially | since Logo traditionally has dynamic scope: you can't actually | know the valence of a function until it is evaluated! | mananaysiempre wrote: | In no particular order: | | - Lisp only needs parentheses because its operators have variable | arity, that's about as deep as the "type system" goes. | | - The concatenative languages wiki <https://concatenative.org> | only lists Om <http://om-language.org> among the (non-reverse) | Polish notation concatenative languages, but its semantics are a | bit more tricky than those for RPN languages when expressed in | terms of left-to-right evaluation (stream processing, not | stacks). | | - Unrelated, but see XY <http://www.nsl.com/k/xy/xy.htm> for a | _very_ elegant RPN semantics. | | - I think I've heard that the APL semantics is commonly described | right to left so might be related? | | - The proposed Lisp-2 notation with a syntactic distinction | between operators and operands strongly reminds me of how the | Self expression syntax | <https://handbook.selflanguage.org/2017.1/langref.html#expres...> | works (its main difference from Smalltalk). | thrwaeasddsaf wrote: | > I think I've heard that the APL semantics is commonly | described right to left so might be related? | | Not particularly related. It's just that every function is | either monadic (operand on the right) or dyadic (infix). That | makes it a case of not needing to explicitly specify where the | function arguments start and end, still without using a stack; | it is purely syntactic, and obvious (although you do need | context to parse anything that uses user-defined things). | Parentheses are still needed for the left operand of a dyadic | function if it is to take an expression more complicated than a | plain array. | | If you had functions of higher arity, then it would become | necessary to add parens, delimiters, or a stack. | mikewarot wrote: | Stoical uses {} instead of () to do grouping, and is a reverse | polish concatenative language. I tried to port it to 64 bit C, | but my C foo isn't up to the task. | | http://stoical.sourceforge.net/documentation.php | cratermoon wrote: | Sort of. The parenthesis around an expression like (a b +) imply | a result of some type. That type is defined by the whatever type | promotion rules are in place for the operands and operators. | Thus, if a and b are integers in the range -MIN_VALUE to | MAX_VALUE, and + is defined as integer addition, then the 'type' | implied by (a b +) is an integer in that range (or possibly an | error condition, if under/overflow). | | The reason you don't see a stack language that evaluates from | left to right is because then it wouldn't be a stack language. | 1-more wrote: | >a Lisp that can drop nested parentheses when the meaning is | clear from context | | It's not a lisp, but Elm with Aaron VonderHaar's elm-format does | that and it is very pleasant. | ggm wrote: | dominant is right to left reading cultures western In But | it's entirely reasonable to ask why we didn't learn to | think in right to left reading of stack order | didn't nonetheless but oh sorry | tub sselehtenon t'ndid oh sorry (trys again) | bibn'j nonejele22 duj After all, treat your strings | badly in Python and they do expose as .. lists .. which | are .. stacks .. kinda. ___________________________________________________________________ (page generated 2021-06-24 23:00 UTC)