Update Specification #20
Conversation
Note that this is the Specification where I want us to be, not the one where we are. I am doing this in form of a pull request to get feedback in.
|
|
||
| 1.7) The number in local keys must be consecutive. | ||
| 1.8) Values of key-value pairs of all ZObjects must be ZObjects. |
There was a problem hiding this comment.
I don't see how this is possible; there must be primitive values somewhere, or you get a "turtles all the way down" scenario! Take something of type Z6 (string) - for example Z28. The value of its Z6K1 key has to be the bare string, not another Z object, or how do you ever end up with the value 'eneyj'?
There was a problem hiding this comment.
So I've been thinking about this some more. Maybe 'string' is really the only primitive type needed? And any case where a string could appear COULD be replaced by a Z6 ZObject instead (but not indefinitely, at some point there has to be a string). Code (in function implementations), positive integers (the values) and any other numeric types we might have can all be represented ultimately as strings or key-value pairs with string values. We may run into a need for something else down the road, but I think what I'd suggest here is to simply say "Values of key-value pairs of all ZObjects must be either ZObjects or strings; keys with a string value can also take a string-type ZObject as value." Something like that maybe?
There was a problem hiding this comment.
Hmm, maybe this should work in a specification for references here as well? That's a case where you need to distinguish between the values of "Z99" as a reference and the string "Z99", so it is necessary to encapsulate the "Z99" value into a string ZObject if the string form is meant.
There was a problem hiding this comment.
The serialization displays a simple string, but it is to be interpreted as a String object. Yes, this does mean its turtles all the way down, but since this is lazy evaluated, I think that's OK.
But I see your point and will think about it further.
| 4.11) Two Z Objects with the same Z1K2 ID must be equal. | ||
| This is modulo QA procedures, caching, and metadata. | ||
| They are equal using Z33 same. | ||
| 7.3) There is no type hierarchy. |
There was a problem hiding this comment.
I'm dubious this can be maintained, but I guess let's go with it for now. Do you want to mention Z1 here though?
There was a problem hiding this comment.
I added a sentence mentioning Z1 here.
| 5) Labels | ||
| 7.5) If the Z1K1 points to a function call, the function call needs to be | ||
| evaluated in order to get the Z4 object back. | ||
| The result of the evaluation is the type. |
There was a problem hiding this comment.
Ok, this is close to the approach we discussed the other day...
eneyj/docs/SPECIFICATION
Outdated
| 5.3) An eneyj implementation may use the Z1K3 labels and Z1K5 aliases to | ||
| support the selection of a Z Object by the user. | ||
| 8.2) A function can choose to handle an error, but has to state that it | ||
| will do so explictly in its signature. |
There was a problem hiding this comment.
signature = type? I don't think signature has been defined yet!
There was a problem hiding this comment.
Ah good point, clarified.
eneyj/docs/SPECIFICATION
Outdated
|
|
||
| 11) Errors | ||
| head_type : [type] -> zobject function(list(zobject)) |
There was a problem hiding this comment.
I'm not sure quite what notation is being used here, this doesn't entirely made sense. Do you have a reference? Is this related to the notation in Benjamin Pierce's book?
There was a problem hiding this comment.
I removed that. That section was too drafty for now.
Note that this is the Specification where I want us to be, not the one where we are.
I am doing this in form of a pull request to get feedback in.