flaviusb · October 6, 2024 00:20
diff --git a/non-C abi noodling.txt b/non-C abi noodling.txt
 https://duriansoftware.com/joe/type-erased-generic-functions-for-c:-a-modest-non-proposal
 https://yosefk.com/blog/i-want-a-struct-linker.html

 Build time vs run time
 - Macros via staging (at build time)

 the struct linker idea can be taken further
 fixup directives and fixup locations, to allow for more than just 'add cases to a struct or enum'.
 Should be able to use it for 'semi-generic' functions etc as well - like, a kind of semi-monomorphisation when added to some complicated lto / linker scripts
 dlopen become difficult though - maybe do something with 'late initialisation' or something, so you can mark sections to be linked and runnable after some stuff has been done, and then instead of dlopen you can use 'add link' and then 'make into executable image, and potentially bring into address space etc', with some kind of 'here is how we fixup symbols for that, and where we throw a condition if trying to jump into an unrealised sub-image'

 stack discipline fn
 coro
 inside out

 function and coroutine and closure pointers that are callable / etc

 functorial modules

 Something about symbol/name lookup, versions, functoriality, fixups
 Something about runtime type information / etc

 A way to do 'rich generics' which is slower / etc, goes through vtables and name mangling and  extra linker shit etc
 → This can possibly be on a 'per language' basis, require an extra runtime, etc etc
 → You can have multiple in a single .so
 → You can also have the parts of the .so which don't rely on that, which you can use 'raw'
 → Something something Meta-Object Protocol

 Would need Rust's borrow checker or equivalent though - can we do this with separate compilation like this?
 Or even a weaker thing, like a way to say 'you/we/they/same-as-whatever-x-does have to handle allocation/deallocation'
 Or a stronger thing, like 'here is our semi-ring adjoint modal logic'
 Destructors
 Signals
 Async

 Learn lessons from Windows SEH and CL 'Conditions' and non-local return and 'DWARF' and 'gcc personalities'


 fixed size, may be available in hardware, otherwise software: uN, iN, flN, fiN, bool, fmN_M (the 'tensor of small floats which share a mantissa' representation)
 platform specific size: usize, isize, item_pointer, function_pointer, closure_pointer, coroutine_pointer
 sum (eg discriminated union), product (eg struct), 'multiple interpretation' (eg union)

 executable image, shared object, object, .a, ... can we do all of them as header, section* {header, data, index}, index..., with different headers and sections and so on, but overall the same logical structure?

 [T; N], [T; N, M, ...], +-*/<>=∨∧¬≠ pow_n log_n root_n -> 
 on stack, on heap
 in, out, inout, multiple return
 inner name:outer name for args; either one or both can be _ for positional
 args can be ? (for optional), * (for zero or more), or + (for one or more)

 Way to do binary layout of objects
 Way to do 'generic parameters' which can be preconditions etc
 Look up what swift can do for optional arguments, varargs, varstructs, default args, constructors, destructors, getters and setters, runtime and compile time introspection (not just of types, names symbols, but also things like memory/allocation, pages, etc)


 lua alike for embedding, with ... as embedder ABI, plus meta-lua alike for staging metaprogramming / exposing more stuff at the ABI level

 ---

 Maybe:
 - define a way to define layout + ~interpretation
 flat [] with potential dimension/s, pointer, direct incorporation
 generic type (when inside a scope where a thing is generic, ...; but you can directly use pointing and so on, as they don't depend on layout), 'unknown layout'
 sum (discriminated union or labelled sum), product (tuple or struct), union (eg 'it could be one of these things, who knows?' - the 'one of these I guess' quantifier)
 function, closure, environment (related to closure, eg the capture), coroutine, state-machine (related to the coroutine), coclosure (a closure that can yield, with a state and an environment)

 unknown with size T and alignment U

 controls for heap, stack, 'MMIO'/etc

 all names are either
 (with word size x) a u16 of the length followed by that many words of bits, written length:contents. The length is a part of the name; zero padding is significant. Eg 1:0, 2:0, 3:0 etc are all different names.
 or some tbd text representation
 Namespaces exist and can be nested etc. Namespaces are written with a '.', so 1:a2.2:fff2 is a name, which is distinct from eg 1:fe.2:fff2
	https://duriansoftware.com/joe/type-erased-generic-functions-for-c:-a-modest-non-proposal
	https://yosefk.com/blog/i-want-a-struct-linker.html

	Build time vs run time
	- Macros via staging (at build time)

	the struct linker idea can be taken further
	fixup directives and fixup locations, to allow for more than just 'add cases to a struct or enum'.
	Should be able to use it for 'semi-generic' functions etc as well - like, a kind of semi-monomorphisation when added to some complicated lto / linker scripts
	dlopen become difficult though - maybe do something with 'late initialisation' or something, so you can mark sections to be linked and runnable after some stuff has been done, and then instead of dlopen you can use 'add link' and then 'make into executable image, and potentially bring into address space etc', with some kind of 'here is how we fixup symbols for that, and where we throw a condition if trying to jump into an unrealised sub-image'

	stack discipline fn
	coro
	inside out

	function and coroutine and closure pointers that are callable / etc

	functorial modules

	Something about symbol/name lookup, versions, functoriality, fixups
	Something about runtime type information / etc

	A way to do 'rich generics' which is slower / etc, goes through vtables and name mangling and extra linker shit etc
	→ This can possibly be on a 'per language' basis, require an extra runtime, etc etc
	→ You can have multiple in a single .so
	→ You can also have the parts of the .so which don't rely on that, which you can use 'raw'
	→ Something something Meta-Object Protocol

	Would need Rust's borrow checker or equivalent though - can we do this with separate compilation like this?
	Or even a weaker thing, like a way to say 'you/we/they/same-as-whatever-x-does have to handle allocation/deallocation'
	Or a stronger thing, like 'here is our semi-ring adjoint modal logic'
	Destructors
	Signals
	Async

	Learn lessons from Windows SEH and CL 'Conditions' and non-local return and 'DWARF' and 'gcc personalities'


	fixed size, may be available in hardware, otherwise software: uN, iN, flN, fiN, bool, fmN_M (the 'tensor of small floats which share a mantissa' representation)
	platform specific size: usize, isize, item_pointer, function_pointer, closure_pointer, coroutine_pointer
	sum (eg discriminated union), product (eg struct), 'multiple interpretation' (eg union)

	executable image, shared object, object, .a, ... can we do all of them as header, section* {header, data, index}, index..., with different headers and sections and so on, but overall the same logical structure?

	[T; N], [T; N, M, ...], +-*/<>=∨∧¬≠ pow_n log_n root_n ->
	on stack, on heap
	in, out, inout, multiple return
	inner name:outer name for args; either one or both can be _ for positional
	args can be ? (for optional), * (for zero or more), or + (for one or more)

	Way to do binary layout of objects
	Way to do 'generic parameters' which can be preconditions etc
	Look up what swift can do for optional arguments, varargs, varstructs, default args, constructors, destructors, getters and setters, runtime and compile time introspection (not just of types, names symbols, but also things like memory/allocation, pages, etc)


	lua alike for embedding, with ... as embedder ABI, plus meta-lua alike for staging metaprogramming / exposing more stuff at the ABI level

	---

	Maybe:
	- define a way to define layout + ~interpretation
	flat [] with potential dimension/s, pointer, direct incorporation
	generic type (when inside a scope where a thing is generic, ...; but you can directly use pointing and so on, as they don't depend on layout), 'unknown layout'
	sum (discriminated union or labelled sum), product (tuple or struct), union (eg 'it could be one of these things, who knows?' - the 'one of these I guess' quantifier)
	function, closure, environment (related to closure, eg the capture), coroutine, state-machine (related to the coroutine), coclosure (a closure that can yield, with a state and an environment)

	unknown with size T and alignment U

	controls for heap, stack, 'MMIO'/etc

	all names are either
	(with word size x) a u16 of the length followed by that many words of bits, written length:contents. The length is a part of the name; zero padding is significant. Eg 1:0, 2:0, 3:0 etc are all different names.
	or some tbd text representation
	Namespaces exist and can be nested etc. Namespaces are written with a '.', so 1:a2.2:fff2 is a name, which is distinct from eg 1:fe.2:fff2
No results found