Hi Eliot,
2015-02-08 12:50 GMT-03:00 Eliot Miranda <eliot.mira...@gmail.com>:
> Hi Hernan,
>
>
> On Feb 7, 2015, at 12:55 PM, Hernán Morales Durand <
> hernan.mora...@gmail.com> wrote:
>
> Hi Eliot,
>
> 2015-02-07 14:48 GMT-03:00 Eliot Miranda <eliot.mira...@gmail.com>:
>
>> Hi Hernan,
>>
>> On Sat, Feb 7, 2015 at 7:41 AM, Hernán Morales Durand <
>> hernan.mora...@gmail.com> wrote:
>>
>>>
>>> 2015-02-07 5:59 GMT-03:00 kilon alios <kilon.al...@gmail.com>:
>>>
>>>> Personally I don't like Pragmas, they have not convinced me so far that
>>>> they fit the style of Smalltalk syntax. I have to confess though I never
>>>> liked descriptive elements and languages .
>>>>
>>>>
>>> Me neither. Actually the pragma idea is not wrong per se, it is the tag
>>> syntax to write them which bothers me. Because the world can be described
>>> with tags if you start that path.
>>>
>>
>> How exactly is the syntax wrong?
>>
>
> I am not saying syntax is wrong, I just don't like it because:
>
> 1) Adds another level of representation inside an already reflective
> system.
>
>
> What do you mean exactly? I don't have clear recollection of whether they
> were in Squeak in 08 or if I ported then, but at that time CompiledMethod
> had a properties object, and pragmas were merged into this. What I did do
> was save a lot of space getting rid if the properties object unless a
> method needed it. And IIRC I changed the implementing class from
> MethodProperties to AdditionalMethodState. So there was no additional
> level of representation. a) the syntax was already there fir primitives
> and b) the state was already there in methods.
>
>
The place where pragmas are located internally are not an issue for me. The
fact that special tags are not following the message pattern template is.
It says there is a special collector, parser, validator, etc. a whole
mechanism because something is - supposedly - not easily expressible with
plain reflective messages.
2) It could be done with plain common message sends.
>
>
> No it can't. Common sends are executable and we don't want pragmas
> executed when the method is run, we want the pragma executed when the
> method is added, or analysed. That was what was ugly about the use of plain
> sends in e.f. VMMaker, that there had to be lots of empty implementations
> of the messages used for metadata.
>
> So using normal sends
> - prevents the metadata from being directly executed because executing
> them when the method is run is wrong
> - confuses meta level and normal level, putting them at the same level,
> and hence...
> - confusing for the programmer because its not obvious what's metadata and
> what's a normal send
> - makes analysis harder for the same reason
>
>
We are talking about different worlds here.
Theoretically I could mark methods this way:
(Pragma
for: (ASTBlockClosure >> #value:)
selector: #primitive:
arguments: (Array with: 60)) addPragma.
So the annotations could be written with normal message sends.
And they could be tool supported, so no one gets confused.
> 3) Should be (to me) "hidden" from method pane, and displayed by a
> specific tool inside the system browser.
>
>
> I disagree. I want to see the pragma. It has essential information that
> shouldn't be hidden. I want to edit it easily.
>
I want to see and edit the pragma too, when I am really interested. Just
like with the bytecodes.
> And how can you in the one hand say it can be implemented as a normal
> message send a d at the same time want it hidden? Be consistent :-)
>
>
There is no inconsistency. I am saying they should be hidden from the
method body.
The method pane you see in the browser should be used to send messages to
your modeling domain (which already imposes its own difficulty), not being
exploited to add meta information where meta could belong to
instrumentation analysis (lint, profiling) or UI building (keymap, menu) or
whatever excuse found to add more tags.
I wonder how one could refactor this method:
Greetings>>helloWorld
<year: 2015>
<status: #toDo>
<author: 'Hernán'>
<scope: #private>
<soapOperationName: #HelloWorld>
<soapDocumentation: #'Returns Hello World'>
<soapResult: #String>
<soapStyle: #RPC>
<rmiOperationName: #HelloWorld>
<rmiDocumentation: #'Returns Hello World'>
<rmiResult: #String>
<asn1OperationName: #HelloWorld>
<asn1Documentation: #'Returns Hello World'>
<asn1Result: #UTF8String>
<dcomOperationName: #HelloWorld>
<dcomDocumentation: #'Returns Hello World'>
<dcomResult: #String>
^'Hello World'
>
>> The <literalMessagePattern> syntax predates pragmas. It was used first
>> for numeric primitives in Smalltalk-76 or Smalltalk-80. Squeak extended it
>> with primitive:module:. I and others extended it to include arbitrary
>> literal message patterns. The syntax of a literal message pattern is the
>> syntax of a send with no receiver and only literal arguments.
>>
> The use of this syntax means
>> a) no new syntax
>> b) each pragma is potentially executable
>> c) methods using specific pragmas can be found using "find senders"
>> d) the execution side of a pragma can be found using "find implementors"
>>
>> So what's wrong with that? How is it wrong to use a common Smalltalk
>> object, a Message, that is well-supported in the system, for method
>> metadata?
>>
>>
> I get that pragmas are messages, but they assume an implicit receiver,
> which actually depends on context. If I understood right with pragmas
> always receiver = destination?
>
>
> Not for pragmas that are just labels. And what's destination? In the
> menu building example above the destination"is the menu but the receiver is
> the menu builder. So I think that what the receiver is depends on usage.
>
> If you change things in the communication model (receiver, sender,
> message, etc.), by removing or adding elements, you have a loss in the
> message because it gets harder to reconstruct the message send.
>
>
> I don't understand this. Can you expand?
>
>
Now I realize how far we are from understanding. But I start to feel tired
to write about communication models here.
>
> Consider
>
> <eventRegistration>
> | eventRegistration |
> { eventRegistration }.
> self eventRegistration.
>
> which of them "it sounds like" you cannot infer their purpose?
>
>
> I don't get the example, because of the confusion of meta layers.
>
>
Now you understand me :)
> <eventRegistration>
> says "this is metadata"
>
>
yes, but not what type of metadata is. Is metadata for instrumentation? is
for documentation?
> | eventRegistration |
>
> says "this is a bug in the method because the variable isn't used, and eg
> Opal will remove it so it won't be there".
>
>
but you get this is a local variable supposed to be used in the current
method. You can get the scope easily.
> { eventRegistration }.
> I guess you mean { #eventRegistration }. If so this is the same. An
> optimizing compiler will delete it.
>
>
Yes. The idea there is the same, you would associate the eventRegistration
as an Array element to be accessed in the current method for example.
> self eventRegistration.
> says "send myself eventRegustration". Which /isn't/ what's wanted.
>
> So for me only the pragma implies "this method is to be registered with
> the event system". The middle two say "I am a bug, or syntax error". The
> last one says "I am a normal send".
>
>
To me says "this method contains code which defines an event". Where the
event is defined should need more metadata until explicit semantics are
enough complete.
>
>
> To me the first because you need the context MyClass>>methodName
> and you need to browse the pragma to get its purpose.
>
>
>
>>
>>> There are other ways to add metadata to methods. Without tagging.
>>>
>>
>> Haven't we discussed that? Putting metadata off to the side introduces a
>> bookkeeping problem. It is a bad idea.
>>
>
> Yes, but I still have a lot of doubts about feedback with pragmas (I hope
> you view them as constructive criticism).
>
>
> I'm finding this whole conversation exhausting.
>
>
Me too :(
> Is like pragmas assume there is always a perfect message transaction.
> How can I halt the execution of a specific pragma?
>
>
> By putting a break point in its implementations.
>
> Can I write <myPragma halt>?
>
>
> No. But you can out a conditional breakpoint in CompiledMethod>>pragmaAt:
> or in the pragma's implementation.
>
How do I know if it will get executed?
>
>
> By reading the broader system or adding break pints as just described.
>
> Is <shortcut> a functional pragma?
> How do I distinguis any pragma from being functional or "documentation"?
>
>
> Using "implementors" and "senders" you can find out where it may be used.
> One if the problems of late-bound systems is figuring out what binds to
> what. Pragmas are more difficult to figure out unless pragmas have clearly
> commented implementations.
>
>
It could be broken because I pressed Alt+M in <gtInspectorAction> and
nothing happens:
gtInspectorActionBrowse
<gtInspectorAction>
^ GLMGenericAction new
action: [ self browse ];
icon: GLMUIThemeExtraIcons glamorousBrowse;
title: 'Browse'
>
>
>>
>>
>>> And they don't need to be in the method pane itself.
>>>
>>
>> For some kinds of metadata, for metadata with semantics, not just a
>> documentary function, it is important for the metadata to be obvious.
>>
>
> I think this depends on context. Because your work could be towards
> low-level machinery details or software reenginering, doesn't mean that we
> all need to view compiler directives, functional and structural
> annotations, etc.
>
>
> That's a mischaracterisation. Most of their uses are for pluggable GUIs.
> And if this is so onerous why weren't you protesting <primitive: 123>?
>
>
Pluggable GUIs in systems without GUI builders.
But yes, the same applies to the <primitive: 123> artifact. If we would
have a Primitives Browser, what would be the point of accessing them
through the normal browser?
>
> And if I can write some prediction... When someone invents automatic
> annotation (like happens now with genomes) and decides it will be cool to
> have them in the image (because you will gain performance, more reflective
> capabilitites, etc) methods could explode with pragmas to the point gets to
> be annoying to browse any method. Then the tool will have to be built by
> need.
>
>
>> No one has argued for hiding the primitive specification off-to-the-side.
>> "Need" is a poor criticism here because using turing equivalence lots of
>> things don't "need" to be the way they are. Instead why not ask what are
>> the pros and cons?
>>
>>
> Ok, many of us knows the pros. I have been using pragmas for a while.
> But if we stop discussing then it will never adapt to new ideas.
> So you may want to share your view of cons too :)
>
>
> The cons are that for years, and at length, one has to defend a good idea
> ;-).
>
Ok, I am starting to think pragmas with tags are the best thing possibly
ever created and the final word of evolution in this area ;)
Seriously, I am not saying is a bad idea at all. I say they could be
visualized in other ways.
I cannot believe people accept happily that < ... > is the best way of
representing annotations.
> Pragmas were a new idea and here in thus conversation we see how resistant
> we are to new ideas. I've seen nothing against the need for per-method
> metadata and a lot on how it can be done with other mechanisms. But the
> existing mechanisms don't do one of two things
> - separate normal from meta levels
> - obviously associate metadata with methods.
>
>
I don't have the final answer but I suspect that because we used to see
Smalltlak meta-levels through tools, we also "demand" that new meta-objects
should cope well with our toolset.
> So what I'm missing in this conversation is addressing the issues:
> - how in a componentised loadable system do we decouple component loads
> where components collide in areas like global menu definitions, inspectors,
> etc?
> - how do we associate metadata with methods so that
> - the metadata is of a form that fits well with the host system?
> - the metadata is clearly associated with the method it is data of?
> - the bookkeeping is managed?
>
> You could add good questions here. But these are the questions I was
> thinking of when we added pragmas to VW.
>
>
>
I have more questions about having a controlled vocabulary for metadata and
annotations, and how we could visualize them better. How could we add
meta-annotations and if descriptive declarative programming could be
avoided with sequential OO.
Naturally they could fit as bad questions for anyone.
Cheers,
Hernán
> It is like having to specify protocol because there is no list pane to
>>> create them.
>>>
>>
>> I disagree. When the pragma is specifying type information, specifying
>> that the method is an action on a specific menu, is a pane in an inspector,
>> and many other uses, it is essential that that information be represented,
>> and putting it in a one-off bookkeeping system is a bad idea. We're not
>> talking about simple documentary metadata like author, category etc.
>>
>
> Well, I think documentary metadata is tremendously complex.
>
>
>
>> We're using pragmas for semantics, semantics of the method that are
>> outside of its execution semantics, semantics about how the method fits in
>> the broader system. And putting that in non-obvious places is a bad idea.
>>
>>
> I agree. But obvious could be a place where can be located by a method
> though not necessarily visible.
>
> Cheers,
>
> Hernán
>
>
>
>>
>>>
>>> Hernán
>>>
>>>>
>>>> About python decorators I disagree that are similar to pragmas. Pragmas
>>>> are focused on being descriptive , python decorators are descriptive as by
>>>> product. The main focus of python decorators is to shorten code by
>>>> introducing syntactic sugar.
>>>>
>>>
>> Kilon, pragmas are not limited to being descriptive.
>>
>>
>>>
>>>> I agree though this is a very interesting discussion and I dont
>>>> understand most of the things stated here so I leave an open door and mind
>>>> for pragmas. Maybe one day I will "get it".
>>>>
>>>
>> That would be nice :)
>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> On Sat, Feb 7, 2015 at 10:02 AM, Thierry Goubier <
>>>> thierry.goub...@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> 2015-02-06 22:00 GMT+01:00 stepharo <steph...@free.fr>:
>>>>>
>>>>>> Really interesting discussion. I like pragmas but this is interesting
>>>>>> to see them challenged.
>>>>>>
>>>>>
>>>>> Thanks. It's a pleasure to discuss that way :)
>>>>>
>>>>>
>>>>>> Yes, but there end up being lots of naming conventions and they are
>>>>>>> non-obvious. Whereas pragmas, because they are in-your-face in the
>>>>>>> methods
>>>>>>> in question, don't need conventions. They just need documenting ;-).
>>>>>>>
>>>>>> Thierry I'm skeptical that multiple protocol will save the problem
>>>>>> because you will rely on coding conventions.
>>>>>>
>>>>>
>>>>> Pragma as well: just explain the conventions behind the gtInspector
>>>>> pragmas, for example.
>>>>>
>>>>> But give me multiple protocols and I'll show you the same conventions
>>>>> rewritten in less lines (and a slightly more efficient code).
>>>>>
>>>>>
>>>>>> And pragma is a clever tagging.
>>>>>>
>>>>>
>>>>> Then maybe we should remove protocols and replace them with pragmas :)
>>>>>
>>>>> Thierry
>>>>>
>>>>>
>>>>>>
>>>>>> Stef
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>> best,
>> Eliot
>>
>
>
