mrakgr / The-Spiral-Language

Functional language with intensional polymorphism and first-class staging.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Layout stack module-with type error

kevmal opened this issue · comments

The following (from the readme):

inl npc = 
    {
    health = dyn 0
    mana = dyn 0
    max_health = 40
    max_mana = 30
    } |> stack

inl ar = array_create npc 3
ar 0 <- {npc with health = dyn 10; mana = dyn 20}
ar 1 <- {npc with health = dyn 20; mana = dyn 10}
//ar 2 <- {npc with health = dyn 10; mana = dyn 20; max_health = 50} // Gives a type error
()

Produces the error

The two sides in array set have different types.
Got: layout_stack ({health=var (int64); mana=var (int64); max_health=lit 40i64; max_mana=lit 30i64}) and {health=int64; mana=int64; max_health=int64; max_mana=int64}

Thank you for bringing this to my attention. When I first wrote the tutorial the above fragment was correct, but since then there have been some changes to the semantics. Among other things, there was a change in order to simplify the implementation of the language that the layout type won't automatically repack itself on updates.

So under the current semantics this is how the correct version would look like:

inl npc = 
    {
    health = dyn 0
    mana = dyn 0
    max_health = 40
    max_mana = 30
    } |> stack

inl ar = array_create npc 3
ar 0 <- stack {npc with health = dyn 10; mana = dyn 20}
ar 1 <- stack {npc with health = dyn 20; mana = dyn 10}
//ar 2 <- stack {npc with health = dyn 10; mana = dyn 20; max_health = 50} // Gives a type error
()

Well, that covers what is correct, but whether that should be correct is a whole other matter. Since layout types have such specialized uses, I am thinking that I should forbid these kinds of implicit conversions. I've never really carved in stone the final design for this particular aspect of them so I might as well do it today.

All clear.

Removed the support for layout types in the ModuleWith construct.

Originally this feature was intended to be a convenience, but now after half a year of practical experience with them I've realized that layout types are simply never used that way so they are better off being restricted. It will make the construct more consistent with the rest of the language.

It would be easy to extend it should the need arise.

Check the manual to see what the correct example would look like as the above is no longer correct.

Once again, I appreciate all bug reports so please don't hesitate to open an issue if you run into something again or if you have questions otherwise. It is also good to know that I haven't written the documentation for myself. If you feel that some sections are lacking or in need of more explanation, your questions will be feedback that I need to improve it.