For implementation it would be nice to specify built-in types in grace code (or as close to it as possible) along with their behavior or in a separate table. Since there are many objects in grace an appendix of built-in objects would probably clutter the spec less than including all their definitions inline.
I think just the types can be specified, and a type literal can be used if the type has no need for a name. Done, None might need some special handling. Of course the Type type will have to be defined clearly as well.
Gathering up objects from the spec:
Type, None, Unknown
done
The grace object
Blocks, Lineups, Strings, Numbers, Booleans
Patter matching objects
All exceptions that can arise from the core language (also touched on in #57)
With these in place some tests can be written with or without reflection to verify that a grace implementation defines its built-in objects correctly. This would help multiple implementations achieve some uniformity.
For implementation it would be nice to specify built-in types in grace code (or as close to it as possible) along with their behavior or in a separate table. Since there are many objects in grace an appendix of built-in objects would probably clutter the spec less than including all their definitions inline.
I think just the types can be specified, and a type literal can be used if the type has no need for a name. Done, None might need some special handling. Of course the Type type will have to be defined clearly as well.
Gathering up objects from the spec:
Type, None, Unknown done The grace object Blocks, Lineups, Strings, Numbers, Booleans Patter matching objects All exceptions that can arise from the core language (also touched on in #57)
With these in place some tests can be written with or without reflection to verify that a grace implementation defines its built-in objects correctly. This would help multiple implementations achieve some uniformity.