Having comments for pragma?
Hi! A pragma may be very obscure. For example, I do: Pragma allInstances anyOne => <debuggerCompleteToSender> If I want to know more about this <debuggerCompleteToSender> is actually quite challenging. I see many methods having that pragma, but not idea what it is for. I see that Halt>>signalerContext and Process>>complete: that use that pragma somehow. But still, I have no idea when I should use that pragma in my method. What about having a way to comment pragma? Maybe something like -=-=-=-=-=-= Object subclass: #Pragma instanceVariableNames: 'method keyword arguments comment' -=-=-=-=-=-= And a simple way to annotate pragmas? Just an idea. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi. Pragmas are selectors hence they're browsable. You can implement a method somewhere with the pragma selector name that includes the documentation. In VW they were careful about that and most, if not all, of their pragmas are carefully commented this way. For example, if you have the pragma <foo> and you implement the method MyClass class >> #foo with some comments in it and you can double click on the pragma <foo> to select its content (foo) and press Cmd+M (or right click implementors) to get to the method having the documentation. On Fri, Jun 24, 2016 at 3:54 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi!
A pragma may be very obscure. For example, I do: Pragma allInstances anyOne => <debuggerCompleteToSender>
If I want to know more about this <debuggerCompleteToSender> is actually quite challenging. I see many methods having that pragma, but not idea what it is for. I see that Halt>>signalerContext and Process>>complete: that use that pragma somehow. But still, I have no idea when I should use that pragma in my method.
What about having a way to comment pragma? Maybe something like -=-=-=-=-=-= Object subclass: #Pragma instanceVariableNames: 'method keyword arguments *comment*' -=-=-=-=-=-=
And a simple way to annotate pragmas? Just an idea.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jun 24, 2016, at 7:55 AM, Clément Bera <bera.clement@gmail.com> wrote:
Hi.
Pragmas are selectors hence they're browsable. You can implement a method somewhere with the pragma selector name that includes the documentation. In VW they were careful about that and most, if not all, of their pragmas are carefully commented this way.
For example, if you have the pragma <foo> and you implement the method MyClass class >> #foo with some comments in it and you can double click on the pragma <foo> to select its content (foo) and press Cmd+M (or right click implementors) to get to the method having the documentation.
+1. I can't stress enough how useful it is to make pragmas real selectors with implementations and to try and apply them using perform:withArguments:. That's when their real power comes in. For example, if you have some method that wants to be added to some tool, make its pragma a message with all the information you need to add it as arguments (things like its position or priority relative to other additions, its name in the list of components, an icon to use, a string for fly-by help) and then implement a builder class whose methods match these pragmas so that when the builder performs the pragma it adds the method to the tool, in a given position, with a given icon and fly-by help etc. In most other systems method annotations are simply that, just passive labels. But in Smalltalk these are executable. You can browse for senders and implementors, you can execute them using a visitor pattern. Much more powerful.
On Fri, Jun 24, 2016 at 3:54 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote: Hi!
A pragma may be very obscure. For example, I do: Pragma allInstances anyOne => <debuggerCompleteToSender>
If I want to know more about this <debuggerCompleteToSender> is actually quite challenging. I see many methods having that pragma, but not idea what it is for. I see that Halt>>signalerContext and Process>>complete: that use that pragma somehow. But still, I have no idea when I should use that pragma in my method.
What about having a way to comment pragma? Maybe something like -=-=-=-=-=-= Object subclass: #Pragma instanceVariableNames: 'method keyword arguments comment' -=-=-=-=-=-=
And a simple way to annotate pragmas? Just an idea.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
+1. I can't stress enough how useful it is to make pragmas real selectors with implementations and to try and apply them using perform:withArguments:. That's when their real power comes in.
For example, if you have some method that wants to be added to some tool, make its pragma a message with all the information you need to add it as arguments (things like its position or priority relative to other additions, its name in the list of components, an icon to use, a string for fly-by help) and then implement a builder class whose methods match these pragmas so that when the builder performs the pragma it adds the method to the tool, in a given position, with a given icon and fly-by help etc.
In most other systems method annotations are simply that, just passive labels. But in Smalltalk these are executable. You can browse for senders and implementors, you can execute them using a visitor pattern. Much more powerful.
Hi eliot For the pragmas paper I read about annotation in Java and from what I learned they are more powerful in Java. They can annotate any language elements and they can also be executed (I have to discuss with a Java expert to get it). Stef
On Sat, Jun 25, 2016 at 8:08 AM, stepharo <stepharo@free.fr> wrote:
+1. I can't stress enough how useful it is to make pragmas real selectors with implementations and to try and apply them using perform:withArguments:. That's when their real power comes in.
For example, if you have some method that wants to be added to some tool, make its pragma a message with all the information you need to add it as arguments (things like its position or priority relative to other additions, its name in the list of components, an icon to use, a string for fly-by help) and then implement a builder class whose methods match these pragmas so that when the builder performs the pragma it adds the method to the tool, in a given position, with a given icon and fly-by help etc.
In most other systems method annotations are simply that, just passive labels. But in Smalltalk these are executable. You can browse for senders and implementors, you can execute them using a visitor pattern. Much more powerful.
Hi eliot
For the pragmas paper I read about annotation in Java and from what I learned they are more powerful in Java. They can annotate any language elements and they can also be executed (I have to discuss with a Java expert to get it).
In Java you *cannot* annotate any language element. You can annotate class, methods, instance variables, method arguments and temporaries and packages. Then when I take an annotation, for example an hibernate annotation: @Entity@Table(name = "EMPLOYEE") In the case of Hibernate, these annotation are for a class and they are used at *runtime* to bind the class instances with database entries (elements of this class are stored in the table EMPLOYEE). Now I've never seen anyone doing that, but as you can access the annotation at runtime, and you can extract from the annotation its name and its parameters (for example you could extract "Table" and "name -> EMPLOYEE". Then, using the Java reflective features, you can do something like: method = obj.getClass().getMethod(methodName, param1.class, param2.class, ..); method.invoke(obj, arg1, arg2,...); And this way you execute a method named "Table", "name" or "EMPLOYEE" with the parameter you want, as you could execute a method from any string matching a method name. We have the same primitive in Pharo on CompiledMethod. I would not say that pragmas are more powerful in Java. Can you give an example of something you can do with the Java annotation that you can't do with Pharo pragmas ? In Slang we use pragma to annotate argument and temporary variables and it works just fine. When you describe in Pharo classes and instance variables using Magritte you can do the same thing as just annotating them. Stef
In Java you *cannot* annotate any language element. You can annotate class, methods, instance variables, method arguments and temporaries and packages.
Then when I take an annotation, for example an hibernate annotation: @Entity @Table(name = "EMPLOYEE") In the case of Hibernate, these annotation are for a class and they are used at *runtime* to bind the class instances with database entries (elements of this class are stored in the table EMPLOYEE).
Now I've never seen anyone doing that, but as you can access the annotation at runtime, and you can extract from the annotation its name and its parameters (for example you could extract "Table" and "name -> EMPLOYEE". Then, using the Java reflective features, you can do something like:
method = obj.getClass().getMethod(methodName, param1.class, param2.class, ..); method.invoke(obj, arg1, arg2,...); And this way you execute a method named "Table", "name" or "EMPLOYEE" with the parameter you want, as you could execute a method from any string matching a method name. We have the same primitive in Pharo on CompiledMethod.
I would not say that pragmas are more powerful in Java. Can you give an example of something you can do with the Java annotation that you can't do with Pharo pragmas ?
Out of a curiosity, how can I annotate class, instance variable, method argument or temporary, or package. How can I annotate the pragma definition itself? How can I retrieve annotations of a pragma definition? I mean, I understand that you can *achieve* same effect, but you *can* achieve it as well with no pragma support at all. Jan
In Slang we use pragma to annotate argument and temporary variables and it works just fine. When you describe in Pharo classes and instance variables using Magritte you can do the same thing as just annotating them.
Stef
On Sat, Jun 25, 2016 at 11:52 AM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
In Java you *cannot* annotate any language element. You can annotate class, methods, instance variables, method arguments and temporaries and packages.
Then when I take an annotation, for example an hibernate annotation:
@Entity@Table(name = "EMPLOYEE")
In the case of Hibernate, these annotation are for a class and they are used at *runtime* to bind the class instances with database entries (elements of this class are stored in the table EMPLOYEE).
Now I've never seen anyone doing that, but as you can access the annotation at runtime, and you can extract from the annotation its name and its parameters (for example you could extract "Table" and "name -> EMPLOYEE". Then, using the Java reflective features, you can do something like:
method = obj.getClass().getMethod(methodName, param1.class, param2.class, ..);
method.invoke(obj, arg1, arg2,...);
And this way you execute a method named "Table", "name" or "EMPLOYEE" with the parameter you want, as you could execute a method from any string matching a method name. We have the same primitive in Pharo on CompiledMethod.
I would not say that pragmas are more powerful in Java. Can you give an example of something you can do with the Java annotation that you can't do with Pharo pragmas ?
Out of a curiosity, how can I annotate class, instance variable, method argument or temporary, or package. How can I annotate the pragma definition itself? How can I retrieve annotations of a pragma definition?
I mean, I understand that you can *achieve* same effect, but you *can* achieve it as well with no pragma support at all.
Agreed. We can do the same thing, but we do it differently.
Jan
In Slang we use pragma to annotate argument and temporary variables and it works just fine. When you describe in Pharo classes and instance variables using Magritte you can do the same thing as just annotating them.
Stef
Annotate a class or an instance variable :-) Alexandre
On Jun 25, 2016, at 3:55 AM, Clément Bera <bera.clement@gmail.com> wrote:
I would not say that pragmas are more powerful in Java. Can you give an example of something you can do with the Java annotation that you can't do with Pharo pragmas ?
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Clement I do not think that we are talking about the same. You are not annotating an AST element. Of course with a convention you can add a method pragma to annotate an source entity that you are the only one to know that it is the right entity. To me this is different. So in the paper I do not want to say that Smalltalk pragmas are equivalent to Java ones because do me they are not. I think that Java annotations are nicely integrated into the language too. And we cannot annotate (the AST element of temp, argument, class def, package and annotations themselves in Smalltalk). I will read more about Java Annotation to be more precise. In Slang we use pragma to annotate argument and temporary variables and it works just fine. Can you give an example on how you annotated it? When you describe in Pharo classes and instance variables using Magritte you can do the same thing as just annotating them. (You see I cannot annotate instance variables directly I can define a method with an annotation that tell me that an instance variable should be interpreted differently.). Stef
https://docs.oracle.com/javase/7/docs/api/java/lang/annotation/ElementType.h... ANNOTATION_TYPE Annotation type declaration CONSTRUCTOR Constructor declaration FIELD Field declaration (includes enum constants) LOCAL_VARIABLE Local variable declaration METHOD Method declaration PACKAGE Package declaration PARAMETER Parameter declaration TYPE Class, interface (including annotation type), or enum declaration Le 26/6/16 à 20:14, stepharo a écrit :
Clement
I do not think that we are talking about the same. You are not annotating an AST element. Of course with a convention you can add a method pragma to annotate an source entity that you are the only one to know that it is the right entity. To me this is different.
So in the paper I do not want to say that Smalltalk pragmas are equivalent to Java ones because do me they are not. I think that Java annotations are nicely integrated into the language too. And we cannot annotate (the AST element of temp, argument, class def, package and annotations themselves in Smalltalk). I will read more about Java Annotation to be more precise.
In Slang we use pragma to annotate argument and temporary variables and it works just fine.
Can you give an example on how you annotated it?
When you describe in Pharo classes and instance variables using Magritte you can do the same thing as just annotating them.
(You see I cannot annotate instance variables directly I can define a method with an annotation that tell me that an instance variable should be interpreted differently.).
Stef
Can be interesting for others: Java SE 8 allows type annotations anywhere that a type is used. Previously, annotations were only allowed on definitions. https://blogs.oracle.com/java-platform-group/entry/java_8_s_new_type
Hi. In Java annotations are first class objects. You can put behaviour and state on them. In Smalltalk you can't do this. 2016-06-26 22:00 GMT+02:00 stepharo <stepharo@free.fr>:
Can be interesting for others:
Java SE 8 allows type annotations anywhere that a type is used. Previously, annotations were only allowed on definitions.
https://blogs.oracle.com/java-platform-group/entry/java_8_s_new_type
On 27 Jun 2016, at 10:36, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi.
In Java annotations are first class objects. You can put behaviour and state on them. In Smalltalk you can't do this.
thatâs why I was suggesting to make them objects instead simple selectors. but seems that people is scared :)
2016-06-26 22:00 GMT+02:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>: Can be interesting for others:
Java SE 8 allows type annotations anywhere that a type is used. Previously, annotations were only allowed on definitions.
https://blogs.oracle.com/java-platform-group/entry/java_8_s_new_type <https://blogs.oracle.com/java-platform-group/entry/java_8_s_new_type>
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? Cheers, Doru
On Jun 27, 2016, at 11:27 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 27 Jun 2016, at 10:36, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi.
In Java annotations are first class objects. You can put behaviour and state on them. In Smalltalk you can't do this.
thatâs why I was suggesting to make them objects instead simple selectors. but seems that people is scared :)
2016-06-26 22:00 GMT+02:00 stepharo <stepharo@free.fr>: Can be interesting for others:
Java SE 8 allows type annotations anywhere that a type is used. Previously, annotations were only allowed on definitions.
https://blogs.oracle.com/java-platform-group/entry/java_8_s_new_type
-- www.tudorgirba.com www.feenk.com "Quality cannot be an afterthought."
2016-06-27 12:12 GMT+02:00 Tudor Girba <tudor@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?
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. Cheers, Doru
On Jun 27, 2016, at 12:34 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-06-27 12:12 GMT+02:00 Tudor Girba <tudor@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."
2016-06-27 12:52 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
The CompiledMethod already has a way to retrieve Pragma instances:
CompiledMethod>>pragmas.
I know. I mean that we could modify compiler in the way that it will use concrete Pragma class during pragma compilation.
Hi Doru,
On Jun 27, 2016, at 3:52 AM, Tudor Girba <tudor@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 <dionisiydk@gmail.com> wrote:
2016-06-27 12:12 GMT+02:00 Tudor Girba <tudor@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."
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). 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. What do you think? Cheers, Doru
On Jun 27, 2016, at 2:39 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Doru,
On Jun 27, 2016, at 3:52 AM, Tudor Girba <tudor@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 <dionisiydk@gmail.com> wrote:
2016-06-27 12:12 GMT+02:00 Tudor Girba <tudor@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."
Hi Doru, On Mon, Jun 27, 2016 at 6:36 AM, Tudor Girba <tudor@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}} 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 <eliot.miranda@gmail.com> wrote:
Hi Doru,
On Jun 27, 2016, at 3:52 AM, Tudor Girba <tudor@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 <dionisiydk@gmail.com> wrote:
2016-06-27 12:12 GMT+02:00 Tudor Girba <tudor@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
Hi Eliot, I will get back to this email after tomorrow. I need a bit of time to put an answer together. Cheers, Doru
On Jun 27, 2016, at 7:55 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Doru,
On Mon, Jun 27, 2016 at 6:36 AM, Tudor Girba <tudor@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}}
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 <eliot.miranda@gmail.com> wrote:
Hi Doru,
On Jun 27, 2016, at 3:52 AM, Tudor Girba <tudor@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 <dionisiydk@gmail.com> wrote:
2016-06-27 12:12 GMT+02:00 Tudor Girba <tudor@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 "What is more important: To be happy, or to make happy?"
Hi,
On Jun 27, 2016, at 7:55 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Doru,
On Mon, Jun 27, 2016 at 6:36 AM, Tudor Girba <tudor@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.miranda@gmail.com> wrote:
Hi Doru,
On Jun 27, 2016, at 3:52 AM, Tudor Girba <tudor@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 <dionisiydk@gmail.com> wrote:
2016-06-27 12:12 GMT+02:00 Tudor Girba <tudor@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."
Hi Doru,
On Jun 30, 2016, at 1:08 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On Jun 27, 2016, at 7:55 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Doru,
On Mon, Jun 27, 2016 at 6:36 AM, Tudor Girba <tudor@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.miranda@gmail.com> wrote:
Hi Doru,
On Jun 27, 2016, at 3:52 AM, Tudor Girba <tudor@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 <dionisiydk@gmail.com> wrote:
2016-06-27 12:12 GMT+02:00 Tudor Girba <tudor@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."
Hi, Ok, great. I will play with this. Cheers, Doru
On Jul 7, 2016, at 11:19 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Doru,
On Jun 30, 2016, at 1:08 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On Jun 27, 2016, at 7:55 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Doru,
On Mon, Jun 27, 2016 at 6:36 AM, Tudor Girba <tudor@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.miranda@gmail.com> wrote:
Hi Doru,
On Jun 27, 2016, at 3:52 AM, Tudor Girba <tudor@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 <dionisiydk@gmail.com> wrote:
2016-06-27 12:12 GMT+02:00 Tudor Girba <tudor@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."
Tudor Girba-2 wrote
Hi,
On Jun 27, 2016, at 7:55 PM, Eliot Miranda <
eliot.miranda@
> wrote:
Hi Doru,
On Mon, Jun 27, 2016 at 6:36 AM, Tudor Girba <
tudor@
> 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
I am concerned with this proposal. Effectively, it says only one person/package can ever define a pragma selector. It would interfere with two completely independent developers from using <pragma: #foo> for their own work. I think it would be better to expand on <pragma:...> to be able to declare the symbol, the Pragma class, the comment, etc. which would create the meta instance you desire, but without closing off independent work. The the expression /PragmaDescription for: #foo/ would answer a collection of PragmaDescriptions (0 or more). Other methods in the API could be used to answer the one and only or throw an error if not exactly one, and so on. [I know of no way that the individual description could find /just/ its corresponding <foo> uses. Conversely, I know of no way that the compiler could reliably determine that a method with <foo> was referring to the pragma from one declaration versus another. But, I think that is less a problem than forcing a "Highlander" implementation.]
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.miranda@
> wrote:
Hi Doru,
On Jun 27, 2016, at 3:52 AM, Tudor Girba <
tudor@
> 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 <
dionisiydk@
> wrote:
2016-06-27 12:12 GMT+02:00 Tudor Girba <
tudor@
>:
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."
-- View this message in context: http://forum.world.st/Having-comments-for-pragma-tp4902987p4905621.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Mon, Jun 27, 2016 at 10:36 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi.
In Java annotations are first class objects. You can put behaviour and state on them. In Smalltalk you can't do this.
That is not quite true, annotations are (kind of) objects but you can not put behavior in them, just define attributes and optionally default values for those attributes.
2016-06-27 13:28 GMT+02:00 Nicolas Passerini <npasserini@gmail.com>:
That is not quite true, annotations are (kind of) objects but you can not put behavior in them, just define attributes and optionally default values for those attributes.
Ah, you are right. I remember many restrictions was applied to them which always forced me to hate Java :)
On Mon, Jun 27, 2016 at 1:44 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-06-27 13:28 GMT+02:00 Nicolas Passerini <npasserini@gmail.com>:
That is not quite true, annotations are (kind of) objects but you can not put behavior in them, just define attributes and optionally default values for those attributes.
Ah, you are right. I remember many restrictions was applied to them which always forced me to hate Java :)
Yep.
On Mon, Jun 27, 2016 at 1:09 PM, Nicolas Passerini <npasserini@gmail.com> wrote:
On Mon, Jun 27, 2016 at 1:44 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-06-27 13:28 GMT+02:00 Nicolas Passerini <npasserini@gmail.com>:
That is not quite true, annotations are (kind of) objects but you can not put behavior in them, just define attributes and optionally default values for those attributes.
Ah, you are right. I remember many restrictions was applied to them which always forced me to hate Java :)
Yep.
Well, there's a reason why they're restricted. Note, that the restriction is on language level, not at runtime level. A annotation class with arbitrary code would pass JVM verification (or at least I can't see a rule that would reject such a class). When I implemented annotation support I was initially thinking the same - let's create an instance of CoolAnnotationClass when the code is accepted and then one can add arbitrary code to his CoolAnnotationClass. I quickly realized this is a (very) bad idea. Or, to be precise, it is a bad idea given the environment. So I'd be very careful.. Jan P.S.: As for "which always forced me to hate Java": I found myself a very enlightening to think carefully about why somebody else do things differently before I start to hate her/him. Besides, there's whole lot of things that Java guys got right...
Following this "bad idea" we should agree that smalltalk metaclass system is horrible and class should be just a language artifact 28 иÑÐ½Ñ 2016 г. 11:45 полÑзоваÑÐµÐ»Ñ "Jan Vrany" <jan.vrany@fit.cvut.cz> напиÑал:
On Mon, Jun 27, 2016 at 1:09 PM, Nicolas Passerini <npasserini@gmail.com> wrote:
On Mon, Jun 27, 2016 at 1:44 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-06-27 13:28 GMT+02:00 Nicolas Passerini <npasserini@gmail.com>:
That is not quite true, annotations are (kind of) objects but you can not put behavior in them, just define attributes and optionally default values for those attributes.
Ah, you are right. I remember many restrictions was applied to them which always forced me to hate Java :)
Yep.
Well, there's a reason why they're restricted. Note, that the restriction is on language level, not at runtime level. A annotation class with arbitrary code would pass JVM verification (or at least I can't see a rule that would reject such a class).
When I implemented annotation support I was initially thinking the same - let's create an instance of CoolAnnotationClass when the code is accepted and then one can add arbitrary code to his CoolAnnotationClass. I quickly realized this is a (very) bad idea. Or, to be precise, it is a bad idea given the environment. So I'd be very careful..
Jan
P.S.: As for "which always forced me to hate Java": I found myself a very enlightening to think carefully about why somebody else do things differently before I start to hate her/him. Besides, there's whole lot of things that Java guys got right...
On Jun 28, 2016, at 8:17 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Following this "bad idea" we should agree that smalltalk metaclass system is horrible and class should be just a language artifact
Are you being serious or sarcastic?
28 иÑÐ½Ñ 2016 г. 11:45 полÑзоваÑÐµÐ»Ñ "Jan Vrany" <jan.vrany@fit.cvut.cz> напиÑал:
On Mon, Jun 27, 2016 at 1:09 PM, Nicolas Passerini <npasserini@gmail.com> wrote:
On Mon, Jun 27, 2016 at 1:44 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-06-27 13:28 GMT+02:00 Nicolas Passerini <npasserini@gmail.com>:
That is not quite true, annotations are (kind of) objects but you can not put behavior in them, just define attributes and optionally default values for those attributes.
Ah, you are right. I remember many restrictions was applied to them which always forced me to hate Java :)
Yep.
Well, there's a reason why they're restricted. Note, that the restriction is on language level, not at runtime level. A annotation class with arbitrary code would pass JVM verification (or at least I can't see a rule that would reject such a class).
When I implemented annotation support I was initially thinking the same - let's create an instance of CoolAnnotationClass when the code is accepted and then one can add arbitrary code to his CoolAnnotationClass. I quickly realized this is a (very) bad idea. Or, to be precise, it is a bad idea given the environment. So I'd be very careful..
Jan
P.S.: As for "which always forced me to hate Java": I found myself a very enlightening to think carefully about why somebody else do things differently before I start to hate her/him. Besides, there's whole lot of things that Java guys got right...
Sarcasm never really works on mailing lists :) Doru
On Jun 28, 2016, at 6:02 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Jun 28, 2016, at 8:17 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Following this "bad idea" we should agree that smalltalk metaclass system is horrible and class should be just a language artifact
Are you being serious or sarcastic?
28 иÑÐ½Ñ 2016 г. 11:45 полÑзоваÑÐµÐ»Ñ "Jan Vrany" <jan.vrany@fit.cvut.cz> напиÑал:
On Mon, Jun 27, 2016 at 1:09 PM, Nicolas Passerini <npasserini@gmail.com> wrote:
On Mon, Jun 27, 2016 at 1:44 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-06-27 13:28 GMT+02:00 Nicolas Passerini <npasserini@gmail.com>: That is not quite true, annotations are (kind of) objects but you can not put behavior in them, just define attributes and optionally default values for those attributes.
Ah, you are right. I remember many restrictions was applied to them which always forced me to hate Java :)
Yep.
Well, there's a reason why they're restricted. Note, that the restriction is on language level, not at runtime level. A annotation class with arbitrary code would pass JVM verification (or at least I can't see a rule that would reject such a class).
When I implemented annotation support I was initially thinking the same - let's create an instance of CoolAnnotationClass when the code is accepted and then one can add arbitrary code to his CoolAnnotationClass. I quickly realized this is a (very) bad idea. Or, to be precise, it is a bad idea given the environment. So I'd be very careful..
Jan
P.S.: As for "which always forced me to hate Java": I found myself a very enlightening to think carefully about why somebody else do things differently before I start to hate her/him. Besides, there's whole lot of things that Java guys got right...
-- www.tudorgirba.com www.feenk.com "When people care, great things can happen."
Hi Eliot. || Are you being serious or sarcastic? I was sarcastics. Please don't kill me. I just too much hate java. I worked on it to much :)) 28 иÑÐ½Ñ 2016 г. 18:05 полÑзоваÑÐµÐ»Ñ "Eliot Miranda" <eliot.miranda@gmail.com> напиÑал:
On Jun 28, 2016, at 8:17 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Following this "bad idea" we should agree that smalltalk metaclass system is horrible and class should be just a language artifact
Are you being serious or sarcastic?
28 иÑÐ½Ñ 2016 г. 11:45 полÑзоваÑÐµÐ»Ñ "Jan Vrany" <jan.vrany@fit.cvut.cz> напиÑал:
On Mon, Jun 27, 2016 at 1:09 PM, Nicolas Passerini <npasserini@gmail.com> wrote:
On Mon, Jun 27, 2016 at 1:44 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-06-27 13:28 GMT+02:00 Nicolas Passerini <npasserini@gmail.com>:
That is not quite true, annotations are (kind of) objects but you can not put behavior in them, just define attributes and optionally default values for those attributes.
Ah, you are right. I remember many restrictions was applied to them which always forced me to hate Java :)
Yep.
Well, there's a reason why they're restricted. Note, that the restriction is on language level, not at runtime level. A annotation class with arbitrary code would pass JVM verification (or at least I can't see a rule that would reject such a class).
When I implemented annotation support I was initially thinking the same - let's create an instance of CoolAnnotationClass when the code is accepted and then one can add arbitrary code to his CoolAnnotationClass. I quickly realized this is a (very) bad idea. Or, to be precise, it is a bad idea given the environment. So I'd be very careful..
Jan
P.S.: As for "which always forced me to hate Java": I found myself a very enlightening to think carefully about why somebody else do things differently before I start to hate her/him. Besides, there's whole lot of things that Java guys got right...
On Jun 28, 2016, at 5:30 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi Eliot. || Are you being serious or sarcastic? I was sarcastics. Please don't kill me. I just too much hate java. I worked on it to much :))
:)
28 иÑÐ½Ñ 2016 г. 18:05 полÑзоваÑÐµÐ»Ñ "Eliot Miranda" <eliot.miranda@gmail.com> напиÑал:
On Jun 28, 2016, at 8:17 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Following this "bad idea" we should agree that smalltalk metaclass system is horrible and class should be just a language artifact
Are you being serious or sarcastic?
28 иÑÐ½Ñ 2016 г. 11:45 полÑзоваÑÐµÐ»Ñ "Jan Vrany" <jan.vrany@fit.cvut.cz> напиÑал:
On Mon, Jun 27, 2016 at 1:09 PM, Nicolas Passerini <npasserini@gmail.com> wrote:
On Mon, Jun 27, 2016 at 1:44 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-06-27 13:28 GMT+02:00 Nicolas Passerini <npasserini@gmail.com>:
That is not quite true, annotations are (kind of) objects but you can not put behavior in them, just define attributes and optionally default values for those attributes.
Ah, you are right. I remember many restrictions was applied to them which always forced me to hate Java :)
Yep.
Well, there's a reason why they're restricted. Note, that the restriction is on language level, not at runtime level. A annotation class with arbitrary code would pass JVM verification (or at least I can't see a rule that would reject such a class).
When I implemented annotation support I was initially thinking the same - let's create an instance of CoolAnnotationClass when the code is accepted and then one can add arbitrary code to his CoolAnnotationClass. I quickly realized this is a (very) bad idea. Or, to be precise, it is a bad idea given the environment. So I'd be very careful..
Jan
P.S.: As for "which always forced me to hate Java": I found myself a very enlightening to think carefully about why somebody else do things differently before I start to hate her/him. Besides, there's whole lot of things that Java guys got right...
When I implemented annotation support I was initially thinking the same - let's create an instance of CoolAnnotationClass when the code is accepted and then one can add arbitrary code to his CoolAnnotationClass. I quickly realized this is a (very) bad idea. Or, to be precise, it is a bad idea given the environment. So I'd be very careful.. can you explain your statement?
Stef
Jan
P.S.: As for "which always forced me to hate Java": I found myself a very enlightening to think carefully about why somebody else do things differently before I start to hate her/him. Besides, there's whole lot of things that Java guys got right...
On Tue, Jun 28, 2016 at 8:53 PM, stepharo <stepharo@free.fr> wrote:
When I implemented annotation support I was initially thinking the same - let's create an instance of CoolAnnotationClass when the code is accepted and then one can add arbitrary code to his CoolAnnotationClass. I quickly realized this is a (very) bad idea. Or, to be precise, it is a bad idea given the environment. So I'd be very careful.. can you explain your statement?
Let me try, this is tricky for me as I'm not good at explaining :-) The problems pop out when one need to load the code back. If <coolish: 100> gets parsed and stored in an annotation container as instance of class Coolish (at compilation time), this means that you just introduced a dependency from package of the method which contains the annotation to the package of Coolish class. This is not (or rather was not in my case) desirable, because I need/want to annotate methods in kernel with annotations for tools. Kernel should not depend or tools - I believe we agree on that :-) Note, that this is less of a problem for Java since Java loads all code lazily, on demand and in a defined way. I personally found it very nice - though it has some (solvable?) issues when this lazy loading is used in Smalltalkish environment such as STX:LIBJAVA) You can indeed parse them and store them as raw data and convert them on demand in reflective API. Then, if the class is not available what to do? Return an instance of generic Pragma? Throw an error? When one starts to put an arbitrary code into the annotation object itself it's either processing code only access data or it somehow fiddles about the annotation itself and/or (worse!) about the method itself. The latter results in difficult to debug problems as the time the code is executed is undefined (if you use lazy instantiation to avoid dependency problem). This may be fine with most Smalltalkers as there are other pieces of code that execute randomly in an undefined order and still very few complain :-) but I did not want to make things even worse. For the former, mere data-accessing processing code, I don't see much of a difference by putting it somwhere else. Follows the same logic as visitor, instead of putting code to nodes, you put them to extra visitor class. Eliot's design elegantly avoid these problems (the same way Java does :-) by simply having one defined structure which keeps the logical type of the annotation as data (the selector of the message send). It has other problems, but not the one above. Not sure if it makes sense, but I did my best :-) I'm not saying it's not solvable and you cannot have class per annotation type, but it is not **that** easy to get it right. This is my experience over the years. HTH, Jan
Stef
Jan
P.S.: As for "which always forced me to hate Java": I found myself a very enlightening to think carefully about why somebody else do things differently before I start to hate her/him. Besides, there's whole lot of things that Java guys got right...
Stef, all, the post below was written by me, not by Stef as it looks. Due to some funny bug, my email client messed up with headers when I saved unfinished mail to "Drafts" and then come back to it later. Time to change email client. I'm very sorry for the confusion this caused. Jan On Wed, 2016-06-29 at 11:21 +0100, stepharo wrote:
On Tue, Jun 28, 2016 at 8:53 PM, stepharo <stepharo@free.fr> wrote:
When I implemented annotation support I was initially thinking the same - let's create an instance of CoolAnnotationClass when the code is accepted and then one can add arbitrary code to his CoolAnnotationClass. I quickly realized this is a (very) bad idea. Or, to be precise, it is a bad idea given the environment. So I'd be very careful.. can you explain your statement?
Let me try, this is tricky for me as I'm not good at explaining :-)Â
The problems pop out when one need to load the code back. If <coolish: 100> gets parsed and stored in an annotation container as instance of class Coolish (at compilation time),  this means that you just introduced a dependency from package of the method which contains the annotation to the package of Coolish class. This is not (or rather was not in my case) desirable, because I need/want to annotate methods in kernel with annotations for tools. Kernel should not depend or tools - I believe we agree on that :-) Note, that this is less of a problem for Java since Java loads all code lazily, on demand and in a defined way. I personally found it very nice  - though it has some (solvable?) issues when this lazy loading is used in Smalltalkish environment such as STX:LIBJAVA)
You can indeed parse them and store them as raw data and convert them on demand in reflective API. Then, if the class is not available what to do? Return an instance of generic Pragma? Throw an error? When one starts to put an arbitrary code into the annotation object itself it's either processing  code only access data  or it somehow fiddles about the annotation itself and/or (worse!) about the method itself. The latter results in difficult to debug problems as the time the code is executed is undefined (if you use lazy instantiation to avoid dependency problem). This may be fine with most Smalltalkers as there are other pieces of code that execute randomly in an undefined order and still very few complain :-) but I did not want to make things even worse. For the former, mere data-accessing processing code, I don't see much of a difference by putting it somwhere else. Follows the same logic as visitor, instead of putting code to nodes, you put them to extra visitor class.Â
Eliot's design elegantly avoid these problems (the same way Java does :-) by simply having one defined structure which keeps the logical type of the annotation as data (the selector of the message send). It has other problems, but not the one above.Â
Not sure if it makes sense, but I did my best :-) I'm not saying it's not solvable and you cannot have class per annotation type, but it is not **that** easy to get it right. This is my experience over the years.Â
HTH, Jan
Stef
Jan
P.S.: As for "which always forced me to hate Java": I found myself a very enlightening to think carefully about why somebody else do things differently before I start to hate her/him. Besides, there's whole lot of things that Java guys got right...
On Fri, Jun 24, 2016 at 10:55 PM, Clément Bera <bera.clement@gmail.com> wrote:
Hi.
Pragmas are selectors hence they're browsable. You can implement a method somewhere with the pragma selector name that includes the documentation. In VW they were careful about that and most, if not all, of their pragmas are carefully commented this way.
Should this be concentrated in a class like PragmaDocumentation, or spread out (I don't know how). cheers -ben
For example, if you have the pragma <foo> and you implement the method MyClass class >> #foo with some comments in it and you can double click on the pragma <foo> to select its content (foo) and press Cmd+M (or right click implementors) to get to the method having the documentation.
On Fri, Jun 24, 2016 at 3:54 PM, Alexandre Bergel <alexandre.bergel@me.com
wrote:
Hi!
A pragma may be very obscure. For example, I do: Pragma allInstances anyOne => <debuggerCompleteToSender>
If I want to know more about this <debuggerCompleteToSender> is actually quite challenging. I see many methods having that pragma, but not idea what it is for. I see that Halt>>signalerContext and Process>>complete: that use that pragma somehow. But still, I have no idea when I should use that pragma in my method.
What about having a way to comment pragma? Maybe something like -=-=-=-=-=-= Object subclass: #Pragma instanceVariableNames: 'method keyword arguments *comment*' -=-=-=-=-=-=
And a simple way to annotate pragmas? Just an idea.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Ben Coman wrote
On Fri, Jun 24, 2016 at 10:55 PM, Clément Bera <
bera.clement@
> wrote:
Hi.
Pragmas are selectors hence they're browsable. You can implement a method somewhere with the pragma selector name that includes the documentation. In VW they were careful about that and most, if not all, of their pragmas are carefully commented this way.
Should this be concentrated in a class like PragmaDocumentation, or spread out (I don't know how).
Since pragmas are an open set and can be added by any package, concentrating them in one place doesn't sound like a good idea. The best place to have the comments is with the code. If the pragmas name real selectors, comment the implementation. If the pragmas are merely tags, comment the method that declares them as pragmas (e.g. VisualWorks requires you to declare the symbols as pragmas before using them). Examples: SUnit.TestCase class>>#testMethodTags declares a couple of pragma selectors for instance methods. testMethodTags "Any method tagged with a <test> pragma is considered a test selector candidate" "<uses:> tags are used to compute instance specific resources for the tagged test. The argument is a symbol for the class name, or a binding reference to the same." <pragmas: #instance> ^#(#test #uses:) SUnit.TestCase class>>#testResourceTags declares a class method pragma for resources. testResourceTags "<resource:> tags are used to compute instance specific resources for the tagged test. The argument is a symbol for the class name, or a binding reference to the same." <pragmas: #class> ^#(#resource) ApplicationModel class>>menuMethodPragmas declares a whole slew of selectors for menus. But it neglects to provide comments in it or in the list of selectors in the Menu class. menuMethodPragmas <pragmas: #instance> <pragmas: #class> ^Menu pragmas However, VW does comment the actual methods: computedSubmenu: label nameKey: key menu: menuIDs position: position "This pragma expects the body of the method marked with it to answer a Menu that will be used as a submenu with the label and position specified by the pragma."
cheers -ben
For example, if you have the pragma <foo> and you implement the method MyClass class >> #foo with some comments in it and you can double click on the pragma <foo> to select its content (foo) and press Cmd+M (or right click implementors) to get to the method having the documentation.
On Fri, Jun 24, 2016 at 3:54 PM, Alexandre Bergel <
alexandre.bergel@
> > wrote:
Hi!
A pragma may be very obscure. For example, I do: Pragma allInstances anyOne =>
<debuggerCompleteToSender>
If I want to know more about this
<debuggerCompleteToSender> is actually
quite challenging. I see many methods having that pragma, but not idea what it is for. I see that Halt>>signalerContext and Process>>complete: that use that pragma somehow. But still, I have no idea when I should use that pragma in my method.
What about having a way to comment pragma? Maybe something like -=-=-=-=-=-= Object subclass: #Pragma instanceVariableNames: 'method keyword arguments *comment*' -=-=-=-=-=-=
And a simple way to annotate pragmas? Just an idea.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- View this message in context: http://forum.world.st/Having-comments-for-pragma-tp4902987p4903138.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hi, I believe we are missing a first class entity for a PragmaType. Essentially, I think that the class side of the Pragma class should become a full object. In fact, we already have a rudimentary version of this in Spotter because we needed an object to be able to browse all definitions of a certain pragma. So, now, I extended it with the concept of a user which is the list of all senders minus the methods that are annotated with a pragma. This helps distinguish the meaning of a pragma by looking at the code where it is being used. Perhaps we can find a better name than users. You can see these users in the inspector and in spotter: I think we should build on this. What do you think? Cheers, Doru
On Jun 24, 2016, at 3:54 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi!
A pragma may be very obscure. For example, I do: Pragma allInstances anyOne => <debuggerCompleteToSender>
If I want to know more about this <debuggerCompleteToSender> is actually quite challenging. I see many methods having that pragma, but not idea what it is for. I see that Halt>>signalerContext and Process>>complete: that use that pragma somehow. But still, I have no idea when I should use that pragma in my method.
What about having a way to comment pragma? Maybe something like -=-=-=-=-=-= Object subclass: #Pragma instanceVariableNames: 'method keyword arguments comment' -=-=-=-=-=-=
And a simple way to annotate pragmas? Just an idea.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- www.tudorgirba.com www.feenk.com "What we can governs what we wish."
I am not sure to get it. Why not simply having a class PragmaDescription that simply associate a comment to a selector ? Alexandre
On Jun 25, 2016, at 3:18 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I believe we are missing a first class entity for a PragmaType. Essentially, I think that the class side of the Pragma class should become a full object.
In fact, we already have a rudimentary version of this in Spotter because we needed an object to be able to browse all definitions of a certain pragma.
So, now, I extended it with the concept of a user which is the list of all senders minus the methods that are annotated with a pragma. This helps distinguish the meaning of a pragma by looking at the code where it is being used. Perhaps we can find a better name than users.
You can see these users in the inspector and in spotter:
<pragma-type-users.png>
I think we should build on this.
What do you think?
Cheers, Doru
On Jun 24, 2016, at 3:54 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi!
A pragma may be very obscure. For example, I do: Pragma allInstances anyOne => <debuggerCompleteToSender>
If I want to know more about this <debuggerCompleteToSender> is actually quite challenging. I see many methods having that pragma, but not idea what it is for. I see that Halt>>signalerContext and Process>>complete: that use that pragma somehow. But still, I have no idea when I should use that pragma in my method.
What about having a way to comment pragma? Maybe something like -=-=-=-=-=-= Object subclass: #Pragma instanceVariableNames: 'method keyword arguments comment' -=-=-=-=-=-=
And a simple way to annotate pragmas? Just an idea.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- www.tudorgirba.com www.feenk.com
"What we can governs what we wish."
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi, That is what I said. We need a meta-object that describes a Pragma instance. I said that we already had the need to have such a meta-object in Spotter and we created one that is called PragmaType. We can call it PramgaDescription as well, but the key point would be to casually connect the meta object and the instances. For example, besides the description, you still would like to know which parts of the image actually react to such a pragma, and this is where getting an idea of the logic that is making use of a pragma is very useful. For example, in the case of the debuggerCompleteToSender pragma, we have: - 15 annotations of methods - 2 methods that use the pragma So, you have 2 places to look for to understand that logic. You would not see this from a description only. Having a real meta-object allows us to complement a possible description with smarter analyses. Cheers, Doru
On Jun 26, 2016, at 2:29 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
I am not sure to get it. Why not simply having a class PragmaDescription that simply associate a comment to a selector ?
Alexandre
On Jun 25, 2016, at 3:18 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I believe we are missing a first class entity for a PragmaType. Essentially, I think that the class side of the Pragma class should become a full object.
In fact, we already have a rudimentary version of this in Spotter because we needed an object to be able to browse all definitions of a certain pragma.
So, now, I extended it with the concept of a user which is the list of all senders minus the methods that are annotated with a pragma. This helps distinguish the meaning of a pragma by looking at the code where it is being used. Perhaps we can find a better name than users.
You can see these users in the inspector and in spotter:
<pragma-type-users.png>
I think we should build on this.
What do you think?
Cheers, Doru
On Jun 24, 2016, at 3:54 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi!
A pragma may be very obscure. For example, I do: Pragma allInstances anyOne => <debuggerCompleteToSender>
If I want to know more about this <debuggerCompleteToSender> is actually quite challenging. I see many methods having that pragma, but not idea what it is for. I see that Halt>>signalerContext and Process>>complete: that use that pragma somehow. But still, I have no idea when I should use that pragma in my method.
What about having a way to comment pragma? Maybe something like -=-=-=-=-=-= Object subclass: #Pragma instanceVariableNames: 'method keyword arguments comment' -=-=-=-=-=-=
And a simple way to annotate pragmas? Just an idea.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- www.tudorgirba.com www.feenk.com
"What we can governs what we wish."
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- www.tudorgirba.com www.feenk.com "Problem solving efficiency grows with the abstractness level of problem understanding."
participants (11)
-
Alexandre Bergel -
Ben Coman -
Clément Bera -
Denis Kudriashov -
Eliot Miranda -
Esteban Lorenzano -
Jan Vrany -
Nicolas Passerini -
Richard Sargent -
stepharo -
Tudor Girba