This is the way
#monad #FunctionalPrograming
This is the way
#monad #FunctionalPrograming
Built my first lisp (after already having started writing two compilers xD) in #zig! Mainly to test out the language, but it was much fun anyway.
It also got a few ideas for my own language for a few functional programming things :D
I enoyied the most the memory checking zig does, be it leaks, use-after-free or double-free, which makes this project the most easy to be memory-safe out of all my native (c-like) projects whithout multiple days using #valgrind xD
#foss #oss #opensource #programming #langdev #lisp #coding #c #c++ #zig #functionalprograming #compilerdev
I want to know how to implement solvers for systems of inference rules; there must be lots of literature. What do I search for?
(naive search only turns up trivialities)
There's a number of reasons this would be beneficial:
- Editing configs within a text-editor is more intuitive
- Written structured data/tables is intuitive
- Methods to set column data would allow constraints to be effectively expressed as conditional logic
- Sum types allow the results of constraints to be expressed more descriptively
- Schemas as code can be source controlled
2/
I've long found people question the applicability of Functional Programming when it's raised in discussion, but I think a clear use-case for the paradigm has been neglected, and that would be the definition of database schemas... it would honestly be really nice, to be able to define database tables and constraints, in a Haskell-like language...
1/
The mnemonics I use to remember the differences between FoldLeft and FoldRight
@MindOfJoe If you like #FunctionalPrograming you might check out #rakulang. Every #haskel nerd that I know who has tried it has loved it.
Raku is an optionally functional scripting language. https://docs.raku.org/language/haskell-to-p6
I'm wondering if academia has updated the state of the art pattern matcher in #scheme
I don't entirely agree with this, but it does have valid points.
https://us16.campaign-archive.com/?u=8b565c97b838125f69e75fb7f&id=361788c0ea
#DesignPatterns #Programming #PHP #OOP #FunctionalPrograming
@anarres @bobkonf
I started using #HTMX for my personal projects, love it! I'm an old web dev, so it feels like getting back to your roots:
the Old School. πΆοΈ
I also mix HTMX and F# (a clone of #OCaml ). #FunctionalPrograming and HTMX is a great way to build.
In (canonical, simple) Continued Fraction (CFs) representation, every real number is a list starting with an integer πβ and followed by some number (possibly none) of positive integers [πβ, πβ, ...]. In strictly typed programming languages, this is essentially a non-empty list; for example, in Haskell, one can use Data.List.NonEmpty and the CF becomes (πβ :| [πβ, πβ, ...]) = (πβ :| tail).
Haskell's strict typing enforces the non-empty aspect of CFs. The CF list must be non-empty, so we can think of it as a head (the πβ term) and a (possibly empty) tail (the [πβ, πβ, ...] terms). If the tail is empty, then the number is an integer. So the natural numbers 0, 1, 2, ... become (0 :| []), (1 :| []), (2 :| []) and so on in CF representation.
Now, taking reciprocal in CF representation involves either removing πβ if it is 0, or prepending 0 to the whole list. Focusing on the first case, if πβ is 0, then we remove that from the list and keep only the tail terms. This step combined with strict typing shows why there is no reciprocal of 0.
If we start with (0 :| []), remove 0 and only keep the tail then we are left with just the empty list []. However, every real number corresponds to a non-empty list and CFs don't allow empty lists.
Therefore the reciprocal of 0 is not a real number.
#math #ContinuedFractions #type #theory #haskell #FunctionalPrograming
Alright people! Just for fun. Which one do you find like best? #kotlin #justforfun #programing #FunctionalPrograming
An oldie but goodie from @garybernhardt
#Python really is a great programming language! The only thing I dislike about it is that itβs not purely functional.
#Haskell people, what do you prefer?
```
void iOFunction
```
or
```
_ <- iOFunction
```
and why? Is there any difference?
#FunctionalPrograming #haskell #scala
Yeah, all that stuff is quite recent. I remember discovering that and thinking "wow, i' m using stuff that wasn't even formalized a decade ago"
TIL: Applicative was described in a paper just 15 years ago.
I've always thought that all the theory bits in FP were discovered much long ago, but I keep being surprised.
This year, I'm doing Advent of Code for the second time. Last year I did it (half way) while learning Rust. This year, I'm doing it in C++ with a functional style! I'll be sharing my solutions to this repo: https://github.com/somecho/aoc23.cpp
I am not entirely convinced by ChatGPT sense of humour this morning while asking it about abstraction.
"For example, consider monads in functional programming. If someone tells you, "A monad is just a monoid in the category of endofunctors," and you are familiar with monoids and endofunctors, then understanding monads becomes easier."