Purpose
Keep an ordinary Idriç path for approximating part of Adriç's intent → mechanism idea before there is dedicated compiler support.
Canonical design note / computer-science discussion:
This is not a request to add Adriç semantics to the Idriç compiler now. It is a note that normal files, modules, names, and selective imports already let us express a useful first version of the idea.
Pattern to preserve
A high-level program should be able to name what it is doing while concrete mechanisms live behind descriptively named files/directories.
For example:
http/
send/
native_socket.idric
native_tls.idric
platform_http.idric
Each file may contain one concrete implementation/function when that is the clearest representation. The caller can import the exact implementation it wants rather than importing an unnecessarily broad surface.
For job-specific collections, allow tiny named modules whose only purpose is to import/re-export the subset actually needed. If one job needs seven operations and another needs eleven with six in common, those can be two small profiles over shared underlying modules rather than one giant universal import.
This is deliberately simple. Module/file structure is doing work that might later be represented by richer Adriç mechanism-selection machinery.
Foreign / primitive implementations still fit
The deepest Idriç implementation may simply be a typed wrapper around C or another existing runtime/library operation.
Example shape:
crypto/
aes256/
some_c_library.idric
That wrapper can still provide the useful Idriç boundary:
- domain-specific input/output types rather than collapsing everything to primitive strings/integers/bytes where avoidable;
- an explicit primitive/FFI boundary;
- comments explaining what mechanism is used and why/when it is appropriate;
- dependency/runtime constraints and relevant guarantees/restrictions;
- upstream source identity/link, with a small local source snapshot/excerpt when useful for inspection.
The implementation being "just a C call" is not a failure. The point is that the high-level Idriç program need not be written in terms of that C call, while a reader can descend to it when they want the mechanism.
Progressive disclosure through path depth
Treat repository/module depth as a usable human-facing hierarchy:
intent / operation
→ mechanism family
→ concrete algorithm
→ primitive / foreign implementation
The top level can therefore stay purpose-ordered and readable. The details remain inspectable rather than being hidden behind a magical abstraction boundary.
Compiler boundary
Do not make this issue contingent on new compiler syntax.
The immediate value is precisely that this works with ordinary Idriç today. Later Adriç work can use real examples built this way to decide which distinctions deserve compiler-visible adverbs, metadata, checking, or automated selection and which should remain ordinary module organization.
Non-goal
Benchmark/run/empirical-data storage is not part of this issue. It may be useful separately, but the core note here is the filesystem/module/import structure.
Purpose
Keep an ordinary Idriç path for approximating part of Adriç's intent → mechanism idea before there is dedicated compiler support.
Canonical design note / computer-science discussion:
This is not a request to add Adriç semantics to the Idriç compiler now. It is a note that normal files, modules, names, and selective imports already let us express a useful first version of the idea.
Pattern to preserve
A high-level program should be able to name what it is doing while concrete mechanisms live behind descriptively named files/directories.
For example:
Each file may contain one concrete implementation/function when that is the clearest representation. The caller can import the exact implementation it wants rather than importing an unnecessarily broad surface.
For job-specific collections, allow tiny named modules whose only purpose is to import/re-export the subset actually needed. If one job needs seven operations and another needs eleven with six in common, those can be two small profiles over shared underlying modules rather than one giant universal import.
This is deliberately simple. Module/file structure is doing work that might later be represented by richer Adriç mechanism-selection machinery.
Foreign / primitive implementations still fit
The deepest Idriç implementation may simply be a typed wrapper around C or another existing runtime/library operation.
Example shape:
That wrapper can still provide the useful Idriç boundary:
The implementation being "just a C call" is not a failure. The point is that the high-level Idriç program need not be written in terms of that C call, while a reader can descend to it when they want the mechanism.
Progressive disclosure through path depth
Treat repository/module depth as a usable human-facing hierarchy:
The top level can therefore stay purpose-ordered and readable. The details remain inspectable rather than being hidden behind a magical abstraction boundary.
Compiler boundary
Do not make this issue contingent on new compiler syntax.
The immediate value is precisely that this works with ordinary Idriç today. Later Adriç work can use real examples built this way to decide which distinctions deserve compiler-visible adverbs, metadata, checking, or automated selection and which should remain ordinary module organization.
Non-goal
Benchmark/run/empirical-data storage is not part of this issue. It may be useful separately, but the core note here is the filesystem/module/import structure.