[Pharo-users] IS there TypePlug for Pharo or similar type annotation tool?

Peter Uhnák i.uhnak at gmail.com
Fri Oct 2 16:03:42 EDT 2015


On Fri, Oct 2, 2015 at 9:03 PM, Alexandre Bergel <alexandre.bergel at 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.uhnak at 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
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20151002/397cb8b5/attachment.html>


More information about the Pharo-users mailing list