Stream: ideas

Topic: static dispatch - decoding

Richard Feldman (Nov 10 2024 at 20:27):

Richard Feldman said:

regarding knowing types - something I realized the doc doesn't address is how this would work:

user = Decode.decode(bytes, Json.utf8)?

this is an example of wanting to do static dispatch, but where the subject type of the dispatch is in the return value of the function rather than its first argument
definitely possible for the type checker to do, and I think decoding is a valuable use case that abilities offer that is worth bringing over to static dispatch, but I hadn't thought about that scenario, what the syntax would look like, etc.

here's an idea for how the syntax could work:

Richard Feldman (Nov 10 2024 at 20:27):

change the where syntax to this:

List.isEq : List a, List a -> Bool
    where a.{ isEq : a, a -> Bool }

Richard Feldman (Nov 10 2024 at 20:28):

crucially, the type uses the full function type, including all of its arguments, rather than the method style of where a.isEq(a) -> Bool as proposed in the doc.

This change makes it possible to specify a where in which the type being statically dispatched on does not have to appear in the first argument position.

Richard Feldman (Nov 10 2024 at 20:28):

a longer one would be e.g.

Dict.insert : Dict k v, k, v -> Dict k v
    where
        k.{ isEq : k, k -> Bool, hash : k, hasher -> Hash },
        hasher.{ u8 : ..., etc. },

Richard Feldman (Nov 10 2024 at 20:29):

and then from there we can have functions where the type being dispatched on appears in the return position:

Json.decode : List U8 -> Result val Problem
    where val.{ decode : List U8, JsonFmt -> Result val Problem }

Richard Feldman (Nov 10 2024 at 20:31):

a potential syntax for invoking static dispatch on return types could be _. like so:

Json.decodeUtf8 : List U8 -> Result val Problem
    where val.{ decodeBytes : List U8, JsonFmt -> Result val Problem }
Json.decodeUtf8 = \input ->
    _.decodeBytes(input, jsonUtf8Fmt)

Richard Feldman (Nov 10 2024 at 20:32):

for a minimal example, so if you put this into the repl...

\input -> _.decodeBytes(input)

...it would infer this type:

input -> output
    where output.{ decodeBytes : input -> output }

Richard Feldman (Nov 10 2024 at 20:33):

I think a downside of this compared to Abilities is that in the Abilities world, the type is kind of mind-bending but the call site looks totally normal, because you're just calling what appears to be an ordinary function (in the Ability's module)

Richard Feldman (Nov 10 2024 at 20:33):

whereas in this one the mind-bendingness appears sooner, namely in the value position

Richard Feldman (Nov 10 2024 at 20:34):

like it's more obvious at the call site that something unusual is happening

Richard Feldman (Nov 10 2024 at 20:34):

(which I guess is in some ways an upside, but mostly still feels like a downside to me haha)

Richard Feldman (Nov 10 2024 at 20:35):

but I do think this is worth preserving in the static dispatch world, because I really enjoy how Roc today has the ergonomics of JavaScript's JSON.parse() but with eager validation, and I wouldn't want to give that up :big_smile:

Richard Feldman (Nov 10 2024 at 20:36):

also, I believe the above should work fine with @Brendan Hansknecht's #ideas > Revamped Encode and Decode design

Richard Feldman (Nov 10 2024 at 20:36):

because all that requires is the "dispatch can happen on return type instead of arg type" capability, which this design provides

Brendan Hansknecht (Nov 10 2024 at 20:57):

Yeah, I think something like this would work well. Though I would very much like some form of alias for those records. Otherwise type signatures will get absolutely crazy

Richard Feldman (Nov 10 2024 at 20:58):

yeah totally

Richard Feldman (Nov 10 2024 at 20:58):

there's a section in the doc about that

Richard Feldman (Nov 10 2024 at 20:58):

"Type Aliases for where Constraints"

Brendan Hansknecht (Nov 10 2024 at 20:58):

I'm not sure about the _. vs requiring a name for those types of used. I think it might be better to force a name so it would be Decode.decodeBytes

Richard Feldman (Nov 10 2024 at 20:58):

I don't think that can work

Richard Feldman (Nov 10 2024 at 20:59):

I guess depending on what you mean

Richard Feldman (Nov 10 2024 at 20:59):

like what would the implementation of Decode.decodeBytes look like?

Richard Feldman (Nov 10 2024 at 20:59):

the body of that function I mean

Brendan Hansknecht (Nov 10 2024 at 22:11):

It wouldn't have an implementation

Brendan Hansknecht (Nov 10 2024 at 22:12):

It would just be part of a interface/trait/implementes alias.

Richard Feldman (Nov 10 2024 at 22:20):

but in this proposal we don't have those :thinking:

Richard Feldman (Nov 10 2024 at 22:40):

I think it would help to show a code example of how someone would define decoding in userspace, provide two different implementations, and then call it to actually perform some decoding

Richard Feldman (Nov 10 2024 at 22:40):

I don't think it can be done via static dispatch without having something like _. but maybe I'm missing something! :big_smile:

Brendan Hansknecht (Nov 10 2024 at 23:13):

I am suggesting that decode should still be explicit even if not a "ability" but maybe that is the same thing as an ability. I'm not sure.

Richard Feldman (Nov 10 2024 at 23:21):

hm, I don't follow

Richard Feldman (Nov 10 2024 at 23:21):

I think I need to see a code example, sorry :sweat_smile:

Brendan Hansknecht (Nov 10 2024 at 23:28):

Json.decodeUtf8 : List U8 -> Result val Problem
    where val.{ decoder : Decode.Decoder val }
Json.decodeUtf8 = \input ->
    jsonFmter = json.formatter(input)
    Decode.decodeWith(_.decoder, jsonFmter)

Would instead be:

# Decode Module
Decoding implements { decoder : Decode.Decoder val }

# Json Module
import Decode exposing Decoding

Json.decodeUtf8 : List U8 -> Result val Problem
    where val implements Decoding
Json.decodeUtf8 = \input ->
    jsonFmter = json.formatter(input)
    Decode.decodeWith(Decoding.decoder, jsonFmter)

Brendan Hansknecht (Nov 10 2024 at 23:29):

I think we still want something explicit that is similar to an ability for this.

Brendan Hansknecht (Nov 10 2024 at 23:29):

It also would be used when you want an explicit contract with multiple methods

Brendan Hansknecht (Nov 10 2024 at 23:30):

Static dispatch would still work the same for true methods that take the first argument of a specific type.

Richard Feldman (Nov 10 2024 at 23:30):

hm, I'm still missing something - in that code example, Decode.decodeWith is called but never defined - where would that be defined (and what would it look like)?

Brendan Hansknecht (Nov 10 2024 at 23:31):

still would be the same as stuff here: https://github.com/bhansconnect/roc-msgpack/blob/efb6ab52b1cc71e5b7306910fa18296df5c75d0a/package/FutureDecode.roc#L121-L133

Brendan Hansknecht (Nov 10 2024 at 23:32):

I can write up a full gist if you want

Richard Feldman (Nov 10 2024 at 23:32):

gotcha

Richard Feldman (Nov 10 2024 at 23:32):

so how would a custom type implement Decoding?

Richard Feldman (Nov 10 2024 at 23:33):

like in the proposal above, it's in the usual way of "if I want to implement custom decoding for my Foo type in the Foo.roc module, I expose Foo.decode and that's it"

Brendan Hansknecht (Nov 10 2024 at 23:33):

I guess I am saying that I want explicit interfaces of some sort. I think that the method dispatch should just work, but the functions that are not methods should be required to go through an explicit interface

Brendan Hansknecht (Nov 10 2024 at 23:34):

Probably would be opt in like abilities today. I mean we still need an opt in system so we can have auto derive for eq, hash, encode, decode, etc

Brendan Hansknecht (Nov 10 2024 at 23:35):

But could also be implicit by just exposing Foo.decoder

Brendan Hansknecht (Nov 10 2024 at 23:36):

I am realizing that I maybe arguing for essentially abilities through static dispatch or keeping both, but I think explicit interfaces are really important. I also am really not a fan of magic functions like _.decode. I think it should be tied back to something. This feels different than just static dispatch for methods.

Richard Feldman (Nov 10 2024 at 23:38):

hm, ok that feels like a pretty dramatically different proposal :sweat_smile:

Richard Feldman (Nov 10 2024 at 23:38):

seems worth a separate thread!

Brendan Hansknecht (Nov 10 2024 at 23:40):

hmm. I guess I have to figure out how to formulate everything. Cause I feel like static dispatch makes sense for methods, but expanding it magically to _.decode feels like adding a totally unrelated feature into static dispatch

Brendan Hansknecht (Nov 10 2024 at 23:40):

Like it is saying magically find the correct module and call the decode function in it essentially.

Brendan Hansknecht (Nov 10 2024 at 23:41):

Wait, would this proposal mean that decode no longer supports structural types?

Brendan Hansknecht (Nov 10 2024 at 23:41):

Cause only nominal types get static dispatch

Richard Feldman (Nov 10 2024 at 23:42):

no, we can infer it in the same way

Brendan Hansknecht (Nov 10 2024 at 23:43):

So static dispatch sometimes works for structural types. But only with _.fn syntax?

Richard Feldman (Nov 10 2024 at 23:44):

no, that's unrelated

Richard Feldman (Nov 10 2024 at 23:44):

like for example it also would work for equality on records

Richard Feldman (Nov 10 2024 at 23:45):

{ a: "foo" }.isEq({ b: "foo" }) would work

Brendan Hansknecht (Nov 10 2024 at 23:45):

Hmm....is that just compiler magic then? Feels weird to say static dispatch doesn't work with structural types, but I guess it does kinda.

Brendan Hansknecht (Nov 10 2024 at 23:45):

Cause I thought the core of static dispatch was it is only for nominal rypes

Brendan Hansknecht (Nov 10 2024 at 23:46):

Though maybe it is only for nominal types if the user is defining static dispatch, but the compiler itself is allowed exceptions

Richard Feldman (Nov 10 2024 at 23:47):

well I'd say the core idea is about looking up implementations based on type information

Richard Feldman (Nov 10 2024 at 23:47):

(which can also be said of abilities)

Richard Feldman (Nov 10 2024 at 23:47):

it's about looking them up using a different algorithm from abilities, with different tradeoffs

Brendan Hansknecht (Nov 10 2024 at 23:49):

Just to confirm a user would never be able to add to static dispatch for a structural type, correct? Those all have to be 100% compiler auto derived (like abilities today)

Richard Feldman (Nov 10 2024 at 23:51):

right

Richard Feldman (Nov 11 2024 at 01:33):

ok, here's an alternate design idea based on #ideas > custom types

Decode.roc

Decoder fmt val :=
    List U8, fmt -> Result val DecodingErr
        where
            val.{ decode : List U8, fmt -> Result val DecodingErr },
            fmt.{ ...etc },

decode : List U8, fmt -> Result val DecodingErr
    where fmt.{ ...etc }
decode = \bytes, fmt -> Decoder.0(bytes, fmt)

Richard Feldman (Nov 11 2024 at 01:34):

so the idea is that if you have a custom type wrapper around a function, you can access that function with Decoder.0

Richard Feldman (Nov 11 2024 at 01:35):

and doing that would only be supported if it has a where clause

Richard Feldman (Nov 11 2024 at 01:36):

which includes the function type itself somewhere

Richard Feldman (Nov 11 2024 at 01:38):

this is kind of a sketch (syntax doesn't feel quite right haha) but the idea is that instead of _. doing inference at the call site, you use a custom type to explicitly write out the signature of the function you expect

Richard Feldman (Nov 11 2024 at 01:38):

and then dispatch on that

Richard Feldman (Nov 11 2024 at 01:42):

I guess a simpler version of that design would be to let you literally just write the type annotation of the function directly:

decode : List U8, fmt -> Result val DecodingErr
    where
        val.{ decode : List U8, fmt -> Result val DecodingErr },
        fmt.{ ...etc },

Richard Feldman (Nov 11 2024 at 01:43):

and I guess the rule could be that if you write a function with no implementation, which has a where clause that requires one of the type variables in it to have a method with that exact type...

Richard Feldman (Nov 11 2024 at 01:43):

(so, val in this case, because this function's type is List U8, fmt -> Result val DecodingErr and val.{ decode : <that exact type> })

Richard Feldman (Nov 11 2024 at 01:44):

...then the implementation becomes inferred to be "go look up what val is and dispatch to that function"

Richard Feldman (Nov 11 2024 at 01:46):

and we could give an error (which would compile to a crash) if you have a standalone type annotation which doesn't fit this form, which would end up working the same way as today (in terms of using standalone type annotations for prototyping)

Richard Feldman (Nov 11 2024 at 02:46):

here's a more explicit idea:

decodeBytes : List U8, fmt -> Result answer DecodingErr
    where
        answer.{ decode : List U8, fmt -> Result answer DecodingErr },
        fmt.{ ...etc },
decodeBytes = \bytes, fmt ->
    import answer exposing [decode]

    decode(bytes, fmt)

Richard Feldman (Nov 11 2024 at 02:46):

so basically you can import using static dispatch to figure out what module is being imported, and then call functions from it

Richard Feldman (Nov 11 2024 at 02:47):

import from a type variable, that is

Richard Feldman (Nov 11 2024 at 02:48):

so you'd get an error if the type variable you were importing from was unsupported, e.g. it wasn't involved in a where clause with a particular shape etc.

Richard Feldman (Nov 11 2024 at 02:49):

could also do like:

    import answer as Decode

    Decode.decode(bytes, fmt)

Richard Feldman (Nov 11 2024 at 02:50):

what I like about this is that it isolates where the lookup is happening: the import is taking the type variable as its input and then giving you access to a module based only on that information

Richard Feldman (Nov 11 2024 at 02:51):

and then everything before and after the import works as expected

Richard Feldman (Nov 11 2024 at 12:43):

I wonder if some extra syntax could make it look more distinct from a normal import, e.g.

import answer.* as Decode

Decode.decode(bytes, fmt)

Richard Feldman (Nov 11 2024 at 12:57):

oh actually maybe it could be as in the type signature:

decodeBytes : List U8, fmt -> Result answer DecodingErr
    where
        { decode : List U8, fmt -> Result answer DecodingErr } as Decode,
        DecodingFmt fmt,
decodeBytes = \bytes, fmt ->
    Decode.decode(bytes, fmt)

Richard Feldman (Nov 11 2024 at 13:02):

so the idea would be that in the type signature's where you can use as to name the module where the function(s) get found, and then you can call them using that module qualifier in the function body

Derin Eryilmaz (Nov 11 2024 at 16:24):

It's complex, but I don't see a better way to do it

Derin Eryilmaz (Nov 11 2024 at 16:27):

i think when it comes to Decode you can't really have it figure the type out for itself. you'd need some kind of declaration to tell it what module to look for decode in, because there's no way to otherwise express "this function's implementation depends on the type of the first parameter of the Ok variant of the return type"

Derin Eryilmaz (Nov 11 2024 at 16:29):

most of the other uses of static dispatch have been "this function's implementatino depends on the type of the first parameter" which is a lot simpler to do, and can be the default

Richard Feldman (Nov 11 2024 at 17:39):

yeah what I like about this design is that it's probably surprising that you could use as in this way, but it does generally fit with what as does (that is, give a name to something that was already in scope), and - like as in general - I think it would be pretty rarely used

Brendan Hansknecht (Nov 11 2024 at 17:41):

I feel like thinking in a single function for isn't quite right either. You will want to be able to wrap and import a group of functions

Richard Feldman (Nov 11 2024 at 17:52):

sure, that definitely works in this design!

Brendan Hansknecht (Nov 11 2024 at 17:59):

How?

Richard Feldman (Nov 11 2024 at 18:27):

here's an idea for how that could look:

Decoder val fmt := List U8, fmt -> DecodeResult val
    where DecoderFormatting fmt

# how you specify a group of `where` constraints
DecoderFormatting fmt : where fmt.{
    u8 : Decoder U8 fmt,
    u16 : Decoder U8 fmt,
    ...etc
}

decodeBytes : List U8, fmt -> Result val DecodingErr
    where
        val.{ decode : List U8, fmt -> Result val DecodingErr } as Decode,
        DecoderFormatting fmt, # how you add a group of `where` constraints
decodeBytes = \bytes, fmt ->
    Decode.decode(bytes, fmt)

Richard Feldman (Nov 11 2024 at 18:35):

so the where fmt.{ ... } and where val.{ ... } essentially mean "all the functions in { ... } can be found in the module where the fmt type is defined (or where the val type is defined, in the other case)"

Richard Feldman (Nov 11 2024 at 18:36):

and the alias format of DecoderFormatting fmt : where fmt.{ would mean "this is a where alias, so adding where DecoderFormatting fmt to a given where clause essentially inlines everything in the alias into that where

Richard Feldman (Nov 11 2024 at 18:36):

and then a where alias is how you specify groups of related statically-dispatched functions, like we do today with Abilities

Richard Feldman (Nov 11 2024 at 18:38):

a simpler example:

Eq a : where a.{ isEq : a, a -> Bool }

List.isEq : List a, List a -> Bool
    where Eq a

Derin Eryilmaz (Nov 11 2024 at 18:46):

i like that syntax a lot actually

Derin Eryilmaz (Nov 11 2024 at 18:57):

lot nicer than the implements stuff we have today

Derin Eryilmaz (Nov 11 2024 at 18:59):

I wonder if we could also add default functions with ? in the where record :fear:

Derin Eryilmaz (Nov 11 2024 at 18:59):

although maybe that isn't necessary

Derin Eryilmaz (Nov 11 2024 at 18:59):

but it would allow default methods (written in terms of the other functions in the ability) that could be overwritten

Richard Feldman (Nov 11 2024 at 19:02):

yeah that sounds unnecessary :sweat_smile:

Richard Feldman (Nov 11 2024 at 19:36):

a way this could be taught:

First, teach that \val, arg -> val.foo(arg) has this inferred type:

val, arg -> ret
    where val.{ foo : val, arg -> ret }

Then, explain that in this syntax, where val.{ foo : val, arg -> ret } means:

• The .{ foo : val, arg -> ret } part means that we're expecting a module to have a top-level foo function with this type
• The val. at the front means "the module we expect to have that function is the module where val is defined"
  • If it turns out we can't access that module's top-level function from this scope, we get a compile-time error.
• Method calls generate this inferred type by default, but you can also write it out by hand and use as to name the module where val is defined.
  • Once you've named that module, you can call any of the functions in it that the type specifies are there (e.g. the decode example).

Richard Feldman (Nov 11 2024 at 19:36):

so at a type level, the whole thing is just about how we find modules

Richard Feldman (Nov 11 2024 at 19:36):

and it's just the method-call syntax of foo.bar(baz) that has anything to do with the first argument

Richard Feldman (Nov 11 2024 at 19:36):

which is to say, the first argument is the one that gets chosen for val.{ ... } in the type

Derin Eryilmaz (Nov 11 2024 at 19:38):

completely agree with everything you just said

Derin Eryilmaz (Nov 11 2024 at 19:40):

should we go with Eq a or a.Eq as a shorthand?

Derin Eryilmaz (Nov 11 2024 at 19:41):

personally I'm liking the second one

Derin Eryilmaz (Nov 11 2024 at 19:41):

fits in with the module theme of using dots

Richard Feldman (Nov 11 2024 at 20:34):

that could work!

Richard Feldman (Nov 11 2024 at 20:34):

so then multiples would be like where a.Eq, a.Hash?

Derin Eryilmaz (Nov 11 2024 at 20:47):

yeah, that sounds good

Richard Feldman (Nov 11 2024 at 21:18):

oh, I realized a problem: the type alias could have other type variables

Richard Feldman (Nov 11 2024 at 21:18):

e.g. Container a elem

Richard Feldman (Nov 11 2024 at 21:19):

hm, although actually I'm not sure if we want to support that :thinking:

Richard Feldman (Nov 11 2024 at 21:19):

so maybe that's a feature, not a bug haha

Derin Eryilmaz (Nov 11 2024 at 21:25):

too complex I think. it should only have one type variable which is the type in question from the same module

Richard Feldman (Nov 13 2024 at 15:37):

Richard Feldman said:

here's a more explicit idea:

here's a variation on this design:

decodeBytes : List U8, fmt -> Result answer DecodingErr
    where
        answer -> { decode : List U8, fmt -> Result answer DecodingErr },
        fmt -> { ...etc },
decodeBytes = \bytes, fmt ->
    import answer as Answer

    Answer.decode(bytes, fmt)

Richard Feldman (Nov 13 2024 at 15:38):

so this is kind of similar to how we use -> in module params:

where
    answer -> { decode : List U8, fmt -> Result answer DecodingErr },

it's like "given this answer type variable, we get back a module with decode which has this type

Richard Feldman (Nov 13 2024 at 15:45):

and maybe we should have the "method type in where" option available as syntax sugar, because it looks more self-explanatory and might be helpful for teaching. So this:

where
    elem.equals(elem) -> Bool

...would mean the same thing as this:

where
    elem -> { equals : elem, elem -> Bool }

Richard Feldman (Nov 13 2024 at 15:49):

there's an argument for having just one syntax for it, so you don't have to learn two. The counterargument is that the first one is a lot nicer to read, and easier to understand (especially for a beginner), and is the one that will come up way more often. The second one only really needs to exist for uncommon use cases like decoding.

Richard Feldman (Nov 13 2024 at 15:52):

a potential counterargument to that is that you'd usually have type aliases anyway (e.g. where elem.Eq), but a counterargument to that is that this is the syntax that would be used to define those type aliases, so you'd still be exposed to it when interacting with the definition of the aliases (or creating your own)

Richard Feldman (Nov 13 2024 at 15:54):

I guess another potential syntax that combines the above two:

where
    elem -> equals : elem, elem -> Bool

Richard Feldman (Nov 13 2024 at 15:58):

so in that design, these would mean the same thing:

Eq a : where
    a -> equals : a, a -> Bool

Eq a : where
    a.equals(a) -> Bool

Agus Zubiaga (Nov 13 2024 at 16:56):

Couldn’t we let you do many of the method syntax and have only that variant?

Agus Zubiaga (Nov 13 2024 at 16:57):

The variable on the left of . already tells you which type it’s on

Agus Zubiaga (Nov 13 2024 at 16:58):

I think we could just let you define as many methods as you want on the same or different type variable

Richard Feldman (Nov 13 2024 at 16:58):

the problem is that decode doesn't take the dispatched type as its first argument:

where
    answer -> { decode : List U8, fmt -> Result answer DecodingErr },

Richard Feldman (Nov 13 2024 at 16:58):

so you can't just write where answer.(...) -> ...

Richard Feldman (Nov 13 2024 at 16:59):

because that's the syntax for answer being the first argument

Richard Feldman (Nov 13 2024 at 16:59):

but in the case of decode it's not the first argument, it's in the return type

Agus Zubiaga (Nov 13 2024 at 16:59):

Ah right, sorry

Richard Feldman (Nov 13 2024 at 16:59):

yeah if we only ever had these in the "first argument" position, then we would totally just do the nicer syntax

Richard Feldman (Nov 13 2024 at 17:00):

but then we lose out on being able to decode directly into things, which would be a way bigger downside than having some less-nice syntax some of the time :big_smile:

Agus Zubiaga (Nov 13 2024 at 17:08):

I guess this would work if we used :: instead of . for module qualification:

where
    answer::decode(List U8, fmt) -> Result answer DecodingErr,

Richard Feldman (Nov 13 2024 at 17:09):

yeah, although then we miss out on . being the universal autocomplete syntax

Richard Feldman (Nov 13 2024 at 17:09):

feels like a pretty invasive solution to a really niche problem :thinking:

Richard Feldman (Nov 13 2024 at 17:12):

where
    elem.equals(elem) -> Bool

where
    answer -> decode(List U8, fmt) -> Result answer DecodingErr

Richard Feldman (Nov 13 2024 at 17:13):

I don't like the double -> in that :sweat_smile:

Richard Feldman (Nov 13 2024 at 17:15):

where
    elem.equals(elem) -> Bool

where
    decode(List U8, fmt) -> Result answer DecodingErr for answer

Agus Zubiaga (Nov 13 2024 at 17:17):

where
    module [answer] as m,
    m.decode(List U8, fmt) -> Result answer DecodingErr,

:sweat_smile:

Richard Feldman (Nov 13 2024 at 17:18):

where
    elem.equals(elem) -> Bool

where
    (module answer).decode(List U8, fmt) -> Result answer DecodingErr

Agus Zubiaga (Nov 13 2024 at 17:19):

Not bad for a niche feature

Richard Feldman (Nov 13 2024 at 17:19):

yeah the module keyword makes it really clear that it's a module :big_smile:

Agus Zubiaga (Nov 13 2024 at 17:21):

Should it be (module [foo, bar]). in case you need two types?

Richard Feldman (Nov 13 2024 at 17:21):

hm I don't think we can support that

Richard Feldman (Nov 13 2024 at 17:21):

the key is that we have to figure out which module to look in to find the decode function

Agus Zubiaga (Nov 13 2024 at 17:22):

Yeah, I mean the case where both types are in the same module

Richard Feldman (Nov 13 2024 at 17:22):

(module answer).decode would mean "go find the module where answer is defined; that's where the decode function can be found

Agus Zubiaga (Nov 13 2024 at 17:23):

I guess it would resolve to the same module anyway

Richard Feldman (Nov 13 2024 at 17:23):

yeah

Richard Feldman (Nov 13 2024 at 17:24):

and then I guess you could do:

where
    elem.equals(elem) -> Bool

where
    (module answer as M).decode(List U8, fmt) -> Result answer Bad

...and then call M.decode in the function body

Richard Feldman (Nov 13 2024 at 17:25):

hm actually no

Richard Feldman (Nov 13 2024 at 17:25):

because if there's more than one, it gets awkward

Agus Zubiaga (Nov 13 2024 at 17:25):

Yeah, that’s what I was going for with the separate module “entry”

Richard Feldman (Nov 13 2024 at 17:25):

where
    (module answer as M).decode(List U8, fmt) -> Result answer Bad
    (module answer as M).other(List U8) -> Result answer Bad

vs like

where
    (module answer).decode(List U8, fmt) -> Result answer Bad
    (module answer).other(List U8) -> Result answer Bad

Agus Zubiaga (Nov 13 2024 at 17:25):

Agus Zubiaga said:

where
    module [answer] as m,
    m.decode(List U8, fmt) -> Result answer DecodingErr,

:sweat_smile:

This

Richard Feldman (Nov 13 2024 at 17:26):

I think it's fine if it's a bit more verbose

Richard Feldman (Nov 13 2024 at 17:26):

like repeating the (module answer). each time

Richard Feldman (Nov 13 2024 at 17:26):

because if you're doing that, you'll prob put it in a type alias, so it'll only be verbose once

Richard Feldman (Nov 13 2024 at 17:26):

and then inside the function body you do:

import answer as M

Agus Zubiaga (Nov 13 2024 at 17:30):

Yeah, that’s probably fine

Richard Feldman (Nov 13 2024 at 17:37):

a thing I like about this:

where
    (module answer).decode(List U8, fmt) -> Result answer Bad
        where fmt.DecodeFormatting,

    (module answer).other(List U8) -> Result answer Bad,

...is that it (correctly) suggests that each of these has their own type variable namespaces, and that (for example) the name fmt is local to that where clause and isn't shared across clauses.

as opposed to like (module answer).{ decode : ..., other : ... } where I'd assume all type variables inside the curly braces share one namespace, like they do in record types

Richard Feldman (Nov 13 2024 at 17:43):

...although I guess this could also achieve that:

where
    module answer as M,
    M.decode(List U8, fmt) -> Result answer Bad
        where fmt.DecodeFormatting,

    M.other(List U8) -> Result answer Bad,

Agus Zubiaga (Nov 13 2024 at 17:53):

Yeah, I find that last one nicer overall, but this is pretty niche so I would be ok with either

Brendan Hansknecht (Nov 13 2024 at 17:54):

I think something that is important is grouping all functions from a module. I think we should design the syntax to aggregate by module (aka type variable).

Brendan Hansknecht (Nov 13 2024 at 17:56):

This is mostly important when you have multiple type variables that import multiple functions. Grouping helps with recognizing what exact variable can or can't do

Derin Eryilmaz (Nov 13 2024 at 18:01):

there was a concern previously about type definitions that looked like

func  :  a -> f where
           a implements { reserve: a, Num b -> c },
           c implements { append: c, Num d -> e },
           e implements { reverse: e -> f }

I wonder if this could also be written as

func : a -> d where
           a.reserve(Num b).append(c).reverse() -> d

maybe not, but...

Brendan Hansknecht (Nov 13 2024 at 18:06):

That works as long as there is only one chain.

Sam Mohr (Jan 07 2025 at 05:23):

Richard Feldman said:

...although I guess this could also achieve that:

where
    module answer as M,
    M.decode(List U8, fmt) -> Result answer Bad
        where fmt.DecodeFormatting,

    M.other(List U8) -> Result answer Bad,

just to clarify, it seems like this is the latest suggestion, one which people are positive on, and a function that uses it would look like:

decode_bytes : List U8, fmt -> Result answer [DecodeFail DecodingErr, GenFail GenErr]
    where
        module answer as M,
        M.decode(List U8, Str, fmt) -> Result answer DecodingErr
            where fmt.DecodeFormatting,

        M.gen_title(List U8) -> Result Str GenErr
decode_bytes = |bytes, format|
    import answer as Ans # I presume it doesn't have to be named M?

    title = Ans.gen_title(bytes)?
    Ans.decode(bytes, tytle, format)

Sam Mohr (Jan 07 2025 at 05:23):

Is anyone unhappy with this syntax?

Ayaz Hafiz (Jan 07 2025 at 05:27):

syntax lgtm but i wonder if there's a way to make this less verbose.. don't have any good ideas off the top of my head other than abilities/aliases but will think

Sam Mohr (Jan 07 2025 at 05:27):

Sounds great! Make sure to wear a helmet when you think that hard

Ayaz Hafiz (Jan 07 2025 at 05:27):

whats the fun in that

Sam Mohr (Jan 07 2025 at 05:28):

You have a point (where your head used to be)

Last updated: Jun 16 2026 at 16:19 UTC