D Profiles Idea
Mensikov
mensikovk817 at gmail.com
Sat Jul 20 23:29:57 UTC 2024
I have an idea. Due to the abundance of D capabilities, I propose
to introduce the concept of D profiles to the community. In D,
you can write firmware for a microcontroller, an OS, a web
server, scripts, a vst plugin, and a compiler. All these niches
have different requirements from the programming language. We
already have a betterC mode, but what if we introduce a more
understandable gradation? Well-defined subsets, let's say. We
call these subsets profiles. With these profiles you can better
search for the required packages in dub. Let's say I have a
system profile, and it will be possible to filter all packages by
this request. A system profile may have requirements not only for
the absence of GC, but also for the API in general, for example,
to be closer to a low level. Or I have a script profile, I can
use both system and script profiles. This will also allow
language developers to see the weaknesses of specific profiles
and introduce features for them. You can build std like a
pyramid, with a system profile at the bottom, and a managment
profile based on it, for example.
Here is the list of profiles I suggest:
CompileTime profile. This profile is the most universal, since it
does not affect runtime in any way.
System profile. This profile uses a DOD (data oriented design)
approach. Minimum classes, delegates. Error handling via values.
Data is not live, scope(exit) instead of destructors. Using
std.sumtype. If it is a library, full dip1000 support. If it is a
library, std.experimental.allocators are fully supported. Can
call gc code at higher levels, so the nogc attribute is not
required. The code will have a lot of boilerplate around memory
management and error handling, just like in C or Zig.
Application profile. Classes and interfaces are already available
in this profile. Structures have raii. Garbage collector is fully
accessible. Processing through exceptions is possible. Support
for OOP and FP paradigms. There may be some kind of runtime
reflection. Totally @safe.
Script profile. It mainly differs in its API in the libraries. It
should be simple and flexible. This can be used as 50 line
scripts for image processing, parsing, data analysis, conversion.
Maybe it’s a library that parses a binary file based on UDA (like
imhex patterns). This could be a library for prototyping
something. Data visualization, plotting, etc. That is, what
Python is used for. Perhaps the compiler will need support for
parsing a module simply as a main function. Perhaps a selective
level of optimization is needed (O2 dependencies, O0 script). You
need a fast linker, or the ability of a compiler to link the code
in jit and execute it right here.
What do you think? Should we split D into 3 languages with a
common ffi?
More information about the Digitalmars-d
mailing list