3 ms·

This is moe interesting than it looks, probably because the best part (IMHO) is about the type system, that is what enables the other ideas. > In Julia, types

by mamcx 3y ago

This is moe interesting than it looks, probably because the best part (IMHO) is about the type system, that is what enables the other ideas. > In Julia, types are first-class and every value has a type This is what I do from the start in https://tablam.org https://tablam.org and only later found that is not common! Is so intuitive this way and simpler to check, by a lot. In fact, I waste so much time adapting type inference algorithms that are hard to translate because for some reason graphs are imposed on trees, types are second-class and live at a distance (and erased) and all is a mess this way. The relational model already makes this so simple: `project / rename / extend` relational operators cover you. From this other facilities become possible. Note how in `SQL` you don't have functions as first-class per se, but now try to imagine that a function is a table and suddenly, is much better!

genman 3y ago
> Putting a string in a Vector{Int64} is simply not allowed. In Java the same applies. But Java is a weird beast. While every value has a type, not all types are equal - there are primitive types like int and double, that are value types, and Integer and Double, that are class types. This all is even more muddied with class generics that are forced into the existing system by type erasure at compile time - so while you can't put a String into an array of Double, you definitely can put a String into a hash map of Double when you really want to, as the hash map is implemented as a class and type parameters of a class are just an illusion that is enforced during the compile time. No sane person will do this and uses all the available tricks to eliminate this possibility, but it is definitely possible.
genman 3y ago
A relational programming language is an interesting concept and I have been thinking if somebody could come up with something. I'm not sure that it results in a good reusable code though. Any examples?
- kevindamm 3y ago
  In a lot of ways the Logic Programming languages are effectively relational (e.g. Prolog, Datalog, KIF) but the search behavior for relations that satisfy a query is a bit different than SQL-like relational languages. On a previous project I embedded a SQL-like sub-language into a model language so that ETL pipelines and OLAP/OLTP processing could be generated to query aggregates and value lookups during inference. It is nontrivial to embed a relational language into another language without making some compromises but there are certainly contexts where it is quite useful. I think C#'s LINQ is a reasonable effort at this but I'm not much a fan of the rest of that language.
- mamcx 3y ago
  I have nothing super finished, this is for fun (until I get time or funding!). But I bet is far more reusable than normal code in most cases. The reason is that the relational/array model has more values: https://www.infoq.com/presentations/Value-Values/ https://www.infoq.com/presentations/Value-Values/, and combined with structural types and the power of relational operators you can eliminate a lot of cases where macros or generics come. One major feature of a "values" language is that is naturally introspectable. Not just values, but types, and metadata. So this is NOT crazy: mod People: data Person: name: Str age: Int data Customer: Person //not subtyping but `SELECT * Person INTO Customer` active: Bool end mod Auth: data User: People.Person //not subtyping but `SELECT * People.Person INTO Customer` password: Password active: Bool data UserSafe: User ? deselect password // SELECT People.Person.*, active INTO UserSafe end fn print(p: Person ... ) // Accept anything that is `SELECT name, age FROM ?`, but critically, not remove the other fields, are just invisible here. This means you don't make type conversions in unnecessary cases fn print_type_no_person(mod:Mod): String let types = mod ?select as_data(this) != Some(Person...) // Anything is a relation, anything query types ? union | into(String) //SELECT t1 UNION t2... + reduce()
foota 3y ago
This seems interesting, have you looked into ECS at all? I'm not sure it would make sense, but it seems like you could store data columnulary by type to get efficient vectorization and access patterns for operations over types, and systems might make for an interesting way of handling data. It's not exactly relational, but it's kind of similar. I've wondered what an ECS framework for normal server side code would look like, where you essentially define an RPCs handling implicitly as a series of systems acting on it.
- mamcx 3y ago
  > but it seems like you could store data columnulary by type to get efficient vectorization and access patterns for operations over types I tried at first to be fully columnar, then cave and try hybrid then now I doing mostly rows with 2d NDArrays. The major reason is that going columnar flip everything and then I need to recreate tons of API, in special costly with FFI or APIs. I was looking into mimicking kdb+, and yes, that is what they end up doing. This lead to a more insular community (that I don't have but well, that is a worry!)
  - foota 3y ago
    Ah yeah, that makes sense. Even having types stored in arrays though could be better than the typical graph like structure you might get from an OO language.

by mamcx 3y ago

genman 3y ago

> Putting a string in a Vector{Int64} is simply not allowed. In Java the same applies. But Java is a weird beast. While every value has a type, not all types are equal - there are primitive types like int and double, that are value types, and Integer and Double, that are class types. This all is even more muddied with class generics that are forced into the existing system by type erasure at compile time - so while you can't put a String into an array of Double, you definitely can put a String into a hash map of Double when you really want to, as the hash map is implemented as a class and type parameters of a class are just an illusion that is enforced during the compile time. No sane person will do this and uses all the available tricks to eliminate this possibility, but it is definitely possible.

genman 3y ago

A relational programming language is an interesting concept and I have been thinking if somebody could come up with something. I'm not sure that it results in a good reusable code though. Any examples?

kevindamm 3y ago
In a lot of ways the Logic Programming languages are effectively relational (e.g. Prolog, Datalog, KIF) but the search behavior for relations that satisfy a query is a bit different than SQL-like relational languages. On a previous project I embedded a SQL-like sub-language into a model language so that ETL pipelines and OLAP/OLTP processing could be generated to query aggregates and value lookups during inference. It is nontrivial to embed a relational language into another language without making some compromises but there are certainly contexts where it is quite useful. I think C#'s LINQ is a reasonable effort at this but I'm not much a fan of the rest of that language.
mamcx 3y ago
I have nothing super finished, this is for fun (until I get time or funding!). But I bet is far more reusable than normal code in most cases. The reason is that the relational/array model has more values: https://www.infoq.com/presentations/Value-Values/ https://www.infoq.com/presentations/Value-Values/, and combined with structural types and the power of relational operators you can eliminate a lot of cases where macros or generics come. One major feature of a "values" language is that is naturally introspectable. Not just values, but types, and metadata. So this is NOT crazy: mod People: data Person: name: Str age: Int data Customer: Person //not subtyping but `SELECT * Person INTO Customer` active: Bool end mod Auth: data User: People.Person //not subtyping but `SELECT * People.Person INTO Customer` password: Password active: Bool data UserSafe: User ? deselect password // SELECT People.Person.*, active INTO UserSafe end fn print(p: Person ... ) // Accept anything that is `SELECT name, age FROM ?`, but critically, not remove the other fields, are just invisible here. This means you don't make type conversions in unnecessary cases fn print_type_no_person(mod:Mod): String let types = mod ?select as_data(this) != Some(Person...) // Anything is a relation, anything query types ? union | into(String) //SELECT t1 UNION t2... + reduce()

foota 3y ago

This seems interesting, have you looked into ECS at all? I'm not sure it would make sense, but it seems like you could store data columnulary by type to get efficient vectorization and access patterns for operations over types, and systems might make for an interesting way of handling data. It's not exactly relational, but it's kind of similar. I've wondered what an ECS framework for normal server side code would look like, where you essentially define an RPCs handling implicitly as a series of systems acting on it.

mamcx 3y ago
> but it seems like you could store data columnulary by type to get efficient vectorization and access patterns for operations over types I tried at first to be fully columnar, then cave and try hybrid then now I doing mostly rows with 2d NDArrays. The major reason is that going columnar flip everything and then I need to recreate tons of API, in special costly with FFI or APIs. I was looking into mimicking kdb+, and yes, that is what they end up doing. This lead to a more insular community (that I don't have but well, that is a worry!)
- foota 3y ago
  Ah yeah, that makes sense. Even having types stored in arrays though could be better than the typical graph like structure you might get from an OO language.