A Ruby compiler that learns

I've posted this on reddit, so it might have been lost in the barrage of
comments, so I'll do it here:

   - will a library of generic interfaces, such as Reader (a la "go"
   io.Reader/Writer) be distributed and usable along with ruby? This is
   important for composability, as simple interfaces will otherwise be
   repeated everywhere.
   - will setting String as an expect type be able to accept something that
   can be coerced to a String? Or that implements #to_s? Or will there be a
   "Stringable" interface for that? Examples in ruby itself are "puts", which
   calls "#to_s" on whatever it's passed along, or "IO.select", which will
   call "#to_io" on the elements of readers/writers arrays.

I'm definitely excited about the possibilities of optional typing, I'd just
like for ruby to have optimal support for "duck-typing", it's greatest
feature.

Martin DeMello <martindemello@gmail.com> escreveu no dia quinta, 30/07/2020
à(s) 20:43:

···

I may be biased because my day job involves writing a static type checker
for python, but I'm really excited to see type annotations coming to ruby.
The fact is that even most dynamic-language code is, for want of a better
word, singly typed - functions expect every argument to have a certain
type, and likewise return a certain type. Furthermore, even when you have
function parameters that can accept objects of several types, it is usually
a fixed set of types (which can be expressed as a union), and there is very
often explicit branching code within the function body that checks the
object's type and then does something with it.

Type annotations serve two purposes - they let static analysis tools help
verify that you are passing objects around correctly, but also they offer a
very convenient and compact way to document your function signatures, and
make reading and working with an unfamiliar codebase a lot easier. I
definitely prefer reading type annotated python code myself. (There was
also Ashley Yakely's great quip that "every sufficiently well-documented
lisp program contains an ML program in the comments")

Now, do the type annotations interfere with ruby's duck-typed nature? No,
for several reasons. The most obvious one is that the language itself
neither mandates nor enforces them - you can treat them as pure
documentation, or ignore them altogether. But assuming you want to opt in
for all the benefits they provide, and run the type checker over your code,
is there anything you can't do? The answer, again, is no - there are
several escape hatches for more duck typed code, including

- Union types: If a parameter can take any of a fixed set of types, you
can just type it as a union. The type checker can then do control flow
analysis to see if some code branches narrow the union to a single type,
and if not it checks that any method calls on the variable are compatible
with all its types. For example

def f(x: A|B)
  case x
    when A
      # x is of type A in here

- Subclassing: This is a standard method for polymorphism in statically
typed OOP languages, and ruby of course supports it

- Interface types: Also called 'protocols' in some languages. This is a
formalisation of "duck typing" - you specify the methods that your argument
must support, and give that set of methods a name. There's an example in
the blog post.

- The Any type: Any is a type that simply specifies that the argument can
be anything. The type checker won't complain about any method you might
want to call on it.

Again, I want to emphasise that your code *already uses these typing
concepts*, it just does so implicitly without any good way to communicate
that to the reader. Now there is a good way.

martin

On Thu, Jul 30, 2020 at 7:38 AM Karthikeyan A K <mindaslab@protonmail.com> > wrote:

Hello All,

I came across this link
The State of Ruby 3 Typing and it
worried me a lot, I saw what people said on twitter and I was not alone.
Looks like most people do not like to add typing in Ruby. Yes I do realize
the benefits we might get like faster programs and so on but....

I strongly feel Ruby should be a language for humans and not language for
corporate's. It's big companies that want these typing. At the same time it
will be great if Ruby can learn to add types automatically. Lets say I have
a function add(a, b), on running it lot of times, Ruby can infer that most
of the time a and b are Number, and hence it can keep a meta data of this
thing it learned in a file in the same project folder. This way we can have
faster Ruby with less programmer frustration. May be we can use test file
that tests these programs (during TDD) to add types.

I am not an language expert, but I Love Ruby, I just want it to be the
best language for programming (for humans). What do you think about it?

- Karthikeyan A K

Sent with ProtonMail Secure Email.

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;

Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk&gt;