sixbrx's comments

On: Prisma Postgres – Runs on bare metal and unikernel...

[sixbrx]

Better tell wikipedia: "The format indicates the first word starting with either case,'

https://en.wikipedia.org/wiki/Camel_case

On: Prisma Postgres – Runs on bare metal and unikernel...

[sixbrx]

Thats not particular to postgres, that's the same in Oracle (or any other db following ISO case handling I believe), just with true (quoted) table name being all uppercase instead for the latter but with same error.

You can quote the table name in the create statement to get the camelcase table name. Just remember to quote in both creation and usage or neither, is a good rule of thumb

On: Prisma Postgres – Runs on bare metal and unikernel...

[sixbrx]

Nah - camel's head can be tall just like the hump.

On: Porffor: A from-scratch experimental ahead-of-time...

[sixbrx]

Here's an example I constructed after reading the TS docs [1] about flow-based type inference and thinking "that can't be right...".

It yields no warnings or errors at compile stage but gives runtime error based on a wrong flow-based type inference. The crux of it is that something can be a Bird (with "fly" function) but can also have any other members, like "swim" because of structural typing (flying is the minimum expected of a Bird). The presence of a spurious "swim" member in the bird causes tsc to infer in a conditional that checks for a "swim" member that the animal must be a Fish or Human, when it is not (it's just a Bird with an unrelated, non-function "swim" member).

    type Fish = { swim: () => void };
    type Bird = { fly: () => void };
    type Human = { swim?: () => void; fly?: () => void };

    function move(animal: Fish | Bird | Human) {
      if ("swim" in animal) {
        // TSC infers wrongly here the presence of "swim" implies animal must be a Fish or Human
        onlyForFishAndHumans(animal); 
      } else {
        animal;
      }
    }

    function onlyForFishAndHumans(animal: Fish | Human) {
      if (animal.swim) {
        animal.swim(); // Error: attempt to call "not-callable".
      }
      // (receives bird which is not a Fish or Human)
    }

    const someObj = { fly: () => {}, swim: "not-callable" };
    const bird: Bird = someObj;

    move(bird);

    // runtime error: [ERR]: animal.swim is not a function

[1] https://www.typescriptlang.org/docs/handbook/2/narrowing.htm...

[noway421 → sixbrx]

Here's a simpler repro:

    type Bird = { id: number };
    type Human = { swim?: () => void; id: number };

    function move(animal: Bird | Human) {
        onlyForHumans(animal); 
    }

    function onlyForHumans(swimmer: Human) {
      if (swimmer.swim) {
        swimmer.swim();
      }
    }

    const someObj = { id: 1, swim: "not-callable" };
    move(someObj);

`someObj` gets casted as `Bird`, then `animal` gets casted as `Human`. Unfortunately unions here are indeed unsound.

As as workaround you could add a property `type` (either `"bird"` or `"human"`) to both `Bird` and `Human`, then TypeScript would be able to catch it.

[oxidant → sixbrx]

This narrowing is probably not the best. I'm not sure why the TS docs suggest this approach. You should really check the type of the key to be safer, though it's still not perfect.

   if (typeof animal.swim === 'function') {....}

[saghm → oxidant]

Compilers don't really have the option of just avoiding non-idiomatic code, though. If the goal is to compile TypeScript ahead of time, the only options are to allow it or to break compatibility, and breaking compatibility makes using ahead-of-time TypeScript instead of some native language that already exists much less compelling.

On: How to escape Honda's privacy hell

[sixbrx]

full time cleaners aren't cheap either

On: Functional semantics in imperative clothing

[sixbrx]

I'm pretty sure the thunk would be tagged by the effects of the inner function, so couldn't be called from an external context not declaring those effects. That's what the effect tracking is for.

On: Serious flaws in SQL (1990)

[sixbrx]

invented the relational model rather

On: Embeddings are a good starting point for the AI cu...

[sixbrx]

i get triggered that the norm vars aren't ever really the norms but their squares

On: Unison Cloud

[sixbrx]

Unison looks like a neat functional language. Do abilities subsume the role of type classes also (without any "effects")? If so, would there be a loss of efficiency for using pure abilities in this way (since a "handler" needs to interpret the ops)? Sorry I've only had a brief look so I'm not sure this makes sense.

Edit: Shorter: do you have type classes

[badelectron → sixbrx]

Short version: no type classes (yet)

Longer version:

Building upon what Quekid5 mentioned, Unison abilities are an implementation of what is referred to as algebraic effects in programming language literature. They represent capabilities like IO, state, exceptions, etc. They aren't really a replacement for type classes, though in some cases you can shoehorn abilities in where you might otherwise use a type class.

For someone coming from a Haskell background, I think that abilities are closer to a replacement for monad transformers. But in my opinion they are much more ergonomic.

Discusson of type classes comes up a lot. Here is a long-standing GitHub issue: https://github.com/unisonweb/unison/issues/502

For what it's worth, I've written Unison quite a lot over the past few years and while I've missed type classes at times, I think that reading unfamiliar code is easier without them. There's no implicit magic; you can see exactly what is being passed into a function. So far I've been happy with a bit more verbosity for the sake of readability.

[Quekid5 → sixbrx]

Abilities are typed effects, effectively. At least, that's how I understand it.

(In a less jokey way: Abilities should be thought of as capabilities, and capabilities are what enable you to do I/O, read from a DB, etc. So they are 'effects' in the Pure FP sense.)

Not sure about the type classes thing.

[zawodnaya → sixbrx]

Unison doesn't have type classes yet, no

On: Global CO2 Levels

[sixbrx]

The vast majority of that time had neither modern humans nor anything like our civilization, so wouldn't really be relevant though. Hell at 600 million years ago there were just the first "complex" (not individually microscopic) life forms emerging.

Also the ups and downs in temperatures happened over a far longer period of time than what we're experiencing now, giving life more time to adapt.