4 ms·
Wouldn't it become very undecidable very fast going down that route? Programming by defining algebras is interesting idea with many practical applications, even
by qsort 4y ago
Wouldn't it become very undecidable very fast going down that route? Programming by defining algebras is interesting idea with many practical applications, even in down-to-earth CRUD apps, but how much magic can you really add before it becomes impossible (or even just very hard) to compile?
The closest example in mainstream languages is Haskell, but even there the compiler basically trusts you. Is it possible to add something else while remaining decidable/efficient? I genuinely don't know.
- mncharity 4y ago> but even there the compiler basically trusts you Yeah, I'm ok with that. I'm more after expressivity than safety or efficiency. Sometimes they're not separable, but confronted with the usual "we don't know how to efficiently compile that, so we won't allow you to express it", my response is always "the language is not the right level at which to choose such engineering tradeoffs - give me finer-grain control, and in program portions where it matters, I'll trade expressiveness for efficiency or safety... after maybe first trying caching and cloud parallelism and patience and external analysis and ... ".
- mncharity 4y ago> after maybe first trying [...] Oops, I got carried away at the end there. Yes, maximally-restricted tolerable representation buys maximized compiler leverage. But might we more often metaprogram that out of diversely-performant maximal power, rather than bootstrapping it on performant but constraining circumscribed power?
- eru 4y agoHaskell already has an extension called UndecidableInstances. Funny enough, even your basic Hindley-Milner style type inference has exponential runtime in the worst case, even if you don't add any bells nor whistles. In practice, people don't tend to write code that triggers that worst-case.
- bjoli 4y agoAm I the only one that likes vanilla Haskell? I find that it quickly becomes messy with all the GHC extensions. I am although more of an SML kind of guy.
- eru 4y agoMany libraries try to stick to Haskell 98. Also whenever someone writes a paper about some new techniques, they always seem to take a lot of pleasure in pointing out when their technique works in Haskell 98. I like that you can mix and match GHC extensions even in the same project. So one library (or even just one module) might use some crazy and messy extensions, but you can still use it from vanilla Haskell. http://dev.stephendiehl.com/hask/#language-extensions http://dev.stephendiehl.com/hask/#language-extensions has a list of extensions and some judgement on them. There are a few that are really neat, but don't really cause any mess: For example, I really like TupleSections. They are not strictly necessary for anything, they are purely cosmetic / syntactic sugar. But they also don't cause any mess. https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/tuple_sections.html https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/tupl... Also: TypedHoles are really neat for developing, and will never show up in your final code. https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/typed_holes.html https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/type...
- neilparikh 4y agoGeneralisedNewtypeDeriving is one that I'd consider fairly important as well.
- eru 4y agoAnd also fairly benign, yes. In contrast: GADTs are really important, but they get you pretty far away from Vanilla Haskell.