eight months of coastal living: coastML status report for October 2022

Today marks eight months of coastal living; let’s checkout the running burndown chart:

• ✓ assignments

• ✓ functions

• ✓ case forms

  • ✓ thread assignments into case forms (e.g. a = case x …​ becomes case x | …​ { a = …​ })

  • ✓ case forms within other forms, such as function calls

• ✓ type forms

• ✓ Python generation

• ✓ decomposition in case forms

  • ✓ including pattern matching

  • ❏ array pattern matching

  • ❏ string pattern matching (this could get interesting…​)

• ✓ accessors (both variables and lambdas) for type

• ❏ gn forms

• ❏ fc forms

• ❏ mod and sig forms

• ❏ an analog to SML’s op, using backticks

• ❏ basis library (stubbed out, need to actually compile)

  • ✓ basic basis stubs: some members of array-*, string-* have been stubbed out

    • ✓ array-length

    • ✓ array-get

    • ✓ array-set!

    • ✓ array-make

    • ✓ array-init

    • ✓ array-make-matrix

    • ✓ array-append

    • ✓ array-append!

    • ❏ array-concat

    • ❏ array-concat!

    • ✓ array-sub

    • ✓ array-copy

    • ❏ array-fill!

    • ❏ array-blit!

    • ❏ array→list

    • ❏ list→array

    • ✓ array-iter

    • ✓ array-map

    • ✓ array-iter-index

    • ✓ array-map-index

    • ❏ array-foldl

    • ❏ array-foldr

    • ❏ array-sort

    • ✓ array-sort!

    • ❏ array-stable-sort

    • ❏ array-fast-sort

    • ✓ string-length

    • ✓ string-get

    • ❏ string-make

    • ❏ string-init

    • ✓ string-split

    • ✓ string-append

    • ❏ string-join

    • ❏ string-contains

    • ❏ string-concat

    • ❏ string-copy

    • ❏ string→array

    • ✓ string-iter

    • ✓ string-map

    • ✓ string-iter-index

    • ❏ string-map-index

    • ❏ string-foldl

    • ❏ string-foldr

    • ✓ string-sort

    • ❏ compare

    • ❏ char-code

    • ❏ char-chr

    • ❏ char-escaped

    • ❏ char-lowercase

    • ❏ char-uppercase

    • ❏ char-compare

    • More of the OS interaction stuff out of the Pervasives API

  • ❏ basis library modules (modular forms, e.g. array-get becomes Array::get)

• ✓ support for the is form

• ❏ code generation

  • ❏ C

  • ❏ C++

  • ❏ C#

  • ❏ Java

  • ❏ Go

  • ✓ Python

  • ✓ JavaScript

  • ❏ Reason/OCaml

  • ❏ F#

• ❏ type inference

• ❏ refinement types

• ❏ a compiler

  • ❏ lambda lifter

  • ❏ closure conversion

  • ❏ pragma to control certain aspects of compilation

  • ❏ checking of accessors prior to compilation

  • ❏ value restriction for ref types

  • ✓ checking that functions exist prior to compilation

  • ✓ checking that case forms use correct constructors

  • ❏ self-tail call rewriting

• bugs fixed

  • ✓ nested arrays [[[1] [2]] [[3] [4]]]

  • ✓ missing / character in identifier/operator character sets

  • ✓ floating point numbers with two integral digits (e.g. 0.12 and 1.12 worked but not 10.12)

    • this was noticed when attempting to write some software to generate Julian dates

    • Was the calculation sheet I was using

  • ✓ return logic

    • ❏ there’s more work to be done here at the top level…​

  • ✓ indentation of blocks

  • ✓ missing bool type

  • ✓ parsing type definitions that have other complex types in them

  • ✓ munging idents (ex: julian-date becomes julian_date)

  • ✓ stripping comments prior to output

    • really need to handle these so that we can output them into the compiled language, but for now this suffices

  • ✓ return prepended to forms that are rewritten to for loops

  • ✓ fix spacing between class forms in Python output

  • ✓ fixed bugs with parsing & displaying characters

  • ❏ case forms at the start of a (call) form are assumed to be functions instead of evaluated for a lambda

    • (case …​ | 10 { " " } | _ { "nope" } esac …​) is assumed to be a lambda already…​ whoops

  • ✓ case forms in a function call in assignment clobbers the assignment

    • ex: a = string-split-char ':' case (OS::getenv "PATH") | (Result.Some s) { s } | (Result.None) { "" } esac;

    • produces a = res1 = …​ which is obviously in correct

  • ✓ case forms that destructure type forms don’t indent correctly and don’t nest if-elif-else correctly

  • ✓ case forms that bind a function call do not indent the initial if correctly

  • ✓ destructuring binds didn’t actually apply a .format correctly

  • ✓ indentation more generally is handled better

  • ✓ ability to call Tags and Modules

  • ✓ instantiate the classes we define

This month I’ve been laying the ground work for a more industrial compiler: self-tail call elimination, forward variable declarations, and being able to call constructors & module members. I’ve also been tinkering with a piece of code I was thinking about after reading Prayers for the Crown Shy, which had a type of digital currency that I’m curious about.

One thing that has been laying heavily on me is how do we want to support ML-style modules…​ and I’m not really sure we actually want to. Looking at it, I believe that type classes are actually the way I want to go about it, but I’m not 100% sure how I want to integrate them into coastML without introducing a ton of complexity.

1. we could use sig and mod forms, with sig stating the type class and mod stating the gn forms that satisfy it

   1. this is simple, but requires you to open or otherwise import the generic lambdas, and it is confusing for folks with ML backgrounds

   2. this would be simple to support, since mod would just act as normal

   3. does require mod to have some sort of "I’m implementing this typeclass" signifier

2. we could support sig and have type forms implement the satisfaction

   1. this would mean type becomes more complex, but doesn’t introduce more forms

   2. gets us to the point of something like SRFI-9/SRFI-57

   3. does potentially make it easier to support downstream compilation, because each constructor could define it’s satisfaction of the type class, and these could be easily copied to say the Python class that results

   4. ends up with a halfway point between Scala’s case classes and type classes

3. we could support sig, and have a impl that implements the satisfaction

   1. impl forms could be imported from mod easily

   2. requires yet another form, but doesn’t pollute mod or type at all

   3. once included, an impl can easily be populated into the environment

4. regardless of which one is chosen, the compiler should support generating them for the most part, unless the user wants to override specific functionality

   1. for example, I don’t want everyone to have to write a show function

One thing that I have been thinking about as well is that originally I thought gn forms would have a sort of dynamic scope: once defined, they would exist at all levels. I’m not sure that’s the correct path; making them lexically scoped is easy enough, even tho I’m not sure if that’s a useful (will people need a generic lambda in a lexical scope often? who knows).

This next month, I want to continue to work on types, type classes, and (self-)TCO. I think this will be an important first step into making coastML an actually-useful auxiliary language.