07:45 <aldos> hi, i was reading the tutorial, i have question on type inferece output

07:46 <aldos> let deriv f dx = function x -> (f (x +. dx) -. f x) /. dx;;

07:47 <aldos> system output of this phrase is - val deriv : (float -> float) -> float -> float -> float = <fun>

07:48 <aldos> I see there is a pair of () in the beginning, meaning taking a funciton?

07:49 <aldos> but it returns a function, which takes one float and returns a float, but i don't see any () around the last two floats

07:56 <aldos> i am seeing same kind thing other places too

08:01 <ski> aldos : the `->' infix operator is right-associative, meaning that `foo -> bar -> baz' is parsed as `foo -> (bar -> baz)'. compare with e.g. `/.' being left-associative, meaning that `x /. y /. z' is parsed as `(x /. y) /. z'

08:02 <ski> so, fully bracketted, the signature would look like

08:02 <ski> val deriv : (float -> float) -> (float -> (float -> float))

08:03 <ski> similarly, the function application "invisible juxtaposition operator" is also left-associative, meaning that `deriv f dx x' parses as `((deriv f) dx) x'

08:03 <ski> assuming that you have some variables `f',`dx',`x' in scope such that

08:03 <ski> val f : float -> float

08:04 <ski> val dx : float

08:04 <ski> val x : float

08:04 <ski> we can deduce

08:04 <ski> val deriv : (float -> float) -> (float -> (float -> float))

08:04 <ski> val deriv f : float -> (float -> float)

08:04 <ski> val deriv f dx : float -> float

08:04 <ski> val deriv f dx x : float

08:05 <ski> aldos : making sense ?

08:09 <aldos> hmm, i think i understand. i quite new two functional progamming, first time learning

08:10 <aldos> \me just made a lot of typos.....

08:10 <ski> note that you could also have defined `deriv' as :

08:11 <ski> let deriv f dx x = (f (x +. dx) -. f x) /. dx;;

08:11 <ski> or

08:11 <ski> let deriv f = function dx -> function x -> (f (x +. dx) -. f x) /. dx;;

08:11 <ski> or

08:11 <ski> let deriv = function f -> function dx -> function x -> (f (x +. dx) -. f x) /. dx;;

08:11 <ski> or

08:11 <ski> let deriv = fun f dx x -> (f (x +. dx) -. f x) /. dx;;

08:13 <ski> presumably they chose the one would showed above, to emphasize that we think of `deriv' as computing a new *function*, given an input function `f', and a small offset `dx'

08:13 <ski> s/one would showed/one you showed/

08:13 <ski> aldos : have you heard about currying, and partial application ?

08:15 <aldos> i heard about currying

08:15 <ski> well, both are about "multiple parameter functions"

08:16 <ski> OCaml doesn't have those. all functions in OCaml takes exactly one input parameter/argument

08:16 <aldos> opps, i thought the are about single parameter functions

08:16 <ski> however, you can *encode*/*represent* multiple parameter functions, in OCaml .. in fact, you can do it in *two* main (different) ways

08:17 <ski> one can be called "tupling". in this way, you pack all the would-be multiple parameters into a single compound aggregate, making that the actual single parameter of your function

08:17 <aldos> like one would define add as a function which takes one param and returns a function which takes one param and return a value

08:19 <ski> typically, you'd pack them into a tuple .. but one could also pack them into a record (`struct', or even "object", if you prefer), or possibly sometimes some other compound structure, like a list, vector or array, or perhaps finite map of some sort (in math, bag/multiset, and set, isn't too uncommon, either)

08:19 <ski> so, you could have said

08:20 <aldos> hmm, i need some more reading before

08:20 <ski> let derivTupled f_and_dx = function x -> ((fst f_and_dx) (x +. snd f_and_dx) -. (fst f_and_dx) x) /. snd f_and_dx;;

08:21 <ski> where `fst' and `snd' extracts the actual `f' and `dx' components of the `f_and_dx' pair that we're interested in (we could have used a `let' in the body of the function, to extract these once, rather than two times for each)

08:22 <ski> however, because OCaml has *pattern-matching* (in this case on tuples), we could write this instead simply as

08:22 <ski> let derivTupled (f,dx) = function x -> (f (x +. dx) -. f x) /. dx;;

08:22 <ski> (generally you want to use pattern-matching, when you can, rather than accessor/selector functions like `fst',`snd', since it becomes much more readable)

08:24 <ski> now, the *other* way to encode multiple parameter functions is, as you hopefully have already seen to some extent, to make a function that accepts one parameter, and returns/computes a new function that accepts all the remaining ones (usually, one at at time, returning new functions, until we've taken all parameters and can return the final result)

08:24 <ski> this is the `deriv' version you showed above

08:25 <ski> oh, aldos left

09:08 <olle> I still need some help rewriting pipe with let* in this case here: https://discuss.ocaml.org/t/prohibiting-invalid-states-with-gadt-the-airlock-exercise/10585/13

12:47 <ski> "Or is there a way to pick only 'a, and ignore 'b and possibly 'c, etc" -- hm, i guess you want some way to have the components referred to by name/label, rather than position, and then being able to only mention the ones which are relevant at a particular point

12:47 <ski> (this reminds me of attribute grammars .. hm, and perhaps it would be possible to do something with row types and row polymorphism ?)

12:51 <ski> hm .. (after looking up `let*' in the manual ..) i think you'd need to store both the input and the output (type) state as parameters of your type `t' ? .. meaning indexed monads, rather than plain monads

12:52 <ski> (hm, vaguely reminds me of McBride doing something with expressing Hoare triples in, i think, a somewhat different way (predicate transformers ?) .. now, if i could recall in which paper i saw that ..)

12:53 <olle> haha lots of parenthesis here

12:53 <olle> ski: yeah, type-level records and then match on them. Maybe a weird feature to want, dunno

12:56 <ski> not really .. i've wanted it, several times, in Haskell (e.g. indirecting fixed-points of mutually-recursive ASTs)

12:57 <ski> there is one GADT trick one can use, to simulate type records, assuming all components have the same kind

13:02 <olle> Yeah?

13:03 <ski> basically, representing k * k as bool -> k .. hm, although now i'm wondering if OCaml supports datakinds (and higher-order types) yet (here bool would be a datakind) .. anyway, the idea is that, in a GADT, instead of matching on a type record (naming the components) in the result type of your data constructors, you call the "record" say 'f and then you pass your "record tags/labels" as argument to

13:03 <ski> that, when you want to refer to a particular component, like false 'f

13:07 <ski> (anyway, you only wanting the mention the relevant components does sound a bit like the "expression problem", and how semantic actions (specifying how to compute synthesized attributed from inherited ones, possibly also involving state-threaded ones) attaches to productions in an attribute grammar only need to mention the relevant attributes for that semantic action .. you can define things separately, and

13:07 <ski> then "mix-in them together")

13:25 <ski> (hm, it may have been "Kleisli arrows of outrageous fortune" by Conor McBride in 2011-03-12 at <https://personal.cis.strath.ac.uk/conor.mcbride/Kleisli.pdf> that i was thinking about)

13:51 <olle> Bit too complicated for me, I'm afraid

14:31 <jedb> let ( @@ ) f g x = f (g x)

14:31 <jedb> let ( |> ) f x = f x

14:31 <jedb> there we go, much better :)

14:47 <jedb> it makes more sense that way

14:51 <ski> hm, i thought there already was a function composition operator ..

14:51 <jedb> apparently not, which was the first problem

14:52 <jedb> so if one of @@ and |> is going to be composition, then it should be the higher priority one that coincidentally looks like the mathematical composition operator, making @@ composition and leaving |> to be application

15:03 <ski> makes sense

16:08 <reynir> ski: yea, you can open Lwt.Syntax for let* etc

16:14 <olle> https://stackoverflow.com/a/15630930/2138090

16:14 <olle> Ten years ago

16:14 <olle> Ah, to be young again

20:02 <companion_cube> jedb: neither is about composition, they're just about application.

22:04 <jedb> companion_cube: I know, and that's dumb, particularly because the documentation lists them under "composition operators"

22:05 <jedb> not even sure why one would even want a reverse application operator

23:31 <ski> reynir : ok, ty. i only saw <https://ocsigen.org/lwt/latest/api/Lwt> mentioning `let%lwt', while "PPX syntax extension" <https://ocsigen.org/lwt/latest/api/Ppx_lwt.html> was 404

23:33 <ski> jedb : some people like "noun.verb.verb" order