Yeah, well... I guess I have ideas how to make it work but that might not work in reality ; _ ;
just hate how positional all the currying and pairing stuff is - as much as it's nice in some cases then stuff lines up properly
Conversation
I had this weird (probably bad) idea to have records with 'abstract' fields that you could make concrete later - which would end up kind of being like functions? And you'd be able to have a 'default' field that your record would reduce to if all the fields were concrete.
2
1
Records with abstract fields are kind of like functions. But there would be sugar on top to make it look more familiar. Hoping this might help with the issues around bundled and unbundled modules: alhassy.github.io/next-700-modul - but I dunno.
1
1
So you'd have:
{
?A : Type,
op : [A, A] -> A,
}
Which could be sugar for:
{
?A : Type,
op : { ?0 : A, ?1 : A, default : A },
}
1
1
And then something like this maybe:
{
add-int-magma : Magma.{A = Int} = {
op = [x, y] => x + y,
},
test-add-int : Int = add-int-magma.op.[1, 3],
}
2
1
This:
add-int-magma.op.[1, 3]
would elaborate to:
add-int-magma.op.{0 = 1, 1 = 3}.default
2
1
But this might break a bunch of nice stuff in the type system and might be a really ✨Bad✨ idea. 😅
2
2
All my instincts tell me that this particular variant is indeed a Bad Idea. You want your 'functions' to be continuous - which, in this case, means given by a uniform definition of the inputs. But in the same neighborhood of this idea, I'm sure there are some good designs.
2
2
One important thing to note, it might have not been clear from my examples, but the `?` on some of the fields was significant - it marks 'unknown' parameters that can be made concrete later on. Anyway, still probably a bit of a silly idea and not sure it makes a difference.
worth exploring to find out *why* it is or isn’t silly, maybe?
2
1