https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112017-12-09T17:25:25ZRuby Issue Tracking SystemRuby master - Feature #14164: [Suggestion] Type system for ruby 3x to be usable for e. g. rubocop or autogenerating crystal code and so forthhttps://bugs.ruby-lang.org/issues/14164?journal_id=682452017-12-09T17:25:25ZEregon (Benoit Daloze)
<ul></ul><p>Here are some thoughts:<br>
Although Crystal looks very similar syntactically, the semantics are fairly different: no runtime metaprogromming, no eval, no arbitrary precision integers by default and it is a statically-typed language (with good type inference to hide it).<br>
So I think if we can auto-generate Crystal from Ruby code it will be either not compatible in many situations, or not significantly faster.<br>
It's a bit like the idea to generate C code from Ruby code, but this gains almost nothing if expressed with the same dynamism (with rb_funcall, etc).<br>
Maybe one could help a bit the semantics by being able to specify an argument if of type int64, but this seems to somewhat go against Integer unification.<br>
Personally I would rather advocate a polyglot approach using multiple languages, by using a different language when requirements need it.</p> Ruby master - Feature #14164: [Suggestion] Type system for ruby 3x to be usable for e. g. rubocop or autogenerating crystal code and so forthhttps://bugs.ruby-lang.org/issues/14164?journal_id=743442018-10-08T13:44:02Zjwmittag (Jörg W Mittag)Ruby-Lang@JoergWMittag.De
<ul></ul><p>I feel that most discussions about "type systems" or "types" for Ruby suffer from a serious lack of unambiguous definitions, this discussion included. Somebody proposes something without precisely defining what <em>exactly</em> they are proposing, then somebody else argues for or against this proposal without precisely saying how they interpreted the proposal and so on and so forth.</p>
<p>There also seems to be a serious lack of understanding of type systems and typing in the Ruby community, which doesn't exactly help discussions about type systems and typing.</p>
<p>For example, this is (at least) the second issue on this tracker that mentions optional typing and performance. There are also several blog posts and tons of threads on ruby-lang. The thing is: optional typing can <em>by definition</em> not improve performance. In fact, optional typing is <em>defined</em> as "typing that does not influence runtime". That is what <em>makes</em> it "optional" in the first place. If optional types had an impact on performance, then there could be programs that run fast enough with the types, but too slow without, and for those programs, you would <em>need</em> the types, thus they would no longer be optional.</p>
<p>The <em>only</em> thing optional typing is allowed to do, is to reject a program as not type-safe. That's it. Adding or removing types can make a program type-check or not type-check, and that is <em>all</em> adding or removing types can do.</p>
<p>The powerful thing about optional typing is that, since it is optional, you are not tied to a single type system. You can choose the type system that works best for you. You can change type systems over the course of a project. You can mix multiple type systems within a project. You can even use multiple type systems at the same time for the same chunk of code.</p>
<p>Discussions about typing in Ruby always seem to confuse a lot of things: Type Annotations vs. Type Language vs. Type System vs. Type Checking. Gradual vs. Soft vs. Optional Typing. Explicit and Implicit Typing. Static and Dynamic Typing.</p> Ruby master - Feature #14164: [Suggestion] Type system for ruby 3x to be usable for e. g. rubocop or autogenerating crystal code and so forthhttps://bugs.ruby-lang.org/issues/14164?journal_id=806232019-08-11T22:00:08Zjwmittag (Jörg W Mittag)Ruby-Lang@JoergWMittag.De
<ul></ul><p>shevegen (Robert A. Heiler) wrote:</p>
<blockquote>
<p>Crystal is in many ways similar to ruby;</p>
</blockquote>
<p>It really isn't. I don't know where this myth originated and why it is so widespread and persistent.</p>
<blockquote>
<p>the syntax is somewhat similar</p>
</blockquote>
<p>Yes, that is true. However, of the three parts that make up a programming language (Semantics, Type System, Syntax), syntax is the least important part of a programming language, although admittedly the most argued about, possibly since it is the most visible and the most easily understandable part.</p>
<p>It is very easy to change the syntax of a language. See, for example, Vala and Genie which are actually more or less <em>the same language</em> just with different syntax. Vala has a C♯-inspired syntax, Genie has a Python-inspired syntax, but they both have the exact same semantics, exact same type system, etc. They are compiled by the same compiler and even have <a href="https://wiki.gnome.org/Projects/Genie#line-106" class="external">the same Syntax Tree</a>.</p>
<p>On the other hand, C and ECMAScript have very similar syntax but radically different semantics.</p>
<blockquote>
<p>(if we ignore the type system and macros perhaps).</p>
</blockquote>
<p>There is a movement in Programming Language Theory to see Type Theory as the Grand Unifying Theory of Programming Language Theory. In other words, there are researchers within PLT who argue that the Type System of a programming language is the <em>only thing</em> that matters. So, if we "ignore the type system", then we ignore the only thing that matters, and then you can indeed say that Crystal is very similar to Ruby, but only because you deliberately ignore the <em>one thing</em> that makes it completely different.</p>
<p>Personally, I think that is going too far and that Semantics are also important, but again, Crystal's semantics are also very different from Ruby's.</p> Ruby master - Feature #14164: [Suggestion] Type system for ruby 3x to be usable for e. g. rubocop or autogenerating crystal code and so forthhttps://bugs.ruby-lang.org/issues/14164?journal_id=806532019-08-12T08:15:23Zzverok (Victor Shepelev)zverok.offline@gmail.com
<ul></ul><blockquote>
<blockquote>
<p>Crystal is in many ways similar to ruby;</p>
</blockquote>
</blockquote>
<blockquote>
<p>It really isn't. I don't know where this myth originated and why it is so widespread and persistent.</p>
</blockquote>
<p>To the best of my memory/understanding, it is not a myth, but a <em>historical</em> fact: Crystal started as an attempt to just make a "compiled Ruby" (probably with type system, but "invisible" kind of one, so on the surface it still looked totally like Ruby and was type-inferred all the way down), then the authors realized they'll need at least <em>some</em> changes to make it work, and somewhere at the road they understood the language is different enough to diverge whenever they want (for example, rethink parts of standard library, change names and APIs of core classes and so on).</p>
<p>But the main page still states</p>
<blockquote>
<p>Crystal’s syntax is heavily inspired by Ruby’s, so it feels natural to read and easy to write, and has the added benefit of a lower learning curve for experienced Ruby devs.</p>
</blockquote>
<p>Obviously, neither of this makes the rest of your comment less true: the languages are quite different by their, so to speak, "spirit" already. I just wanted to point out that the "myth" has its hard justification (and that's why people frequently came with "let's borrow this from Crystal" ideas -- the same, to some extent, happens with Elixir, which also has Ruby-inspired syntax and intersecting communities, so every month somebody proposes to "finally" borrow the <code>|></code> operator, which just will not make sense in Ruby).</p>