luxe/unilang

semiotic breakdown (lack of binary signifies/signified combinations)

luxe opened this issue · 1 comments

luxe commented

if semiotics have taught me anything, its that I'm missing signifiers to particular signified objects.
In particular, multiple signifiers when combined equate to a single signified, (which in my language, and every other language) remains unamed. The point is, take either model of a sign (saussure to pierce), and make sure we can reprsent the language recursively in this way at the level of visible signs. and ensure they can be disjoint from other signs. This is an important realiszation, because I've already noticed myself doing this on multiple occasions. On the other hand, its essentially an argument against composition for everything being associated. (Don't worry, the transcompilation process will still use composition). But what I'm saying is, we express composition in the language not through composition itself, but through association.
We also allow for areas to bundle concepts/tokens/signs and give them their own name (signifier) to be used elsewhere.

so lets take a [mr][int][val].
This becomes its own language level concept that could be named (and in many times be implicitly named for you)

[changeable_val]
[mr][int][val]

/\ example not that important.

But now multiple functions can use [changeable_val] directly.

We've already done the same thing with dependencies (module/header/link/etc) onto types.

What does this mean for the language? It means the user (if they want to be more granular; and in customizable cases will be enforced to) specify closer to (signifiers)->signified where each signified is used as part of another level of a signifiers part to create another signified.

Ideally we want the (signifiers) to only be one name or one symbol, we may relax this on more discrete cases (such type annotations for parameter passing as talked about above)

Keep in mind, this is already a compositional association we did for sharing a data member between two structs, and how we build structs today. (more generally, I mean product/sum types) We give the data members their parent relations.

luxe commented

I think we will also be able to pull some ideas of "Semiotics of Programming" by Kumiko