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 <i.uhnak@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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.