15:05 <greenbagels> question: if i want to convert an int to char and vice-versa (basically a bijection from some set of chars to some set of ints), what would be the best way to implement this?

15:06 <greenbagels> currently i have two pattern matching functions for the char -> int function and inverse function

15:06 <hannes> greenbagels: if it is a small set of char, int - you could use an association list [ ('a', 1) ; ('b', 2) ] and do lookups / reverse lookups

15:08 <hannes> or construct maps (int -> char ; char -> int) at load time.. I guess what I'd express is: depends on your use case and performance requirements

15:12 <greenbagels> im just wondering if there's a way to have some kind of single interface for such a function

15:12 <greenbagels> but i think the type system would make that hard

15:14 <greenbagels> maybe wrapping the two functions in a function that takes a variant IntOrChar type and dispatches to the appropriate function on the raw data types...

16:21 <zebrag> hannes: two first functions there https://v2.ocaml.org/api/Char.html

16:39 <zebrag> Functions of_int and to_int, for unicode characters, there: https://ocaml.org/p/ocaml-base-compiler/4.14.0/doc/Stdlib/Uchar/index.html

20:31 <ski> olle : fwiw, <http://gallium.inria.fr/%7Eprotzenk/mezzo-lang/> (from that SO answer) 403s

20:31 <ski> zebrag : 404

20:33 <ski> (also, i forgot if it was mentioned, but Rust does not have a "linear type system". iiuc, it's more about uniqueness)

20:34 <qwr> i think it was called affine types

20:44 <ski> that's also not the same thing

20:46 <ski> linear types/logic forbid contraction (using a variable/assumption more than once) and weakening (not using a variable in scope). affine types/logic only forbid contraction. there's also relevant/relevance types/logic, which forbid weakening but not contraction. and there's ordered / non-commutative logic, which forbids contraction, weakening, exchange (using variables/assumptions out of order (of

20:46 <ski> introduction))

20:47 <ski> (and when i say "forbid" i mean "forbid, generally". it's still possible to do these things, in some particular circumstances, you've opt-in. the so-called "modalities" ("of course","why not", variations))

20:47 <ski> anyway ..

20:49 <ski> with linearity/affinity, you can't duplicate (not discard, for linear case) in the future. but you might already have duplicated in the past (before deciding to opt out of that capability, for the present reference, using "dereliction", converting an unrestricted reference to a linear/affine one)

20:50 <ski> (so, you can't assume uniqueness of reference, and can't do update-in-place)

20:53 <ski> whereas, with uniqueness, you know you haven't duplicated (and obviously not discarded either, since you have a reference) in the past, but you're still allowed to duplicate in the future (unless you have to conform to an interface which requires you to return a unique reference, say ..). so you can update-in-place (arrays and other mutable structures, as well as virtual I/O token sequencing. also reusing dead

20:53 <ski> allocated nodes (possibly not having to copy over some fields), or else statically inserting calls to `free')

20:54 <ski> Clean and Mercury uses uniqueness. i haven't looked in detail at what Rust does, but afaiui, it uses at least something similar/related

20:54 <ski> Start :: *World -> *World // Clean

20:55 <ski> :- mode main(io :: di,io :: uo) is det. % Mercury

20:56 <ski> (`*' means "unique". `io' is a type, and `di' and `uo' are parameter modes, short for `unique >> dead' and `free >> unique', meaning "destructive input" (consumes unique reference) and "unique output" (produces unique reference))

21:36 <greenbagels> ski: small world huh

21:37 <greenbagels> i was going "why are they talking about this in the math channel"