Hi,
> On Jun 27, 2016, at 7:55 PM, Eliot Miranda <eliot.mira...@gmail.com> wrote:
>
> Hi Doru,
>
> On Mon, Jun 27, 2016 at 6:36 AM, Tudor Girba <tu...@tudorgirba.com> 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 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).
> 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.
> 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 <eliot.mira...@gmail.com> wrote:
> >
> > Hi Doru,
> >
> >> On Jun 27, 2016, at 3:52 AM, Tudor Girba <tu...@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 <dionisi...@gmail.com>
> >>> wrote:
> >>>
> >>>
> >>> 2016-06-27 12:12 GMT+02:00 Tudor Girba <tu...@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."
>
>
>
>
>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
--
www.tudorgirba.com
www.feenk.com
"Not knowing how to do something is not an argument for how it cannot be done."
