From: cr88192@gmail.com
On 10/17/2025 4:07 PM, bart wrote:
> On 15/10/2025 19:00, BGB wrote:
>> On 10/15/2025 5:26 AM, bart wrote:
>>> On 15/10/2025 02:13, BGB wrote:
>>>
>>>> Apparently the languages people are trying to push as C replacements
>>>> are mostly Rust, Zig, and Go.
>>>>
>>>> None of these particularly compel me though.
>>>> They seem more like needless deviations from C than a true
>>>> successor.
>>>
>>> So what would a true successor look like?
>>>
>>
>> Probably sorta like C with a few vaguely C++ like features, but with a
>> cleaner and simpler design.
>>
>> Should ideally be usable for similar stuff to C.
>> Not drastically or needlessly different.
>
> Well, my own language is somewhere at the level of C, yet it looks very
> different.
>
> It was a rather crude affair in 1981/82, it has now evolved some modern
> conveniences. But I deliberately keep it low-level.
>
As for me, in 1982: I didn't exist yet.
So, alas, my journey mostly starts in the 90s (childhood) and 2000s
(teens / early 20s). But, alas, I have now exceeded 4 decades of existence.
>
> This is a C program to print some square roots:
>
> #include
> #include
>
> int main() {
> for (int i=1; i<=10; ++i)
> printf("%d %f\n", i, sqrt(i));
> }
>
In the language I was imagining as a hypothetical, probably:
using stdio, math;
int main() {
for (int i=1; i<=10; ++i)
printf("%d %f\n", i, sqrt(i));
}
Doesn't really match my personal style, but there is little here that
actually needs to change in the language as-imagined.
>
> This is it in my language (all are complete programs):
>
> proc main=
> for i to 10 do
> println i, sqrt i
> od
> end
>
Yeah.
In my first script language:
for(var i=0; i<=10; i++)
printf("%d %f\n", i, sqrt(i));
Generally there was no "main", but would instead basically execute
everything at the toplevel from top to bottom.
Function syntax was basically:
function foo(x, y)
{ return x+y; }
But, did allow a shorthand:
function foo(x, y) x+y;
Where, no braces meant that the expression was interpreted as the entire
body.
Alternatively:
function foo(x, y) { x+y }
Where, if a function is terminated by an expression with no semicolon,
then it behaved as if there was an implicit return statement.
Initially, it was dynamically typed, but later gained static types:
function foo(x:int, y:int):int { x+y }
Which did basically the same thing, but with the types as 32-bit integers.
Say:
var arr1 = [1,2,3,4,5]; //array, dynamically typed
var arr2:int[] = [1,2,3,4,5]; //array of int
var arr3 = [1,2,3,4,5]i; //array is int[], but arr3 is not.
var obj1 = {x:3, y:4}; //ex-nihilo object with 2 members
...
A later successor language had switched to a more Java like syntax and
structure. It was then in an awkward middle ground of being neither
great as a free-form scripting language; nor great as an implementation
language. Where it competed with C, but still lacked good integration
with C; as I had also switched to a simpler FFI modeled after C#'s
P/Invoke (its predecessor had used header-mining and auto-glue).
A more recent project had gone the complete opposite direction, and used
a language modeled off of 1980s era BASIC.
But, as noted, it ended up diverging some from BASIC, gaining the use of
dynamic scoping and "RETURN expr" + "x = GOSUB label", ...
Arguments could be provided, but also wonky:
Rather than being defined by the function, they are provided caller
side, mostly as names that are bound within the newly created dynamic
frame of the called label.
In this latter case, no separate parser, no bytecode, ...
Instead, the program was basically parsed into an array of token IDs
(grouped into lines), and the interpreter walked the tokens (with all
the keywords and special tokens defined first so that they got
statically-assigned numbers).
So, there was basically an array of tokens, and an array mapping lines
to indices in the token array, and an array to map labels to line
indices, ...
In this case, we are back to starting by walking down from the top of a
file. The parser design and syntax was also not very flexible, but
sufficient for the use-case.
I went this route mostly because it allows for a smaller/simpler
interpreter. So, whole language design was based mostly on how I could
do an interpreter within a relatively modest line-count (initial goal
being to fit everything in under 1000 lines of C).
Adding the CSG stuff basically blew out this limit though (could be
sub-1000 lines, but this mostly excludes things like vector math or CSG
solids; which also broke consistency with the "1980s BASIC" design
influence).
Where, had wanted something for some basic 3D modeling and animation
tasks, but: OpenSCAD + exporting STL didn't fit my needs.
Implementing the SCAD language, to extend with new features, would have
been more code.
In some ways, programmatic CSG is preferable to traditional 3D modeling
and animation tools (even if pretty much everyone else seems to prefer
triangle mesh models and GUI-driven 3D model tools over CSG and
describing geometry directly). Though, granted, nicer to have have
higher-level primitives and operators, rather than having to do
everything manually with planes and "Brush Solids". Though, internally,
the primitives get turned into "brush solids" based on collections of
planes, with geometry mostly being clipped between solids using the
planes (so, you don't have true spheres, rather a sphere becomes a brush
with a large number of planes, ...).
Granted, all the code for the CSG proper is not counted in the line
count for the BASIC interpreter, otherwise the number would be
significantly higher.
But, in this language, one could have something like:
let i=0
lbl0:
print i
i=i+1
if i<=10 goto lbl0
Where, "THEN" is optional if "GOTO" or similar is used.
Though, "THEN" is required if you want an "ELSE" clause.
Note that both clauses need to go on the same line.
Note that in this case, the language was case-insensitive as the
keywords and identifiers were case normalized.
L0:
...
GOTO L0
Is equivalent to:
l0:
...
goto l0
Traditionally, BASIC is written all upper case though, but then one
needs to SHIFT or CAPS-LOCK the whole time.
>
> Finally, this is it in Zig:
>
> const std = @import("std");
>
> pub fn main() void {
> for (1..11) |i| {
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
