Types will be part of Ruby 3 stdlib source

Post by 59nadir » Fri, Apr 19, 2019, 4:53 PM UTC

Shish2k wrote: post #82

tomc1985 wrote: post #26

Earlier quoted context omitted.

So, what, everyone standardizes around an IDE then? You really think that's gonna unite the vim and emacs camps? I'm personally tired of staring at variables trying to figure out what they're supposed to be, then having to dive into source to see how its used. C/C++/C# solved that problem, why are we still dealing with it?

C had some typing, but I'm not going to call it "solved" until "numberOfHats = distanceInPixels + weightInKg" is considered a compile-time error due to the three "int" values being incompatible; but "numberOfHats = aliceHatCount + bobHatCount" is acceptable. How does nobody(?) support this yet? Python supports some parts: you can subclass int, and you get all of the int methods like addition and subtraction for free,…

    newtype Pixel = Pixel Int
    newtype Em = Em Int

    pixelWidthToEm :: Pixel -> Em
    pixelWidthToEm (Pixel px) = Em px

    data User a =
      User { name :: String, socialSecurityNumber :: String }

    data LogSafe
    data LogUnsafe

    logUser :: User LogSafe -> IO ()
    logUser = undefined

    makeUserLogSafe :: User LogUnsafe -> User LogSafe
    makeUserLogSafe = undefined

    type DistanceInPixels = number & { readonly __newtype__: "DistanceInPixels" }

    export type Newtype = T & { readonly __newtype__: Tag }
    type Pixels = Newtype

Post by aasasd » Fri, Apr 19, 2019, 5:10 PM UTC

wilg wrote: post #182

aasasd wrote: post #160

Earlier quoted context omitted.

It's not limited by network speed because I have HOMEBREW_NO_GITHUB_API and HOMEBREW_NO_AUTO_UPDATE enabled. It's not like I just today stumbled into the problem. Brew's not even consuming much system cpu time during `brew search`, despite hogging a core for a full minute. Even just `brew help` takes almost 10 sec cold.

Are you using JRuby or something? 10 seconds is too long. > time brew help > brew help 0.55s user 0.26s system 96% cpu 0.849 total

Post by delaaxe » Fri, Apr 19, 2019, 5:21 PM UTC

fjp wrote: post #180

viraptor wrote: post #150

Earlier quoted context omitted.

It depends what do the type annotations do. I'm not sure how perl6 does it, but for example in python type annotations are completely ignored at runtime, so don't have any impact. We'll see how much / for what does Ruby 3 actually want to use the type information. Sorbet on its own is unlikely to affect runtime either.

Going to keep praying for type/performance optimizations in Python so we can all get past the "python is slow" thing. Async python is an absolute joy to develop with.

Post by geraldbauer » Fri, Apr 19, 2019, 5:31 PM UTC

geraldbauer wrote: post #97

cutler wrote: post #83

Instead of: sig {params(name: String).returns(Integer)} ... why not simply: sig {name: String, returns: Integer}

Instead of: sig {params(name: String).returns(Integer)} ... why not simply: sig [String]=>[Integer] Yes, that's just ruby - see https://github.com/s6ruby/ruby-to-michelson/blob/master/cont... for example for live running code (in secure ruby) :-)

   sig {params(new_value: T.nilable(Integer)).void}

   sig Integer?                  # or
   sig [Option.of(Integer)]=>[]  # longest form in sruby
   sig [Integer?]=>[]            # same as Integer?

Post by BenMorganIO » Fri, Apr 19, 2019, 6:01 PM UTC

mnarayan01 wrote: post #133

cutler wrote: post #110

Earlier quoted context omitted.

Right, so why not implement the sig as a block and keep the syntax concise - the Ruby Way.

Then you'd need an extra set of delimiters, e.g.: sig {{name: String, returns: Integer}}