keyword arguments

[schmurfy]

Hi, I tried to look up informations on this but I can't find anything at all so...

is there a rubinius version with support for keyword arguments currently ? I just tried with the 2.0.0 release but melbourne raises an error with a simple:

def do_something(a: 42)
  p [:toto, a]
end

something(a: 6)

I really wish to try rubinius but I need keyword arguments so I am currently stuck xD

[dbussink]

We don't have keyword arguments yet. We need to port over the new parser and add support for this.

[schmurfy]

thanks for the clarification, I was not sure if there was some option hidden somewhere. Maybe saying that rubinius 2.0 is compatible with ruby 2.1 was a bit premature ;)

[dbussink]

@schmurfy It's our target version, not everything is done though.

[dvdplm]

So the released rubinius 2.0 is actually not even mri 2.0 compatible in this area? As in: named parameters are not supported at all, not only the mri 2.1 changes?

def tst(v1: "val1", v2: "val2", v3: "val3")
  puts "#{v1} #{v2} #{v3}"
end

tst(v3:"new", v2: 1)

The above is a syntax error on rbx 2.0.

[dbussink]

@dvdplm No, like I said we haven't finished porting over the syntax changes.

[dvdplm]

Cool, np, was just wondering if I were missing some command line switch or something.

[vic]

@brixen @dbussink have you seen http://github.com/whitequark/parser, I'd love to experiment on replacing melbourne with parser and see how things go. I know melbourne itself was created due to rubinius and it mostly wraps the mri original code so it's more likely to stick to mri behaviour and corner cases (or intended wtfs), but having whitequark/parser produce a pure-ruby ragel based lexer is by itself interesting to me, along the "less c, more ruby" mantra of rubinius, of course I know the parser is a critical rubinius part and if parser cant produce the AST as fast and correct as melbourne currently does it would be no option.

[dbussink]

@vic Yeah, I know about it. If you want, you can try prototyping that. What we do need to consider is things like compatibility and performance for a final decision on if it would be worth replacing or not. But to know that, we need to prototype it :).

So yeah, personally I'd definitely be interested in that but no guarantees that it will actually end up being used because of now unknown reasons. It's also something that I personally am not that interested in in putting a lot of time in, but if it interests you, please dive in :).

Also note btw, that the parser is only one part. We also will need some VM changes for support keyword arguments well. We should also optimize them well and not use expensive hashes etc. when not necessary.

[igrigorik]

After beating my head against same problem with flags for a while... I agree, declaring Rubinius "2.1.0 compatible", but without keyword args, seems like a pretty big gotcha.

[jc00ke]

"Rubinius 2.0 is expected to be compatible with Ruby 2.1" but since 2.1 hasn't even shipped yet, sounds like we still have time :wink:

[dvdplm]

@jc00ke Saying "Rubinius 2.0 is expected to be compatible with Ruby 2.1" kinda implies it's compatible with mri 2.0 (and it's not). This is not a big deal, just a communications glitch, imo.

[jemc]

This feature is very important to me, and the only thing stopping my team from using Rubinius on a group of projects. I don't have the time to commit to tackling this feature on my own, but I want to form a coalition with some other like-minded users who see this as an important feature and organize to get this done.

I'm also wondering how this feature fits into the plans for Rubinius X... is it a planned feature for that language?

[brixen]

@jemc it's a WIP. It won't be in the next release but I expect it'll be done by the end of the weekend.

[jemc]

@brixen Cool. Then I'll be patient and worry about other things. Thanks for the heads up, and let me know if there's anything I can do to help.

[schmurfy]

any news on this ? I followed rubinius for so long I can't wait to try it out on a real project ^^

[brixen]

@schmurfy I was blocked on fixing a segv in the C-API. Probably won't have keywords done for the "Miami release" but soon thereafter. :)

[schmurfy]

thanks for the inputs, it will be hard but I'll be patient ^^

[schmurfy]

I am not trying to be annoying but... any news on this ?:( I really want to jump in and contribute to this project but I can't do that until my project can at least run on it, I even considered moving back to hash parameters just to be able to run it with rubinius.

[freemanoid]

@schmurfy feel free to ask such question on #rubinius irc.freenode.net

[schmurfy]

I might do that but it would be nice to have an update here so everyone interested can be notified (if there is any update that said).

[yorickpeterse]

Small notes from IRC:

09:13:50 yorickpeterse | morning                                                   
10:10:04 yorickpeterse | So what's the status of keyword arguments?                
10:19:29      dbussink | yorickpeterse: we still need to port over the 2.1 parser  
10:19:35      dbussink | and then implement all the necessary vm constructs        
10:20:02 yorickpeterse | Hm, how much trouble would that be?                       
10:20:11      dbussink | yorickpeterse: quite a bit                                
10:20:16      dbussink | since porting the parser is non trivial                   
10:20:21      dbussink | and the vm additions are as well                          
10:20:26 yorickpeterse | hm                                                        

[schmurfy]

thanks ^^

[diegoviola]

I would love to see this as well.

[schmurfy]

glad to see some movement on this :) I also noticed that referencing an issue in a pull request does not send notifications out :(

[andyl]

How in the world can Rubinius claim to be 2.1 compatible without keyword arguments?

[schmurfy]

rubinius is not currently compatible with even 2.0, the announcements should have been more like this: "rubinius is aiming to be compatible with the latest MRI release and is currently compatible with MRI 1.9"

[andyl]

From the Rubinius blog post in Oct: "Rubinius 2.0 is expected to be compatible with Ruby 2.1."

My $.02 for building loyalty and trust: key messages about software capabilities have to be simple and accurate. Don't make your audience read between the lines. Describe what the product currently does. Don't speculate.

[schmurfy]

is there a way I can help on this ? (I only made one small patch on the ruby side and have no experience on the C++ side of rubinius)

[brixen]

@andyl Rubinius passes 19,305 RubySpecs that pass on MRI 2.1. Keywords are an extremely tiny portion of MRI compatibility, regardless of how important they may be to you. If you have other issues besides known ones like keywords, please open an issue. Even better, check if RubySpecs exist and if they don't, send a PR.

@schmurfy I've got the old parser specs imported to rubinius-melbourne but I need to update them and add keyword specs. Once the specs are ready, I'll work on getting the rest done.

[andyl]

@brixen - citing X number of specs that pass on MRI 2.1 is an obfuscation that forces your audience to parse your words and read between the lines. Rubinius is not 2.1 compatible if all of the language features don't work. To imply otherwise is deceptive communication that will burn new users. There's no shame in 1.9 compatibility. Simple/trustworthy communication will help to build a loyal audience for Rubinius, which I would like to see.

[brixen]

@andyl unfortunately, while I wish it were as simple as you say, it's not. I've been working on RubySpec for a very long time. If there was such a thing as "MRI compatibility" as a definite and explicit point in time, it would have made things a lot easier. Not even MRI knows what feature set defines one of their language versions.

We are compatible with a ton of 2.1 features and more are arriving daily. If you know of something we aren't compatible with, besides keywords, write specs or open an issue. Otherwise, my time is better spent elsewhere than trying to convince you of this reality.

[ollym]

Leaving this out and claiming "2.1 compatibility" is a serious oversight IMHO. I've just been caught out by this and wasted a lot of time upgrading my staging environment only to find I can't run my app without having keyword arguments.

If this is the case then I wonder how many other features have also been omitted....

rbx-2.2.2 :007 > module Foo; refine String do end end

NoMethodError: undefined method `refine' on Foo (Module)
    from kernel/delta/kernel.rb:78:in `refine (method_missing)'

oh dear....

[chuckremes]

It’s doubtful that refinements will ever make it into Rubinius.

On Jan 14, 2014, at 8:45 AM, Oliver Morgan notifications@github.com wrote:

Leaving this out and claiming "2.1 compatibility" is a serious oversight. I wonder how many other features have also been omitted....

rbx-2.2.2 :007 > module Foo; refine String do end end

NoMethodError: undefined method refine' on Foo (Module) from kernel/delta/kernel.rb:78:inrefine (method_missing)' oh dear....

— Reply to this email directly or view it on GitHub.

[yorickpeterse]

I'd say that if one needs refinements there are worse things to worry about than compatibility.

Regardless, keyword arguments are in the making but they're not as easy to add as one might think. They require parser changes, compiler changes as well as virtual machine changes (depending on how they were to be implemented). I am not aware on a particular ETA but based on the recent work done on the compiler by @brixen I doubt it will take that much longer (do not take my word for it though).

The README already contains a list of things that are not currently implemented in Rubinius, I'll add keyword arguments and refinements to that list for the time being.

[dvdplm]

The README already contains a list of things that are not currently implemented in Rubinius, I'll add keyword arguments and refinements to that list for the time being.

@YorickPeterse great initiative!

[schmurfy]

refinements is a hairy subject... I personally don't like them at all and at least I know I am not the only one ;)

[ollym]

@brixen any news on this?

[schmurfy]

seriously... is there something I can do to speed this up ?

I tried to compile rubinius-melbourne but I can't even get the tests to run so I can't do much... (and the issue tracker looks completely dead) I just read the rubinius blog last article and If you want a reason I would port an application to another language, there is a big one : MRI and I am currently stuck on it unfortunately :( As ugly as the language looks go is more and more tempting... :(

I love ruby as a language and I have great hopes with rubinius (at least way more than for MRI), even with limited experience in rubinius itself (I have one or two small commits) I may be of some help but I have no idea what I can do or where to start.

Keyword arguments seem to be considered as completely negligible feature I get that but I still need them and I consider them one of the most useful feature implemented on a syntax level, especially when I think of the crappy way it was done before with hash and all the problems that come with it.

[yorickpeterse]

Keyword arguments are not considered to be negligible in any way. The main reason that this is taking a while is that it's not as trivial as simply running gem install keyword-arguments. To give some indication, the following would have to happen to support this:

1. The lexer/parser would have to be updated according to MRI, this in itself is already a bit tricky as it will need verification to ensure nothing is broken.
2. The Rubinius compiler would have to be updated to be aware of keyword arguments, given you actually want to treat them in a special way (and not just as a Hash).
3. The virtual machine would have to be updated to actually do something with keyword arguments.
4. Possible changes to the JIT might have to be made to make the usage of keyword arguments fast. Having said that, my knowledge of the JIT is limited so this step might not be needed.
5. Specs, specs and more specs. @brixen has been working on updating a lot of specs for Melbourne to make this process easier both now and in the future.

I vaguely recall that the VM in a way already has some foundations available for this, but I'm not 100% sure about this.

In terms of time, progress has been a bit slow due to other issues taking priority (e.g. GC bugs), @brixen relocating across the US and the typical cases of people being busy.

There's current an outstanding pull request that updates Melbourne with keyword argument support, which can be found here https://github.com/rubinius/rubinius-melbourne/pull/5. I'm not sure in what state of completion it is, but work is definitely under way.

Having said that, I'll see if I can poke @brixen to get an update on what needs to be done and if this is something average Joe/Alice can do without requiring super in-depth knowledge of the Rubinius internals (meaning more people could take on the task).

[schmurfy]

thanks for the update :)

[fgarcia]

+1 for keywords arguments

definitely that is the killer feature that holds me back to mri

However it is an amazing how much job is getting done already. Thanks a lot to those coders in the front lines

[wbharding]

Am so close to being able to jump to Rubinius, but this is sort of a deal-breaker for us since named arguments are pretty pervasive in our codebase.

[jockee]

@wbharding +1

[schmurfy]

I hate to sound like a broken record but is there any progression ?

[yorickpeterse]

From my conversations with @brixen he's currently working on it. However, he's also out of the country for a while so I'm not sure about what the ETA would be.

[schmurfy]

If he is working on it that's fine for me :)

[brixen]

@schmurfy yes, progress. Still getting the testing set up correctly with the build tool chain, but it's almost there.

[schmurfy]

thanks for the report, I can't wait to get my hands on it xD

[mhenrixon]

:+1: need this and symbol arrays %i(some symbolic keys)

[funal125]

:+1: