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}}
So we could add the information you want to Pragma, and have it be lazy.
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.
> 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
>
>
> > 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
