<d_bot>
<antron> ns12: a slightly different option is to install ocp-browser, which gives you a neat way to find most of the docs for your whole switch in the terminal
<d_bot>
<NULL> Why it isn't located at the same relative path is a good question
<ns12>
I guess I got confused by (1) the different design between the online version and the download version (e.g. lack of sidebar navigation), (2) the different relative path.
mro has joined #ocaml
jlrnick has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
olle has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
<ns12>
Hello, in OCaml, is it possible to limit a integer within a range? For example, value "x" should be an integer between 0 and 10 inclusive. "x : int" is not appropriate because it also includes integers outside the range (e.g. -2, -1, 11, 12, etc.).
<ns12>
Of course, I could try to do something like "type n = One | Two | Three | Four | Five | ...", but this quickly becomes tedious when the range is larger.
<ns12>
Besides, this would be wholly impractical for ranges of real numbers.
<octachron>
You can define a private int type that can only be constructed through a smart constructor that enforces that invariant.
<ns12>
octachron: What is a "smart constructor"? Does it only enforce the invariant at runtime?
<olle>
ns12: Type-level Peano numbers, if you're "that" kind of person :)
<olle>
ns12: But in general, no. See F* lang for comparison.
<ns12>
olle: Does this require a more sophisticated type system? What is the name of the type system that can do this?
<olle>
ns12: Multiple different type systems can do it.
<olle>
ns12: One name is "type refinement"
<olle>
Since "int" is refined to "int between x and y"
<ns12>
octachron: https://wiki.haskell.org/Smart_constructors Is that the "smart constructor" you are referring to? Looks like it only enforces the invariants at runtime, not at compile time.
<olle>
But then you have to carry around a proof in one way or the other, I think
<ns12>
Besides F*, are there any other languages that can do this?
<olle>
ns12: Yes, multiple. Agda, Idris, Coq, to name some.
<olle>
"OCaml with its module system is more or less system Fomega. The fun keyword is the lambda and the functor keyword is the big lambda"
<olle>
"Integrating refinement and dependent types: a fellowship report"
<olle>
Etc etc
<ns12>
Thank you for the information.
<olle>
np
bartholin has joined #ocaml
mro has quit [Remote host closed the connection]
xgqt has quit [Ping timeout: 256 seconds]
xgqt has joined #ocaml
mro has joined #ocaml
foo303 has joined #ocaml
<octachron>
ns12, yes but with private types, OCaml can at least enforce that you can only construct values through the smart constructors.
<ns12>
Thanks octachron for the practical advice.
<octachron>
In some very very specific case, it might be useful to use GADTs or private type with type-level integer as phantom parameter, but the complexity cost is sharp.
mro has quit [Remote host closed the connection]
infinity0 has quit [Ping timeout: 268 seconds]
infinity0 has joined #ocaml
bartholin has quit [Ping timeout: 256 seconds]
jlrnick has quit [Ping timeout: 256 seconds]
bartholin has joined #ocaml
wyrd has quit [Ping timeout: 276 seconds]
bartholin has quit [Ping timeout: 256 seconds]
bartholin has joined #ocaml
bobo_ has joined #ocaml
spip has quit [Ping timeout: 256 seconds]
<d_bot>
<EduardoRFS> Hmmm would changing OCaml ABI so that return tuples are not allocated lead to any performance regression?
bartholin has quit [Ping timeout: 256 seconds]
<olle>
I had an idea on how to extend the function core, when it's not possible to easily lift out side-effects
<olle>
That is, side-effects are tangled in business logic
<zozozo>
EduardoRFS : that'd depend on how the tuples are used: if they are deconstructed instantly upon return, then it would help, but if the tuple is sued as a value, you'd need to allocate it anyway, so it's not clear it's useful to do that in all cases
<olle>
E.g., for some side-effecst, you don't need to see the result, and it's safe to delay them. So you can put them in a queue to be executed later in the imperative shell (so called).
<olle>
Is the OCaml effect system merged? So you can jump back and forth, like with yield/generator?
bartholin has joined #ocaml
<d_bot>
<Bluddy> yes but only via a library. the language doesn't include the constructs yet.
_tjr_ has quit [Quit: quitting]
<olle>
OK, thanks Bluddy
_tjr_ has joined #ocaml
<sadiq>
olle, it's merged to trunk but not part of a release yet (it'll come with 5.0)
<d_bot>
<VPhantom> zozozo: Has there been any actual work done on unboxed types or is it just the RFC so far?
<sadiq>
if you're interested in any of this stuff I highly recommend listening to Stephen Dolan's episode on Signals and Threads.
<sadiq>
(is also covers the work happening on local allocation and unboxed types)
gravicappa has quit [Ping timeout: 256 seconds]
<zozozo>
Vphantom : mainly the RFC I think, but actually, most of the backend of the compiler is already more or less able to handle unboxed types, the main hurdle is having a user interface to control that, or adding heuristics in flambda to automatically do that, but it's not easy to do
<zozozo>
(well, unboxed records, not the unboxed types and packing suggested in the RFC)
bartholin has quit [Ping timeout: 256 seconds]
lyxia has left #ocaml [WeeChat 3.3]
bartholin has joined #ocaml
<d_bot>
<VPhantom> I see. I just like to see those kinds of milestones which make OCaml's run-time performance inch closer and closer to C++/Rust over the years.
foo303 has quit [Quit: Leaving]
<companion_cube>
yeah good luck with that
gwizon has joined #ocaml
salkin has joined #ocaml
mro has joined #ocaml
bartholin has quit [Ping timeout: 260 seconds]
<olle>
:D
<olle>
Like C# is a more realistic target
bartholin has joined #ocaml
<d_bot>
<VPhantom> For real-life work (i.e. not synthetic benchmarks for algorithm X, but stuff that includes some amount of I/O) I suspect that OCaml is already pretty darn close.
waleee has joined #ocaml
<Corbin>
olle: Like monads?
AeroNotix has joined #ocaml
<companion_cube>
yeah depends what, really
<companion_cube>
for application stuff, probably good enough
<olle>
Corbin: Monads what? Wrapping side-effects? Something like it, but in a more imperative fashion.
<olle>
Assuming there is already a legacy code base that neeeds to be made more "functional core"
<companion_cube>
I never understood that
<companion_cube>
for me it's imperative core, functional sheel :D
<olle>
I figured there are three use-cases. 1) Side-effects can be delayed in a queue; 2) Side-effects depend on each other's success; 3) You need to get the result of the side-effect at once.
<olle>
companion_cube: Sheel? Pun?
<companion_cube>
no
<companion_cube>
write the details in imperative, but limit side effects in scope
<companion_cube>
so that the larger picture is mostly made of immutable values
<olle>
companion_cube: It's related to unit testing and mocking.
<companion_cube>
I do neithe
<companion_cube>
r
<olle>
You do integrity tests for the shell and unit tests for the core
<olle>
:D
<companion_cube>
zozozo: I have an idea of a nice showcase for unboxed records :p
<companion_cube>
it's called slices
<zozozo>
haha
<zozozo>
that'd be nice indeed
<olle>
What's a slice?
jlrnick has joined #ocaml
<companion_cube>
a slice of array/bytes
<zozozo>
olle: a pointer/ref to a buffer/array/indexable thing + a start offset + a length/end offset
<companion_cube>
in other languages you can typically just point in the middle and store the length, bypassing the pointer to the beginning
<companion_cube>
but that wouldn't work with the GC
<d_bot>
<VPhantom> @companion_cube For basically anything I've been doing for my client so far, OCaml beats the sh*t out of Perl, that's for sure. An order of magnitude here, up to two there… Heck, even `ocaml-protoc` how it was 2 years ago was already 2.5x faster than `Google::ProtocolBuffers::Dynamic` in my tests, and that's despite the latter making judicious use of Google's C++ parser for the IDL and the uPB library for encoding/decoding.
<companion_cube>
I mean, sure, but perl isn't exactly the fastest :D
<companion_cube>
we should compare with Go, java, etc. rather
<olle>
Is Perl even compiled...?
<companion_cube>
nope
<d_bot>
<VPhantom> (`ocaml-protoc` was also a tad faster than `protobuf.js` which, interestingly, was still twice as fast as NodeJS's built-in JSON module for comparable JSON structures.)
<olle>
Can't compare scripting lang with compiled lang, that's silly. :)
<companion_cube>
:D
<d_bot>
<VPhantom> For sure. But my point is that for business use at least, compared to the other popular options (Ruby, Perl, PHP, JavaScript), OCaml performs admirably already.
<companion_cube>
still forgetting java :p
<companion_cube>
(and C#)
<d_bot>
<VPhantom> Java I put in the same bin as C++ and Rust nowadays because it _finally_ has decent performance at run-time.
<d_bot>
<VPhantom> …and .NET is dead to me. 😛
<companion_cube>
I'd argue that there's a bin in between the dynamic langs, and C++/rust
<companion_cube>
like {C++,rust} < {java,go,OCaml,Haskell} < {python,perl,ruby,php}
<d_bot>
<VPhantom> I know that F# outperforms OCaml but I'm willing to live with that in order to avoid .NET, Windows and Microsoft in general. 😛
<companion_cube>
JS between somewhere in the middle
<d_bot>
<VPhantom> JS sometimes performs in that middle bin.
<olle>
lol @ java + performance, just don't collect?
<companion_cube>
exactly, depends on a lot of things
<olle>
Koka 2 is the interesting case
<Corbin>
Y'all aren't serious, right? Hopefully y'all want to compare specific implementations and runtimes, not languages. Otherwise ECMAScript (browser) < Raku < ECMAScript (Rhino) < Perl 5!?
<Corbin>
(Perl 5 and Raku are difficult to compile for the same reason: arity is undecideable until runtime!! But otherwise they are not intrinsically slow.)
<d_bot>
<VPhantom> I just wish more people realized that a compiled language doesn't have to mean "twice as expensive to develop with". (i.e. OCaml is a joy to use for the most part.) I had to deal with so many things written in scripting languages and grinding to a crawl under low to moderate load, it's not even funny. It's one of the reasons I'm scrapping our Perl stuff instead of just trying to improve it.
<companion_cube>
Corbin: in general I'd consider the main implementations
<companion_cube>
or bastest
<companion_cube>
so, "JS" here mostly means V8
<Corbin>
companion_cube: So it's a popularity contest, not an actual quest for quality? It's important to be crisp about this sort of thing.
<companion_cube>
no, it's also a contest where you consider the realistic options
mro has quit [Remote host closed the connection]
<companion_cube>
if you write JS in the browser, well, you also have to account for other browsers, so perf claims are weaker
<companion_cube>
outside the browser it's almost all V8
<companion_cube>
so you can approximate to V8
<AeroNotix>
attempting to bring in OCaml to an organization would be a pretty difficult thing these days
<Corbin>
That's the game-console/PC dichotomy. This does indeed sound like popularity-contest logic.
<AeroNotix>
if the organization has already coalesced around some other platform, OCaml would be a hard-sell. There are plenty of trendier platforms most organizations would prefer to evaluate over OCaml.
<d_bot>
<VPhantom> In my case we're small enough that I was able to sell OCaml on the promise that the result would be an order of magnitude easier to maintain than our current Perl ball of strings.
<AeroNotix>
entirely depends on the number and quality of developers
<d_bot>
<VPhantom> Just one for now, in our case. 😎
<companion_cube>
Corbin: what's the issue with PC/console?
<companion_cube>
if you write a game and aim at many platforms, you still have to consider the weakest ones
<d_bot>
<VPhantom> Can you not just do less in the weaker ones, instead of leveling by the base?
<Corbin>
companion_cube: When people make a video game, they can either target a console first, or PC first. PC has more horsepower overall, but has very diverse target machines, so that it's easy to guarantee maximum performance (with a nice video card) but hard to guarantee a minimum.
<companion_cube>
unless you ask for a minimum requirement
<companion_cube>
which has been done for decades
<Corbin>
Targeting console first flips this around; the console is typically weak, but mass-produced. Easy to get a performance floor, hard to reach the ceiling.
<Corbin>
...It's common knowledge that minimum requirements for PCs do not provide a playable experience. To the point where "minimum" and "playable" are sometimes distinct sets of requirements. "minimum" usually means WRT some sort of testing or certification programme; could be as simple as "has no viruses" and "boots".
<Armael>
🤔
gravicappa has joined #ocaml
<d_bot>
<darrenldl> "It has to terminate"
<companion_cube>
I've played with the minimum requirements in the past
<companion_cube>
for some games it works, but with lower settings (ofc)
<companion_cube>
anyway, what's the relation to what we were saying?
<d_bot>
<VPhantom> …and that's why I haven't played a PC game since Grand Prix III in the late 1990s. Keeping up with requirements seems difficult (on a budget, anyway), plus most titles require a certain operating system, although I've been surprised to take a peek at Steam and find that many titles did have a Linux version these days.
<Corbin>
It's a continuation of the software-engineering discussion.
mro has joined #ocaml
<companion_cube>
but how does it relate to language performance?
<Corbin>
"language performance" is meaningless and I was hoping to illustrate the depth of the incorrectness of this sort of memetic thinking with a real-world example.
<d_bot>
<VPhantom> I think it relates to how in our use case, OCaml is basically as performant as C++ or Rust, compared to what we had before.
<Corbin>
Because, as you surely know, some games use *the exact same codebase* on both PC and console.
<olle>
"meaningless" is a bit strong
<Corbin>
VPhantom: I bet you can be more specific; by "basically as performant", you mean that a series of chosen benchmarks didn't change much, and those benchmarks were chosen relative to your actual operations?
<companion_cube>
language performance is very much meaningful
<d_bot>
<VPhantom> I haven't done more than scratching the surface yet but the difference is pretty obvious in what I've dealt with so far. The whole premise of "use any scripting language you want, hardware improves faster than the time you would've wasted using a compiled language" is garbage in my experience.
perrierjouet has quit [Quit: WeeChat 3.4]
<Corbin>
companion_cube: Provide one (1) metric on formal languages which is a correspondence/projection of performance, please. I'd love to hear how this works.
<companion_cube>
every language generally has at most a handful of implementations, so you already get a performance ceiling for them
<companion_cube>
and given how modern machines work, there's no way in hell a normal python program will be as fast as a normal rust or C++ program
<Corbin>
Sure, when using Somebody Else's Code. But that's not the only mode of software engineering, and it sounds like most of y'all are talking about corporate contexts...
<companion_cube>
you can contrieve some weird counter-example but that's just fact
<companion_cube>
no, about real programmers writing real code using existing languages' implementations
mro has quit [Remote host closed the connection]
<companion_cube>
I'm not saying there's a maximum theoretical performance
<companion_cube>
but very much a concrete one
<companion_cube>
and even then, python is slow by design
<companion_cube>
JS is, too, but a ton of efforts has been spent to make it less slow
<Corbin>
In the real world, employers typically have custom toolchains and languages which are internal to their operations. I had to learn like three DSLs at Google. I wrote a compiler at HPE. We are not in a world where corporations only use third-party code; they write their own tools.
<d_bot>
<VPhantom> The "use whatever language, performance is fine" premise is how you get startups like `rally.io` which are sluggish to use from day one. It's clear they probably use JS end-to-end, lots of flavor-of-the-month frameworks piled on top of each other, etc.
<companion_cube>
yeah and did google manage to make python fast?
<companion_cube>
the answer is: no :D
<d_bot>
<VPhantom> 😛
<d_bot>
<froyo> "language overhead" is very much real
<companion_cube>
and they *tried*
mro has joined #ocaml
<companion_cube>
several times
<d_bot>
<VPhantom> Wasn't there stuff like "cpython" or something, which compiled Python to binary?
<d_bot>
<darrenldl> good try(?) ig
<companion_cube>
similarly, for OCaml, we have good perf. But we have a ceiling
<companion_cube>
the compiler won't emit SIMD, so we just can't do it
<companion_cube>
so in some cases C++ or rust will be 8 or 16 times faster, unavoidably
mro has quit [Remote host closed the connection]
<Corbin>
companion_cube: PyPy is fast. CPython has political obstacles to becoming fast; what were you going to blame architectually?
<d_bot>
<VPhantom> The GC bit and the boxing are definitely an unavoidable overhead. Very thin compared to the abstractions in scripting language runtimes though.
<d_bot>
<froyo> companion_cube: i remember there was a talk on discuss about that
<d_bot>
<froyo> simd I mean
<d_bot>
<darrenldl> 8 - 16x speed up usually is in data encoding signal processing stuff fortunately, so not the most common thing fortunately
<d_bot>
<VPhantom> I forgot about those kinds of extensions. I guess for some very specific uses cases they can really help.
<companion_cube>
@monk because the compiler doesn't produce simd instructions
<companion_cube>
🤷
<companion_cube>
which is a valid choice, it's horribly complicated
<d_bot>
<darrenldl> or be go, and have go asm : D
<olle>
companion_cube: That's why you should compile to C :D
<Corbin>
companion_cube: So, here's the problem with that logic: Cammy in RPython is much faster than Cammy in OCaml. If I were to confuse implementations with languages, I would have to conclude that RPython's faster than OCaml.
<d_bot>
<darrenldl> afaict the GB/s type of simd code has always been crafted by experts
<Corbin>
Since PyPy is just Python in Python, and CPython is Python in C, I'd similarly have to conclude that Python's faster than C.
<companion_cube>
Corbin: possibly?
<companion_cube>
but you can't conclude from one sample point
<companion_cube>
you can also argue that pypy and cpython aren't doing the same thing
<Anarchos>
what is the autotools command to rebuild the configure script from configure.ac ? I tried autoconf, but i get some errors like «error: possibly undefined macro: AC_MSG_NOTICE»
mro has joined #ocaml
<Corbin>
companion_cube: Well, such an argument would have to be architectural. PyPy and CPython do the same sort of bytecode compilation, both have GCs, etc. (Also counterexamples *are* usually argued from just one point?)
<companion_cube>
doesn't pypy have a JIT? 🤔
<companion_cube>
well "A is faster than B" is not a rigid forall, grr
<companion_cube>
nothing in life really is (including this statement)
<Corbin>
companion_cube: PyPy is written in RPython. RPython's toolchain can automatically turn interpreter-shaped functions into JITs, but this is not part of the architecture of the interpreter itself.
<Corbin>
And yes, my point is that "A is faster than B" is a bogus belief with A and B are formal languages. We can prove things formally, but this belief seems too facile to actually be made formal.
<companion_cube>
so pypy+rpython is a JIT
<companion_cube>
yes, and we don't implement in formal languages
<Corbin>
So stop saying "language"! Say "platform", "framework", "system", or "environment".
<companion_cube>
that's incredibly vague
<companion_cube>
OCaml is a language, not a "system"
<Corbin>
RPython provides JITs, but the JIT isn't why Cammy is faster in RPython than in OCaml. *That* is entirely due to how OCaml's compiler (doesn't) handle eta-expansion.
<Corbin>
...Do you implement in OCaml?
<companion_cube>
I do, yes
<Corbin>
Then OCaml isn't a language, because "we don't implement in formal languages".
<companion_cube>
you just added "formal"
<companion_cube>
I mean, you ignored the "formal"
<Corbin>
What, OCaml isn't a formal language!? It clearly has syntax generated from a grammar, and it clearly has semantics (relative to which the compiler is implemented -- unless the compiler doesn't try to be correct!?)
<companion_cube>
the semantics is what the compiler does
<companion_cube>
but if you want to go to languages with specs, sure, there's SML, C++, for example
<companion_cube>
some people try to stay in the standard C++
<companion_cube>
and I'd argue it's generally faster than standard SML
<companion_cube>
you can find programs that will more easily be fast in SML, but not on average
<Corbin>
olle: This is about how much software engineers are allowed to ignore formal issues when making claims about how software works.
<olle>
Materialism, perhaps
<olle>
Allowed by whom?
<Corbin>
My position is merely that, since software is fully abstract and symbolic, it *only* has formal issues.
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<olle>
Sounds idealistic, indeed.
perrierjouet has joined #ocaml
mro has quit [Remote host closed the connection]
<Corbin>
(Also I am tired of tribal positions, where people insist that languages are "good" or "fast" or "beautiful" or "readable" or other empty judgements.)
<olle>
It can be fast on average in a certain domain
<companion_cube>
I'll try to read this… thing
<olle>
Assuming normally distributed skill
<companion_cube>
it's a bad start because it doesn't define what the heck it is talking about, but well
bartholin has quit [Ping timeout: 256 seconds]
<Corbin>
companion_cube: It's about how people have trouble communicating across paradigm shifts. It's also about a paradigm shift in how we talk about languages vs. systems.
<d_bot>
<froyo> if you don't put a forall qualifier and try to be pedantic, if you just account for the general case, I think it's safe to say that as long as the language enforces elementary abstractions over the platform it runs on, it'll have a ceiling over how fast programs produced by it go compared to how fast they can go if written in a language with lower level of control.
<companion_cube>
^
<Corbin>
olle, froyo: This is a fine intuition! Doesn't work for Turing-complete languages.
mro has joined #ocaml
<companion_cube>
w h o g i v e s a s h i t
<Armael>
Corbin: why?
<companion_cube>
software isn't fully abstract
<companion_cube>
software runs on real machines
<olle>
froyo, not sure that's true, since you don't know how "magic" the compiler is, right?
<companion_cube>
otherwise it's math (which is a fine thing, too!)
perrierjouet has quit [Client Quit]
<d_bot>
<froyo> olle: compiler magic is opportunistic, kinda like jit magic :P
<olle>
A super-smart compiler could be faster on average than (normally distributed) skilled devs.
<olle>
[in a certaint domain]
<companion_cube>
that's what pushed people to use C instead of asm :
<companion_cube>
;0
<olle>
Sure
<Corbin>
Armael: In short, (1) optimizers fail unpredictably on pathological non-terminating inputs, and (2) Gödel and Kolmogorov showed that we can't predict whether a program is pathological just by looking at it.
<olle>
We'll all be replaced by AI soon enough, so nothing to worry about ^^
<d_bot>
<froyo> yea ocaml is fine and performant enough even tho it doesn't have c++ level of control, it's your limits that you should know well
<companion_cube>
Corbin: but unoptimized (or barely optimized) C++ still beats the crap out of cpython
<olle>
companion_cube: On average? :)
<Corbin>
companion_cube: What are you holding constant and what are you varying when you make that claim? I have personally experienced counterexamples, so what fact do you believe you're communicating and defending?
<companion_cube>
:D
<companion_cube>
the fact that C++ will have good cache locality and compile directly to assembly
<companion_cube>
as opposed to, erm, pretty basic bytecode
<companion_cube>
I'm assuming a decent C++ programmer, ofc.
<companion_cube>
but it's clear that the same loop in C++ (with even -O0) and in python, is… well…
<companion_cube>
a major win for C++
<Corbin>
The "same"? The same types, the same exception handling, the same resource management? Also I know the word "vtable", you can't fool me with that "directly to assembly" claim.
<Corbin>
companion_cube: What I'm getting at is that the underlying motive for this statement wasn't a fact, but a tribal meme: "C++ better than Python, because the performance tribe says so"
<d_bot>
<Et7f3> Vtable is only used with virtual keyword
<d_bot>
<Et7f3> So good all struct can still be direct assembly
<companion_cube>
Corbin: or, knowing how computers work, and using both C++ and python programs
<companion_cube>
your choice
bartholin has joined #ocaml
<companion_cube>
like Et7f3 says. Besides, a vtables just means a few more asm instructions
<companion_cube>
chase pointer, find offset, jump
<Corbin>
Ah, so you mean *a chosen subset of C++ which doesn't include "slow" constructions* is "fast"?
<companion_cube>
in python: a hashtable lookup using a string :D
<companion_cube>
no, vtables are fast
<companion_cube>
much faster than a python method call
<Corbin>
Hm, so "directly to assembly" isn't what provides "fast".
<companion_cube>
no, the design of C++ also makes things fast
<companion_cube>
offsets are known (or a vtable lookup away, ie an array lookup, not a hashmap lookup)
<d_bot>
<froyo> Corbin: I think I get the point you're trying to make, and I agree that synthetic benchmarks don't reflect something inherent about the language in a formal sense.
<d_bot>
<froyo> I just don't want to dismiss the fact that a language runtime exists, and the semantics a language chooses to omit are all chances to make things go faster, or costs you have to pay because they have to be general and not tailored to your application. I can use an int knowing its value will never exceed 10, but I have to pay for a whole object in cpython, along with methods and checks and implicit conversions to bigints etc..
<Corbin>
Since the design of C++ was to desugar to C, there are no constructions in C++ that aren't also in C. Is C++ faster than C? Why or why not?
jlrnick has quit [Ping timeout: 240 seconds]
<Corbin>
froyo: Sure. Also, CPython sucks. Also also, Python is just another programming language. *But also*, OCaml sucks and OCaml is just another programming language. And etc.
<d_bot>
<Et7f3> C++ with all features is about 2-3% slower
<d_bot>
<Et7f3> than C
<d_bot>
<froyo> if it weren't for the cosmic effort it'd take to gather a representative sample of all programs in all languages, then run it, and create a scatter plot of performance, memory usage, energy usage, and code size, I'd love to see what such plot would look like
<companion_cube>
Corbin: C and C++ are pretty close
<companion_cube>
I'd argue C++ is probably a bit faster in practice, because it makes it easier to use better algorithms
<Corbin>
companion_cube: Sure. Do you see how, with your framing, you just shifted the goalposts from "fast" to "fast in a relatively small amount of code"?
rgrinberg has joined #ocaml
<d_bot>
<darrenldl> i mean if one must be pedantic, then the more precise phrasing i guess would be that different designs yield different "natural" implementations wrt state of the art at the time and budget, and we argue based on said natural implementations
<companion_cube>
Corbin: well, we moved from C++ vs python, to C++ vs C
<companion_cube>
so…
<companion_cube>
and yes, "fast in code people will actually write"
<companion_cube>
(which is why one could argue rust is even faster :p)
<olle>
OT, but in my book on physiology, the electron is a particle, and light is described as waves. Can you imagine?
<Corbin>
companion_cube: I'm not sure how to communicate the concept that which systems are efficient is not an absolute, but always relative to what our society has made efficient. Different tools are all that's required.
<olle>
Agree to disagree :D
<companion_cube>
sure, never said the word "absolute"
<companion_cube>
(and yes, performance is relative to hardware… news at 11?)
<olle>
Lisp machine anyone?
perrierjouet has joined #ocaml
<d_bot>
<froyo> love that pdf you shared btw
<d_bot>
<froyo> may sound silly, but the way its laid out is so beautiful
<Corbin>
companion_cube: "language X is faster than language Y" *is* an absolute. You might think it's relative to "the real world", but there is no single absolute real world; it's relative depending on the observer. Endorsing one relative view as the absolute state of the world is tribal.
<olle>
Corbin: I think there's an implied "on average" in there :)
<Corbin>
olle: Which probability distribution? I agree that it's implied, but I disagree that it's an argument-saving nuance.
<olle>
Corbin: E.g., making a web app, Java is on average faster than PHP
<olle>
But that's the system Java and PHP
<olle>
Well, you can argue that static typing in the formal language open possibilities of optimizations in the language system.
<olle>
Which is why you can't separate the two completely
salkin has quit [Ping timeout: 260 seconds]
bartholin has quit [Ping timeout: 250 seconds]
<companion_cube>
Corbin: a formula 1 is faster than a bicycle
<companion_cube>
sure, you can argue that if the formula one doesn't have fuel, it's actually slower, blabla, but the statement remains true
bartholin has joined #ocaml
bartholin has quit [Client Quit]
<Corbin>
companion_cube: Note that there's a dominating principle: There's some minimum distance where the car is faster than the bicycle, *and* every longer distance reduces to that case, *and* distance is a measurable metric for every trip. This principle doesn't transfer to TC languages except in special cases like the desugaring case with C++ and C; compilers need not be linear.
<Corbin>
("linear"!? That's not the right word at all.)
<companion_cube>
oh well
<companion_cube>
we probably cannot say anything about anything
<d_bot>
<RegularSpatula> I’m confused…is there something wrong with saying something like “oh I will write this genome assembler in C++ rather than python. It will be faster.”?
mro has quit [Quit: Leaving...]
<companion_cube>
apparently yes
<d_bot>
<RegularSpatula> I don’t have formal CS training so I feel as I’m missing the point of Corbin’s argument (that’s not supposed to be a slight against their argument)
perrierjouet has quit [Quit: WeeChat 3.4]
perrierjouet has joined #ocaml
<olle>
Imagine you're in a cave. You see only shadows. :)
<olle>
The shadows are the implementation.
<olle>
Outside is the sun, the real world.
<olle>
That's System F :D
<olle>
OOP is kind of the Demiurg.
gravicappa has quit [Ping timeout: 250 seconds]
<olle>
Corbin is Plato and companion_cube kind of Jesus
olle has quit [Ping timeout: 256 seconds]
perrierjouet has quit [Quit: WeeChat 3.4]
Anarchos has quit [Ping timeout: 256 seconds]
perrierjouet has joined #ocaml
Anarchos has joined #ocaml
<Corbin>
RegularSpatula: *Will* it be faster? In my experience, only sometimes. That's all that's wrong.
<companion_cube>
then you probably write crappy C++
<d_bot>
<cemerick> Say I have a module type that declares some abstract type; is there any way to allow the concrete type declared by implementing modules to be visible without adding duplicative `with` constraints to each implementing module's type declaration?
<d_bot>
<cemerick> It's _fine_ if there's just one abstract type, but pretty laborious IMO past two
<companion_cube>
I can't think of a way :/
<companion_cube>
well, you can pack stuff in a sub-module, and say `: S with module A=A`
<companion_cube>
that can alias a whole bunch of types
<companion_cube>
but it can also be tricky
<d_bot>
<cemerick> ocamllsp suggested `type t = private ..` in the signature, which apparently typechecks, but I don't know what that really means or how to match it in the implementations
perrierjouet has quit [Quit: WeeChat 3.4]
perrierjouet has joined #ocaml
<d_bot>
<cemerick> oh, `..` is the extensible variants
<d_bot>
<orbitz> Is case refutation something you use to fix code that isn't compiling or is it something you voluntarily do to help the compiler?
perrierjouet has quit [Client Quit]
<octachron>
Case refutation is here to help the exhautiveness pattern matching analyzer.
<octachron>
It is required for compiling if you are promoting the inexhaustive pattern matching warning to an error.
<d_bot>
<cemerick> companion_cube: not sure what you mean re: the sub-module suggestion
<d_bot>
<cemerick> like, have the module type actually require that everything be within an inner module, and then use that to have the compiler implicitly derive the narrower module type?
<companion_cube>
with TYPES you can carry n type aliases at once
olle has joined #ocaml
def has joined #ocaml
<def>
et vice versa
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<d_bot>
<cemerick> oh, I see
<companion_cube>
do that at scale though, and your eyes will bleed
<companion_cube>
source: I have been doing that
<companion_cube>
and my _build/log is all covered in blood now
<d_bot>
<cemerick> feels like just pushing a blob of complexity around
<Fardale>
/topic
<d_bot>
<Président daren le pétrolier> how idiomatic is using the `let ... and ...` syntax when several assignments follow each other without being mutually recursive?
zebrag has joined #ocaml
<d_bot>
<Et7f3> I think it depend `let x = ... and y = ...` seem idiomatic enough and can be more readable than `let x, y = ..., ...`
<d_bot>
<froyo> oh here's a little neat observation: last year ocaml hello world executable was ~700kb, and a little less than 300 stripped, right now with trunk it's ~2.5 mb, and a little less than 900 kb stripped
<d_bot>
<froyo> looks like there have been some substantial additions to the runtime
Anarchos has quit [Quit: Vision[]: i've been blurred!]
<d_bot>
<cemerick> companion_cube: that actually worked out for me pretty nicely, thanks 🙃
<companion_cube>
:)
<d_bot>
<cemerick> gah, 🙂
<d_bot>
<cemerick> I was able to segment off all of the operations that depended upon the parameterized types to a single functor, and then include the results in the forward-facing modules, so the API remained unchanged
Enjolras has joined #ocaml
jackhill has joined #ocaml
Putonlalla has joined #ocaml
thizanne has joined #ocaml
pgiarrusso has joined #ocaml
saltrocklamp[m] has quit [Ping timeout: 240 seconds]
salkin has joined #ocaml
mclovin has quit [Ping timeout: 245 seconds]
<d_bot>
<Président daren le pétrolier> I see, ty!
smondet[m] has quit [Ping timeout: 250 seconds]
JosEduardo[m] has quit [Ping timeout: 250 seconds]
CodeBitCookie[m] has quit [Ping timeout: 240 seconds]
Sofi has quit [Ping timeout: 245 seconds]
pgeorgi has quit [Ping timeout: 256 seconds]
OCamlPro[m] has quit [Ping timeout: 268 seconds]
spip has joined #ocaml
bobo_ has quit [Ping timeout: 256 seconds]
def has left #ocaml [#ocaml]
waleee has quit [Ping timeout: 240 seconds]
rgrinberg has joined #ocaml
saltrocklamp[m] has joined #ocaml
OCamlPro[m] has joined #ocaml
CodeBitCookie[m] has joined #ocaml
smondet[m] has joined #ocaml
JosEduardo[m] has joined #ocaml
Sofi has joined #ocaml
pgeorgi has joined #ocaml
waleee has joined #ocaml
oriba has joined #ocaml
perrierjouet has quit [Quit: WeeChat 3.4]
perrierjouet has joined #ocaml
olle has quit [Ping timeout: 240 seconds]
<d_bot>
<cemerick> what's the dune workflow/convention for vendoring a project that has not yet been published or installed? i.e. just symlinking an unpublished project doesn't work, in contrast to symlinking a working dir of a project that has been published and/or installed
perrierjouet has quit [Quit: WeeChat 3.4]
perrierjouet has joined #ocaml
salkin has quit [Quit: salkin]
olle has joined #ocaml
<d_bot>
<Et7f3> Git submodule
<d_bot>
<Et7f3> Or use opam pin/esy resolution
OCamlPro[m] has quit [Read error: Connection reset by peer]
JosEduardo[m] has quit [Read error: Connection reset by peer]
saltrocklamp[m] has quit [Write error: Connection reset by peer]
Sofi has quit [Read error: Connection reset by peer]
smondet[m] has quit [Write error: Connection reset by peer]
CodeBitCookie[m] has quit [Write error: Connection reset by peer]
pgeorgi has quit [Read error: Connection reset by peer]
<d_bot>
<cemerick> Yeah, I can (and do) vendor stuff that is otherwise opam-published, that works just fine. It's when the project in question isn't published that I hit problems.
smondet[m] has joined #ocaml
JosEduardo[m] has joined #ocaml
OCamlPro[m] has joined #ocaml
CodeBitCookie[m] has joined #ocaml
saltrocklamp[m] has joined #ocaml
Sofi has joined #ocaml
pgeorgi has joined #ocaml
waleee has quit [Ping timeout: 250 seconds]
<companion_cube>
oh no, menhir has broken my code
<d_bot>
<Anurag> @cemerick I have symlinked an unpublished project's directory into a different project in the past, and that has worked well with dune. When I'm near my laptop I can go check how my project was setup, but I don't remember needing to do anything beyond creating a symlink.
olle has quit [Ping timeout: 260 seconds]
<d_bot>
<cemerick> sure, appreciate it 🙂
waleee has joined #ocaml
<d_bot>
<cemerick> yeah, it works if I pin the library, which then does the "Package does not exist, create as a NEW package? [Y/n]" dance
<d_bot>
<Anurag> You wouldn't need to `pin` if using symlinks + dune.
motherfsck has quit [Quit: quit]
<d_bot>
<cemerick> well, it's the pinning that let's dune work in this case (or so it seems)
<d_bot>
<Anurag> I just tried this again, and my recollection seems accurate. I created symlink within a project (`ln -s ../shuttle .`) and im able to reference it in dune files in the new project and project compilation works fine. No opam involved so no pinning. An older version of `shuttle` is indeed available on opam, but it isn't installed on my local switch
<d_bot>
<cemerick> okay, but if you have an altogether-unpublished library, does a simple symlink work?
<d_bot>
<Anurag> Yes it does. But i think I know why we might be seeing a difference. I can get an error during build if i remove the `public_name` stanza from the library in the project I symlink
<d_bot>
<cemerick> mmmmm, I'll try adding one
<d_bot>
<cemerick> Whooo, dassit 🙂
<d_bot>
<cemerick> but I thought public_name defaulted to name 🤔
<d_bot>
<cemerick> oh, which is quite incorrect, looking at the docs for public_name
<d_bot>
<cemerick> @Anurag thanks again!
waleee has quit [Ping timeout: 250 seconds]
waleee has joined #ocaml
perrierjouet has quit [Quit: WeeChat 3.4]
waleee has quit [Ping timeout: 240 seconds]
waleee has joined #ocaml
sheb_ has joined #ocaml
sheb has quit [Ping timeout: 256 seconds]
perrierjouet has joined #ocaml
waleee has quit [Ping timeout: 240 seconds]
waleee has joined #ocaml
vicfred has joined #ocaml
azimut has joined #ocaml
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]