Up to Main Index                           Up to Journal for October, 2023

                    JOURNAL FOR SUNDAY 29TH OCTOBER, 2023
______________________________________________________________________________

SUBJECT: Status of the ‘any’ type + small performance boost
   DATE: Sun 29 Oct 18:39:41 GMT 2023

With all the recent storms you wouldn’t believe it’s the end of summer and the
clocks have gone back :(

Work continues slowly on adding the ‘any’ type to Mere. I have the basic ‘any’
type working. Conversions to and from type any are working. The automatic
conversions to a variable of type any work, this includes basic types to type
any on function calls.

To support the automatic conversions I’ve had to add label conversions which
Mere did not have. The label type now has two conversions. A label can be
converted to a label — not useful in itself — and a label can be converted to
type any.

With so many conversions happening I’ve had to rework how type information for
Mere types are handled. This has resulted in a 7% performance boost compared
to v0.0.8 :) However, it’s also caused a tiny memory I’m trying to fix :|

While working on, and debugging, the ‘any’ type I noticed that there are a lot
of instances, mostly in generated code, where a goto jumps to another goto.

For example:


    goto guard1
    fn1: func; endfunc
    guard1:

    goto guard2
    fn1: func; endfunc
    guard2:

    goto guard3
    fn1: func; endfunc
    guard3:


There is now a compiler optimisation phase that will rewrite the goto, where
possible, to be more efficient:


    goto guard3
    fn1: func; endfunc
    guard1:

    goto guard3
    fn1: func; endfunc
    guard2:

    goto guard3
    fn1: func; endfunc
    guard3:


A further optimisation will be to drop the unused labels. For now I’ve just
implemented the quick and easy optimisation before I forget about it.

Right now I’m trying to find a nice fix for the tiny memory leak. After that I
need to get arrays and maps to play nice with the ‘any’ type. It would also be
good to have an []any — an array that takes any type. However, I need to think
about that a bit more as I can see it causing all sorts of issues — and maybe
solving a few.

A prime example is that the current arrays are one dimensional and can only
hold basic types. Implementing []any would imply being able to write the
following:


    a := dim []any() 2
    a[0] = [string] "a" "ant"
    a[1] = []int 1 2 3
    println literal a

    // displays: []any([string]("a" "ant"), []int(1 2 3))


At the moment I’m not sure if the added complexity would be worth it. The
above could already be achieved with a [int]:


    m:[int]
    m[0] = [string] "a" "ant"
    m[1] = []int 1 2 3
    println literal m

    // displays: [int](0 [string]("a" "ant"), 1 []int(1 2 3))


As I said, I still need to think through the implications. For now I want to
fix the tiny memory leak and get arrays and maps working nicely with the ‘any’
type so I can maybe release v0.0.9 for Halloween…

Only two days left until Halloween!  ╓╥ôô╥╖  ;)

--
Diddymus


  Up to Main Index                           Up to Journal for October, 2023