klfc VS ghc-proposals

I use https://github.com/39aldo39/klfc in my scripts to generate the OS-specific files for ANSI layouts. I convert the KLA json to their format. There may be bugs in that process. Checking it is on to-do list.

On Windows I am using DreymaR's extend layer to navigate in Vim using the directional keys on JKLI (qwerty). On Linux I used KLFC to create a custom keyboard replicating that of Dreymar's, I just tweaked a few keys on the examples folder to better suit my needs.

The OTHER Big News is that I now have install files for basic ANSI layouts. They are in Alpha/Beta state, I have not tested them and will welcome feedback. They are generated via the Keyboard Layout Files Creator @ https://github.com/39aldo39/klfc

The diaeresis appears on the bépo layout by default. It also has Greek letters, like say Σ. I have extended bépo by setting Caps Lock to work as a modifier key, so I get twice as much space. Every time I meet a new symbol I want to have, I put it somewhere on the keyboard. klfc is a fantastic tool for this.

How did you create your custom layout? I already found out about klfc, but 1. It doesn't work on wayland, 2. It's not entirely clear to me how to use this tool.

KLE .json has a lot of issues. Den and I have started talking about what we need. Probably needs a wider group. There is already this project as well as Kalamine

> 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.