<flux>
I remember reading its announcement quite some time ago, but it seems quite complete - perhaps a bit too complete (witness the reasons behind creating camlish), but can provide type safety too
<palomer>
heehee
<palomer>
nice
Andman1 has joined #ocaml
Andman1 is now known as Manjor117
Manjor117 is now known as Major117
Major117 is now known as Agent47
Agent47 is now known as YopAndman
YopAndman has left #ocaml []
SirNick has joined #ocaml
mjambon has joined #ocaml
itewsh has joined #ocaml
ttamttam has joined #ocaml
ttamttam has left #ocaml []
_andre has quit ["leaving"]
rwmjones has quit [Read error: 113 (No route to host)]
Ariens_Hyperion has joined #ocaml
Camarade_Tux has joined #ocaml
rwmjones has joined #ocaml
_zack has quit ["Leaving."]
jeddhaberstro has joined #ocaml
slash_ has joined #ocaml
itewsh has quit ["There are only 10 kinds of people: those who understand binary and those who don't"]
Ariens_Hyperion has quit []
<Alpounet>
when playing with polymorphic variants
<Alpounet>
to get [ `A of x | `B of y ], without > or <, we're obliged to give types explicitly right ?
Jedai has quit [Read error: 113 (No route to host)]
<mrvn>
depends
<mrvn>
> hmm, or not. damn. I though type inference could produce [ `A ... ] types.
zbrown has left #ocaml []
seafood has joined #ocaml
seafood has quit [Read error: 60 (Operation timed out)]
sOpen has joined #ocaml
<sOpen>
Hi, I have a program in which I am right now passing around a state record. I want to modify more than a single field on gets and sets (some fields are dynamic). What's the Right Way to do this? Use an object? A module? Functions over a record?
<mrvn>
yes
<mrvn>
object is probaly easiest
<sOpen>
mrvn, is there any facility for getters and setters? do i need to write all of them?
<sOpen>
mrvn, ah! thank you. I understand how to do what i want now. :-)
<Alpounet>
mrvn, I've tried.
<sOpen>
is there some fundamental difficulty in implementing records? Why do both OCaml and Erlang leak field names?
seafood has joined #ocaml
<mrvn>
fields of a record are like any other binding.
<sOpen>
mrvn, why? field names aren't used naked, are they? isn't there always a syntactic distinction between field names and other bindings?
<sOpen>
seems like unnecessary namespace pollution?
<mrvn>
sOpen: x.field makes it infere that x is a record of the type that contains field.
<mrvn>
sOpen: how else do you want to detect the type of x?
<sOpen>
ah, that would be a good reason
<sOpen>
mrvn, why can't a similar trick to objects be done? the type of x is not a record but a record-pattern
<mrvn>
sOpen: s#method has the same problem as x.field
<hcarty>
sOpen: Object methods have a potential run-time penalty associated with them when compared with records
<mrvn>
ok, not totally. methods are like hash variants.
<monadic_kid>
there are other alternatives to dealing with your state but they aren't easy to grok, in particular functional reactive programming
<sOpen>
hcarty, ok... this should be a type checking, static thing, thlugh
<sOpen>
monadic_kid, frp isn't right for this... I'm building undo trees
<hcarty>
Method lookup is looked up at run-time, since < field : t ... > is an "acceptable" (correct terminology?) type in OCaml, while { field : t ... } is not
<hcarty>
s/looked up/performed/
<hcarty>
With records everything is determined statically at compile time
<mrvn>
< field : t ... > is like `Field of t
<sOpen>
monadic_kid, I did see http://code.google.com/p/froc/ though... based on FrTime. What ocaml frp system do you like?
<monadic_kid>
I haven't used any yet, i'm still trying to grok it myself ;)
rwmjones has quit [Read error: 104 (Connection reset by peer)]
<hcarty>
The OSP 2007 FrGui and underlying library structure seems nice, though perhaps not complete
<mrvn>
hcarty: In C++ method lookup is static. I miss that in ocaml.
<mrvn>
+possibly
<sOpen>
mrvn, I don't understand hash variants, yet. I guess I don't see why { field : t .. } couldn't be a type?
<hcarty>
mrvn: I haven't spent much time in C++ recently, thanks to OCaml...
<mrvn>
sOpen: it could.
<sOpen>
mrvn, so... wouldn't that hoist field names into the type system?
<mrvn>
sOpen: But { field : t .. } and { x : int; field : t; ..} would not be compatible. With objects they are.
<sOpen>
mrvn, why wouldn't they be compatible? I can pass the second where the first is expected but not vice versa.
<mrvn>
sOpen: Because record fields are compile time static offsets.
<mrvn>
sOpen: And the first has offset 0 and the second offset 1
<sOpen>
mrvn, aha! the sense is making now
<sOpen>
now the dynamic method dispatch comment makes sense :-)
<mrvn>
Hash variants and object methods have a lookup table using (hash "name")
<mrvn>
So the offset doesn't matter, the hash is always the same no matter the position
slash_ has quit [Client Quit]
willb has quit [Read error: 110 (Connection timed out)]
<sOpen>
mrvn, hmm... i will need to read more to understand what this entails. At what levels are record field names contained? module? file?
<hcarty>
sOpen: Module
<sOpen>
hcarty, they are bound to the module, though, right? not forced private? If you open the module, they spill out?
<hcarty>
sOpen: Yes, that is correct
<sOpen>
hcarty, ok, cool. thanks :-)
<hcarty>
module Foo = struct type t = { x : int; y : int } end let it = { Foo.x = 1; y = 1 } ... open Foo let it2 = {x = 1; y = 1}
Yoric[DT] has quit ["Ex-Chat"]
<hcarty>
sOpen: It can get odd if you nest a lot of modules and end up with types where have to type things like "it.Foo.bar.Baz.x"
Camarade_Tux has quit ["Quitte"]
monadic_kid has quit ["Leaving"]
<Alpounet>
may I bring mlbot ?
<Alpounet>
:-p
<hcarty>
Alpounet: Certainly!
<hcarty>
I think the lack of continuous presence is a large part of what hindered the use of xavierbot
mlbot has joined #ocaml
<Alpounet>
here he is
<Alpounet>
I'll find a place to put mlbot permanently
<Alpounet>
but later
<sOpen>
mlbot, hello
<hcarty>
Alpounet: Yes, I imagine that would take a bit of preparation
<hcarty>
> module Foo = struct type t = { x : int; y : int } end let it = { Foo.x = 1; y = 1 };;
<mlbot>
module Foo : sig type t = { x : int; y : int; } end
<mlbot>
val it : Foo.t = {Foo.x = 1; Foo.y = 1}
<hcarty>
> it.x;;
<mlbot>
Type Error
<hcarty>
> it.Foo.x;;
<mlbot>
- : int = 1
<hcarty>
> open Foo it.x;;
<mlbot>
Use of ``open'' forbidden
<Alpounet>
hcarty, indeed. I have to give him most of OCaml compiler's .cmo, compiled with the same compiler than mlbot...
<Alpounet>
> let f = function | `A -> 0 | `B -> 1 ;;
<mlbot>
val f : [< `A | `B ] -> int = <fun>
mjambon has left #ocaml []
<Alpounet>
> let f2 ( x : [`A | `B] ) = match x with `A -> 0 | `B -> 1 ;;
<mlbot>
val f2 : [ `A | `B ] -> int = <fun>
<Alpounet>
mrvn, it seems we must do it this way
<Alpounet>
(of course, with module interfaces, it is much more practical and readable, as we separate signatures & implementation)
<Alpounet>
> f2 `B ;;
<mlbot>
- : int = 1
<Alpounet>
> f2 `C ;;
<mlbot>
Type Error
<Alpounet>
> f `C ;;
<mlbot>
Type Error
nimred has quit [hubbard.freenode.net irc.freenode.net]
lanaer has quit [hubbard.freenode.net irc.freenode.net]
Ori_B has quit [hubbard.freenode.net irc.freenode.net]
jlouis has quit [hubbard.freenode.net irc.freenode.net]
noj has quit [hubbard.freenode.net irc.freenode.net]
r0bby has quit [hubbard.freenode.net irc.freenode.net]
noj has joined #ocaml
nimred has joined #ocaml
lanaer has joined #ocaml
Ori_B has joined #ocaml
jlouis has joined #ocaml
<Alpounet>
oh, I didn't knew about the following.
r0bby has joined #ocaml
<Alpounet>
> type variant = [ `A of int | `B of bool ] ;;
<mlbot>
type variant = [ `A of int | `B of bool ]
<Alpounet>
> let f = function | #variant -> "variant" | _ -> "other" ;;