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

Allow type assignments #33

Open
jtoman opened this issue Mar 18, 2012 · 12 comments
Open

Allow type assignments #33

jtoman opened this issue Mar 18, 2012 · 12 comments

Comments

@jtoman
Copy link
Member

jtoman commented Mar 18, 2012

Related to #22, we should allow assigning the type of one method to another method. For example, the slice method of the Array object has the exact same type as the [] method. How we should add this to the grammar and parser is up in the air, we could use a syntax like alias slice '[]' or we could use something that looks like OCaml's destructive type assignment: slice := '[]'. Alias is already a keyword in Ruby, so that may be more intuitive to users and it gets my vote.

@jeffrey-s-foster
Copy link
Member

I think there are two cases here:

  1. For base_types.rb, I agree we want something like "type_alias :slice '[]'"
  2. For other classes, we should intercept the alias method and automatically copy over type signatures.

@jtoman
Copy link
Member Author

jtoman commented Mar 18, 2012

Looking at Ruby's parse.y, it appears that alias is actually built into the parser and is not a function call (I'm surprised too...). I don't know how practical it is for us to intercept that, although there may be a hook.

@jtoman
Copy link
Member Author

jtoman commented Mar 18, 2012

I have confirmed that alias is not a method call:

class Foo
  def self.alias(foo,bar)
    p foo,bar
  end
  def foo
  end
  alias :bar :foo
end

The self.alias method is never called.

@jeffrey-s-foster
Copy link
Member

Huh, odd. In any case, we can go with the slightly more awkward "type_alias" for everything, and at some point perhaps get a change made to the language so we can intercept the call.

@jtoman
Copy link
Member Author

jtoman commented Mar 18, 2012

Looking at the old parser, it appears that alias was a keyword. Is there a reason to use type_alias over plain alias?

@jeffrey-s-foster
Copy link
Member

I thought we would do this outside of the parser. So the typesig method would assign type signatures, and then the type_alias method would make aliases. That makes more sense to me than putting it inside the string passed to typesig. What do you think?

@jtoman
Copy link
Member Author

jtoman commented Mar 18, 2012

I think that makes more sense. I would add the rtc_ prefix to it so we completely avoid confusion with the alias method. Do you think the type abbreviations mentioned in #22 should also be a method call?

@jeffrey-s-foster
Copy link
Member

Sure, rtc_alias sounds good. Yes, I think the type abbreviations in #22 should probably also be a method call---it removes an extra layer and simplifies the parser, so it seems like a win.

@jtoman
Copy link
Member Author

jtoman commented Mar 18, 2012

Well, we'll still need to invoke the parser, something will have to parse the type that someone writes, it's just a difference between

rtc_type :my_type,":foo or :bar"
# vs.
typesing("type my_type = :foo or :bar")

@jeffrey-s-foster
Copy link
Member

Right, but with rtc_alias, you don't have to (a) extend the grammar with new "type my_type = ..." productions, and (b) explain to programmers what the new syntax means.

@jtoman
Copy link
Member Author

jtoman commented Mar 18, 2012

I think we're confusing the two issues. Type abbreviations, as mentioned in the ticket, saves people from having to write long complicated types over and over again. Type aliasing allows for assigning the type of one function to another. The discussion of rtc_type above refers to type abbreviations. rtc_alias would require no help from the parser.

@jeffrey-s-foster
Copy link
Member

Sorry, you're right. For type aliases, I think they need to be in the parser, since we might at some point need a bit more complexity with them.

@ghost ghost assigned sstrickl Oct 1, 2012
@sstrickl sstrickl removed their assignment Jan 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants