Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Generalizing 'jq' and Traversal Systems using optics and standard monads

chrispenner.ca

Post reply on HN
Print view View original

71–80 of 102 posts

Re: Generalizing 'jq' and Traversal Systems using optics and standard monads

#71

Post by AnthonBerg »

AlotOfReading wrote: post #57
AnthonBerg wrote: post #41

Earlier quoted context omitted.

Dependent types are able to express the constraints that prevent or catch this error. The types of the arguments to the function can have value constraints on it, and those constraints can be determined from a value that exists there: the name of the function.

Not only do dependent types have huge decidability issues, it's my understanding that integrating them with side effects is still an area of active research.

I think fortunately those are orthogonal matters :)

First, I don't know that dependent types have huge decidability issues that are an inherent obstacle in general; Idris for one has a very practical and elegant model of computation – things like totality checking, linearity rules and elimination of "scaffolding" types do a lot for us.

Dependent types do allow telling the compiler about more dimensions to consider – in a way that allows for a computational explosion at compile time – but those were always an available to consider as part of the computation; Dependent types dont add that complexity, rather they allow us to address it in the type system. I see it such that we're in a stronger position to manage and navigate that complexity by allowing us to express it to the compiler in a succinct and clear way near the core context of desired action. Dependent types allow us to do less by allowing us to do more.

And integrating purely functional mechanisms with side effects is a fun and interesting avenue of research, and I don't know that adding dependent types makes that more difficult; I'd think it makes it easier?

Re: Generalizing 'jq' and Traversal Systems using optics and standard monads

#73

Post by spullara »

dragonwriter wrote: post #29
vortico wrote: post #9

Why do you need all this theory when you can use simple imperative languages? for staff in company.staff: for pet in staff.pets: if pet.type == 'cat': print(pet.name + " belongs to " + staff.name) I don't understand why functional languages are used at all.

Functional idioms are often more expressive when you want to do something with a result other than an immediate side effect like printing. Sure, you can use imperative loops to build up a data structure to work with, but functional idioms (or comprehensions, which are generally an imperative-looking wrapper over functional idioms) can be quite concise and expressive for that purpose. for (owner builds a datastructure…

i would say this is just imperative programming.

Re: Generalizing 'jq' and Traversal Systems using optics and standard monads

#74

Post by spullara »

AnthonBerg wrote: post #72
spullara wrote: post #69

This guy is way better at jq than me.

The theory that describes what jq does and is proven to lead to further places is way better at jq than the implementation of jq that currently exists.

i get it, i just grabbed an optics lib to use it.

Re: Generalizing 'jq' and Traversal Systems using optics and standard monads

#75

Post by AnthonBerg »

vortico wrote: post #9

Why do you need all this theory when you can use simple imperative languages? for staff in company.staff: for pet in staff.pets: if pet.type == 'cat': print(pet.name + " belongs to " + staff.name) I don't understand why functional languages are used at all.

Optics allow us to do something like this:

  import optics.for as o_for
  o_for company.staff.pets as (.{pet}, optics.parentNode as owner) where (pet.type == "cat"):
    print "{.name|%s} belongs to {owner.name|%s}")
We're guaranteed to be safe against null values in company and staff and pets – we don't have to think about it – and no "for" or "if" is required for walking down the structure. Also the types of pet and owner are completely certain, and we can give verified compile-time guarantees that the string we're populating is 100% correct to match the input.

This is the very simplest use of optics. Optics also allow us to do express wild things over those structures, such as selecting nodes based on some defined statistical relationship to the statistics of defined parts of the whole structure. It's as simple and concise as the example above. And as efficient as possible.

Re: Generalizing 'jq' and Traversal Systems using optics and standard monads

#76

Post by [deleted] »

dwohnitmok wrote: post #66
zaptheimpaler wrote: post #60

So overly complicated. The "state of the art" of FP now means heavy type systems and heavy machinery to deal with them. The 80/20 pareto of FP is just pure functions + composing those functions and it works in any language. Here is all of it in python: from __future__ import print_function import json struct = json.loads(open('staff.json','r').read()) staff = struct['staff'] salaries = struct['salaries'] def visit_pe…

This example has nothing to do with type systems. The same system exists e.g. for Clojure (see Specter). The fundamental idea behind the approach in the article is the following: Treat the path through a nested data structure as a first-class thing. This gives helps us mainly in two scenarios: 1. Allowing for easy field-update-like code to exist for immutable data structures in addition to mutable data structures. Th…

[deleted]

Re: Generalizing 'jq' and Traversal Systems using optics and standard monads

#77

Post by AnthonBerg »

vortico wrote: post #15
choeger wrote: post #11

Earlier quoted context omitted.

Functions are composable. Your statement is not. If I would ask you to create a snippet that searches for cats, another one that searches for dogs and a third one that searches for staff that owns both a cat and a dog you will either duplicate a lot of code or end up with functions. Now if you restrict yourself to not introduce any side effects, the interpreter can be proven correct, the execution can be analysed muc…

What's wrong with functions? A function `printCatsBelongingToStaff()` is much easier to read than a line of functional code. I don't understand what you mean by "analyzed much better" and "neat safety guarantees". Is my code hard to analyze or unsafe?

> "analyzed much better" and "neat safety guarantees"

Ah - how about if we add "by the compiler": They can be analyzed much better by the compiler, and we get neat safety guarantees by the compiler.

> Is my code hard to analyze or unsafe?

Not for a human, no :) But optics allow us to drop some boilerplate, retain all flexibility, and also allow the compiler to do a deeper analysis so we can compose computational patterns. That composition composes, so as we build more complex things we have tools with us to help navigate them.

Re: Generalizing 'jq' and Traversal Systems using optics and standard monads

#78

Post by AnthonBerg »

spullara wrote: post #74
AnthonBerg wrote: post #72

Earlier quoted context omitted.

The theory that describes what jq does and is proven to lead to further places is way better at jq than the implementation of jq that currently exists.

i get it, i just grabbed an optics lib to use it.

Sincere apology, in joy too though: My previous comment was intended to be a joke-via-overdefinition but also constructive :) On reread it came out as kinda not-fun pedantry. Thanks for your understanding. I got your joke too :)

Re: Generalizing 'jq' and Traversal Systems using optics and standard monads

#79

Post by AnthonBerg »

AnthonBerg wrote: post #71
AlotOfReading wrote: post #57

Earlier quoted context omitted.

Not only do dependent types have huge decidability issues, it's my understanding that integrating them with side effects is still an area of active research.

I think fortunately those are orthogonal matters :) First, I don't know that dependent types have huge decidability issues that are an inherent obstacle in general; Idris for one has a very practical and elegant model of computation – things like totality checking, linearity rules and elimination of "scaffolding" types do a lot for us. Dependent types do allow telling the compiler about more dimensions to consider –…

To continue the thought: This dependent type is expressible, trivially decidable, and has no additional side effect burden:

"This function's type depends on its function name. If its function name is "sqrt", then {check some simple rules about square roots, like if x is 0 then output is 0, if x > 1 then output This one too:

"This function's type depends on its function name. If its function name is "sqrt", then check that it calls and returns a formally verified square root function applicable to its input type that is known to be decidable and appropriate to the floating point math definitions we're operating in right now"

Re: Generalizing 'jq' and Traversal Systems using optics and standard monads

#80

Post by whateveracct »

formerly_proven wrote: post #44
whateveracct wrote: post #37

Earlier quoted context omitted.

They're good names for a couple reasons 1. The analogies made do hint at their meanings. 2. But at the same time, the names are more proper nouns than definitions. For something so abstract, it's better to give it an opaque, easy-to-remember name than to give it a "better" name that maybe oversimplifies what it is. This is basically the "Functor" vs "Mappable" argument.

They're practically useless for searching for them. Unsurprisingly trying to co-opt widely used terms tends to be ambiguous and confusing (cf. crypto cryptography, cryptocurrency, and those are at least related). Perhaps the only exception in this group is "data lens", which works as a compound [1]. Guess what optics software does? No ETL, that's for sure. Optics patterns? Uh-oh. Optics development? Nuh-uh. Optics da…

Try searching "optics Haskell"

https://www.google.com/search?source=hp&ei=mL5-X7iCJNCs0PEPo...

First result is to the popular and well-documented `optics` library which is exactly this topic. It's perfectly discoverable.

On that note, try googling "Haskell >>=" or "Haskell ". Good results for both. Looks like the "Haskell's symbols and esoterica isn't googlable" is a dead argument now :)

Post reply on HN