Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add an API to declare the standard "prelude" types to a schema type system #208

Closed
mvdan opened this issue Jul 22, 2021 · 5 comments
Closed

Comments

@mvdan
Copy link
Contributor

mvdan commented Jul 22, 2021

See #207 (comment).

@mvdan
Copy link
Contributor Author

mvdan commented Jul 23, 2021

Bonus points if this also makes initializing a typesystem easier. Right now it's:

ts := schema.TypeSystem{}
ts.Init()
// accumulate all basic types

Would be nice if it was instead just something like:

ts := schema.StandardTypeSystem() // already includes basic types

@mvdan
Copy link
Contributor Author

mvdan commented Aug 31, 2021

The new func MustTypeSystem(types ...Type) *TypeSystem in master seems close to this; imagine if I could do:

ts := schema.MustTypeSystem(schema.Prelude...)

I'd slightly prefer just schema.StandardTypeSystem() though, since it would be clearer it should never error/panic, and it's also more descriptive without the schema. package repetition.

@mvdan
Copy link
Contributor Author

mvdan commented Aug 31, 2021

FYI @warpfork ^ since you did #232

@warpfork
Copy link
Collaborator

warpfork commented Sep 2, 2021

Yeah, we should have something for this.

I didn't form strong opinions on how exactly it should be written (because I still sort of wish we could get away from these golang constructors at all, but, here we are for a while yet, it seems).

A list of prelude types that one can unroll into the varargs for MustTypeSystem would seem good, I guess, if we can get away with something that light.

Or, I've also now a couple of times had the wish for a constructor method for TypeSystem that takes both an existing TypeSystem and a list of new types and just adds them together to form a new one. (This mostly has come up in tests, and I'm not sure the desire is very correct, on second thought. Just a thought.)

@mvdan
Copy link
Contributor Author

mvdan commented Jan 20, 2022

dmt.Compile now spawns the full prelude:

// Prelude; probably belongs elsewhere.
{
ts.Accumulate(schema.SpawnBool("Bool"))
ts.Accumulate(schema.SpawnInt("Int"))
ts.Accumulate(schema.SpawnFloat("Float"))
ts.Accumulate(schema.SpawnString("String"))
ts.Accumulate(schema.SpawnBytes("Bytes"))
ts.Accumulate(schema.SpawnAny("Any"))
ts.Accumulate(schema.SpawnMap("Map", "String", "Any", false))
ts.Accumulate(schema.SpawnList("List", "Any", false))
// Should be &Any, really.
ts.Accumulate(schema.SpawnLink("Link"))
// TODO: schema package lacks support?
// ts.Accumulate(schema.SpawnUnit("Null", NullRepr))
}

And I think we're in agreement that the vast majority of users should use schemas by using ipld.LoadSchema and the DSL rather than manually spawning and accumulating types.

For that reason, I think we can close this issue. Note that the prelude doesn't include Null right now; that's blocked on support for unit typekinds, so I've raised #336 as a reminder.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants