waleee-cl has quit [Quit: Connection closed for inactivity]
Haudegen has quit [Ping timeout: 240 seconds]
mfp has quit [Ping timeout: 240 seconds]
Amaan has quit [*.net *.split]
_habnabit has quit [*.net *.split]
JSharp has quit [*.net *.split]
higherorder__ has quit [*.net *.split]
JSharp has joined #ocaml
_habnabit has joined #ocaml
higherorder__ has joined #ocaml
Amaan has joined #ocaml
osa1 has quit [Ping timeout: 265 seconds]
Riddhima has joined #ocaml
Riddhima has quit [Client Quit]
mro_name has joined #ocaml
mro_name has quit [Ping timeout: 258 seconds]
Serpent7776 has joined #ocaml
ArthurStrong has joined #ocaml
curtosis has joined #ocaml
shawnw has joined #ocaml
curtosis has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
ArthurStrong has quit [Quit: leaving]
shawnw has quit [Ping timeout: 260 seconds]
Tuplanolla has joined #ocaml
shawnw has joined #ocaml
mro_name has joined #ocaml
bartholin has joined #ocaml
mro_name has quit [Remote host closed the connection]
mro_name has joined #ocaml
zebrag has joined #ocaml
mro_name has quit [Remote host closed the connection]
mro_name has joined #ocaml
mro_name has quit [Remote host closed the connection]
mro_name has joined #ocaml
mro_name has quit [Remote host closed the connection]
EstherPhebe has joined #ocaml
tane has joined #ocaml
mfp has joined #ocaml
glass is now known as theglass
EstherPhebe has quit [Ping timeout: 240 seconds]
bartholin has quit [Ping timeout: 260 seconds]
zebrag has quit [Quit: Konversation terminated!]
zebrag has joined #ocaml
olle_ has joined #ocaml
bartholin has joined #ocaml
webshinra has quit [Remote host closed the connection]
webshinra has joined #ocaml
Haudegen has joined #ocaml
mro_name has joined #ocaml
zebrag has quit [Quit: Konversation terminated!]
zebrag has joined #ocaml
mro_name has quit [Remote host closed the connection]
<shalokshalom>
How to get this working?
<schlaftier>
shalokshalom: You have a syntax error in your code. OCaml doesn't use // for comments
<shalokshalom>
Ah, ok
<shalokshalom>
I port this from a fsharp code base
<shalokshalom>
Why isnt it specifically mentioned, in the error message box?
<schlaftier>
It is mentioned that it is a syntax error. One of the few differences in syntax between F# and OCaml
<schlaftier>
It would of course be nice if it would tell you more, but it's always hard to guess what you intended to write
bartholin has quit [Ping timeout: 240 seconds]
zebrag has quit [Quit: Konversation terminated!]
rpcope has quit [Ping timeout: 260 seconds]
zebrag has joined #ocaml
rpcope has joined #ocaml
osa1 has joined #ocaml
curtosis has joined #ocaml
bartholin has joined #ocaml
tryte has quit [Remote host closed the connection]
tryte has joined #ocaml
curtosis has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
<Armael>
also, you cannot use capitalized names for types, identifiers or record field names (eg "type Item"), they are reserved for constructors (so PassableExit is fine)
Haudegen has quit [Read error: Connection reset by peer]
shawnw has quit [Ping timeout: 260 seconds]
zebrag has quit [Read error: Connection reset by peer]
zebrag has joined #ocaml
Haudegen has joined #ocaml
<olle_>
Is there any consensus or suggestion when to use exception vs other error handling technique (options type, result type)?
<d_bot>
<Shon F> This mainly evinces there not being clear consensus.
<olle_>
Yes yes :D
<d_bot>
<Shon F> But imo there are pretty good guidelines from other strongly types lang communities, and rules of thumb used in most case I write and use in OCaml.
<olle_>
Funny how exceptions are so contested
<olle_>
Some modern language remove them, others make them stronger
<olle_>
Rust, Go - no exceptions
<olle_>
Koka - exceptions is just a special case of effect handlers
<d_bot>
<Shon F> Use options when you have partial functions, and the absence of an output for an input can only mean one thing.
<d_bot>
<Shon F> Use results when the failures to find an output for an input can happen in different ways and you need to track that difference.
<d_bot>
<Shon F> Rust has no exception handling but lots of libs will panic where an ocaml lib might raise an exception.
<d_bot>
<Shon F> Use exceptions when something is truly exceptional (should not ever happen, rather than an error case you’re anticipating).
<d_bot>
<Shon F> And then, finally, if you’d rather use exceptions than results for expected errors because it really simplifies the code or improves performance or something, then do so 🙂
<olle_>
Yeah, not sure how panic improves the situation :d
<olle_>
Then theres'a `assert` :)
<olle_>
there's*
<d_bot>
<Shon F> Lol. Yeah. I guess there is at least the arguable benefit in rust of there only being one way to have recoverable errors.
<d_bot>
<Shon F> But personally I’m happy to have a way to raise and handle exceptions 🙂
<d_bot>
<Shon F> I agree it’s interesting that there’s still contention around error handling within and across communities.
<companion_cube>
It's the difference between error and bug, is all
<olle_>
companion_cube: but then rust does not differ between recorevable and unrecoverable?
<olle_>
error*
<companion_cube>
That's what I said
<companion_cube>
You should recover from errors, not bugs
<companion_cube>
(you can "catch" a panic in rust, but that's niche, only useful for test tools or in a server)
<companion_cube>
(and it's not the way of handling errors)
<olle_>
companion_cube: not sure I agree. what about database rollback at bug?
<companion_cube>
Why would you rollback :)
<companion_cube>
You should not have committed yet
<olle_>
hm
<companion_cube>
If you're in the middle of a transaction it'll be cleanup up by RAII
<companion_cube>
Cleaned up *
<olle_>
You mean Drop trait?
<companion_cube>
Yes
<olle_>
That's still run at panic?
<companion_cube>
Yes
bartholin has quit [Ping timeout: 240 seconds]
<olle_>
Ah
<companion_cube>
(unless you specify that panic = abort)
<companion_cube>
(in which case your program dies immediately and the DB will cancel when the connection is closed, I imagine)
zebrag has quit [Quit: Konversation terminated!]
zebrag has joined #ocaml
mro_name has joined #ocaml
bartholin has joined #ocaml
infinit_0 has joined #ocaml
<olle_>
But yeah, it's interesting with topics which never reach consensus. Hm.
<olle_>
AI super-lord will have to tell us later.
infinit_0 has quit [Quit: Connection closed]
<companion_cube>
The good solution is obviously a typed effect system :p
<olle_>
:)
<olle_>
companion_cube: Isn't that just Java with extra steps? :D (Didn't try it, so don't know, and I like the Java way, I think)
<companion_cube>
The big difference is that it plays well with type inference and higher order functions
<olle_>
Oh yeah
zebrag has quit [Quit: Konversation terminated!]
zebrag has joined #ocaml
olle_ has quit [Ping timeout: 260 seconds]
<d_bot>
<flazz> I use a type placeholder like `(raise Error: my_desired_type)` to trick the type checker until i figure out how to compute the value I need. Is there something like this that is more generally used?
<zozozo>
I usually just put some "assert false" as placeholders
<d_bot>
<flazz> sorry, I moved it to #beginners
<d_bot>
<ostera> are there any instances where type inference becomes undecideable, eg, when first-class modules are involved?
<d_bot>
<ostera> and by that i mean that ocamlc will stack overflow or go OOM
<d_bot>
<octachron> Not at the value level. The module type system is impredicative however and can make the typechecker loops.
<d_bot>
<ostera> aight
<d_bot>
<ostera> thanks @octachron!
<d_bot>
<ostera> I have this small datatype where one of the polymorphic variants had a module type in them
<d_bot>
<ostera> and not annotating the input argument of a function that recurses over it essentially stack overflows ocamlc
<d_bot>
<octachron> Ah, the above statement is "bug excepted". On the OCaml side, there is a bug with some constrained type projections.
<d_bot>
<octachron> Then there is the fact that bucklescript is late in term of bugfixing.
<d_bot>
<ostera> yeah, so this may just run fine in OCaml
<d_bot>
<Cyclomatic Complexity> is the coq channel bridged with #coq ?
bartholin has quit [Ping timeout: 246 seconds]
mro_name has quit [Remote host closed the connection]
mro_name has joined #ocaml
bartholin has joined #ocaml
mro_name has quit [Remote host closed the connection]
arecaceae has quit [Remote host closed the connection]
arecaceae has joined #ocaml
<shalokshalom>
This is from the homepage, is my English rusty or does this appear incorrect to you too?
<shalokshalom>
OCaml, in common with other functional languages, writes and brackets function calls differently
<d_bot>
<antron> what's wrong with it? seems like fine english, at least grammatically
<d_bot>
<antron> it does have an ambiguity, if taken without context
mro_name has joined #ocaml
<shalokshalom>
I dont understand the 'writes'
Shreya has quit [Ping timeout: 252 seconds]
<d_bot>
<antron> "OCaml writes function calls differently"
<shalokshalom>
And in general the whole second part of the sentence.
<shalokshalom>
Ah, ok.
<d_bot>
<antron> it's questionable semantically, because OCaml doesn't write - we write 🙂
<d_bot>
<antron> "OCaml brackets function calls differently"
<shalokshalom>
Ah, and brackets is also used as a verb
<d_bot>
<antron> yes it's questionable also because of that
<shalokshalom>
I have never heard someone saying "I bracket that" xD
<d_bot>
<joris> I just checked it exists in dictionary for this precise use case
mro_name has quit [Remote host closed the connection]
<d_bot>
<joris> It is even the first entry interestingly
<shalokshalom>
bracket?
<shalokshalom>
I bracket that?
<d_bot>
<antron> and there is an ambiguity even with the verb interpretation, which is that is the "writing" and "bracketing" different in OCaml from -other- things in the context, or are the "writing" and "bracketing" different from each other, i.e. inconsistent
<d_bot>
<joris> Yup
<shalokshalom>
^^
<shalokshalom>
Lets bracket that, guys. ^-^
<d_bot>
<antron> so it's a questionable sentence in many ways, but nonetheless "correct" 😛 just not advisable
<d_bot>
<djellemah> fwiw "bracket" as a verb is more often passive-voice.
<shalokshalom>
The site is read by people who have a simple English in mind.
<shalokshalom>
I hope.
<d_bot>
<antron> yep ok it doesn't immediately compare OCaml to other languages, just says "differently," which means the context does not disambiguate, in fact it looks as if it says that the reason this is a source of many mistakes is because there is an inconsistency in how OCaml writes and brackets function calls, which would be an inherent flaw of OCaml rather than a difference with many other languages
<d_bot>
<antron> yes, i think this should be rewritten
<shalokshalom>
This sounds like I dont even understand it now, after this presumly good explaination. ^^
<shalokshalom>
thanks
<d_bot>
<antron> i guess there is that comparison with C above, but it's very tenuous by the time i've worked through all the other ambiguities that this sentence presents 🙂
<d_bot>
<antron> or rather not ambiguities, but threats to comprehension
<shalokshalom>
Yeah, probably some copy and pasting going on
<shalokshalom>
The original sense, probably made sense.
<shalokshalom>
And then they added the content inbetween.
<shalokshalom>
I am about to port a code from fsharp,
<shalokshalom>
type details =
<shalokshalom>
{ Name: string
<shalokshalom>
Description: string }
<shalokshalom>
multi-line type definitions seem to be incorrect, my vscode plugin tells me it expects a closing curly in the second line,.
<companion_cube>
you need `;` in between fields
<shalokshalom>
record type, that is
<shalokshalom>
oh, thanks
<companion_cube>
also field names must be lower case :)
<companion_cube>
(at least the first letter)
<shalokshalom>
I got it
<shalokshalom>
ocamllsp does often simply say 'syntax error' and nothing else, or gives very rudimentary hints.
<shalokshalom>
Is this so also with the other editor plugins?
<companion_cube>
hum depends on the syntax error
<shalokshalom>
Something like this
<companion_cube>
some are really bad (like a missing `in` after let, sadly)
<shalokshalom>
ok
<companion_cube>
a good trick is to add `;;` after toplevel definitions to try and narrow the error
<shalokshalom>
Reason made Elm-like messages and they said, OCaml could use them too.
<shalokshalom>
I guess this didnt happen?
<companion_cube>
reason also has a better grammar for this kind of stuff, afaik
<shalokshalom>
Coming from FSharp, this seems to be a stright downgrade, tool wis.e
<companion_cube>
hmmm maybe
<shalokshalom>
And can OCaml use the Reason stuff?
<companion_cube>
well it's just a different grammar
<companion_cube>
imho merlin is otherwise very very good
<shalokshalom>
That one literally says "Syntax error"
<companion_cube>
ah!! :D
<shalokshalom>
The other one said closing bracket is missing, while it was a ;
<shalokshalom>
Sooo. *shrug
<companion_cube>
well a closing } would also have worked, right?
<shalokshalom>
Well, I wanted to do a multiline
<companion_cube>
I must say I never do this kind of error (uncapitalized constructor) so I don't see these rought edges
<shalokshalom>
Eta, Reason, Rust, Elm and so many others established such a nice standard
<shalokshalom>
Yeah, I guess.
<companion_cube>
they're also 20 or 30 years younger :)
<shalokshalom>
Most can read the documentation :P
<shalokshalom>
Well, but they are semantically not so different, right?
<companion_cube>
you can't just ignore the existing tooling…
<shalokshalom>
I think this is more about priorities.
<companion_cube>
better errors messages would help, but yeah, someone needs to step up
<companion_cube>
and there's little manpower in OCaml compared to, say, rust
<companion_cube>
(not elm, but afaik Elm is a tiny language)
<shalokshalom>
Yep, Elm is pretty small.
<zozozo>
actually, I was thinking I might try and contribute to syntax error messages for ocaml, but iirc there were some plans to change the way menhir does syntax error messages, and thus until that lands, there wasn't a lot of motivation to write the necesary code for error messages
<companion_cube>
and doesn't value retrocompatibility like OCaml does
<companion_cube>
zozozo: :o :o
<zozozo>
companion_cube: well, dolmen woke up my interest for parsing, :p
<companion_cube>
so it seems :)
<companion_cube>
I wish we could also fix the grammar but looks like it'll never happen
<shalokshalom>
*down*
<zozozo>
yeah, changing the grammar is not likely to happen
<zozozo>
and sadly, from what I see, alternative syntax experiments (did anyone say reason ?), haven't really yet shown great things from that pov (i.e. just providing an alternative syntax, but keeping all other things the same)
<zozozo>
(but that may be due to me not knowing enough of what's happening with say, reason)
<companion_cube>
shalokshalom: the upside is that code is not broken
<shalokshalom>
my code never happens to come into existence
<shalokshalom>
and neither that of new programmers
<shalokshalom>
how old is the average ocaml programmer, specifically within the project?
<shalokshalom>
Reason has split, into Rescript and something else. Static and Javascript, I think.
<shalokshalom>
So, what is the issue with my unit type? :D
<shalokshalom>
The compiler of OCaml with the syntax of FSharp, thats a cool idea ^^
<shalokshalom>
I hate .Net and love FSharp
olle_ has joined #ocaml
<shalokshalom>
How are sum types or discriminated union types are called in OCaml?
<olle_>
algebraic datatypes
<zozozo>
in some places, they may also be called variants
<shalokshalom>
ah, thanks
<shalokshalom>
500.000 different names for those :D
<shalokshalom>
tagged unions..
<shalokshalom>
Ah, they ask for a capitalized first letter.
<shalokshalom>
So records and unions basically swap places here, in FSharp
bartholin has quit [Ping timeout: 260 seconds]
<d_bot>
<colin> I think also that F# lets you pass them as functions, OCaml does not (without like ppx derivers for producing `mk_*` functions)
<shalokshalom>
uff
<shalokshalom>
you mean one of both or just one of them?
<shalokshalom>
type exit =
<shalokshalom>
| PassableExit of string * destination: RoomId
<shalokshalom>
Thats the original.
<shalokshalom>
Its warning is, again, syntax error on destination, and nothing else .
<shalokshalom>
Is this how all the editors work, or just mine?
<companion_cube>
If they reuse the ocaml parser, probably all of them
<d_bot>
<mnxn> OCaml doesn't have tuple labels like F#
<shalokshalom>
Why not simply using that from Reason?
<shalokshalom>
They said, you can just as much use that one.
<d_bot>
<mnxn> Reason is completely different syntax and grammar
<shalokshalom>
They said, its implemented on a level, where you can access it.
<shalokshalom>
They also just do compile to OCaml.
bartholin has joined #ocaml
<shalokshalom>
Its painful, every ML dialect seems to have other glaring issues
<shalokshalom>
And nobody seems to care.
<shalokshalom>
Sorry
<shalokshalom>
I am a beginner, as you can tell and I am looking for a good year or so, for a decent language to start with and I constantly jump between the few languages with the features I consider important.
<shalokshalom>
mnxn: In that example you showed me, about the union type. I see you put something in front of the string, altough the original code I think is assuming PassableExit being the string here, can you clearify this please?
<shalokshalom>
When I delete something, it just gives me a syntax error: The type variable _ is unbound in this type declaration.
<d_bot>
<mnxn> You can either have all unnamed elements (a tuple) or all named elements (a record)
<d_bot>
<mnxn> There's no weird mixing like F#
<shalokshalom>
Which I assume, means it wants something to feed into the type
<shalokshalom>
Aha, ok
mro_name has joined #ocaml
<shalokshalom>
But it is named? It is just the name of the union type itself, no?
<shalokshalom>
thats all so confusing.
<d_bot>
<mnxn> The elements of the record must also be named
mro_name has quit [Remote host closed the connection]
<d_bot>
<darrenldl> i cant think of a use case for that to be desirable tbh
<d_bot>
<darrenldl> (the mixing)
poornima has joined #ocaml
mro_name has joined #ocaml
poornima has quit [Client Quit]
<drakonis>
hmm, what are the options besides eliom for doing webdev?
<drakonis>
it seems like overkill and doesnt appear to support dune?
zebrag has quit [Quit: Konversation terminated!]
zebrag has joined #ocaml
<d_bot>
<rw> If you are looking for a Rails/Phoenix alternative, there are a few under active development; you might want to look at Sihl. For simple routers like sinatra/express, there are more "production ready" options. This page will probably help you find what you're looking for:
Guest68323 has quit [Remote host closed the connection]
<drakonis>
ah, sihl looks interesting
<drakonis>
it doesnt do frp, does it?
<drakonis>
hmm so it doesnt
<d_bot>
<froyo> funny, I went from ocaml to fsharp for a little while and felt _that_ was a straight downgrade
<d_bot>
<froyo> shalokshalom
<shalokshalom>
yeah, in many ways it is
<shalokshalom>
That is the dilemma.
<shalokshalom>
Pick your poison, as they say.
<d_bot>
<froyo> I tend to gravitate towards the more unixy poisons
<d_bot>
<froyo> I can't imagine using fsharp without an ide
<shalokshalom>
I am on Linux too
<shalokshalom>
I cant imagine using any language without an ide.
<d_bot>
<froyo> :P ocaml does it just fine
<shalokshalom>
yeah, for a professional
<d_bot>
<froyo> im far from that!
<shalokshalom>
It doesnt work for me.
<shalokshalom>
Particulary, when I know how beautifully it can be.
<d_bot>
<froyo> yeah.. thats my problem, i just like unixy poisons~
<shalokshalom>
FSharp that compiles into OCaml is my dream.
<shalokshalom>
Or Erlang, like Fez.
<shalokshalom>
Also, the community is important, and all the functional programming communites see a beginner as somebody, who comes from other languages.
<shalokshalom>
Opposed to someone new to programming.
<Armael>
there are a few good ocaml books that are targeted at beginners
<Armael>
beginners to programming
mro_name has quit [Remote host closed the connection]
<shalokshalom>
I already read them all
<shalokshalom>
OCaml for complete beginners, particullary
<shalokshalom>
That just cant replace proper IDE support, compiler messages and that like.
<d_bot>
<froyo> dependence on ides isn't good on the long run tbh
<d_bot>
<froyo> at least imo
<shalokshalom>
Also, that even something simple like a record type and sum type already introduces superflous syntax and disallows certain features to work at all, is just a downer.
<shalokshalom>
When even these simple things are complicated, compared to FSharp, what will happen further above.
<shalokshalom>
I also dont want to depend on an IDE.
<d_bot>
<froyo> sounds like a lisp could pique your interest ^^
mro_name has joined #ocaml
<zozozo>
shalokshalom: to what kind of superfluous syntax do you refer to ?
<shalokshalom>
yeah, just indendation based
<shalokshalom>
see ahead
<shalokshalom>
the semicolon in records is slightly annoying, while not the end of the world
<d_bot>
<froyo> \> When even these simple things are complicated, compared to FSharp
<d_bot>
<froyo>
<d_bot>
<froyo> a comparative mindset will see everything unfamiliar as wrong or complicated. fsharp has its conventions. it has significant whitespace which is not intuitive for some programmers. main needs "superfluous" entrypoint annotations, etc etc..
<shalokshalom>
the limitation in the sum type seems annoying.
<zozozo>
shalokshalom: what limitation ?
<shalokshalom>
indendation based syntax might be subjective, the sum type thing is not
<zozozo>
the fact about not being able to name only one of the field ?
<shalokshalom>
that there is no clear way, or even explaination until, why and how the sum type in the tutorial can be ported to OCaml.
<shalokshalom>
And it does name the thing left side of the =, I think
<zozozo>
which tutorial ?
<zozozo>
I'm a bit confused: either the tutorial is for ocaml, in which case the examples given should work, or it's not for ocaml, in which case you can't really fault ocaml for not explaining how to translate a tutorial example from another language...
<shalokshalom>
If you read the backlog, so you that a member of the community already provided a replacement
<shalokshalom>
While I dont really understand, why I need to add 'something' and make it so much more wordy and then have to do an additional step somewhere else in the code
<shalokshalom>
Thats at least, how I am understanding it.
<d_bot>
<froyo> again you're not coming into ocaml with a fresh mindset and accepting what it has to offer. you're replacing a pipe wrench with a spud and complaining they don't do everything the same way. fsharp and ocaml share heritage and thats where they stop having things in common. neither is compatible or a super/subset
<shalokshalom>
"Thats just how it is" > Closed.
<Armael>
ux a
<Armael>
(oops)
<shalokshalom>
froyo: You can say the same about jumping to C++
<shalokshalom>
Its not really the point.
<shalokshalom>
OCaml just doesnt provide the basics of programming.
<d_bot>
<froyo> why use fsharp tutorials with their focus on fsharp particulars to try and learn not-fsharp
<shalokshalom>
Doesnt help, when it exceeds in the advanced topics.
<shalokshalom>
I like to port the code, so I can see how to do it in OCaml.
<shalokshalom>
While that has turned out to be clearily a failure.
<d_bot>
<froyo> \> OCaml just doesnt provide the basics of programming.
<d_bot>
<froyo>
<d_bot>
<froyo> bold of you to say that when it's pervasive in the french education xD
<zozozo>
well.. porting code is not the best starting point to learn a language
<zozozo>
imagine trying to port F-sharp to C to learn C...
<shalokshalom>
I dont want to study a language that lacks, what F-Sharp can.
<d_bot>
<froyo> sounds like you found your fit with fsharp then ^^
<shalokshalom>
And that puts on basically every second issue "Syntax error" and nothing else.
<zozozo>
well, tbh I'm pretty each language in existence has at least one feature that no other language has
<d_bot>
<froyo> go forth and make great thing
<shalokshalom>
I mean, that is laughable.
<zozozo>
so, there will be things that F-sharp can do that OCaml can't, and the other way around is true
<shalokshalom>
froyo: The issue is, that the compiler and couple of other things, are much more my thing in OCaml.
<zozozo>
I agree that the ocaml compiler provides close to no help with syntax errors, and that is a problem
<shalokshalom>
My problems with it lie in the front end, and I hate fsharps backend.
<shalokshalom>
And they do that since 40 years.
<shalokshalom>
That will never change.
<shalokshalom>
There will never be proper error messages, since that is "superflous" appearently.
<shalokshalom>
Thanks
<d_bot>
<froyo> I'd add a "_trivially_" qualifier here. Technically you can do all with each. ...With different degrees of headache.
<zozozo>
shalokshalom: that's not what we said
<zozozo>
it's just that for now, there hasn't yet been enough efforts in that direction, compared to other languages
<zozozo>
but there are efforts, it's just that it is progressing slowly
<shalokshalom>
you can also write everything in PHP
<shalokshalom>
Syntax error for a basic error as the only information is progress??
<shalokshalom>
How that?
<shalokshalom>
What is there, less to it?
<shalokshalom>
Other than not recognizing the error at all.
<zozozo>
well, for one thing, producing good error messages in these case is *hard*
<shalokshalom>
Other languages solve it.
<shalokshalom>
Languages who are very similar to OCaml.
<zozozo>
I did'nt sya impossible, just hard
<shalokshalom>
And as Eta has shown, its mostly about wanting it to happen.
<zozozo>
and it happenned that up until now, there didn't seem to be any one entity (person or company) that was motivated enough to contribute that to the compiler
<flux>
the OCaml compiler would be able to give more precise error messages if it cared more about whitespace :)
<shalokshalom>
People have said Haskell has necessarily bas error messages, until a single person implemented straight upgrades in weeks.
<shalokshalom>
Where there is a will, there is a way.
<flux>
also, "Be the change you want to see"
<shalokshalom>
Yeah, I am a beginner
<shalokshalom>
I get that told since 2 years.
<flux>
ocaml error messages have improved a lot over the time
<shalokshalom>
I cant start, until I have a language, that has at least the most basic things, like type inference and good funtional programming support
zebrag has quit [Quit: Konversation terminated!]
<shalokshalom>
And a sensible backend
<shalokshalom>
flux: I cant imagine how it looked like before.
zebrag has joined #ocaml
<d_bot>
<froyo> a while back xlr thought multicore ocaml was an unnecessary idea, now it's one step to being merged upstream. active languages don't stop evolving.
<shalokshalom>
I went through my beginner code and it showed in literally 3/4 cases simply "syntax error" and absolutely nothing else.
<shalokshalom>
multi core support in ocaml is something I am looking very much forward
<shalokshalom>
I read that its possible to also implemented a OTP similar pattern thanks to underlying additions
<shalokshalom>
While anyway, that seems to be inaccessible to me again.
<d_bot>
<froyo> flux, I'd hate it if we ended up with significant whitespace in ocaml lol
<d_bot>
<froyo> so much structural freedom taken away
<zozozo>
personally, I look forward to the fiber management, which could make stack overflows a thing of the past
<shalokshalom>
froyo: Do you know, that FSharp has a keyword based implementation?
<shalokshalom>
F# lets you choose between significant whitespace and in/end
<Fardale>
zozozo: what is the relation between fiber and stack overflows?
<octachron>
And there is work ongoing on syntax errors, or more precisely on good and integrated error handling with menhir.
<flux>
froyo: it doesn't need to be significant to guide heuristics in error diagnostics
<d_bot>
<froyo> oh yeah, by all means then, flux xD
<flux>
froyo: consider the normal beginner bug: let a =\n let b = 42\n let c = 54;;
<zozozo>
Fardale: fibers are allocated on the C heaps, and ocaml function frames are stacked in the fibers, so basically, that could mean (but I'm trying to verify this) that you are not limited by the OS/C stack sapce anymore
<zozozo>
potentially
<shalokshalom>
Instantly closing such an issue with "thats nothing that can be changed" is something very different to me than "a lot of work going on"
<zozozo>
octachron: do you have a link for that work on error messages in menhir ?
<d_bot>
<froyo> it does mean heavier memory profile too, yeah? like haskell
<flux>
shalokshalom: btw, surely you not only received "syntax error" but also the exact place where the syntax error was. I guess a better error message would then tell what it was expecting but didn't receive.. in fact that's quite a typical error message to produce from a lexer/parser, I wonder why it's not giving that :).
<shalokshalom>
Oh wow
<octachron>
It just that the OCaml compiler has taken the principled road of improving its parser generator rather than throwing it away and just use a handwritten parser.
<shalokshalom>
If that is an improvement after 40 years of development, I dont know.
<d_bot>
<froyo> zozozo, replying to your "OCaml just doesnt provide the basics of programming.
<d_bot>
<froyo> "
<shalokshalom>
Look at Elm, they did that in a fraction of the time, including implementing the whole language at the side.
<d_bot>
<froyo> fibers are allocated on the C heaps*
<d_bot>
<Anurag> Ocaml lsp would also not be the project that can improve compiler error messages. So I'm not sure opening an issue there will be very productive.
<Fardale>
zozozo: ok thank you
<shalokshalom>
And no, I didnt get "the exact place where the error was"
<d_bot>
<froyo> gah, talking to irc through discord is a little confusing xD
<shalokshalom>
I actually got a wrong position one time
<shalokshalom>
Anurag: They probably can improve the situation by guiding people to where it does.
<flux>
I somehow doubt that, unless tab/space whitespace confusion was occurring.. I mean probably for your intended purpose, but I trust that it's able to point the exact point where it fails to parse.
<shalokshalom>
And I thought, it might be a lsp specific issue
<shalokshalom>
Since I could not imagine, that is just all the compiler can figure out.
mro_name has quit [Ping timeout: 258 seconds]
<zozozo>
froyo: indeed it can be, ^^
<flux>
IIRC even merlin has sometimes failed (perhaps still does?) in presence of wrong kind of whitespace in Emacs
<octachron>
zozozo, I am not sure if there is anything published anywhere yet.
<zozozo>
shalokshalom: what's the problem in your screenshot ?
<shalokshalom>
I intentionally replicated the mistake with the missing =, since that is what someone here tried in its instance and got the error message, that I get. Just that in my case, it mixed the line.
<shalokshalom>
The error message belongs to the let a
<zozozo>
octachron: ok, ^^ who's working on that actually ? (I ask because some time ago, I wrote quite a few hand-(written error messages for a parser library i wrote, and I was wondering if that work would be rendered obsolete by upcoming changes in menhir, :p )
bartholin has joined #ocaml
<flux>
shalokshalom: but it didn't mistake the line.. the = doesn't need to be in the same line after "a", it could be in the exact place of "type"
<zozozo>
shalokshalom: actually, no the error rightfully belongs to what appears right after the "let a"
<flux>
so here's an example where whitespace-aware diagnostics could help ;)
<shalokshalom>
thats confusing
<zozozo>
to the ocaml parser whether there are 1 space of a thousand line breaks doesn't change anything
<shalokshalom>
but when missing the ; it points it out in the very same line
<zozozo>
much like what happens in C for instance
<shalokshalom>
despite that it doesnt need to be there
<shalokshalom>
and that it actually complains about something else entirely.
<flux>
it's really the first bit of code that didn't follow the syntax
<shalokshalom>
I dont care about the internal definition, I care about the experience. :)
<flux>
pretty nice that it indeed says it was expecting =
<shalokshalom>
^^
<shalokshalom>
Did you see the Eta example above?
<shalokshalom>
Call me, when Ocaml is this far.
<flux>
if it doesn't make you think "hmm, why does it expect = here" then I dont know what to do :)
<flux>
I did not see the Eta example, how far back in the history as it?
<zozozo>
octachron: oh wow, that's impressive
<zozozo>
flux: it's a link to a tweet a bit earlier
<d_bot>
<froyo> ocaml errors are by no means a success story, but if you've worked with an older compiler they used to be way worse lol
<d_bot>
<froyo> I hope they continue to improve^^
<d_bot>
<froyo> I don't care to compare elm, eta, reason or rust, each have their very different development priorities, levels of commitment to backwards-compatibility, technical/design debt
<flux>
shalokshalom: well, OCaml basically does that already..
<flux>
Error: Unbound value List.fold_leftt
<flux>
# List.fold_leftt;;
<flux>
Hint: Did you mean fold_left or fold_left2?
<flux>
but, time to sleep
<octachron>
Even the audience of the error message is a problem. Error messages that lecture you on your mistake are fine the first few times; but are they still efficient on their hundreth instance?
<d_bot>
<froyo> shalokshalom: it would help if you came back then more willing to invest in the thing you're curious to learn about -- _including_ its quirks. waiting for perfection _to then start_ is waiting forever.
<shalokshalom>
I rather go to the more perfect
<shalokshalom>
And I am asking for fundamentals
<shalokshalom>
My mindset will never change to "accept that the absolute bare minimum" is considered a fancy feature.
<d_bot>
<rgrinberg> ocaml type errors are much better than syntax errors by the way
<d_bot>
<rgrinberg> not as good as the above, but pretty good
<zozozo>
tbh, in this case (unbound name), I slightly prefer the compact version that ocaml gives rather than the lengthy one from eta
<zozozo>
much less characters to have to read/parser in order to see what the error is
<companion_cube>
Wtf is eta anyway
<shalokshalom>
haskell on kvm
<shalokshalom>
jvm
<d_bot>
<froyo> \> accept that the absolute bare minimum
<d_bot>
<froyo> I admit it's a valid quality of life feature. I would _love_ to have nice precise error messages. (Not as much as eta's though, gosh, that looks too friendly)
<d_bot>
<froyo> I don't think that makes ocaml inferior to any of those languages. that's my problem with this whole thing. it could see improvement in **this one point** (and a couple more things), but it has its strengths that set it so far apart. You're the one to make the tradeoffs.
<companion_cube>
Good that's horrible
<shalokshalom>
too friendly
<shalokshalom>
I like it too friendly, please :)
<companion_cube>
"you wrote great code"
<companion_cube>
Fuck that message
<companion_cube>
Condescending and fake
<shalokshalom>
This is literally the only part I dont care
<shalokshalom>
I care about the other stuff
<shalokshalom>
froyo: Can I ask you one question: Did you start programming with Ocaml?
<d_bot>
<froyo> and exhaustiveness checks :D
<d_bot>
<froyo> started with python
<companion_cube>
shalokshalom: have you been a beginner for 2 years?!
<shalokshalom>
I do prefer to start with a proper language and not jumping from one half broken one to the next
<d_bot>
<rgrinberg> we need something like that based on the number of gadt's in scope when the error occurs
<d_bot>
<froyo> python -> c -> ocaml
<d_bot>
<froyo> with sprinkles of elm, haskell, java, scheme, go, js, ... yeah I looked around between those you could say.. but "mained" those three
<shalokshalom>
So I didnt start to write real code, since I like type inference, functional programming and a nice community.
<shalokshalom>
So do you think, that your comment about OCamls error messages is still true, considering you hypothetically started in it?
<companion_cube>
maybe you should stay in F#
<d_bot>
<froyo> if I started in ocaml and never left it it'd be my world
<d_bot>
<froyo> i wouldn't know what others look like
<d_bot>
<froyo> python was _perfection_ to my eye when I first started
<d_bot>
<froyo> just start! you're missing out so much waiting for a golden throne
<d_bot>
<froyo> PLs are just tools you get dirty with
<d_bot>
<froyo> yes i did use elm
<d_bot>
<froyo> i know how its compiler works
<shalokshalom>
Thats documentation, tutorial and error message in one.
<shalokshalom>
And not "syntax error" and done.
<d_bot>
<rgrinberg> Don't you think you're wasting your time?
<companion_cube>
and ours, possibly
<d_bot>
<froyo> i feel like i am, im just waiting on a stream
<companion_cube>
(oh, what do I see: Elm 0.17, so it's not a stable language 🤔)
<d_bot>
<rgrinberg> What kind of discussion do you expect? Of course nobody is going to say that these shitty error messages are good
<shalokshalom>
Everybody chooses itself, what they want to do with their time.
<d_bot>
<rgrinberg> Unfortunately, they're hard to fix. Either move on to a new language or suck it up and get past the syntax errors
<shalokshalom>
companion_cube: No, Elm is actually notorious for breaking changes.
<shalokshalom>
And I guess they are now on 0.30 or something
<companion_cube>
shalokshalom: that's kind of a lot more problematic than subpar error messages, you know?
<shalokshalom>
That screenshot is old.
<companion_cube>
like, as you said, priorities
<shalokshalom>
companion_cube: I do not say Elm is the right language
<d_bot>
<froyo> companion_cube: it's also dead fwiw, the bdfl killed it more or less xD
<d_bot>
<froyo> shame when it brought excellent novelties
<d_bot>
<froyo> but hey, didn't go to waste
<shalokshalom>
And let's see, if Elm reaches 1.0 before OCaml gets proper error messages.
<shalokshalom>
;)
<d_bot>
<froyo> imagine having extensible rows and then removing them because "nobody used that"
<companion_cube>
:DDDDDD
<d_bot>
<froyo> the records
<Armael>
oops
<shalokshalom>
And yeah, the guy killed it as he refused to work with Elchemy and basically called everyone toxic, who disagreed with him.
<shalokshalom>
Purescript still has row types.
<companion_cube>
good for them
<shalokshalom>
I didnt knew, Elm had them.
<shalokshalom>
Ah, extensible.
<companion_cube>
note that in both cases, implementing a compiler is significantly easier than for OCaml as the type systems are smaller, syntax is smaller, and there's no runtime or native backend
<shalokshalom>
I am ready for bed.
<shalokshalom>
Yes, I know.
<shalokshalom>
Eta is Haskell
<companion_cube>
OCaml devs worked harder on having a good GC and pattern matching compilation I guess.
<shalokshalom>
So...
<shalokshalom>
Its all about balance.
<shalokshalom>
And Eta can do it too.
<shalokshalom>
Rust
<shalokshalom>
Clang
<shalokshalom>
If you can implement that in C++....
<shalokshalom>
Just say you dont give a fuck
<companion_cube>
fwiw if OCaml was made in 2010 like rust, it'd have a better syntax I think
<shalokshalom>
Dont lie and put makeup on.
<shalokshalom>
I love the syntax of OCaml.
<companion_cube>
please email ocaml.org to get a refund
<d_bot>
<froyo> xD
<Armael>
:DDD
<companion_cube>
(I guess people are wrong to ask for multicore, syntax errors are much more urgent)
<d_bot>
<froyo> well the sdf plan9 stream is out if yall wanna join me
<companion_cube>
(and yeah, it's important, I agree, but if you read documentation it'll tell you about stuff as basic as "constructors are capitalize")
<shalokshalom>
both is fine
<companion_cube>
> you wrote some shitty code!
<companion_cube>
> syntax error
<shalokshalom>
It doesnt tell me the stuff about sum types
<shalokshalom>
since it simply didnt support it
<companion_cube>
still not clear what you mean there
<d_bot>
<froyo> who read the docs?! my cube companion
<companion_cube>
`type foo = A of int * string` works
<companion_cube>
`type foo = A of { x: int; y: string}` works too
<d_bot>
<mnxn> AOT for JVM and .NET seems quite difficult with how common reflection is.
<d_bot>
<mnxn> It looks like they're making good progress though.
<companion_cube>
I think you can have reflection and AOT together
<d_bot>
<mnxn> GraalVM was a very slow compiler last time I tried it. Unlike OCaml :)
<companion_cube>
unless you mean reflection where you can instantiate generics at runtime
<d_bot>
<mnxn> I think all of that falls under the "reflection" umbrella in the Java and C# worlds
<shalokshalom>
CoreRT always worked only for C#
<shalokshalom>
And dotnet core is now .NET
<companion_cube>
@mnxn I think java can't do that since generics are not reified
<companion_cube>
but the little I know about .NET indicates that they, indeed, rely a lot on JIT-ing code
<shalokshalom>
And I assume, that compiling F# to OCaml is possibly simple
<shalokshalom>
The only other compilers currently are Fable and Fez and Fez is unmaintained.
<companion_cube>
you probably assume wrong
<d_bot>
<mnxn> companion_cube: Hmm, maybe not. I just remember having to add a list of a bunch of classes to the graalvm command line for a reflection-dependent program to not crash at runtime.
<companion_cube>
OCaml doesn't have a JIT
<shalokshalom>
Generics in .Net are actually implemented by the FSharp maintainer.
<d_bot>
<mnxn> shalokshalom: CoreRT definitely worked with F# before.
<d_bot>
<mnxn> Not all of it (like printfn), but I remember have programs that worked.
<d_bot>
<mnxn> Compiling a language to another is almost never simple
<shalokshalom>
Yeah, I mean it was considered incomplete and people didnt really consider it production ready
<shalokshalom>
Other than with C#
<shalokshalom>
Well, F# and Ocaml are very similar. And Haxe can compile to 10 different languages
<shalokshalom>
Nim to at least 4 or so.
<d_bot>
<Jbasto> Are there any decent semantic analyzers made in ocaml that are built to interpret COOL (Classroom Object Oriented Language), preferably one that utilizes hashtables.
<d_bot>
<Jbasto> Im just looking for one that I can reference
vicfred has joined #ocaml
l1x has quit [Quit: Connection closed for inactivity]