Discussion - namespace of functions and other types

[lubianat]

Hello,

Great work. I do not know if it is a study question, but I was wondering: why functions and other types end up in the same namespace?

It seems to me that these two groups of objects are very different:

• ZID1 -> "type": something (where something's type is type)
• ZID2 -> "type":function

Also, this seems as another special kind of object:

• ZID3 -> "type":type

I was thinking about how to make it clearer. One option is different namespaces for types, functions and other classes.

Other is to have an additional property/relation/key:

• ZID1 -> "primitive class": "instance of a type" ; type: something
• ZID2 -> "primitive class": "type" ; type:type
• ZID3 -> "primitive class": "instance of a function" ; type: function

The idea is to avoid mixing of primitive and non-primive types.

(I am still getting to understand the details of the project. If this does not make sense, please, disregard it).

[vrandezo]

Thanks for the question! I am sorry, I am really bad at explaining, so the questions are super useful to clarify things. Thanks for digging through the material and trying to make sense of it.

My hope is that there is basically no distinction between the Function type and other types, in fact, that there is no such thing as a primitive type.

To give an example: the implementation of the lambda calculus in eneyj doesn't actually use object of type function. If you look at Z41 i_combinator, it is not of type Z8 function, but of type Z40 lambda. And yet you can call i_combinator(i_combinator) and it will evaluate (to i_combinator, because the i_combinator is just identity as per https://en.wikipedia.org/wiki/SKI_combinator_calculus , defined as λx.x)

And Z40 lambda is, if I remember it correctly, implemented entirely within user-space of abstracttext, and has nothing hardcoded in eneyj itself - so there is no real difference between functions and other types. They can be user defined, and thus it is simpler to have them all in the same namespace.

One other option would have been to have every type in its own namespace, but since some day we might have coercion, subtypes, or on-the-fly created types, this will likely be unfeasible at some point. So I have them now all in a single namespace.

This is not set in stone.

Thank you for the question! Feel free to continue the conversation here, or to close it if this answers the question. (And start new issues whenever you like)

[lubianat]

Thank you!

It answers the question.

Maybe, then, it would be interesting to rephrase this bit of the docs:

"Types of Z-Objects
The type field of Z385 in the first screenshot above linked to "positive integer". Positive integer is not a primitive type in AbstractText, but is defined in AbstractText itself, in fact as the Z-Object with the ZID Z70."

When it says that "Positive integer is not a primitive type" it seems like there is such a thing as primitive types (at least for me that was the case).

Maybe just adding "there is no such thing as a primitive type." and a link to this response, if someone wants to know more about it, would already be of help.

[vrandezo]

Good point! I explicated that there are no such things as primitive types. Thank you!

c49f909