FUBS.md

@@ -10,17 +10,18 @@ It will continue to be a private work in progress for many more months.  It will
   * It must be self hosted on its own source code repository.
   * It must be be under a new open source license that ensures our core principal is not violated by other programmers' forks.
 
-We have an almost pathological focus on minimalism.  We want the functionality of any modern IDE with only 100,000 lines of code. 
+We have an almost pathological focus on minimalism.  We want the functionality of any modern IDE with only 100,000 lines of code running on bare metal.
 
 ## Core Principles (roughly in order of importance)
   1. Have a unified execution and authoring environment.  Any program must also provide the tool with which it was created and allow itself to be modified.  We endeavor to make it as frictionless as possible for a user of a program to understand or modify it.  **Anyone using a program can become its programmer within seconds.**  We will insist on this via our open source license.
   1. Anyone can code.  Make it easy for anyone to modify any part of the system.  Imposing restrictive [encapsulation](https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)) is selfish and elitist.
   1. Milliseconds matter.  A programmer should see the results of a program modification instantaneously.
   1. It is extremely important for systems to be self hosted.  Only use other programming systems as a bootstrap mechanism.  If your system uses nothing written with another system, then you can rest assured that it is complete.
-  1. [Dynamic analysis](https://en.wikipedia.org/wiki/Dynamic_program_analysis) with 100% [code coverage](https://en.wikipedia.org/wiki/Code_coverage) is far more effective at catching programmer mistakes than static analysis will ever be. Programming tools can make such testing much less cumbersome.
+  1. Be opionated and don't spend time and lines of code to make everyone happy.
   1. Never compromise the present for backwards compatibility.  Fix mistakes as soon as they are identified regardless of how it affects existing dependers.  An antiquated depender can either keep up or become an artifact.
   1. No sacred cows.  If something can be substantially improved, do it.
-  1. The programming language must make it easy for the programmer to understand and control what the computer is doing at the lowest level.  High level abstractions should never lessen this understanding.
+  1. [Dynamic analysis](https://en.wikipedia.org/wiki/Dynamic_program_analysis) with 100% [code coverage](https://en.wikipedia.org/wiki/Code_coverage) is far more effective at catching programmer mistakes than static analysis will ever be. Programming tools can make such testing much less cumbersome.
+  1. The programming tools must make it easy for the programmer to understand and control what the computer is doing at the lowest level.  High level abstractions should never lessen this understanding.
   1. Use concrete [AST](https://en.wikipedia.org/wiki/Abstract_syntax_tree) metrics to measure some aspects of code quality.
      1. Fewer nodes for the same program with similar execution time and space is almost always better.
      1. If node A refers to node B, a shorter path from A to B through the AST is almost always better.
@@ -30,52 +31,42 @@ We have an almost pathological focus on minimalism.  We want the functionality o
 ## Major Tasks
   * MVP
      * Runs self hosted on Linux with OpenGL. (complete)
-     * Runs self hosted on bare metal. (2023 Q2)
+     * Runs self hosted on bare metal. (2023 Q4)
         * Boot
         * Keyboard
         * HDMI
-     * Nail self hosted code editing (50% complete) (2023 Q2)
-     * Create self hosted source management system. (2023 Q2)
-     * Programming / debugging bridge to another device. (2023 Q3)
+     * Nail self hosted code editing (50% complete) (2023 Q3)
+     * Create self hosted source management system. (2023 Q3)
+     * Programming / debugging bridge to another device. (2023 Q4)
      * Write open source license.
   * Other high priority things:
-     * Android container. (2023 Q4)
+     * Android container. (2024 Q1)
 
 ## Language Details
-  * FUBS is basically an imperative language with decent support for closures and class hierarchies.
-  * Classes can contain inner classes, data fields (singleton or per object), and functions (singleton or bound to an object).
+  * FUBS is basically an object oriented imperative language with decent support for closures and class hierarchies.
+  * Only classes exist at the top level.  Classes can contain inner classes, data fields (global or per object members), functions, and methods.
     * Inner classes exist solely for the purpose of providing a hierarchical namespace.
   * A class may specify one or more parent classes for inheritance.
     * Diamond inheritance is prohibited.
-    * Name collisions for singletons and object fields are prohibited.
-    * Name collisions for object functions create a function group for [dynamic dispatch](https://en.wikipedia.org/wiki/Dynamic_dispatch).
-  * Only classes exist at the top level.  All functions and data are fields belonging to a class.
+    * Name collisions for global functions and data fields are prohibited.
+    * Name collisions for methods create a group for [dynamic dispatch](https://en.wikipedia.org/wiki/Dynamic_dispatch).
   * Strongly typed.
     * Supported types:
       * Primitive types (passed by value):
-        * Single byte
-          * No operations allowed except storing and retreiving from array and casting.
-        * 4 byte integer
-        * 8 byte integer (not implemented yet)
-        * IEEE 754 single precision floating point
-        * IEEE 754 double precision floating point (not implemented yet)
-        * Boolean
-      * Reference types (nullable):
+        * i1, i4, i8, bool, f4, f8
+      * Reference types (nullable and passed by reference):
         * Array
-        * Object (bound to a specific class)
-        * Functions, Methods, Closures
-    * Signedness of integer types is determined by the binary operator chosen.
-    * Stack variable types are inferred.
+        * Object (instance of a specific class)
+        * Functions, Closures
+      * Tuples (passed by value)
+    * Decent type inferencing for stack variable types.
     * No automatic coercion except for widening of object types.
-      * Any primitive type may be cast to any other primitive type.
-    * Class parameters provide for [generic programming](https://en.wikipedia.org/wiki/Generic_programming).
+    * Decent support for [generic programming](https://en.wikipedia.org/wiki/Generic_programming).
   * Heap management:
     * No dynamic reachability analysis except when debugging.
     * A reference type may be "prime", which means that it will be automatically freed when it leaves scope (for local variables), or its parent is freed (for object fields).
     * Static analysis will help catch program errors with respect to prime reference management.
-    * Copies of prime references are permitted.  The static analyzer will try to prove that a copy does not escape the lifetime of the object it points to.
-  * Only rudimentary support for strings.
-    * A string constant may be specified in a program.  It will manifest itself as a mutable array of single bytes.
+      * Guaranteed to catch double-free errors.
+      * The programmer is expected to avoid use after free errors.  Less efficient execution modes can guarantee this with runtime reference counting.
   * [Balls](https://en.wikipedia.org/wiki/Exception_handling)
   * [Closures](https://en.wikipedia.org/wiki/Closure_(computer_programming))
-  * Higher level concurrency mechanisms have not been worked out yet.
\ No newline at end of file