bluespec.com Forum Index bluespec.com
Bluespec Forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

method formal arguments in Interface definition

 
Post new topic   Reply to topic    bluespec.com Forum Index -> Designing with BSV's Rules, Interfaces, ...
View previous topic :: View next topic  
Author Message
ShepSiegel



Joined: 14 Aug 2007
Posts: 41

PostPosted: Wed Sep 05, 2012 6:08 am    Post subject: method formal arguments in Interface definition Reply with quote

We follow a practice of first defining our module interfaces and then implementing modules that provide them. When it comes time to implement the interface methods, I usually copy them one-by-one from the Interface declaration down to the bottom of the module being implemented.

Code:
interface FooIfc;
  method Bit#(42) yieldData;
endinterface

module mkFoo (FooIfc)
...
  method Bit#(42) yieldData = ...;
endmodule


The BSV-RG is clear in section 5.5 on Interface definition that the return type of the method is optional, as the compiler already knows, and it must exactly match the declaration. Fine, we like to see the return Type for documentation and readability. Yet in some cases, the compiler will complain with an Error (apparently seeing some ambiguity) that is "fixed" by simply eliding the offending method type formal which follows the Type, e.g.

Code:
  method Bit yieldData = ...;  // Always OK
  method Bit#(42) yieldData = ...;   // Sometimes Errors


Why is this?
Back to top
View user's profile Send private message
quark
Site Admin


Joined: 02 Nov 2007
Posts: 500

PostPosted: Wed Sep 05, 2012 8:11 pm    Post subject: Re: method formal arguments in Interface definition Reply with quote

Using "Bit" as the type does not work for me. I get this error:
Code:
Error: "Test2.bsv", line 6, column 11: (T0025)
  The type `Bit' is applied to too few arguments.

From this code:
Code:
interface Ifc;
   method Bit#(42) yieldData();
endinterface

module mkTest(Ifc);
   method Bit yieldData = ?;
endmodule

Do you have an example that you can show where it works?

Also, do you have an example of an error about ambiguity? I'd be interested in fixing any usability issues around that.

Anyway, the answer is that there are known bugs where BSC is too permissive about the types that you are allowed to write. Specifcially, if you don't give types for *everything* in a method declaration, BSC doesn't know what to do with the partial type information; since BSC can only deal will full types or no types, it ignores any partial types. Which means that partial types can be wrong and BSC will not warn or error about it:
Code:
interface Ifc;
   method Bit#(42) yieldData(Bit#(8) x);
endinterface

module mkTest(Ifc);
   method Bool#(17) yieldData(x) = ?;
endmodule

In the above code, not only is the return type wrong, but it makes no sense -- Bool doesn't take an argument. But since there is no type given for the argument "x", BSC ignores all the other types and treats the method as if no type information had been given; so BSC ignores the bogus type. If you put a type on "x", though, then BSC will check all the types, and you'll get an error about "Bool#(17)".

This is a rough edge that we intend to fix. But since it doesn't hinder people from writing designs, it hasn't been a big priority.
Back to top
View user's profile Send private message
patil.nikhil



Joined: 17 Aug 2007
Posts: 69
Location: University of Texas at Austin

PostPosted: Thu Sep 06, 2012 12:09 am    Post subject: Re: method formal arguments in Interface definition Reply with quote

quark wrote:


In the above code, not only is the return type wrong, but it makes no sense -- Bool doesn't take an argument. But since there is no type given for the argument "x", BSC ignores all the other types and treats the method as if no type information had been given; so BSC ignores the bogus type. If you put a type on "x", though, then BSC will check all the types, and you'll get an error about "Bool#(17)".

This is a rough edge that we intend to fix. But since it doesn't hinder people from writing designs, it hasn't been a big priority.


I have been bitten once by this. If memory serves me right, I had forgotten to specify the return type of a local (inside a module) function declaring the function thus:

function funcName(Bool blah, int blah2).

Because of this, other unrelated type-errors weren't making much sense to me until a very long time, when I realized that bluespec was ignoring the type of funcName entirely. I see why it is so much easier to just ignore the "incomplete" type of funcName entirely, but a warning would be nice here. Smile
Back to top
View user's profile Send private message Visit poster's website
patil.nikhil



Joined: 17 Aug 2007
Posts: 69
Location: University of Texas at Austin

PostPosted: Thu Sep 06, 2012 12:44 am    Post subject: Re: method formal arguments in Interface definition Reply with quote

patil.nikhil wrote:
but a warning would be nice here. Smile


On a related note, sometimes I wish bluespec would/could collect statistics about which kinds of errors occur most often and how many successive compiles they take to resolve for each user. Such information could be used to prioritize bugfixes/enhancements for the compiler, or even justify procrastinating on a feature request. Maybe I am naive, but so long as you don't automatically email actual BSV code back to bluespec.com, universities may even be willing to have that feature signed into the license agreement.
Back to top
View user's profile Send private message Visit poster's website
ShepSiegel



Joined: 14 Aug 2007
Posts: 41

PostPosted: Thu Sep 06, 2012 6:14 am    Post subject: Reply with quote

I made up the Bit#(42) yieldData example from memory. We hit this pattern every week or so. But now that we know...

Quote:
Specifcially, if you don't give types for *everything* in a method declaration, BSC doesn't know what to do with the partial type information; since BSC can only deal will full types or no types


... it makes a little more sense. I will post or email "real" examples as we encounter them. They also include the argument Types to Action or ActionValue methods, not just Value methods.

I think we have seen cases were the error was caused by fully specifying the type; and is cleared by (partially) eating away at the Type parametrization details without entirely removing the type.
Back to top
View user's profile Send private message
quark
Site Admin


Joined: 02 Nov 2007
Posts: 500

PostPosted: Thu Sep 06, 2012 4:33 pm    Post subject: Reply with quote

For subinterfaces, you don't give the type:
Code:
interface Ifc;
   interface Reg#(Bool) subifc;
endinterface

module mkMod(Ifc);
   interface Reg subifc;
      method ...
      method ...
   endinterface
endmodule

Here, the "Reg" is not a type, it's the interface name, because BSC is going to create a value from the fields that follow. (The same way that you have to give the name of a struct when creating a struct value. It just happens that the name is also the type.) BSC doesn't need the full type here, so it will give an error if you provide "#(Bool)":
Code:
Error: "TestType.bsv", line 6, column 17: (P0005)
  Unexpected `#'; expected subinterface name

(We could maybe let the syntax be looser and allow users to give the type here, instead of just the interface name.)

For methods, I'm not aware of a situation where removing type arguments will help. I'll certainly welcome any examples.
Back to top
View user's profile Send private message
ShepSiegel



Joined: 14 Aug 2007
Posts: 41

PostPosted: Fri Sep 07, 2012 7:25 am    Post subject: Reply with quote

Ah, I see! I'm nearly certain you just hit this nail on the head. We will check, but I'm pretty sure it would be our ignorance of the difference in the return type of a method vs. the type paramaterizing a subinterface that has been at play here.

Thank you for sharing that vital nugget. -Shep
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    bluespec.com Forum Index -> Designing with BSV's Rules, Interfaces, ... All times are GMT - 4 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum
bluespec.com topic RSS feed 


Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP