Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Type-safe GraphQL with OCaml

andreas.github.io

Post reply on HN
Print view View original

91–100 of 102 posts

Re: Type-safe GraphQL with OCaml

#91

Post by kbenson »

runeks wrote: post #80
kbenson wrote: post #45

Earlier quoted context omitted.

> The first is modular implicits: it feels so kludgy to have to type `a + b` for integers, `a +. b` for floats and `a ^ b` for string concatenation. I know it sounds like a small thing, but it makes the language feel inelegant, and aesthetics are important. That's interesting, as being forced to use the same operator for addition and for concatenation (and what's more with the result of mixed types if allowed often d…

> Not allowing the addition of floats and ints together is less of a fundamental issue, but it also helps quite a few problems. Needing to use +. to add two floats seems odd to me as well, and I believe this is what OP was pointing out. I would agree with you that adding and int to a float should require conversion of one of the arguments, but I see no need for a separate + operator for floats and ints.

> I would agree with you that adding and int to a float should require conversion of one of the arguments, but I see no need for a separate + operator for floats and ints.

Yes, what I was trying to express is that in a typed language with many types, choosing a few types and using operators to signify what you are doing is an odd choice, especially if you implement it for some types but not others. I understand the want of the language designers to protect people from these mistakes, I just think they chose an oddly inconsistent way of of doing so. The logical conclusion of different operators for different types is many more operators than shown here, so that leaves the language with these special cases. Special cases cause confusion.

Re: Type-safe GraphQL with OCaml

#92

Post by z3t4 »

runeks wrote: post #82
tom_mellior wrote: post #75

Earlier quoted context omitted.

> a return code type mismatch caused every Mac OS X machine [...] I don't doubt you, but I was just trying to read up on details of this and the internet is so full of fluff pieces that I can't find anything technical real quick. Would you have a link to a writeup of the bug behind this issue?

https://www.theregister.co.uk/2017/11/29/apple_macos_high_si... The relevant function returns an opaque integer to signal failure/success. If this were typed properly — e.g. a type that represents either “Success” or “Failure” explicitly (rather than implicitly via an int) — the bug would be unlikely to happen, since it would require the function in question to explicitly return “Success” when in fact it had failed (…

While disassembled code is hard to read I think it's not a problem with weak types. The problem seems to be the root account got enabled without a password.

Re: Type-safe GraphQL with OCaml

#93

Post by masklinn »

runeks wrote: post #81
masklinn wrote: post #25

Earlier quoted context omitted.

Haskell does not allow accidentally mixing floats and integers together. In fact it doesn't even allow mixing finite and infinite-precision integers together, despite using the same operator for all number additions: Prelude> (3::Int) + (4::Integer) :2:13: Couldn't match expected type ‘Int’ with actual type ‘Integer’ In the second argument of ‘(+)’, namely ‘(4 :: Integer)’ In the expression: (3 :: Int) + (4 :: Intege…

Off topic: why on earth does ghci print out that last “In an equation for ‘it’: it = […]” statement? Seems like something internal to ghci, and not something that’s relevant to the user.

You'd have to check ghci's source itself, but I expect it just hands the bits over to GHC for evaluation and the relevant GHC API (sensibly) requires a name, for which ghci provides "it".

Re: Type-safe GraphQL with OCaml

#94

Post by renox »

kcorbitt wrote: post #18
StreamBright wrote: post #15

Earlier quoted context omitted.

I think the exact opposite. Finally a language where floats and integers cannot be mixed together accidentally.

The type checker is capable of disallowing `float + int` while still allowing `int + int` and `float + float`, which is what I want.

Why? As long as float -> int implicit conversion are forbidden, I don't see any issue with allowing implicit int -> float conversion.

Re: Type-safe GraphQL with OCaml

#95

Post by renox »

k__ wrote: post #9
kcorbitt wrote: post #4

If ReasonML is able to form a real community, I have high hopes for its long-term prospects. Such an enjoyable language to use! I think their general approach of bootstrapping a community by lowering impedance with the JS ecosystem is a decent one. In case anyone on the OCaml team is reading this though, there are two language-level changes that I think could do wonders for wider adoption. The first is modular implic…

I think the problem isn't that + +. and ^ look different, it's that they are symbols. That's also what makes scala so unapproachable, you get stuff like ++> or =*= that doesn't make any sense. x + y makes sense to most people x ^ y not so much

But addition != concatenation, that said I prefer ~ for concatenation operator (as in D)

Re: Type-safe GraphQL with OCaml

#96

Post by KirinDave »

z3t4 wrote: post #92
runeks wrote: post #82

Earlier quoted context omitted.

https://www.theregister.co.uk/2017/11/29/apple_macos_high_si... The relevant function returns an opaque integer to signal failure/success. If this were typed properly — e.g. a type that represents either “Success” or “Failure” explicitly (rather than implicitly via an int) — the bug would be unlikely to happen, since it would require the function in question to explicitly return “Success” when in fact it had failed (…

While disassembled code is hard to read I think it's not a problem with weak types. The problem seems to be the root account got enabled without a password.

It is crystal-clear a type error, but here's an article breaking it down:

https://objective-see.com/blog/blog_0x24.html notes that od_verify_crypt_password is called with an error check expecting 0, but on failure it returns 0x1. The code then goes on to a "success" path with an "update".

This is a classical type mismatch that C and C++ pre-2012 are so famous for. Someone writing this program where both modules were in Rust would have used Option or Result and this expectation mismatch wouldn't have existed.

Re: Type-safe GraphQL with OCaml

#97

Post by pimeys »

KirinDave wrote: post #90
pimeys wrote: post #69

Earlier quoted context omitted.

I'm not the biggest fan of Scala, but for me it's more that it reminds me of Java than the functional constructs. But pointing at Scalaz is a bit ridiculous. It's a known test library for trying things out and basically not allowed in any Scala codebase I've been working on.

Scalaz is widely used and widely panned. Even though I'm a haskell and purescript programmer that prefers to write and >>=, I find Scala's approach frustrating and hard to read. Especially as type lambdas stack up. I'm just saying; the impression exists for a reason and the reason is a popular and well-known library.

I'm all with you here. I prefer Haskell and OCaml every time over Scala.

Re: Type-safe GraphQL with OCaml

#98

Post by z3t4 »

KirinDave wrote: post #96
z3t4 wrote: post #92

Earlier quoted context omitted.

While disassembled code is hard to read I think it's not a problem with weak types. The problem seems to be the root account got enabled without a password.

It is crystal-clear a type error, but here's an article breaking it down: https://objective-see.com/blog/blog_0x24.html notes that od_verify_crypt_password is called with an error check expecting 0, but on failure it returns 0x1. The code then goes on to a "success" path with an "update". This is a classical type mismatch that C and C++ pre-2012 are so famous for. Someone writing this program where both modules were…

It is still not clear, it seems more like a logic error to me. Zero means success and a non zero value is an error code. It basically says "if login fails, then do this". If they would have used a boolean instead, or a result enum, the code would have taken the same path! I argue that strong typing would not have detected the logic error! The bad code was probably rushed in to make the upgrade work. All tests turning up green can really put you into a false sense of security. But that is another strongly opinioned topic!

Re: Type-safe GraphQL with OCaml

#99

Post by KirinDave »

z3t4 wrote: post #98
KirinDave wrote: post #96

Earlier quoted context omitted.

It is crystal-clear a type error, but here's an article breaking it down: https://objective-see.com/blog/blog_0x24.html notes that od_verify_crypt_password is called with an error check expecting 0, but on failure it returns 0x1. The code then goes on to a "success" path with an "update". This is a classical type mismatch that C and C++ pre-2012 are so famous for. Someone writing this program where both modules were…

It is still not clear, it seems more like a logic error to me. Zero means success and a non zero value is an error code. It basically says "if login fails, then do this". If they would have used a boolean instead, or a result enum, the code would have taken the same path! I argue that strong typing would not have detected the logic error! The bad code was probably rushed in to make the upgrade work. All tests turning…

You've just defined two type errors.

Re: Type-safe GraphQL with OCaml

#100

Post by hajile »

c-cube wrote: post #76
hajile wrote: post #58

Earlier quoted context omitted.

I wish SML were more popular. The syntax is much better and regular. I'll be done teaching you advanced SML language features before I could finish teaching the basics of ocaml. SML also has a multithreaded implementation in polyml and a better compiler in mlton. The standard library is not big enough, but at least there aren't 4 like in ocaml (std, core, batteries, and container). The only issue is that just a littl…

Nowadays, OCaml has so many more syntactic sugar and typing goodies compared to SML, that it's not fair to compare them anymore. I'm no expert in SML, but from what I know: - OCaml's pattern matching is more powerful (more or-patterns, lazy, matching records with field-puning): `match x with lazy {x; y; z=(None | Some 0); _} -> x+y` - GADTs along with phantom types: many things are now type-safe (including the builti…

Ocaml is a mess. Just like C++, PHP, or Perl, it's spent way too much time bolting extra stuff here and there until different codebases can look like completely different languages. Ocaml's features don't flow well together and make it very hard to teach the language (as used in the real world) to new developers.

Golang has fewer features than Ocaml and is worse in almost every way, but people love it's simplicity. The best language features are the ones you can add without significantly increasing syntactic complexity.

I agree that Ocaml has some great features that the current SML spec lacks. That spec is 20 years old now. There's plenty of room to look at Ocaml features and pick a good set that does enough of the things without blowing up the complexity.

SML's let expression is definitely superior to Ocaml's. Ocaml has two different `let` expressions -- one for top-level and one for sub-expressions.

To borrow from a comparison [here](http://adam.chlipala.net/mlcomp/)

    (* Ocaml *)
    let six = 6
    let rec fact x = if x = 0 then 1 else x * fact (x - 1)

    let six_fact =
      let six = 6 in
      let rec fact x = if x = 0 then 1 else x * fact (x - 1) in
      fact 6

    (* SML *)
    val six = 6
    fun fact x = if x = 0 then 1 else x * fact (x - 1)

    val six_fact =
      let
        val six = 6
        fun fact x = if x = 0 then 1 else x * fact (x - 1)
      in
        fact 6
      end
SML groups multiple declarations together which provides greater clarity IMO while having an end keyword helps identify the let block.
Post reply on HN