Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for blocks with arbitrary number of arguments #94

Closed
smarr opened this issue Jan 18, 2017 · 5 comments
Closed

Add support for blocks with arbitrary number of arguments #94

smarr opened this issue Jan 18, 2017 · 5 comments
Labels
enhancement Improves the implementation with something noteworthy good first issue Are you trying to have a good at SOMns? Start here! language-design Not everything is in the spec, sometimes, we need to decide what's best.

Comments

@smarr
Copy link
Owner

smarr commented Jan 18, 2017

Currently, we only support blocks with up to two arguments (in addition to self).
So, the best we can do is [:a :b | #foo ] value: 1 with: 3.

Thus, we can't have blocks with 3 or more arguments. The implementation is currently also based on Smalltalk classes Block1, Block2, Block3 with the corresponding interface.

It would be good to lift that restriction and enable blocks with more arguments.
I am not sure what the best way forward is.
I am also not sure whether blocks should support currying or 'culling' (I think that's the term used in Pharo). So, basically the question is whether a block should handle activation with insufficient amount of arguments.

We should look into Newspeak, Pharo, TruffleMate, Grace, etc to see options on how to handle this.

@smarr smarr added enhancement Improves the implementation with something noteworthy good first issue Are you trying to have a good at SOMns? Start here! language-design Not everything is in the spec, sometimes, we need to decide what's best. labels Jan 18, 2017
@smarr
Copy link
Owner Author

smarr commented Jan 18, 2017

A solution should also resolve the problem with issue #21.

@smarr smarr added this to the later milestone Aug 7, 2017
@smarr
Copy link
Owner Author

smarr commented Jan 9, 2018

Think @charig's solution is here: charig/TruffleMATE#31

@smarr
Copy link
Owner Author

smarr commented Feb 14, 2018

@Richard-Roberts Did you see #215? @daumayr already implemented a solution. I just forgot about it. Is this what you need? Will try to look into merging ASAP.

@ghost
Copy link

ghost commented Feb 14, 2018

@smarr This is what would I would have done. It would be good to get this into the dev branch if you have time (no rush though, it's only causing one Grace test to fail for now).

@smarr smarr added this to Open Issues in Completeness Feb 14, 2018
@smarr smarr moved this from Open Issues to In Progress in Completeness Feb 14, 2018
@smarr
Copy link
Owner Author

smarr commented Feb 17, 2018

This is solved with #215.

@smarr smarr closed this as completed Feb 17, 2018
Completeness automation moved this from In Progress to Completed Feb 17, 2018
@smarr smarr modified the milestones: later, v0.6.0 - Black Diamonds Feb 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improves the implementation with something noteworthy good first issue Are you trying to have a good at SOMns? Start here! language-design Not everything is in the spec, sometimes, we need to decide what's best.
Projects
No open projects
Completeness
  
Completed
Development

No branches or pull requests

1 participant