On 25 February 2016 at 01:01, Siva Kalyan <[log in to unmask]> wrote: > A way of implementing parentheses would be to use “downstep” (or upstep), as in some African languages (or indeed, as in English parenthetical clauses or asides). Perhaps the language would have to be “musical” in a sense. That's a neat idea. The human vocal range limits how many levels of syntactic recursion would be available, though. Still, (as in English parenthetical clauses) it could be useful to have just one level of syntactic embedding available at times. > Or perhaps recursion could be replaced with cataphora, e.g.: “If a, then do the following and end: if b, then do the following and end: if c,….and end.” This might be more convenient for the speaker. Kind of like Haskell "where" clauses (Haskell isn't the only programming language that has those, but it's the first one that comes to mind). On 25 February 2016 at 04:21, Piermaria Maraziti <[log in to unmask]> wrote: > On 25/02/16 08:31, Logan Kearsley wrote: > >> The major problem that I see needing to be solved is parenthesization; > > You can try to look at lojban (generally and for this problem). > > Also: complex code may be hard to dictate and forth is difficult for other > reasons (RPN is not so easy and you should track items on the stack). Eh, I don't find RPN (or regular Polish Notation, either) to be that bad. Most people just aren't used to it. A stack isn't strictly necessary (it's just the most straightforward way of implementing it on a machine), and as long as the virtual stack depth is small, it behaves just like a strictly verb-final (or verb-initial) language. I think most of the hard parts are tracking data flow complex data flow when there aren't any variable names, whether you do it with a stack or not. If you're composing on-the-fly, that's a trade-off against keeping track of parenthesization, and it's not clear to me yet that either one is really better or worse. But if you are reciting something memorized, the details of which were worked out ahead of time so that you don't have to track data flow in your head, then the concatenative style, I *think*, should be easier to memorize and recite accurately than an applicative style with explicit argument lists. > I suppose that a solution could be "defining" blocks of code, say: > > call this "foo" begin > do this > do that > end > > call this "bar" begin > read a > if a then foo else abort > do thistoo > end > > for i in array v do bar with i-th from v > > This can be *like* function definition but short scope. It did occur to me that "let" constructions in many programming languages do derive from the natural-language usage of mathematicians; e.g., "let x equal ...; then...". And if you make use of dynamic, rather than lexical, scoping rules, that mechanism could be used to eliminate all syntactic recursion without having to remember argument lists. Dynamic scoping is usually considered a Bad Idea in programming language design, except in a few very specific restricted circumstances, but now I'm wondering if Larry Wall's linguistics background has something to do with why Perl has it! -l.