From Newsgroup: comp.lang.c

On 2026-09-10 09:48, David Brown wrote:

On 10/09/2026 00:30, bart wrote:

On 09/09/2026 22:26, Janis Papanagnou wrote:

[...]

[...]

[...]

Each type of import has its own advantages and disadvantages.

Type 1 would need micro-management if you want a lot of symbols from a module.-a But if you only need a small number, it can keep things neat -
you only see what you actually want to use.-a And if the imported module only really exports a single name (like "my_class.py" exporting
"My_Class"), it's a neat solution that avoids later code clutter from
having to specify the module name.

Type 2 lets you immediately use all the identifiers from the module, but causes a lot of problems if things change in the future.-a Maybe your own code has a function "fluff", and a later version of "foobar.py" also
adds a function "fluff".-a That is not going to be good.

Type 3 lets you conveniently import all the exported symbols from the module, but you need to specify the namespace when using them.

As I see it, Janis favours that kind of flexibility for modules (though
of course the details may differ for different languages).

Since you mentioned me - and since I don't intend after my thorough
explanation to spend yet more time with bart's posts about it - let
me confirm your interpretation, and give an example from practice.

Note also that none of the languages I'm currently using is supporting
that principle - there's no "best" language in that respect, although
some are closer to an ideal modularization than others. (Some recent
languages [that I don't know] may do a better job here, I'd expect.)

Once I needed a function to produce Gaussian noise - and nothing else!
(Back then I used, I think, the Fortran IMSL library.) - In a modern modules-supporting environment I'd have liked to have something like

use imsl.math.rand.gauss

I don't want the whole library, nor the whole math package, nor all
the random functions. I want them neither pollute my namespace, nor
do I want that libraries, library components, or functions are even
considered for inclusion, neither on the program text level, nor at
the binary module level, if they are not needed.

In case of name clashes that happen despite a pinpointed inclusion
there's still an optional qualification syntax necessary. - In case
of the above example the "structuring path" could be used for that,
say, for example, something like rand.gauss and matrix.gauss .

You seem to be favouring just type 2 - or even a "from * import *" solution.-a That might be convenient for a personal language where you
are the only one ever writing the code - you know there are no
collisions, because you wrote everything.-a For anyone else, working
outside a bubble, it is unscalable.

What I find annoying with his posts is that from within his bubble he's
not even trying to look outside his horizon, even with obvious things.
His inept exaggerations, the sloppiness, and misrepresentations add to
the annoyance. - I'm tired.

Thanks for taking the task to explain that to him.

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 10/09/2026 23:06, Janis Papanagnou wrote:

On 2026-09-10 09:48, David Brown wrote:

On 10/09/2026 00:30, bart wrote:

On 09/09/2026 22:26, Janis Papanagnou wrote:

[...]

[...]

[...]

Each type of import has its own advantages and disadvantages.

Type 1 would need micro-management if you want a lot of symbols from a
module.-a But if you only need a small number, it can keep things neat
- you only see what you actually want to use.-a And if the imported
module only really exports a single name (like "my_class.py" exporting
"My_Class"), it's a neat solution that avoids later code clutter from
having to specify the module name.

Type 2 lets you immediately use all the identifiers from the module,
but causes a lot of problems if things change in the future.-a Maybe
your own code has a function "fluff", and a later version of
"foobar.py" also adds a function "fluff".-a That is not going to be good.

Type 3 lets you conveniently import all the exported symbols from the
module, but you need to specify the namespace when using them.


As I see it, Janis favours that kind of flexibility for modules
(though of course the details may differ for different languages).

Since you mentioned me - and since I don't intend after my thorough explanation to spend yet more time with bart's posts about it - let
me confirm your interpretation, and give an example from practice.

Note also that none of the languages I'm currently using is supporting
that principle - there's no "best" language in that respect, although
some are closer to an ideal modularization than others. (Some recent languages [that I don't know] may do a better job here, I'd expect.)

Once I needed a function to produce Gaussian noise - and nothing else!
(Back then I used, I think, the Fortran IMSL library.) - In a modern modules-supporting environment I'd have liked to have something like

-a use imsl.math.rand.gauss

I don't want the whole library, nor the whole math package, nor all
the random functions. I want them neither pollute my namespace, nor
do I want that libraries, library components, or functions are even considered for inclusion, neither on the program text level, nor at
the binary module level, if they are not needed.

In case of name clashes that happen despite a pinpointed inclusion
there's still an optional qualification syntax necessary. - In case
of the above example the "structuring path" could be used for that,
say, for example, something like-a rand.gauss-a and-a matrix.gauss .

You seem to be favouring just type 2 - or even a "from * import *"
solution.-a That might be convenient for a personal language where you
are the only one ever writing the code - you know there are no
collisions, because you wrote everything.-a For anyone else, working
outside a bubble, it is unscalable.

What I find annoying with his posts is that from within his bubble he's
not even trying to look outside his horizon,

You don't try to look much outside yours either.

But also, the difference between you and me is that I devise my own
solutions, and do not have to settle for someone else's decisions.

In any case, my module scheme is intended to work between the
constituent modules of programs designed to work with whole-program compilation, more than for external libraries written by someone else.

Generally these have to be more 'chummy' and are non-hierarchical, but
there are hierarchical options within the program's modules too for
better segregation and structure.

His inept exaggerations, the sloppiness,

When you have to implement this stuff then you can't be sloppy. Perhaps
you're just jealous that my scheme isn't available in your favourite
language.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-09-10 10:11, David Brown wrote:

On 09/09/2026 23:07, Janis Papanagnou wrote:

[...]

But there need not be a problem using '=' for assignments and also
for comparisons if the respective languages could tell them apart by
context and with appropriate semantic rules.

Agreed.-a In my "dream language", assignment would be a statement, not an expression, which lets you use the same symbol.

I'm not sure it's a good idea to have the same symbol here. I'd
certainly prefer a separate symbol anyway. (Notwithstanding that
a context dependent differentiation is or might be possible.)

I suppose "C" has adopted the assignment being an expression from
Algol 68; but in the latter case we *do* have separate symbols.
I suspect that "C" might have just used a '=' instead of the back
then already not uncommon ':=' just to save some tying?
The "problem" is obviously not the assignment-expression per se;
but the comprised design choices of the C-language as a whole.

Indeed, assignment
would be very rare - normally variables would be initialised once, and
never changed.

Incidentally that's exactly what I observed in recent times when
I recovered my Algol 68 programming; the language defines such a
handling by "identity declarations".
INT answer = 42 defines an item of reference level 0 (constant)
INT state := 0 defines/initializes a variable (reference level 1)
and I noticed in my programs a prevalence of identity declarations
and mostly only few variables.

Given that observation it may be unfortunate that we need explicit
'const' to specify such identities in "C", a language that strived
for terseness (as it seems).

Janis

[...]

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

bart <bc@freeuk.com> writes:
[...]

But also, the difference between you and me is that I devise my own solutions, and do not have to settle for someone else's decisions.

And you insist on discussing your solutions in comp.lang.c.

I see you've posted to comp.lang.misc. I encourage you to do so more
often.

[...]

When you have to implement this stuff then you can't be
sloppy. Perhaps you're just jealous that my scheme isn't available in
your favourite language.

When you're the only user, you can get away with being sloppy and
covering only the use cases that apply to you.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

bart pisze:

On 10/09/2026 15:59, fir wrote:

fir pisze:

Try it with a real example, such as:

-a-a-a-a-a succeeded =-a tdefl_init pComp-a pPut_buf_func-a pPut_buf_user >>>> flags == TDEFL_STATUS_OKAY ;

-a-a-a-a-a succeeded = succeeded &&-a tdefl_compress_buffer pComp-a pBuf >>>> buf_len-a TDEFL_FINISH == TDEFL_STATUS_DONE

im not sure what you mean hera bove but with this e conventions im
talkin abouts its

succeeded =-a tdefl_init( pComp,-a pPut_buf_func,-a pPut_buf_user,
flags== TDEFL_STATUS_OKAY) ;

Not bad, but this is the original:

-a-a succeeded = (tdefl_init(pComp, pPut_buf_func, pPut_buf_user, flags)
== TDEFL_STATUS_OKAY);

thet would be

succeeded = (tdefl_init pComp-a pPut_buf_func-a pPut_buf_user-a flags ) == TDEFL_STATUS_OKAY

and

succeeded = succeeded &&-a tdefl_compress_buffer( pComp , pBuf,
buf_len, TDEFL_FINISH == TDEFL_STATUS_DONE);

And here's the original for this:

-a-a-a-a succeeded = succeeded && (tdefl_compress_buffer(pComp, pBuf,
buf_len, TDEFL_FINISH) == TDEFL_STATUS_DONE);


I think the parentheses and commas do a good job in removing ambiguity.

Although the originals probably had one pair of superfluous
parentheses each, as '=='s precedence is already higher than both =
and &&.

But, what are you planning with general expressions: will you still
have operator precedences?

if the comma and parenthesis are not needed why use them

esp as a most amount of code is like

-avoid RunFrame advance
-a{
-a-a-a-a-a Initialise,
-a-a-a-a-a ClearFrameData 0x444444
-a-a-a-a-a DrawLine3d 100.0-a-a 100.0-a-a 0.0-a-a-a-a 100.0 -100.0 0.0-a-a-a 0xffffff
-a-a-a-a-a DrawLine3d 100.0-a -100.0-a-a 0.0-a-a-a -100.0 -100.0 0.0-a-a-a 0xffffff
-a-a-a-a-a DrawLine3d -100.0 -100.0-a-a 0.0-a-a-a -100.0-a 100.0 0.0-a-a-a 0xffffff
-a-a-a-a-a DrawLine3d -100.0-a 100.0-a-a 0.0-a-a-a-a 100.0-a 100.0 0.0-a-a-a 0xffffff
-a-a-a-a-a DrawDot3d 0.0 0.0 100.0-a-a 20.0-a 0x557788
-a-a-a-a-a DrawDot3d 0.0 0.0 150.0-a-a 30.0-a 0x557722
-a-a-a-a-a DrawDot3d 0.0 0.0 -100.0-a 10.0-a 0xaa7788
-a-a-a-a-a InitSomeJointsFigures
-a-a-a-a-a DrawCloud1, DrawCloud2,
-a-a-a-a DrawCloud11, DrawCloud12, UpdateDotsBag, DrawDotsBag

-aFillRectangle2 10 10 20 20 color
-a-a DrawSomeText2F 0xcccccc 0x666666 20 10 " %x \x00"-a-a 0xffffff
-a-a DrawSomeText2F 0xcccccc 0x666666 10 20 "hello, this is example
program compiled by fir's furia compiler \x00"

-a-a-a DeawLines
-a-a-a DrawTextByBalls "hello\x00" 0 0 0x999999
-a-a-a DrawCubesCubeGeo

-a-a BezierPatchTest

-a-a space_pressed? FireDotFromCameraCurrentColor 0.0 0.0 100000 20
-a-a a_pressed?!-a FireDotFromCameraCurrentColor 1.0 0.0 10000 20
-a-a f5_toggler? DrawManual

-a-a DrawFloor 20000 30 0x555555
-a-a DrawRawModel

-a}

i mean lot are "normal" simple calls and there is a lot of (,,,,);
to skip
as to operator precedence ofc its needed and as i said what i show
here is the part that is "resolved" but there are more complex
cases where it is not resolved yet

(for example for this many return values , operator form of functions
(as a would like to have "x foo y" where foo is a function and x y are arguments, and those float char types, some constructions like loops
and so on

i consider yet such syntax


ru2mandelbrot_calculate N|eimage_beg_x N|eimage_beg_y N|eimage_end_x N|eimage_end_y N|eox N|eoy N|elx rC+max_iter
{
lyN|e lx*frame_size_y/frame_size_x
dxN|e lx/frame_size_x
dyN|e lx/frame_size_x
axN|e ox-lx*.5+dx*.5
ayN|e oy-ly*.5+dy*.5

jrC+ image_beg_y..image_end_y { c_imN|e ay+j*dy
irC+ image_beg_x..image_end_x { c_reN|e ax+i*dx
nrC+ mandelbrot_n c_re c_im max_iter, sumarC+ suma+n,
OffscreenBufferSetValue i j n }}
}


axN|e mean "double ax ="
N|eimage_beg_y means "N|eimage_beg_y"
nrC+ means "int n ="

and so on

so this will cover doubles and ints but no solutions for chars floats
schorts, defined types etc - so it may be a problem (alse those
typenames in heaer consumes types/chars

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 10/09/2026 08:48, David Brown wrote:

On 10/09/2026 00:30, bart wrote:

On 09/09/2026 22:26, Janis Papanagnou wrote:

On 2026-09-09 20:12, bart wrote:

On 09/09/2026 02:59, Waldek Hebisch wrote:

[...]

Some even specify individual names to be imported from a module.
What a complete waste of time!

I fear you're just exposing your very limited perception and experience
here. (And en passant probably also the mindset of a technocratic paper
pusher than a software designer.)

Myself I'm favoring _to be able_ to import only what I need and not the
whole bunch of existing things of a module (with all potential implicit
and explicit consequences).

Why? What is the advantage of so much micromanagement?

Consider modules in Python, since that is a language with "real" modules
and with which many people are familiar.

# foobar.py
def foo() : return "foo"
def bar() : return "bar"

Another file user.py wants to use "foo" from "foobar.py".-a They can do
so in three main ways :

1. Specific inclusion

from foobar import foo
x = foo()

2. Global namespace inclusion

from foobar import *
x = foo()

3. Module namespace inclusion

import foobar
x = foobar.foo()

Each type of import has its own advantages and disadvantages.

Type 1 would need micro-management if you want a lot of symbols from a module.-a But if you only need a small number, it can keep things neat -
you only see what you actually want to use.

Python doesn't have export attributes. That means that every top- or module-level identifier can be imported into another module.

In mine, entities have to be explicitly exported to be visible outside.
That means importing everything that a module exports is fine; that's
the idea!

And if the imported module
only really exports a single name (like "my_class.py" exporting
"My_Class"), it's a neat solution that avoids later code clutter from
having to specify the module name.

I allow that anyway. Unless two modules export the same name then the
compiler complains. However a local name can silently shadow an imported
name, but that's how scopes work in general.

Type 2 lets you immediately use all the identifiers from the module, but causes a lot of problems if things change in the future.-a Maybe your own code has a function "fluff", and a later version of "foobar.py" also
adds a function "fluff".-a That is not going to be good.

Type 3 lets you conveniently import all the exported symbols from the module, but you need to specify the namespace when using them.

As I see it, Janis favours that kind of flexibility for modules (though
of course the details may differ for different languages).

You seem to be favouring just type 2 - or even a "from * import *"
solution.

Mine actually can be a little more sophisticated. Say for example you
have a mini-library of three modules, and the whole exports several
functions from across those modules.

In Python you'd have to import all three modules: you'd need to now the internal structure, which in future can change.

With mine, you just import the lead module of the three. If
qualification is needed, then you use the name of the lead module; the internal structure is opaque.

It is also possible to encapsulate a bunch of functions and stuff which
is only available via a namespace.

That might be convenient for a personal language where you
are the only one ever writing the code - you know there are no
collisions, because you wrote everything.-a For anyone else, working
outside a bubble, it is unscalable.

As I explained in a post a little while ago, my module scheme is mainly intended to manage the modules of a single program intended for
whole-program compilation. That includes self-contain mini-libraries
which are statically compiled into the app.

For external libraries, there is a separate approach called the 'FFI'.

There, typically, I would need to create bindings. For my SDL3 example,
that would define 1200 functions, plus 3000 more named constants,
macros, enumerations, structs and types.

This is not part of the module scheme, other than the bindings for
imported FFI functions being with a container module that will re-export
them for use with the rest of the application. That container module
will wrap them in an optional namespace.

Here it would obviously be ludicrous to micro-manage large, unwieldy
subsets of those 4000 names. A program would just do:

module sdl # sdl.m contains the 4000 lines which is condensed
# form of the 86 SDL3 headers

Then all 4000 names will be available. The same as in C, except that I
can shadow them if needed.

I can call SDL3 functions like this:

sql_quit()

This is SDL_Quit in C, but my language allows any case. Or I can apply
the qualifier:

sdl.sql_quit()

But this is obviously a bit silly; SDL names already have a special prefix.

That 'module sdl' line BTW exists in one place in the program. The 4K
sdl.m module is compiled once no matter how many modules in all.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 10/09/2026 23:52, Keith Thompson wrote:

bart <bc@freeuk.com> writes:
[...]

But also, the difference between you and me is that I devise my own
solutions, and do not have to settle for someone else's decisions.

And you insist on discussing your solutions in comp.lang.c.

I see you've posted to comp.lang.misc. I encourage you to do so more
often.

Look, this group is more or less dead (you can thank fir for breathing
some life into it recently!), and comp.lang.misc pretty much is. Besides nobody bothers with topicality any more.

At least I still discuss related technical topics.

[...]

When you have to implement this stuff then you can't be
sloppy. Perhaps you're just jealous that my scheme isn't available in
your favourite language.

When you're the only user, you can get away with being sloppy and
covering only the use cases that apply to you.

The scheme I use would suffice for ALL projects I've worked on; ALL
programs I've written in C (not many); and many open source C projects
that I've come across.

(I can't say 'most', as they are often too complex and chaotic to see if
my approach would apply.)

And I repeat, when you have to implement it, it has to work. It's no
good if it's buggy!
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

bart <bc@freeuk.com> writes:

On 10/09/2026 23:52, Keith Thompson wrote:

[...]

I see you've posted to comp.lang.misc. I encourage you to do so more
often.

[...]

Besides nobody bothers with topicality any more.

Manifestly untrue.

[...]

When you have to implement this stuff then you can't be
sloppy. Perhaps you're just jealous that my scheme isn't available in
your favourite language.

When you're the only user, you can get away with being sloppy and
covering only the use cases that apply to you.

[...]

To be clear, that wasn't necessarily meant as a criticism. When I
wrote code for my own use, I feel free to ignore cases that I
personally don't find useful -- cases that I would want to cover
if I were to share the code publicly.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 10/09/2026 23:08, Chris M. Thomasson wrote:

On 9/9/2026 5:43 AM, David Brown wrote:
[...]

Just defining the symbol is fine - for use as a pure header guard,
where the check is with "#ifndef" or "#ifdef", defining it to a value
has no added value.-a Adding the "1" in that example was done without
thinking.

________
#ifndef __NUMBER_GENERATOR_H__
#define __NUMBER_GENERATOR_H__ 1
________

Is that __* non conformant? Does it breach the impl name prefix space?

Yes. As Keith pointed out, using "H_NUMBER_GENERATOR_" or similar is
better. Various conventions are used, and usually the risk of
collisions with implementations is entirely negligible. But there is no
cost in avoiding reserved prefixes, so you might as well do so.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 10/09/2026 19:17, fir wrote:

David Brown pisze:

On 10/09/2026 18:21, fir wrote:

David Brown pisze:

Either this is just a waste of time (and the fact that most of your
posts are replies to your own posts suggest that this is the case), or
you are really interested in making a new language - and
comp.lang.misc would be a better place to discuss it.

how it suggest that? note thise are 'replies' maybe in some technical
sense of a usenet reader..but on thought /write level they are just continuation of thoughts/topic..its rather quite artificall to write ll
you got to say in one post and assume you have nothing to add ..i often
have things to add

Public forums - like a Usenet group - are not like having a whiteboard
on your wall. If you ask questions that are topical to the group, or
make comments or replies that are topical to the group, that's great.
When you ramble with wild ideas, post after post, that's just wasting everyone's time. People don't give any feedback, and mostly skip them.

So please, write your ramblings on a bit of paper or a whiteboard. When
you have something worth sharing with other people, and you want
feedback or help, post them to an appropriate group. If it is actually
about C, that's comp.lang.c. If it is about a weird new language with
lots of Unicode signs and a very different syntax, comp.lang.misc is a
better choice.

This is surely not difficult to understand.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

David Brown pisze:

On 10/09/2026 19:17, fir wrote:

David Brown pisze:

On 10/09/2026 18:21, fir wrote:

David Brown pisze:

Either this is just a waste of time (and the fact that most of your
posts are replies to your own posts suggest that this is the case),
or you are really interested in making a new language - and
comp.lang.misc would be a better place to discuss it.

how it suggest that? note thise are 'replies' maybe in some technical
sense of a usenet reader..but on thought /write level they are just
continuation of thoughts/topic..its rather quite artificall to write
ll you got to say in one post and assume you have nothing to add ..i
often have things to add

Public forums - like a Usenet group - are not like having a whiteboard
on your wall.-a If you ask questions that are topical to the group, or
make comments or replies that are topical to the group, that's great.
When you ramble with wild ideas, post after post, that's just wasting everyone's time.-a People don't give any feedback, and mostly skip them.

So please, write your ramblings on a bit of paper or a whiteboard.-a When you have something worth sharing with other people, and you want
feedback or help, post them to an appropriate group.-a If it is actually about C, that's comp.lang.c.-a If it is about a weird new language with
lots of Unicode signs and a very different syntax, comp.lang.misc is a better choice.

This is surely not difficult to understand.

what you say is shallow looking on C so i cant agree... you try to
impose you shallow view (just some way like keith thompson want to
impose his rigid rukles here that this group is only for standard freaks)

i may partially agree that some investigation in possible c syntax/skin
are somewhat intermediate - but those are intermediate results kinda
needed to obtain final conclusions

i dont much can do something with fact that some post dont interest you
- belive many posts who many wrote here not interest me also (like
things keith writes, or trigraph topic and many more)
(regular c stuff is also not so much interesting, its ok, but some
deeper c ideas much more interesting)


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

David Brown pisze:

On 10/09/2026 19:17, fir wrote:

David Brown pisze:

On 10/09/2026 18:21, fir wrote:

David Brown pisze:

Either this is just a waste of time (and the fact that most of your
posts are replies to your own posts suggest that this is the case),
or you are really interested in making a new language - and
comp.lang.misc would be a better place to discuss it.

how it suggest that? note thise are 'replies' maybe in some technical
sense of a usenet reader..but on thought /write level they are just
continuation of thoughts/topic..its rather quite artificall to write
ll you got to say in one post and assume you have nothing to add ..i
often have things to add

Public forums - like a Usenet group - are not like having a whiteboard
on your wall.-a If you ask questions that are topical to the group, or
make comments or replies that are topical to the group, that's great.
When you ramble with wild ideas, post after post, that's just wasting
everyone's time.-a People don't give any feedback, and mostly skip them.

So please, write your ramblings on a bit of paper or a whiteboard.
When you have something worth sharing with other people, and you want
feedback or help, post them to an appropriate group.-a If it is
actually about C, that's comp.lang.c.-a If it is about a weird new
language with lots of Unicode signs and a very different syntax,
comp.lang.misc is a better choice.

This is surely not difficult to understand.

what you say is shallow looking on C so i cant agree... you try to
impose you shallow view (just some way like keith thompson want to
impose-a his rigid rukles here that this group is only for standard freaks)

i may partially agree that some investigation in possible c syntax/skin
are somewhat intermediate - but those are intermediate results kinda
needed to obtain final conclusions

i dont much can do something with fact that some post dont interest you
- belive many posts who many wrote here not interest me also (like
things keith writes, or trigraph topic and many more)
(regular c stuff is also not so much interesting, its ok, but some
deeper c ideas much more interesting)

speaking about this whiteboard or blackboard : also not this group has
some historical value and people may be interested how this great new
language by fir was born (great new B or great new C or great new D
or even more like great new E or -e or -a still problems with tha name

if i took a way to use unicode maybe i should take unicode sign?
it will make all this printers to print unicode in papers so that would
be kinda new impact )
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 11/09/2026 13:13, fir wrote:

speaking about this whiteboard or blackboard : also not this group has
some historical value and people may be interested how this great new language by fir was born (great new B or great new C or great new D
or even more like great new E-a or -e or -a still problems with tha name

If you're looking for a name for your new language ...
... might I suggest EfA-


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Richard Harnden pisze:

On 11/09/2026 13:13, fir wrote:

speaking about this whiteboard or blackboard : also not this group has
some historical value and people may be interested how this great new
language by fir was born (great new B or great new C or great new D
or even more like great new E-a or -e or -a still problems with tha name

If you're looking for a name for your new language ...
... might I suggest EfA-

assuming that im right and youre part of history - youre get known for
this - and its not so much glorious legacy
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

Richard Harnden pisze:

On 11/09/2026 13:13, fir wrote:

speaking about this whiteboard or blackboard : also not this group
has some historical value and people may be interested how this great
new language by fir was born (great new B or great new C or great new D
or even more like great new E-a or -e or -a still problems with tha name

If you're looking for a name for your new language ...
... might I suggest EfA-

assuming that im right and youre part of history - youre get known for
this - and its not so much glorious legacy

im a bit joking here but note 'joking' is giving to know thet what some
say is in some way not to 'stright' understanding but not exactly
precisiszing whet is not 'strict' and what not

i hjust now wana go frome one banal to another (and one strict view on
thing turned into quite another different strict view may become turnin
banal into banal and the progres is for me from somewhat banal or not
balal into less banal

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

Richard Harnden pisze:

On 11/09/2026 13:13, fir wrote:

speaking about this whiteboard or blackboard : also not this group
has some historical value and people may be interested how this great
new language by fir was born (great new B or great new C or great new D
or even more like great new E-a or -e or -a still problems with tha name

If you're looking for a name for your new language ...
... might I suggest EfA-

assuming that im right and youre part of history - youre get known for
this - and its not so much glorious legacy

i hope though history will not remember it too much becouse it would
spoil its mood to remember such ultra banal and low outcomes
(even not so much representative fortunatelly)

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

fir pisze:

David Brown pisze:

On 10/09/2026 19:17, fir wrote:

David Brown pisze:

On 10/09/2026 18:21, fir wrote:

David Brown pisze:

Either this is just a waste of time (and the fact that most of your >>>>> posts are replies to your own posts suggest that this is the case), >>>>> or you are really interested in making a new language - and
comp.lang.misc would be a better place to discuss it.

how it suggest that? note thise are 'replies' maybe in some
technical sense of a usenet reader..but on thought /write level they
are just continuation of thoughts/topic..its rather quite artificall
to write ll you got to say in one post and assume you have nothing
to add ..i often have things to add

Public forums - like a Usenet group - are not like having a
whiteboard on your wall.-a If you ask questions that are topical to
the group, or make comments or replies that are topical to the group,
that's great. When you ramble with wild ideas, post after post,
that's just wasting everyone's time.-a People don't give any feedback,
and mostly skip them.

So please, write your ramblings on a bit of paper or a whiteboard.
When you have something worth sharing with other people, and you want
feedback or help, post them to an appropriate group.-a If it is
actually about C, that's comp.lang.c.-a If it is about a weird new
language with lots of Unicode signs and a very different syntax,
comp.lang.misc is a better choice.

This is surely not difficult to understand.

what you say is shallow looking on C so i cant agree... you try to
impose you shallow view (just some way like keith thompson want to
impose-a his rigid rukles here that this group is only for standard
freaks)

i may partially agree that some investigation in possible c syntax/skin
are somewhat intermediate - but those are intermediate results kinda
needed to obtain final conclusions

i dont much can do something with fact that some post dont interest
you - belive many posts who many wrote here not interest me also (like
things keith writes, or trigraph topic and many more)
(regular c stuff is also not so much interesting, its ok, but some
deeper c ideas much more interesting)

speaking about this whiteboard or blackboard : also not this group has
some historical value and people may be interested how this great new language by fir was born (great new B or great new C or great new D
or even more like great new E-a or -e or -a still problems with tha name

there is also an option of raa to consider

if i took a way to use unicode maybe i should take unicode sign?
it will make all this printers to print unicode in papers so that would
be kinda new impact )

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

fir pisze:

fir pisze:

David Brown pisze:

On 10/09/2026 19:17, fir wrote:

David Brown pisze:

On 10/09/2026 18:21, fir wrote:

David Brown pisze:

Either this is just a waste of time (and the fact that most of
your posts are replies to your own posts suggest that this is the >>>>>> case), or you are really interested in making a new language - and >>>>>> comp.lang.misc would be a better place to discuss it.

how it suggest that? note thise are 'replies' maybe in some
technical sense of a usenet reader..but on thought /write level
they are just continuation of thoughts/topic..its rather quite
artificall to write ll you got to say in one post and assume you
have nothing to add ..i often have things to add

Public forums - like a Usenet group - are not like having a
whiteboard on your wall.-a If you ask questions that are topical to
the group, or make comments or replies that are topical to the
group, that's great. When you ramble with wild ideas, post after
post, that's just wasting everyone's time.-a People don't give any
feedback, and mostly skip them.

So please, write your ramblings on a bit of paper or a whiteboard.
When you have something worth sharing with other people, and you
want feedback or help, post them to an appropriate group.-a If it is
actually about C, that's comp.lang.c.-a If it is about a weird new
language with lots of Unicode signs and a very different syntax,
comp.lang.misc is a better choice.

This is surely not difficult to understand.

what you say is shallow looking on C so i cant agree... you try to
impose you shallow view (just some way like keith thompson want to
impose-a his rigid rukles here that this group is only for standard
freaks)

i may partially agree that some investigation in possible c syntax/skin
are somewhat intermediate - but those are intermediate results kinda
needed to obtain final conclusions

i dont much can do something with fact that some post dont interest
you - belive many posts who many wrote here not interest me also
(like things keith writes, or trigraph topic and many more)
(regular c stuff is also not so much interesting, its ok, but some
deeper c ideas much more interesting)

speaking about this whiteboard or blackboard : also not this group has
some historical value and people may be interested how this great new
language by fir was born (great new B or great new C or great new D
or even more like great new E-a or -e or -a still problems with tha name

there is also an option of raa to consider

this one may be clever as you may treat C as a mooon shape it suggest
that C might enetered a new mooon (black moon) and after this is raa
phase - C rising again..assuming C and raa are both parts of O

it is some kind of pleasing, but enough to take it?

if i took a way to use unicode maybe i should take unicode sign?
it will make all this printers to print unicode in papers so that
would be kinda new impact )

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

fir pisze:

fir pisze:

fir pisze:

David Brown pisze:

On 10/09/2026 19:17, fir wrote:

David Brown pisze:

On 10/09/2026 18:21, fir wrote:

David Brown pisze:

Either this is just a waste of time (and the fact that most of
your posts are replies to your own posts suggest that this is the >>>>>>> case), or you are really interested in making a new language -
and comp.lang.misc would be a better place to discuss it.

how it suggest that? note thise are 'replies' maybe in some
technical sense of a usenet reader..but on thought /write level
they are just continuation of thoughts/topic..its rather quite
artificall to write ll you got to say in one post and assume you
have nothing to add ..i often have things to add

Public forums - like a Usenet group - are not like having a
whiteboard on your wall.-a If you ask questions that are topical to >>>>> the group, or make comments or replies that are topical to the
group, that's great. When you ramble with wild ideas, post after
post, that's just wasting everyone's time.-a People don't give any
feedback, and mostly skip them.

So please, write your ramblings on a bit of paper or a whiteboard.
When you have something worth sharing with other people, and you
want feedback or help, post them to an appropriate group.-a If it is >>>>> actually about C, that's comp.lang.c.-a If it is about a weird new
language with lots of Unicode signs and a very different syntax,
comp.lang.misc is a better choice.

This is surely not difficult to understand.

what you say is shallow looking on C so i cant agree... you try to
impose you shallow view (just some way like keith thompson want to
impose-a his rigid rukles here that this group is only for standard
freaks)

i may partially agree that some investigation in possible c syntax/skin >>>> are somewhat intermediate - but those are intermediate results kinda
needed to obtain final conclusions

i dont much can do something with fact that some post dont interest
you - belive many posts who many wrote here not interest me also
(like things keith writes, or trigraph topic and many more)
(regular c stuff is also not so much interesting, its ok, but some
deeper c ideas much more interesting)

speaking about this whiteboard or blackboard : also not this group
has some historical value and people may be interested how this great
new language by fir was born (great new B or great new C or great new D
or even more like great new E-a or -e or -a still problems with tha name >>>

there is also an option of raa to consider

this one may be clever as you may treat C as a mooon shape it suggest
that C might enetered a new mooon (black moon) and after this is-a raa
phase - C rising again..assuming C and-a raa are both parts of O

it is some kind of pleasing, but enough to take it?

okay for now its somewhat pleasing , so i take it for now,
(takin in considaretion my words on barbarians, raa fits in that story )
but no guarantee i dont chamge it

(bit for now its reserved)

if i took a way to use unicode maybe i should take unicode sign?
it will make all this printers to print unicode in papers so that
would be kinda new impact )

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

bart <bc@freeuk.com> writes:

When you have to implement this stuff then you can't be sloppy.

You demonstrated you can be extremely sloppy in your thinking and
in your argumentation! That doesn't mean that you wouldn't be able
to "write programs" ("this stuff"), for sure. - Another example of
sloppy thinking and argumentation.

Perhaps you're just jealous

Your mindset is so primitive, naive, and erroneous; unprecedentedly
given your stubbornness. Your persistent habit of making guesses,
completely missing the point, topics, and characters, had regularly
been shown to be widely erroneous. - I see you can't just stop your
ineffective tries. It won't lead you anywhere.

that my scheme isn't available in your favourite language.

I have no "favourite language". (In a couple languages there's some
concepts that I'd like to be more widely spread. - Not sure you're
capable of understanding that and notice the blatant difference!)

And you should meanwhile know that meaningless home-brewed languages
are neither of general interest nor of mine; but you seem to have a
persisting mental hindrance to understand what is easy understandable
by others. - Just to be clear; I don't know that "my scheme" you're
talking about is because I'm not interested in your posts about your
personal tools.

(I also suggest to become a bit more honest about your "achievement"
with creating your tool unless it gets some minimum general relevance
beyond your micro-ecosystem. - Why don't you advertise and offer your
tools at any more appropriate place if you think they're so important, innovative, or generally useful?!)

Janis

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Janis Papanagnou pisze:

bart <bc@freeuk.com> writes:

When you have to implement this stuff then you can't be sloppy.

You demonstrated you can be extremely sloppy in your thinking and
in your argumentation! That doesn't mean that you wouldn't be able
to "write programs" ("this stuff"), for sure. - Another example of
sloppy thinking and argumentation.

Perhaps you're just jealous

Your mindset is so primitive, naive, and erroneous; unprecedentedly
given your stubbornness. Your persistent habit of making guesses,
completely missing the point, topics, and characters, had regularly
been shown to be widely erroneous. - I see you can't just stop your ineffective tries. It won't lead you anywhere.

that my scheme isn't available in your favourite language.

I have no "favourite language". (In a couple languages there's some
concepts that I'd like to be more widely spread. - Not sure you're
capable of understanding that and notice the blatant difference!)

And you should meanwhile know that meaningless home-brewed languages
are neither of general interest nor of mine; but you seem to have a persisting mental hindrance to understand what is easy understandable
by others. - Just to be clear; I don't know that "my scheme" you're
talking about is because I'm not interested in your posts about your
personal tools.

(I also suggest to become a bit more honest about your "achievement"
with creating your tool unless it gets some minimum general relevance
beyond your micro-ecosystem. - Why don't you advertise and offer your
tools at any more appropriate place if you think they're so important, innovative, or generally useful?!)

Janis

lol, i told keith's team are funny asses..it needs some funcy answer:

you say 'usefull', i tell "your mum is doin new school"

https://www.youtube.com/watch?v=cumbkA5dGDI



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

Janis Papanagnou pisze:

bart <bc@freeuk.com> writes:

When you have to implement this stuff then you can't be sloppy.

You demonstrated you can be extremely sloppy in your thinking and
in your argumentation! That doesn't mean that you wouldn't be able
to "write programs" ("this stuff"), for sure. - Another example of
sloppy thinking and argumentation.

Perhaps you're just jealous

Your mindset is so primitive, naive, and erroneous; unprecedentedly
given your stubbornness. Your persistent habit of making guesses,
completely missing the point, topics, and characters, had regularly
been shown to be widely erroneous. - I see you can't just stop your
ineffective tries. It won't lead you anywhere.

that my scheme isn't available in your favourite language.

I have no "favourite language". (In a couple languages there's some
concepts that I'd like to be more widely spread. - Not sure you're
capable of understanding that and notice the blatant difference!)

And you should meanwhile know that meaningless home-brewed languages
are neither of general interest nor of mine; but you seem to have a
persisting mental hindrance to understand what is easy understandable
by others. - Just to be clear; I don't know that "my scheme" you're
talking about is because I'm not interested in your posts about your
personal tools.

(I also suggest to become a bit more honest about your "achievement"
with creating your tool unless it gets some minimum general relevance
beyond your micro-ecosystem. - Why don't you advertise and offer your
tools at any more appropriate place if you think they're so important,
innovative, or generally useful?!)

Janis

lol, i told keith's team are funny asses..it needs some funcy answer:

you say 'usefull', i tell "your mum is doin new school"

https://www.youtube.com/watch?v=cumbkA5dGDI

sorry becouse my bad english i am rather unable to catch some more
subtle things in this anglish so maybe it should be

you say 'usefull', i tell your mama is doin new school

maybe this would be more appropriate

(by crom.. i feel body pain again)
(fir)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

fir pisze:

Janis Papanagnou pisze:

bart <bc@freeuk.com> writes:

When you have to implement this stuff then you can't be sloppy.

You demonstrated you can be extremely sloppy in your thinking and
in your argumentation! That doesn't mean that you wouldn't be able
to "write programs" ("this stuff"), for sure. - Another example of
sloppy thinking and argumentation.

Perhaps you're just jealous

Your mindset is so primitive, naive, and erroneous; unprecedentedly
given your stubbornness. Your persistent habit of making guesses,
completely missing the point, topics, and characters, had regularly
been shown to be widely erroneous. - I see you can't just stop your
ineffective tries. It won't lead you anywhere.

that my scheme isn't available in your favourite language.

I have no "favourite language". (In a couple languages there's some
concepts that I'd like to be more widely spread. - Not sure you're
capable of understanding that and notice the blatant difference!)

And you should meanwhile know that meaningless home-brewed languages
are neither of general interest nor of mine; but you seem to have a
persisting mental hindrance to understand what is easy understandable
by others. - Just to be clear; I don't know that "my scheme" you're
talking about is because I'm not interested in your posts about your
personal tools.

(I also suggest to become a bit more honest about your "achievement"
with creating your tool unless it gets some minimum general relevance
beyond your micro-ecosystem. - Why don't you advertise and offer your
tools at any more appropriate place if you think they're so important,
innovative, or generally useful?!)

Janis

lol, i told keith's team are funny asses..it needs some funcy answer:

you say 'usefull', i tell "your mum is doin new school"

https://www.youtube.com/watch?v=cumbkA5dGDI

sorry becouse my bad english i am rather unable to catch some more
subtle things in this anglish so maybe it should be

you say 'usefull', i tell your mama is doin new school

maybe this would be more appropriate

(by crom.. i feel body pain again)
(fir)

this ilustrates this common topic:

if youre not holding any rules of behaviour you may and in a crowd of
annoying spammers like quite popular here..bot on oposite side
you got a society of fellows who have so called sticks up their asses
yet worse they oftan talk bulshit as stck up their as not guarantees
talkin sense

but those spamers also seem to have brain small as some seed
so the normality lies somewehere in between imo
(coz really this stick up the ass crowd is imo nonstandable spamers are
also nonstandable)

sadly usenet is not much large today it seems (which is very bad ofc)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

fir pisze:

fir pisze:

Janis Papanagnou pisze:

bart <bc@freeuk.com> writes:

When you have to implement this stuff then you can't be sloppy.

You demonstrated you can be extremely sloppy in your thinking and
in your argumentation! That doesn't mean that you wouldn't be able
to "write programs" ("this stuff"), for sure. - Another example of
sloppy thinking and argumentation.

Perhaps you're just jealous

Your mindset is so primitive, naive, and erroneous; unprecedentedly
given your stubbornness. Your persistent habit of making guesses,
completely missing the point, topics, and characters, had regularly
been shown to be widely erroneous. - I see you can't just stop your
ineffective tries. It won't lead you anywhere.

that my scheme isn't available in your favourite language.

I have no "favourite language". (In a couple languages there's some
concepts that I'd like to be more widely spread. - Not sure you're
capable of understanding that and notice the blatant difference!)

And you should meanwhile know that meaningless home-brewed languages
are neither of general interest nor of mine; but you seem to have a
persisting mental hindrance to understand what is easy understandable
by others. - Just to be clear; I don't know that "my scheme" you're
talking about is because I'm not interested in your posts about your
personal tools.

(I also suggest to become a bit more honest about your "achievement"
with creating your tool unless it gets some minimum general relevance
beyond your micro-ecosystem. - Why don't you advertise and offer your
tools at any more appropriate place if you think they're so important, >>>> innovative, or generally useful?!)

Janis

lol, i told keith's team are funny asses..it needs some funcy answer:

you say 'usefull', i tell "your mum is doin new school"

https://www.youtube.com/watch?v=cumbkA5dGDI

sorry becouse my bad english i am rather unable to catch some more
subtle things in this anglish so maybe it should be

you say 'usefull', i tell your mama is doin new school

maybe this would be more appropriate

(by crom.. i feel body pain again)
(fir)

this ilustrates this common topic:

if youre not holding any rules of behaviour you may and in a crowd of annoying spammers like quite popular here..bot on-a oposite side
you got a society of fellows who have so called sticks up their asses
yet worse they oftan talk bulshit as stck up their as not guarantees
talkin sense

but those spamers also seem to have brain small as some seed
so the normality lies somewehere in between imo
(coz really this stick up the ass crowd is imo nonstandable spamers are
also nonstandable)

sadly usenet is not much large today it seems (which is very bad ofc)

im so sad over a dead tehnologies i dont even know (az those old ones
weirdly often seem better thatthise modern)

if the raa would become internet i would try to revitalise usenet
encouraging to write here
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 12/09/2026 07:01, Janis Papanagnou wrote:

bart <bc@freeuk.com> writes:

When you have to implement this stuff then you can't be sloppy.

You demonstrated you can be extremely sloppy in your thinking and
in your argumentation! That doesn't mean that you wouldn't be able
to "write programs" ("this stuff"), for sure. - Another example of
sloppy thinking and argumentation.

Perhaps you're just jealous

Your mindset is so primitive, naive, and erroneous; unprecedentedly
given your stubbornness. Your persistent habit of making guesses,
completely missing the point, topics, and characters, had regularly
been shown to be widely erroneous. - I see you can't just stop your ineffective tries. It won't lead you anywhere.

that my scheme isn't available in your favourite language.

I have no "favourite language". (In a couple languages there's some
concepts that I'd like to be more widely spread. - Not sure you're
capable of understanding that and notice the blatant difference!)

And you should meanwhile know that meaningless home-brewed languages
are neither of general interest nor of mine; but you seem to have a persisting mental hindrance to understand what is easy understandable
by others. - Just to be clear; I don't know that "my scheme" you're
talking about is because I'm not interested in your posts about your
personal tools.

Then you are blinkered. You should be able to evaluate and appreciate
useful and innovate ideas by yourself, without relying on widespread
adoption to tell you if they are good or bad.

If, tomorrow, a major mainstream language introduced a module scheme
just like mine, would you still hate it and think it useless, or would
you suddenly change your mind?!

Obviously not, because you are bigoted.

(I also suggest to become a bit more honest about your "achievement"
with creating your tool unless it gets some minimum general relevance
beyond your micro-ecosystem. - Why don't you advertise and offer your
tools at any more appropriate place if you think they're so important, innovative, or generally useful?!)

I might have done that 35 years ago or more.

For example, at one time my small company produced business computers.
We designed everything about them (my job was taking care of the
motherboard). We did the PCB layout, manufactured the actual PCBs, and populated the PCBS by hand, all in the UK (my boss owned two other small companies that took care of that).

We even produced our own OS for it (via a 3rd associated company)!.

Today's landscape is utterly different. Can you imagine one company in
the UK producing dozens of computers per week compared with current mass-production in the far east that produces millions?

The same with software, and with languages - no one is interested in 70s
or 80s retro languages. And coding itself is being revolutionised.

So, yes, my 'stuff' is a small bastion of languages and tools with a particular philosophy - small, fast, simple, effortless, self-contained, minimal and elegant. It is a continuation of that 1980s ethos where we
did nearly everything in-house.

That does not mean you have to look down your nose at what I do.

If you look at fir's recent litany of complaints about C, wasn't it
remarkable that most of those were 'fixed' in my systems language!

Last year we had a discussion about Algol68 and specifically A68G, in comp.lang.misc. You were a proponent of that language and tool.

I made some complaints about them that you and others didn't like. In
the end I got fed and up signed off with this list of comparisons
between them and my two personal languages.

----------------------------------------------------------------------

(From comp.lang.misc, 'Removing influences from a language', posted
13-Nov-25 22:39 GMT) ----------------------------------------------------------------------

I have a systems language and a higher level dynamic one, that share the
same syntax.

So here are a number of those practical features, written with the
systems language in mind, but many apply to both. A few at the end apply
to the dynamic one only.

This is why an old-fashioned, stilted language like Algol68 to me is now
more of a curiosity; it's a toy.

Features not natively present in Algol68 (that I know of, but of course
I haven't read the full spec):

* Fully case-insensitive

* Module scheme

* Namespaces

* Scope-control attributes

* Whole-program compilation (while having multiple modules!)

* 'main' entry-point function that is automatically called

* Mostly semicolon-free syntax (newline terminates statements
unless they clearly continue onto the next line)

* Full FFI with full support for machine-specific types

* Full control of record layouts and alignment

* Full out-of-order definitions for all entities

* Textual code inclusion

* String/binary file inclusion (embed any text or binary file as data)

* Int is the main signed, numeric integer type, defaulting to 64 bits

* Word is a 64-bit type used for unsigned numbers, and bit-patterns
that may not be numeric (Haskell also has Int and Word types)

* Label pointers and computed goto

* Bit/Bitfield indexing ops for both l- and r-values

* Bit-fields within records

* CASE statement that sequentially checks a control expr against N
possibilies (not the same as A68's 'case')

* SWITCH statement that checks a control expr against N possibilies
in parallel

* SELECT statement that evaluates one of N possibilities according to an
index 1..N. This is most like A68's 'case; it only exists as compact
syntax

* Simple enumerations

* ENUMDATA defines a set of enumerations in parallel with corresponding
data arrays

* TABLEDATA defines parallel data arrays without any enums

* SWAP operator

* Chained comparisons: a = b = c; a <= b < c

* 'IN' operator: if a in b..c, or if a in [b, c, d]

* ++ and -- operators, including value-returning versions

* Pointer arithmetic

* Simple macros

* Character constants: value such as 'A' up to 'ABCDEFGH' occupy one
Word value

* Multiple assignments: (a, b, c) := (x, y, z)

* Multiple function return values: (a, b) := f(x)

* Experimental piping operator: x -> F -> G means G(F(x))

* Default function arguments

* Named keyword arguments

* For-loops that work over the values of a collection rather than an
integer range

* REPEAT-UNTIL

* Looping CASE and SWITCH: DOCASE and DOSWITCH

* Loop controls EXIT, REDO, NEXT can work with nested loops

* ELSE clause for FOR-loops (as in Python)

* Two special forms of DOSWITCH: DOSWITCHU uses multi-point dispatch
code (to work better with branch prediction), of use within bytecode
dispatch loops

* And DOSWITCHX; needs extra setup code but can be 5% faster

* Function tables which can be interrogated at runtime for function
names and addresses

* Built-in READ+READLN and PRINT+PRINTLN /statements/

* Type-punning conversions including of r-values

* Encapsulation: anything defined in a Record type can be accessed via
the namespace scheme

Following are dynamic language only:

* Arbitrary precision decimal floating point arithmetic

* Pascal-style bit-sets: ['A'..'Z', 'a'..'z']

* Bit-arrays (actually of u1/u2/u4 elements) and bit pointers

* Built-in hash-table arrays

* 'IN' operator where RHS is a collection

* Basic exceptions

* First-class types and operators

I haven't mentioned my tools or their performance. Let's just say the self-hosted systems compiler builds itself in 0.1 seconds, on the same
machine that A68G builds in 35 seconds, if fast-tracked. They're nippy.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

bart pisze:

* Mostly semicolon-free syntax (newline terminates statements
-a unless they clearly continue onto the next line)

make it also ,-free becouse most (if not strictly any) , is not
needed as space is a separtor ... i just like removed , and
turned :: into , (as it was fee and better lookin)

";" advanced to be a paragraph(block) end sign

also many () in function calls also not needed as i showed in previous examples


as for this " " "," ";" syntax i just described it is probably and of
the road here, cant do better/much beter robably (except maybe ; is not
best looking so this sign eventually can change but the schem is like
cleanest possible imo




--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

bart pisze:

* Mostly semicolon-free syntax (newline terminates statements
-a-a unless they clearly continue onto the next line)

make it also ,-free becouse most (if not strictly any) , is not
needed as space is a separtor ... i just like removed , and
turned :: into , (as it was fee and better lookin)

-a";" advanced to be a paragraph(block) end sign

also many () in function calls also not needed as i showed in previous examples

as for this " " "," ";" syntax i just described it is probably and of
the road here, cant do better/much beter robably (except maybe ; is not
best looking so this sign eventually can change but the schem is like cleanest possible imo

there is also an option of making blocks of blocks that would need
more signs - or repeating one etc


foo()
a b c, d e f, g h;
i j, k, l m n, o, p; ;

v w, x;
q, r s, t u; ;
;


of course ;; not lokin good but something better here

so this is the same as

foo()
{
{{ {a b c, d e f, g h}
{i j, k, l m n, o, p}}
{{v w, x}
{q, r s, t u} }
}


thus the logial lines in functions can be indexed foo[1][0][0] would be
v x (v(x) call)


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

fir pisze:

bart pisze:

* Mostly semicolon-free syntax (newline terminates statements
-a-a unless they clearly continue onto the next line)

make it also ,-free becouse most (if not strictly any) , is not
needed as space is a separtor ... i just like removed , and
turned :: into , (as it was fee and better lookin)

-a-a";" advanced to be a paragraph(block) end sign

also many () in function calls also not needed as i showed in previous
examples


as for this " " "," ";" syntax i just described it is probably and of
the road here, cant do better/much beter robably (except maybe ; is
not best looking so this sign eventually can change but the schem is
like cleanest possible imo

there is also an option of making blocks of blocks that would need
more signs - or repeating one etc

foo()
-a a b c, d e f, g h;
-a i j, k, l m n, o, p; ;

-a v w, x;
-a q, r s, t u;-a ;
;

of course ;; not lokin good but something better here

so this is the same as

foo()
{
-a{{ {a b c, d e f, g h}
-a {i j, k, l m n, o, p}}
-a {{v w, x}
-a {q, r s, t u} }
}

thus the logial lines in functions can be indexed foo[1][0][0] would be
v x (v(x) call)

the question is qhat with if-else and loops

if(a) {b c} else {d e}

btw if (as sorta is in c if(a) x; is replacement of if (a) {x;}
then more logical it would be id(a) x; <--> if(a) {x} the if (a) {x;}
has less sense


in case of ifs it sees it probably shuld be

{ if(a) {b c} else {d e} }

so one block is not divided here on 2 subblocks but there is also a 'rest'

also that can be a loop though im not sure to this both

in such case elements of normal c code probably also can be adressed

though c codes are mostly shallow-wide not much vertical as blocks
usually are mady by this if and for

void DeallocFont(BMFont* f)
{
if(!f) return;

for(int i = 0; i < 256; i++)
{
if(f->g[i].alpha)
{
free(f->g[i].alpha);
f->g[i].alpha = NULL;
}
}

free(f);

}


here DeallocFont.0 would be if(!f) return;

DeallocFont.0.0 would be return

(not sure as to "if(!f)" also index as subblock - maybe
then 0,0 would be "if(!f) " soe 0.0.1 would be !f









--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

bart pisze:

* Multiple function return values: (a, b) := f(x)

i asked ai which languages get tis in which year and it says
(note ai may be not fully reliable, but it may be treated as some date
whose are not know if fully reliable but worth maybe lookin at )

J-Ozyk Od kiedy mniej wi-Ocej Przyk+ead
CLU 1975 x, y := foo()
Perl 1987 ($x, $y) = foo()
Python 1991 x, y = foo()
Lua 1993 x, y = foo()
Ruby 1995 x, y = foo()
Go 2009/2010 x, y := foo()
Swift 2014 (x, y) = foo()
JavaScript 2015 (ES6) [x, y] = foo()
C# 2017 (C# 7) var (x, y) = foo()
Rust 2015 dla destructuring let; 2022 dla assignment let (x, y) = foo()


as i said back then i was starting lerning c afair 25 years ago
maybe even exactly, - it was i remember like in a week thet was after
WTC attack (so 25 years aggo exactly) - maybe 25 years form now

maybe more on this story - in Toru+a (whwre i was studying physics
back then ) there was a chep books bookstore and i bought some old cheap
book on "turbo c 2.0" (by bielinki?) i dont remember but has it still on
my bookshelf - i literally was traveling in bus from toru+a to my city
when the radio in that bus give the news of WTC co its easy to memorize

i alos remember i was not studying this book in toru+a (i got no pc
on my last place i rented i turu+a (before we , me and my friend piotr,
got some but we anly played adom on linuc there)

so its sure i not learned it before wtc and i remember i was learning it
quite afterwards

this book was totally obsolete in 2001 but i find it very interesting as
it covered C which before i got no idea on (only nknewed asembler,
creepy basics and turbo pascel 7.0 or something)

so when i was learnig c in this late 2001 thru 2002 and 2003 it was my begining (fortunate to remember in some way 2001 first year of knowing c
and so on)

so as to this above list I presently FOR MYSELF discovered that s should
have it (returning 2 values ) was as i remember in 2003 (and i remember
people back then didnt considered it as obvious)

its maybe suprising perl and python had it so early but its also
suprising javascript had it so late



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 12/09/2026 13:37, fir wrote:

bart pisze:

* Mostly semicolon-free syntax (newline terminates statements
-a-a unless they clearly continue onto the next line)

make it also ,-free becouse most (if not strictly any) , is not
needed as space is a separtor ...

Removing intra-line commas is not really practical. Even if technically
some code can be parsed without it, humans have difficulty.

Some structure is needed. Take this parameter list with commas:

(a b c, d e)

'a' and 'd' are types; b, c, e are parameter names. Without the commas
it would just be:

(a b c d e)

(In my language, user-defined types are not resolved into types until
after parsing. The parser relies on structure to determine which names
are types.)

While a function call like F(a + b, -1, sin c) ('sin' is an operator),
would become:

F(a + b -1 sin c)

It all runs together, and here there is also an ambiguity between "b,
-1" and "b - 1".

However, I /have/ looked at interline commas: this is where you have a
long list of data initialisers, one per line. There it would be less of
a problem as newline acts as separator.

But I still found it troublesome as the parser needs to keep track of
whether it's a semicolon- or comma-separated context.

(This is partly implemented, but as I can't remember in which language
or context, I find it easier to just write the commas.)

i just like removed , and
turned :: into , (as it was fee and better lookin)

Really? So C's 'std::cout' becomes 'std,cout'? That looks totally wrong.

also many () in function calls also not needed as i showed in previous examples

Minimalist just doesn't work, sorry. It might in a language like Haskell
which has special rules (and features like currying), but that is not
the kind of language I want to write.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

bart pisze:

On 12/09/2026 13:37, fir wrote:

bart pisze:

* Mostly semicolon-free syntax (newline terminates statements
-a-a unless they clearly continue onto the next line)

make it also ,-free becouse most (if not strictly any) , is not
needed as space is a separtor ...

Removing intra-line commas is not really practical. Even if technically
some code can be parsed without it, humans have difficulty.

Some structure is needed. Take this parameter list with commas:

-a-a (a b c, d e)

'a' and 'd' are types; b, c, e are parameter names. Without the commas
it would just be:

-a-a (a b c d e)

its becouse you give examples with not know what it mean if it would be

int b c float e its more clear (fully clear imo

though im was not saying on this case - as i said , works in a place of
; (its a "logical line" seperator so it work like ";" in c where the c
usages of "," are ust removed

i mean , removed
; replaced by ,

(In my language, user-defined types are not resolved into types until
after parsing. The parser relies on structure to determine which names
are types.)

While a function call like F(a + b, -1, sin c) ('sin' is an operator),
would become:

-a-a F(a + b -1 sin c)

F a+b -1 sin c

is clear imo 9though better is to use separate - sign for neg values
not subtraction)

in above i mean probably its good to take you baf write

foo arg arg arg foo arg arg

i mean "only one function acll in logical line so you would need

foo arg arg arg, foo arg arg

to satisfy this rule so if

you see this

F a+b -1 sin c

you know its one function call thus sin c is argument

It all runs together, and here there is also an ambiguity between "b,
-1" and "b - 1".

However, I /have/ looked at interline commas: this is where you have a
long list of data initialisers, one per line. There it would be less of
a problem as newline acts as separator.

But I still found it troublesome as the parser needs to keep track of whether it's a semicolon- or comma-separated context.

(This is partly implemented, but as I can't remember in which language
or context, I find it easier to just write the commas.)

i just like removed , and
turned :: into , (as it was fee and better lookin)

sorry i meant ; not :: (shift didnt worked )

Really? So C's 'std::cout' becomes 'std,cout'? That looks totally wrong.

also many () in function calls also not needed as i showed in previous
examples

Minimalist just doesn't work, sorry. It might in a language like Haskell which has special rules (and features like currying), but that is not
the kind of language I want to write.

there is alos to use ' optionally i mean some may use them in ()

like

print a b c

may use

(print a b c) //optionally

or

print (a b c) //optionally

or
print (a,b,c) //optionally

aventually

thet would probbaly not collide with general "bare naked" {s n j, s d f,
s d}
syntax


im not sure if allowing print(a b c) could not cause slight collisions
if so some slight changes there would need be here but in worst case
it would be disalowed but probably i would prefer in worst case
doing meaningful space it is not eventually allowing

print (a b c)

in that case (at worst ) but maybe its not needed, i would need to check it




--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

bart wrote:

On 12/09/2026 07:01, Janis Papanagnou wrote:

bart <bc@freeuk.com> writes:

When you have to implement this stuff then you can't be sloppy.

You demonstrated you can be extremely sloppy in your thinking and
in your argumentation! That doesn't mean that you wouldn't be able
to "write programs" ("this stuff"), for sure. - Another example of
sloppy thinking and argumentation.

Perhaps you're just jealous

Your mindset is so primitive, naive, and erroneous; unprecedentedly
given your stubbornness. Your persistent habit of making guesses,
completely missing the point, topics, and characters, had regularly
been shown to be widely erroneous. - I see you can't just stop your
ineffective tries. It won't lead you anywhere.

that my scheme isn't available in your favourite language.

I have no "favourite language". (In a couple languages there's some
concepts that I'd like to be more widely spread. - Not sure you're
capable of understanding that and notice the blatant difference!)

And you should meanwhile know that meaningless home-brewed languages
are neither of general interest nor of mine; but you seem to have a
persisting mental hindrance to understand what is easy understandable
by others. - Just to be clear; I don't know that "my scheme" you're
talking about is because I'm not interested in your posts about your
personal tools.

Then you are blinkered. You should be able to evaluate and appreciate
useful and innovate ideas by yourself, without relying on widespread adoption to tell you if they are good or bad.

Oh no, Janis is a punch card kid. He has to conform or else the
university will dock his punch card time.

If, tomorrow, a major mainstream language introduced a module scheme
just like mine, would you still hate it and think it useless, or would
you suddenly change your mind?!

Obviously not, because you are bigoted.

(I also suggest to become a bit more honest about your "achievement"
with creating your tool unless it gets some minimum general relevance
beyond your micro-ecosystem. - Why don't you advertise and offer your
tools at any more appropriate place if you think they're so important,
innovative, or generally useful?!)

I might have done that 35 years ago or more.

For example, at one time my small company produced business computers.
We designed everything about them (my job was taking care of the motherboard). We did the PCB layout, manufactured the actual PCBs, and populated the PCBS by hand, all in the UK (my boss owned two other small companies that took care of that).

We even produced our own OS for it (via a 3rd associated company)!.

Today's landscape is utterly different. Can you imagine one company in
the UK producing dozens of computers per week compared with current mass-production in the far east that produces millions?

Not to mention, Janis is showing his small-mindedness (perhaps a total
lack of MBA) that lower prices create greater demand. In Janis' world, increasing the prices at your company leads to greater lurve and
happiness with no repercussions whatsoever. It's all about price for
Janis, not price * units sold. He had to spend all his time at
university waiting for the punch card system and found no time for
economics electives.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

bart pisze:

On 12/09/2026 13:37, fir wrote:

bart pisze:

* Mostly semicolon-free syntax (newline terminates statements
-a-a unless they clearly continue onto the next line)

make it also ,-free becouse most (if not strictly any) , is not
needed as space is a separtor ...

Removing intra-line commas is not really practical. Even if
technically some code can be parsed without it, humans have difficulty.

Some structure is needed. Take this parameter list with commas:

-a-a-a (a b c, d e)

'a' and 'd' are types; b, c, e are parameter names. Without the commas
it would just be:

-a-a-a (a b c d e)

its becouse you give examples with not know what it mean if it would be

int b c float e its more clear (fully clear imo

though im was not saying-a on this case - as i said , works in a place of
; (its a "logical line" seperator so it work like ";" in c where the c usages of "," are ust removed

i mean , removed
; replaced by ,

(In my language, user-defined types are not resolved into types until
after parsing. The parser relies on structure to determine which names
are types.)

While a function call like F(a + b, -1, sin c) ('sin' is an operator),
would become:

-a-a-a F(a + b -1 sin c)

F a+b -1 sin c

is clear imo-a 9though better is to use separate - sign for neg values
not subtraction)

in above i mean probably its good to take you baf write

foo arg arg arg foo arg arg

i mean "only one function acll in logical line so you would need

foo arg arg arg, foo arg arg

to satisfy this rule so if

you see this

F a+b -1 sin c

you know its one function call thus sin c is argument

It all runs together, and here there is also an ambiguity between "b,
-1" and "b - 1".

However, I /have/ looked at interline commas: this is where you have a
long list of data initialisers, one per line. There it would be less
of a problem as newline acts as separator.

But I still found it troublesome as the parser needs to keep track of
whether it's a semicolon- or comma-separated context.

(This is partly implemented, but as I can't remember in which language
or context, I find it easier to just write the commas.)

i just like removed , and
turned :: into , (as it was fee and better lookin)

sorry i meant ; not :: (shift didnt worked )

Really? So C's 'std::cout' becomes 'std,cout'? That looks totally wrong.

also many () in function calls also not needed as i showed in
previous examples

Minimalist just doesn't work, sorry. It might in a language like
Haskell which has special rules (and features like currying), but that
is not the kind of language I want to write.

there is alos to use ' optionally i mean some may use them in ()

like

print a b c

may use

(print a b c) //optionally

or

print (a b c)-a //optionally

or
print (a,b,c) //optionally

aventually

thet would probbaly not collide with general "bare naked" {s n j, s d f,
s d}
syntax

im not sure if allowing print(a b c) could not cause slight collisions
if so some slight changes there would need be here but in worst case
it would be disalowed but probably i would prefer in worst case
doing meaningful space it is not eventually allowing

print (a b c)

in that case (at worst ) but maybe its not needed, i would need to
check it

you probbaly mean such cases

foo a b c (d f) e

note if c is a function and it takes 2 arguments its
not clear if its

foo a b c (d f) e

or
foo a b c((d f) e )

if d e are values then it probably ishould be first but if
d is a function it probably should be the second


generally i dont see a clear problems here, somebody would need to give
me some problematic example coz i dont see any (not seeing ofr sure i inspected all bot seemd to ma like it iis ok or close to okay)










--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

F a+b -1 sin c

this second minus is in fact needed so normally

this above is f a+b-2 sin(c)

unicode as usually instead of having something cruciallu usful provides
soem weirdos here

this above with -2 not subtraction would be f a+b -u2 sin(c)

but meybe somethin could be find
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

fir pisze:

F a+b -1 sin c

this second minus is in fact needed so normally

this above is f a+b-2 sin(c)

unicode as usually instead of having something cruciallu usful provides
soem weirdos here

this above with -2 not subtraction would be-a f a+b -u2 sin(c)

but meybe somethin could be find

unicode has such options

2-2*N|u2
2-2*-u2
2-2*rei2
2-2*rU+2

no one looks much good in seamonkey reader i use , this third looks
standable though but thats depend on font i guess
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

fir pisze:

F a+b -1 sin c

this second minus is in fact needed so normally

this above is f a+b-2 sin(c)

unicode as usually instead of having something cruciallu usful provides
soem weirdos here

this above with -2 not subtraction would be-a f a+b -u2 sin(c)

but meybe somethin could be find

note (1) imo you should not look if its easy for human to resolve it
only if compiler can resolve it

human can add some spaces and () "eventually" so what the problem

more over trained people would understand it as they understand present
c which is also quite cryptic if you dont understand it


and note (2) id compiler is to understod given formula it had
definitions so he knows if given ab c d e if function variable
type or something else as it need be defined (if its not defined he recgognizes it too - as undefined symbol

mor eto say thse comples syntaxes are in fact rare imo, most common is
pure stuf like

print "abjhabj", drawline x y p q 0x777

so most impoortant it has this especially clean (as i got)

second more common is probbaly

setpixel x*b+c y*g+h rand_color 0x889977 0xaabbcc

imo its also clean if you know what setpixel
and rand_color take

set pixel takes 3 and randcolor2 so its not any ambiguity for compiler

and human may add () in many places here

setpixel(x*b+c y*g+ (rand_color(0x889977 0xaabbcc))

though this traditional form im not sure

imo its probably clearer to write

setpixel x*b+c y*g+h (rand_color 0x889977 0xaabbc)

than traditional

setpixel (x*b+c y*g+h rand_color(0x889977 0xaabbc))

this is becouse (f a a) is one thing where f(a a) is one things and
(a a) is liek lESS one thing, but probbaly this form can be allowed for tradition (though im not sure as it seems bad)


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 12/09/2026 14:44, fir wrote:

bart pisze:

On 12/09/2026 13:37, fir wrote:

bart pisze:

* Mostly semicolon-free syntax (newline terminates statements
-a-a unless they clearly continue onto the next line)

make it also ,-free becouse most (if not strictly any) , is not
needed as space is a separtor ...

Removing intra-line commas is not really practical. Even if
technically some code can be parsed without it, humans have difficulty.

Some structure is needed. Take this parameter list with commas:

-a-a-a (a b c, d e)

'a' and 'd' are types; b, c, e are parameter names. Without the commas
it would just be:

-a-a-a (a b c d e)

its becouse you give examples with not know what it mean if it would be

int b c float e its more clear (fully clear imo

Sure, but what happens when someone /wants/ to have user-define types?
So in general it is ambiguous.

In C you can also have a parameter list which has only types, no
parameter names. If that is still a feature, then:

(a, b, c, d);

can be assumed (by the reader) to be all types. But this:

(a b c d)

is more ambiguous; how many parameters are there: is it 4 (abcd are all types); 3 (a is a type, bcd are names), or 2 (ac are types, bd are
names)? Other combinations may be possible.

though im was not saying-a on this case - as i said , works in a place
of ; (its a "logical line" seperator so it work like ";" in c where the
c usages of "," are ust removed

i mean , removed
; replaced by ,

(In my language, user-defined types are not resolved into types until
after parsing. The parser relies on structure to determine which names
are types.)

While a function call like F(a + b, -1, sin c) ('sin' is an operator),
would become:

-a-a-a F(a + b -1 sin c)

F a+b -1 sin c

Significant white space now? Come pm, what sort of crazy language is
this going to be?!

But since this is a fantasy language anyway that is never going to be implemented, then sure, leave out whatever you want. But it will be a
terrible language to work with.

is clear imo-a 9though better is to use separate - sign for neg values
not subtraction)

in above i mean probably its good to take you baf write

foo arg arg arg foo arg arg

Users can make their own identifiers so it could be this:

arg foo foo foo arg foo foo

In general a compiler will see:

a b c d e f g

Seven consecutive identifiers.

i mean "only one function acll in logical line so you would need

foo arg arg arg, foo arg arg

to satisfy this rule so if

you see this

F a+b -1 sin c

you know its one function call thus sin c is argument

I'm sorry, but this stuff needs to be COMPLETELY AMBIGUOUS. Someone
should INSTANTLY be able to know what is intended, rather than waste
time trying to infer it. This is supposed to be the source code of some program, not a puzzle!

You can make it unambiguous by using commas and parentheses, and
EVERYONE will understand what is being expressed.

What exactly are trying to achieve here: saving a few seconds of typing
but then spending ten times as long trying to understand the code, or
1000 times as long trying to debug all the subtle bugs that have crept in?

I know this is a fantasy, but aren't you interested in practicalities at
all?

i just like removed , and
turned :: into , (as it was fee and better lookin)

sorry i meant ; not :: (shift didnt worked )

std;cout isn't much better! Both "::" and "." are commonly used for this purpose.

im not sure if allowing print(a b c) could not cause slight collisions
if so some slight changes there would need be here but in worst case
it would be disalowed but probably i would prefer in worst case
doing meaningful space it is not eventually allowing

print (a b c)

How sure are you that two user identifiers can never be adjacent?

What about operators that can be both unary and binary? A further example:

a b * c * d

Is this a(b * c * d), or a(b, *c * d), or (b, *c, *d) etc?

Please don't say that you have to work it out by hunting for the
definitions; as I said this should not be a puzzle.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

bart wrote:

What exactly are trying to achieve here: saving a few seconds of typing
but then spending ten times as long trying to understand the code, or
1000 times as long trying to debug all the subtle bugs that have crept in?

That's the spirit! fir is trying to achieve a nonsensical language, just
like your line here (which I guess is missing the word 'you'). Playing
along, I see you are typing nonsense to placate him!

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

bart pisze:

On 12/09/2026 14:44, fir wrote:

bart pisze:

On 12/09/2026 13:37, fir wrote:

bart pisze:

* Mostly semicolon-free syntax (newline terminates statements
-a-a unless they clearly continue onto the next line)

make it also ,-free becouse most (if not strictly any) , is not
needed as space is a separtor ...

Removing intra-line commas is not really practical. Even if
technically some code can be parsed without it, humans have difficulty.

Some structure is needed. Take this parameter list with commas:

-a-a-a (a b c, d e)

'a' and 'd' are types; b, c, e are parameter names. Without the
commas it would just be:

-a-a-a (a b c d e)

its becouse you give examples with not know what it mean if it would be

int b c float e its more clear (fully clear imo

Sure, but what happens when someone /wants/ to have user-define types?
So in general it is ambiguous.

In C you can also have a parameter list which has only types, no
parameter names. If that is still a feature, then:

-a (a, b, c, d);

can be assumed (by the reader) to be all types. But this:

-a (a b c d)

is more ambiguous; how many parameters are there: is it 4 (abcd are all types); 3 (a is a type, bcd are names), or 2 (ac are types, bd are
names)? Other combinations may be possible.

though im was not saying-a on this case - as i said , works in a place
of ; (its a "logical line" seperator so it work like ";" in c where
the c usages of "," are ust removed

i mean , removed
; replaced by ,

(In my language, user-defined types are not resolved into types until
after parsing. The parser relies on structure to determine which
names are types.)

While a function call like F(a + b, -1, sin c) ('sin' is an
operator), would become:

-a-a-a F(a + b -1 sin c)

F a+b -1 sin c

Significant white space now? Come pm, what sort of crazy language is
this going to be?!

But since this is a fantasy language anyway that is never going to be implemented, then sure, leave out whatever you want. But it will be a terrible language to work with.

is clear imo-a 9though better is to use separate - sign for neg values
not subtraction)

in above i mean probably its good to take you baf write

foo arg arg arg foo arg arg

Users can make their own identifiers so it could be this:

-a arg foo foo foo arg foo foo

In general a compiler will see:

-a a b c d e f g

this is your very serious problem here that you assume 'unlearned' human should understand it, compiler must understand it... Im not sure hovever
how to explain it to you that this your dogmate is wrong

you know what you talk also fits to c you also neeeded to learn what
given construction mean here its just the same jus construction have
less ,,, () stuf




kompiler knows what given symbols are..if it make sense it will compile
it if not he will not if you make some complex stuff with a net of
functions like

f1 a f2 f3 f4 a a f5 f6

compiler know which function takes how many arguments
and will resolve it to fit

im not sure if there is any disimbiguity here or none


if you know one tell me and i will tell a rule to resolve it
(as it may be resolved by some rule

if yu worry on humen radibilit y you just add parentheses and you
end up at worst in your initial form..but there is simply a form to
do it much cleaner and many use will use the clean lightweight 'naked'
form (no gothic clothes)

Seven consecutive identifiers.

i mean "only one function acll in logical line so you would need

foo arg arg arg, foo arg arg

to satisfy this rule so if

you see this

F a+b -1 sin c

you know its one function call thus sin c is argument

I'm sorry, but this stuff needs to be COMPLETELY AMBIGUOUS. Someone
should INSTANTLY be able to know what is intended, rather than waste
time trying to infer it. This is supposed to be the source code of some program, not a puzzle!

it is totally ambigious , one confusion is only related to the problem
that -2 uses the same sign as 4-2 (this is in fact nonstandable that
mean you need give unicode sign (and in worse case if comeone couldnt
probbaly something like this meaningful space here but that would be
bad ofc in that case - though generally spaces are meningfull its not
that you can skipp all spaces in c... in fact in my version they are
more meaningfull than in c becouse you cant delete much more of them but
this kind of meaningfulnes as 4-2 against 4 -2 is obviously wrong
(but some other better probably may exist)

when i see this its totally clear to me


F a+b -1 sin c

F tahes 2 args a+b-1 and sin c its only badly written like

F (a +b -1 , sin( c ) )

you may also badly write

You can make it unambiguous by using commas and parentheses, and
EVERYONE will understand what is being expressed.

What exactly are trying to achieve here: saving a few seconds of typing
but then spending ten times as long trying to understand the code, or
1000 times as long trying to debug all the subtle bugs that have crept in?

imo it is both faster to read and type arso cleaner

I know this is a fantasy, but aren't you interested in practicalities at all?

its not a fantasy language this is just scientific outcome on possible language syntax so it so much fantasy as 2+2=4


its not a fantasy its a RESULT

(such things name is RESULTS (rezultaty in polish), outcome

i just like removed , and
turned :: into , (as it was fee and better lookin)

sorry i meant ; not :: (shift didnt worked )

std;cout isn't much better! Both "::" and "." are commonly used for this purpose.

im not sure if allowing print(a b c) could not cause slight collisions
if so some slight changes there would need be here but in worst case
it would be disalowed but probably i would prefer in worst case
doing meaningful space it is not eventually allowing

print (a b c)

How sure are you that two user identifiers can never be adjacent?

What about operators that can be both unary and binary? A further example:

-a a b * c * d

Is this a(b * c * d), or a(b, *c * d), or (b, *c, *d) etc?

Please don't say that you have to work it out by hunting for the definitions; as I said this should not be a puzzle.

no worry , definitions wouldnt help here

this above is obviously non possible you cant have unary and binary
here (as far as it seems, i may be maybe wrong)

a*b must be binary if *b would be unary then it mean you have

a *b so its ambiguity , so there some additional rule would need to be
used at least

rule can be

a*b // is binary
a(*b) //is unary
(a*)b //is unary

this touches some problem becouse it blocks a(b) syntax which eventually
could be usefull, but it eventually may be seen not much usefull
as i see () more like separators not 'calling' operator
(it only be blocked for those types of ab though not necessary for
fiunction calls

there is also option to use this space as a seperator ..this kind of mmeaningfull spaces i use here all time for example in a b c d
apaces are meaningfull coz its not ab c d

so a *b wouldnt be considered good idea but a (*b) being different than
a(*b) may be (but VERY eventually)





--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

bart pisze:

Sure, but what happens when someone /wants/ to have user-define types?
So in general it is ambiguous.

In C you can also have a parameter list which has only types, no
parameter names. If that is still a feature, then:

-a (a, b, c, d);

can be assumed (by the reader) to be all types. But this:

-a (a b c d)

is more ambiguous; how many parameters are there: is it 4 (abcd are all types); 3 (a is a type, bcd are names), or 2 (ac are types, bd are
names)? Other combinations may be possible.

this one i dont understand whats difference id someone uses like
structure nameinstead of int?

no difference

and if ou see such thing as int int a b foo float
do i ask you how many type names are there? how many wariables and how
many function names?

note in code if it is not obfuscated names are meaningfull, type names
are not popular ther repeat and you know them generally function names
are usualy verbs (i write is mostly in big letter, variables i
personally always write low leter)

some functions i write low letter but those very qshort very quick usage
one like sin strcmp print - only few things like that

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

bart pisze:

Sure, but what happens when someone /wants/ to have user-define types?
So in general it is ambiguous.

In C you can also have a parameter list which has only types, no
parameter names. If that is still a feature, then:

-a-a (a, b, c, d);

can be assumed (by the reader) to be all types. But this:

-a-a (a b c d)

is more ambiguous; how many parameters are there: is it 4 (abcd are
all types); 3 (a is a type, bcd are names), or 2 (ac are types, bd are
names)? Other combinations may be possible.

this one i dont understand whats difference id someone uses like
structure nameinstead of int?

no difference

and if ou see such thing as int int a b foo float
do i ask you how many type names are there? how many wariables and how
many function names?

note in code if it is not obfuscated names are meaningfull, type names
are not popular ther repeat and you know them generally function names
are usualy verbs (i write is mostly in big letter, variables i
personally always write low leter)

some functions i write low letter but those very qshort very quick usage
one like sin strcmp print - only few things like that

obviously your not obliged to understand that (i mean this new naked/no
gothic clothes) syntax

its maybe better people dont understand that it maybe mnimalises chanse someone would take that valueable syntax results and implement it and
not adress (credt) me an propar author of this stuff

its not that those results are not to take, they may be taken but
thecredits should be done just to make historical acuracy of some
solutions not spreading lies (and filling history with lies (yawn) i
think its understood

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 12/09/2026 18:23, fir wrote:

bart pisze:

In general a compiler will see:

-a-a a b c d e f g

this is your very serious problem here that you assume 'unlearned' human should understand it, compiler must understand it...

This is the problem: a compiler might not understand it.

To do so, first requires that those symbols have been previously
defined, and here, that they have also been resolved /while parsing/.

This is the case for C as it is now. But remember you were annoyed at
having to declare things in advance? So it might be that 'a' is a
function that is defined later on.

In that case, it won't know how to parse this properly. It will need to
build a tentative AST (perhaps a concrete syntax tree or 'CST'), and
later transform into a proper AST.

But that still leaves the problem of any reader of the code being
bamboozled.

It might worth remembering that a HLL is supposed to be easier to write
and read than assembly or machine code. Having this extra burden for
virtually no benefit is pointless.

you know what you talk also fits to c you also neeeded to learn what
given construction mean here its just the same jus construction have
less ,,, () stuf

Well, we don't know the rest of your language. I mentioned one point above.

C itself still has structure: you will never see 7 user identifiers
together (unless someone goes overboard with macros, and that would be
very poor too).

kompiler knows what given symbols are..if it make sense it will compile
it if not he will not if you make some complex stuff with a net of
functions like

f1 a f2 f3 f4 a a f5 f6

compiler know which function takes how many arguments
and will resolve it to fit

OK, a compiler might be able to do so if:

* There are no variadic functions

* The languages doesn't have default argument values (BTW this feature
would be a million times more useful than being able to leave out all punctuation)

* The function doesn't use an unspecified parameter list (this was a
feature of C but C23 may have deprecated that)

* You sort out the clashes between unary and binary operators.

* All names have either been previously defined, or whole extras has
been done for this purpose.

But that is not the point: a human reader does not want that extra burden.

im not sure if there is any disimbiguity here or none

if you know one tell me and i will tell a rule to resolve it
(as it may be resolved by some rule

if yu worry on humen radibilit y you just add parentheses and you
end up at worst in your initial form

It's not that simple; if you see:

a ( ... )

does that '(' mean the whole argument list is contained, or just the
first argument of several? How much lookahead is needed to make it work?

..but there is simply a form to

do it much cleaner and many use will use the clean lightweight 'naked'
form (no gothic clothes)

when i see this its totally clear to me

OK, here is a fragment of code by itself:

a b c d

Tell me what it means. You don't have access to the rest of the program,
or you haven't got time to hunt for the definitions in 100,000 lines of
code spread across 28 headers in 12 folders.

Now here is the same fragment but with those 'useless' commas and
parentheses:

a(b(c, d))

Does that help?

Yes, there might technically be redundancy, but that is a useful feature
in a programming language: it can catch mistakes.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

no worry , definitions wouldnt help here

this above is obviously non possible-a you cant have unary and binary
here (as far as it seems, i may be maybe wrong)

a*b must be binary if *b would be unary then it mean you have

a *b so its ambiguity , so there some additional rule would need to be
used at least

rule can be

a*b-a // is binary
a(*b) //is unary
(a*)b //is unary

this touches some problem becouse it blocks a(b) syntax which eventually could be usefull, but it eventually may be seen not much usefull
as i see () more like separators not-a 'calling' operator
(it only be blocked for those types of ab though not necessary for
fiunction calls

there is also option to use this space as a seperator ..this kind of mmeaningfull spaces i use here all time for example in a b c d
apaces are meaningfull coz its not ab c d

so a *b wouldnt be considered good idea but a (*b) being different than a(*b) may be (but VERY eventually)

overally the question if to allow a(b) as a syntax is by chance good
question

it is mostly eventually needed from traditional reasons

f(a) [4 chars] is also maybe shorter than (f a)[5 chars] but longer than
f a [3 chars]
some coud say fthat f(a)f(a)f(a)f(a) wins over (f a)(f a)(f a) and
equals with f a f a f a f a f a, hard to say at this moment


f(a) probabably could be allowed but if so probably tha lack of space
would be meaningfull at least for some types

i cant say yet for sure in this case.. problem is imo

f(a) is in fact more misleading than helpfull

some really do like

print("ass " foo(x y) sin(x))




over more logical

print "ass" (foo x y)(sin x)



over a cleaner


print "ass" foo x y sin x


esp as free spaces may be added for clarity

print "ass" foo x y sin x

there ere many unicode eventuals separators for optional usage
for someone who need it in some cases but not for general usage imo but
an option


not this above but something could ba taken but
1) FOR OPTIONAL USAGE ONLY
2) NOT , MUST BE SOMETHING OTHER


for example those circles (bullets) i generally find more suitable for denoting definitions

rui foo
x = 28
rui bar
print "ataa"
rui zoo { sin x}

some liek python keyword def but shorter

raa ya!


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

bart pisze:>

a(b(c, d))

Does that help?

not much honestly - if youre so much in hole you can find
definitions..as you say you are

two terrible mistakes you do

1) you somewhat assume that definitions are not pesent - all definitions
are present - if definitions are not present it would not compile


2) you talk about this human reader its not a problem

you may add those parenthesis optionally... and if someone not added it
blame him

though as i said i would add the () different way

not a(b(c, d))

but

a (b c d)



you anyway should use meaningdull names in this examples becouse names
carry an information
and with this examples you compare obfuscated code context - in which by chance my form also wins (which is fortunate)

im not saying this is no more cryptic i just say its not cryptic if you
know what it is and know the rules

this form is simpler a(b(c, d))
than mine a b c d becouse in mine form this a b c d may be just more
things than in this a(b(c, d))


in your form a can be a variable or type b also c cant be a function d
cant be a function

its very bad becouse in my form it can



(note i not yet call about all thos syntaxes as i mosly only chosen
the function call form (also nested) and simple expresions like a=b+3

eben for such simple expresions ike

int a b c
or int a b c float e d f

alos not fully resolved finction headers

im not yet sure so some things are potentially open, yet

BUT IM RATHER COMPLETELY SURE

that this form

DrawLine x y p q color

for basic function call IS TOO GOD TO NOT TAKE IT -

co this is FIXED..its offical, as someone could say

you cant just not take such good things
(saying you as a mode of speach, i mean someone, its too good to not
take it)












--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

a (b c d)

this btw ilustrates some problem

a (b c d)

probably must be allowed here but you CANT ASSUME

that a (b c d) is function cal generally

YOU MAY ASSUME in there newline after that but if there is oor example x
after that

a (b c d) x


this part a (b c d) dont mean its function call -
if a takes one argument its function call but if two

a (b c d) x

is function call

so not always a ( b c d) is function call

could probably enforce that

a(b c d)


may be function call but im not sure if its good idea


i dont see a problem with this crazy helps to reader like he would have
no brain, btter use meaningfull names to know what is what


combination of 4 not meaningful names in programing is not usual i would say




--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

combination of 4 not meaningful names in programing is not usual i would
say

i think i need to break this conversation as for at least till monday
(coz i get a bit weary)..could eventuall add something but not
necessary, but longer discusion of this type at least after some break
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 12/09/2026 19:35, fir wrote:

bart pisze:>

-a-a-a a(b(c, d))

Does that help?

not much honestly - if youre so much in hole you can find
definitions..as you say you are

two terrible mistakes you do

1) you somewhat assume that definitions are not pesent - all definitions
are present - if definitions are not present it would not compile

2) you talk about this human reader its not a problem

you may add those parenthesis optionally... and if someone not added it blame him

though as i said i would add the () different way

not-a-a a(b(c, d))

but

-a a (b c d)

you anyway should use meaningdull names in this examples becouse names
carry an information

You want to design a language that /depends/ on the user devising
suitable names in order to deduce the /shape/ of the code? That is the
whole point of using a structured HLL in the first place!

Try this experiment: take a C source file and eliminate all ()s and
commas. Replace with a space if necessary to separate alphanumeric tokens.

Compare with the original and see which one is easier to work with.

(With C, missing () will give problems with macro definitions and casts,
among other things.)

Note that the code will still have braces. I suggest a better aim is to eliminate most braces. The should be no need to ever see '} else {'
instead of just 'else'.

In fact, if C is the start point, there is a huge amount that can be
done to end up with a cleaner language while not doing away with useful redundancy.

This is a C program:

#include <stdio.h>
#include <math.h>

int main() {
for (int i = 1; i <= 10; ++i) {
printf("%d %f\n", i, sqrt(i));
puts("----------");
}
}

A little contrived, but no matter because the same contrivance is here
in my systems language:

proc main =
for i to 10 do
println i, sqrt i
println "----------"
end
end

The C has 53 tokens (58 if you include all that gubbins inside the first string).

My version has only 17 tokens, nearly 70% fewer. And yet it still uses
the parentheses and commas that you're trying to eliminate (not many in
this example, but that is part of my point).

Of C's 53/58 tokens, 16 are parentheses, colons and semicolons. Removing
those would still leave 37/42 tokens. If you also disregard those
'#includes', a one-time cost, it would still be 23/27! (And would result
in ambiguous code unless you add lots of new rules.)

So I think you're going about this the wrong way: getting rid of
/useful/ punctuation symbols while still keeping the useless ones,
resulting in a more restricted language with new rules.

DrawLine x y p q color

for basic function call IS TOO GOD TO NOT TAKE IT -

This will break as soon as you try something more complicated.

If you want that, then try a PostScript-style stack language:

x y p q colour DrawLine

Here, parentheses and commas are not needed.

The problem is you don't want to write 10s of 1000s of lines in this
style; you want a conventional syntax which is easier to follow.

BTW here is a draw-line routine in my scripting language:

proc gxline(w, x, y, ?x2, ?y2) ...

It takes either one point or two. It is these optional args that would
make it hard to figure out a call like this:

gxline w a b c d

Is this gxline(w, a, b, c, d), or is it gxline(w, a, b(c, d))? In this
dynamic language, b might be a variable containing a function reference.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

bart wrote:

BTW here is a draw-line routine in my scripting language:

-a proc gxline(w, x, y, ?x2, ?y2) ...

It takes either one point or two. It is these optional args that would
make it hard to figure out a call like this:

-a-a gxline w a b c d

Is this gxline(w, a, b, c, d), or is it gxline(w, a, b(c, d))? In this dynamic language, b might be a variable containing a function reference.

Why don't you ask Keith? He will tell you a cat was medium size, and so
it is gxline(w,a,b(c,d)). Finally, the man has a use. Can you build a
compiler with Keith at its center to make these disambiguations? Rumor
has it there is an AI which is one person answering questions, but has
quite a backlog. Speed may be an issue.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

bart pisze:

A little contrived, but no matter because the same contrivance is here
in my systems language:

-a-a proc main =
-a-a-a-a-a-a for i to 10 do
-a-a-a-a-a-a-a-a-a-a println i, sqrt i
-a-a-a-a-a-a-a-a-a-a println "----------"
-a-a-a-a-a-a end
-a-a end

() and ; removed which is good but you alsoe need to remove keywords
and this one ' and it will be ok


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

bart pisze:

A little contrived, but no matter because the same contrivance is here
in my systems language:

-a-a-a proc main =
-a-a-a-a-a-a-a for i to 10 do
-a-a-a-a-a-a-a-a-a-a-a println i, sqrt i
-a-a-a-a-a-a-a-a-a-a-a println "----------"
-a-a-a-a-a-a-a end
-a-a-a end

() and ; removed which is good but you alsoe need-a to remove keywords
and this one ' and it will be ok

something like - you need a billet to mark definitions ..next one may be
used by another definition but may also put empty one


rui main
EYAO10
println EYAO sqrt EYAO
println "----------"

rui



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

fir pisze:

bart pisze:

A little contrived, but no matter because the same contrivance is
here in my systems language:

-a-a-a proc main =
-a-a-a-a-a-a-a for i to 10 do
-a-a-a-a-a-a-a-a-a-a-a println i, sqrt i
-a-a-a-a-a-a-a-a-a-a-a println "----------"
-a-a-a-a-a-a-a end
-a-a-a end

() and ; removed which is good but you alsoe need-a to remove keywords
and this one ' and it will be ok

something like - you need a billet to mark definitions ..next one may be used by another definition but may also put empty one

-arui main
-a-a-a EYAO10
-a-a-a-a-a-a println EYAO sqrt EYAO
-a-a-a-a-a-a println "----------"

-arui

btw i asked ai about years of languages dont need ";" at the endo of
line (as i said ai is not totally reliable but out of curiosity)


a od jak dawna w jezykach programowanie jest to ze mozna ominac koncowy
; ktory np w c jest wymagany

To zale++y od j-Ozyka, bo pomijanie ko+acowego ; pojawia+eo si-O ju++ bardzo wcze+cnie.

Najciekawsza chronologia:

J-Ozyk Rok Jak to dzia+ea
Python 1991 ; w og||le nie jest potrzebny do ko+aca instrukcji rCo koniec linii j-a ko+aczy
Visual Basic 1991 brak ; na ko+acu instrukcji
Ruby 1995 koniec linii zwykle ko+aczy instrukcj-O
JavaScript 1995 automatyczne wstawianie +crednika (ASI)
Go 2009 kompilator automatycznie wstawia ; w okre+clonych miejscach Swift 2014 ; opcjonalny
Kotlin 2016 ; opcjonalny
Rust 2010/2015 ; ma znaczenie sk+eadniowe i cz-Osto jest wymagany, wi-Oc to
inny przypadek

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 12/09/2026 19:58, bart wrote:

(Snipping lots of good points about language design - I don't want to
discuss fir's hypothetical language, but I can still give you a little
more information on a C point.)

* The function doesn't use an unspecified parameter list (this was a
feature of C but C23 may have deprecated that)

The use of non-prototype function declarations (including implicit ones)
was marked as an "obsolescent" feature in C90. (That is, if I
understand correctly, it was not actually deprecated but was planned to
be deprecated in the near future). C23 skipped deprecation entirely and removed it from the language. (I think most C programmers see that as absurdly slow timing from the C standards committee and C compiler implementers. I only know of one C expert who thought non-prototype
function declarations were useful to keep around, and I don't think he
ever gave a good reason for that.)

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 13/09/2026 09:15, fir wrote:

bart pisze:

A little contrived, but no matter because the same contrivance is here
in my systems language:

-a-a-a proc main =
-a-a-a-a-a-a-a for i to 10 do
-a-a-a-a-a-a-a-a-a-a-a println i, sqrt i
-a-a-a-a-a-a-a-a-a-a-a println "----------"
-a-a-a-a-a-a-a end
-a-a-a end

() and ; removed which is good but you alsoe need-a to remove keywords
and this one ' and it will be ok

The same code runs as-is in my scripting language, but that also allows
this version:

for i to 10 do
? i, reUi
? "-"*10
od

Any better? (The "-"*10 works above too but it was two extra tokens! The
'reU' is an alias for 'sqrt' and was added for fun.)

There used to be a compact form of loop too which may have looked like this:

(i:10 || ?i, reUi; "-"*10)

That's great. But now imagine 1000 lines full of such gobbledygook.

It sounds like your ideal language would be APL, if is not 'clean' and
'clear' that you're after, but 'minimal' and 'cryptic'.

The first version above is the best balance in my view. You /want/ some mixture of keywords and symbols.

In any case, in a typical program, only 1/3 of alphanumerics of
keywords; the rest will still be user-identifiers.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

bart pisze:

On 13/09/2026 09:15, fir wrote:

bart pisze:

A little contrived, but no matter because the same contrivance is
here in my systems language:

-a-a-a proc main =
-a-a-a-a-a-a-a for i to 10 do
-a-a-a-a-a-a-a-a-a-a-a println i, sqrt i
-a-a-a-a-a-a-a-a-a-a-a println "----------"
-a-a-a-a-a-a-a end
-a-a-a end

() and ; removed which is good but you alsoe need-a to remove keywords
and this one ' and it will be ok

The same code runs as-is in my scripting language, but that also allows
this version:

-a for i to 10 do
-a-a-a-a-a ? i, reUi
-a-a-a-a-a ? "-"*10
-a od

Any better? (The "-"*10 works above too but it was two extra tokens! The 'reU' is an alias for 'sqrt' and was added for fun.)

There used to be a compact form of loop too which may have looked like
this:

-a(i:10 || ?i, reUi; "-"*10)

That's great. But now imagine 1000 lines full of such gobbledygook.

It sounds like your ideal language would be APL, if is not 'clean' and 'clear' that you're after, but 'minimal' and 'cryptic'.

The first version above is the best balance in my view. You /want/ some mixture of keywords and symbols.

In any case, in a typical program, only 1/3 of alphanumerics of
keywords; the rest will still be user-identifiers.

i gave you example - its only cryptic if you dont know what it means



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

bart pisze:

On 13/09/2026 09:15, fir wrote:

bart pisze:

A little contrived, but no matter because the same contrivance is
here in my systems language:

-a-a-a proc main =
-a-a-a-a-a-a-a for i to 10 do
-a-a-a-a-a-a-a-a-a-a-a println i, sqrt i
-a-a-a-a-a-a-a-a-a-a-a println "----------"
-a-a-a-a-a-a-a end
-a-a-a end

() and ; removed which is good but you alsoe need-a to remove keywords
and this one ' and it will be ok

The same code runs as-is in my scripting language, but that also
allows this version:

-a-a for i to 10 do
-a-a-a-a-a-a ? i, reUi
-a-a-a-a-a-a ? "-"*10
-a-a od

Any better? (The "-"*10 works above too but it was two extra tokens!
The 'reU' is an alias for 'sqrt' and was added for fun.)

There used to be a compact form of loop too which may have looked like
this:

-a-a(i:10 || ?i, reUi; "-"*10)

That's great. But now imagine 1000 lines full of such gobbledygook.

It sounds like your ideal language would be APL, if is not 'clean' and
'clear' that you're after, but 'minimal' and 'cryptic'.

The first version above is the best balance in my view. You /want/
some mixture of keywords and symbols.

In any case, in a typical program, only 1/3 of alphanumerics of
keywords; the rest will still be user-identifiers.

i gave you example - its only cryptic if you dont know what it means

consider for example french or polish language its totally cryptic until
you will learn it... not to say you want to understand it without
definitions

overally this discussin ended i think at least as for few months,
cant continue becouse you repeat the same things which i got the same
answer (ori talk tehe sama and you rpeat with the same answer)

repeating is not necassary ;c

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 13/09/2026 10:53, fir wrote:

fir pisze:

bart pisze:

It sounds like your ideal language would be APL, if is not 'clean'
and 'clear' that you're after, but 'minimal' and 'cryptic'.

The first version above is the best balance in my view. You /want/
some mixture of keywords and symbols.

In any case, in a typical program, only 1/3 of alphanumerics of
keywords; the rest will still be user-identifiers.

i gave you example - its only cryptic if you dont know what it means

consider for example french or polish language its totally cryptic until
you will learn it...

That is not your aim. That appears to be to start with a language that
you know perfectly well, but remove all punctuation, capitalisation and structure, and half the words. But to what purpose; because you're too
lazy to type?

not to say you want to understand it without

definitions

So an APL (or J or K) program is never cryptic because all you have to
do is learn it? If only I'd thought of that!

The same applies to Assembly I guess. And machine code?

overally this discussin ended i think at least as for few months,
cant continue becouse you repeat the same things

And you keep repeating the same nonsense. What is your endpoint: a
program that can be expressed in one byte?

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

David Brown pisze:

On 12/09/2026 19:58, bart wrote:

(Snipping lots of good points about language design - I don't want to discuss fir's hypothetical language, but I can still give you a little
more information on a C point.)

* The function doesn't use an unspecified parameter list (this was a
feature of C but C23 may have deprecated that)

The use of non-prototype function declarations (including implicit ones)
was marked as an "obsolescent" feature in C90.-a (That is, if I
understand correctly, it was not actually deprecated but was planned to
be deprecated in the near future).-a C23 skipped deprecation entirely and removed it from the language.-a (I think most C programmers see that as absurdly slow timing from the C standards committee and C compiler implementers.-a I only know of one C expert who thought non-prototype function declarations were useful to keep around, and I don't think he
ever gave a good reason for that.)

i was thinking about possible usage of this thinghbut dont see clearly many..its maybe weird as it seem tit should be some

more probably i see as to thios global tmp ram record
which you cn at least use to pass values among

f(); b(); with no passing arguments //via this tmp global ram


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

bart pisze:

On 13/09/2026 10:53, fir wrote:

fir pisze:

bart pisze:

It sounds like your ideal language would be APL, if is not 'clean'
and 'clear' that you're after, but 'minimal' and 'cryptic'.

The first version above is the best balance in my view. You /want/
some mixture of keywords and symbols.

In any case, in a typical program, only 1/3 of alphanumerics of
keywords; the rest will still be user-identifiers.

i gave you example - its only cryptic if you dont know what it means

consider for example french or polish language its totally cryptic
until you will learn it...

That is not your aim. That appears to be to start with a language that
you know perfectly well, but remove all punctuation, capitalisation and structure, and half the words. But to what purpose; because you're too
lazy to type?

-anot to say you want to understand it without

definitions

So an APL (or J or K) program is never cryptic because all you have to
do is learn it? If only I'd thought of that!

The same applies to Assembly I guess. And machine code?

apl i dont know but ofc it applies to assembly but x86 assembly is
terribly flawed
x86 assembly is like c++

overally this discussin ended i think at least as for few months,
cant continue becouse you repeat the same things

And you keep repeating the same nonsense. What is your endpoint: a
program that can be expressed in one byte?

my goal is to make it cleanest possible
and also make thsi sintax more powerfull - it is "carrying" a lot more "weight" (semantic weight).. i men where short sentences may expres much meaning
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

bart pisze:

On 13/09/2026 10:53, fir wrote:

fir pisze:

bart pisze:

It sounds like your ideal language would be APL, if is not 'clean'
and 'clear' that you're after, but 'minimal' and 'cryptic'.

The first version above is the best balance in my view. You /want/
some mixture of keywords and symbols.

In any case, in a typical program, only 1/3 of alphanumerics of
keywords; the rest will still be user-identifiers.

i gave you example - its only cryptic if you dont know what it means

consider for example french or polish language its totally cryptic
until you will learn it...

That is not your aim. That appears to be to start with a language that
you know perfectly well, but remove all punctuation, capitalisation
and structure, and half the words. But to what purpose; because you're
too lazy to type?

-a-anot to say you want to understand it without

definitions

So an APL (or J or K) program is never cryptic because all you have to
do is learn it? If only I'd thought of that!

The same applies to Assembly I guess. And machine code?

apl i dont know but ofc it applies to assembly but x86 assembly is
terribly flawed
x86 assembly is like c++

overally this discussin ended i think at least as for few months,
cant continue becouse you repeat the same things

And you keep repeating the same nonsense. What is your endpoint: a
program that can be expressed in one byte?

my goal is to make it cleanest possible
and also make thsi sintax more powerfull - it is "carrying" a lot more "weight" (semantic weight).. i men where short sentences may expres much meaning

this example is quite clean and weighty

rui main
EYAO10
println EYAO sqrt EYAO
println "----------"

rui

esp this EYAO10 is clean and weighty i got a lot of problems with this
becouse x10 eventually worked but has terrible disadwantage xa is not
standable (a is variable value say 100) but unicode resolves a lot of
problems coz EYAOa work

NOTE this all now seem obvious but before discovering this what seems
obvious LATER BEFORE this all conclusions was VERY FAR form obvious

im saying this becouse i thing that people will take some outcome and
not adress its orygination..all this conclusion i take are oryginal at
least in a sense it is not copied from someo other source (except the
most common typical knowledge base)

(not saying that some solutions i use by chance were already invented
but often in some different contextes and not fully)

even seint the fact some just should take unicode was not obvious not to mention many other things




--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 2026-09-12, bart <bc@freeuk.com> wrote:

Note that the code will still have braces. I suggest a better aim is to eliminate most braces. The should be no need to ever see '} else {'
instead of just 'else'.

There can be a difference; for example (assume <stdio.h> included):

if (0) { if (1) puts("foo"); else puts("bar"); }

if (0) { if (1) puts("foo"); } else { puts("bar"); }

The first line will print nothing; the second one will print "bar".
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

fir pisze:

bart pisze:

On 13/09/2026 10:53, fir wrote:

fir pisze:

bart pisze:

It sounds like your ideal language would be APL, if is not 'clean' >>>>>> and 'clear' that you're after, but 'minimal' and 'cryptic'.

The first version above is the best balance in my view. You /want/ >>>>>> some mixture of keywords and symbols.

In any case, in a typical program, only 1/3 of alphanumerics of
keywords; the rest will still be user-identifiers.

i gave you example - its only cryptic if you dont know what it means >>>>>

consider for example french or polish language its totally cryptic
until you will learn it...

That is not your aim. That appears to be to start with a language
that you know perfectly well, but remove all punctuation,
capitalisation and structure, and half the words. But to what
purpose; because you're too lazy to type?

-a-anot to say you want to understand it without

definitions

So an APL (or J or K) program is never cryptic because all you have
to do is learn it? If only I'd thought of that!

The same applies to Assembly I guess. And machine code?

apl i dont know but ofc it applies to assembly but x86 assembly is
terribly flawed
x86 assembly is like c++

overally this discussin ended i think at least as for few months,
cant continue becouse you repeat the same things

And you keep repeating the same nonsense. What is your endpoint: a
program that can be expressed in one byte?

my goal is to make it cleanest possible
and also make thsi sintax more powerfull - it is "carrying" a lot more
"weight" (semantic weight).. i men where short sentences may expres
much meaning

this example is quite clean and weighty

-a rui main
-a-a-a-a EYAO10
-a-a-a-a-a-a-a println EYAO sqrt EYAO
-a-a-a-a-a-a-a println "----------"

-a rui

its not fully resolved yet as questions may ofc arise and need answer
for example if i use EYAO as an index then EYAO as ana infinite loop is taken? maybe yes maybe not (need answer)


also it rises question is tabEYAO=10 okay as an array acces tab[x]=10

also if to allow spaces and so on

EYAO tab_size
tab EYAO = 10

but i know such things may be resolved more or less so it not deny such
clean base

esp this EYAO10 is clean and weighty i got a lot of problems with this becouse x10 eventually worked but has terrible disadwantage xa is not standable (a is variable value say 100) but unicode resolves a lot of problems coz EYAOa work

NOTE this all now seem obvious but before discovering this what seems obvious LATER BEFORE this all conclusions was VERY FAR form obvious

im saying this becouse i thing that people will take some outcome and
not adress its orygination..all this conclusion i take are oryginal at
least in a sense it is not copied from someo other source (except the
most common typical knowledge base)

(not saying that some solutions i use by chance were already invented
but often in some different contextes and not fully)

even seint the fact some just should take unicode was not obvious not to mention many other things

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

esp this EYAO10 is clean and weighty i got a lot of problems with this becouse x10 eventually worked but has terrible disadwantage xa is not standable (a is variable value say 100) but unicode resolves a lot of problems coz EYAOa work

NOTE this all now seem obvious but before discovering this what seems obvious LATER BEFORE this all conclusions was VERY FAR form obvious

you by chance illustrate this problem

you in fact has notably more feel in this things as average comp.lang.c
user (as seen the fight with you statements often true but you itself
when confronted with better sollution not only not take it but also
fights with it

this illustrates how indeed far from this solution are nearly all people
;c (so rare i dont know none who is close but maybe some are hidden in
some mountains ;c wtill my solutions are oryginal as i dont know no one
who is doin something close as me here)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

bart wrote:

On 13/09/2026 10:53, fir wrote:

fir pisze:

bart pisze:

It sounds like your ideal language would be APL, if is not 'clean'
and 'clear' that you're after, but 'minimal' and 'cryptic'.

The first version above is the best balance in my view. You /want/
some mixture of keywords and symbols.

In any case, in a typical program, only 1/3 of alphanumerics of
keywords; the rest will still be user-identifiers.

i gave you example - its only cryptic if you dont know what it means

consider for example french or polish language its totally cryptic
until you will learn it...

That is not your aim. That appears to be to start with a language that
you know perfectly well, but remove all punctuation, capitalisation and structure, and half the words. But to what purpose; because you're too
lazy to type?

-anot to say you want to understand it without

definitions

So an APL (or J or K) program is never cryptic because all you have to
do is learn it? If only I'd thought of that!

The same applies to Assembly I guess. And machine code?

overally this discussin ended i think at least as for few months,
cant continue becouse you repeat the same things

And you keep repeating the same nonsense. What is your endpoint: a
program that can be expressed in one byte?

He wants to compress the language, metaphor a plum, into a prune that
has much reduced.

It is the same way with a newsgroup when the warlord Lane W has
compressed all the shitheads, David Brown, Keith, bart, and the rest
except I guess the fellows who are in the mood, when they all conspire
by email to not respond to anything he writes. It is at such a time that
he declares victory. As I roll over yet another group in the 97 I have subjugated to my rule and made complacent, a tear drips from my eye. C,
such a beautiful language, yet what hypocrites such as David Brown
defending it. Really, nothing personal? I beg to differ. Under my boot,
a serpent crawls out of the skull of another victim.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Lane W pisze:

bart wrote:

On 13/09/2026 10:53, fir wrote:

fir pisze:

bart pisze:

It sounds like your ideal language would be APL, if is not 'clean'
and 'clear' that you're after, but 'minimal' and 'cryptic'.

The first version above is the best balance in my view. You /want/
some mixture of keywords and symbols.

In any case, in a typical program, only 1/3 of alphanumerics of
keywords; the rest will still be user-identifiers.

i gave you example - its only cryptic if you dont know what it means

consider for example french or polish language its totally cryptic
until you will learn it...

That is not your aim. That appears to be to start with a language that
you know perfectly well, but remove all punctuation, capitalisation
and structure, and half the words. But to what purpose; because you're
too lazy to type?

-a-anot to say you want to understand it without

definitions

So an APL (or J or K) program is never cryptic because all you have to
do is learn it? If only I'd thought of that!

The same applies to Assembly I guess. And machine code?

overally this discussin ended i think at least as for few months,
cant continue becouse you repeat the same things

And you keep repeating the same nonsense. What is your endpoint: a
program that can be expressed in one byte?

He wants to compress the language, metaphor a plum, into a prune that
has much reduced.

It is the same way with a newsgroup when the warlord Lane W has
compressed all the shitheads, David Brown, Keith, bart, and the rest
except I guess the fellows who are in the mood, when they all conspire
by email to not respond to anything he writes. It is at such a time that
he declares victory. As I roll over yet another group in the 97 I have subjugated to my rule and made complacent, a tear drips from my eye. C,
such a beautiful language, yet what hypocrites such as David Brown
defending it. Really, nothing personal? I beg to differ. Under my boot,
a serpent crawls out of the skull of another victim.

no worry its hard to answer this becouse its hard to know what exactly
tis is about but it sometimes have some points (you will need hovever
care not to overdo it..becouse as i said when commenting some people
with sticks up in their asses some such type coments are fun but if
there is to much of cross boundering there may haos os spam do appear
and that is harmfull

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 13/09/2026 11:53, Ike Naar wrote:

On 2026-09-12, bart <bc@freeuk.com> wrote:

Note that the code will still have braces. I suggest a better aim is to
eliminate most braces. The should be no need to ever see '} else {'
instead of just 'else'.

There can be a difference; for example (assume <stdio.h> included):

if (0) { if (1) puts("foo"); else puts("bar"); }

if (0) { if (1) puts("foo"); } else { puts("bar"); }

The first line will print nothing; the second one will print "bar".

This illustrates my point; first some Pascal:

if cond then begin s1; s2 end else begin s3; s4 end

C is the same but uses braces, and semicolons are terminators:

if (cond) { s1; s2; } else { s3; s4; }

One has 'end else begin', the other has '} else {'.

However the Pascal version can be improved; since 'then' and 'else' can
act as block delimiters:

if cond then s1; s2 end else s3; s4 end

Only the final block in a chain (eg. if-else-if) needs the 'end'
terminator. And now 'else' is by itself.

Unfortunately this doesn't transfer well to C:

if (cond) s1; s2; else s3; s4; }

The () around 'cond' are needed as the ')' separates cond and s1 (fir
doesn't not appreciate this point; he thinks it is fine for statements
and expressions to run together provided that there is a way to infer
where one logically ends and the other starts).

The trouble is that lone, unbalanced } at the end.

So it would need a bigger change. But then that's what fir is doing.
(He's never going to get there, but there's no harm in humouring him.)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

bart pisze:

On 13/09/2026 11:53, Ike Naar wrote:

On 2026-09-12, bart <bc@freeuk.com> wrote:

Note that the code will still have braces. I suggest a better aim is to
eliminate most braces. The should be no need to ever see '} else {'
instead of just 'else'.

There can be a difference; for example (assume <stdio.h> included):

-a-a-a-a if (0) { if (1) puts("foo");-a-a else-a-a puts("bar"); }

-a-a-a-a if (0) { if (1) puts("foo"); } else { puts("bar"); }

The first line will print nothing; the second one will print "bar".

This illustrates my point; first some Pascal:

-a if cond then begin s1; s2 end else begin s3; s4 end

C is the same but uses braces, and semicolons are terminators:

-a if (cond) { s1; s2; } else { s3; s4; }

One has 'end else begin', the other has '} else {'.

However the Pascal version can be improved; since 'then' and 'else' can
act as block delimiters:

-a if cond then s1; s2 end else s3; s4 end

Only the final block in a chain (eg. if-else-if) needs the 'end'
terminator. And now 'else' is by itself.

Unfortunately this doesn't transfer well to C:

-a if (cond) s1; s2; else s3; s4; }

The () around 'cond' are needed as the ')' separates cond and s1 (fir doesn't not appreciate this point; he thinks it is fine for statements
and expressions to run together provided that there is a way to infer
where one logically ends and the other starts).

The trouble is that lone, unbalanced } at the end.

So it would need a bigger change. But then that's what fir is doing.
(He's never going to get there, but there's no harm in humouring him.)

what you consider problems is so siple i dont even think on it


as to ifs syntax i am yet not sure

some like this may be considered but its not much good loking
though is sorta logical

x<10 raA x++>5
raA more_than_five
ray less_than_six
ray do_nothing

those raA ale also sorta redundant

x<10 x++>5 more_than_five ray less_than_six ray do_nothing




can optionally ad parenthesis or braces for clarity

x<10 (x++>5 more_than_five ray less_than_six) ray do_nothing

x<10 {x++>5 more_than_five ray less_than_six } ray do_nothing



but im not fully convinced
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 13/09/2026 14:21, fir wrote:

bart pisze:

On 13/09/2026 11:53, Ike Naar wrote:

On 2026-09-12, bart <bc@freeuk.com> wrote:

Note that the code will still have braces. I suggest a better aim is to >>>> eliminate most braces. The should be no need to ever see '} else {'
instead of just 'else'.

There can be a difference; for example (assume <stdio.h> included):

-a-a-a-a if (0) { if (1) puts("foo");-a-a else-a-a puts("bar"); }

-a-a-a-a if (0) { if (1) puts("foo"); } else { puts("bar"); }

The first line will print nothing; the second one will print "bar".

This illustrates my point; first some Pascal:

-a-a if cond then begin s1; s2 end else begin s3; s4 end

C is the same but uses braces, and semicolons are terminators:

-a-a if (cond) { s1; s2; } else { s3; s4; }

One has 'end else begin', the other has '} else {'.

However the Pascal version can be improved; since 'then' and 'else'
can act as block delimiters:

-a-a if cond then s1; s2 end else s3; s4 end

Only the final block in a chain (eg. if-else-if) needs the 'end'
terminator. And now 'else' is by itself.

Unfortunately this doesn't transfer well to C:

-a-a if (cond) s1; s2; else s3; s4; }

The () around 'cond' are needed as the ')' separates cond and s1 (fir
doesn't not appreciate this point; he thinks it is fine for statements
and expressions to run together provided that there is a way to infer
where one logically ends and the other starts).

The trouble is that lone, unbalanced } at the end.

So it would need a bigger change. But then that's what fir is doing.
(He's never going to get there, but there's no harm in humouring him.)

what you consider problems is so siple i dont even think on it

as to ifs syntax i am yet not sure

some like this may be considered but its not much good loking
though is sorta logical

x<10 raA x++>5
-a-a-a-a-a-a raA-a more_than_five
-a-a-a-a-a-a ray less_than_six
-a-a-a ray do_nothing

Try: if 5 < x < 10.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

bart pisze:

On 13/09/2026 14:21, fir wrote:

bart pisze:

On 13/09/2026 11:53, Ike Naar wrote:

On 2026-09-12, bart <bc@freeuk.com> wrote:

Note that the code will still have braces. I suggest a better aim
is to
eliminate most braces. The should be no need to ever see '} else {'
instead of just 'else'.

There can be a difference; for example (assume <stdio.h> included):

-a-a-a-a if (0) { if (1) puts("foo");-a-a else-a-a puts("bar"); }

-a-a-a-a if (0) { if (1) puts("foo"); } else { puts("bar"); }

The first line will print nothing; the second one will print "bar".

This illustrates my point; first some Pascal:

-a-a if cond then begin s1; s2 end else begin s3; s4 end

C is the same but uses braces, and semicolons are terminators:

-a-a if (cond) { s1; s2; } else { s3; s4; }

One has 'end else begin', the other has '} else {'.

However the Pascal version can be improved; since 'then' and 'else'
can act as block delimiters:

-a-a if cond then s1; s2 end else s3; s4 end

Only the final block in a chain (eg. if-else-if) needs the 'end'
terminator. And now 'else' is by itself.

Unfortunately this doesn't transfer well to C:

-a-a if (cond) s1; s2; else s3; s4; }

The () around 'cond' are needed as the ')' separates cond and s1 (fir
doesn't not appreciate this point; he thinks it is fine for
statements and expressions to run together provided that there is a
way to infer where one logically ends and the other starts).

The trouble is that lone, unbalanced } at the end.

So it would need a bigger change. But then that's what fir is doing.
(He's never going to get there, but there's no harm in humouring him.)

what you consider problems is so siple i dont even think on it


as to ifs syntax i am yet not sure

some like this may be considered but its not much good loking
though is sorta logical

x<10 raA x++>5
-a-a-a-a-a-a-a raA-a more_than_five
-a-a-a-a-a-a-a ray less_than_six
-a-a-a-a ray do_nothing

Try: if 5 < x < 10.

why? its the same


5<x<10 raA



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

bart pisze:

On 13/09/2026 14:21, fir wrote:

bart pisze:

On 13/09/2026 11:53, Ike Naar wrote:

On 2026-09-12, bart <bc@freeuk.com> wrote:

Note that the code will still have braces. I suggest a better aim >>>>>> is to
eliminate most braces. The should be no need to ever see '} else {' >>>>>> instead of just 'else'.

There can be a difference; for example (assume <stdio.h> included):

-a-a-a-a if (0) { if (1) puts("foo");-a-a else-a-a puts("bar"); }

-a-a-a-a if (0) { if (1) puts("foo"); } else { puts("bar"); }

The first line will print nothing; the second one will print "bar".

This illustrates my point; first some Pascal:

-a-a if cond then begin s1; s2 end else begin s3; s4 end

C is the same but uses braces, and semicolons are terminators:

-a-a if (cond) { s1; s2; } else { s3; s4; }

One has 'end else begin', the other has '} else {'.

However the Pascal version can be improved; since 'then' and 'else'
can act as block delimiters:

-a-a if cond then s1; s2 end else s3; s4 end

Only the final block in a chain (eg. if-else-if) needs the 'end'
terminator. And now 'else' is by itself.

Unfortunately this doesn't transfer well to C:

-a-a if (cond) s1; s2; else s3; s4; }

The () around 'cond' are needed as the ')' separates cond and s1
(fir doesn't not appreciate this point; he thinks it is fine for
statements and expressions to run together provided that there is a
way to infer where one logically ends and the other starts).

The trouble is that lone, unbalanced } at the end.

So it would need a bigger change. But then that's what fir is doing.
(He's never going to get there, but there's no harm in humouring him.)

what you consider problems is so siple i dont even think on it


as to ifs syntax i am yet not sure

some like this may be considered but its not much good loking
though is sorta logical

x<10 raA x++>5
-a-a-a-a-a-a-a raA-a more_than_five
-a-a-a-a-a-a-a ray less_than_six
-a-a-a-a ray do_nothing

Try: if 5 < x < 10.

why? its the same

5<x<10 raA

interesting problem is if

araAbraAcraAdraA all must be tru to go here


so how to implement or this way


araybraycraydray {all must be false to go here}
{or would be here it seems but you may go here also after false
and it has no end/delimiter so it needs something..}



so maybe or is

(araybraycraydray)ray { or is here? }









--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

bart pisze:

On 13/09/2026 14:21, fir wrote:

bart pisze:

On 13/09/2026 11:53, Ike Naar wrote:

On 2026-09-12, bart <bc@freeuk.com> wrote:

Note that the code will still have braces. I suggest a better aim
is to
eliminate most braces. The should be no need to ever see '} else {'
instead of just 'else'.

There can be a difference; for example (assume <stdio.h> included):

-a-a-a-a if (0) { if (1) puts("foo");-a-a else-a-a puts("bar"); }

-a-a-a-a if (0) { if (1) puts("foo"); } else { puts("bar"); }

The first line will print nothing; the second one will print "bar".

This illustrates my point; first some Pascal:

-a-a if cond then begin s1; s2 end else begin s3; s4 end

C is the same but uses braces, and semicolons are terminators:

-a-a if (cond) { s1; s2; } else { s3; s4; }

One has 'end else begin', the other has '} else {'.

However the Pascal version can be improved; since 'then' and 'else'
can act as block delimiters:

-a-a if cond then s1; s2 end else s3; s4 end

Only the final block in a chain (eg. if-else-if) needs the 'end'
terminator. And now 'else' is by itself.

Unfortunately this doesn't transfer well to C:

-a-a if (cond) s1; s2; else s3; s4; }

The () around 'cond' are needed as the ')' separates cond and s1 (fir
doesn't not appreciate this point; he thinks it is fine for
statements and expressions to run together provided that there is a
way to infer where one logically ends and the other starts).

The trouble is that lone, unbalanced } at the end.

So it would need a bigger change. But then that's what fir is doing.
(He's never going to get there, but there's no harm in humouring him.)

what you consider problems is so siple i dont even think on it


as to ifs syntax i am yet not sure

some like this may be considered but its not much good loking
though is sorta logical

x<10 raA x++>5
-a-a-a-a-a-a-a raA-a more_than_five
-a-a-a-a-a-a-a ray less_than_six
-a-a-a-a ray do_nothing

Try: if 5 < x < 10.

not btw that if you want make much more rigid and more descriptive
language youre obviously fukll right to implement this philosophy im not denying this

i waguely remember i sad to you something like "try" or "you my try"
giving some of my outcomes as to my philosophy as i assumed you
want to use something good ;c

im joking (imo ofc my philosophy here is better but you may use your own
ofc)

for me your conventions are suboptimal (all those ones who not by chance
are mine own ;c )

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

bart pisze:

On 13/09/2026 14:21, fir wrote:

bart pisze:

On 13/09/2026 11:53, Ike Naar wrote:

On 2026-09-12, bart <bc@freeuk.com> wrote:

Note that the code will still have braces. I suggest a better aim >>>>>> is to
eliminate most braces. The should be no need to ever see '} else {' >>>>>> instead of just 'else'.

There can be a difference; for example (assume <stdio.h> included):

-a-a-a-a if (0) { if (1) puts("foo");-a-a else-a-a puts("bar"); }

-a-a-a-a if (0) { if (1) puts("foo"); } else { puts("bar"); }

The first line will print nothing; the second one will print "bar".

This illustrates my point; first some Pascal:

-a-a if cond then begin s1; s2 end else begin s3; s4 end

C is the same but uses braces, and semicolons are terminators:

-a-a if (cond) { s1; s2; } else { s3; s4; }

One has 'end else begin', the other has '} else {'.

However the Pascal version can be improved; since 'then' and 'else'
can act as block delimiters:

-a-a if cond then s1; s2 end else s3; s4 end

Only the final block in a chain (eg. if-else-if) needs the 'end'
terminator. And now 'else' is by itself.

Unfortunately this doesn't transfer well to C:

-a-a if (cond) s1; s2; else s3; s4; }

The () around 'cond' are needed as the ')' separates cond and s1
(fir doesn't not appreciate this point; he thinks it is fine for
statements and expressions to run together provided that there is a
way to infer where one logically ends and the other starts).

The trouble is that lone, unbalanced } at the end.

So it would need a bigger change. But then that's what fir is doing.
(He's never going to get there, but there's no harm in humouring him.)

what you consider problems is so siple i dont even think on it


as to ifs syntax i am yet not sure

some like this may be considered but its not much good loking
though is sorta logical

x<10 raA x++>5
-a-a-a-a-a-a-a raA-a more_than_five
-a-a-a-a-a-a-a ray less_than_six
-a-a-a-a ray do_nothing

Try: if 5 < x < 10.

not btw that if you want make much more rigid and more descriptive
language youre obviously fukll right to implement this philosophy im not denying this

i waguely remember i sad to you something like "try" or "you my try"
giving some of my outcomes as to my philosophy as i assumed you
want to use something good ;c

im joking (imo ofc my philosophy here is better but you may use your own ofc)

for me your conventions are suboptimal (all those ones who not by chance
are mine own ;c )

for me the ones im searching are optimal at least ofr last 'research
state' though i got different worry (on whch i was saint more than one)

c indeed is on some very impressive track to me and im not quite sure
using my filosophy (which is at seen very fractal and syntax
minimalising) is in fact worse than this oryginal "railroad" track

in old c i by chance see something like 'coal' and 'rails'/railroad
feeling and in this mine i see its more like light and plastic 'style'
not so much nice eventually - it worries my but dont know what to do
with that..maybe its too much far form assembly/machine language but
today hard to work in machne language on raw steel and oil machines..
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

fir pisze:

bart pisze:

On 13/09/2026 14:21, fir wrote:

bart pisze:

On 13/09/2026 11:53, Ike Naar wrote:

On 2026-09-12, bart <bc@freeuk.com> wrote:

Note that the code will still have braces. I suggest a better aim >>>>>>> is to
eliminate most braces. The should be no need to ever see '} else {' >>>>>>> instead of just 'else'.

There can be a difference; for example (assume <stdio.h> included): >>>>>>
-a-a-a-a if (0) { if (1) puts("foo");-a-a else-a-a puts("bar"); }

-a-a-a-a if (0) { if (1) puts("foo"); } else { puts("bar"); }

The first line will print nothing; the second one will print "bar". >>>>>

This illustrates my point; first some Pascal:

-a-a if cond then begin s1; s2 end else begin s3; s4 end

C is the same but uses braces, and semicolons are terminators:

-a-a if (cond) { s1; s2; } else { s3; s4; }

One has 'end else begin', the other has '} else {'.

However the Pascal version can be improved; since 'then' and 'else' >>>>> can act as block delimiters:

-a-a if cond then s1; s2 end else s3; s4 end

Only the final block in a chain (eg. if-else-if) needs the 'end'
terminator. And now 'else' is by itself.

Unfortunately this doesn't transfer well to C:

-a-a if (cond) s1; s2; else s3; s4; }

The () around 'cond' are needed as the ')' separates cond and s1
(fir doesn't not appreciate this point; he thinks it is fine for
statements and expressions to run together provided that there is a >>>>> way to infer where one logically ends and the other starts).

The trouble is that lone, unbalanced } at the end.

So it would need a bigger change. But then that's what fir is
doing. (He's never going to get there, but there's no harm in
humouring him.)

what you consider problems is so siple i dont even think on it


as to ifs syntax i am yet not sure

some like this may be considered but its not much good loking
though is sorta logical

x<10 raA x++>5
-a-a-a-a-a-a-a raA-a more_than_five
-a-a-a-a-a-a-a ray less_than_six
-a-a-a-a ray do_nothing

Try: if 5 < x < 10.

not btw that if you want make much more rigid and more descriptive
language youre obviously fukll right to implement this philosophy im
not denying this

i waguely remember i sad to you something like "try" or "you my try"
giving some of my outcomes as to my philosophy as i assumed you
want to use something good ;c

im joking (imo ofc my philosophy here is better but you may use your
own ofc)

for me your conventions are suboptimal (all those ones who not by
chance are mine own ;c )

for me the ones im searching are optimal at least ofr last 'research
state' though i got different worry (on whch i was saint more than one)

c indeed is on some very impressive track to me and im not quite sure
using my filosophy (which is at seen very fractal and syntax
minimalising) is in fact worse than this oryginal "railroad" track

in old c i by chance see something like 'coal' and 'rails'/railroad
feeling and in this mine i see its more like light and plastic 'style'
not so much nice eventually - it worries my but dont know what to do
with that..maybe its too much far form assembly/machine language but
today hard to work in machne language on raw steel and oil machines..

so i also not judge your language stylistically - it may heve some
feeling (though i not get this feeling as i dont know it... this feeling
is maybe a part of times where things were used..as c had probably a
feeling of thi 60ties or 70ties in MIT (berkeley?) or something

for ma c has always good 'dark' feeling but all that times was more like
rain night and oxygene feeling that present times... bright lcd plastic monitors and things
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 13/09/2026 15:34, fir wrote:

bart pisze:

On 13/09/2026 14:21, fir wrote:

bart pisze:

On 13/09/2026 11:53, Ike Naar wrote:

On 2026-09-12, bart <bc@freeuk.com> wrote:

Note that the code will still have braces. I suggest a better aim >>>>>> is to
eliminate most braces. The should be no need to ever see '} else {' >>>>>> instead of just 'else'.

There can be a difference; for example (assume <stdio.h> included):

-a-a-a-a if (0) { if (1) puts("foo");-a-a else-a-a puts("bar"); }

-a-a-a-a if (0) { if (1) puts("foo"); } else { puts("bar"); }

The first line will print nothing; the second one will print "bar".

This illustrates my point; first some Pascal:

-a-a if cond then begin s1; s2 end else begin s3; s4 end

C is the same but uses braces, and semicolons are terminators:

-a-a if (cond) { s1; s2; } else { s3; s4; }

One has 'end else begin', the other has '} else {'.

However the Pascal version can be improved; since 'then' and 'else'
can act as block delimiters:

-a-a if cond then s1; s2 end else s3; s4 end

Only the final block in a chain (eg. if-else-if) needs the 'end'
terminator. And now 'else' is by itself.

Unfortunately this doesn't transfer well to C:

-a-a if (cond) s1; s2; else s3; s4; }

The () around 'cond' are needed as the ')' separates cond and s1
(fir doesn't not appreciate this point; he thinks it is fine for
statements and expressions to run together provided that there is a
way to infer where one logically ends and the other starts).

The trouble is that lone, unbalanced } at the end.

So it would need a bigger change. But then that's what fir is doing.
(He's never going to get there, but there's no harm in humouring him.)

what you consider problems is so siple i dont even think on it


as to ifs syntax i am yet not sure

some like this may be considered but its not much good loking
though is sorta logical

x<10 raA x++>5
-a-a-a-a-a-a-a raA-a more_than_five
-a-a-a-a-a-a-a ray less_than_six
-a-a-a-a ray do_nothing

Try: if 5 < x < 10.

why? its the same

The same as ... what?

I don't know what your example was meant to do. But if testing whether x
was in some interval, and with my example 'x' is only written once.

Otherwise you might want to look at how lots of languages do more
general pattern-matching.>

5<x<10 raA

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

bart <bc@freeuk.com> wrote:

On 09/09/2026 02:59, Waldek Hebisch wrote:

bart <bc@freeuk.com> wrote:

On 08/09/2026 01:02, Waldek Hebisch wrote:

bart <bc@freeuk.com> wrote:

On 07/09/2026 14:33, David Brown wrote:

On 07/09/2026 14:55, bart wrote:

A typical module scheme works like this:

* You have, say, a project of 100 modules
* Each module selectively exports some entities
* Each module selectively imports some subset of the other 99 modules >>>>>>>

OK so far.

The result is that each module starts with some rag-tag collection of >>>>>>> 'import' statements, each different from any other module, and needing >>>>>>> a lot of maintenance.

No.-a People who write /structured/ code do not do "rag-tag".

When a project is of a size where it is inconvenient to keep track of >>>>>> all the separate "import" (or "#include", or whatever) statements, you >>>>>> use a hierarchy.-a Instead of importing "dns", "udp", "http", etc., >>>>>> modules, you import "network".-a The common "network" module pulls in the
sub-modules.-a You probably also organise things in directories and sub- >>>>>> directories, matching the module layout.-a It is /structured/.

But it's a pattern I've seen a lot. In C also, as collections of
#includes; this example is from Lua, a project of only 35 modules, and >>>>> from one of its .c files:

#include "lprefix.h"

#include <float.h>
#include <limits.h>
#include <math.h>
#include <stdlib.h>

#include "lua.h"

#include "lcode.h"
#include "ldebug.h"
#include "ldo.h"
#include "lgc.h"
#include "llex.h"
#include "lmem.h"
#include "lobject.h"
#include "lopcodes.h"
#include "lparser.h"
#include "lstring.h"
#include "ltable.h"
#include "lvm.h"

Every file has a different set. In all, there are 28K lines of C code >>>>> among the .c files, and there are 466 #include lines. That is similar to >>>>> the maintenance nightmare where each file imports a particular set of >>>>> modules.

The organization looks sensible to me.

Not to me. This project uses these 35 files:

lapi.c lauxlib.c lbaselib.c lcode.c lcorolib.c lctype.c ldblib.c
ldebug.c ldo.c ldump.c lfunc.c lgc.c linit.c liolib.c llex.c
lmathlib.c lmem.c loadlib.c lobject.c lopcodes.c loslib.c lparser.c
lstate.c lstring.c lstrlib.c ltable.c ltablib.c ltests.c ltm.c lua.c
lundump.c lutf8lib.c lvm.c lzio.c onelua.c

(A build will use 34 of them, depending whether it is EXE or DLL.)

With a module scheme, there should be no need for any additional info at >>> all. But my point was, with how such schemes typically work, you still
have lots of mixed sets of 'import' statements at the start of each file. >>>

Given that #include lines
are less than 2% of total and are likely to change very infrequently
I see no maintennce problem.

You can't quantify it like that. In any case, they will only change
infrequently once you've finished development!

If a program is "finished" it will not change at all. During
normal developement I need to add #include lines, but once
added they tend to stay. Sometimes I realize that given
include is not needed or I decide to rename a file. Normal
code is different, first version may have bugs which need
fixing, I may realize that different structure is better, so
there is lot of changes. Relatively to that I perceive changes
to #include lines to be very infrequent.

I found it annoying enough, and taking up enough time to devise a new
way of doing modules. And it is utter bliss.

I agree that maintaing info that you do not value may be annoying.
But if you are used to maintaing C code bases, than maintaining
#include lines does not take much time.

People around here always seems to be making excuses for C!

I find that adding include files, creating headers, maintaining forward declarations etc to be a complete PITA.

Apparenty you ignored first part above. So, let me expand this.
I see value in specifying interfaces. For me it is important
design information. It takes some time to get it right. Not
time to code or type. It takes time to find good design.
Writing declarations is small part of it. In my use typical import
statement imports several declarations so is even smaller issue.
I mentioned non-C project where I have about 1200 modules. There
are 1115 import statements. Note that some uses imply/are equivalent
to import, for example there is inheritance of interfaces (given
interface exports everything that its parents export plus usually some additional things), there is probably about 5 thousends of instances
of inheritance. Alternatives would involve duplicating some thousends
of declarations (probably around 10-15 thousends). The system
has about 150000 LOC (215000 wc lines). Compared to total import
statements and inheritance specifications are small part. And they
are relatively trivial: cases where code compiled but import or
inheritance statements were wrong wre quite rare and they mainly
were cases of missing export or not needed import. Later re-design
may change interfaces, but I mean correctness with respect to design
at time where code was compiled. OTOH normal executable code may
compile fine but behaves completely wrong, so requires more work,

I do not think that C can do what this system is doing. But extrapolating, design in C of similar spirt would probably need say 5000 #include
lines, some hairy macros and 200000-300000 LOC. And executable part
would be much more tricky to get right.

To put this in a bit different way, I probably can enter 1000 lines
daily. If there is enough regularities than I can use tools like cut-and-paste, global replacement and similar to reduce amount of
typing and to generate say 2000 lines in a day. But when I need
to write executable code, than in happy cases _maybe_ I can
generate 500 lines a day. And usually much less than this.
In case of C I can cut-and-paste between prototypes and function
header, so aount of work needed to maintain declaration in
include file is much smaller than for typical code line. If
I need to change say type in declaration I do this via global
search and replace going over all sources, so extra work needed
is proportional to size of prototypes, which is small percentage
of total sources. And such changes are essentially design changes,
so need some thought before I make them.

So, I think that your problem is mostly psychological: you consider export/import info as unimportant and it is painful to you to do
work that you consider useless. I consider maintaining export/import
info as important and can do this with resonable efficiency.

Still, modern languages tend to have a module scheme, suggesting the
'flexible' C approach (I'd use the term 'prehistoric') wasn't quite enough. >>

I used or at least looked at several languages with module systems
or things intended to perform similar duty. You approach seem to
be unique, all other require explicit import or equivalent at least
in some (rather frequent) cases. Some languages do not support
re-export, in such case you can rightfully complain. The ones with
re-export allow forming common interface module do that number
of import statements is minimised. But this is developers choice
and apparently most prefer to import only needed things, even
though it requires more import statements.

Some even specify individual names to be imported from a module. What a complete waste of time!

If I need 1 or 2 names from a module, then it makes sense to specify
them explicitely. This is important information if you want to change
design. I certainly do not want to _always_ specify individual names
and system that I use do not require this.

It's bad enough listing the modules themselves, of which there may a
dozen or two, but there could be hundreds of imported functions.

A module scheme should mean less work not more.

OK. But I look at total work. Old systems like FORTRAN (when
it was all caps) made things "easy" by providing default type
for variables based on first letter. Later systems tended to
be more strict requireing explicit declarations. Modern
tendecly is to use type inference, either full as in ML and
followers, or partial like C or C++ 'auto'. Mismatched
declarations may cause troubles like crashes or wrong output
that take work to fix. Compared to that mismatches in explicit
declarations are trivial to fix. So one adds some extra work
to write and maintain declarations for benefit of better error
detection and reduction of total work. Type inference means
almost no reduction in ability to detect errors and some reduction
of work in maintaining declarations. At least in case of C and
C++ type inference optional: you can still give explicit types.
At least your description of of your module system suggest that
it is more like FORTRAN than modern type interface. That is
you hardcode some resonable use case. But if it does not match
user needs, then either program will not build or there will
be chance of build errors. Maybe you worked out good rules,
we do not know. But there is a different aspect: local declarations
are pretty frequent and can be result of macro expansion. So
'auto' has measurable impact on ease of coding. '#include'
lines are much less frequent, so possible saving is much smaller.
Given small possible gain old principle "do not fix what is not
broken" applies. As I wrote, there are things that should
be improved and many languages other than C have their own
module system. But requrement for explicit imports is very
common.

Module system has other advantages over C. First, in C sane
developers use headers in consistent way, but language
does not enforce it. Typical module system enforces
consistency. Second, module interfaces can be parsed once,
avoiding problem of repeated re-parsing of C headers.

According to David Brown and Scott Lurndal, that is a non-problem!

And according to DB, reducing a large, complex mass of header files (of external library) into one compact file 95% smaller, would be a waste of time.

If they want, they can write what they think about this issue.
Here I am stating my opinion in context of what you wrote.
One problem with C headers is that a single macro can choose
a differenet branch in a header, so you either need some sophisticated
system of dealing with conditionals or you need to re-parse
whenever any macro is defined differently than during previous
parse. Also, when we have system that works but burns more CPU
cycles than desirable, then throwing enough CPU power may be
best practical solution. That does not stop me for looking for
more CPU-efficient solutions.

Third, modules resolve name clashes: the "same" name in
two different modules is disambiguated by its source module.
Fourth, given a main module compiler can track its imports
and build the program without need for separate Makefile.

I tried a scheme in C once. That is, a scheme where you submitted only
the main.c file to the compiler, then it discovered the rest.

It worked well, but required programs to be written in a certain way.
For example, each module file.c required a matching file.h header.

Yes, C includes are not real module system, so one needs extra
conventions.

In the main module, you only included the .h files needed by this
module. It would then add those .c files, and applied the process recursively.

However all the projects I wanted to build weren't structured like this.

Yes.

There are different styles. Ada, Modula 2 and Extended Pascal
use separate interface modules. In typical practice they are
stored in separate files so this looks similar to C practice
of having .c and .h files. Other languages like UCSD/Turbo
Pascal have modules with separate iterface and implementation
parts, but both parts are considered a single module. In
practice with such languages whole module is kept in a single
file, so number of separate files is smaller. But you still
have separate declarations in interface part and definitions
in implementation part. Wirth Oberon (or at least some variant
of it) uses different apprach, IIRC exported functions are
marked putting asterisk before function name. That means less
code to write, but to see what is exported you need a separate
tool.

With separate interface files, who writes the interface: is it the programmer who has to duplicate what is in the implementation? (In which case, what checks are made that it matches?)

In system that I use it is the programmer. System checks that
declaration match. In case of systems allowing overloading
there is possiblity that interface file contains one declaration,
while module body declares different function of the same name.
That alone is legal. But if function declared in interface has
no corresponding implementation, then sooner or later this will
be detected. One possibilty is that compilation of module may
signal error due to unimplemented export. Another posibility is
that attempt to use such unimplemented function will cause
runtime error. The second may be nicer during developement,
when interface is defined first and implemented in incremental
way, as it allows testing what is implemented. The first one
is better when you wnat to compile final program.

Or is it automatic?

My first attempts at (modern) modules tried to do the latter, but it was hard. For example, compile module A.m and it generates A.exp which is
the interface that can be used elsewhere via 'import A'.

But suppose A and B import each other; which is compiled first?

This I resolve with what you would call "whole program compilation".
First pass tries to recognize types. Second pass collects info
about exported functions. I use this in context of explicit interface
parts, but in fact compiler parses everthing and extracts some
information from implementation part. So in principle I could
extract interace based on some markers. After the second pass there
is normal compilation where imports use info colleded in the second
pass. This in not particularly fast, for 150000 LOC I need 3.5s
to extract the interface info. Still, it is small part of the
whole compilation which needs about 300s CPU time (about 38s
real time when using 20 cores). Note: those 3.5s by necessity is
using single core, so I care more about it than about other part
that can be speeded up by using more cores.

For languages without overloading one could use multipass approach:
in first pass collect info about identifiers exported from given
module and list of modules that it imports. In the second pass
compiler would found out which module is responsible for defining
each imported identifier. After that one can do compilation as
in case of explicit interfaces. That is compiler can find out
modules which define each identifier needed by the interface.
If there is cycle between interfaces, that can be detected and
reported (it is an error in typical implementation of explicit
interfaces). Otherwise compiler could find an order such that
each interface depend only on interfaces compiled earlier. After
that one can compile implementations in any order.

IIUC Oberon still _allows_ explicit interface files. So one
could use explicit interfaces to break cycles. That is compiler
would first compile interface part of A, after that modules using A,
and finally implementation part of A.

This is an advantage of a manually written interface, in that cyclic
imports become easier, and you don't need a heirarchical structure.

IIUC modules with separate iterface and implementation were
advocated together with database-like storage of source code.

I now work with whole program compilers. There, a discrete interface
file doesn't make sense and is not needed between the modules of the
same program.

Well, I want well specified interfaces between parts of the program.
With this it is much easier to decide which module is wrong (does not
comply with its interface) and consequently to fix bugs. Also
I have modules which can use use one of several other modules.
That is module M can use function from A, B, C, ... and it should
work correctly which each one. As long as A, B, C, ... have the
same interface I can test that M works with say A and the A, B, C, ...
in fact implement the same interface and after that expect that
M will also work with B or C. Without well specified interfaces
that would be much harder (or impossible).

In different context, one may have collection of modules such that
some subsets form programs. That is particularly relevant for microcontrollers, where target is too small to include all available
modules. Also, different microcontrollers may need different
(alternative) hardware specific modules. In such situation you
do not want to leak hardware specific details to general modules.
And in general, you want to limit what is pulled in only to stuff
that is actually needed.

But they still exist at the boundaries of the program: when the program imports an external library, or my program is a library that exports functions. In that case, they are only partly automated.

--
Waldek Hebisch
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

bart pisze:

On 13/09/2026 15:34, fir wrote:

bart pisze:

On 13/09/2026 14:21, fir wrote:

bart pisze:

On 13/09/2026 11:53, Ike Naar wrote:

On 2026-09-12, bart <bc@freeuk.com> wrote:

Note that the code will still have braces. I suggest a better aim >>>>>>> is to
eliminate most braces. The should be no need to ever see '} else {' >>>>>>> instead of just 'else'.

There can be a difference; for example (assume <stdio.h> included): >>>>>>
-a-a-a-a if (0) { if (1) puts("foo");-a-a else-a-a puts("bar"); }

-a-a-a-a if (0) { if (1) puts("foo"); } else { puts("bar"); }

The first line will print nothing; the second one will print "bar". >>>>>

This illustrates my point; first some Pascal:

-a-a if cond then begin s1; s2 end else begin s3; s4 end

C is the same but uses braces, and semicolons are terminators:

-a-a if (cond) { s1; s2; } else { s3; s4; }

One has 'end else begin', the other has '} else {'.

However the Pascal version can be improved; since 'then' and 'else' >>>>> can act as block delimiters:

-a-a if cond then s1; s2 end else s3; s4 end

Only the final block in a chain (eg. if-else-if) needs the 'end'
terminator. And now 'else' is by itself.

Unfortunately this doesn't transfer well to C:

-a-a if (cond) s1; s2; else s3; s4; }

The () around 'cond' are needed as the ')' separates cond and s1
(fir doesn't not appreciate this point; he thinks it is fine for
statements and expressions to run together provided that there is a >>>>> way to infer where one logically ends and the other starts).

The trouble is that lone, unbalanced } at the end.

So it would need a bigger change. But then that's what fir is
doing. (He's never going to get there, but there's no harm in
humouring him.)

what you consider problems is so siple i dont even think on it


as to ifs syntax i am yet not sure

some like this may be considered but its not much good loking
though is sorta logical

x<10 raA x++>5
-a-a-a-a-a-a-a raA-a more_than_five
-a-a-a-a-a-a-a ray less_than_six
-a-a-a-a ray do_nothing

Try: if 5 < x < 10.

why? its the same

The same as ... what?

I don't know what your example was meant to do. But if testing whether x
was in some interval, and with my example 'x' is only written once.

Otherwise you might want to look at how lots of languages do more
general pattern-matching.>

5<x<10 raA

this was not on topic so i dont understand what you mean
on this comparsions 0<=x<640 i was writing already long ago
this example was not on checking x but on if-else forms

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 9/13/2026 4:29 AM, Lane W wrote:

bart wrote:

On 13/09/2026 10:53, fir wrote:

fir pisze:

bart pisze:

It sounds like your ideal language would be APL, if is not 'clean'
and 'clear' that you're after, but 'minimal' and 'cryptic'.

The first version above is the best balance in my view. You /want/
some mixture of keywords and symbols.

In any case, in a typical program, only 1/3 of alphanumerics of
keywords; the rest will still be user-identifiers.

i gave you example - its only cryptic if you dont know what it means

consider for example french or polish language its totally cryptic
until you will learn it...

That is not your aim. That appears to be to start with a language that
you know perfectly well, but remove all punctuation, capitalisation
and structure, and half the words. But to what purpose; because you're
too lazy to type?

-a-anot to say you want to understand it without

definitions

So an APL (or J or K) program is never cryptic because all you have to
do is learn it? If only I'd thought of that!

The same applies to Assembly I guess. And machine code?

overally this discussin ended i think at least as for few months,
cant continue becouse you repeat the same things

And you keep repeating the same nonsense. What is your endpoint: a
program that can be expressed in one byte?

He wants to compress the language, metaphor a plum, into a prune that
has much reduced.

Take a source file, compress it, and show all the printable chars from
the blob? ;^)

It is the same way with a newsgroup when the warlord Lane W has
compressed all the shitheads, David Brown, Keith, bart, and the rest
except I guess the fellows who are in the mood, when they all conspire
by email to not respond to anything he writes. It is at such a time that
he declares victory. As I roll over yet another group in the 97 I have subjugated to my rule and made complacent, a tear drips from my eye. C,
such a beautiful language, yet what hypocrites such as David Brown
defending it. Really, nothing personal? I beg to differ. Under my boot,
a serpent crawls out of the skull of another victim.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Ike Naar <ike@sdf.org> writes:

On 2026-09-12, bart <bc@freeuk.com> wrote:

Note that the code will still have braces. I suggest a better aim is to
eliminate most braces. The should be no need to ever see '} else {'
instead of just 'else'.

There can be a difference; for example (assume <stdio.h> included):

if (0) { if (1) puts("foo"); else puts("bar"); }

if (0) { if (1) puts("foo"); } else { puts("bar"); }

The first line will print nothing; the second one will print "bar".

I believe bart was suggesting a language change, not offering advice
on how to program in C.

In C, the syntax for an "if" statement is:

if ( expression ) statement
if ( expression ) statement else statement

(C23 tweaks this very slightly in ways that are not relevant to
the current discussion.) Since it's defined in terms of single
statements, if you want multiple statements in a branch you need to
create one by enclosing multiple statements in braces. This also
requires a rule about which "if" a given "else" is associated with.

Many other langauges allow multiple statements where C only allows
a single statement. They typically do so by requiring a closing
delimiter matching the "if", for example "endif", "end if", "end",
or "fi". They also typically add a single token combining "else"
and "if", typically "elseif", "elsif", or "elif".

(Pascal follows the C approach, but spells "{" and "}" as "begin"
and "end".)

It's not practical to follow bart's advice (always use "else" rather
than "} else {" unless you're using some language other than C.

bart's point, I think, is that he dislikes the way C does this.

Personally, I tend to prefer the non-C delimited approach, since
it's a bit less error-prone, but both approaches are perfectly
valid and can be used cleanly and correctly with a little care.
It's not a factor I consider when deciding which language to use.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 13/09/2026 19:55, Waldek Hebisch wrote:

bart <bc@freeuk.com> wrote:

On 09/09/2026 02:59, Waldek Hebisch wrote:

I find that adding include files, creating headers, maintaining forward
declarations etc to be a complete PITA.

Apparenty you ignored first part above. So, let me expand this.
I see value in specifying interfaces. For me it is important
design information. It takes some time to get it right. Not
time to code or type. It takes time to find good design.
Writing declarations is small part of it.

Sure. But interfaces to what? To some sort of library?

And it isn't really much to do with modules. C libraries have
interfaces, usually as headers, but it doesn't have modules.

A more typical problem is organising the functions, variables, types,
enums and tables of an application into multiple modules: what goes
where; what needs to be shared.

Once you have your N modules, then that's the list the language's module scheme uses to build your app.

A formal interface would be used for external libraries, or for internal libraries where a group of modules form a private sub-program.

In my use typical import
statement imports several declarations so is even smaller issue.
I mentioned non-C project where I have about 1200 modules. There
are 1115 import statements. Note that some uses imply/are equivalent
to import, for example there is inheritance of interfaces (given
interface exports everything that its parents export plus usually some additional things), there is probably about 5 thousends of instances
of inheritance. Alternatives would involve duplicating some thousends
of declarations (probably around 10-15 thousends). The system
has about 150000 LOC (215000 wc lines).

If you have 215Kloc and 1200 modules, then you have other challenges
than a module scheme. (That's some 0.18Kloc/module on average, while my
stuff might be more like 1Kloc, and used to be nearer 2Kloc.)

But I'm surprised you only have about one import statement per file: is
it the same project-wide interface file, or is each much more specific?

Compared to total import
statements and inheritance specifications are small part. And they
are relatively trivial: cases where code compiled but import or
inheritance statements were wrong wre quite rare and they mainly
were cases of missing export or not needed import. Later re-design
may change interfaces, but I mean correctness with respect to design
at time where code was compiled. OTOH normal executable code may
compile fine but behaves completely wrong, so requires more work,

I do not think that C can do what this system is doing. But extrapolating, design in C of similar spirt would probably need say 5000 #include
lines, some hairy macros and 200000-300000 LOC. And executable part
would be much more tricky to get right.

I'm now curious as to what weird things you're doing. Is this other language/scheme one like C++, or something that you have devised?

So, I think that your problem is mostly psychological: you consider export/import info as unimportant and it is painful to you to do
work that you consider useless. I consider maintaining export/import
info as important and can do this with resonable efficiency.

As I suggested above, perhaps 'import/export' are too-strong terms for
talking about sharing between friendly modules of the same subprogram.

(A 'subprogram' is my language is one building block down from
'program', which equates to a single EXE or DLL binary. 'Module' is just
below that and that corresponds to one source file.)

Meanwhile interfaces between programs (ie. between EXE/DLL files) is
something that doesn't come up often for me; it is a different subject,
and something I would also apply automatic methods to as much as
possible. It is FFI more than modules.

Still, modern languages tend to have a module scheme, suggesting the
'flexible' C approach (I'd use the term 'prehistoric') wasn't quite enough.

I used or at least looked at several languages with module systems
or things intended to perform similar duty. You approach seem to
be unique, all other require explicit import or equivalent at least
in some (rather frequent) cases. Some languages do not support
re-export, in such case you can rightfully complain. The ones with
re-export allow forming common interface module do that number
of import statements is minimised. But this is developers choice
and apparently most prefer to import only needed things, even
though it requires more import statements.

Some even specify individual names to be imported from a module. What a
complete waste of time!

If I need 1 or 2 names from a module, then it makes sense to specify
them explicitely.

I don't see why. Unless you mean it is more important to exclude the
names you haven't listed?

Support a library or module M exports functions A - F. You'd write:

import M

then later you can write M.A() to M.F() without doing anything else.

Suppose you only need function D. In that case you just call M.D();
nothing is forcing you to call M.E() too!

If this is about not having to include those functions in the binary,
then that would be something for the language to deal with: it knows
which functions have called, and knows those are the ones to import.

Mismatched
declarations may cause troubles like crashes or wrong output
that take work to fix. Compared to that mismatches in explicit
declarations are trivial to fix. So one adds some extra work
to write and maintain declarations for benefit of better error
detection and reduction of total work.

What benefits are these? All I can see are loads of annoying errors
because you've forgotten to declare entities.

Type inference means
almost no reduction in ability to detect errors and some reduction
of work in maintaining declarations. At least in case of C and
C++ type inference optional: you can still give explicit types.
At least your description of of your module system suggest that
it is more like FORTRAN than modern type interface.

Type inference and modules are different things. Modules manage
visibility named entities including types across source files.

With my whole-program scheme, there will never be type mismatches across
the sources files of a particular program. That can only happen when interface/API info and implementation or binary are separate.

(Type inference is minimal, nothing like H-M. In any case my Modules
work the same way across two languages, one fully typed and static, the
other dynamically typed.)

Module system has other advantages over C. First, in C sane
developers use headers in consistent way, but language
does not enforce it. Typical module system enforces
consistency. Second, module interfaces can be parsed once,
avoiding problem of repeated re-parsing of C headers.

According to David Brown and Scott Lurndal, that is a non-problem!

And according to DB, reducing a large, complex mass of header files (of
external library) into one compact file 95% smaller, would be a waste of
time.

If they want, they can write what they think about this issue.

They're users who are proficient in their tools. Nothing ever seem to be
a problem - that superfast hardware and dozens of parallel cores can't
fix! I've learnt from experience that even a build time of minutes
(where the result might be a mere 1MB binary) doesn't faze them.

Oh, it's a 'one-off', or they are not curious as to why a simple task
isn't faster.

Basically they are not interested in any merits of my solutions.

Here I am stating my opinion in context of what you wrote.
One problem with C headers is that a single macro can choose
a differenet branch in a header, so you either need some sophisticated
system of dealing with conditionals or you need to re-parse
whenever any macro is defined differently than during previous

All the problems with C headers would be a big subject by itself!

With separate interface files, who writes the interface: is it the
programmer who has to duplicate what is in the implementation? (In which
case, what checks are made that it matches?)

In system that I use it is the programmer. System checks that
declaration match.

C uses the 'linkage' system for functions and variables. It uses text replication to share entities such as types, structs, enumerations and
macros. How do other language's modules cope with the latter?

(I only know about Python. My languages of course handle all those too.)

My first attempts at (modern) modules tried to do the latter, but it was
hard. For example, compile module A.m and it generates A.exp which is
the interface that can be used elsewhere via 'import A'.

But suppose A and B import each other; which is compiled first?

This I resolve with what you would call "whole program compilation".
First pass tries to recognize types. Second pass collects info
about exported functions. I use this in context of explicit interface
parts, but in fact compiler parses everthing and extracts some
information from implementation part. So in principle I could
extract interace based on some markers. After the second pass there
is normal compilation where imports use info colleded in the second
pass. This in not particularly fast, for 150000 LOC I need 3.5s
to extract the interface info. Still, it is small part of the
whole compilation which needs about 300s CPU time (about 38s
real time when using 20 cores).

This is that 215Kloc project? 300s (approx time for single core) is
pretty slow for that. What is the problem here; the language being hard
to process?

(As you know my stuff works perhaps 3 magnitudes faster, assuming your
machine is faster.

Although I am currently investigating why my C compiler takes 0.12
seconds to process some 0.5M lines of SDL3 headers when TCC takes only
0.05 seconds. I'm just curious.

An odd fact I discovered today: if SDL3 headers (86 files/82Kloc) are preprocessed, the result is only 4000 lines and 27K tokens, even though
550K lines are processed according to my compiler (but maybe that's why
it's slow).

This output is not enough to use as a new compact header; it will need #defines etc that have been stripped. But it shows the core of the API
is quite small. I will investigate further.)

I now work with whole program compilers. There, a discrete interface
file doesn't make sense and is not needed between the modules of the
same program.

Well, I want well specified interfaces between parts of the program.
With this it is much easier to decide which module is wrong (does not
comply with its interface) and consequently to fix bugs.

As I said, many of my modules are friendly. I don't care about formal interfaces. When I do, a module or several can form their own more
private group.

This makes coding much, much simpler.

Also
I have modules which can use use one of several other modules.
That is module M can use function from A, B, C, ... and it should
work correctly which each one. As long as A, B, C, ... have the
same interface I can test that M works with say A and the A, B, C, ...
in fact implement the same interface and after that expect that
M will also work with B or C. Without well specified interfaces
that would be much harder (or impossible).

When happens when A gets too big and you want to split it into A1 and
A2; will it need a new formal interface between them?

In different context, one may have collection of modules such that
some subsets form programs. That is particularly relevant for microcontrollers, where target is too small to include all available
modules. Also, different microcontrollers may need different
(alternative) hardware specific modules. In such situation you
do not want to leak hardware specific details to general modules.
And in general, you want to limit what is pulled in only to stuff
that is actually needed.

I work with a 64-bit supercomputer with huge amounts of memory. (In
other words, the second-cheapest PC in the shop.)

Still, last year I adapted my systems language to work with an emulated
Z80 system, and the module scheme still worked!

Yes, the memory is more limited, you just have less stuff in the
modules. The scheme allows for some flexibility.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

bart <bc@freeuk.com> wrote:

On 13/09/2026 19:55, Waldek Hebisch wrote:

bart <bc@freeuk.com> wrote:

On 09/09/2026 02:59, Waldek Hebisch wrote:

I find that adding include files, creating headers, maintaining forward
declarations etc to be a complete PITA.

Apparenty you ignored first part above. So, let me expand this.
I see value in specifying interfaces. For me it is important
design information. It takes some time to get it right. Not
time to code or type. It takes time to find good design.
Writing declarations is small part of it.

Sure. But interfaces to what? To some sort of library?

And it isn't really much to do with modules. C libraries have
interfaces, usually as headers, but it doesn't have modules.

If you want popular comparisons look at Modula 2 or Turbo Pascal.
Each module has interface part and implementation part. Form
outside you can only see what is in the interface part. In
particular to compile any module using A you only need interface
part of A. You can compile implementation of A later, or even
change implementataion of A _after_ you compiled users.

A more typical problem is organising the functions, variables, types,
enums and tables of an application into multiple modules: what goes
where; what needs to be shared.

You may view interface as information about what needs to be shared,
but IMO there is more to this. In badly designed program a lot
must be shared. In well designed program and assuming that problem
domain is suitable for modularization sharing is quite limited.
And frequently is is possible to replace implementation part by
quite a different thing without affectiong correctness of the
program.

To make a concrete example, I needed simple varianat of regular
expressions. In principle I could call existing library via FFI, but
that had its own problems. Since the core algorithm is quite simple
I decided to roll my own. I ended with collection of 4 modules.
One module implements a single node of automation, second one
implements matching algorithm and build automation (that is graph
of nodes) from other data. Third module provides a higher level
abstractions, representing patterns build from simpler automatons
via boolean operations. Fourth module contains a parser which
converts textual patterns to internal representation, using
operations provided by earlier modules. Together this is 452
wc lines. One may be tempted to do this a single module, but
I think that what I did have better structure: first module
essentially defines data struture (or maybe I should say data
type) and in principle this could be part of the second module.
But having module means that some things are hidden and some
are exported in nicer form. So I do not consider having this
as a separtate module as a big deal, but I think that overall
thanks to this code is a little nicer. Second module implements
core algorithm. IMO is is nice that this code is not mixed
with other parts and also it is potentially reusable in the
future. Third module implements feature that I needed, it
is something that AFAIK is not supported by standard libraries
so I would need it even if I decided to scrap the first two
modules and replace them by FFI calls to some standard library.
The actual syntax of supported patterns is confined to the
fourth module. If I needed different syntax (possibly with
different featurs set) I can provide an alternative parser
module. As you later write those are "friendly" modules
designed to work together. But each of them have reasonably
well specified responsibilities. And since responsiblity
of each module is rather narrow, each of them is simple,
almost trivial. Functionality provided by this collection
of 4 modules is not very impressive, but less trivial than
each of the involved modules.

Once you have your N modules, then that's the list the language's module scheme uses to build your app.

A formal interface would be used for external libraries, or for internal libraries where a group of modules form a private sub-program.

In my use typical import
statement imports several declarations so is even smaller issue.
I mentioned non-C project where I have about 1200 modules. There
are 1115 import statements. Note that some uses imply/are equivalent
to import, for example there is inheritance of interfaces (given
interface exports everything that its parents export plus usually some
additional things), there is probably about 5 thousends of instances
of inheritance. Alternatives would involve duplicating some thousends
of declarations (probably around 10-15 thousends). The system
has about 150000 LOC (215000 wc lines).

If you have 215Kloc and 1200 modules, then you have other challenges
than a module scheme. (That's some 0.18Kloc/module on average, while my stuff might be more like 1Kloc, and used to be nearer 2Kloc.)

Actually, having a lot of small modules makes things easy. I have
a few larger modules (one is about 3.5K wc lines and it is possible
that some are larger than that), that are harder. Actually, the
problem are interactions in bigger modules. If I could neatly
separate parts of big module I would probably split it.

But I'm surprised you only have about one import statement per file: is
it the same project-wide interface file, or is each much more specific?

As I wrote, there is inheritance which is used much more frequently
than import. And import means that all functions from imported
module may be used without qualification. That is if module A
exports function f, than after importing A I can just write 'f()'
to call 'f' (assuming it needs no arguments). In any place (without
need for import statement) I can use qualified name, that is
write 'f()$A' to call 'f' from module 'A'. There are about 8000
of such qualified calls.

Also, about 160 modules are purely interface, it makes no sense to
import them and they do not import anything. They are only used
with inheritance. About 90 are mostly interface, they provide
functions accesible via inheritance and normally are not imported.
about 400 modules work as abstract data types, that is they provide
functions to create and access various data structures.

Compared to total import
statements and inheritance specifications are small part. And they
are relatively trivial: cases where code compiled but import or
inheritance statements were wrong wre quite rare and they mainly
were cases of missing export or not needed import. Later re-design
may change interfaces, but I mean correctness with respect to design
at time where code was compiled. OTOH normal executable code may
compile fine but behaves completely wrong, so requires more work,

I do not think that C can do what this system is doing. But extrapolating, >> design in C of similar spirt would probably need say 5000 #include
lines, some hairy macros and 200000-300000 LOC. And executable part
would be much more tricky to get right.

I'm now curious as to what weird things you're doing. Is this other language/scheme one like C++, or something that you have devised?

That scheme shares some similarity to C++, but there are differences.
One thing is that at least nominaly there is very strong separation
between modules. Namely data related to a module is invisible
outside, all you can do is to call functions provided by the module.
You may guess that if that was completely true at implementation
level, then performance would be rather poor needing a lot of
function call. So there is a compromise, performance critical
functions (like array indexing) are inlined between modules.
In few rare cases one module uses low level tricks to directly
access data of other module. But in vast majority of cases the
isolation is respected. There are performance traps, but with
care performance can be quite good.

This scheme was invented by other folks in period between 1975-1985.
I have added some changes and improvements, but essential features
are preserved.

Anyway, there is string type checking and isolation between modules,
for me it makes developement much easier. There is garbage collection.
There is code reuse via inheritance and via generic coding (the
same code can work with different data types). To get similar
effects in C one would have to either use macros (to generate
variants of "the same" code for different types) or call functions
via dispatch tables. That would need extra code and would result
in weaker type checking. The code intesively uses operator and
function overloading, it would be more bulky and harder to read
without that. C++ could do some things that I need, but it seems
that it also lacks some features and AFAICS in current form could
not serve as a replacement.

So, I think that your problem is mostly psychological: you consider
export/import info as unimportant and it is painful to you to do
work that you consider useless. I consider maintaining export/import
info as important and can do this with resonable efficiency.

As I suggested above, perhaps 'import/export' are too-strong terms for talking about sharing between friendly modules of the same subprogram.

As I wrote I have very strong isolation between modules, even if
they are designed to work together. And normally I aim at clearly
divided responsibilities. So IMO 'import/export' correspond with
my reality.

(A 'subprogram' is my language is one building block down from
'program', which equates to a single EXE or DLL binary. 'Module' is just below that and that corresponds to one source file.)

Meanwhile interfaces between programs (ie. between EXE/DLL files) is something that doesn't come up often for me; it is a different subject,
and something I would also apply automatic methods to as much as
possible. It is FFI more than modules.

Still, modern languages tend to have a module scheme, suggesting the >>>>> 'flexible' C approach (I'd use the term 'prehistoric') wasn't quite enough.

I used or at least looked at several languages with module systems
or things intended to perform similar duty. You approach seem to
be unique, all other require explicit import or equivalent at least
in some (rather frequent) cases. Some languages do not support
re-export, in such case you can rightfully complain. The ones with
re-export allow forming common interface module do that number
of import statements is minimised. But this is developers choice
and apparently most prefer to import only needed things, even
though it requires more import statements.

Some even specify individual names to be imported from a module. What a
complete waste of time!

If I need 1 or 2 names from a module, then it makes sense to specify
them explicitely.

I don't see why. Unless you mean it is more important to exclude the
names you haven't listed?

Support a library or module M exports functions A - F. You'd write:

import M

then later you can write M.A() to M.F() without doing anything else.

As I wrote I can use equvalent of M.A() without import. And I find
this preferable when I need only 1 or 2 functions from a module.

Suppose you only need function D. In that case you just call M.D();
nothing is forcing you to call M.E() too!

In my case import means that functions are available without
qualification, so plain E() may call function from imported module.
And I have function overloading and partial type inference. In
effect, it is not entirely trivial to decide which function is
actually called when you write E(). Most functions either needs
arguments or produces values (or both), so calling wrong functions
almost surely is not a big problem, that is either overloading
machinery would choose the correct one, or call to wrong one will
result in type error. But still, I think that is better to limit
possible confusion and import as little as possible.

If this is about not having to include those functions in the binary,
then that would be something for the language to deal with: it knows
which functions have called, and knows those are the ones to import.

No, that is purely compile time thing, that is controling what
may be called by limiting visibility.

Mismatched
declarations may cause troubles like crashes or wrong output
that take work to fix. Compared to that mismatches in explicit
declarations are trivial to fix. So one adds some extra work
to write and maintain declarations for benefit of better error
detection and reduction of total work.

What benefits are these? All I can see are loads of annoying errors
because you've forgotten to declare entities.

I remember maybe one or two cases when wrong function was called
and that passed type checking. Without control of visibility
such cases would be much more frequent. Note: without overloading
such cases would normally be detected as mismatched definitions,
unless somebody adds extra rules that say last import wins.
But for me overloading and type interface are large benefits
and comparably need to control visiblity is modest cost.

More generally, I also worked with dynamic languages where one
simply calls a function and types of arguments are only checked
on use. IME code in such languages needs a lot of testing, much
more than with type checking. That is without type checking
it is too easy to ship code which calls a function with argument
of wrong type. Clearly to check types compiler must know them.
And absent total type reconstrution (like in ML), one needs to
declare types of arguments and return type of functions.
So I hope that is part is clear.

You may doubt necessity of having duplicate declaration in the
module interface. In principle compiler could do all needed
checks having only single declaration. But compilers that I
use need declaration in interface part. And when reading code I
actually prefer to have both declarations. Namely, when looking
at interactions between modules I look at interface parts and
want to see relevant declarations there. When working on inner
part of module I want relevant info there. For example, I disliked
standard Pascal rule that forward declaration contained all
info, but corresponding defintion contained just function name
skipping arguments types and names. For me extra effort during
reading, due to extral lookup for missing info meant more work
compared to cut-and-paste needed to duplicate function header.

Type inference means
almost no reduction in ability to detect errors and some reduction
of work in maintaining declarations. At least in case of C and
C++ type inference optional: you can still give explicit types.
At least your description of of your module system suggest that
it is more like FORTRAN than modern type interface.

Type inference and modules are different things. Modules manage
visibility named entities including types across source files.

Sure. I mentioned type inference to illustrate that approach may
change and if compiler can infer needed information, then languages
may depend on this saving programmer work. But gross rules like
firt letter rule of old FORTRAN (or implicit int from traditional
C) are unsatisfactory. And when talking about modules your
rule "all modules are visible" looks more like old gross rules and
unlike inference process.

With my whole-program scheme, there will never be type mismatches across
the sources files of a particular program. That can only happen when interface/API info and implementation or binary are separate.

AFAICS there is possibilty of calling wrong function (if there are
2 functions having the same name and argument types). And with
type inference there is even some possibility of getting wrong
type: compiler calls function giving wrong result type and then
passes this type to a different function. Of course, since you
have function declarations compiler can ensure that passed type is
appropriate for called function. But that still leaves some
possiblity of calling wrong function, especially if programmer
uses only a handful of types and reuses function names.

(Type inference is minimal, nothing like H-M. In any case my Modules
work the same way across two languages, one fully typed and static, the other dynamically typed.)

Module system has other advantages over C. First, in C sane
developers use headers in consistent way, but language
does not enforce it. Typical module system enforces
consistency. Second, module interfaces can be parsed once,
avoiding problem of repeated re-parsing of C headers.

According to David Brown and Scott Lurndal, that is a non-problem!

And according to DB, reducing a large, complex mass of header files (of
external library) into one compact file 95% smaller, would be a waste of >>> time.

If they want, they can write what they think about this issue.

They're users who are proficient in their tools. Nothing ever seem to be
a problem - that superfast hardware and dozens of parallel cores can't
fix! I've learnt from experience that even a build time of minutes
(where the result might be a mere 1MB binary) doesn't faze them.

Oh, it's a 'one-off', or they are not curious as to why a simple task
isn't faster.

Basically they are not interested in any merits of my solutions.

Here I am stating my opinion in context of what you wrote.
One problem with C headers is that a single macro can choose
a differenet branch in a header, so you either need some sophisticated
system of dealing with conditionals or you need to re-parse
whenever any macro is defined differently than during previous

All the problems with C headers would be a big subject by itself!

With separate interface files, who writes the interface: is it the
programmer who has to duplicate what is in the implementation? (In which >>> case, what checks are made that it matches?)

In system that I use it is the programmer. System checks that
declaration match.

C uses the 'linkage' system for functions and variables. It uses text replication to share entities such as types, structs, enumerations and macros. How do other language's modules cope with the latter?

Typical approach is to have compiled version of interface. That
requires some method to write such info to files. IIUC GNU C
precompiled headers use (or used) crude but simple method: they
just dumpled memory area containing intenal compiler representation
of the header. This is simple and fast, but any tiny mismatch could
lead to error, so this mechanizm has serious limitations and is
unsuitable for use with modules. GNU Pascal walked internal tree
of nodes, keeping visted nodes in a hash table to make sure that
needed node is stored exactly one. During storing each node was
assigned integer identifier and all pointers were repleaced by
identifiers (numbers) of taget node. Reading worked in reverse:
it re-build nodes in memory, replacing numeric indentifiers by
pointers.

The system I mentioned above writes interface information in textual
form, but it is easier to parse and more explicit than source code.

(I only know about Python. My languages of course handle all those too.)

My first attempts at (modern) modules tried to do the latter, but it was >>> hard. For example, compile module A.m and it generates A.exp which is
the interface that can be used elsewhere via 'import A'.

But suppose A and B import each other; which is compiled first?

This I resolve with what you would call "whole program compilation".
First pass tries to recognize types. Second pass collects info
about exported functions. I use this in context of explicit interface
parts, but in fact compiler parses everthing and extracts some
information from implementation part. So in principle I could
extract interace based on some markers. After the second pass there
is normal compilation where imports use info colleded in the second
pass. This in not particularly fast, for 150000 LOC I need 3.5s
to extract the interface info. Still, it is small part of the
whole compilation which needs about 300s CPU time (about 38s
real time when using 20 cores).

This is that 215Kloc project? 300s (approx time for single core) is
pretty slow for that. What is the problem here; the language being hard
to process?

There are some challenges, that like type inference and function
overloading. Actually, handling of types is pretty complex.
Types have parameters and various things, like which functions
are really exported depends on parameters. So to decide if a
call is legal compiler may be forced to do rather complex reasoning.
But AFAICS the main trouble is simple-minded apprach to compilation.
Namely to allow overloading compiler in sequence tries all visible
functions with given name. For each possiblity it tries to compile
argument getting right types. This process is recursive. In
effect, a subexpression of a complex expression may be compiled
multiple times (exponentially many in size of the whole expression).
Usually expressions are resonably small and good possibility is
found relatively early. But 5 seconds for a single line is
possible. In addition compiler uses linear search in symbol table.
This is caused by complexity of maintaining symbol table in other
forms: during recursive search things get inserted in rather irregular
way and removal depends on linear structure. Actually, I added
a hash table that handles most searches, but some searches really
need linear search and they take most time.

Getting rid of recursion and implied by this multiple re-compilation
probably would give 3-5 times faster compilation (and hopefully
would eliminate really bad cases). If things could be simplified
so that hash table is enough, that probably would double speed.
Once that is handled other things would requre attention. But
it does not make much sense to fight for small speedups in other
places when biggest issues (that is recursive compilation and
linear search are unresolved). And that require substantial
rework. Even after rework compiler is unlikly to be as fast as
yours. Namely overloading and type inference means to at any
compilation step there may be multiple possiblities. I do not
know how many, but 2-3 are likely per average call site and
in more compilcated expressions this may compound, maybe to
tens, maybe to thousends. So to find correct types compiler
will have to do more work than compiler without such a
feature. As I wrote, I do not know how much, but 3 times
more work is probably too optimistic, someting between 10 and
20 is more liekely and really hope that worse cases are rare
so that they do not affect average too much.

Also, compiler is using higher level data structures that
has its own costs. Parsing this 215K wc lines takes 1 second,
while it should be possible to do this in 0.1 second. But
again, before other issues are handled relative gain from
faster parser is too small to bother (I may speed up parser
if I need to reorganize it to implement some extra feature).

BTW: It is hard to compare compile speed in longer time because
machines got faster. But when I started my work build needed
something like 2.5 hours, so now is way faster. Some speedup
comes from Makefile-s (skipping useless recompilation). Most
from faster computers. But factor between 2 and 3 probably is
due to may work.

(As you know my stuff works perhaps 3 magnitudes faster, assuming your machine is faster.

Although I am currently investigating why my C compiler takes 0.12
seconds to process some 0.5M lines of SDL3 headers when TCC takes only
0.05 seconds. I'm just curious.

An odd fact I discovered today: if SDL3 headers (86 files/82Kloc) are preprocessed, the result is only 4000 lines and 27K tokens, even though
550K lines are processed according to my compiler (but maybe that's why
it's slow).

When I need to look at preprocessed files I frequently see a lot of
blank lines, so I am not surprised that headers get smaller. At first
glance 4000 lines after preprocessing looks too small, but maybe it
is real.

This output is not enough to use as a new compact header; it will need #defines etc that have been stripped. But it shows the core of the API
is quite small. I will investigate further.)

At some time I did a little work on Mac OS API. There was about
220 tousends symbols, of which something like 200 tousends where
various magic constants. So, maybe bulk od SDL3 headers is due
to defiend constants?

I now work with whole program compilers. There, a discrete interface
file doesn't make sense and is not needed between the modules of the
same program.

Well, I want well specified interfaces between parts of the program.
With this it is much easier to decide which module is wrong (does not
comply with its interface) and consequently to fix bugs.

As I said, many of my modules are friendly. I don't care about formal interfaces. When I do, a module or several can form their own more
private group.

This makes coding much, much simpler.

It seems that our coding style and methodology differ. I find it
simpler with specified interfaces. OK, I do varios small or ad
hoc things and in such case I do not bother much with interfaces.
But if code is intended to live longer and fit into something
bigger, then I care much about interfaces. And IMO in longer
term that is easier.

Also
I have modules which can use use one of several other modules.
That is module M can use function from A, B, C, ... and it should
work correctly which each one. As long as A, B, C, ... have the
same interface I can test that M works with say A and the A, B, C, ...
in fact implement the same interface and after that expect that
M will also work with B or C. Without well specified interfaces
that would be much harder (or impossible).

When happens when A gets too big and you want to split it into A1 and
A2; will it need a new formal interface between them?

Yes. Let me add that that I am not too worried by biggish piece
of code. Say, I would probably keep 20000 lines in a single file
if I could not find reasonably natural way to split it into pieces.
OTOH, if there is natural division into parts which are 100 lines
each, then I probably would split it into such small parts.

Let me add, that in C if file gets really too big, but there is
no natural split into modules, then I may accept a multi-file
module. But this is not an option if a language implementation
assumes that file=module.

In different context, one may have collection of modules such that
some subsets form programs. That is particularly relevant for
microcontrollers, where target is too small to include all available
modules. Also, different microcontrollers may need different
(alternative) hardware specific modules. In such situation you
do not want to leak hardware specific details to general modules.
And in general, you want to limit what is pulled in only to stuff
that is actually needed.

I work with a 64-bit supercomputer with huge amounts of memory. (In
other words, the second-cheapest PC in the shop.)

Me too. But I work with a few architectures: x86_64, aarch64 and
riscv64. The only realy fast and big is a PC, but the other are
useful too. Actually, few days ago I worked on code generators
for a different compiler than discussed above, targeting aarch64
and riscv64.

Still, last year I adapted my systems language to work with an emulated
Z80 system, and the module scheme still worked!

Yes, the memory is more limited, you just have less stuff in the
modules. The scheme allows for some flexibility.

I am not trying to have native compiler for such machines. Rather,
for microcontrollers I use cross compilers. Certainly, I could have
some fun trying to create native compiler for such machine, but
I have enough fun with what I am doing and I am trying to avoid
starting too many projects that I will not be able to finish due
to lack of time.
--
Waldek Hebisch
--- Synchronet 3.22a-Linux NewsLink 1.2