Re: else ladders practice

On 20/11/2024 14:38, Waldek Hebisch wrote:

Bart <bc@freeuk.com> wrote:

Either you're developing using interpreted code, or you must have some
means of converting source code to native code, but for some reason you
don't use 'compile' or 'build' to describe that process.
>
Or maybe your REPL/incremental process can run for days doing
incremental changes without doing a full compile.

 Yes.
 

It seems quite mysterious.

 There is nothing misterious here.  In typed system each module has
a vector (one dimensional array) called domain vector containg amoung
other references to called function.  All inter-module calls are
indirect ones, they take thing to call from the domain vector.  When
module starts execution references point to a runtime routine doing
similar work to dynamic linker.  The first call goes to runtime
support routine which finds needed code and replaces reference in
the domain vector.
 When a module is recompiled references is domain vectors are
reinitialized to point to runtimne.  So searches are run again
and if needed pick new routine.
 Note that there is a global table keeping info (including types)
about all exported routines from all modules.  This table is used
when compileing a module and also by the search process at runtime.
 The effect is that after recompilation of a single module I have
runnuble executable in memory including code of the new module.
If you wonder about compiling the same module many times: system
has garbage collector and unused code is garbage collected.
So, when old version is replaced by new one the old becomes a
garbage and will be collected in due time.

This sounds an intriguing kind of system to implement.
That is, where program source, code and data structures are kept resident, individual functions and variables can be changed, and any other functions that might be affected are recompiled, but no others.
This has some similarities to what I was doing in the 1990s with hot-loadable and -modifible scripts. So a lot more dynamic than the stuff I do now.
The problem is that my current applications are simply too small for it to be worth the complexity. Most of them build 100% from scratch in under 0.1 seconds, especially if working within a resident application (my timings include Windows process start/end overheads.)
If I was routinely working with programs that were 10 times the scale (so needing to wait 0.5 to 1 seconds), then it might be something I'd consider. Or I might just buy a faster machine; my current PC was pretty much the cheapest in the shop in 2021.

The other system is similar in principle, but there is no need
for runtime search and domain vectors.
 

I might run my compiler hundreds of times a day (at 0.1 seconds a time,
600 builds would occupy one whole minute in the day!). I often do it for
frivolous purposes, such as trying to get some output lined up just
right. Or just to make sure something has been recompiled since it's so
quick it's hard to tell.
>

>
I know.  But this is not what I do.  Build produces mutiple
artifacts, some of them executable, some are loadable code (but _not_
in form recogized by operating system), some essentially non-executable
(like documentation).

>
So, 'build' means something different to you. I use 'build' just as a
change from writing 'compile'.

 Build means creating new fully-functional system.  That involves
possibly multiple compilations and whatever else is needed.

I would call that something else, perhaps based around 'Make' (nothing to do with Linux 'make' tools).
Here is the result of such a process for one of my 1999 apps:
  G:\m7>dir
  10/03/1999  00:57            45,056 M7.DAT
  17/10/2002  19:22           370,288 M7.EXE
  11/10/2021  21:05             7,432 M7.INI
  17/10/2002  19:27           705,376 M7.PCA
  10/03/1999  00:59             8,541 M7CMD.INI
The PCA files contains a few dozen scripts (at that time, they were compiled to bytecode). This was a distribution layout, created a batch file, and ending up a floppy, or ater FTP-ed to a web-site.
This is not routine building of either than M7.EXE program unit, or those scripts which are compiled independently from inside M7.EXE.