> 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 <[email protected]> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
