71–80 of 82 posts
Except missing the pesky runtime implementation. We don't need though, right? As long as the types say it's right.
The static types depicted in typescript are entirely fictitious. Any similarity to runtime types is purely coincidental.
Reminds me of Idris: https://gist.github.com/chrisdone/672efcd784528b7d0b7e17ad9c... Recently though, I've been wondering whether advanced type system stuff is the right approach. It usually becomes pretty complicated, like another language on top of the regular language. Maybe it would be easier to have some kind of framework for compiler plugins that do extra checks. Something that would make it easy to check forma…
Maybe check out Clojure spec? https://clojure.org/guides/spec
This is something that most mainstream language's type system cannot do.
(This may be obvious, but a lot of commenters here might have missed that.)
Earlier quoted context omitted.
I wonder if we should have a kind of "hidden type system", where we still take advantage of having a single type system to reason about, but the extra-specific "weird-ish" types can be hidden, almost like private variables, where visibility is literally hidden from the programmer unless obtained from debug modes or errors.
You mean like the C++ auto keyword but everywhere?
I've been kind of curious why tricks like this aren't used more to make sql and such. Heck, you could do similar tricks for shell execution. Or any general "string that is parseable." Seems we always take the route of not parsing the string as much as we can?
> why tricks like this aren't used more Some languages don't support this. The languages that do would require extensive systems to implement this feature. It may simply not be a priority over other requirements like thread safety, atomicity, etc. > similar tricks for shell execution Shell only supports strings, integers and lists. The type system is too limited for this level of type-checking. This works in typescri…
Basic point being that the equivalent of named/delimited parameters with pretty much forced support for escaping such that you have to go out of your way to send raw strings.
I think, bottom line, it bemuses me that the default "convenience" methods are almost always "send this string over to another process to evaluate it" instead of any processing locally on it. That feels it would be far better as the power "escape hatch" instead of the "convenience method" that it is often pitched as.
I've been kind of curious why tricks like this aren't used more to make sql and such. Heck, you could do similar tricks for shell execution. Or any general "string that is parseable." Seems we always take the route of not parsing the string as much as we can?
There is actually efforts in the Typescript community attempting to do just that. Personally I think it'll end up being a waste, but these sorts of experiments, even when they fail, often can help along new discoveries. And on the off-chance they get it right, then damn that's pretty great.
I've been kind of curious why tricks like this aren't used more to make sql and such. Heck, you could do similar tricks for shell execution. Or any general "string that is parseable." Seems we always take the route of not parsing the string as much as we can?
There is an implementation of SQL that operates on a table shaped type, entirely at type level. For your amusement: https://github.com/codemix/ts-sql There are a bunch of more practical takes that codegen types from your database and generate types for your queries, eg: https://github.com/adelsz/pgtyped To me the second approach seems much more pragmatic because you don’t need to run a SQL parser in your typechecker…
Your implication that it is a tradeoff, btw, I fully endorse/agree with. And I know there will be pathological projects out there where the code gen will take ages to complete. I'd hazard a guess that most people wouldn't notice the codegen happening on every build for most projects. Especially on modern build machines.
I've been kind of curious why tricks like this aren't used more to make sql and such. Heck, you could do similar tricks for shell execution. Or any general "string that is parseable." Seems we always take the route of not parsing the string as much as we can?
This is a pretty neat application, but most embedded languages like SQL have a way more complicated grammar that would require a really complicated set of types to parse. This can tank the performance of your type checking step and it also means that the error messages you get out of the parser-in-types are going to be nearly useless. A more common solution is to parse the string at runtime with a proper parser with…
I'm also curious on the idea of having a string parsed at runtime and why that is necessarily better? Sounds like this is essentially dynamic typing? Where they are calling it branded, instead of dynamic? At first, I confess the idea sounded close to a tagged union. You have to have something in the data to indicate the tag; but I guess it is missing the union part? Definitely looks close to the idea of treating "objects" as maps.
Neat idea, thanks for sharing!