Patchless modification of Lua source code

classic Classic list List threaded Threaded
69 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Patchless modification of Lua source code

Dirk Laurie-2
Over the years, there have been several replies to suggested patches
on this list, saying "no need to patch Lua".

The trick is not described in the "Customization" section of
'doc/readme.html' so this post has the dual purpose of documenting it
here (probably not for the first tine) and pleading that a better (not
Linux-specfic, and also saying how to do it for liblua.a or liblua.dll
as the case may be) description than mine might in future be described
there.

~~~
A customized version of Lua that would affect only non-header files,
i.e. files with names ending in ".c", never requires patching Lua
itself. The job can be done from the command line, illustrated here
for two such files under Linux.

The key points are:

1. All external names used by Lua are declared in header files.
2. If such a name has been resolved by an object file or library
linked earlier, the linker will be satisfied and will not replace it.
3. Any .o files needed by the linker will be built automatically from
.c files by the Makefile rules.

So all that is necessary is:

1. In the Lua source directory, save your modified files with another
prefix, say "my", instead ol "l" starting their names, e.g.
'myctype.c' and 'mylex.c'.
2. When you want a new 'lua' including your most recent modifcations:
    rm my*.o     # necessary because the Makefile does not know about them
    make linux -e "LUA_O=  lua.o myctype.o mylex.o"
~~~

Reply | Threaded
Open this post in threaded view
|

Re: Patchless modification of Lua source code

Dirk Laurie-2
Op Ma. 19 Nov. 2018 om 11:09 het Dirk Laurie <[hidden email]> geskryf:

> 2. When you want a new 'lua' including your most recent modifcations:
>     rm my*.o     # necessary because the Makefile does not know about them
>     make linux -e "LUA_O=  lua.o myctype.o mylex.o"

Actually, you probably do not need "rm my*.o". The dependency of .o
files on .c files is automatic.

Reply | Threaded
Open this post in threaded view
|

Re: Patchless modification of Lua source code

Viacheslav Usov
In reply to this post by Dirk Laurie-2
On Mon, Nov 19, 2018 at 10:10 AM Dirk Laurie <[hidden email]> wrote:
 
1. All external names used by Lua are declared in header files.
2. If such a name has been resolved by an object file or library
linked earlier, the linker will be satisfied and will not replace it.
3. Any .o files needed by the linker will be built automatically from
.c files by the Makefile rules.

No. Quoting clause 6.9/5 of the C11 standard:

If an identifier declared with external linkage is used in an expression (other than as part of the operand of a sizeof or _Alignof operator whose result is an integer constant), somewhere in the entire program there shall be exactly one external definition for the identifier; otherwise, there shall be no more than one.

(end)

The standard has no concept of "linked earlier" and consequently no primacy of "names linked earlier", and the entire program, including all the libraries, shall have a function with a given name defined at most once. Per clause 4/2, "If a ‘‘shall’’ or ‘‘shall not’’ requirement [...] is violated, the behavior is undefined".

Note that what you do may fail in weird ways even with toolchains that do have the notion of "linked earlier" - precisely because something has been linked earlier. Your application may be using the "modified" functions, while Lua itself and the other libraries use the "original" functions. This would be a special case of generally undefined behaviour.

Do not do this, except for fun.

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: Patchless modification of Lua source code

Dirk Laurie-2
Op Wo. 21 Nov. 2018 om 01:31 het Viacheslav Usov <[hidden email]> geskryf:

>
> On Mon, Nov 19, 2018 at 10:10 AM Dirk Laurie <[hidden email]> wrote:
>
>>
>> 1. All external names used by Lua are declared in header files.
>> 2. If such a name has been resolved by an object file or library
>> linked earlier, the linker will be satisfied and will not replace it.
>> 3. Any .o files needed by the linker will be built automatically from
>> .c files by the Makefile rules.
>
>
> No. Quoting clause 6.9/5 of the C11 standard:
>
> If an identifier declared with external linkage is used in an expression (other than as part of the operand of a sizeof or _Alignof operator whose result is an integer constant), somewhere in the entire program there shall be exactly one external definition for the identifier; otherwise, there shall be no more than one.
>
> (end)
>
> The standard has no concept of "linked earlier" and consequently no primacy of "names linked earlier", and the entire program, including all the libraries, shall have a function with a given name defined at most once. Per clause 4/2, "If a ‘‘shall’’ or ‘‘shall not’’ requirement [...] is violated, the behavior is undefined".
>
> Note that what you do may fail in weird ways even with toolchains that do have the notion of "linked earlier" - precisely because something has been linked earlier. Your application may be using the "modified" functions, while Lua itself and the other libraries use the "original" functions. This would be a special case of generally undefined behaviour.
>
> Do not do this, except for fun.

What you state so categorically and trenchantly may well be true in
other situations, but I would remind you that we are now dealing with
source files that would have worked if used as patched versions of
standard Lua files. The point of the exercise is simply that patching
can be avoided by this trick, for which I claim no originality.

For the 'linux' target of the Makefile supplied with Lua 5.4 work2,
the link step expands to:

   gcc -std=gnu99 -o lua   lua.o mylex.o myctype.o liblua.a -lm -Wl,-E -ldl

The way I understand it, is that the only the three object files
lua.o, mylex.o and myctype.o must not contain a duplicate definition
of an external routine. Only some routines of a library are linked in,
only the ones still unresolved. For example, the C99 math library
contains atanh, but the lua source code does not request it, so it is
not linked into the lua executable.

It seems to me that, if those three files contain a name conflict,
then omitting mylex.o and myctype.o and instead replacing llex.c and
lctype.c by mylex.c and myctype.c respectively, as in effect patching
would do, would contain the same name conflict, contradicting the
assumption that patching would have worked.

Admittedly I do not have the C11 standard open in front of me (which
BTW seems to be totally irrelevant when a program is compiled
according to the gnu99 standard) and am relying solely on about thirty
years' experience as a C programmer.

I apologize for omitting, in the mistaken belief that they would be
implicit to any reasonably experienced reader, the final words "from
liblua.a" from my point number 2,

— Dirk

Reply | Threaded
Open this post in threaded view
|

Re: Patchless modification of Lua source code

Viacheslav Usov
On Wed, Nov 21, 2018 at 8:27 AM Dirk Laurie <[hidden email]> wrote:

> The point of the exercise is simply that patching can be avoided by this trick, for which I claim no originality.

The point of my message is that the exercise violates the rules of the C language and is inherently dangerous. It would be a disservice to the community to promote your method without this clearly stated.

> Admittedly I do not have the C11 standard open in front of me (which BTW seems to be totally irrelevant when a program is compiled according to the gnu99 standard)

You did say:

[...] pleading that a better (not Linux-specfic, and also saying how to do it for liblua.a or liblua.dll as the case may be) description than mine might in future be described there.  

(end)

In that broader context your method ought to be supported by a language standard rather than a particular tool. Even with that tool, though, your method is dangerous.

The requirement that names with external linkage shall be defined at most once is not new in C11. It existed already in C89, viz., clause 3.7:

If an identifier declared with external linkage is used in an expression (other than as part of the operand of a sizeof operator), somewhere in the entire program there shall be exactly one external definition for the identifier.

(end)

Observe how the more recent standard is almost a verbatim replica of the old one in this respect. This is not accidental, because the requirement of _one_ definition of an external entity is a basic tenet of C and is traceable back K&R 's book (1978). Your method is fundamentally flawed.

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: Patchless modification of Lua source code

Dirk Laurie-2
Op Wo. 21 Nov. 2018 om 10:59 het Viacheslav Usov <[hidden email]> geskryf:

> Your method is fundamentally flawed.

This is not "my" method. I have merely filled out the details and
written it up in a thread that is easy to find. The suggestion that
the linker can do the work without the need for patching the Lua core
is due to Luiz.

http://lua-users.org/lists/lua-l/2011-05/msg00543.html

Reply | Threaded
Open this post in threaded view
|

Re: Patchless modification of Lua source code

Luiz Henrique de Figueiredo
> The suggestion that the linker can do the work without the need for
> patching the Lua core is due to Luiz.

That has been my experience in many years without exception.

The C standard is talking about the definition of symbols but it never
mentions a linker or how it should work, AFAIR. The linker is just
implementing the requirements in the C standard in a reasonable and
convenient way: it resolves symbols as it sees definitions for them. A
library is not meant to be totally incorporated into the program; only
modules that provide definitions for the program are incorporated.
Again, this is reasonable and convenient, and works extremely well in
practice. It has been like that for many decades.

Reply | Threaded
Open this post in threaded view
|

Re: Patchless modification of Lua source code

Viacheslav Usov
On Wed, Nov 21, 2018 at 12:12 PM Luiz Henrique de Figueiredo <[hidden email]> wrote:

> The C standard is talking about the definition of symbols but it never mentions a linker or how it should work, AFAIR.

This is not true. For example, in C89, clause 2.1.1.2 Translation phases, number 8:

All external object and function references are resolved. Library components are linked to satisfy external references to functions and objects not defined in the current translation. 

(end)

This is echoed verbatim in C11. The requirements for external references and definitions are covered elsewhere in the standard (I cited them earlier).

> The linker is just implementing the requirements in the C standard in a reasonable and convenient way:

The linker is either conformant or not. However, the particular requirement of "one definition only" is one where the standard lets the implementation (i.e., the linker) behave in an undefined way (because the standard implicitly recognises that an implementation may not have sufficient means to enforce conformant behaviour). This merely means that the onus is on the programmer to ensure that the whole program is conformant, which, in this case, means to ensure that no function is defined more than once in the program, which includes all its libraries.

> A library is not meant to be totally incorporated into the program; only modules that provide definitions for the program are incorporated.

This is, in fact, not a requirement. An implementation is free to incorporate all of the library. And when a shared library used, this is exactly what happens.

If the previous "static" linking phase has resolved some of the dependencies, these dependencies won't be resolved during the "dynamic" linking phase to the functions incorporated in the shared library. This is permitted under the broad umbrella of undefined behaviour. However, this:

> Again, this is reasonable and convenient, and works extremely well in practice. It has been like that for many decades.

would be a dangerous idea to entertain.

First, other libraries that the executable depends on will not have been linked statically to the same "replacement" functions, so they will have to resort to the "original" dependencies. Your program, as whole, may end up using different versions of the same set of functions simultaneously. Even without those other libraries the sole library that you intend to patch "without patching" can happily continue using its own functions, with the same result.

Second, if those other libraries resort to the same trick, the situation is not just proportionally worse, it is much worse because this may end up with duplicate export symbols and a whole new problem to solve.

Finally, none of this is portable and on some platforms one would have to go through pretty serious gyrations to convince the linker it is OK to have duplicate symbols and that these particular ones are to be used statically. Which is actually good.

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: Patchless modification of Lua source code

Philippe Verdy-2
I disagree. In practice the linker are trying to resolve symbols by starting from a first unit and using the other modules and libraries one by one, in the strict order where they are specified in the link command, until there remains no other unresolved symbols, at which time all other units may be discarded, when building a standalone application, or still added to the pack when building a library. But the linker will emit a warning if it finds a symbol redefined by another unit, because the result of the link can only keep one of the reference, the first one encountered, the rest, if it is not reachable at all by any other exported symbol part of the smallest unit, can be discarded directly by the linker.

So the order by which you specify the compiled units, and then the libraries, is significant.

E.g a link command specifying "-ll -lm" is not equivalent to the same command specifying "-lm -ll" instead. The same remark applies to the ordered list of .o units, which just come as a first group before all libraries, but are not necessarily all included in the linker module, except when building a library and the modules kept in the library still have at least one distinctive symbol.

Le mer. 21 nov. 2018 à 13:45, Viacheslav Usov <[hidden email]> a écrit :
On Wed, Nov 21, 2018 at 12:12 PM Luiz Henrique de Figueiredo <[hidden email]> wrote:

> The C standard is talking about the definition of symbols but it never mentions a linker or how it should work, AFAIR.

This is not true. For example, in C89, clause 2.1.1.2 Translation phases, number 8:

All external object and function references are resolved. Library components are linked to satisfy external references to functions and objects not defined in the current translation. 

(end)

This is echoed verbatim in C11. The requirements for external references and definitions are covered elsewhere in the standard (I cited them earlier).

> The linker is just implementing the requirements in the C standard in a reasonable and convenient way:

The linker is either conformant or not. However, the particular requirement of "one definition only" is one where the standard lets the implementation (i.e., the linker) behave in an undefined way (because the standard implicitly recognises that an implementation may not have sufficient means to enforce conformant behaviour). This merely means that the onus is on the programmer to ensure that the whole program is conformant, which, in this case, means to ensure that no function is defined more than once in the program, which includes all its libraries.

> A library is not meant to be totally incorporated into the program; only modules that provide definitions for the program are incorporated.

This is, in fact, not a requirement. An implementation is free to incorporate all of the library. And when a shared library used, this is exactly what happens.

If the previous "static" linking phase has resolved some of the dependencies, these dependencies won't be resolved during the "dynamic" linking phase to the functions incorporated in the shared library. This is permitted under the broad umbrella of undefined behaviour. However, this:

> Again, this is reasonable and convenient, and works extremely well in practice. It has been like that for many decades.

would be a dangerous idea to entertain.

First, other libraries that the executable depends on will not have been linked statically to the same "replacement" functions, so they will have to resort to the "original" dependencies. Your program, as whole, may end up using different versions of the same set of functions simultaneously. Even without those other libraries the sole library that you intend to patch "without patching" can happily continue using its own functions, with the same result.

Second, if those other libraries resort to the same trick, the situation is not just proportionally worse, it is much worse because this may end up with duplicate export symbols and a whole new problem to solve.

Finally, none of this is portable and on some platforms one would have to go through pretty serious gyrations to convince the linker it is OK to have duplicate symbols and that these particular ones are to be used statically. Which is actually good.

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: Patchless modification of Lua source code

Viacheslav Usov
On Wed, Nov 21, 2018 at 4:06 PM Philippe Verdy <[hidden email]> wrote

> I disagree. 

With what, exactly?

> In practice the linker

What linker is that, exactly?

How in your "I disagree" response did you consider the case of shared libraries, which I have specifically addressed twice and which are the whole point of this thread to begin with?

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: Patchless modification of Lua source code

Philippe Verdy
shared libaries are handled the same way: an application loading a shared libary will be linked by the system by resolving names in a defined order: the order specified in the compiled applications, which lists the shared libraries it needs in a significant order. If two shard libraries export the same symbol, only one will be used: the symbol coming from the first library (the other symbol from a further-listed shared library may still be used indirectly, if the second library has other symbols used by the application, and the application then allows the second distinct implementation of the first symbol used indirectly)

Say that an apps needs symbols ("a","b","c") from "sharedlibary1" and symbols ("d","e","f") from "sharedlibary2". The "sharedlibrary2" may also export the symbol "a" (used indirectly within sharedlibary2 to implement "c"). The app will itself will use directly only "a" from "sharedlibrary1" because the application was compiled to load and use "sharedlibary1,sharedlibary2" in that precise order. But when the application will use "d" from "sharedlibary2", this could cause the implementation "a" from "sharedlibary2" to be used, even if there's also the separate implementation of "a" in sharedlibrary1.

In all cases, the order or resolution is always important and needs to be specified. For this reason, shared libraries are not used in an unordered collection of library names: there must be a specified order (and typically shared libaries are loaded and resolved one at a time, and internal uses by shared libaries themselves are resolved internally by each shared libary itself, specifying its own internal dependencies (already resolved when they were compiled), or external dependencies (these additional dependencies must have NO impact to the application using it, unless the application loading a shared DLL also instructs that DLL to allow resolving its own external dependencies using a path order specified by the application, to override the default path included in the shared library itself; for most cases, such overrides are not possible but many shared library loaders are using an external path, such as in the environment, to indicate where to load the other libraries: a DLL loader may check that the located libaries match a specific digital signature to accept using it, and if not, the lookup will need to search on other entries of the environment path: this can prevent unexpected matches, and it's a solution that allows "signed" libraries to be specified in random order; if libraries are not signed and the application or libraries do not specify a specific digital signature or an absolute path for locating them, then nothing will prevent duplicate symbols to occur, except the specified order).

Symbol dependies form an oriented graph across all modules, with several layers of locality, each module defining its own order of dependencies (the names of shared libaries are themselves also "symbols", like normal symbols attached to individual objects inside each library or module).


Le mer. 21 nov. 2018 à 16:22, Viacheslav Usov <[hidden email]> a écrit :
On Wed, Nov 21, 2018 at 4:06 PM Philippe Verdy <[hidden email]> wrote

> I disagree. 

With what, exactly?

> In practice the linker

What linker is that, exactly?

How in your "I disagree" response did you consider the case of shared libraries, which I have specifically addressed twice and which are the whole point of this thread to begin with?

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: Patchless modification of Lua source code

Philippe Verdy
In reply to this post by Viacheslav Usov
Note: checking digital signatures of shared libraries is rarely used. Instead the common practice is to specify a version number: a module may not just indicate the name of a library, but also the allowed version(s) in which it may be linked. This generally solves quite well the dependencies on an external (unpredictable) path.

If you want to create a specific "patched" version of Lua, the best to it it to assign to your path a subversion number indicating that it derives from a base "standard" version.

Say you create a patched version based in Lua version "5.3", your new patch will be versioned for example as "5.3-mypatch-1.0". The DLL loader for an application depending on your patch, can be instructed to match "5.3-mypatch-1.0" (or higher) and not just "5.3", and it will not match version "5.4" because it is in another branch which does not include the "mypatch-1.0" base of the derived branch which itself depends on the base "5.3" branch, which is not replacable in this case.

This is in fact a basic scheme of all "sane" versioning systems where each branch must be precisely identifiable.

But appliatiosn that want very secure dependencies, should not just match version numbers (not even a single one excluding higher ones), but should match digital signatures (this is possible with the Windows DLLs, not sure that it works with all dynamic library loaders on Linux/Unix, which may not have the feature needed to check exact implementations, but may just use whatever "simple" symbols or names are found first in their loader path, in which case the result will not be predictable if the environment path can vary: the behavior will be fully driven and defined by the order specified in the environment path, just like with shells for resolving simple command names to actual locations of their implementations in applications stored on the filesystem, where the order of entries in the environment path is also very significant).


Le mer. 21 nov. 2018 à 16:22, Viacheslav Usov <[hidden email]> a écrit :
On Wed, Nov 21, 2018 at 4:06 PM Philippe Verdy <[hidden email]> wrote

> I disagree. 

With what, exactly?

> In practice the linker

What linker is that, exactly?

How in your "I disagree" response did you consider the case of shared libraries, which I have specifically addressed twice and which are the whole point of this thread to begin with?

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: Patchless modification of Lua source code

Viacheslav Usov
In reply to this post by Philippe Verdy
On Wed, Nov 21, 2018 at 4:55 PM Philippe Verdy <[hidden email]> wrote:

> shared libaries are handled the same way

Same way as that of an unspecified linker?

Are you claiming that your description is applicable to all the operating systems and all the linkers in the world?

> But when the application will use "d" from "sharedlibary2", this could cause the implementation "a" from "sharedlibary2" to be used, even if there's also the separate implementation of "a" in sharedlibrary1.

> internal uses by shared libaries themselves are resolved internally by each shared libary itself, specifying its own internal dependencies (already resolved when they were compiled), or external dependencies (these additional dependencies must have NO impact to the application using it

So this seems to agree at least with problem "First" in the message to which you responded "I disagree".

Again, what exactly do you disagree with?

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: Patchless modification of Lua source code

Philippe Verdy
I disagreed with what to say about linkers (I also said that command line shells in OSes are also exctly like linkers; and variable name binding implemented in any language is in fact also like a linker). Everywhere there's an order of priority for name lookups
In programming languages, including Lua, this is called "scope", and a "closure" is the fact of binding specific sets of variables to specific scopes.
And that's what I mean by "locality".
Some names may be left unresolved by such linking/binding, leaving "external" names. Or they may be oinly partially resolved to a small subset, with a late final binding: this is what occurs with effective values of parameters of functions (but there's still always a priority order for completely resolving these links).
I do not know any example where a well defined priority order is not used by any "linker" (or programming language, or shell using linking/binding) for resolving "names", "symbols", or "variables", even in languages that allow symbolic values (e.g. Lisp, or Prolog).


Le mer. 21 nov. 2018 à 17:18, Viacheslav Usov <[hidden email]> a écrit :
On Wed, Nov 21, 2018 at 4:55 PM Philippe Verdy <[hidden email]> wrote:

> shared libaries are handled the same way

Same way as that of an unspecified linker?

Are you claiming that your description is applicable to all the operating systems and all the linkers in the world?

> But when the application will use "d" from "sharedlibary2", this could cause the implementation "a" from "sharedlibary2" to be used, even if there's also the separate implementation of "a" in sharedlibrary1.

> internal uses by shared libaries themselves are resolved internally by each shared libary itself, specifying its own internal dependencies (already resolved when they were compiled), or external dependencies (these additional dependencies must have NO impact to the application using it

So this seems to agree at least with problem "First" in the message to which you responded "I disagree".

Again, what exactly do you disagree with?

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: Patchless modification of Lua source code

Sean Conner
It was thus said that --------- Philippe Verdy once stated:
>
> I do not know any example where a well defined priority order is not used
> by any "linker" (or programming language, or shell using linking/binding)
> for resolving "names", "symbols", or "variables", even in languages that
> allow symbolic values (e.g. Lisp, or Prolog).

  INRAC.

  A computer language with non-deterministic binding (and flow control, but
I digress), used for a few commerical programs that I know of.

  -spc (There are *always* exceptions, except for death ... )


Reply | Threaded
Open this post in threaded view
|

Re: Patchless modification of Lua source code

Philippe Verdy
I said "I do not know", you replied by giving an example you know but is almost confidential, whose applications using it are rare to find.

So you don't disagree what I said, you confirm it!

Le mer. 21 nov. 2018 à 20:34, Sean Conner <[hidden email]> a écrit :
It was thus said that --------- Philippe Verdy once stated:
>
> I do not know any example where a well defined priority order is not used
> by any "linker" (or programming language, or shell using linking/binding)
> for resolving "names", "symbols", or "variables", even in languages that
> allow symbolic values (e.g. Lisp, or Prolog).

  INRAC.

  A computer language with non-deterministic binding (and flow control, but
I digress), used for a few commerical programs that I know of.

  -spc (There are *always* exceptions, except for death ... )


Reply | Threaded
Open this post in threaded view
|

Re: Patchless modification of Lua source code

Philippe Verdy
I cannot even find any reference about INRAC on the net. All I find is the acronym and brand in France of the "Institut National pour la Retraite ACtive", a training institute for senior people.

I find a reference in GitHub for the name of a module written in Perl for reverse engineering of RAC files used in the early 1980s by the RACTER program, used for chatting, an ancestor of IRC... But I don't know if you refer to this Perl module and its related language. This is an alpha module, not tested, not even documented.

Le mer. 21 nov. 2018 à 20:55, Philippe Verdy <[hidden email]> a écrit :
I said "I do not know", you replied by giving an example you know but is almost confidential, whose applications using it are rare to find.

So you don't disagree what I said, you confirm it!

Le mer. 21 nov. 2018 à 20:34, Sean Conner <[hidden email]> a écrit :
It was thus said that --------- Philippe Verdy once stated:
>
> I do not know any example where a well defined priority order is not used
> by any "linker" (or programming language, or shell using linking/binding)
> for resolving "names", "symbols", or "variables", even in languages that
> allow symbolic values (e.g. Lisp, or Prolog).

  INRAC.

  A computer language with non-deterministic binding (and flow control, but
I digress), used for a few commerical programs that I know of.

  -spc (There are *always* exceptions, except for death ... )


Reply | Threaded
Open this post in threaded view
|

Re: Patchless modification of Lua source code

Sean Conner
In reply to this post by Philippe Verdy
It was thus said that the Great Philippe Verdy once stated:

> Le mer. 21 nov. 2018 à 20:34, Sean Conner <[hidden email]> a écrit :
>
> > It was thus said that --------- Philippe Verdy once stated:
> > >
> > > I do not know any example where a well defined priority order is not used
> > > by any "linker" (or programming language, or shell using linking/binding)
> > > for resolving "names", "symbols", or "variables", even in languages that
> > > allow symbolic values (e.g. Lisp, or Prolog).
> >
> >   INRAC.
> >
> >   A computer language with non-deterministic binding (and flow control, but
> > I digress), used for a few commerical programs that I know of.
> >
> I said "I do not know", you replied by giving an example you know but is
> almost confidential, whose applications using it are rare to find.
>
> So you don't disagree what I said, you confirm it!

  You do not speak for me, and I did not "confirm" what you said.

  You also did not do a search, because while I said "used for a few
commerical programs" I said nothing about the difficulty of finding the
programs.

  -spc

Reply | Threaded
Open this post in threaded view
|

Re: Patchless modification of Lua source code

Sean Conner
In reply to this post by Philippe Verdy
It was thus said that the Great Philippe Verdy once stated:
> I cannot even find any reference about INRAC on the net. All I find is the
> acronym and brand in France of the "Institut National pour la Retraite
> ACtive", a training institute for senior people.
>
> I find a reference in GitHub for the name of a module written in Perl for
> reverse engineering of RAC files used in the early 1980s by the RACTER
> program, used for chatting, an ancestor of IRC... But I don't know if you
> refer to this Perl module and its related language. This is an alpha
> module, not tested, not even documented.

  Congratulations!  RACTER was, in fact, written in INRAC and was
commercially available in tthe mid 80s [1][2].  The RAC files *is* the
program, and the language itself is non-deterministic in resolving names
which I gave as an example to back up the point Viacheslav Usov was making.

  -spc

[1] It was even used in the writing of the book _The Policemans' Beard
        is Half Constructed_ (https://www.amazon.com/Policemans-Beard-Half-Constructed-Computer/dp/0446380512/)

[2] The INRAC compiler was also available commercially, but is hard to
        find.

Reply | Threaded
Open this post in threaded view
|

Re: Patchless modification of Lua source code

Philippe Verdy
In reply to this post by Sean Conner
I can pretend that you reconfirm once again what I said, by confirming that your example is hard to find (if we cannot find and evaluate it, then your reply is justifying nothing at all, it just proves that you cannot justify your opposition by verifiable arguments you could have invented only to give a contradiction...)

Yes there are programming languages that use "late binding" (i.e. where bionding is not solved at all imemdiately, allowing multiple names/symbols to coexist and remain unfiltered), but this does not prove that these languages are usable for anything, without finally using a final "linker" that will resolve the references to names using a well defined and predictable order with additional data (or environment) specifying the expected ordering rules.


Le mer. 21 nov. 2018 à 21:10, Sean Conner <[hidden email]> a écrit :
It was thus said that the Great Philippe Verdy once stated:
> Le mer. 21 nov. 2018 à 20:34, Sean Conner <[hidden email]> a écrit :
>
> > It was thus said that --------- Philippe Verdy once stated:
> > >
> > > I do not know any example where a well defined priority order is not used
> > > by any "linker" (or programming language, or shell using linking/binding)
> > > for resolving "names", "symbols", or "variables", even in languages that
> > > allow symbolic values (e.g. Lisp, or Prolog).
> >
> >   INRAC.
> >
> >   A computer language with non-deterministic binding (and flow control, but
> > I digress), used for a few commerical programs that I know of.
> >
> I said "I do not know", you replied by giving an example you know but is
> almost confidential, whose applications using it are rare to find.
>
> So you don't disagree what I said, you confirm it!

  You do not speak for me, and I did not "confirm" what you said.

  You also did not do a search, because while I said "used for a few
commerical programs" I said nothing about the difficulty of finding the
programs.

  -spc

1234