szkl has quit [Quit: Connection closed for inactivity]
Groumf has quit [Ping timeout: 250 seconds]
trev has joined #ocaml
azimut has quit [Remote host closed the connection]
azimut has joined #ocaml
azimut has quit [Remote host closed the connection]
azimut has joined #ocaml
bartholin has joined #ocaml
<discocaml>
<froyo> hey what's a cross-platform way to get cwd's root?
<discocaml>
<froyo> in other words: `/a/b/c` -> `/`, `C:\a\b\c` -> `C:\`
Serpent7776 has joined #ocaml
<discocaml>
<froyo> I know I can just handle those two cases, but I'm hoping for something cross-platform like the things you find in `Filename` module
<discocaml>
<froyo> er, `String.sub` not `Str.sub`
infinity0 has quit [Remote host closed the connection]
infinity0 has joined #ocaml
<discocaml>
<JM> I usually use fpath (https://erratique.ch/software/fpath) to manipulate file names/directories. (but it probably does something similar to what you've written already)
<discocaml>
<JM> Do not use the following reserved names for the name of a file:
<discocaml>
<JM>
<discocaml>
<JM> CON, PRN, AUX, NUL, COM0, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, COM¹, COM², COM³, LPT0, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9, LPT¹, LPT², and LPT³. Also avoid these names followed immediately by an extension; for example, NUL.txt and NUL.tar.gz are both equivalent to NUL. For more information, see Namespaces.
<discocaml>
<JM> ```
<greenbagels>
Gotta love windows
<greenbagels>
Apparently they are holdovers from DOS
ridcully_ has joined #ocaml
ridcully has quit [Ping timeout: 255 seconds]
<greenbagels>
does hte ocaml compiler itself use ocamllex and ocamlyacc, or is it hand-written instead? (or some mixture of the two, like gcc used to be)
fweht has joined #ocaml
<octachron>
the compiler use: ocamllex + menhir
<octachron>
which is one the motivation for improving menhir error message writings to get rid of the `Syntax error _` error messages
<greenbagels>
octachron: did it used to use ocamlyacc rather than menhir? i do see that menhir is generally recommended as what people should use for new projects
<octachron>
The compiler switched to menhir in 4.08
<greenbagels>
also unrelated, but https://v2.ocaml.org/manual/tail_mod_cons.html mentions that an implementation of List.map using a recursive aux function "is tail-recursive, but it is measurably slower than the simple, non-tail-recursive version. "
<greenbagels>
how slower is "measurably slower"?
raphaal has joined #ocaml
<raphaal>
hi all
dnh has joined #ocaml
ritog has joined #ocaml
wingsorc has quit [Ping timeout: 256 seconds]
ritog has quit [Quit: Leaving]
waleee has joined #ocaml
<discocaml>
<hockletock> @greenbagels semgrep apparently tested switching to a Ls module with tail recursive functions pre-TRMC and one of their benchmarks got 34% slower https://github.com/semgrep/semgrep/pull/3555
<discocaml>
<hockletock> that replaced all the List.* functions with tail recursive versions and most of their benchmarks were not significantly impaired.
fweht has quit [Quit: Connection closed for inactivity]
boozec has joined #ocaml
dnh has joined #ocaml
<greenbagels>
Interesting
<greenbagels>
I wouldn't have expected that
Inline has quit [Ping timeout: 255 seconds]
dnh has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<discocaml>
<hockletock> how to get to the benchmark data from those PRs?
<companion_cube>
hmm you'd have to run it locally…
edr has joined #ocaml
dnh has joined #ocaml
<discocaml>
<wravoc> Moving/continuing my comments in general about stdlib and string manipulation.
<discocaml>
<wravoc>
<discocaml>
<wravoc> I did see the ocaml-re which
<discocaml>
<wravoc> > missing features are back-references and look-ahead/look-behind assertions
<discocaml>
<wravoc>
<discocaml>
<wravoc> Which was in PERL in like 1986. I hope this paltry situation improves, OCaml is such a beautiful language.
<companion_cube>
you can use pcre/pcre2 no?
<discocaml>
<._null._> If you want to do powerful parsing, you should look into parser generators and parser combinators, regexp are only for the class of regular languages, which is not that large
<companion_cube>
`re` does regex differently (possibly more efficiently in a sense, there's no backtracking)
<discocaml>
<hockletock> "PCRE" are regexp in name only
<discocaml>
<wravoc> Interestingly, Nim also decided to skirt around like and just use C PCRE calls. I was just hoping for first xclass support for a first class language.
<discocaml>
<octachron> I don't really see the appeal of regexp expansions when either parser combinators or menhirs are much more readable for parsing generic formats?
<discocaml>
<wravoc> Interestingly, Nim also decided to skirt around like and just use C PCRE calls. I was just hoping for first class support for a first class language.
<discocaml>
<._null._> I strongly agree
<discocaml>
<leviroth> One use case is for letting your user specify a regex
<discocaml>
<leviroth> Easy for them to enter an arbitrary string of whatever regex syntax you support, hard for them to write some ocaml which you then compile
<discocaml>
<._null._> Fine for regexes, but why try to expand it
<companion_cube>
I mean just use pcre bindings if you want the full perl "regex"
<discocaml>
<hockletock> I don't see how using the PCRE library is "skirting around" anything, having anything but full compatibility with an existing implementation would be in some ways worse than useless
<companion_cube>
why would anyone want to reimplement pcre, anyway
<companion_cube>
that sounds horrible :D
dnh has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<discocaml>
<wravoc> To reply in bulk to some of these comments, but isn't that why Python is so popular? Because it has almost all string manipulation built-in, easy to use, and well documented?
<discocaml>
<._null._> I really doubt Python is popular for string manipulation
<discocaml>
<wravoc> Huh
<companion_cube>
that'd be perl
gentauro has quit [Read error: Connection reset by peer]
<companion_cube>
seems like `re` in python has all that though
<greenbagels>
handling strings in python is pretty comfy fwiw
<companion_cube>
for sure
<companion_cube>
@wravoc maybe OCaml isn't exactly aiming at being a good scripting language, you know?
gentauro has joined #ocaml
Serpent7776 has quit [Ping timeout: 252 seconds]
neiluj has joined #ocaml
oisota9 has joined #ocaml
xd1le_ has joined #ocaml
caasih_ has joined #ocaml
delyan__ has joined #ocaml
<discocaml>
<wravoc> I think the primary use for OCaml is well understood. However, because scripting languages are good/focused at string manipulation does not mean high level languages are *not* good at them. In fact, they are mostly good at them and many successful ones provide comprehensive string manipulation, Scala and Erlang for example.
farn_ has joined #ocaml
rwmjones_ has joined #ocaml
xd1le has quit [Ping timeout: 252 seconds]
rwmjones has quit [Ping timeout: 252 seconds]
farn has quit [Ping timeout: 252 seconds]
delyan_ has quit [Ping timeout: 252 seconds]
caasih has quit [Ping timeout: 252 seconds]
edr has quit [Ping timeout: 252 seconds]
infinity0 has quit [Ping timeout: 252 seconds]
process0 has quit [Ping timeout: 252 seconds]
ski has quit [Ping timeout: 252 seconds]
nore has quit [Ping timeout: 252 seconds]
oisota has quit [Ping timeout: 252 seconds]
dhil has quit [Ping timeout: 252 seconds]
patrick__ is now known as patrick
caasih_ is now known as caasih
delyan__ is now known as delyan_
oisota9 is now known as oisota
ski has joined #ocaml
process0 has joined #ocaml
dhil has joined #ocaml
<companion_cube>
(erlang?? really?)
<companion_cube>
I imagine Scala re-exposes some sort of JVM regex library, that's probably quite nice
infinity0 has joined #ocaml
<greenbagels>
so i'm trying to use this year's advent of code to learn a bit about project and organization, since it naturally will lead to some 25 modules, one for each day
<greenbagels>
if my goal is just to have a unified interface for each day (only two functions exposed: day1 : string -> unit and day2 : string -> unit); what would be a good way to handle that? surely not 25 .mli files all containing the same interface?
rito has quit [Quit: Leaving]
<greenbagels>
part1 and part2, nto day1 and day2*
ritog has joined #ocaml
<octachron>
I generally have a submodule `Part_1` and `Part_2` whenever my implementation in Part_1 cannot be translated to `Part_2`.
rito has joined #ocaml
<octachron>
Not sure, if it is really useful to fix the interface for each day.
rito has quit [Remote host closed the connection]
ritog has quit [Client Quit]
nore has joined #ocaml
<greenbagels>
it was less about utility and more about seeing if the concept was doable
<greenbagels>
I guess in practice if you want multiple modules with the same interface you'd use functors to parameterize a module on another module or something?
<greenbagels>
mostly i had testing in mind, my thought was if the modules have the same interface, then writing a test harness would be easy, but i do not know that
<discocaml>
<wravoc> Yup, Erlang has full Unicode, multi-encoding support, and regular expressions with look ahead/behind assertions, built-in.
<octachron>
greenbagels, you would define a module type and include this module type.
<octachron>
not that surprisingly, a good and modern "regexp" engine is not something that you want to do in house as a compiler developper's side project
<companion_cube>
OCaml could honestly provide a few more things out of the box, but well
<discocaml>
<wravoc> Yeah, from that Erlang link:
<discocaml>
<wravoc> > The matching algorithms of the library are based on the PCRE library, but not all of the PCRE library is interfaced and some parts of the library go beyond what PCRE offers.
<companion_cube>
(e.g. pcre instead of `str` 😂)
<discocaml>
<wravoc> Yeah, from that Erlang link:
<discocaml>
<wravoc> > The matching algorithms of the library *are based on the PCRE library*, but not all of the PCRE library is interfaced and *some parts of the library go beyond* what PCRE offers.
<discocaml>
<wravoc> Yeah, from that Erlang link:
<discocaml>
<wravoc> > The matching algorithms of the library **are based on the PCRE library**, but not all of the PCRE library is interfaced and *some parts of the library go beyond* what PCRE offers.
<discocaml>
<wravoc> From that Erlang link:
<discocaml>
<wravoc> > The matching algorithms of the library **are based on the PCRE library**, but not all of the PCRE library is interfaced and *some parts of the library go beyond* what PCRE offers.
<octachron>
It looks like erlang went on the strings as lists of scalar values side.
<greenbagels>
PCRE is far more powerful than being able to only describe regular languages right
<discocaml>
<octachron> @wravoc , for the sake of the bridge it is generally better to explain what you mean rather than edit your previous answer to add bold for emphasis
<discocaml>
<Kali> (the bridge reissues messages upon edits)
alexherbo2 has joined #ocaml
<octachron>
Oh, Erlang unicode string API does look nice. It is a shame that they choose to not handle casefolding correctly but this is at least documented.
<companion_cube>
greenbagels: yeah, PCRE is kind of badly named
<greenbagels>
companion_cube: in that respect maybe its not a bad thing that ocaml-re doesnt support PCRE's full features? (though maybe the PCRE interface then is a bit of a faux pas?)
<companion_cube>
it's just the syntax part
<companion_cube>
if you want PCRE you can just use the library that binds it, really
<companion_cube>
(bigger issue with `re` is its handling of unicode)
boozec_ has joined #ocaml
trev has quit [Quit: trev]
boozec has quit [Ping timeout: 255 seconds]
cimento has joined #ocaml
neiluj has quit [Quit: Client closed]
<greenbagels>
octachron: re: defining a module type and including it; so that means there's no avoiding making an .mli for each module, even if they are all going to have the same signature in the end, eh?
<greenbagels>
yeah at that point i'll just forego the explicit .mli and ignore the fact that helper functions in each module will be exposed, i s'pose
<octachron>
Yes, having an `include Interface.S` only solves the problem of making the `mli`s uniform.