A Language Design Analysis of HolyC (2019) | Hacker News Reader

A Language Design Analysis of HolyC (2019)

harrison.totty.dev

82 pointsd-s13 comments

The article gets something wrong about C.

"U0 is essentially void but with zero size. In regular C, void is actually considered a Unit Type and thus when computing sizeof(void) in GCC, you will find that it resolves to 1."

In C, void has no size; the expression sizeof (void) is invalid. There are no values of type void.

gcc, as an extension, permits pointer arithmetic on pointers to void. An unfortunate side effect of this extension is that it treats sizeof (void) as 1. If you compile with "-pedantic-errors", it will reject that expression.

What's even more insane than an elephant with blue eyes?

>There is no type checking what-so-ever.

See also http://www.codersnotes.com/notes/a-constructive-look-at-temp.... What impresses me most is how integrated the whole system is, e.g.:

> TempleOS has its own programming language, HolyC. The whole operating system is written in it, except for x64 assembly in the lower-level parts. Perhaps unexpectedly, the same language is also used for the shell. … There is no built-in calculator application, because the shell itself is one. Just enter 5+7 on the command line and you'll get the answer. You can even go further than this and use the shell as a REPL to build entire programs in.

> TempleOS's unified hypertext really shines when presented in the shell. From the command-line, you can call Uf("Foo") to disassemble a function, and each symbol printed will be hyperlinked in the shell window. Click on it to go to the source. objdump can't do that.

> The most notable feature of TempleOS is its ubiquitous hypertext system, DolDoc. This is the foundation for the both the shell and the text editor. Unlike Unix which represents everything via plain-text, everything in Temple is stored in DolDoc format … You can store images (and even 3D meshes) directly into documents. You can put macros in there: hyperlink commands that run when you click on them. So if you want to build a menu or launcher, you just make a new text document and put links in it.

And so on.

Sounds a lot like Lisp-y stuff, but done with a significantly lower level c-like language.

Yes, that's how I'd put it. OP is not really a 'language design analysis' so much as a 'syntactic sugar roundup'.

The interesting parts of HolyC is that it is moving C towards a Lisp-like, and Terry seemed to be reinventing it independently? At least, his explanation for not having #defines misses why, besides 'just not liking it': you don't need #defines (which are a very poor man's macro), when you have implemented compile-time computation, which can give you real macros (pass in an arbitrary string to an arbitrarily complicated function to interpret & compile it into some HolyC).

For variadic functions, what type is the built-in 'argv' variable?

I think this is answered by the "Misc Features & Quirks" bullet point:

There is no type checking what-so-ever.

Sure, but the compiler at least needs to know it's size, right?

Given the type discipline, I assume it would type to the equivalent of void **

> The stack does not grow because HolyC does not utilize virtual memory.

How does this work?

memory is identity mapped in templeos. so page faults are meaningless.

that statement is false though, because paging is mandatory in long mode. all memory accesses are virtual memory accesses.

If all memory is identity mapped, how does one program cooperate with another absent OS intervention? Can memory corruption happen when one process accidentally writes in the address space of another? What about overflows?

yes

the whole os is one address space

Reply on news.ycombinator.com