Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Loops (was Re: do { quit; } else { })
Date: Thu, 24 Apr 2025 14:51:12 +0100
Organization: A noiseless patient Spider
Lines: 149
Message-ID: <vudfkh$1n25v$1@dont-email.me>
References: <vspbjh$8dvd$1@dont-email.me> <vu01k7$1bfv2$1@dont-email.me>
 <vu0720$1dva7$1@dont-email.me> <vu2hmg$3jn88$1@dont-email.me>
 <vu2mkc$3noft$1@dont-email.me> <vu38da$735n$1@dont-email.me>
 <vu3j7s$g755$1@dont-email.me> <87ecxmv4t4.fsf@nosuchdomain.example.com>
 <vu401g$reom$1@dont-email.me> <20250420200823.908@kylheku.com>
 <vu5bqp$230jl$2@dont-email.me> <20250421113640.839@kylheku.com>
 <vu67up$2ubvr$1@dont-email.me> <20250421125957.29@kylheku.com>
 <vu6kkt$392e6$1@dont-email.me> <vu6q3b$3jhq1$1@paganini.bofh.team>
 <vu7r19$da0o$1@dont-email.me> <20250422103555.547@kylheku.com>
 <vu8sm8$18fhc$2@dont-email.me> <vub14h$3d9kt$1@dont-email.me>
 <vub8rh$3kfla$1@dont-email.me> <vudak2$1i7us$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 24 Apr 2025 15:51:14 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a15eea173108e872714458e11e12d2b4";
	logging-data="1804479"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+As7KdwEgeC7LSmKF+uBgc"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:qAuRWgLV1r3poezCqEMGksv/0aM=
Content-Language: en-GB
In-Reply-To: <vudak2$1i7us$1@dont-email.me>

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?