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.
2) It could be done with plain common message sends.
3) Should be (to me) "hidden" from method pane, and displayed by a specific
tool inside the system browser.
> 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? 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.
Consider
<eventRegistration>
| eventRegistration |
{ eventRegistration }.
self eventRegistration.
which of them "it sounds like" you cannot infer their purpose?
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).
Is like pragmas assume there is always a perfect message transaction.
How can I halt the execution of a specific pragma? Can I write <myPragma
halt>?
How do I know if it will get executed? Is <shortcut> a functional pragma?
How do I distinguis any pragma from being functional or "documentation"?
>
>
>> 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.
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 :)
>
>> 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
>
