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