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.