<olle>
companion_cube: yes. and then came Goedel and crushed everyone, leading to the current meta-mathematical viewpoint: Shut up and count!
FreeBirdLjj has quit [Ping timeout: 265 seconds]
<d_bot>
<Et7f3> It is funny that all discord users are called d_bot on IRC: We can believe d_bot is a super user 😂
<d_bot>
<Et7f3> Does emotes traverse the bridge ? 😃
<companion_cube>
yep, they're just utf8
<olle>
# let x = Some "asd";;
<olle>
# let Some(y) = x;;
<olle>
Warning 8: this pattern-matching is not exhaustive.
<olle>
but
<olle>
# let Some(y) | None = x;;
<olle>
fails with
<olle>
Error: Variable y must occur on both sides of this | pattern
<olle>
Not possible?
<olle>
Can't assign default value if x = None?
<companion_cube>
on the toplevel, just eat the warning
<companion_cube>
in code, use a function, or a match
dborisog has quit [Ping timeout: 264 seconds]
cantstanya has quit [Ping timeout: 240 seconds]
cantstanya has joined #ocaml
<def>
let (Some (y), _ | None, y) = x, default;;
<def>
(don't try this at home)
<companion_cube>
don't you still get a warning? :D
<theblatte>
no, why would you?
<companion_cube>
binding y from different parts of the pattern? I forgo
<companion_cube>
there's a warning for sometihng like that, but I can't remember what exactly
<companion_cube>
maybe ((x,_) | (_,x)) -> …
<def>
it's an or-pattern, you better bind the same names on both side, otherwise you get an error :)
<theblatte>
companion_cube: maybe you mean | (x, _) | (_, x) when something about x ->
<theblatte>
the warning about the fact that it will only try one of the matches and if the when clause fails then fail the match even though the other one might succeed
<olle>
def: wia
<olle>
woa
<theblatte>
for reference the non-joke answer is "let y = match x with Some y -> y | None -> default"
<olle>
let x | _ -> "default" = y
<olle>
bah
<olle>
theblatte: yeah, but how fun is that? xD
<theblatte>
sorry /o\
<theblatte>
obviously I meant "you should use a GADT to rule out the None case for your x"
<olle>
equally horrible is let unpack x = match x with Some x -> x | None -> failewith "lol"
<olle>
theblatte: that's possible?
<theblatte>
well at least if that fails you'll know the informative "lol"
<theblatte>
olle: sure
<olle>
theblatte: how? I need to brag on reddit (/r/reasonml)
<theblatte>
I'll let you unpack the existential yourself :p
<theblatte>
but it won't be the regular "option" type any more
<olle>
bah
<olle>
when there's finally a normal use-case for gadt
<theblatte>
some standard libraries have helpers for this, eg Base has Option.value x ~default
<olle>
i can imagine
<companion_cube>
CCOpt.get_or ~default x
<companion_cube>
it's the most basic function in any Option module :D
<companion_cube>
(with map and flat_map)
<theblatte>
hey there's map in Stdlib
<theblatte>
no exists though
<theblatte>
wait a minute
<theblatte>
there's Option.value too!!
<theblatte>
I forgot it was added
<theblatte>
so in a couple years reason should have it too /o\
<olle>
or their own version
<companion_cube>
well, they're on 4.06 now I think?
<companion_cube>
or is that BS?
<theblatte>
the only limit is BS AFAIK
zolk3ri has quit [Remote host closed the connection]
ipavlo_ has joined #ocaml
<olle>
oh, so gadt is a form of type refinement? didn't know
<olle>
i thought it was intellectual masturbation...
<olle>
well, it can be both ^^
<olle>
can serialization be type-safe?
<companion_cube>
with codegen, yes
<companion_cube>
(or manually written code)
<olle>
companion_cube: or phrased like this: how do I know ppx_deriving_json.ml is correct?
<olle>
compared to, e.g., JSON.stringify?
<olle>
(in js)
<companion_cube>
these seem like totally different things
<companion_cube>
JS doesn't even have type safety? :)
<olle>
i know
<olle>
but both must be validated using testing anyway?
<companion_cube>
for ppx_deriving, you trust it like you would trust any library
<olle>
yeah, but then it offers no benifit compared to JSON.stringify(myObject);
<companion_cube>
there is no JSON.stringify in OCaml
<olle>
no, i'm comparing with javascript
<companion_cube>
(I mean, it's called Marshall, and is very very unsafe)
<companion_cube>
but you're comparing super different things
<olle>
so?
<olle>
hm, this feels like the same problem to proof that a compiler outputs the intended assembler code
<companion_cube>
programs are (almost) never entirely bug frees
<olle>
sure
<companion_cube>
but you can probably trust ppx_deriving more than handwritten code, typically, since it's code that is more mature and has had more time to mature
<olle>
but, i wanted to write a blog post about type-safe websocket communication, but if it boils down to "trust the lib", it doesn't matter if you use ocaml or javascript on both server/client
<companion_cube>
but in JS, when you deserialize, you don't validate anything, do you?
<companion_cube>
whereas ppx_deriving is going to take json and either fail, or return a valid value of your type
<companion_cube>
that's where the difference is
<olle>
no, it's still at runtime
<companion_cube>
I mean, you can't guarantee that a connection is valid
<companion_cube>
but you can guarantee that if the deserializer gives you `Ok x` then x is valid
<companion_cube>
in json you just cast, right?
<companion_cube>
(or pray)
<companion_cube>
so it fails anywhere in the program instead of giving you a neat error at the edge of your program
<olle>
no, you use JSON.parse() to get a JS object
<olle>
i assume it throws an exception? not sure
<companion_cube>
==> not comparing the same thing
<companion_cube>
if you compare with typescript, that's more interesting
<companion_cube>
cause there you have types
<companion_cube>
but JSON.parse() gives you Any, and then you just yolo-cast it (typically)
<olle>
hm, true
<companion_cube>
JSON.parse is basically `Yojson.from_string`
<companion_cube>
not `foo_of_json` for a given type foo
<olle>
right
<olle>
it's a customized parser, one can say, maybe?
<companion_cube>
parser + validation + conversion
<olle>
very good points
<companion_cube>
also the reason why protobuf and co exist
<olle>
protobuf?
<companion_cube>
(they do both the serialization stuff, and the validation aspect)
<waleee-cl>
oh, typescript. Must be old-ish? var has gone out of fashion
<olle>
waleee-cl: yeah, that first quote was from stackoverflow
<olle>
sorry, i'm mixing up my references
<olle>
"The crux of the problem is that when you round-trip serialize/deserialize a TypeScript class to JSON, what you get back is not an instance of that type. You just get back a generic object with all the same data fields as your class."
<olle>
with ppx_deriving_json, would it be possible to serialize type t = Foo of string, but then unserialize it in type s = Bar of string?
<zozozo>
olle: you'll get a runtime error
<zozozo>
as far as I recall, ppx_deriving_yojson encodes the name of the constructor in the serialised json
<zozozo>
but if you ahve type t = Foo of string and type t' = Foo of string, you you could potentially cross-serialize
smazga has quit [Ping timeout: 256 seconds]
<olle>
zozozo: wrong ppx, i'm talking about ppx_deriving_json, not yojson
<olle>
zozozo: ok
<zozozo>
ah, sorry I misread, I haven't used ppx_deriving_json yet so I don't know
ansiwen has quit [Read error: Connection reset by peer]
ansiwen has joined #ocaml
<companion_cube>
it'll fail to deserialize because of the cstor name indeed
<zozozo>
hm.. the doc about ppx_deriving_json is surprisingly small (and by that I mean lacking any information about how types are encoded into json, :p )
<flux1>
is Containers still the lib to go, if the standard library, Core or Batteries don't satisfy?-)
<companion_cube>
I mean, if you eliminate all the other choices, then it's all that remains, yes :D
<companion_cube>
tautologically
<flux1>
there could be new ones!
<flux1>
exciting forks
<zozozo>
well, iirc tablecloth is more or less a fork of containers (at least partially ?)
<companion_cube>
ah, well, it's in reason land
<zozozo>
indeed
<olle>
wrong
<olle>
type t = Two 2
<zozozo>
but anyway, it hasn't really established itself as a reasonable stdlib alternative/extension in ocaml land as far as I can tell
<olle>
and type s = Two 2
<olle>
both serialize to [0,2]
<olle>
:(
<zozozo>
oh, so it looks like ppx_deriving_json encodes only the tag/order of the constructor whereas ppx_deriving_yojson encodes the name (the numebr might be slightly faster I suppose ?)
<olle>
i guess
<companion_cube>
ahh, ppx_deriving_json, idk this one
<olle>
ok, but then again, the type-safety between the client and server is nil?
jnavila has joined #ocaml
<olle>
except maybe in an ocsigen project, where to put server/client code in the same file
pigeonv has quit [Ping timeout: 246 seconds]
<zozozo>
olle: not nil, but in any case, when you receive a string from any source not in the program itself, you can't really trust it so you'll always need to parser and validate it and treat the potential error case (if only because the network would have dropped and/or modified the message)
<olle>
yeah
<zozozo>
for inter-process messaging between the same ocaml program, marshalling could be relatively safe I'd say (as long as used properly)
<olle>
bah
jnavila_ has joined #ocaml
<zozozo>
I think ocsigen uses marshall to transfer things between client and server more or less transparently from the user's perspective if I recall correctly
jnavila has quit [Ping timeout: 256 seconds]
<olle>
ok
<companion_cube>
marshall is useful, but dangerous
<zozozo>
indeed
<olle>
why dangerous?
pigeonv has joined #ocaml
<companion_cube>
because if you give the wrong type when you deserialize, it can segfault
<zozozo>
basically deserializing with Marshall gives you an ocaml value, but marshall cannot know of which type since types are erased at compile-time
<zozozo>
so to use the deserialized value, you need to unsafely cast it to the type you know (or pretend to know) it should be
<olle>
zozozo: sounds like same issue as ppx_deriving_json
<olle>
so, will ppx yojson play well with js_of_ocaml, i wonder...
<zozozo>
olle: it seems a bit similar indeed (though a bit less so I suppose, for instance, I expect ppx_deriving_json to return an error in the following case : type = Foo of string type s = Foo of string | Bar of int, let _ = t_of_json (to_json (Bar 1)) )
<zozozo>
whereas marshall would not raise an error and silently let your program segfault later
<olle>
yikes
<olle>
D:
<zozozo>
(ppx_deriving_json can know that t_of_sjon cannot handle construcotrs past the only construcotr with tag 0, so it can raise an error if something is really out of range)
<zozozo>
that's what companion_cube meant by Marshall is unsafe, ^^
<olle>
hehe, both Two 2 and Five 2 will serialize identically if they have the same position in the type def.
<olle>
zozozo: kk!
smazga has joined #ocaml
narimiran has quit [Ping timeout: 265 seconds]
<olle>
would be nice with a serializer that *provably* will serialize it to a unique string
<olle>
again, i need my own team of master students!
<companion_cube>
serializing is the easy part
<companion_cube>
deserializing is the hard part
<olle>
why? if it's provably unique
<simpson>
Because having the names for functions/procedures/classes/etc. does not automatically ensure that such code objects are in the deserializing process.
<companion_cube>
unique wrt what
<olle>
wrt any other possible type? maybe not possible with nominal typing and type abstraction :d
<simpson>
And you probably do *not* want tools that make this easier. Java's JOSS and Python's pickle are two good examples of when putting class names into the serialized data stream turned out to be a Bad Idea.
<companion_cube>
if you serialize the OCaml program (the .exe) along with the value, maybe you stand a chance :D
<olle>
hehehe
<companion_cube>
otherwise, no chance
<olle>
Modulename_typename <--
<companion_cube>
it's still not unique
<companion_cube>
cause 2 different versions of your program will use the same name
<olle>
true
<olle>
hm hm hm
<companion_cube>
(hence my quip about serializing the whole program alongside, which is ridiculous)
<olle>
simpson: PHP does that too, I believe
<companion_cube>
(or a hash of it, which is less bad)
<olle>
hash collision!!!!!1111
<companion_cube>
I don't care about crypto hash collisions
<companion_cube>
they're not very realistic
<olle>
i know, it was a joke :)
<olle>
there's a linus rant about it
<simpson>
Capn Proto and Protocol Buffers store a hash of each structured layout, and each hash can only be used once per linkage. But (1) they were *designed* for serialization, and (2) they don't solve the Upgrade Problem transparently, because you probably don't want fully transparent Upgrades!
<olle>
ok
<zozozo>
well, to has type-safe deserializing, you'd need to include the type definition of the all the serialized values when serializing, and then check those, which would be very heavy (and lead to the same runtime errors as say ppx_derigin_yojson actually)
<olle>
i need to rename the title of my blog...
jco has quit [Quit: WeeChat 2.8]
<olle>
type-safe websocket communication - it's not possible
<zozozo>
well, it's some kind of trust problem, I'd say
<olle>
still, ocaml is interesting, because it's one of the few langs where you can write both server and client code
<zozozo>
type-safety in youre program works because you have one entity (the compiler) which checks the types
<olle>
or maybe they all compile to js these days? dunno anymore
<zozozo>
but over the network, you need to truste the program at the other end, the network itself, etc... and it's not realistically feasible i'd say
<simpson>
Yep. Type systems cannot be extended over The Network. They cannot even be extended over The Filesystem. Erasure to bytestrings removes any hope of uniquely reconstituting a heap from a serialized object.
<companion_cube>
crypto hashes can get you quite far though
<simpson>
Sure. Unguessable strings are hard to guess, by definition.
<zozozo>
olle: for most cases, certianly, but you can always imagine a situation where two types have the same name and the same structure but not the exact same invariants across two programs
<zozozo>
(imagine someone that code the same map as search tree but one in the left-to-right order and the other the the right-to-left ordering)
<zozozo>
(you might be type-safe but not semantic/abstraction-safe I suppose, :/ )
<olle>
interesting point
vicfred has quit [Read error: Connection reset by peer]
vicfred has joined #ocaml
vicfred has quit [Max SendQ exceeded]
vicfred has joined #ocaml
vicfred has quit [Max SendQ exceeded]
vicfred has joined #ocaml
<zozozo>
you also have potential attack scenarios where someone/something will alter the serialised data (e.g. by un-ordering bindings of a map), which might make a program fail in unepexcted way if the deserialized data is not checked
<flux1>
if I have an exception, I store the exception, and reraise later, is it possible to recover the original backtrace if I don't store it when I first received it?
<flux1>
Cool, Printexc: val raise_with_backtrace : exn -> raw_backtrace -> 'a
<flux1>
helps, though I still need to store it
Hrundi_V_Bakshi has joined #ocaml
Jesin has quit [Quit: Leaving]
Jesin has joined #ocaml
jnavila_ has quit [Quit: Konversation terminated!]