-
Notifications
You must be signed in to change notification settings - Fork 0
Language
The system will be programmed in a language that provides at the same time high level abstraction and composition options while being semantically possible to optimize at run time by looking both at the data access and the operations possible on the data.
That is the system will optimize both the storage format to suite the operations performed on it, and optimize the algorithms to suite the data.
The above requirement means that the language must allow specification of operations in a manner that is equally (or more) optimizable as the current crop of query languages.
I imagine that the language will be stratified into layers of provability, f.ex. having a strong functional language12 at its core.
1 Total Functional Programming paper
2 Total Functional Programming @ Wikipedia
Subtyping, Subclassing, and Trouble with OOP
The Third Manifesto
Date and Darwens Type System
Conceptual Queries
One important construct in a database system is the tuple. This construct is notoriously hard to model in current programming systems. I would like to see tuples modeled as functions from symbols to values. The interesting part is to type this function. The type should be something like n ∊ names(t1) → type(t,n), in other words a dependent type.
Two relations R1 and R2 can be modelled as functions f:A → (B,C) and g:C→D. The natural join (R1 ⋈ R2)(A*,B,C,D) should thus be f ⋈ g: A → (B,C,D). I wonder where one would end up if all of the relational algebra is brought down to function operations. Should partial application be seen as a form of selection? What is a projection of a function?
I’m thinking that the language should be based on a pattern matching as one of the most fundamental operations. This can be used to support polymorphism in the OOP sense while not having to add actual methods and stuff.
Also delimited continuations seems to be a rather powerful and important feature. With the right syntax maybe exceptions and even return values can be implemented as a library.
In a language like Java each object is associated with an identity tied to that object. This means that if you are programming in an immutable style where state transitions are modled as returning new values you are foced to create an actual object with identity and all, an object that can escape the context in which it was created in various ways. Moden VMs optimize away this as best as they can, but it still seems wasteful to have this semantivcs forced on you as a programmer. In Java you can pass the same instance around as implementing various interfaces though, so atleast there is a workaround. Creating an interface for each interesting state the object can have, and implementing it, adds a lot of boilerplate code though.
So I’m thinking that a language should support encapsulating state with operations in a manner that doesn’t force you to either instanciate new objects or add lots of boilerplate.
The topic of identiy is also interesting when you look at the mess that is Javas contracts with eqals, hashCode and the collection library. I’m thinking that a language should support both value semantics and reference semantics. And they probably shouldn’t be mixed. Value identity means that all observable state must be part of the indentity. Reference identity should probably be entierly defined by the reference. This means that there is no need what so ever to define “equals” for any object in a language. Equality is entierly defined by either value semantics or reference semantics and never ever a mix.