6 ms·

Wow types in a different file... This is like C++ but worse... Is this because Ruby is extremely difficult to parse, to the point that nobody wanted to mess wi

Wow types in a different file... This is like C++ but worse... Is this because Ruby is extremely difficult to parse, to the point that nobody wanted to mess with the parser? I remember reading a comment a while back from the creator of a Ruby parsing library and he said the language design is arbitrary and extremely difficult to parse correctly

corytheboyd 6y ago
I am guessing this is exactly why, otherwise why would any sane group of people come up with this idea? And if that's the case... why why WHY even try to do it this way?! Feels like a VERY forced pushing of a square peg into a non-existent hole.
- tinco 6y ago
  I don't think that's not the reason at all, features are regularly added to ruby with much more complicated consequences for the parser. I would speculate the reason is that it's a very consequential change for the user, and they don't want to commit to it yet. I bet Ruby 4.0 will have optional inline types, if it turns out RBS are as functional as is expected.
sanxiyn 6y ago
I think it is more like .d.ts for TypeScript. Sometimes you do want types in a different file.
- shadowfacts 6y ago
  Not really, .ts files can have types in the source code. .d.ts lets you type external JS code which is useful for untyped dependencies, as is the case here, I imagine. But within your own project having types be part of the actual declarations is much better.
- throwaway189262 6y ago
  Those are only used to retrofit types on external libraries that don't have them. All types within project are in the source. .d.ts is a way to add types to source you don't control. Ruby should have gone the path of typescript where .d.ts generation and type stripping is done by a tool you run when you publish your library. That way you can work with types in your code but export it to plain js that others can use with or without tyoings
viraptor 6y ago
> Is this because Ruby is extremely difficult to parse, to the point that nobody wanted to mess with the parser? Unlikely. They're are many Ruby implementations and on top of that rubocop has an independent parser.
- dragonwriter 6y ago
  > They're are many Ruby implementations Not with truly independent parsers; as I understand, most (maybe all) use, either directly or by way of a direct translation, parse.y from MRI. > and on top of that rubocop has an independent parser. Rubocop (or, rather, the parser gem it depends on) seems to have an independent lexer and a parser that is a Bison translation (maybe even mechanical, I'm not sure) of MRIs parse.y.

corytheboyd 6y ago

I am guessing this is exactly why, otherwise why would any sane group of people come up with this idea? And if that's the case... why why WHY even try to do it this way?! Feels like a VERY forced pushing of a square peg into a non-existent hole.

tinco 6y ago
I don't think that's not the reason at all, features are regularly added to ruby with much more complicated consequences for the parser. I would speculate the reason is that it's a very consequential change for the user, and they don't want to commit to it yet. I bet Ruby 4.0 will have optional inline types, if it turns out RBS are as functional as is expected.

sanxiyn 6y ago

I think it is more like .d.ts for TypeScript. Sometimes you do want types in a different file.

shadowfacts 6y ago
Not really, .ts files can have types in the source code. .d.ts lets you type external JS code which is useful for untyped dependencies, as is the case here, I imagine. But within your own project having types be part of the actual declarations is much better.
throwaway189262 6y ago
Those are only used to retrofit types on external libraries that don't have them. All types within project are in the source. .d.ts is a way to add types to source you don't control. Ruby should have gone the path of typescript where .d.ts generation and type stripping is done by a tool you run when you publish your library. That way you can work with types in your code but export it to plain js that others can use with or without tyoings

viraptor 6y ago

> Is this because Ruby is extremely difficult to parse, to the point that nobody wanted to mess with the parser? Unlikely. They're are many Ruby implementations and on top of that rubocop has an independent parser.

dragonwriter 6y ago
> They're are many Ruby implementations Not with truly independent parsers; as I understand, most (maybe all) use, either directly or by way of a direct translation, parse.y from MRI. > and on top of that rubocop has an independent parser. Rubocop (or, rather, the parser gem it depends on) seems to have an independent lexer and a parser that is a Bison translation (maybe even mechanical, I'm not sure) of MRIs parse.y.