[HN Gopher] A Language Design Analysis of HolyC (2019)
       ___________________________________________________________________
        
       A Language Design Analysis of HolyC (2019)
        
       Author : d-s
       Score  : 65 points
       Date   : 2023-04-16 12:48 UTC (10 hours ago)
        
 (HTM) web link (harrison.totty.dev)
 (TXT) w3m dump (harrison.totty.dev)
        
       | bradrn wrote:
       | 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.
        
         | alephaleph wrote:
         | Sounds a lot like Lisp-y stuff, but done with a significantly
         | lower level c-like language.
        
       | _kst_ wrote:
       | 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.
        
       | hexane360 wrote:
       | For variadic functions, what type is the built-in 'argv'
       | variable?
        
         | qsort wrote:
         | I think this is answered by the "Misc Features & Quirks" bullet
         | point:
         | 
         |  _There is no type checking what-so-ever._
        
       | shrimp_emoji wrote:
       | What's even more insane than an elephant with blue eyes?
       | 
       | > _There is no type checking what-so-ever._
        
       | jordan_bonecut wrote:
       | > The stack does not grow because HolyC does not utilize virtual
       | memory.
       | 
       | How does this work?
        
         | lamp987 wrote:
         | 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.
        
       ___________________________________________________________________
       (page generated 2023-04-16 23:01 UTC)