<ollehar2>
"How to split a big pattern match into multiple modules?"
<ollehar2>
Sad.
<ollehar2>
This is important for me: "add new modules without touching old code"
<Drup>
how perf-sensitive is the pattern matching in question ?
<ollehar2>
performance? totally irrelevant
<Drup>
Then it's trivial
<ollehar2>
Aha?
<Drup>
you write a function Xml.t -> thingy option in each module
<Drup>
you collect them somewhere
<Drup>
and you try each one by one.
<ollehar2>
collect the modules?
<Drup>
the functions
<Drup>
you make a list somewhere
<Drup>
(where you need to call it, typically)
<ollehar2>
Collect the functions from the modules in a list, without the modules?
<ollehar2>
As with function alias?
<octachron>
If the dispatch is regular enough, you can also have a map Xml.t -> canonical_key and a (canonical_key, Xml.t -> thingy) map
<Drup>
that's for efficiency though
<ollehar2>
hm
<Drup>
ollehar2: let l = [Mod1.f; Mod2.f; Mod3.f]
<ollehar2>
oooooh
<ollehar2>
Do I need a module signature, like CAN_PARSE_XML?
<Drup>
and you try each one, in order.
<ollehar2>
sure
<Drup>
not really
<Drup>
all the functions must have the same signature
<ollehar2>
OK, function type is enough, then?
<ollehar2>
yes
<ollehar2>
nice
<ollehar2>
If you write on stackoverflow I can accept it, otherwise I'll write the answer.
<Drup>
it's "poor man's modular patter match" :)
<ollehar2>
ha
<ollehar2>
!
<ollehar2>
yeah
<ollehar2>
weird no one answered this :d
<Drup>
(name by me)
<Drup>
but it's a classical technique
<Drup>
it's most often use for modular error handling, in the compiler in particular
<Drup>
I'm too lazy to write the SO answer, feel free to do it (with attribution :D)
hlisp has joined #ocaml
hlisp has quit [Remote host closed the connection]
<ollehar2>
yep yep
jbrown has quit [Quit: Leaving]
<ollehar2>
There's no "reflection" thingy in OCaml, which would make it possible to dynamically include modules in the function list which has a specific signature or interface?
<ollehar2>
A module can have any number of signatures, right?
<companion_cube>
first class modules? it's not dynamic, but you can manipulate different modules according to a common interface
<ollehar2>
Not exactly the same thing, no.
<Drup>
No, there is no reflection thingy
<companion_cube>
alas
<ollehar2>
D:
<Drup>
given the state of Java, that's a good thing
<ollehar2>
hehe
<ollehar2>
Obj.magic?
<ollehar2>
Read all linked modules?
<companion_cube>
well I'd love a `'a ty`
<companion_cube>
I can only see upsides
<Drup>
companion_cube: that is not at all what he is asking for, and that's barely reflection, just type of
<companion_cube>
yep but that'd be sweet
<Drup>
ollehar2: if you really don't want to make a list ... `let l = ref [] let registed x = l := x :: !l`
<Drup>
register*
<Drup>
Don't try to emulate Java insanity in OCaml, it doesn't work.
<ollehar2>
Hey, I happen to be a PHP developer :D
<Drup>
I'll try not to hold it against you
<ollehar2>
;)
<ollehar2>
So, how do I do a variable variable in OCaml?
<Drup>
You should try to elevate yourself further though :)
<ollehar2>
(Joke)
<simpson>
Would MetaOCaml offer better tools for reflection? Or do they only offer staged programming?
<Drup>
simpson: so, it sort of does ... but you still can't really "get all the modules linked and inspect their module types"
<Drup>
Oleg likes to use canonical structures to emulate that, but ... let's say it's a Coq version of reflection :D
<ollehar2>
get_declared_classes
<ollehar2>
:)
<ollehar2>
What about a ppx thingy that injects module name into list when loaded?
<Drup>
ollehar2: what's wrong with a register function ? :|
<ollehar2>
Or actually, I already did something similar years ago, with multiple entry points
<companion_cube>
too much magic
<ollehar2>
@drup yes, that
<ollehar2>
register function = let _ ... in each module?
<Drup>
yes.
<companion_cube>
low tech solution ftw
<Drup>
exactly
<ollehar2>
yes, I did this in my hacked "MVC" framework many years ago
<ollehar2>
when you guys tought me OCaml the first time :D
<ollehar2>
I'd say 2012
<simpson>
Drup, ollehar2: Sure. FWIW this sort of enumerate-the-ambient-process ability is usually too powerful. In Java, for example, this ability makes class loaders fundamentally unsafe: They aren't restrained in what they can do.
<simpson>
So it's not surprising that otherwise-powerful metaprogramming systems might have what appears to be a blind spot but is actually a careful design decision.
<ollehar2>
Safe? I'm a PHP dev, I don't care about "safe".
<ollehar2>
$className = 'blubb"; $blubb = new $className;
<Leonidas>
if you ever thought "hey, it would be cool to do different things depending on whether the return value will be looked into"
<ollehar2>
I guess the commit message for that feature contains a use-case rational? Who knows.
<ollehar2>
Btw, they might add the pipe operator to PHP, like |>
<ollehar2>
Register function together with @@deriving sexp_of for complete introspection?
<simpson>
At some point, surely it's easier to take a staged approach and pass around code objects. I don't know where that point is, though.
<ollehar2>
hm
<ollehar2>
Wouldn't it be nice to be able to say, "OCaml can do everything PHP can"?
<simpson>
Not really; indeed, I work on a project that works to *remove* capabilities from typical user-level code, and PHP is so untamed as to be unapproachable for that work. http://habitatchronicles.com/2017/05/what-are-capabilities/ will help explain, but you should finish the Confused Deputy story first.
<ollehar2>
Just use docker?
<ollehar2>
It's the new standard answer after last decades "Just use jQuery"
<simpson>
Close; microservices are like objects, sure, but containerization is not isolation.
<simpson>
Similarly, class loaders ought not to allow enumerating code objects in a process.
<dash>
I like ocaml because of its inabilities
<dash>
not just its abilities
Niamkik has quit [Ping timeout: 260 seconds]
ollehar2 has quit [Quit: Connection closed]
Niamkik has joined #ocaml
TheLemonMan has joined #ocaml
<companion_cube>
not having a universal print is a bit tired, tho
Haudegen has quit [Quit: Bin weg.]
zolk3ri has joined #ocaml
<simpson>
Yeah. Especially for data types, where one would hope that there are nice human-readable ways to represent values.
<companion_cube>
for all the woes of reflection (or RTTI or whatever), at least it provides an answer to that
<simpson>
Yes. And if it's not present, then usually cheating is required. My preferred day-to-day language requires types to explicitly provide instances for overriding the automatic universal-value-printing machinery, or otherwise you get something boring like "<myCoolObject>".
<companion_cube>
what would that language be?
<simpson>
I'm thinking of Monte, but I used to work mainly in Python, which has the same issue and ergonomics.
<companion_cube>
ugh :s
<companion_cube>
(sorry)
<simpson>
py`class Whatever(object): def __repr__(self): ...` or m`object whatever { to _printOn(out) { ... } }`
<simpson>
(Happens. I only work on Monte because I want an alternative to Python 3, and I think there ought to be a modern flavor of E.)
<companion_cube>
nim does it well, I think
<companion_cube>
you have `repr x` which is a universal printing function
<companion_cube>
and you can overload `$` to print stuff as you want
<simpson>
I've recently been examining Cello, a library for C which is basically its own dialect, and they have figured out a very cool polymorphic technique kind of like type classes: http://libcello.org/learn/show
ygrek has quit [Ping timeout: 246 seconds]
<companion_cube>
I'd never use that I think :D
<companion_cube>
a DSL on top of Cā¦ š±
<companion_cube>
is monty untyped?
ygrek has joined #ocaml
<simpson>
Probably. It depends on who you ask and which tribe they're from. I know a POV that thinks that Monte is dependently typed, as well as a POV that thinks that all Turing-complete languages are untyped.
<simpson>
m`def x := 42` is legal, but so is m`def x :(Int > 2) := 42`. If one thinks that types are about type theories, then this is untyped; if it's about type systems, then this is dependently typed.
<companion_cube>
I'm having a hard time to follow, to me dependent types are a type theory
<simpson>
Sorry, maybe that's a bit big of a link for one bite. The essential idea is that turning code objects into values *of a given type* is a partial operation. The types themselves are like values. And so what appears to be a rich, even dependently-typed system from *within* those values, is actually from the outside a single object (the Turing object) and a single arrow (the Kleene application).
<companion_cube>
yeah I think I don't want to know :D
Haudegen has joined #ocaml
zolk3ri has quit [Remote host closed the connection]
<simpson>
No worries. Category theory isn't always the solution. In fact, it's probably usually not the solution.
sagax has joined #ocaml
dborisog has quit [Ping timeout: 244 seconds]
wingsorc has joined #ocaml
sugarwren has joined #ocaml
sz0 has quit [Quit: Connection closed for inactivity]
ggole has quit [Quit: Leaving]
ollehar2 has joined #ocaml
sugarwren has quit [Ping timeout: 272 seconds]
<ollehar2>
A depends on B, and B depends on A, where A and B are modules
<ollehar2>
Can I just make them depend on SIG instead of the implementation?
<ollehar2>
Hm, that's what mli files are for, I guess.
c4rc4s has quit [Quit: Adios]
c4rc4s has joined #ocaml
muskan has joined #ocaml
ollehar2 has quit [Quit: Connection closed]
narimiran has quit [Ping timeout: 260 seconds]
TC01 has quit [*.net *.split]
pippijn has quit [*.net *.split]
robi has quit [*.net *.split]
ahf has quit [*.net *.split]
tmhoang has quit [*.net *.split]
hannes has quit [*.net *.split]
cross has quit [*.net *.split]
asm89 has quit [*.net *.split]
hannes has joined #ocaml
pippijn has joined #ocaml
rowbee has joined #ocaml
cross has joined #ocaml
asm89 has joined #ocaml
asm89 has quit [Changing host]
asm89 has joined #ocaml
TC01 has joined #ocaml
ahf has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
Haudegen has joined #ocaml
Hrundi_V_Bakshi has joined #ocaml
Jesin has quit [Quit: Leaving]
ollehar2 has joined #ocaml
TheLemonMan has quit [Remote host closed the connection]
Jesin has joined #ocaml
ollehar2 has quit [Quit: Connection closed]
averell has quit [Quit: .]
averell has joined #ocaml
muskan has quit [Ping timeout: 245 seconds]
tane has quit [Quit: Leaving]
jao has quit [Remote host closed the connection]
ygrek has quit [Ping timeout: 256 seconds]
jao has joined #ocaml
hlisp has joined #ocaml
Hrundi_V_Bakshi has quit [Ping timeout: 256 seconds]