On 24/04/2025 13:25, David Brown wrote:
On 23/04/2025 19:43, bart wrote:
By the 500 such macro definitions, and the EXTENSIVE use of such macro invocations instead of functions, in a class of application I'm very familiar with.
>
So you don't know. You guessed.
Why are you automatically sticking up for THEM and not ME?
What qualifications and what experience would somebody need for David Brown to give credence to their opinion?
I'm sure there are lots projects you can look at and know straight off that its uses of macros or whatever is over the top.
Suppose you reported that here, but I suggested that you don't know that; you're only guessing?
You don't have any idea /why/ the developers choose to use macros like this - you simply assume that because you have written an interpreter with little use of macros,
I've written a million lines of code with little use of macros.
They are prevalent in C simply because the language has them and people will use them. Even if you ignore the ones that only exist people because don't like to use enums for named constants.
What your experience tells you is that is that it is /possible/ to implement a little virtual machine for a simple language without using C macros.
It tells you nothing about whether or not it is a good idea, because you have not tried it out for comparison. It tells you nothing about how best to implement Lua in C, because that is a very different language from your languages.
The example I gave was from ADD; my language has ADD too! Except that Lua's ADD works between Ints and Floats (Floats only before 5.1?); mine works between Ints, Floats, Strings, Bignums and Sets.
So, how different is it really?
It tells you nothing about the best structure for a core project written by multiple people, with extensions written by hundreds or thousands of people, and with many orders of magnitude more end users - because you just have a one-person language.
You forgot the bit where I said I've been doing this since the 1980s, on a few languages of my own, both dynamic and statically typed. And I've looked at lots of others including their implementations.
I've also got my C compiler to build and run some of those (Lua and Seed7 among them).
I even created a C interpreter.
I've experimented with half a dozen kinds of bytecode dispatcher, and several methods of type dispatching, and tried out AST tree-walkers.
Some of my interpreters were embedded, and run within commercial products, and used by other people to create their own add-on programs.
And to cap it all, you (AFAIUI) don't even use C to implement any of this stuff - you use your own languages. (Those may well be a better choice than C for implementing virtual machines.)
I did try C at one point. That didn't use macros either.
The way you could /know/ the best way to implement a Lua virtual machine in C would be to investigate if the Lua developers, or any other groups, have tried to implement the Lua VM in different ways and seen how well they work. Or you could find books or articles that discuss different ways of implementing VMs.
Maybe /I/ should write a book or article instead!
There are perhaps a half-dozen basic ways of implementing language virtual machines. There are a very large number of interpreted or byte- coded languages. You have experience of implementing a couple of simple languages, for personal use, using either a strangely restricted subset of C or one of your own languages.
How many interpreters do you think the developers of Lua have worked on? (And how many of those developers also devised and programmed its implemenation language?)
You describe my languages as 'simple'; how much more complex do you think Lua is?
I find it disappointing that you don't want to acknowledge that I might know something of this field, that I have extensive experience of it, and that my opinions might be valid.
More so that you seem to know little about Lua, but decide to give them the benefit of a doubt anyway.
/Maybe/ they had good reasons for using so many macros, but /maybe/ so do I for having so few!
So why are you automatically assuming they must be right, and I must be wrong?
As it happens, my main scripting language is bigger and richer than Lua. And yet, my implementation is somewhat smaller, and most programs run faster. It's a paradox.
Here:
c:\cx>bcc -i lua hello.lua
Compiling lua.c to lua.(int)
Hello from Lua
This is my C interpreter, interpreting lua.c (a one-file version), which then runs hello.c.
Further, this is part of a survey of interpreters running a recursive Fibonacci benchmark:
Lang Implem Type Category Millions of Calls/second
Bash Bash ? Int 0.0014
C Pico C S Int 0.7
Seed7 s7 S Int 3.5
Algol68 A68G S Int 5
Python CPython 3.14 D Int 11
Lox Clox D Int 17
Lua Lua 5.4 D Int 22
Q DD D Int 73
PyPy PyPy 7.3.19 D JIT 128
JavaScript NodeJS D JIT 250 (See Note 2)
My product is Q/DD. It has the best performance of the pure interpreters; beyond that you need to employ JIT techniques.
The 'Note 2' mentioned is to do with NodeJS having a 0.5 second startup latency which had to be compensated for.
So I know fuck-all about writing interpreters, they are all toys, my languages are toys, and my opinion counts for nothing?
do { quit; } else { }
Re: do { quit; } else { }