<d_bot>
<xxxquantacion> you can use emacs to replace both 😉
<companion_cube>
no thanks :p
waleee has quit [Ping timeout: 272 seconds]
waleee has joined #ocaml
waleee has quit [Ping timeout: 252 seconds]
unyu has joined #ocaml
<d_bot>
<darrenldl> using emacs for everything sounds like a security nightmare
mbuf has joined #ocaml
<d_bot>
<NULL> I had a question in #beginners that wasn't well written, and I didn't get satisfying answers. I'm retying here, with a better written question hopefully.
<d_bot>
<NULL> According to the OCaml documentation, value restriction (setting all free type variables of the type of a value to be weakly polymorphic) happens for every value that is the result of function application.
<d_bot>
<NULL> Syntactic "computations" should not trigger value restriction.
<d_bot>
<NULL>
<d_bot>
<NULL> With context
<d_bot>
<NULL> ```ocaml
<d_bot>
<NULL> type t = { id: 'a. 'a -> 'a }
<d_bot>
<NULL> let hidden_id () = { id = Fun.id }
<d_bot>
<NULL> let unhidden_id = (hidden_id ()).id
<d_bot>
<NULL> ```
<d_bot>
<NULL> first `hidden_id ()` is typed with value restriction, to `t`, then the `id` field is syntactically accessed.
<d_bot>
<NULL> Is there a reason to still apply value restriction here ?
zodeishi has quit [Ping timeout: 272 seconds]
zebrag has quit [Remote host closed the connection]
adrien_ has joined #ocaml
mosterdt_ has joined #ocaml
bacam_ has joined #ocaml
habnabit has joined #ocaml
habnabit has joined #ocaml
adrien has quit [*.net *.split]
mosterdt has quit [*.net *.split]
habnabit_ has quit [*.net *.split]
bacam has quit [*.net *.split]
<d_bot>
<xxxquantacion> why?
<d_bot>
<darrenldl> unless im mistaken, you'd have many components sharing the same process space with no clear sandboxing mechanism
<d_bot>
<darrenldl> well okay, it does not make things worse than the default scenario, but makes it very difficult to fit principle of least privilege back into the system
<d_bot>
<darrenldl> similar to microkernel vs monolithic kernel debate
shawnw has quit [Ping timeout: 252 seconds]
mro has joined #ocaml
Haudegen has joined #ocaml
jbrown has joined #ocaml
bacam_ is now known as bacam
bartholin has joined #ocaml
fluxm has quit [Write error: Connection reset by peer]
krnkktz has quit [Remote host closed the connection]
smondet[m] has quit [Remote host closed the connection]
Sumera[m] has quit [Remote host closed the connection]
radiopotin[m] has quit [Remote host closed the connection]
labor[m] has quit [Read error: Connection reset by peer]
olle has joined #ocaml
labor[m] has joined #ocaml
krnkktz has joined #ocaml
fluxm has joined #ocaml
Sumera[m] has joined #ocaml
smondet[m] has joined #ocaml
radiopotin[m] has joined #ocaml
yoctocell has joined #ocaml
wonko has joined #ocaml
dhil has joined #ocaml
yoctocell has quit [Remote host closed the connection]
yoctocell has joined #ocaml
favonia has quit [Ping timeout: 272 seconds]
yoctocell has quit [Remote host closed the connection]
yoctocell has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
<d_bot>
<octachron> @NULL : The point of the value restriction is that it is sound if too conservative. One need a reason to lift the value restriction, not the other way around. The issue that you are pointing is due to the fact that the typechecker doesn't track precisely which type variables come from a nonexpansive (side-effect free) subexpressions. Notice for instance that `Fun.id` type is not generic anymore in `let weak = ref None, Fun.id`.
rks` has quit [Ping timeout: 264 seconds]
zodeishi has joined #ocaml
rks` has joined #ocaml
zodeishi has quit [Quit: Leaving]
mro has quit [Remote host closed the connection]
cedric has joined #ocaml
mro has joined #ocaml
mro has quit [Ping timeout: 272 seconds]
wonko has quit [Ping timeout: 250 seconds]
mro has joined #ocaml
mro has quit [Ping timeout: 272 seconds]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
<d_bot>
<bikal> Is this not possible?
<d_bot>
<bikal> ```module type M = sig
<d_bot>
<bikal> type 'a t
<d_bot>
<bikal>
<d_bot>
<bikal> type input
<d_bot>
<bikal>
<d_bot>
<bikal> type 'a promise
<d_bot>
<bikal>
<d_bot>
<bikal> val run : input -> 'a t -> ('a, string) result promise
<d_bot>
<bikal> end
<d_bot>
<bikal>
<d_bot>
<bikal> type 'a m = (module M with type 'b t = 'a t)```
<d_bot>
<bikal> i.e. `type 'a m` gives me and error `invalid package type ...`
<d_bot>
<octachron> It is indeed not possible.
<d_bot>
<bikal> ok. so there is no way to use first class modules with `'a t` types in them and specify type equality?
<d_bot>
<bikal> so I suppose this is one of the diffs between functors and first-class modules.
<d_bot>
<octachron> It is more the difference between first-class modules (which are more about hiding internal types) and lightweight functors (à la modular explicit). But yes, this is a case where moving to the functor solves the issue.
Haudegen has quit [Quit: Bin weg.]
mro has quit [Read error: Connection reset by peer]
andreypopp has joined #ocaml
mro_ has joined #ocaml
bnrroy has joined #ocaml
<bnrroy>
Bonjour, je dois développer une fonction qui vérifie si une hypothèse est vraie en vérifiant les règles (faits et conclusions) incluses dans un système expert. J'ai trouvé un algo en pseudo-code pour le faire mais j'ai de la difficulté à le traduire en OCAML. Quelqu'un pourrait m'aider?
<olle>
Oh la la
<bnrroy>
ouin...
<zozozo>
bnrroy: this channel is mostly english-speaking, but you can join #ocaml-fr to speak french, ^^
<zozozo>
bnrroy: well, if you could first describe what you have tried and what's blocking you, then we'll be able to give you pointers
<zozozo>
also, how much experience do you have with OCaml ?
<bnrroy>
it is my first class in ocaml, so not much experience in a functionnal language.
<bnrroy>
First, what would be the equivalent of For each ?
<zozozo>
well, it depends, on what structure do you want to iterate ? i.e. do you want "for each" element of a linked list ?, or for each element of a set ? or for each element of an array ?
<bnrroy>
can I paste some line of code right here?
<zozozo>
bnrroy: please use a paste service
<zozozo>
though, in general, the equivalent of a "for each" would be to use an `iter` or `fold` function (or a for/while loop for integers)
zebrag has joined #ocaml
berberman_ has joined #ocaml
berberman has quit [Ping timeout: 272 seconds]
Tuplanolla has joined #ocaml
wonko has joined #ocaml
<d_bot>
<NULL> Let me tell what I understood of value restriction and please tell me if I'm wrong :
<d_bot>
<NULL> - Value restriction must be done exactly at function applications and mutable fields typing (+ internal mutable types like arrays)
<d_bot>
<NULL> - Relaxed value restriction then generalises type variables that only have covariant positions in the considered type [expression]
<d_bot>
<NULL> + On this note, the documentation seems to indicate that relaxed value restriction and relaxation for covariant type parameters are different, but I couldn't find any difference
<d_bot>
<NULL> - The compiler does one typing pass and at the end weakens all type variables if it found a function application or a record-with-mutable-field definition (or array, etc.) and the type variable is not only at covariant positions
<d_bot>
<NULL> - It is possible (and sound) to weaken type variables only *at* the function applications and record-with-mutable-field definitions (and arrays, etc.), but less simple and thus more time consuming on compilation
<d_bot>
<NULL> - Only weakening type variables at the dangerous places would make my `let unhidden_id = (hidden_id ()).id` type polymorphic
mro_ has quit [Remote host closed the connection]
Haudegen has joined #ocaml
favonia has joined #ocaml
<d_bot>
<flodin> q
<d_bot>
<flodin> q
<d_bot>
<flodin> åwdq¨ö
favonia has quit [Ping timeout: 272 seconds]
favonia has joined #ocaml
<d_bot>
<Drup> I just want to comment that you are assuming the wrong direction: The compiler starts with variables that are not generalized and then ask itself "Can I generalize this variable". Generalization can be done at any point, but it's slightly more convenient to do it at let-bindings only (and you don't loose anything). Weak type variables are the variables that were not generalized.
<d_bot>
<Drup> The main question is: which type variables can we generalize, and this is where (relaxed) value restriction comes in.
<d_bot>
<Drup> It is not possible to only look at function applications *in the ocaml type system*, it would requires additional tools, such as effects. It is not a question of being "time consuming at compilation"
mro has joined #ocaml
<bnrroy>
@zozozo thanks, I will try with iter.
TheLemonMan has joined #ocaml
mro has quit [Ping timeout: 245 seconds]
mro has joined #ocaml
waleee has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
<bnrroy>
What is the equivalent of "case-switch" in OCaml?
<d_bot>
<NULL> `match e with | Constructor1 -> result1 | Constructor2 (arg1, Constructor1 as arg2) -> result2`
<d_bot>
<NULL> Whoops, forgot to remove the "answer"
<d_bot>
<NULL> This direction does break how I envisioned it. The question is then why do it this way : having general variables by default would allow for `(ref None, Fun.id)`, but I imagine there are good reasons not to do it this way.
<d_bot>
<NULL> I don't understand what you mean in the first part here
<zozozo>
bnrroy: you'll need to define a type to represent a "rule"
mro has quit [Remote host closed the connection]
mro has joined #ocaml
rks`_ has joined #ocaml
p4bl01 has joined #ocaml
wagle has joined #ocaml
mro has quit [Ping timeout: 272 seconds]
rks` has quit [Killed (iridium.libera.chat (Nickname regained by services))]
rks`_ is now known as rks`
dh` has quit [*.net *.split]
wagle_ has quit [*.net *.split]
Johann has quit [*.net *.split]
dy has quit [*.net *.split]
p4bl0 has quit [*.net *.split]
ccx has quit [*.net *.split]
dy has joined #ocaml
bnrroy has quit [Quit: Client closed]
mro has joined #ocaml
Johann has joined #ocaml
waleee has quit [Ping timeout: 264 seconds]
waleee has joined #ocaml
ccx has joined #ocaml
foo303 has joined #ocaml
wonko has quit [Remote host closed the connection]
lobo has quit [Ping timeout: 250 seconds]
lobo has joined #ocaml
favonia has quit [Ping timeout: 272 seconds]
favonia has joined #ocaml
mbuf has quit [Read error: Connection reset by peer]
<d_bot>
<Drup> except that generalizing anything that contains `ref None` (except inside a function) is unsound, regardless of how you look at it
olle has quit [Ping timeout: 244 seconds]
mbuf has joined #ocaml
tizoc` has joined #ocaml
tizoc` is now known as tizoc_
Enjolras_ has joined #ocaml
Leonidas has joined #ocaml
reynir1 has joined #ocaml
Leonidas is now known as Guest7422
pieguy128_ has joined #ocaml
dy` has joined #ocaml
Tuplanolla has quit [*.net *.split]
ccx has quit [*.net *.split]
dy has quit [*.net *.split]
dhil has quit [*.net *.split]
motherfs1 has quit [*.net *.split]
pieguy128 has quit [*.net *.split]
reynir has quit [*.net *.split]
Leonidas_ has quit [*.net *.split]
Enjolras has quit [*.net *.split]
tizoc has quit [*.net *.split]
<d_bot>
<NULL> There's nothing against generalising the type variables of `Fun.id` in the couple, is there ? `ref None` is next to it, but won't change anything
ccx has joined #ocaml
motherfs1 has joined #ocaml
<zozozo>
@NULL : how do you distinguish the `ref None` from the `Fun.id` ?
Tuplanolla has joined #ocaml
dhil has joined #ocaml
<zozozo>
i.e. how would the typechecker decide to generalize one and not the other ?
waleee has quit [Quit: WeeChat 3.1]
<d_bot>
<NULL> The question is first theoretical. A possible algorithm (using generalised types by default, so maybe not applicable) could be to type `None` as `'a option`, then `ref None` as `'_weak1 option ref` with value restriction, then `Fun.id` as `'b -> 'b` (no need for value restriction, there is no application in this part) and finally `(ref None, Fun.id)` as `'_weak1 option ref * ('b -> 'b)`
mro has quit [Remote host closed the connection]
<d_bot>
<Drup> Ah, I see what you are getting at
<d_bot>
<Drup> so, we would indeed generalize more often, in this case before creating the tuple
<d_bot>
<Drup> we only generalize at let-binding here, because it's mostly simpler
<d_bot>
<Drup> The other reason is that ... well, you could just let-bind, really. 🙂
<d_bot>
<NULL> As of now this is the only time where splitting a let-bind in two is required I encountered
<d_bot>
<Drup> Yes, it's specific to generalization
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
brn has joined #ocaml
<brn>
Hi, I need to write this algo in OCaml :for every rule R with a consequent that matches H do
<brn>
if for all antecedents A of rule R, we have Backward-Chaining(A) = true then
<brn>
return true
<brn>
Could someone give me a hit?
<brn>
hint*
olle_ has joined #ocaml
brn has quit [Quit: Client closed]
Guest47 has joined #ocaml
waleee has joined #ocaml
olle_ has quit [Ping timeout: 252 seconds]
Guest47 has quit [Quit: Client closed]
<d_bot>
<froyo> @octachron regarding that last ann here on discord, will 4.13's second alpha get the multicore runtime? or rather another internal staging change??
<d_bot>
<octachron> It is more another internal change. That should be visible on vanilla OCaml in fact.
<d_bot>
<octachron> Note that it is also the only multicore-improvement in 4.13 because there is very fews items left in the list of required features before switching to multicore.
<d_bot>
<froyo> safepoints, right?
<d_bot>
<froyo> that seems to be the "big pr" from what ive seen
<d_bot>
<octachron> Yes, this is safepoint, which is required for multicore, since safe polling matters more here.
<d_bot>
<octachron> Whereas, with current OCaml, there are few edge cases where you program might be not interruptible in a loop that never allocates. But the intersection of program that needs to interrupted and not-allocating programs wasn't meaningful enough to increase the code size of other programs for their sake.
<d_bot>
<mimoo> is there an existing effort to rewrite ocaml's runtime (written in C) in rust?
<companion_cube>
nope
<d_bot>
<froyo> lol full circle eh?
<companion_cube>
I like rust, but it's not going to help make the GC safer
<d_bot>
<Deadrat> But it would widen the contributor pool? Also it would probably simplify a bunch of code
<d_bot>
<Deadrat> But I'm not sure
<companion_cube>
:D
<companion_cube>
the contributor pool of the runtime?
<companion_cube>
afaict, the runtime's code would be almost 100% unsafe rust
<companion_cube>
and would introduce a dependency on LLVM
<d_bot>
<Deadrat> But my RIIR
<Corbin>
(If there *is* an efficient safe GC monad, then somebody should write a paper about it. Many of us would love to see safer GCs.)
<companion_cube>
you'll be faster arrived by formally proving a GC and extracting C from the proof
<companion_cube>
imho
<companion_cube>
and that's godamn slow :p
<Armael>
(you don't need to extract C from a proof, you can prove a C program correct)
<Corbin>
Aren't the biggest speed considerations also unsafe in C? e.g. the stack manipulation and searching registers for roots?
<companion_cube>
I meant as in rust's "unsafe"
<Corbin>
Ah, sure. I'm just thinking that C's not ideal either. It's too bad that it takes more than a page of assembly to write a GC; there ought to be a better intermediate language.
<companion_cube>
are you u/corbin? :p
<d_bot>
<froyo> you probably can subst asm for c, just not very portable c
<companion_cube>
zozozo: could the GC be written in one of the compiler's IRs? :p
<dmbaturin>
The C parts are relatively isolated and it's not really a bad C either.
<dmbaturin>
It also makes OCaml buildable on many platforms, including those not supported by Rust.
<d_bot>
<froyo> ^
<d_bot>
<froyo> i was pleasantly surprised to find a plan9 port of ocaml
<d_bot>
<froyo> 4.07 but hey
<d_bot>
<froyo> probably just needs someone familiar with how the compiler builds to pull it up to newer vnum
<dmbaturin>
I love the fact that z/Arch is a supported platform even though I don't own a mainframe yet. ;)
<Corbin>
companion_cube: Curses, you've seen through my clever disguise! I used to have /nick simpson on Freenode.
<dmbaturin>
(Hercules works very well though, if you want to emulate one)
<companion_cube>
:D
<d_bot>
<froyo> o ik, write the runtime in Forth
<d_bot>
<froyo> :P
<dmbaturin>
By the way, is anyone using to.ml? What are the things you hate about it most?
<companion_cube>
the API changes over the years
<dmbaturin>
I'm working on a replacement.
<companion_cube>
nice
<companion_cube>
nto that I use toml anymore
<companion_cube>
sexp all the way!
<dmbaturin>
So far it's a wrapper for to.ml that I made to live with the API a bit and try the designs: https://github.com/dmbaturin/soupault/blob/master/src/otoml.ml Next step is a parser, using Menhir's .messages for proper parse error reporting.
<dmbaturin>
The reason for having e.g. TomlInlineTable is to make "read |> parse |> print" more idempotent and give the user more control on the way their TOML documents are displayed.
<dmbaturin>
Also, date/time stuff is going to be pluggable via functors, with default just returning them as strings after checking the format. It's not good to force a specific calendar library on the user.
<zozozo>
companion_cube: I doubt it
<zozozo>
and I think that even if it would be, it'd be insanely hard to read and understand
<zozozo>
for instance, this is already done for some object-related methods in the cmm translation