-
Notifications
You must be signed in to change notification settings - Fork 4
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
Allow for function instantiation #44
Comments
Unfortunately it is not possible to have a Proc or a lambda pass through a block. So you can't do something like this: Proc.new {
|a|
yield a
} This has major implications for our implementation, so any instantiated method could not accept a block. I'll look into ways to work around this. |
It now strikes me as incredibly obvious that we can implement our own "Proc" class that will pass along a block. We would implement the same api, and we may even consider inheriting from Proc so that is_a? and what not continue to work. I will start working on implementing this next. |
Functions can now be instantiated via the rtc_instantiate call on proxy objects. rtc_instantiate takes two arguments, the first is the name of the method, the second is a hash mapping type variables to a string representation of the types to use for those type variables. Blocks *can* be passed to the instantiated methods. The pseudo-proc returned from rtc_instantiate supports call, [], and () from the Proc api, but does not support the other methods, such as arity, parameters, curry, etc. This commit includes a first cut at tests, but more testing is required before I call this feature totally implemented. In addition, in the process of creating this commit, the get_method method of the NominalType was refactored take two paths depending on whether the which is present or not. Partially addresses #44.
It's possible to confuse our type inferencer for polymorphic methods. We should allow code like the following
The text was updated successfully, but these errors were encountered: