[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)