IS there TypePlug for Pharo or similar type annotation tool?
Locked
IS there TypePlug for Pharo or similar type annotation tool?
 
|
Hi,
What options do we have in terms of type annotations in Pharo? I stumbled upon TypePlug this https://marcusdenker.de/talks/08ParisTypes/08ParisTypePlug.pdf (or rather this http://scg.unibe.ch/archive/masters/Hald07a.pdf ) which enabled type annotation for Squeak such as ~~~~~~~~~~~~~~~~ Fruit>>mixWith: aFruit <:type: Fruit :> ^ (Array with: self with: aFruit) <:type: Array E: Fruit :> ~~~~~~~~~~~~~~~~ Orange>>color ^ (Color orange) <:type: Color :> ~~~~~~~~~~~~~~~~ (or even blocks) [ :a1 <:type: Integer :> :a2 <:type: Integer :> | a1 + a2 ] ~~~~~~~~~~~~~~~~ obviously something like this wouldn't even compile in Pharo (does Sqeak have different syntax for pragmas, or did the TypePlug change the syntax?) And my question is... is there a port of this, or something similar? I've also found this http://randycoulman.com/blog/2013/02/12/specifying-types-for-smalltalk-fit/ Which is a framework for integrated testing that uses pragmas such as ~~~~~~~~~~~~~~~~ makeBatchWithdrawalOn: aDate note: aString <fitTakes: #(#{Date} #{String})> <fitReturns: #{Fixture}> ^(BatchWithdrawalFixture date: aDate note: aString) systemUnderTest: systemUnderTest ~~~~~~~~~~~~~~~~ Right now I am exploring what options we have in Pharo in terms of type annotations (before writing yet-another-library ;-)). Thanks, Peter |
|
|
Hi Peter!
I see you are really motivated for having types in Pharo. This is great. The email you’ve sent a couple of days ago motivated me for continuing my effort. The two important design points of my implementation are as follow: (A) - Types are specified in the method comment. Consider the following two examples: -=-=-=-=-=-=-=-=-=-=-=-= RBParser class>>parseMethod: aString " :: String -> RBProgramNode “ ... -=-=-=-=-=-=-=-=-=-=-=-= The method parseMethod: accepts a string as argument and return a program node -=-=-=-=-=-=-=-=-=-=-=-= exampleLabelledIf " var b: RTPieBuilder var c: Class “ | b c | … -=-=-=-=-=-=-=-=-=-=-=-= The method exampleLabelledIf defines two temporary variables, b and c. The comment defines the types of these variables (B) - I am still unsure which types system to use. Probably I will use the one of Dart for now. It is easy to implement but it is unsound. I think having a Gradual Type checker for Pharo would be fantastic, but this is seriously more complicated to have. All in all, there is a fair amount of non-trivial theory behind. Does this make sense to you? Cheers, Alexandre > On Oct 2, 2015, at 3:50 PM, Peter Uhnák <[hidden email]> wrote: > > Hi, > > What options do we have in terms of type annotations in Pharo? > > I stumbled upon TypePlug this https://marcusdenker.de/talks/08ParisTypes/08ParisTypePlug.pdf (or rather this http://scg.unibe.ch/archive/masters/Hald07a.pdf ) > > which enabled type annotation for Squeak such as > ~~~~~~~~~~~~~~~~ > Fruit>>mixWith: aFruit <:type: Fruit :> > ^ (Array with: self with: aFruit) <:type: Array E: Fruit :> > ~~~~~~~~~~~~~~~~ > Orange>>color > ^ (Color orange) <:type: Color :> > ~~~~~~~~~~~~~~~~ > (or even blocks) > [ :a1 <:type: Integer :> :a2 <:type: Integer :> | a1 + a2 ] > ~~~~~~~~~~~~~~~~ > > obviously something like this wouldn't even compile in Pharo (does Sqeak have different syntax for pragmas, or did the TypePlug change the syntax?) > > And my question is... is there a port of this, or something similar? > > I've also found this http://randycoulman.com/blog/2013/02/12/specifying-types-for-smalltalk-fit/ > Which is a framework for integrated testing that uses pragmas such as > ~~~~~~~~~~~~~~~~ > makeBatchWithdrawalOn: aDate note: aString > <fitTakes: #(#{Date} #{String})> > <fitReturns: #{Fixture}> > ^(BatchWithdrawalFixture date: aDate note: aString) > systemUnderTest: systemUnderTest > ~~~~~~~~~~~~~~~~ > > Right now I am exploring what options we have in Pharo in terms of type annotations (before writing yet-another-library ;-)). > > Thanks, > Peter -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Re: IS there TypePlug for Pharo or similar type annotation tool?
|
|
On Fri, Oct 2, 2015 at 9:03 PM, Alexandre Bergel <[hidden email]> wrote: Hi Peter! Well my primary motivation is that I need annotated code to be able to do full model reverse-engineering (that of itself is very hard task, however if you work only on constrained models that you've forward-engineered or control, it's significantly simpler). In fact types are not enough because they do not tell things like cardinality and other features of relations between objects, but I will be adding that too, probably in similar fashion to MSE pragmas, since I am already using FAMIX model. (In fact FAMIX already annotates the type of it's own properties with <MSEProperty>.) As for the type of the types... I am not looking for battle-hardened solution, just something good-enough. The benefit of using pragmas over comments is that I don't need to parse them and currently they look better (unlike comment they are nicely colored, instead of a block of text). This would be also fairly easy (it seems) to implement. Now for what you are proposing (A) is basically JavaDoc for Smalltalk; this was already done in other languages such as JavaScript's JSDoc ( https://developers.google.com/closure/compiler/docs/js-for-compiler ) - Google Closure can do static analysis and js transpilation/optimization, php has PHPDoc ( https://en.wikipedia.org/wiki/PHPDoc ) and Ruby also has something similar (RDoc or something). So this is definitely something that is being used at large and is well integrated with today IDEs (so not using it is those languages is actually detrimental). Also this doesn't affect the syntax of the language. (B) I am not familiar with Dart, but it seems similar to what TypeScript does, where I can do either backward compatible with regular javascript ~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~ with specification of a type ~~~~~~~~~~~~~~~~~~~ setName(name: string) { this.name = name; } ~~~~~~~~~~~~~~~~~~~ (in fact PHP can do this too for non-primitives and I believe JavaScript/ECMAScript7 was also supposed to support something like that). This however would require change to the syntax, which I'm not very keen on (and I cannot imagine that anyone would welcome syntax change). Now as I mentioned, right now I'm exploring options that are available; my requirements only overlap of what real solution (whether annotations or gradual types) offer. So maybe I will settle on some custom-hacked pragmas until/if a mature solution emerges. (Pragma annotations are also what I would go for if nothing better comes up). Peter The email you’ve sent a couple of days ago motivated me for continuing my effort. |
|
|
> Well my primary motivation is that I need annotated code to be able to do full model reverse-engineering (that of itself is very hard task, however if you work only on constrained models that you've forward-engineered or control, it's significantly simpler).
> In fact types are not enough because they do not tell things like cardinality and other features of relations between objects, but I will be adding that too, probably in similar fashion to MSE pragmas, since I am already using FAMIX model. (In fact FAMIX already annotates the type of it's own properties with <MSEProperty>.) Oh, okay! This has a radically different purpose than static typing then. There is a bit of work on that. For example google this: "Typing in Model Management” However I am not sure how practical it is. > As for the type of the types... I am not looking for battle-hardened solution, just something good-enough. Yes, but even this is not easy to get. > The benefit of using pragmas over comments is that I don't need to parse them and currently they look better (unlike comment they are nicely colored, instead of a block of text). This would be also fairly easy (it seems) to implement. > > Now for what you are proposing My proposal is actually very close to the optional types of Dart https://www.dartlang.org/articles/optional-types/ I plan to use these types in Pharo to do some static checking, checked execution mode, and providing additional analysis such as code coverage, code completion. I believe this is a very good tradeoff, however it is not sound. Gradual typing is, but it is significantly more complicated to implement I have the impression. > This however would require change to the syntax, which I'm not very keen on (and I cannot imagine that anyone would welcome syntax change). Changing the syntax is a very bad idea. Google GradualTalk to have an idea of what i mean. I played with GradualTalk, it works well on toy examples. However I cannot use it for my projects :-) > > Now as I mentioned, right now I'm exploring options that are available; my requirements only overlap of what real solution (whether annotations or gradual types) offer. So maybe I will settle on some custom-hacked pragmas until/if a mature solution emerges. > (Pragma annotations are also what I would go for if nothing better comes up). If you feel like going toward the annotations, then go for it! I will purpose the type declaration in comments because it fits better my needs. However, it should be quite trivial to bridge our two approaches. Alexandre > > Peter > > The email you’ve sent a couple of days ago motivated me for continuing my effort. > > The two important design points of my implementation are as follow: > (A) - Types are specified in the method comment. Consider the following two examples: > -=-=-=-=-=-=-=-=-=-=-=-= > RBParser class>>parseMethod: aString > " > :: String -> RBProgramNode > “ > ... > -=-=-=-=-=-=-=-=-=-=-=-= > The method parseMethod: accepts a string as argument and return a program node > > -=-=-=-=-=-=-=-=-=-=-=-= > exampleLabelledIf > " > var b: RTPieBuilder > var c: Class > “ > | b c | > … > -=-=-=-=-=-=-=-=-=-=-=-= > The method exampleLabelledIf defines two temporary variables, b and c. The comment defines the types of these variables > > (B) - I am still unsure which types system to use. Probably I will use the one of Dart for now. It is easy to implement but it is unsound. I think having a Gradual Type checker for Pharo would be fantastic, but this is seriously more complicated to have. > > All in all, there is a fair amount of non-trivial theory behind. Does this make sense to you? > > Cheers, > Alexandre > > > > On Oct 2, 2015, at 3:50 PM, Peter Uhnák <[hidden email]> wrote: > > > > Hi, > > > > What options do we have in terms of type annotations in Pharo? > > > > I stumbled upon TypePlug this https://marcusdenker.de/talks/08ParisTypes/08ParisTypePlug.pdf (or rather this http://scg.unibe.ch/archive/masters/Hald07a.pdf ) > > > > which enabled type annotation for Squeak such as > > ~~~~~~~~~~~~~~~~ > > Fruit>>mixWith: aFruit <:type: Fruit :> > > ^ (Array with: self with: aFruit) <:type: Array E: Fruit :> > > ~~~~~~~~~~~~~~~~ > > Orange>>color > > ^ (Color orange) <:type: Color :> > > ~~~~~~~~~~~~~~~~ > > (or even blocks) > > [ :a1 <:type: Integer :> :a2 <:type: Integer :> | a1 + a2 ] > > ~~~~~~~~~~~~~~~~ > > > > obviously something like this wouldn't even compile in Pharo (does Sqeak have different syntax for pragmas, or did the TypePlug change the syntax?) > > > > And my question is... is there a port of this, or something similar? > > > > I've also found this http://randycoulman.com/blog/2013/02/12/specifying-types-for-smalltalk-fit/ > > Which is a framework for integrated testing that uses pragmas such as > > ~~~~~~~~~~~~~~~~ > > makeBatchWithdrawalOn: aDate note: aString > > <fitTakes: #(#{Date} #{String})> > > <fitReturns: #{Fixture}> > > ^(BatchWithdrawalFixture date: aDate note: aString) > > systemUnderTest: systemUnderTest > > ~~~~~~~~~~~~~~~~ > > > > Right now I am exploring what options we have in Pharo in terms of type annotations (before writing yet-another-library ;-)). > > > > Thanks, > > Peter > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Re: IS there TypePlug for Pharo or similar type annotation tool?
|
|
In reply to this post by Peter Uhnak
On 02-10-15 20:50, Peter Uhnák wrote:
> What options do we have in terms of type annotations in Pharo? The only type annotations I've actually used in Pharo is Magritte Stephan |
|
|
In reply to this post by Peter Uhnak
Why do you need that?
Le 2/10/15 20:50, Peter Uhnák a écrit : > Hi, > > What options do we have in terms of type annotations in Pharo? > > I stumbled upon TypePlug this > https://marcusdenker.de/talks/08ParisTypes/08ParisTypePlug.pdf (or > rather this http://scg.unibe.ch/archive/masters/Hald07a.pdf ) > > which enabled type annotation for Squeak such as > ~~~~~~~~~~~~~~~~ > Fruit>>mixWith: aFruit <:type: Fruit :> > ^ (Array with: self with: aFruit) <:type: Array E: Fruit :> > ~~~~~~~~~~~~~~~~ > Orange>>color > ^ (Color orange) <:type: Color :> > ~~~~~~~~~~~~~~~~ > (or even blocks) > [ :a1 <:type: Integer :> :a2 <:type: Integer :> | a1 + a2 ] > ~~~~~~~~~~~~~~~~ > > obviously something like this wouldn't even compile in Pharo (does > Sqeak have different syntax for pragmas, or did the TypePlug change > the syntax?) > > And my question is... is there a port of this, or something similar? > > I've also found this > http://randycoulman.com/blog/2013/02/12/specifying-types-for-smalltalk-fit/ > Which is a framework for integrated testing that uses pragmas such as > ~~~~~~~~~~~~~~~~ > makeBatchWithdrawalOn: aDate note: aString > <fitTakes: #(#{Date} #{String})> > <fitReturns: #{Fixture}> > ^(BatchWithdrawalFixture date: aDate note: aString) > systemUnderTest: systemUnderTest > ~~~~~~~~~~~~~~~~ > > Right now I am exploring what options we have in Pharo in terms of > type annotations (before writing yet-another-library ;-)). > > Thanks, > Peter |
Re: IS there TypePlug for Pharo or similar type annotation tool?
|
|
In reply to this post by Peter Uhnak
This was based on a hacked compiler (using a smack grammar on top of a code generator based on RB Nodes similar to the one we have now in Opal). We changed the grammar to parse these kind of annotations. Marcus |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |