Hi,
Ok, great. I will play with this.
Cheers,
Doru
> On Jul 7, 2016, at 11:19 PM, Eliot Miranda <eliot.mira...@gmail.com> wrote:
>
> Hi Doru,
>
>> On Jun 30, 2016, at 1:08 PM, Tudor Girba <tu...@tudorgirba.com> wrote:
>>
>> 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 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 <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."
--
www.tudorgirba.com
www.feenk.com
"To lead is not to demand things, it is to make them happen."
