Thanks, so short answer is to not use literals for structures, maps, lists and other terms, but use functional wrapper with its own typespec which will return term as expression without any branching inside?
Thanks, so short answer is to not use literals for structures, maps, lists and other terms, but use functional wrapper with its own typespec which will return term as expression without any branching inside?
Yes, and then compose into bigger types, and bigger functions. Maybe like this.
Yes, probably it will work, but I think it looks creepy
And of course if you will introduce new type and function every time you need branching - it will gain 3x amount of code, and will gain overhead regarding function calls in runtime
Yes, ofc I like pattern matching - it makes code shorter etc,
but it not resolves problem with typespecs and Dialyzer here - try to compile it and run checks, Dialyzer will be happy with it
Although I’m unsure how well dialyzer checks that (wow the syntax highlighting is bad on ::)? But I’m like 80% sure Dialyzer matches based on unbound names for handling passed in types.
Good thing the AST is so simple, just some primitive types, lists, 2-tuples, and 3-tuples. /me wishes it were just 3-tuples and primitives-inside-special-3-tuples
There are ways though, and since each form of an AST node is distinct then it could be a headless sum type safely (or heads without internal named distinction, which is easy to do).
Ah yeah, the when might be necessary, unsure?
I don’t. It is runtime based, not entirely compile-time, which is point defeating.
Yep yep, it is a great positive typer, it was not designed to be an actual complete typing system.
It’s not too bad actually, especially if there is a ‘dynamic’ type that must be matched out for use in statically-strongly typed sections (deft as a typed def, or something that is module-wide?), then you can pretty well incrementally improve it knowing that the only unchecked areas are areas that are not typed.
At least until you define such an Option.t type or so and baked in a few common patterns.
Not any more than current code already has to do, the dynamic->typed boundaries would still use matchers and guards to safely determine what it is, which is what you have to do anyway to determine the types of something. However inside the typed area then direct calls could be made that entirely bypass guards and other such checks for known paths.
Yeah I really wish Elixir started as a typed language, erlang being dynamically typed is one of the things I’ve hated most about it, only standing it because of dializer. Elixir started from the wrong side of typing even though it was made a-new still seemed entirely broken to me…
Actually I think it was @vic that made a library or two along that path. ^.^
Yep, it definitely would, though that would add overhead that the static type checking means wouldn’t need to exist anyway (proper static typing can remove a lot of checks and can generate a lot better code in a few areas).
Yeah overspecs are way too noisy because the quality of the specs in the overall engine and essentially all libraries are not made quite right in a lot of places (especially once you take macro’s in mind).
Like in a real full typing system! ^.^
Typespecs don’t generate code though.
/me really wants to work more on the TypedElixir experiment… blehg lack of time…
Yes, but in an HM typesystem you need named constructors to write your macro, even if the internal implementation strips them… This is not a disaster, though, and you can work around it.
