hoogle VS ghc-proposals

Dimensions behave somewhat like a "type system" for math. These dimensional-analysis tricks act like the trick you see in Haskell sometimes, where you can easily guess an implementation of an expression once you know it's type (or e.g. search by type signature https://hoogle.haskell.org/ )

Haskell Spotlight makes vscode a client for hoogle. It isn't too different than jumping into your browser and type https://hoogle.haskell.org/. The main advantage is that you have everything in one place

https://hackage.haskell.org/package/base and https://hoogle.haskell.org are automatically up to date and better searchable than almost any other reference of any other programming language. maintaining a redundant reference that needs to be kept up to date manually is simply stupid.

Ideally like this: https://zio.dev/reference/#concurrency

Or this: https://hoogle.haskell.org/?hoogle=fork

And yeah I get it, it's hard to Google for punctuation operators in languages because it doesn't give useful search results (but not impossible, for example, Haskell has a search engine for documentation that handles symbols/punctuation).

{ "customLocalFormatters.formatters": [ { "command": "make format", "languages": ["haskell"] } ], "emeraldwalk.runonsave": { "commands": [ { "match": "*.hs", "isAsync": true, "cmd": "make retag retag_file=${file}" } ] }, "ghcid.command": "make ghcid", "goto-documentation.customDocs": { "hs": "https://hoogle.haskell.org/?hoogle=${query}" } }

You had a look at Hoogle?

https://hoogle.haskell.org/

For some type signatures there is (are) only one (or only a few) meaningful implementation(s).

> I think Haskell needs a way to graduate (or retire) language extensions

https://github.com/ghc-proposals/ghc-proposals/pull/601

Additionally, while this proposal is focused on the simple implementation and so in the current proposal or patterns do not bind any variables as per #522, if we do get settled on syntax and then later wish to expand to allow binding variables as in #43, then the syntax is again clean and discoverable.

Yeah, a relatively natural thing would be to be able to opt-in to having the HasField instances be available in all contexts. The (not yet implemented, but accepted) "Modifiers" GHC proposal might be nice for that.

The local modules proposal imo is excellent as-is.

Why would you drop TypeFamilies? It seems fairly popular, given that it was just one vote short of getting added to GHC2021. Do you consider it a less-ideal compromise, that is subsumed by your second proposal (Core with GRTT)?

as syntax is contentious a topic as ever, David (the main proposal author) and I would like to invite you to give your input on https://github.com/ghc-proposals/ghc-proposals/pull/585, where we propose to change the syntax of the accepted proposal #522 introducing Or patterns. In particular, we'd like to know

This looks great, congratulations on completing it! I assume you didn’t get an opportunity to evaluate the delimited continuations based eff library? It would’ve been nice to see Cont included as one of the effects covered, though perhaps not available in all the systems you looked at? Maybe some future work.

I do hope qualified exports are available someday: https://github.com/ghc-proposals/ghc-proposals/pull/283

Right. Being able to disable "custom type warnings" at use sites was part of an earlier proposal (https://github.com/ghc-proposals/ghc-proposals/pull/454) but it ended up being shelved.