tel

35 ms·

391.
by tel 9y ago
I disagree it’s impractical—it’s just not valuable. Assoc-In reads as convenient to you, and it is if you’ve already thrown away type information, and reads as destructive to me, a force for destroying information. Lenses aren’t better beca
392.
by tel 9y ago
Honestly, at this point if you’d like to keep chatting, would you mind emailing me? I’d like to discuss these ideas further if it’s of interest.
393.
by tel 9y ago
It doesn’t really. I’m not claiming this works with standard Haskell practice. Typed techniques don’t translate directly to untyped things. The act of traversing each time is “forgetting”/“synthesizing” type information and is exactly
394.
by tel 9y ago
I fixed the type errors in what I presented before. Little changed: I had to fix the typos, bad imports, and missing pragmas, and then I had to instantiate Val as Hashable and Eq, but since all things inside of Val are Hashable and Eq it wa
395.
by tel 9y ago
Apologies, quick sketch in an airport between flights. May fix this later when I’ve actually got an internet connection.
396.
by tel 9y ago
> I mean it should work for every `Data.Map k a`, where `k => Ord`, just like all the other Data.Map functions. This is where we're got a difference of opinion. My statement is that assoc-in doesn't do anything close to wo
397.
by tel 9y ago
It’s feasible and easy to write assoc-in atop of Dynamic... it’s just not done because nobody programming in Haskell thinks it’s valuable. We could choose to support much more opt-out dynamic behavior no sweat, but nobody wants to. The id
398.
by tel 9y ago
I wouldn’t because once I’ve got a type system the tradeoff never works out. But the same thing can be expressed. I don’t see the thrust of your argument. You can write both styles of program in both languages, but you can only have type gu
399.
by tel 9y ago
When they keys are all different types then you've got data Value = ... | VMap (Map Value Value) ... assocIn :: [Value] -> (Value -> Value) -> (Value -> Value) I was again assuming types more
400.
by tel 9y ago
There's also the way where you encode `Map String Value` as a member of `Value`. This is closer to what Clojure does and does allow assoc-in to be written directly. I was just playing along with the other comments' encoding of m
401.
by tel 9y ago
You can use lenses, it's something like over (at "foo" . at "bar") :: (a -> b) -> (Map String (Map String a) -> Map String (Map String b)) Neatly, this system generalizes to typed realizations imme
402.
by tel 9y ago
That seems wrong... Your x100F has an APS-C sensor and is going to benefit from better dynamic range and low light performance for it. The iPhone can use its auto HDR magic to recover dynamic range but that's gotta have an impact with
403.
by tel 9y ago
Being pretty familiar with Haskell and programming in Scala nowadays, I think Haskell's dogmatic nature makes it much easier to program in! Consistency minimizes conceptual overhead when programming by a lot.
404.
by tel 9y ago
Endomorphism has less implied structure. Lots of dumb things are endomorphisms. Homomorphism implies "structure preservation" which can make it more specific.
405.
by tel 9y ago
That has a little to do with Scala just being a pretty bad place to implement most of these things. E.g., Monad transformers work just great in Haskell but are terrible in Scala due to the sort of terrible ways type parameters and inference
406.
by tel 9y ago
Generally, no. As others have mentioned, Mathematics isn't really a language. It's at the very least absolutely certainly not one language. Certain parts of Mathematics use a typed language. Certain parts rely on other kinds of
407.
by tel 9y ago
Probability theory is the study of distributions of constant measure in measure theoretic terms. There are some good resources that mtzet mentions, but I just wanted to note that a lot of the integration terminology which you take for grant
408.
by tel 9y ago
Calculus essentially discusses how things change smoothly and it has a very nice mechanism for talking about smooth changes algebraically. A system which is at an optimum will, at that exact point, be no longer increasing or decreasing: a m
409.
by tel 9y ago
I'm aware of polymorphic variants and row types and the like. My concern is one of modularity in that I consider a running system pretty dead, extensions during coding are where language features and their logics are interesting. Clo
410.
by tel 9y ago
Not true. You can model sums with inheritance along with an exclusivity constraint, but it's a weird model and subtyping is more general. Further, the idea of each variant being its own type is inherently a subtyping sort of idea. Sums
411.
by tel 9y ago
Type theory isn't FP as much as logic--it applies everywhere. That said, totally agree that you're unlikely to have encountered it outside of an FP context in 2017. Product and sum type are fundamental structures for construction
412.
by tel 9y ago
This is largely to do with subtyping and it's well known that systems with user-defined nominal subtyping don't have good inference. Scala's inference is really in the middle: squarely better than C/Java and much worse t
413.
by tel 9y ago
Dunfield-Krishnaswami handles higher ranked polymorphism but is probably most famous for just being a very nice presentation of bidirectional typechecking. Algorithm W (Hindley-Milner) is only able to infer first-order polymorphism occurrin
414.
by tel 9y ago
The algorithm is split into two mutual components the "inference" and the "checking" (upward and downward) which run together. This turns out to be a really flexible setting for playing with language and type features as
415.
by tel 9y ago
Haven't used PHP in more than a decade so I looked up the documentation. The most relevant parts I could find were "Classes and Objects" and "Namespaces". After a rough review, I'd say that the it is possible
416.
by tel 9y ago
Many of the ideas expressed here may feel like bells and whistles but tend to have a formal backing which makes them quite a bit different than other language features. They might still impact UI in a way that's highly undesirable, b
417.
by tel 9y ago
"looking to get into..." -- No, not at all. It will lead you down a long rabbit hole that doesn't actually wind up anywhere too close to functional programming. CT is great for "looking to get really good at" FP. It
418.
by tel 9y ago
Why are you asking me? If it's to imply that the answer is "obviously not" so as to project it to other readers then why are you trying to answer for them? Clearly others have decided that what you suggest is either unnecessa
419.
by tel 9y ago
Ha, thank you.
420.
by tel 9y ago
Your argument seems to be that "Real World Haskell" uses obscure features that I and many others don't understand, thus Haskell is complex. This is true if it is (a) impossible to write "Real World" Haskell without

More ›