Currently, the scheduler is coupled with audio driver.

However, it can be decoupled as a separated module by defining a trait that has multiple callback such as a system wakeup, processing a buffer and processing sample.

This will be also useful for defining modules as a separated crate which depends on external crate, such as Symphonia for audio file reader and RtMidi for midi driver.

pub trait Plugin{
 fn get_extern_fns(&mut self)-> &[ExtFunType];
 fn get_extern_cls(&mut self)-> &[ExtClsType];
 fn on_system_launch(&mut self);
 fn on_process_block(&mut self,buf: &SampleBuffer);
 fn on_process_sample(&mut self, samples : &[Sample]);
 fn on_system_end(&mut self);
}

https://mimium.org/en/docs/users-guide/language-specification/built-in-function/#loadwavpathstring-float-x-0--loadwavsizepathstring-float

Also, string literal should be implemented.

While this isn't a problem at the moment, I see this clippy warning (if you are using VS Code, you can set rust-analyzer.check.command option to clippy to always see such warnings, but it might be a bit annoying):

warning: a `const` item should not be interior mutable
   --> mimium-lang\src\runtime\builtin_fn.rs:231:1
    |
231 | / pub const BUILTIN_FNS: LazyCell<[BuiltinFn; 49]> = LazyCell::new(|| {
232 | |     [
233 | |         i_i!(neg),
234 | |         i_i!(not),
...   |
306 | |     ]
307 | | });
    | |___^
    |
    = help: consider making this `Sync` so that it can go in a static item or using a `thread_local`
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#declare_interior_mutable_const
    = note: `#[warn(clippy::declare_interior_mutable_const)]` on by default

The explanation of declare_interior_mutable_const says:

Consts are copied everywhere they are referenced, i.e., every time you refer to the const a fresh instance of the Cell or Mutex or AtomicXxxx will be created, which defeats the whole purpose of using these types in the first place.

I think I've heard about this problem, but forgot how to deal with this (static LazyLock?). Let me file this here for now.

Because most of the vector values are expected to be a small number of elements, replacing Vec to SmallVec will greatly reduce heap allocation, especially for VM.

https://docs.rs/smallvec/latest/smallvec/

Because the closure and higher-order function can be realized in this implementation, Temporal recursion can be extended to more functional style, not just updating variable over time with destructive assignment by wrapping value like this.

fn generator(init:float, interval:float){
  let v = init // this v is captured and closed with recursive "updater" function
 let updater = | |{
     v = v+1
     updater()@(now+interval)
 }
 updater()@0;
 v
}

Currently, inline comment //comment inside function definition fails to parse.
The parser should be changed so that it can ignore comment token at anywhere in the process.
We can remove all the comment tokens before parsing but it maybe better to keep it as a metadata for the following expression id because it can be extended as an attribute or documentation comment system.

I experimentally implemented a pipe operator, and got to know there are two types of pipes.

cf. https://github.com/tc39/proposal-pipeline-operator?tab=readme-ov-file#why-the-hack-pipe-operator

• explicit function call (Hack pipe): value |> foo(%)
• implicit function call (F# pipe): value |> foo

It seems my implementation is a simpler version of "Hack pipe," which is without the placeholder % by assuming the value is inserted into the first argument. Since my main language is R, I naturally assumed this is the pipe operator. On the other hand, Mimium's pipe is "F# pipe". I think this needs some discussion because both pipe have their pros and cons.

Is it common to use the F# style in this area? If I understand correctly, F#'s pipe is designed for combination with partial application. I'm wondering if there's any plan.

(I'm asking this simply because it looks easy to implement. Not sure about the importance of the feature itself)

• #![feature(box_patterns)] if we use arena for recursive types, no longer needed(maybe match_deref crate macro can be used for simple matching)
  • #12
• #![feature(iterator_try_collect)] itertools can be used
• #![feature(iter_collect_into)] used only one location in typing.rs, no need to persist with this feature
• #![feature(if_let_guard)] no longer used in current code, can just remove
• #![feature(lazy_cell)] stabilized in v1.8.0, just remove it and set the minimum compiler version

In the current implementation, compiler clones many String value and comparing them.
Use StringInterner crate will improve the performance.

https://docs.rs/string-interner/latest/string_interner/

Also, recursive type definitions in the Expr and Type are realized simply with Box<Self>, however, this this will make a implementation
of interactive inspection of values difficult, for example, for the language server. Using id_arena simplifies this situation, along with performance improvements.

They are tested on my another project otopoiesis (an experimental branch)

https://github.com/tomoyanonymous/otopoiesis/blob/372bfb7b5c760744f69532c63e8804878a84397d/otopoiesis_lang/src/expr.rs#L31-L32

https://github.com/tomoyanonymous/otopoiesis/blob/372bfb7b5c760744f69532c63e8804878a84397d/otopoiesis_lang/src/lib.rs#L25-L28

For stereo and the more multi-channel processing, tuple types needs to be implemented.

https://github.com/mimium-org/mimium/blob/dev/examples/demo.mmm

This code returns 0.0. It seems this user-defined function div is used for / operation because / simply calls a function with the name of Op::get_associated_fn_name(). Is this for allowing users to override the operators? If not, probably add _mimium_ prefix to the builtin functions and prohibit the use of the prefix (until namespace is implemented?).

fn div(x, y) {
    0.0
}
fn dsp(){
    1.0 / 1.0
}