Re: Making Lua unique through supporting natural language texts as valid script code

[Claudio Grondi <claudio.grondi@...>]

On 10/1/23 17:51, Lars Müller wrote:
> 1. Programming languages shouldn't use/allow nonprintable characters
> except perhaps in (long/raw) string literals.

It's a pity that nonprintable characters are there, but not used. From 
my perspective it's time to change it ...


> 2. Would break existing code and introduce many syntactic ambiguities.
> Consider the simple p = print. Is this an assignment p = print() or an
> assignment p = print?
In my general concept of an oOo system using a text editor for invoking 
executable actions instead of a shell usage of an assignment isn't part 
of the concept. And because p=print() and p=print is already handled in 
Lua, there is no need to worry about ambiguities. It's ok as it is ...

> 3. Again a nonprintable control character. Adding hyphen would introduce
> ambiguities, breaking existing code again: Is a-b the name a-b or the
> subtraction a - b?

`a-b` is clearly a name. To achieve subtraction you would need to 
separate the operator from the variable names `a - b`. Like a*b could be 
also made a name .. In the general concept of oOo system a*b will be a 
name of a function which performs multiplication of the value stored in 
a variable with name `a` with the value stored in the variable with name 
`b`. The idea is to refrain from usage of internal variable names in 
usual sense, replacing them with a mechanism of getting the values from 
appropriate named files. And as files allow any characters in them ... 
there is actually no reason to restrict variable and function names to 
[_a-zA-z0-9], but .. to achieve simplicity and avoid the need to cope 
with utf-8 encoding and Unicode I tend to prefer the idea to stick with 
one-byte ASCII and an own kind of encoding with appropriate true type 
font for use in a text editor to write scripts.

> 4. Again ambiguities: Is x=f "blah" the assignment x=f followed by the
> comment "blah", or the assignment x=f("blah")?

See 2. for reasons not to worry about this. Assignments can stay and 
work as usual ... The idea is to be able to use a function f as a 
standalone statement without the need of specification of any arguments. 
The general concept of the oOo system is to refrain from passing any 
arguments to functions at all. Passing arguments to functions is origin 
of creating an own language within the language which then needs 
explanations ... you can escape from this evil circle only when 
functions are not able to take any arguments at all. This would make 
things much, much easier and more straightforward.

> 5. Not an option, would introduce ambiguities and break existing code -
> comma, period and colon all already have meanings (arglist / varlist /
> table entry separator, indexing operator, implicit self parameter
> syntactic sugar). Treating them like semicolons (usually unnecessary
> statement delimiters) would break practically all existing code. Some
> examples: Is f().x=2 equivalent to f();x=2 or f()["x"]=2? Is f():g()
> equivalent to f();g() or local self=f();self.g(self)?
See 2.  YES ... the assignment is evil ... and reason for trouble ... 
Let's refrain from using assignments at all ... or let them there 
working as usual if used in code.

> The support of nonprintable characters would be easy to implement, the
> rest not so much; it isn't even well defined.
I took already a look at Lua source code ... I can't find in the C-code 
where the parsing is done and what needs to be changed in order to allow 
additional characters in symbol names or to extend the range of 
characters used as neutral (because not needed) statement separators.

The actual problem I see is to explain to someone who is deeply into the 
existing programming mechanisms and paradigms what the final goal and 
concept of oOo is, because it goes beyond usual understanding of what a 
programming language is for.

The core idea is to use the keyboard to write a text in a text editor 
and invoke all the systems functionality from there using a custom 
language created out of the available functionalities (mixing usage of 
executable files written in various programming languages).

Textadept with Lua scripting appears to me to be a perfect start to 
create a proof of the concept which comes down to the guideline:
"""
TEACHING THE SYSTEM
to understand what you say
is a much better investment than
LEARNING THE LANGUAGE
the system can understand
"""

Once you have got the main idea of what I am actually after, then you 
will much better understand how to help to achieve it providing the 
appropriate language means making it possible. In my eyes Lua is the 
best language available for this purpose if slightly modified to support 
more freedom of choice while writing code.

Claudio

> - Lars
>
> On 01/10/2023 13:41, Claudio Grondi wrote:
> > Lua would require some minor changes only, which if I am not mistaken
> > won't break any past code and should be relatively easy to implement,
> > in order to support natural language texts as valid script code.
> >
> > May someone help me to provide proof of the concept explaining where
> > and how to modify Lua C-code in order to:
> >
> > 1.    allow ASCII values 0x02 (Start of Text) and 0x03 (End of Text)
> > to be used in script code and interpreted respectively as `[[` and `]]`
> >
> > 2.    allow function calls by specifying the function name only
> > (without using braces and without the need of passing a parameter)
> >
> > 3.    extend [_a-zA-z0-9] characters allowed in symbol names with
> > ASCII value 0x1F (Unit Separator) and `-` which will be treated like
> > [0-9] not allowed as first symbol name characters
> >
> > 4.    allow usage of unnamed strings (i.e. string literals which can
> > be specified anywhere in code without the need of assigning them to a
> > symbol) ignoring them like comments
> >
> > 5.    allow next to `;` also usage of `,` , `.` and `:`
> >
> > ?