Orthogonal concepts

@keean

I am trying to nail down in my mind, the fundamental orthogonal semantic concepts of our proposed programming language.

Concept	Description
`data`	Unified sum, product, recursive, and record data types. No early bound operations other than construction and access. Record types may optionally be mutable.
`typeclass`	Delayed binding of operations to types at the use-site. Contrast to OOP (subclassing) which binds operations at construction of objects. For polymorphic types, typeclass objects delays binding operations until construction of the typeclass object (instead of prematurely binding operations at the construction of an instance of the implementing type); whereas, my posited and proposed solution to the Expression Problem employing unions, in theory further delays binding to the use-site for polymorphic types. Note that delaying is a positive attribute in this context, because it increases degrees-of-freedom.
`module`	Encapsulating `data` with compile-time (statically) bound operations and access control, enabling more sophisticated types.
monadic effect system	#4 (comment)

Thus I am wondering if module is the most apt name for the concept? I think of a module as a unit of code that is imported separately. We still need to import data and typeclass, so is this done by files? Isn't each file then a module? If so, what is the apt name for the concept of module above? I am thinking the above concept for module is really a class (without the subclassing inheritance anti-pattern). Can't modules extend other modules?

Edit: note also OCaml functors and modules.

Edit#2: on typeclasses, I replied to @keean:

Optional implicit parameters (which Scala has) provide a way of unifying runtime interfaces (passed by value) and monomorphisable interfaces (passed implicitly by type).

I like that summary (in the context of what I had written). We should make sure we frame that and use it in our documentation.

Edit#3: @shelby3 wrote:

I think it is important to remember that we want to keep implementation of interface (i.e. typeclass) orthogonal to instantiation of data, otherwise we end up with the early binding of subclassing. For example, in subclassing both a rectangle and a square would be subclasses of an interface which provides width and height. Yet a square only has one dimension, not two. Any interfaces which need to operate on the dimensions of rectange and square need to be customized for each, which is what typeclasses do. We will still have subtyping such as when an interface extends another interface then we can subsume to the supertype (which is why we need read-only references and for supersuming then write-only references). Yet references will not have the type of an interface if we don't provide typeclass objects, so then the only case of subtyping will be the subset relationships created by conjunctions and disjunctions of data types.

Yes, I think that is correct. We basically split objects into three orthogonal concepts, data are effectively object properties, typeclass are inferfaces, an modules control data hiding (privite data etc).

Note: Elsewhere I proposed that we can combine the three into a single syntax and generic concept, but lets leave that to one side for now.

Did you see my edits pointing out that 'module' has two meanings? Should we use another keyword than module?

Extension and functors are something ML supports on modules, at the moment I don't think we should. I like the ability to have multiple modules in one file, but effectively modules are able to be separately compiled and linked later. In the simplest form they are like namespaces where you cannot access their private data from outside. A module has to export things to be visible outside, and import the external functions and data in order for them to be visible inside.

Note I added the idea for a monadic effect system. Well I guess it isn't orthogonal in some sense as its implementation relies I suppose on the other 2 or 3 concepts, but the systemic model for handling of impurity is an orthogonal concept.

@shelby3

@shelby3 wrote:

Concept Description

typeclass Delayed binding of operations to types at the use-site. Contrast to OOP (subclassing) which binds operations at construction of objects. For polymorphic types, typeclass objects delays binding operations until construction of the typeclass object (instead of prematurely binding operations at the construction of an instance of the implementing type); whereas, my posited and proposed solution to the Expression Problem employing unions, in theory further delays binding to the use-site for polymorphic types. Note that delaying is a positive attribute in this context, because it increases degrees-of-freedom.

I want to raise this conceptualization of solving the Expression Problem to a matrix, so that we can how this plays out on more levels.

Background

Dynamic polymorphism is instituted whenever we bind the interface to an object and refer to the type of that object as the interface; Because whether it be at data type object instantiation for subclassing or typeclass object instantiation (aka Rust trait objects), we then must incur dynamic dispatch because when holding a reference of said interface type at compile-time, there is no static (compile-time) knowledge of the types of data that can be referenced with the said interface type (rather the runtime dynamic dispatch handles the dynamic polymorphism). In subclassing the interface is a supertype and in typeclass objects, the interface is the typeclass bound (constraint) on data types that can be assigned to a reference with said type.

So the lesson that once we bind an interface at compile-time before the function call site, then we forsake static polymorphism and the opportunity for mono-morphisizing the function. More importantly, we lose the axis of the Expression Problem to add new interfaces (operations) to the data types referenced via an interface type. We can add new data types but can't add new operations.

Subclassing binds the interface very early at data type instantiation. Typeclass objects bind later at typeclass object instantiation. And typeclass bounds bind even later at the function call site.

So ideally, we wanted to always delay to typeclass bounds, but this conflicts with polymorphism of adding data types orthogonally when dealing with heterogeneous union types. Thus I pointed out that by retaining the union of data types instead of prematurely subsuming them to the typeclass bound of a typeclass object, then we could delay the binding to the function call site. Thus we can continue to add new orthogonal operations to the union type, unlike for typeclass objects. The trade-off is that adding a new type to a union type requires invariant collections (such as a List); whereas, typeclass objects will interopt fine with arrays because the type of the array doesn't need to change when adding new data types to an exist typeclass object type. I explained this is more detail in prior linked discussion. Readers can refer to the prior explanation, so I don't need to repeat it here.

Matrix Conceptualization

So what we can see is there is a tension with trade-offs between the competing choices of carrying around the specific data types and subsuming to the interface. So both are needed for different situations.

Recently @skaller pointed out another axis of this tension. That is in the case where don't want to discard the data types because we want to leave them open to new operations, but we want to dictate that a specific implementation is used for a specific typeclass where ever it might be needed. Apparently OCaml's functors accomplish this by being first-class and one can pass these along with a module and they will morph the module with the specific constraints desired, while leaving the rest of the module unspecialized, and thus through the chaining of functors, one can get the same effective result as early binding for one typeclass but remaining open to extension for other typeclasses.

So really what we need is to being able to attaching a typeclass object to a data type instance and pass them around as a pair every where a data type is expected. So in other words, dynamic patching of the dictionary for the dynamic dispatch, wherein if that data type is then applied to a trait object at a call site or trait object assignment, then the prior binding is not overwritten and any additional dynamic dispatch bindings are augmented.

So then we no longer view data types and typeclass objects separately. A data type always has a dynamic dictionary attached to it, yet it is augmented at runtime, not with compile-time knowledge. The compiler can only guarantee the required typeclass operations will be available at runtime, but it can't guarantee which implementation was selected, because at runtime when it writes the implementation to the dynamic dictionary of the typeclass object, it can't know if a preexisting one will already exist.

So we have lifted dynamic polymorphism to a 2nd order. We have dynamism of dynamic dispatch.

The matrix is we have two axes of data type and interface, and a third axis of implementations that cojoin the two. This third axis can't be tracked at compile-time without dependent typing, but the compiler only needs to insure that the required interfaces are present in order to insure soundness. So this works.

What this enables is for example @skaller's example of wanting to set the ordering of comparison operations, while leaving the data type open to extension with other typeclasses. @keean's proposed solution also achieves it, but it lacks atomicity of retaining this with the data type. For example, @keean's solution is not generic in type of algorithm that can be applied ex post facto and thus it fails another axis of the tension of solving the Expression Problem.

What we will see generally is that higher order dynamism is required to solve higher order tensions in the Expression Problem.

So the lesson that once we bind an interface at compile-time before the function call site, then we forsake static polymorphism and the opportunity for mono-morphisizing the function.

This is not quite right. We can still mono-morphise even with compile-time interface binding - in fact for the traditional requirement this is a requirement. The point is we can statically know both the interface and the exact type passed, and therefore chose and inline the exact function. Rust does this in all cases exept when dynamic polymorphism in involved.

So we can inline and monomorphise the functions when the interface is statically bound and the type is statically know. If either are false (so dynamic binding to the interface, or dynamic typing) we cannot monomorphise in languages like Rust.

So really what we need is to being able to attaching a typeclass object to a data type instance and pass them around as a pair every where a data type is expected.

This is exactly what adding functions to an objects prototype does in JavaScript.

@keean

@keean wrote:

So really what we need is to being able to attaching a typeclass object to a data type instance and pass them around as a pair every where a data type is expected.

This is exactly what adding functions to an objects prototype does in JavaScript.

No it is not the same. The JavaScript prototype impacts all instances. I am referring to impacting only instances which are assigned to the trait bound.

@keean I have decided that it is nearly impossible to try to explain these issues like this. I will need to make detailed code examples and write a white paper. You don't seem to understand me.

No it is not the same. The prototype impacts all instances. I am referring to impacting only instances which are assigned to the trait bound.

So you want the implementation used to depend on the value of the object not just its type.

This is monkey-patching, adding a method directly to the object itself.

@shelby3

@shelby3 wrote:

So the lesson that once we bind an interface at compile-time before the function call site, then we forsake static polymorphism and the opportunity for mono-morphisizing the function.

This is not quite right.

It is right. I just haven't been able to communicate my points to you.

You have written it badly then because

once we bind an interface at compile-time before the function call site, then we forsake static polymorphism and the opportunity for mono-morphisizing the function.

This is exactly the opposite of what is true.

We must bind the interface statically in order to be able to monomorphise and we must statically know the type at the call site as well.

@keean

@keean wrote:

The point is we can statically know both the interface and the exact type passed

If you had understood me, you would understand that I already explained that we don't know the exact type passed, that was entirely the point of binding early erasing the data types from further compile-time knowledge and you only have the trait bound remaining. That you didn't even get that point from what I wrote seems really bizarre.

If you had understood me, you would understand that I already explained that you don't know the exact type passed, that was entirely the point. That you didn't even get that point from what I wrote seems really bizarre.

We always know the exact type passed, that is the whole point of parametric polymorphism. The only time we do not is if there is what Rust calls a trait-object or what Haskell calls an existential-type involved.

@keean

@keean wrote:

The only time we do not is if there is what Rust calls a trait-object

Bingo. Re-read my long comment again.

So in a traditional system like Rust, if there is a trait object we can never monomorphise, it doesn't matter how early or late the type-class is bound.

No, because you can emulate it over values.
Just read in the type as string and destructure,

So whilst it seems you agree with me that we can do everything we want with static types, I don't really get why you keep going on about strings? A type is a graph, you can see this because anything with braces '(' and ')' is fundamentally a binary tree, and if we include recursive types, we end up with types being regular_trees not strings!

So whilst it seems you agree with me that we can do everything we want with static types, I don't really get why you keep going on about strings?

Because you can simulate types created at runtime with strings representing the types, i.e. respresenting the type definition. *
It is however unnice toward runtime reflection.
You wouldn't do that with type definitions at compile time.

Note:* You didn't integrate types created at runtime in your type system as this would mutate your type set.

The 'any' type is bad in any case, you don't really want it. Note this is different from an unconstrained type variable. As I said you can only perform the identity operation on the 'any' type.

Perhaps I should turn this around? What do you think you gain by having runtime types? Can you show me a short motivating example for the sort of programming your are adovacating?

As I said you can only perform the identity operation on the 'any' type.

The any type is nothing different than the union type specified over all possible types in your program.

What do you think you gain by having runtime types? Can you show me a short motivating example for the sort of programming your are adovacating?

For instance in game programming.
You create different Enemy (Sub) Types at runtime:

List<Enemy> enemies;
if(random condition)
{
    Sub1Enemy se1 = RuntimeReflection.createInstance(SubEnemy1,random args)
    enemies.add(se1)
}
...
if(random condition)
{
    SubnEnemy sen = RuntimeReflection.createInstance(SubEnemyn,random args)
    enemies.add(sen)
}
return enemies

We assume the subtypes of Enemy all exists, but the arguments for instantiation and the decision which subtypes are instantiated is randomized.

You get the list of enemies in a function and filter the desired subtype of enemies over this list and mutate specific properties of this type of enemy.

fun(List<Enemy> l)
{
    for(enemy : l)
    {
        match(enemy)
        {
            case enemy isa SubEnemyi:
                    //e.g. access a specific SubEnemyi field
        }
    }
}

Of course you can do this in Haskell via sum types but these are runtime types, too, though they are labeled.
Sum types and union types strongly relate to each other.

Edit:
Note I presented an example about runtime polymorphic types, but maybe you meant types created at runtime.

As an example for this I could imagine that create a new subtype of enemy and instantiate it over random choices resulting to random number of fields.
This is a rare case but should be possible and has the advantage over string representations in that the instances of the new subtypes with their fields are automatically efficiently stored into memory by the runtime.

Or you can define an interface for enemy, and then you could runtime load unknown enemies as binary modules, where you do not know the internal data layout of the state store for the enemy, which I think is a better solution of the above problem.

Refresh please

Or you can define an interface for enemy, and then you could runtime load unknown enemies as binary modules

What's the difference and in which part is this better?

Edit: What me interests more is what is an interface, a typeclass or something else?

I guess you instantiate your required interface with different modules.

Then your interface type is a (partially) dynamic type. And how do you access fields that were not defined in the interface without runtime reflection?

Then your interface type is a (partially) dynamic type. And how do you access fields that were not defined in the interface without runtime reflection?

You access through the defined API which is the same for all implementations of the interface. What I meant was the 'module' can have its own private data which could be any type.

You access through the defined API which is the same for all implementations of the interface. What I meant was the 'module' can have its own private data which could be any type.

Sure all implementations implement the methods of the interface and all those methods can be accessed but what is when I try to access data which is not listed in the interface?

but what is when I try to access data which is not listed in the interface?

How do you know there is data there, how do you know how to interpret the data. Really what can you do with data you don't understand, you may find out it's an 'int' but is it a price, a distance, a frequency?

How do you know there is data there, how do you know how to interpret the data.

Runtime Reflection which scans structurally over this value.

Really what can you do with data you don't understand, you may find out it's an 'int' but is it a price, a distance, a frequency?

For the same reason when you try to search keys overs json structures which don't exists but you tried it however because you have expectations over it.

You have to imagine that you have partial knowledge. You know you want a structure with a give field name and a given type or a part thereof but you don't know the complete structure and you don't interseted in the complete structure.
Dynamicism is to handle with partial knowledge.

Dynamicism is to handle with partial knowledge

But to what end? What can you do if you don't know what it is? This is like downcasting (towards the subtype).

You have an API for shapes, and each shape has a 'draw' method. Great, you can now draw your shapes anywhere. You start poking around in their private data and get 32.6, is that the radius of a circle, the size of a square, the height of a triangle? Just the number is meaningless, and you cannot do anything with it. Really you should not be allowed to see anything that is not part of the published API, otherwise all sorts of things can go wrong, for example the next release of the module could store it's data in a completely different layout. You end up with very fragile code that is going to break all the time and need a lot of maintenance and rewriting.

for example the next release of the module could store it's data in a completely different layout. You end up with very fragile code that is going to break all the time and need a lot of maintenance and rewriting.

Afaics, if you compile your loadable module you should include the corresponding layout in it which you don't know in the project which will import the module.
Another example is if you use an structure instance from a library and access a specific field, your compiler must know that this field access is still valid.
Where does the compiler knows this?
Because the library must contain some layout information.
The same for polymorphic structures which can't be completely monomorphized and removed in binary code in order to monomorphize them later in the linked application.

OOP is really Actors not Class Inheritance

Navigation Menu

Repository navigation

Orthogonal concepts #14

Background

Matrix Conceptualization

162 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Orthogonal concepts #14

Description

Activity

keean commented on Sep 25, 2016

shelby3 commented on Sep 25, 2016

keean commented on Sep 25, 2016

shelby3 commented on Sep 26, 2016

shelby3 commented on Oct 5, 2016

Background

Matrix Conceptualization

keean commented on Oct 5, 2016

keean commented on Oct 5, 2016

shelby3 commented on Oct 5, 2016

keean commented on Oct 5, 2016

shelby3 commented on Oct 5, 2016

keean commented on Oct 5, 2016

shelby3 commented on Oct 5, 2016

keean commented on Oct 5, 2016

shelby3 commented on Oct 5, 2016

keean commented on Oct 5, 2016

162 remaining items

keean commented on Apr 21, 2018

sighoya commented on Apr 22, 2018

keean commented on Apr 22, 2018

sighoya commented on Apr 22, 2018

keean commented on Apr 22, 2018

sighoya commented on Apr 22, 2018

sighoya commented on Apr 22, 2018

sighoya commented on Apr 22, 2018

keean commented on Apr 22, 2018

sighoya commented on Apr 22, 2018

keean commented on Apr 22, 2018

sighoya commented on Apr 22, 2018

keean commented on Apr 22, 2018

sighoya commented on Apr 23, 2018

shelby3 commented on Sep 9, 2018

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions