Deutsch   English   Français   Italiano  
<vreqv1$16clp$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Python recompile
Date: Wed, 19 Mar 2025 16:21:54 +0000
Organization: A noiseless patient Spider
Lines: 69
Message-ID: <vreqv1$16clp$1@dont-email.me>
References: <vq1qas$j22$1@gallifrey.nk.ca> <vq4m0u$1ctpn$1@dont-email.me>
 <vq4n05$1d5dv$1@dont-email.me> <vq4om7$1dbo2$2@dont-email.me>
 <vq6dqh$1pskk$1@dont-email.me> <vq6f8p$1pmnk$1@dont-email.me>
 <vq6gqc$1qcp8$1@dont-email.me> <vq6ips$1pmnk$2@dont-email.me>
 <vq6j5h$1qosf$1@dont-email.me> <20250304092827.708@kylheku.com>
 <vq7g1p$1vmg5$1@dont-email.me> <vq8544$23f55$4@dont-email.me>
 <vq88s7$242vk$1@dont-email.me> <vq8cdq$24hi9$2@dont-email.me>
 <vq9di0$2db82$1@dont-email.me> <86frjruk1m.fsf@linuxsc.com>
 <vqaqnr$2l1ar$3@dont-email.me> <86bjudvnno.fsf@linuxsc.com>
 <vqdcko$36d74$1@dont-email.me> <86o6y4sinc.fsf@linuxsc.com>
 <vr3oc6$3di63$1@dont-email.me> <86v7s5pk3w.fsf@linuxsc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 19 Mar 2025 17:21:54 +0100 (CET)
Injection-Info: dont-email.me; posting-host="7e795a09c43565574fe5145a3967fadc";
	logging-data="1258169"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+LdvtHG1niT4/ewMU4Vsce"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:IM58GdVlCaCYcDHl7JDJ2JRjdvI=
Content-Language: en-GB
In-Reply-To: <86v7s5pk3w.fsf@linuxsc.com>
Bytes: 4430

On 19/03/2025 07:14, Tim Rentsch wrote:
> bart <bc@freeuk.com> writes:
> 
>> On 13/03/2025 21:52, Tim Rentsch wrote:
>>
>>> bart <bc@freeuk.com> writes:
>>>
>>>> Here however is a summary of these fictional tools:
>>>>
>>>> https://github.com/sal55/langs/blob/master/CompilerSuite.md
>>>
>>> I'm not interested in the tools.  What I am asking to see is
>>> the language.
>>
>> I'm working on a document that summaries the features.
> 
> I expect some people will find it interesting reading.  It is
> almost certainly worth writing, assuming there is an interested
> audience.

I don't know if you've seen the thread I made, where I posted a link to 
it. So any suggestions now are a little late.

The evidence is that no one is interested in this kind of language now.

I will use the write-up for my quick reference (to remind me of what's 
in there, which is quite a lot). But I will probably add appendices with 
some proper reference material.

> My interest is seeing a definition of the language, including
> at least a complete syntax, and some sort of description of
> the semantics for each construct, especially those that look
> or behave differently than familiar constructs in mainstream
> languages.

Most languages I've tinkered with, I haven't bothered with any 
references. I just need to know the basics (hello world; defining a 
function; printing a number).

I think most people don't until they have to use a language properly.

>  Being concise or terse is okay;  I don't need to
> read a belabored explanation of, for example, how function
> calls work, if they work the same way that function calls in
> C work.  But it is important, in this example, to say that
> function arguments are always evaluated left-to-right (if
> indeed that is the case),

A lot of this stuff is up to the implementation. Here, function 
arguments I believe are always evaluated right-to-left, which in my own 
implementation, is an assumption made in the front-end.

But it's really up to the backend. It could decide to reverse the order; 
there is enough info in the IL to do that, but it's messy. So it should 
really be a characeteristic that the front-end interrogates.

There's another issue with the stack, which normal grows downwards, but 
when the backend is told to interpret the IL, it grows upwards. So 
function arguments are physically ordered the other way around, but the 
right-most in the source code is still evaluated first.

(This had a bearing when the backend was used to interpret C, where my 
implementation of variadic function bodies assumed the stack went a 
certain way.)

Anyway, the ordering is not specified by the language, and should be be 
relied upon. It won't hurt to mention that though.