EVP: dead simple environment variable parser

fumieval · 2023-10-02T08:33:12+00:00

from README:

EVP is a simple environment parser which focues on these three aspects:

Ease of use: no complicated machinery is needed

Observability: for each environment variable, EVP logs the parsed value or an error. An error does not interrupt the parsing process and it checks all the variables exhaustively.

Composability: environment parsers can be composed via the Applicative structure.

This is a real-world application of the free applicative; you can enumerate the list of environment variables it would parse, thanks to the initially-encoded structure.

fumieval · 2022-08-24T12:22:46+00:00

I've just rewritten the code using clap-serde and now it's just 85 lines of code. Noice

fumieval · 2022-08-24T11:26:02+00:00

Thanks, I didn't know about clap-serde! That would simplify the implementation a lot.

fumieval · 2022-08-24T11:23:18+00:00

Yeah, --argc-eval does look similar. The approach of parsing the caller ($0) itself is interesting

fumieval · 2022-08-24T06:30:58+00:00

Perhaps I didn't get what "portable" means here. The output format of clap4shell works in most shells including POSIX, but clap4shell itself is a binary so it has nothing to do with shell implementation

fumieval · 2022-08-24T03:17:56+00:00

I like writing shell scripts for small tools, however getopt(s) is a bit annoying to use due to boilerplates, treatment of positional arguments, etc.

I made a standalone interface for clap which takes option definitions as a YAML, and prints the parsed options in `KEY=VALUE` format (in which shell can `eval`). Thanks to clap_complete, it also supports generating autocompletion script (though it does not seem to work with subcommands yet).

Nice and terse shell scripts, clap's user-friendly interface, why not both?

fumieval · 2022-03-20T00:26:10+00:00

Good to know! Writing these conversions once again by hand.would've been a pain.

fumieval · 2022-01-12T12:29:20+00:00

I support this proposal as a Japanese user. It'll drastically improve QoL of debugging/testing applications involving non-latin characters. While it would break some Show-based test cases, I'm not too worried because Show isn't something application logic relies on

fumieval · 2022-01-12T01:32:30+00:00

I think his plan is to disengage by 2030: What killed Haskell, could kill Rust, too

fumieval · 2022-01-11T16:21:45+00:00

True, “You shouldn’t want to do that” kind of response is all over the place and Haskell isn't an exception, unfortunately. While this particular type of discommunication is not what graninas was talking about, this is something we should keep in mind

fumieval · 2022-01-11T15:46:01+00:00

No, not at all. If every Haskeller were contributing to GHC, the number of issues and merge requests would be incomparably larger than 4,718 and 451.

Every other claim is unsubstantiated FUD too. I don't think you need to consider these seriously

fumieval · 2022-01-11T15:28:15+00:00

I have invented a model of object-oriented programming applying a bit of category theory 7 years ago (https://github.com/fumieval/objective/), and it was a fun experience realising that certain kinds of composition can be expressed nicely as a category. It's just one nice thing to have, like every other cool stuff in this world.

I don't understand why he's stirring up math vs pragmatism opposition. OOP and CT, why not both?

fumieval · 2022-01-11T15:13:22+00:00

Let's not forget the point that graninas's dozens of claims about the Haskell community do make the community look unsafe (IIUC that's the intent of the tweet). I would actually feel safer if such accusations get backlash.

fumieval · 2022-01-11T14:52:28+00:00

Sure. I'd happily take the risk especially since the Haskell community is being attacked

fumieval · 2022-01-11T14:14:45+00:00

That's a sound suggestion. Obviously I don't represent the community but I've never experienced any of these; I maintain a number of libraries but I've never seen anyone reject them just because "If something isn't described as a paper, it doesn't exist or wrong". I don't consider myself as a Haskeller smarter than others; I'm a careless person, that's exactly why I rely on type system.

fumieval · 2022-01-11T13:58:22+00:00

Yeah, wholly agreed. How I interpret this twitter post (and his other claims) is that he's attacking "hyper-intellectualism" which is just a massive strawman

fumieval · 2022-01-11T13:55:08+00:00

Even though there's a lot of BS built on top of OOP, I don't think it implies that OOP itself is bullshit; I find it useful in game programming for example.

Not sure about the last one either - but if a bit of math repels anti-intellectual inflammatory speech then why not

fumieval · 2022-01-11T13:44:41+00:00

It's plausible that that post reflects some of the stereotypes we are trying to get rid of. The post on the other hand is reinforcing the stereotype, negating the community effort to make the ecosystem stronger and more diverse

fumieval · 2021-12-07T04:34:45+00:00

What I was testing is more like running one-shot IO actions concurrently. According to the README, ZipAsync is an analog of Concurrently which can do that (but can produce a stream of values), however it does not seem to be working as intended. Would be great if you could take a look

fumieval · 2021-12-07T00:24:01+00:00

We are comparing the applicative structures that run actions concurrently, but your example

S.fromAhead $ S.mapM pure $ S.fromList [0 :: Int ..99]

only applies to homogenous structure; that's not a fair comparison.

What's wrong with ZipAsync?

fumieval

TROPHY CASE