StudioInfinity/dyna3
2
0
Fork 1
Code Issues 44 Pull requests Projects 2 Releases 2 Wiki Activity Actions

Update Coding environment

Glen Whitney 2025-03-19 04:00:50 +00:00
parent 305215680f
commit 53630f6707
1 changed files with 7 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
Coding-environment.md

@ -1,5 +1,12 @@
We're currently developing Dyna3 in Rust, with a Civet-like [syntax unmangler](https://code.studioinfinity.org/glen/husht) on the back burner. We're currently developing Dyna3 in Rust, with a Civet-like [syntax unmangler](https://code.studioinfinity.org/glen/husht) on the back burner.
#### Heterogeneous collections
The question came up in a recent meeting about how to handle a collection of different sorts of Elements in an Assembly, or Regulators, etc. A bit of web searching reveals that the two main ways to do this are with enums (more appropriate when the list of alternatives is relatively small, similar, and not too likely to need lots of extension), or with (dynamic) "trait objects". In other words, if you define a trait, and have (possibly completely disparate in a concrete sense) a number of types that implement that trait, then you can treat pointers/references to entities that implement that trait as a uniform type and put them in collections, and Rust will autogenerate a "vtable" of functions to call the appropriate implementation on each at runtime when you call the trait methods through such a pointer/reference. In other words, we can define the interface(s) that Elements and Regulators support, and then have as many different implementations of those as we like, and still use them interchangeably through the corresponding "trait objects". A decent, albeit quite old now, reference on this seems to be [this blog entry](https://blog.rust-lang.org/2015/05/11/traits.html). Not sure if recent language developments have created better takes on some of the things we might want to do along these lines.
-----
(The remainder of this page includes our early language-choice notes.)
An early proposal for an implementation language was Nim, which has a well-developed static type system, with generic functions and operator overloading, and a clean mostly brace-free syntax. It compiles to C, C++, and JavaScript, and has foreign function interfaces for all three. There is a third-party direct-to-WebAssembly compiler using LLVM that was active not too long ago. So this seems like a promising choice and likely to be the way to go unless some issue or better alternative pops up. An early proposal for an implementation language was Nim, which has a well-developed static type system, with generic functions and operator overloading, and a clean mostly brace-free syntax. It compiles to C, C++, and JavaScript, and has foreign function interfaces for all three. There is a third-party direct-to-WebAssembly compiler using LLVM that was active not too long ago. So this seems like a promising choice and likely to be the way to go unless some issue or better alternative pops up.
However, a single program cannot call both C/C++ and JavaScript. Dyna3 might consist of multiple programs, though, that somehow call each other, so it might be possible to use both external JavaScript and C++ libraries in the overall project -- I am not sure. However, a single program cannot call both C/C++ and JavaScript. Dyna3 might consist of multiple programs, though, that somehow call each other, so it might be possible to use both external JavaScript and C++ libraries in the overall project -- I am not sure.