Print

Print


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.