ideas: next gen language

ideas/@Plan

@@ -1,5 +1,15 @@
 2021 Roadmap for "New Curv"
 ===========================
+The long term goal is a major redesign of Curv:
+
+* A more powerful language with new syntax, and more efficient runtime.
+* A more powerful, optimizing GPU compiler.
+* A faster, more powerful GPU rendering engine that uses compute kernels.
+* A more powerful, more general purpose set of graphics primitives.
+* A new user interface.
+
+The current priority list for 2021 is:
+
 1. Language Design Bible (< new language)
 2. New Language (< new SubCurv compiler)
     High Level (as a modelling language)

ideas/Fast_Eval

@@ -9,8 +9,10 @@ Here are the possibilities for fast expression evaluation:
   Forbidden in iOS (Zee wants to do an iOS port). Impossible in WASM (per Wasm3
   readme). Complicated, as I need to generate low level IR for the JIT library.
 * Generate C++, compile to *.so or *.dll, dlopen and execute. Forbidden in iOS.
-  Impossible in WASM/web browser, but can you generate an external WASM module
-  and then execute it? Yes (https://github.com/indutny/wasm-jit/).
+  Native only: Not workable in WASM/web browser.
+* WASM/JIT: Generate an external WASM module and then execute it.
+  * https://github.com/indutny/wasm-jit/
+  * JIT based x86 emulator in WASM: leaningtech.com/cheerpx
 * GPU compute. Super fast for appropriate work loads. Strangely, this is the
   only universal option for optimized native code execution.
 * AOT compiler. Generate C++, compile to native code or WASM.
@@ -29,6 +31,7 @@ Priorities:
     implement a GPU version.
  1. GPU compute language.
  2. Tail-threaded interpreter. Faster, but finicky & bleeding edge.
+    Needs a fallback for WASM.
  3. AOT compiler, offshoot of current GLSL/C++ compiler.
  4. Internal JIT. Difficulty + lack of universality makes this lowest priority.
 
@@ -62,6 +65,22 @@ generate efficient code. So this probably needs more time to bake.
 See also the Wasm3 interpreter architecture (aka M3, Massey Meta Machine):
 github.com/wasm3/wasm3/blob/main/docs/interpreter.md
 
+Small hackable example (283 lines of C++):
+gist.github.com/snej/9ba59d90689843b22dc5be2730ef0d49
+lobste.rs/s/wmuvxw/tails_tiny_forth_core_written_as_hack_for
+
+I think this technique is presently impossible in WASM, based on
+blog posts written by the CheerpX team. It requires the WASM tail call
+feature, which is stalled in the implementation phase for 2 years
+(Mozilla hasn't implemented it).
+ * https://medium.com/leaningtech/extreme-webassembly-1-pushing-browsers-to-their-absolute-limits-56a393435323
+ * https://medium.com/leaningtech/extreme-webassembly-2-the-sad-state-of-webassembly-tail-calls-f5d48ef82a87
+
+Because of this, the C/C++ code needs to be written so that it "falls back"
+to generated code that works correctly without the tail call optimization,
+and doesn't blow up the call stack. The interpreter will be slower without
+the tail call optimization, probably comparable to the Curv 0.4 interpreter.
+
 JIT
 ---
 Can I JIT the entire language to native code, or is this restricted to SubCurv?
@@ -94,6 +113,7 @@ Here is a list of JIT libraries in 2021: https://github.com/vnmakarov/mir
   * ... see mir readme for more
 
 What is my JIT story for Curv running in WASM?
+* See CheerpX, referenced above, a sophisticated JIT running in WASM.
 * Maybe there is no JIT under WASM: interpreter only.
 * JITing to WASM makes sense for SubCurv. But WASM lacks proper tail recursion.
   The tail recursion proposal entered Phase 3 (implementation) in Aug 2019.

ideas/language/next/Simple_DA → ideas/language/next/Data_Types

@@ -30,6 +30,57 @@ An operation on a UDT is a function:
 By convention, the operations on a UDT are packaged in a module named after
 the UDT.
 
+Data Types
+----------
+Every boxed Curv value contains a type tag, which is used for dynamic
+dispatching. This is a statement about the Curv VM.
+
+I've considered two models:
+* All type tags are disjoint. This is similar to Scheme, where primitive types
+  are disjoint.
+* Type tags form a hierarchy. This is similar to Julia.
+I prefer to keep things simple.
+
+A value's type tag is determined when it is constructed. In fact, I believe
+that it is uniquely determined by the value's constructor (and not by any
+constructor arguments).
+
+A simple data constructor has a unique type tag associated with it.
+
+Each type tag has an associated Type value -- all of the values with that tag
+belong to the associated type. Not all Types have an associated tag: those
+that do are called "data types".
+
+Primitive types (which are not constructed using 'data' definitions) also
+have tags and data types. For example, `Num` is a data type.
+
+Data types are used by theories for efficient dynamic dispatch of overloaded
+operations. A theory used for dynamic dispatch may require its types to be
+data types.
+
+Simple Data Constructors
+------------------------
+A data constructor is defined like this:
+    data CtorName ArgType0 ArgType1 ... -- 0 or more arg types
+
+This is the simplest design that meets the needs of the shape library.
+One use case for data constructors is to add new constructors to an existing
+Theory, such as the Shape theory. Data constructors may have zero or more
+curried arguments, because so do shape constructors:
+    everything
+    cube 10
+    rotate (45*deg) cube
+
+A data constructor value supports multiple protocols:
+* is a constructor function (if the constructor has at least one argument).
+* is a data value (if the constructor has zero arguments).
+* is a type for classifying instances of the data constructor.
+
+Problem: this design suggests that Type is a theory, which is extended by
+defining new data constructors. Eg, 'data MyType' could be used to create a
+new niladic type constructor. Except that MyType is already a type used to
+classify its sole instance, which is the value MyType. So there is a conflict.
+
 Strawman #H: Constructors
 --------------------------
 Something like Haskell data type declarations would be okay.