@ekaitz_zarraga

Several reasons.

First, as you know, I care a lot about the auditatability of software.

I'm also much curious about RISC-V, but I hadn't time to study it despite it looks much cleaner than x86_64.

Finally, these weeks I'm overwhelmed by work and family and cannot hack much for fun, and your text did a good job to remind me that fun.

Thanks. 😉

@ekaitz_zarraga

Thanks Ekaitz, you made my day!

@ekaitz_zarraga can you pass this link to @ondiz, I'm pretty sure she would like it.

It was one of the song of my youth (despite being way older than me): https://iteroni.com/watch?v=VMvRjINvMc4

@ekaitz_zarraga What I have in mind would be a function that take a string and return an AST. And then functions to traverse/validate/pattern match such AST.

It would not need a whole Turing complete language (and thus it should NOT be so), but could be more readable than --with-this=that -xcfs or the like.

AND the shell could do interesting things with the AST before passing to the command.

@ekaitz_zarraga Said this way, I can stop #Jehanne and redirect the home page to #Oberon! 😄

@ekaitz_zarraga

Probably Wirth was far ahead of... OUR times.

@ekaitz_zarraga technically speaking, that's true for any operating system (it is at least for #Jehanne and #Plan9): the program image of a program is cached so that already faulted page won't be load twice (unless there's high memory pressure and images are discarded).

This is a plain advantage of actual binaries over interpreted stuff, I think. And actually it's not easy to achieve outside kernel without an always running virtual machine.

@ekaitz_zarraga I mean: what if instead of "argc" and "argv" you had "length" and "program" where program was just a string to be interpreted in your specific (but very simple and conventional) language?

What if the shell could apply macro to commands' "programs" before calling exec()?

And what if the syntax was both homoiconic and pythonic?

Yes... I should sleep more... but it sounds VERY interesting in my head.

@ekaitz_zarraga a cheap alternative to a better solution

At times I wonder if command line arguments are half thought surrogates for a small interpreter in the standard library.

I wonder how life would be if every single command would implement his own mini language and exec() would take a string to be interpreted instead of an array of... arguments.

Such interpreter would likely be a sort of lisp (but veeery minimal..), and probably so would be the shell (but a bit more powerful).

Such approach would have interesting impacts on command line programs and general terminal UX.

I would not expect much fuss for such change kernel side.

I wonder if anybody else explored such approach (except on Lisp Machines, obviously)

@ekaitz_zarraga

"If it cannot be read and completely understood in a month, it's broken beyond repair."

My new mantra in #FreeSoftware development.

@codewiz @yaaps @casastorta

@ekaitz_zarraga @theruran

AFAIK they are provided by the C library (and usually also depends on the target architecture and os)

@ekaitz_zarraga they basically setup things that must occurs once just after a program exec()uted starts, like initializing the c library.

But the only thing that crt0.s HAVE to do is to setup argc and argv and then call main() (in Jehanne it calls __jehanne_libc_init that will call main)

@ekaitz_zarraga

Maybe the crt0.s and friends here might be useful (but they are x86_64 and specific of Jehanne) https://github.com/JehanneOS/jehanne/tree/master/sys/src/lib/jehanne/amd64

@ekaitz_zarraga Btw, I managed to cross compile cat.c from Linux to #Jehanne with TinyCC and run it on Jehanne.

This means that, to some extent, static linking works.

```tcc cat.c -m64 -nostdinc -nostdlib -g -I$JEHANNE/sys/include -I$JEHANNE/arch/amd64/include -L$JEHANNE/arch/amd64/lib $JEHANNE/arch/amd64/lib/crt* -ljehanne -static -Wl,-section-alignment=1000```

I had to modify tccelf.c to use _main instead of _start as the elf starting point.

Tricky.And a very little step forward (cat.c is very simple)

But a little hope.

@ekaitz_zarraga

I know nothing about it.

I've just found it on suckless.org among the software that rocks.

Yet seems to support amd64 and even run on plan9

@ekaitz_zarraga

Did you look at https://git.simple-cc.org/scc/file/README.html

The website it so minimalist it's hard to do anything but contact the developers: https://www.simple-cc.org/

You know @ekaitz_zarraga?

I'm trying #TinyCC! 😉

I gave a look to all the compilers at http://suckless.org/rocks/ but apparently #tcc is the most mature and the only one completelly self-sufficient.

BUT.

I do not know.

What it I restart from #9front?No ELF. No #POSIX. No... shit.

It took a huge amount of work to do all this in #Jehanne but... why going after so much complexity? Why not just restart from scratch?

Give a look at this:https://gcc.gnu.org/pipermail/gcc/2021-April/235367.html

Relying on #GNU (and on US-based software) is becoming a huge hazard.

Or more precisely, it's just proving to be such hazard and we were to naive to realize before.

We need to rebuild everything from scratch, anything that cannot be completely rebuilt in a month must be rewitten.

So what's the point of compatibility?

@ekaitz_zarraga

I'm not so deep into electronics and virtual machines, but what I have in mind right now is something like a #scheme based on #fexprs (like Kernel style languages) but with a #python-like #homoiconic syntax (early python, no syntactic sugar whatsover).

Homiconicity is important because people need to learn that data is code and code is data.

Oberon has a great simplicity, it could be a good alternative to an Kernel-style but his syntax is not readable on first sight nor homoiconic.

But to be readable on first sight it has to build on top of few orthogonal existing human language conventions.

For example, instead of "include" or "import" or "using" and so on, you would include external definitions through something like "KNOWING", meaning that to understand what a piece of code will do, you have to know what the imported files do.

Just like with human #knowledge, when we build on top of what was already written by those before us.

And to contextualize, you would always use /, not ".", ":", "->".

And maybe we should have a multilanguage programming language as we do in Europe, not just mindless adopting English.

It's time to go forward.

@ekaitz_zarraga

I'm not sure.

My trust has been betrayed so many times in these years by (those I thought were) #FreeSoftware projects... I do not know who to trust now.

#Harvey, #Mozilla, #GCC...#Google corrupts everything it touch... and now its employees also created the #Plan9 foundation.

There MUST be a way out, but I cannot see it right now.

GCC taught me a new valuable lesson, though.

A new operating system is not enough. A new protocol is not enough either.

We need a new programming language that can be read and understood by literally everybody on first sight.