Re: Lark - A surface syntax for Common Lisp

On 2/16/2026 5:11 PM, Tim Bradshaw wrote:
>
>
>> On 16 Feb 2026, at 13:32, Greg Menke (as gregm32768 at comcast dot 
>> net) <[email protected]> wrote:
>>
>> But how can an editor handle substantial levels of nesting cleanly?   
>> It is ever so easy to add/delete a space even by accident and then 
>> things get ambiguous.
>
> Even if that were true which in my experience it is not when using any 
> slightly competent editor, it is surprisingly hard for this to happen 
> in Python for instance.
>
>   * You can only increase indentation where the syntax allows it, and
>     then it is not optional to do so.
>   * Assuming you use n-space indentation steps then a line which is
>     outdented by 1 to n-1 spaces from its expected indentation is a
>     syntax error.
>   * You are not allowed to use any mixture of tabs and spaces for
>     indentation which depends on the width of a tab, which in effect
>     outlaws any indentation scheme which is not either pure tabs or
>     pure spaces.
>
> The people who may find this hard are those who use single-space 
> indent steps.  OK.
>
> --tim

I still don't get it, not trying to be difficult I just don't understand 
how python is not fragile.    I don't use single-space indents, use 
Emacs and 3 or 4 spaces for indents.   Yet its crazy easy to 
accidentally move code following a conditional up into the conditional, 
or bring code out of the conditional just by accidentally hitting a tab, 
and then ambiguity can spread if the region of code is deeply nested.   
The block move keystrokes are a lifesaver, but I keep getting into 
little indenting problems when code is complex.   Its not a problem I 
ever have with C/C++ or Lisp, or Java, heaven help us.