June 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Having comments for pragma?

by Tudor Girba

Hi Eliot, I agree with most things you say (except the conclusion :)), and I think that we are talking about complementary issues. As I mentioned before, there already is a need to distinguish between a plain selector and one that is associated with pragmas. This is what you find in PragmaType in Spotter and Inspector. This is a kind of meta-object and having it adds value. I can search for pragmas âtypeâ (we can also call it a PragmaSelector), and I can distinguish between all occurrences of a pragma âtypeâ and its utilization in computation. But, the current implementation of PragmaType is a mere pseudo-meta-object, given that it has no casual connection to the runtime. What we know from Smalltalk is that the analysis model does not have to differ from the runtime one. The consequence is that every time we do see a difference, we should investigate because we might uncover a hidden need opportunity. I know the VW model, and indeed, we could have something like: MyConcept class>>myPragmaDefinition âa comment about the pragma" <pragma: #selector> However, this only deals with the definition of the pragma type not with the internal representation. There could still well be an object that encapsulates both the selector and the comment. And that object would also allow us to build tools around it. We could call it a PragmaType, PragmaDefinition, or even PragmaSelector. And we could get the Pragma to point to this type either through an inst var or through a query (I would probably prefer an instvar). I think that this proposition does not remove from the simplicity of the implementation at all, but allows the new needs to be accommodated nicely. The alternative is to not do anything, in which case we will continue to have an analysis-only-pseudo-meta-object which is not nice at all. I do not think we should jump on this lightly, but I do think we should have a critical look and evaluate the options. What do you think? Cheers, Doru > On Jun 27, 2016, at 2:39 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Doru, > >> On Jun 27, 2016, at 3:52 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> The CompiledMethod already has a way to retrieve Pragma instances: >> >> CompiledMethod>>pragmas. >> >> However, the Pragma instance does not have a meta-object associated with it. So, I would first start from adding that one and linking such a PragmaType to its instances. The important thing here would be that all Pragma instances with a certain selector should reference the same PragmaType. > > Let me express a dissenting opinion. Our pragma system is minimal yet powerful. By using Message instances (with literal arguments) to represent pragmas we get > - executable pragmas that can be applied using perform: or wrappers such as sentTo: > - we can use conventional browsing queries (implementors and senders) to discover which methods are marked by a specific pragma and what pragma-processing tools implement a specific pragma. > - a rich pragma language that can have many, named parameters > - a system which doesn't need its own language, but reuses the existing Smalltalk parsing facilities, and so is easier to learn and to implement > > So its parsimony is an important part of its virtues. It is minimal. > > One thing missing from the Squeak/Pharo implementation is the set of legal pragmas a class accepts. In VisualWorks a class implements the <pragma: #pragma:selector:> (it might be <pragmas: #(pragma:selector:one: pragma:selector:two:)>) to define the legal set of pragmas. [Implementation note, these are /not/ searched for ahead of compilation; instead, the parser delays searching for class-side methods containing pragma: pragmas until it encounters a pragma, and it searches for all class side methods, including in superclasses). > > This scheme allows pragmas to be checked; only pragmas in the set of allowed pragmas are accepted, and it allows collision-free extensibility; any package can add a set of legal pragmas to a class merely by choosing a method selector that won't collide with any other containing pragma: pragmas, eg > kernelPragmas > <pragma: #primitive:> > <pragma: #primitive:error:> > <pragma: #primitive:module:> > <pragma: #primitive:module:error:> > > We're missing this, which means our compilers don't safely check for valid pragmas and can't reject invalid or unrecognized ones, which is error prone. > > If we implemented this then we would have a natural place to comment pragmas in the method that defines a particular pragma, one that would be found using senders. > > None of this requires a meta object. It is perfectly recursive; using itself to implement itself. I find this very elegant (I didn't invent pragma: pragmas; Steve Dahl did, and it's a cool idea). > > So as an inventor of pragmas I'd like to ask for the minimal implementation outlined above. I'd like that we didn't j tricycle a specific meta object, with all the additional tools that implies, and instead stick to the minimalist and parsimony of the original design and use pragmas to comment pragmas. > >> Cheers, >> Doru > > Thanks for reading. > Cheers, Eliot > >>> On Jun 27, 2016, at 12:34 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>> >>> >>> 2016-06-27 12:12 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >>> Hi, >>> >>> That is my proposal as well: introduce a first class entity that describes a Pragma instance. Who would be interested to play with this? >>> >>> How it could be done? >>> Probably compiler could search preferred Pragma class for given selector. And then we will have collection of real pragma instances inside CompiledMethod. What do you think? >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Be rather willing to give than demanding to get." >> >> >> >> >> > -- www.tudorgirba.com www.feenk.com "When people care, great things can happen."

June 27, 2016

Re: [Pharo-dev] Having comments for pragma?

by Eliot Miranda

Hi Doru, > On Jun 27, 2016, at 3:52 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > The CompiledMethod already has a way to retrieve Pragma instances: > > CompiledMethod>>pragmas. > > However, the Pragma instance does not have a meta-object associated with it. So, I would first start from adding that one and linking such a PragmaType to its instances. The important thing here would be that all Pragma instances with a certain selector should reference the same PragmaType. Let me express a dissenting opinion. Our pragma system is minimal yet powerful. By using Message instances (with literal arguments) to represent pragmas we get - executable pragmas that can be applied using perform: or wrappers such as sentTo: - we can use conventional browsing queries (implementors and senders) to discover which methods are marked by a specific pragma and what pragma-processing tools implement a specific pragma. - a rich pragma language that can have many, named parameters - a system which doesn't need its own language, but reuses the existing Smalltalk parsing facilities, and so is easier to learn and to implement So its parsimony is an important part of its virtues. It is minimal. One thing missing from the Squeak/Pharo implementation is the set of legal pragmas a class accepts. In VisualWorks a class implements the <pragma: #pragma:selector:> (it might be <pragmas: #(pragma:selector:one: pragma:selector:two:)>) to define the legal set of pragmas. [Implementation note, these are /not/ searched for ahead of compilation; instead, the parser delays searching for class-side methods containing pragma: pragmas until it encounters a pragma, and it searches for all class side methods, including in superclasses). This scheme allows pragmas to be checked; only pragmas in the set of allowed pragmas are accepted, and it allows collision-free extensibility; any package can add a set of legal pragmas to a class merely by choosing a method selector that won't collide with any other containing pragma: pragmas, eg kernelPragmas <pragma: #primitive:> <pragma: #primitive:error:> <pragma: #primitive:module:> <pragma: #primitive:module:error:> We're missing this, which means our compilers don't safely check for valid pragmas and can't reject invalid or unrecognized ones, which is error prone. If we implemented this then we would have a natural place to comment pragmas in the method that defines a particular pragma, one that would be found using senders. None of this requires a meta object. It is perfectly recursive; using itself to implement itself. I find this very elegant (I didn't invent pragma: pragmas; Steve Dahl did, and it's a cool idea). So as an inventor of pragmas I'd like to ask for the minimal implementation outlined above. I'd like that we didn't j tricycle a specific meta object, with all the additional tools that implies, and instead stick to the minimalist and parsimony of the original design and use pragmas to comment pragmas. > Cheers, > Doru Thanks for reading. Cheers, Eliot >> On Jun 27, 2016, at 12:34 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> >> 2016-06-27 12:12 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >> Hi, >> >> That is my proposal as well: introduce a first class entity that describes a Pragma instance. Who would be interested to play with this? >> >> How it could be done? >> Probably compiler could search preferred Pragma class for given selector. And then we will have collection of real pragma instances inside CompiledMethod. What do you think? > > -- > www.tudorgirba.com > www.feenk.com > > "Be rather willing to give than demanding to get." > > > > >

June 27, 2016

Re: [Pharo-dev] Having comments for pragma?

by Nicolas Passerini

On Mon, Jun 27, 2016 at 1:44 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2016-06-27 13:28 GMT+02:00 Nicolas Passerini <npasserini(a)gmail.com>: > >> That is not quite true, annotations are (kind of) objects but you can not >> put behavior in them, just define attributes and optionally default values >> for those attributes. > > > Ah, you are right. I remember many restrictions was applied to them which > always forced me to hate Java :) > Yep.

June 27, 2016

Re: [Pharo-dev] Having comments for pragma?

by Denis Kudriashov

2016-06-27 13:28 GMT+02:00 Nicolas Passerini <npasserini(a)gmail.com>: > That is not quite true, annotations are (kind of) objects but you can not > put behavior in them, just define attributes and optionally default values > for those attributes. Ah, you are right. I remember many restrictions was applied to them which always forced me to hate Java :)

June 27, 2016

Re: [Pharo-dev] Having comments for pragma?

by Nicolas Passerini

On Mon, Jun 27, 2016 at 10:36 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi. > > In Java annotations are first class objects. You can put behaviour and > state on them. In Smalltalk you can't do this. > > That is not quite true, annotations are (kind of) objects but you can not put behavior in them, just define attributes and optionally default values for those attributes.

June 27, 2016

Re: [Pharo-dev] Having comments for pragma?

by Denis Kudriashov

2016-06-27 12:52 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > The CompiledMethod already has a way to retrieve Pragma instances: > > CompiledMethod>>pragmas. > I know. I mean that we could modify compiler in the way that it will use concrete Pragma class during pragma compilation.

June 27, 2016

Re: [Pharo-dev] Having comments for pragma?

by Tudor Girba

Hi, The CompiledMethod already has a way to retrieve Pragma instances: CompiledMethod>>pragmas. However, the Pragma instance does not have a meta-object associated with it. So, I would first start from adding that one and linking such a PragmaType to its instances. The important thing here would be that all Pragma instances with a certain selector should reference the same PragmaType. Cheers, Doru > On Jun 27, 2016, at 12:34 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-06-27 12:12 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > That is my proposal as well: introduce a first class entity that describes a Pragma instance. Who would be interested to play with this? > > How it could be done? > Probably compiler could search preferred Pragma class for given selector. And then we will have collection of real pragma instances inside CompiledMethod. What do you think? -- www.tudorgirba.com www.feenk.com "Be rather willing to give than demanding to get."

June 27, 2016

Re: [Pharo-dev] Having comments for pragma?

by Denis Kudriashov

2016-06-27 12:12 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > That is my proposal as well: introduce a first class entity that describes > a Pragma instance. Who would be interested to play with this? > How it could be done? Probably compiler could search preferred Pragma class for given selector. And then we will have collection of real pragma instances inside CompiledMethod. What do you think?

June 27, 2016

Re: [Pharo-dev] Having comments for pragma?

by Tudor Girba

Hi, That is my proposal as well: introduce a first class entity that describes a Pragma instance. Who would be interested to play with this? Cheers, Doru > On Jun 27, 2016, at 11:27 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 27 Jun 2016, at 10:36, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> Hi. >> >> In Java annotations are first class objects. You can put behaviour and state on them. In Smalltalk you can't do this. > > thatâs why I was suggesting to make them objects instead simple selectors. but seems that people is scared :) > >> >> 2016-06-26 22:00 GMT+02:00 stepharo <stepharo(a)free.fr>: >> Can be interesting for others: >> >> Java SE 8 allows type annotations anywhere that a type is used. Previously, annotations were only allowed on definitions. >> >> https://blogs.oracle.com/java-platform-group/entry/java_8_s_new_type >> >> >> > -- www.tudorgirba.com www.feenk.com "Quality cannot be an afterthought."

June 27, 2016

Become Identity Forward

by tesonep＠gmail.com

Hello, I'm trying to become forward some objects, these objects are stored in IdentitySets so I need to copy the identityHash of the older objects to the new ones. So that the IdentitySets are still well constructed. I have read the comments in Array >> elementsForwardIdentityTo: copyHash: , and Array >> elementsForwardIdentityTo:, so I realise that the operation I want to use is the first with copyHash in true or the later (that should be doing the same, from the comments). But after trying it, it is not working as expected. If I try with: x := Object new. y := Object new. z := Object new. set := IdentitySet new. set add: x. set add: y. hash := x identityHash. bhash := x basicIdentityHash. self assert:(set isHealthy). z becomeForward: x copyHash: true. set isHealthy "false" z basicIdentityHash = bhash. "false" z identityHash = hash "false" It is not working, but if I changed the copyHash parameter to false, it works. Something is not right (the comment or the implementation), because the comment says: "If copyHash is true, the identityHashes remain with the pointers rather than with the objects so that the objects in the receiver should still be properly indexed in any existing hashed structures after the mutation. If copyHash is false, then the hashes of the objects in otherArray remain unchanged." Do I have understanded everything wrong or there is something that is not working (or at least the comment is not clear) Is somebody using these operations? How do you expect to work? Maybe If you can help me to understand the situation I can fix the comments. Thanks in advance. -- Pablo Tesone. tesonep(a)gmail.com

June 27, 2016