mal/impls/chuck/chuck.md

- I've found a potential bug in their substring function:
  https://github.com/ccrma/chuck/issues/55
- later I've found one in their regex replace function, too:
  https://github.com/ccrma/chuck/issues/60
- this suggests there hasn't been much testing done on things
  unrelated to audio which is not that unexpected in an audio
  programming language, but still...
- the manual isn't up to date, so you need to look at `VERSIONS` and
  the examples instead, sometimes the sources, too
- the manual only speaks of the debug syntax for printing
  (`<<<foo>>>;` which goes to stderr), I've found a `chout` object you
  can send strings to for outputting to stdout
- quitting is done via `C-c` only
- you'll want to use `--silent` to disable audio errors/processing,
  but then the process will use 100% CPU and ignore any waiting
- stdin handling is terrible:
  - the manual shows a keyboard example with HID devices, but it
    doesn't work on linux
  - there's a "hacked" `ConsoleInput` class with only an example file
    for it, it works for most of the part, but doesn't accept `C-d`
  - the obvious alternative is printing a prompt manually, then
    waiting for `KBHit` events and printing them, but that's rather
    tedious as you'd have to convert the ascii numbers into chars
    yourself and make a buffer-like thing
  - I've also considered writing a thing sending OSC events per
    keyboard hit and processing these in ChucK as they come in, but
    that would most likely not work with the test harness ._.
- the OOP system is seriously weird
  - influenced by C++ *and* java
  - one public class per file
  - to export functionality, you must use a public class (and static
    functions/variables)
  - if you use static variables, you can't assign values to them
    directly, you'll have to do that after the class has been defined
  - worse, you can't even declare anything that's not a primitive, so
    if you want to declare a reference type, use the reference
    operator instead...
  - no interfaces
  - no generics (copy/paste code for all types you need!)
  - no unions (use Object, then cast to the correct type)
  - there is no obvious way of casting to arrays of types
  - no private (things are public by default, public keyword is used
    to export code)
  - no self-references in classes (so no trees, static "constructors"
    work though)
  - no meaningful way of working with null for primitive types (mutate
    a reference and look at the return code instead)
  - no boxed versions of primitive types
  - no automatic boxing/unboxing
  - no upcasting/downcasting
- No module system
  - `Machine.add(file)` is the only mechanism available from code (no
    read all file contents and eval), but if you use it, it defers
    loading the files until the file it's used in, rendering it
    useless
  - Therefore the only way to make use of it is writing a file that
    only consists of these instructions
  - The only practical alternative is specifying all files you need
    loaded in the right order when starting chuck
  - That's why I wrote a runner script extracting `// @import file.ck`
    lines (hello JS!) and running chuck with them
- No real exception system
  - The VM is able to throw exceptions (out of bounds, nullpointer),
    but you can't do anything about them and only get a hint what kind
    of operation caused it (no stacktrace or anything)
  - No user-definable exceptions, no mechanism to catch or throw them
    (other than intentionally doing something illegal)
  - This means that you should use C-style error checking by
    converting the potentially erroneous functions into returning a
    status code and mutating a reference passed to them as argument
    which is highly weird in a otherwise Java-like language
  - An alternative is defining an error object (which belongs to the
    same supertype as the other legal return values) and checking its
    type by inspecting the user-tracked type field
- No function pointers/functors/closures
  - This is a bit unexpected as if you leave away the parentheses
    holding the argument list and debug print a function, you'll see
    it being recognized as a function, yet you can't store it anywhere
    for passing it around
  - This is not quite right as you can store it in an `Object`, just
    not call it in any way or cast it to a function type
  - So you get to implement functors and closures yourself...
  - A functor is a class with a call method taking an argument list
    and executing the code of the function you intend to pass around
  - To use it, store an instance of its class somewhere, then use its
    call method with an argument list
  - Closures can be implemented with a data structure holding a
    snapshot of the current environment, the parameter list and AST,
    the last two being a way of representing an anonymous function.
- Other oddities
  - strict distinction between assigning values and references with
    two separate operators for them (`<<` for array append doesn't
    seem to care though)
  - strings are supposedly reference types, yet you can assign them
    with the regular operator...
  - `<<` on an `type[]` gives you a weird error as you need to use an
    `type[0]` (and a `type[]` is merely a reference...)
  - The compiler will find lots of mistakes for you, but cannot figure
    out code branches not returning anything which means that return
    type violations will blow up in your face unless there's a
    reasonable default value (null for `Object` isn't, 0 for `int` and
    "" for `string` is)
  - If you abuse the type system too much, chances are you get a
    segfault or assert instead of an exception...
  - Debug print shows the object and its type if you pass one
    argument, if you pass more than one, it prints the concatenation
    of their representations instead, so it's a bit hard to make out
    what is a debug print and what isn't
  - there are no hash maps, just the possibility to use a string key
    on an array for storing and fetching contents (like in PHP, eww)
    and no way of retrieving keys/values or even iterating over these
  - I think I've spotted a weird scoping bug that prefers a member
    variable over a local variable after nesting scopes, therefore I
    consider the language to not implement proper lexical scoping
  - another proof of it is declaring variables in consequent if-blocks
    as that gives you an error instead of being permitted as they
    should be in different local scopes...