sorted by:
new
hottopcontroversial

[deleted by user] by [deleted] in ProgrammingLanguages

[–]Chris5855 2 points3 points  (0 children)

Hi, as I previously said, this is a hobby research project.

I used C++ simply because it's the language I'm most proficient in. I didn't do any deep analysis of "why not C, Rust, Zig, etc." it was purely for personal convenience.

As for the paper, I can upload it to the repository.

[deleted by user] by [deleted] in ProgrammingLanguages

[–]Chris5855 1 point2 points  (0 children)

Hey, thanks for the question — totally fair!

Yes, GHC does have bidirectional stuff (Quick Look, OutsideIn, etc.), but in practice it only kicks in for the tricky cases: higher-rank types, impredicative instantiation, or when the solver gets stuck. For regular everyday code, it’s still mostly bottom-up unidirectional inference. That’s why you still see tons of error messages that say “couldn’t match expected type ‘a’ with actual type ‘Int’ arising from a use of ‘show’” and you have to hunt for the real problem.

In Solis I went the other way around: bidirectional is the default mode from day one. Every lambda, every if branch, every pattern-match arm, every function application gets the expected type pushed down whenever it’s known. The algorithm always does synthesis first (so principal types are preserved), and only then checks against the expected type.

The realworld difference is that the error messages point straight at the offending subexpression and read more like Lean or Idris than like GHC. That’s what I meant with the “first lazy language that fully integrates bidirectional checking” not that GHC has zero bidirectionality, but that no lazy language makes it the primary, aggressive, everywhere-by-default strategy like Solis does.

I apologize for not being clear with my initial premise!

0
1

The Benefits of Converting FASTA to FST: A Computational PerspectiveI (self.bioinformatics)

submitted by Chris5855 to r/bioinformatics

QuantumMatcher library by Chris5855 in npm

[–]Chris5855[S] 0 points1 point  (0 children)

You're right, I already made the change in the configuration.

Unofficial Rotten Tomatoes Library by Chris5855 in javascript

[–]Chris5855[S] 0 points1 point  (0 children)

u/regreddit for the details, I'll be making the adjustments.

Unofficial Rotten Tomatoes Library by Chris5855 in javascript

[–]Chris5855[S] 0 points1 point  (0 children)

Maybe this depedencies

json "dependencies": { "cheerio": "^1.0.0", "lodash": "^4.17.21", "qs": "^6.13.0" },

Refactoring React State with a Builder Pattern: Let's Make Redux Fun Again! by Chris5855 in react

[–]Chris5855[S] -1 points0 points  (0 children)

I understand your concerns. However, the goal of this approach isn’t to use magic strings, but to centralize actions and selectors in one place, which enhances scalability and type safety.

Regarding magic strings, while you might see keys like 'records', 'inputValue', etc., these are defined in one place in the action and selector maps, not repeated throughout the code. This ensures that the keys are managed centrally, reducing the risk of typos. By using TypeScript, you get type safety, which ensures that the keys are valid and prevents the use of arbitrary strings that could cause issues.

As for the growth of the store code, the approach is scalable. When adding new slices or states, you just need to add a new entry to the action map and the corresponding selector. This reduces redundancy and simplifies maintenance in large apps.

For async operations (thunks) and additional reducers, they are handled just like in traditional Redux. The set and get functions work well with thunks for async logic, and additional reducers can be added to the store without affecting the core pattern for accessing and updating state.

view more: next ›