casastortaAway has quit [Quit: ZNC 1.10.1 - https://znc.in]
casastorta has joined #ocaml
<discocaml>
<maplethecolor> No, it is a general purpose IDE made in Rust
<discocaml>
<maplethecolor> Don't know what kinda machine you're rocking but the website loads just fine
casastortaAway has joined #ocaml
casastortaAway has quit [Ping timeout: 252 seconds]
germ_ has quit [Read error: Connection reset by peer]
casastortaAway has joined #ocaml
germ_ has joined #ocaml
bartholin has joined #ocaml
Serpent7776 has joined #ocaml
zozozo has quit [Ping timeout: 276 seconds]
casastorta has quit [Ping timeout: 276 seconds]
<discocaml>
<froyo> Kali: for me it's the jetbrains font. seems most proportional and doesn't overdo the ligatures or look too unique. I will never understand narrow fonts like iosevka.
<discocaml>
<froyo> understand the appeal of*
<discocaml>
<shadowkestrel> froyo: right now i use a bitmap font called Cozette, it's pretty small for most people but works for me, and if i need to show it to others i just scale it to 2x
casastorta has joined #ocaml
<discocaml>
<shadowkestrel> i find antialiasing actually makes text harder to read for me, my eyes are a little quirky like that i guess
<discocaml>
<froyo> yeah that's the opposite end of the fonts spectrum haha
<discocaml>
<froyo> high tech ttfs and otfs with ligatures on one end, and bitmap fonts that can work in a tty on the other
<humasect>
maplethecolor. yeah it sure loads. its huge for one page
<humasect>
shadowkestrel: me also.
<discocaml>
<froyo> I wish one could map each font to each selected unicode range, for people who can read multiple scripts to enjoy the best font for each
casastortaAway has quit [Ping timeout: 276 seconds]
casastortaAway has joined #ocaml
inline has joined #ocaml
casastorta has quit [Ping timeout: 272 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<olle>
Could promises be used as an alternative to effects, in some cases?
<olle>
Instead of performing an effect, the parent scope provides a promise which is executed?
<olle>
Tho a promise is just a lambda, then.
<olle>
A lambda that's not pure.
casastorta has joined #ocaml
casastortaAway has quit [Quit: ZNC 1.10.1 - https://znc.in]
casastorta has quit [Client Quit]
<companion_cube>
Wat
casastorta has joined #ocaml
casastortaAway has joined #ocaml
<olle>
companion_cube: You have a command object that fetches a user from a storage engine. You can either perform a db effect, or the command object can be provided a promise or lambda to fetch that user.
<olle>
A more common approach in php land (and probably elsewhere) is to just inject a db connection and use that. But that usually leads to mocking hell in the test code, at least in my own code.
<companion_cube>
I'm not sure if we agree on definitions, but lwt for example has been using promises for decades
<olle>
companion_cube: sure, but I assume the code using lwt promises create their own promises, and thus makes the code effectful, not pure?
<olle>
I actually never did any mocking in OCaml, I think.
<companion_cube>
Ocaml isn't pure 🤷♂️
<olle>
Very true, I'm just looking for strategies to reduce, or better destroy, mocking in test code ^^'
<discocaml>
<maplethecolor> some good resources if you want to learn rust, feel free to ask anything about it
<discocaml>
<rmu.> you can always bring it in, python still support types, although it doesn't itself do anything with them
<discocaml>
<rmu.> @maplethecolor it's fundamentally two things, i do love the language to a certain extent. I just don't like how pulling in a single crate pulls in 500 transistive dependencies nor the macro scene, so much, way toooooooooooo much code is generated.
<discocaml>
<rmu.>
<discocaml>
<rmu.> plus, from my experience, i don't know why but a lot of people i see write Rust, fight the borrow checker way too much to an extent it harms the code quality
<discocaml>
<rmu.> ah and compile times
<discocaml>
<maplethecolor> To each their own I guess 🤷♀️
<discocaml>
<td2t> is cargo as good as dune
<discocaml>
<rmu.> rust has better tooling
<discocaml>
<maplethecolor> I'd say better
<discocaml>
<td2t> In my short time at my current uni I learned about the existence of FP
<discocaml>
<td2t> even though I had a Prolog course before
<discocaml>
<td2t> I dabbled in Haskell and Ocaml last year, they teased Rust but never gave any classes in it
<discocaml>
<td2t> the professors at my uni love Ocaml
<discocaml>
<rmu.> i ask professors in my country they tell me what is O C A M L
<discocaml>
<rmu.> spelled out
<discocaml>
<td2t> lul
* discocaml
<rmu.> pain
<discocaml>
<td2t> they also love Coq
<discocaml>
<td2t> and sometimes talk about a mythical language called erlang
chrisz has quit [Ping timeout: 252 seconds]
<discocaml>
<diligentclerk> I am a big fan of OCaml and Coq.
<discocaml>
<maplethecolor> Coq is great
<discocaml>
<diligentclerk> learning both Prolog and Haskell / OCaml is pretty important I think for understanding the diversity of language approaches that are out there.
<discocaml>
<diligentclerk> Logic programming is so fascinating
<discocaml>
<td2t> lol I would have never learned any of those if I never left my home country
<discocaml>
<td2t> I bombed my Haskell exam tho
<discocaml>
<diligentclerk> I don't think I would really want to use Prolog because it's dynamically typed, isn't it?
<discocaml>
<diligentclerk> But I learned about a statically typed logic programming language called Mercury and I've always wanted to write a serious program in it.
<discocaml>
<diligentclerk> The OCaml / ML module system should be more widely adopted in my opinion, it's a shame that the ML's are the only languages that use it
<discocaml>
<diligentclerk> You could really drop it on top of any good language and have a perfectly usable module system.
<discocaml>
<diligentclerk> isn't this stuff still under development
<discocaml>
<td2t> Im pretty sure uv and ruff is out on stable release??
<discocaml>
<diligentclerk> > ty is in preview and is not ready for production use.
<discocaml>
<diligentclerk> >
<discocaml>
<diligentclerk> > We're working hard to make ty stable and feature-complete, but until then, expect to encounter bugs, missing features, and fatal errors.
<discocaml>
<rmu.> ruff uv is ready, ty no. pyrefly ready
<discocaml>
<rmu.> pyrefly is from meta
<discocaml>
<shadowkestrel> diligentClerk: absolutely agree with you on modules. functors are also such a sensible solution to problems that other languages answer with all sorts of shenanigans (dyn trait with 5 layers of `when`, anyone?)
<discocaml>
<rmu.> rewrite of the pyre type checker which was in ocaml 🥹
<discocaml>
<diligentclerk> I don't know why I would want a faster mypy lmao. The problem with mypy isn't that it's slow, it's that retrofitting types onto Python is unwieldy and has limited adoption by the community
chrisz has joined #ocaml
<discocaml>
<rmu.> for large codebases, you do..?
<discocaml>
<rmu.> it ties into your development experience through LSP no?
<discocaml>
<rmu.> https://pyrefly.org/ i mean front of page performance comparison
LainIwakura has quit [Ping timeout: 272 seconds]
<discocaml>
<drupyog> @diligentclerk mypy's type checker is not very good. Pyright is a lot more usable
<discocaml>
<drupyog> (I don't know about pyrefly)
<discocaml>
<rmu.> pyrefly new they just released it idk when
<discocaml>
<rmu.> pyre wasn't popular outside of meta
<discocaml>
<diligentclerk> can you indicate an example of the difference? It's the same type system and same annotations I would be really surprised if somebody released a new typechecker for OCaml that was somehow better than the existing one
<discocaml>
<jalsol> my professor pronounced it oxaml
<discocaml>
<rmu.> bro was prophesizing
<discocaml>
<rmu.> OXCAML
<discocaml>
<rmu.> 😂
<discocaml>
<jalsol> nah he knew jackshit about programming languages
<discocaml>
<jalsol> he is an elder NLP researcher who took the course away from another formal language prof
<discocaml>
<jalsol> he is an elder NLP researcher who took the programming language course away from another formal language prof
<discocaml>
<._null._> Are you sure it's the same type system?
<discocaml>
<rmu.> i hope he wasn't the python-only enjoyer and touched C++ at least?
<discocaml>
<jalsol> he did assembly
<discocaml>
<rmu.> ah ok not so bad 😂
<discocaml>
<jalsol> started as an EE + CS
<discocaml>
<drupyog> The python spec only mandates part of a surface level type system that is visible in annotations, it doesn't mandate the full thing
<discocaml>
<drupyog> so different type system implement use slightly different super set
<discocaml>
<drupyog> and more importantly: they differ in how succesful they are at infering things which are not annotated
<discocaml>
<drupyog> (OCaml is a different situation, due to the notion of principal typing, where inference is garanteed complete and returning a most general type in a large subset of the language)
<discocaml>
<._null._> Does python mandate more than the syntax of types and what annotations are ?
<discocaml>
<drupyog> not really
<companion_cube>
it doesn't define a type system at all afaict
<discocaml>
<jalsol> it does throw some errors iirc if an argument doesn't have a matching type
<discocaml>
<jalsol> but that's the furthest it can go
<discocaml>
<drupyog> that's the dynamic one
<discocaml>
<drupyog> but the static one used by all the type checkers is not defined beyond the syntax of annotations. (The dynamic type system *should* be compatible with the static one, but isn't always :D)
LainIwakura has joined #ocaml
<discocaml>
<maplethecolor> There are only a few concepts enforced in the static type system by the spec
<discocaml>
<maplethecolor> beyond syntax, generics, primitive types, and a few special cases, everything else is up to the checker
td2thinh has quit [Remote host closed the connection]
humasect has joined #ocaml
<discocaml>
<contificate> "better than nothing" is my review of Python typecheckers
<discocaml>
<contificate> nowadays, can kinda write Python as bad ML - w/ `dataclasses` and `match` - nicer than Scheme, being my comparative endorsement of it
exfalsoquodlibet has quit [Changing host]
exfalsoquodlibet has joined #ocaml
<humasect>
youlia
<companion_cube>
welia, theylia?
<humasect>
eh julia =) looking back at python, having writ blender export stuff, its not so bad eh.
<discocaml>
<astreamingcomesacrossthesky> No workaday amount of money could be given to me to endorse Python over basically any Lisp dialect
<discocaml>
<contificate> I'd love to agree but it's nice to be able to introduce a style of programming in the workplace without convincing people to pick up something new
<discocaml>
<contificate> can retrofit algorithmic clarity with some of Python's latest additions
<humasect>
its quick to play with and edit, convenient, but i wouldn't use it if blender didnt need it
<discocaml>
<astreamingcomesacrossthesky> You're probably right but I quit programming professionally bc I grew weary of dealing with just the sort of person who is not quick to take up new things that seem foreign to them
<discocaml>
<astreamingcomesacrossthesky> As if a programming language that swaps out some delimiters for a different smaller set of delimiters is foreign
<discocaml>
<contificate> ha, I couldn't agree more
<discocaml>
<astreamingcomesacrossthesky> Your argument is sound tho
<discocaml>
<contificate> sometimes deal with x86_64 writers in various security communities
<discocaml>
<contificate> and they have tantrums over at&t vs Intel syntax
<discocaml>
<contificate> and yet they don't have similar tantrums over Python vs C
<discocaml>
<contificate> very curious indeed
<discocaml>
<astreamingcomesacrossthesky> It's all stupid language wars in the end and infantile tantrums about productivity, idk how it got started or how to get out of it but it does seem to be basically everywhere except these niche language communities around languages like OCaml or various lisps
<humasect>
yeah astreamingetc; i'm away from professionally but dabbling for hobby stuff, learned way too many languages =
<discocaml>
<contificate> a lot of people are unconvinced by the expressiveness of something like OCaml until they get into a domain of programming where the bread and butter is specifying and manipulating inductively-defined data
<discocaml>
<contificate> a lot of real programming work is just glue work
<discocaml>
<contificate> I basically write off my teenage years being obsessed with C++ from my programming experience
<discocaml>
<contificate> because it was just reading the standard and winning niche arguments online, not actually improving at programming
<humasect>
the main thing i look for now: the tools, platform, editor, interop etc. i know python and C++ excels on these but i dont want to use them for fun. =)
<humasect>
what is inductively-defined ?
<humasect>
contificate: same here with c/c++.
<humasect>
(except it was the 90s, not so much 'online')
<discocaml>
<contificate> let's say "recursively-defined" instead
<humasect>
spinning around haskell, lisp, prolog, julia/erlang, i feel that ocaml feels like a healthy middle. i wish it were still called Objective however
<discocaml>
<contificate> lots of languages make it an esoteric endeavour to actually spell out such data
<discocaml>
<contificate> and make working with it even more effort
<discocaml>
<contificate> yet.. it's like some of the most important stuff in programming
<humasect>
contificate: ohh yeah. after first haskell, i cannot live without pattern match and *types* and *inference* [and lazy]
<discocaml>
<contificate> the crazy thing is that ADTs and pattern matching are not inherently functional
<humasect>
yep. i used to take pleasure in writing link-list new() and remove() etc. with C. but blissfully didnt know there were Others
<discocaml>
<contificate> yet they were neglected by the mainstream for decades, not inherited by languages, etc.
<humasect>
Starting With Data is definately how i go about things
<discocaml>
<astreamingcomesacrossthesky> I will say that it is to pythons credit that it supports literal syntax for hashtables, I wish that were a more common feature of other languages
<discocaml>
<yawaramin> pretty sure we could do it in OCaml with a PPX eg `let tbl = [%h {a = 1; b = 2}]`
<discocaml>
<astreamingcomesacrossthesky> Not that that couldn't be done (idk, I imagine it's possible), but wouldn't that be incredibly complex given the existing record syntax
<discocaml>
<yawaramin> i don't think so, PPX syntax is specially distinct from normal syntax for this reason
euphores has quit [Ping timeout: 245 seconds]
<discocaml>
<yawaramin> i mean, i could be missing something, but it seems doable
hsw has quit [Ping timeout: 276 seconds]
<humasect>
i'm lost/torn between base and core ;; ppx/sexp needs core right ?
<humasect>
base*=std
hsw has joined #ocaml
xenu has joined #ocaml
<discocaml>
<deepspacejohn> You can use record syntax in PPXes. E.g. deriving show uses it for configuration `[@@deriving show { with_path = false }]`
<discocaml>
<drupyog> @yawaramin big limitation of that is it prevents writing values for the keys
<discocaml>
<yawaramin> what is 'writing values for the keys'?
<discocaml>
<._null._> You can't have `{ 0: 1 }`
<discocaml>
<._null._> (or with an `=` sign)
<discocaml>
<contificate> guess you could restructure it to be assoc lists or something - it is feasible to do
<discocaml>
<contificate> I wrote a minimal perfect hashing generator (akin to gperf) for OCaml - wasn't so bad but struggled to be that competitive with OCaml's own Hashtbl because the builtin hashing is pretty good
<discocaml>
<deepspacejohn> It would be nice if a hypothetical hashtable/map syntax could compile into the internal data structure directly, rather than function calls to add the values.
<discocaml>
<contificate> yeah, perfect hashing should be built into languages imo - same with a re2c-like language for compile time regexing
<discocaml>
<contificate> I guess what you're suggesting is more generic though - as it'd basically be a precomputed repr that you can "liven" into a real thing, so that you can edit it at runtime
<discocaml>
<contificate> without serialised calls to a bunch of `Hashtbl.replace`
<discocaml>
<yawaramin> wait, why can't we do `{0: 1}` inside a PPX record? i thought it doesn't care about type-checking at that point?
<discocaml>
<deepspacejohn> wouldn't `{0` be a syntax error?
<discocaml>
<deepspacejohn> IIRC it has to be valid OCaml syntax still.
<discocaml>
<._null._> You're parsing an indent in the LHS
<discocaml>
<._null._> ident*
<discocaml>
<deepspacejohn> you also can't express `Hashtbl.add k v` where `k` is a binding, if `{k: v}` compiles `k` to a string.
<discocaml>
<yawaramin> oh ok, then it should be possible to do the simpler case where the keys are valid idents and make a hashtbl with only string keys?
<discocaml>
<contificate> what are the values
<discocaml>
<yawaramin> 'a
<discocaml>
<contificate> the fragment of the grammar you're describing is for specifying record types
<discocaml>
<contificate> which admit of types on the rhs
Serpent7776 has quit [Ping timeout: 276 seconds]
<companion_cube>
Tbh I almost never use the polymorphic hashtable
<discocaml>
<contificate> kind of irrelevant as you could feasibly make the input format whatever you want, a semantic comment would also work
<discocaml>
<deepspacejohn> you couldn't do things like `add "CAPS KEYS" v` still, which I feel like isn't a corner case.
johnridesabike has quit [Quit: johnridesabike]
<discocaml>
<yawaramin> \#"CAPS KEYS" 🙂
<discocaml>
<yawaramin> but yeah. not really that useful
LainIwakura has quit [Ping timeout: 272 seconds]
<discocaml>
<contificate> seem to recall someone was asking about this on the discourse
<humasect>
im glad we have read/show, also sexp, coming from haskell i was serializing types just about; worked as a nice DSL/storage/db
<discocaml>
<contificate> and the solution was a horrible use of marshalling
<discocaml>
<contificate> not fond of OCaml's marshalling as it means compiler artifacts are pretty much opaque and must be examined by the correct compiler-libs version
<humasect>
hm, i've always called it [de]serializing