Ginger - holy fuck again?

The final result. A language which can do X

• Support my OS

  • Compile on many architectures
  • Be low level and fast (effectively c-level)
  • Be well defined, using a simple syntax
  • Extensible based on which section of the OS I'm working on
  • Good error messages

• Support other programmers and other programming areas

  • Effectively means able to be used in most purposes
  • Able to be quickly learned
  • Able to be shared
    • Free
    • New or improved components shared between computers/platforms/people

• Support itself

  • Garner a team to work on the compiler
    • Team must not require my help for day-to-day
    • Team must stick to the manifesto, either through the design or through trust

The language: A manifesto, defines the concept of the language

• Quips

  • Easier is not better

• Data as the language

  • Differentiation between "syntax" and "language", parser vs compiler
    • Syntax defines the form which is parsed
      • The parser reads the syntax forms into data structures
    • Language defines how the syntax is read into data structures and "understood" (i.e. and what is done with those structures).
      • A language maybe have multiple syntaxes, if they all parse into the same underlying data structures they can be understood in the same way.
      • A compiler turns the parsed language into machine code. An interpreter performs actions directly based off of the parsed language.

• Types, instances, and operations

  • A language has a set of elemental types, and composite types
    • "The type defines the [fundamental] operations that can be done on the data, the meaning of the data, and the way values of that type can be stored"
    • Elemental types are all forms of numbers, since numbers are all a computer really knows
    • Composite types take two forms:
      • Homogeneous: all composed values are the same type (arrays)
      • Heterogeneous: all composed values are different
        • If known size and known types per-index, tuples
        • A 0-tuple is kind of special, and simply indicates absence of any value.
    • A third type, Any, indicates that the type is unknown at compile-time. Type information must be passed around with it at runtime.
    • An operation has an input and output. It does some action on the input to produce the output (presumably). An operation may be performed as many times as needed, given any value of the input type. The types of both the input and output are constant, and together they form the operation's type.
  • A value is an instance of a type, where the type is known at compile-time (though the type may be Any). Multiple values may be instances of the same type. E.g.: 1 and 2 are both instances of int
    • A value is immutable
    • TODO value is a weird word, since an instance of a type has both a type and value. I need to think about this more. Instance might be a better name

• Stack and scope

  • A function call operates within a scope. The scope had arguments passed into it.
  • When a function calls another, that other's scope is said to be "inside" the caller's scope.
  • A pure function only operates on the arguments passed into it.
  • A pointer allows for modification outside of the current scope, but only a pointer into an outer scope. A function which does this is "impure"

• Built-in

  • Elementals
    • ints (n-bit)
    • tuples
    • stack arrays
      • indexable
      • head/tail
      • reversible (?)
      • appendable
    • functions (?)
    • pointers (?)
    • Any (?)
  • Elementals must be enough to define the type of a variable
  • Ability to create and modify elmental types
    • immutable, pure functions
  • Other builtin functionality:
    • Load/call linked libraries
  • Comiletime macros
    • Red/Blue

• Questions

  • Strings need to be defined in terms of the built-in types, which would be an array of lists. But this means I'm married to that definition of a string, it'd be difficult for anyone to define their own and have it interop. Unless "int" was some kind of macro type that did some fancy shit, but that's kind of gross.
  • An idea of the "equality" of two variables being tied not just to their value but to the context in which they were created. Would aid in things like compiler tagging.
  • There's a "requirement loop" of things which need figuring out:
    • function structure
    • types
    • seq type
    • stack/scope
  • Most likely I'm going to need some kind of elemental type to indicate something should happen at compile-time and not runtime, or the other way around.

The roadmap: A plan of action for tackling the language