Hi Doru, > On Jun 30, 2016, at 1:08 PM, Tudor Girba <[email protected]> wrote: > > Hi, > >> On Jun 27, 2016, at 7:55 PM, Eliot Miranda <[email protected]> wrote: >> >> Hi Doru, >> >> On Mon, Jun 27, 2016 at 6:36 AM, Tudor Girba <[email protected]> wrote: >> 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). >> >> Well, there already /is/ a meta-object called Pragma, and it gets >> instantiated when one accesses the compiled method via pragmas: >> >> (CompiledMethod allInstances detect: [:m| m pragmas size > 1]) pragmas >> collect: [:ea| {ea. ea class}] {{<export: true> . Pragma} . {<var: #tablePtr >> type: 'int *'> . Pragma}} > > Yes I know :). An instance of Pragma denotes an concrete annotation of a > method. I now would like a meta-object that describes all Pragma instances > having the same selector. For example, the protocol on the class side of the > Pragma class is actually a query protocol that is better suited for the > instance side of a PragmaDescription meta-object. For example: > > Pragma class>>allNamed: aSymbol in: aClass > > would become > > PragmaDescription>>pragmasIn: aClass > > and you would use it like: > > (PragmaDescription named: aSymbol) pragmasIn: aClass > > Creating an instance of PragmaDescription would imply searching the image for > the <pragma:> definition.
I like this. > I would also like to have a Flyweight pool per environment such that we > always get only one instance of a PragmaDefinition per selector (like it > happens with Symbols). Yes, good refinement. >> So we could add the information you want to Pragma, and have it be lazy. > > It does not quite belong to the Pragma. A comment is common to all Pragma > instances, and having it duplicated at the instance level is less elegant. > > But, looking for the users (all senders of the pragma selector - the methods > that use the annotation) of a Pragma would be even less inconvenient to have > on the instance side of Pragma. > > >> The Pragma could go search for the defining class-side pragma methods and >> use the parser to extract the comment(s) when asked. Hence simple access to >> pragmas, interested only in the selectors for applying, wouldn't have their >> performance be impacted. > > The design sketched above would require no runtime penalty for a Pragma > instance. All code that works now would work identically afterwards. We would > only have one selector in Pragma to get the corresponding description: > > Pragma>>description > ^ PragmaDescription named: self selector > > Alternatively, we could modify the compilation to associate the > PragmaDescription in an inst var of a Pragma instance. So, > CompiledMethod>>pragmas would always return instances of Pragmas with a > PragmaDefinition inst var. > > I think I would start with the lazy lookup first, and this would disturb > nothing from the current behavior. Sounds like a reasonable plan. > > >> 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. >> >> This pseudo-meta-object (Pragma) can sty ill be causally connected, in the >> same way that a MethodReference can be causally connected. The causation is >> things like "remove", "recompile", but that's dubious. It's essentially a >> read-only relationship; one wants to be able to locate the method from the >> pragma, but changing the method from the pragma isn't necessarily a good >> idea. Would you agree that convenience methods like "remove" on >> MethodReference are a bad idea and one should stick to the removeSelector: >> protocol on Behavior and ClassDescription? >> >> >> What do you think? >> >> Have I and enough coffee to scramble my thoughts might be a more pertinent >> question ;-) > > :) > > Cheers, > Doru > > >> >> Cheers, >> Doru >> >> >>> On Jun 27, 2016, at 2:39 PM, Eliot Miranda <[email protected]> wrote: >>> >>> Hi Doru, >>> >>>> On Jun 27, 2016, at 3:52 AM, Tudor Girba <[email protected]> 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 <[email protected]> >>>>> wrote: >>>>> >>>>> >>>>> 2016-06-27 12:12 GMT+02:00 Tudor Girba <[email protected]>: >>>>> 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." >> >> >> >> >> >> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot > > -- > www.tudorgirba.com > www.feenk.com > > "Not knowing how to do something is not an argument for how it cannot be > done." > >
