4 ms·
Avoiding this hairy problem was why I went[1] with a more verbose and more alien-looking -- but much more regular -- s-expression syntax for what is still exact
by akkartik 10y ago
Avoiding this hairy problem was why I went[1] with a more verbose and more alien-looking -- but much more regular -- s-expression syntax for what is still exactly a C type system:
number
(address number)
(address address number)
(address array character)
(map (address array character) (list number))
(function number -> number)
etc. For simple types you can replace brackets with colons:
address:array:character
But you have full expressiveness if you need it.
[1] https://github.com/akkartik/mu https://github.com/akkartik/mu
- bluetomcat 10y agoIMHO, C's type system is quite orthogonal but is let down by the confusing declarator syntax. I designed my own experimental statically-typed language which basically inherits the C type system, but uses a "human-oriented" declaration syntax: a: int; // int a p: ptr(int); // int *p q: ptr(ptr(long)); // long **q arr: int[20]; // int arr[20] arrp: ptr[20](int); // int *arrp[20] parr: ptr(int[20]); // int (*parr)[20] fp: fptr(a: int, b: int): long; // long (*fp)(int a, int b) https://github.com/bbu/quaint-lang https://github.com/bbu/quaint-lang
- akkartik 10y agoOoh, Quaint looks very interesting. I think there's a lot of overlap with my Mu project, beyond these minor syntactic decisions. Lots of room for compare and contrast, and for sharing and stealing ideas :)