On Fri, Oct 2, 2015 at 9:03 PM, Alexandre Bergel <alexandre.ber...@me.com> wrote:
> Hi Peter! > > I see you are really motivated for having types in Pharo. This is great. > 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 ~~~~~~~~~~~~~~~~~~~ setName(name) { this.name = name; } ~~~~~~~~~~~~~~~~~~~ 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. > > 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 <i.uh...@gmail.com> 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >
