kabirkbr
commented
3 years ago 
Open kabirkbr opened 3 years ago
kabirkbr
commented
3 years ago
kabirkbr
commented
3 years ago Nil, 18/02/2021 / Slack
It seems clear to me that we'll eventually want to formally define everything. I.e. actually purely define "time", "PyTorchTensor", etc (even if "purely" may sometime mean "experientially" when we don't know any better). Obviously that's a crazy big endeavour, but IMO necessary in the long run. If everything if formally defined, then decentralized consensus on semantics can be achieved I believe. Regardless, fortunately we don't need worry about that at this stage, although it's always nice to think about it.
And obviously AI will eventually be able to help, but that's another chapter.
alexey 2021/02/17 / slack
I have some doubts regarding a fully decentralized ontology. My intuition is that services should apparently be free to introduce new types using GADT / dependent types, and this doesn’t cause any conceptual problem. But I’m not that sure about new grounded types. I’m not sure if we are going to use grounded types in AI-DSL at all (e.g. we cannot purely formally define “time”; if AI-DSL type system / ontology has to refer to the concept of time, it will be a symbol grounded in the external world), but if yes, there should be some basic types built-in in AI-DSL. Maybe, it will be enough to have them and dependent types on top of them. It depends on how much semantics we want to involve in AI-DSL. For example, if someone wants to say that their service accepts 2D signals, it’s not an issue. But if we want to distinguish, e.g., optical images and MRT images, or songs (for the soundsplitter service) and voice (for speaker recognition) we need some standards to describe this, or otherwise it will be a mess. The next question, how and where these standards will be defined and how they will evolve. Maybe, we were not going to bite the bullet of real-world semantics in AI-DSL at all for now… But I’m also not sure about locally used Type Providers and FFIs either (i.e. types grounded not in physical world, but in some opaque computations). If we want these types to be used somewhere outside one service (and apparently if we want the service to have them in its API, we do want this), then they should be accessible outside it. Of course, if you only mean that services themselves can be considered as type providers, then it makes sense. But it means that these types cannot be reused separately from these services (e.g. MyServiceType a b means calling MyService with a and b type arguments). Other services can pass MyServiceType info to each other, but this will be just a reference to the unique service. So, it’s not an introduction of new sharable types. We can create a sizeTSize type this way, only if it is introduced as a service or if there is a global agreement that it refers to the concrete implementation of C++ size_t type. We can use type providers to introduce, say, pytorch tensors this way. But if one service just says “I have PyTorchTensor” type, and another service says the same, how can these types be identified? How can we check that we can pass PyTorchTensor output of one service to the input of another? They need to wrap the same computational entity, and we need to have means that the entity is the same. Maybe it is doable in a decentralized way, but looks complicated…