N Papoulias

M Denker

S Ducasse

L Fabresse

End-User Abstractions for Meta-Control: Reifying the Reflectogram

Keywords: Reflection, Intercession, Reflectogram, Explicit Control

Reflective facilities in OO languages are used both for implementing language extensions (such as AOP frameworks) and for supporting new programming tools and methodologies (such as object-centric debugging and message-based profiling). Yet controlling the runtime behavior of these reflective facilities introduces several challenges, such as computational overhead, the possibility of meta-recursion and an unclean separation of concerns between base and metalevel. In this paper we present five dimensions of meta-level control from related literature that try to remedy these problems. These dimensions are namely: temporal and spatial control, placement control, level control and identity control. We then discuss how these dimensions interact with language semantics in classbased OO languages in terms of: scoping, inheritance and first-class entities. We argue that the reification of the descriptive notion of reflectogram can unify the control of meta-level execution in all these five dimensions while expressing properly the underlying language semantics. We present an extended model for the reification of the reflectogram based on our additional analysis and validate our approach through a new prototype implementation that relies on byte-code instrumentation. Finally, we illustrate our approach through a case study on runtime tracing.

Introduction

The notion of reflection was formally introduced to programming language literature by Brian Cantwell Smith in 1982 (by means of the programming language 3-LISP [START_REF] Smith | Reflection and semantics in a procedural programming language[END_REF]). In OO reflective systems, reflection is concretized using a MOP (Meta-Object Protocol ) [START_REF] Kiczales | The Art of the Metaobject Protocol[END_REF]. A meta-object is a regular object that Preprint submitted to SCIENCE OF COMPUTER PROGRAMMING December 17, 2016 describes, reflects or defines the behavior of a notion of the language in question [START_REF] Maes | Concepts and experiments in computational reflection[END_REF]. The process of materializing a notion of a language (such as an object, a class, a context or a method) as an object inside the language itself is called reification. Reflective facilities in OO languages [START_REF] Cazzola | Reflection and meta-level architectures: State of the art and future trends[END_REF] are used both for implementing language extensions such as AOP frameworks [START_REF] Tanter | A versatile kernel for multi-language AOP[END_REF] and for supporting new programming tools and methodologies such as object-centric debugging [START_REF] Ressia | Object-centric reflection[END_REF] and message-based profiling [START_REF] Bergel | Counting messages as a proxy for average execution time in Pharo[END_REF].

Yet, controlling the runtime behavior of reflection introduces several challenges such as computational overhead [START_REF] Maes | Issues in computational reflection[END_REF], the possibility of meta-recursion [START_REF] Chiba | Avoiding confusion in metacircularity: The Meta-helix[END_REF][START_REF] Denker | The Meta in meta-object architectures[END_REF] and an unclean separation of concerns between base and meta-level [START_REF] Bracha | Mirrors: Design principles for meta-level facilities of object-oriented programming languages[END_REF]. These problems arise mainly when implicit reflection (i.e., reflection that is activated implicitly by the interpreter on pre-defined execution events [START_REF] Maes | Issues in computational reflection[END_REF]) alters the semantics of a running process in ways that lead to excess overhead or inconsistencies.

Although implicit reflection involves complicated modeling concerns, it is useful to consider it -in its most simple form -as operating similarly to an Event-Condition-Action model [START_REF] Dittrich | The active database management system manifesto: A rulebase of ADBMS features[END_REF][START_REF] Tanter | Partial behavioral reflection: Spatial and temporal selection of reification[END_REF]. In a class-based OO language the ECA model would be depicted as shown in Figure 1. The Event (left part of Figure 1) in the case of implicit reflection is a semantic action of the underlying interpreter (e.g., read/write slot, message send, method execution etc.) while both Condition and Action can be considered as custom code snippets (such as block closures) defined by the developer. Registration of such events can take the following form (code presented in Smalltalk syntax): In essence, the interpreter triggers an Event (such as a message send) if a predefined condition is met for that event (e.g., a counting flag is set) and then a reflective action is implicitly evaluated (e.g., a message counter is incremented).

Condition Event

MsgSend

MsgReceived IvRead Starting from this general (albeit naive) model for implicit reflection this paper presents five dimensions of meta-level control from related literature, namely: temporal and spatial control, placement control, level control and identity control. We then discuss how these dimensions interact with language semantics in class-based OO languages in terms of: scoping, inheritance and first-class entities. We argue that the reification of the descriptive notion of reflectogram [START_REF] Tanter | Partial behavioral reflection: Spatial and temporal selection of reification[END_REF] can unify the control of meta-level execution in all these five dimensions while expressing properly the underlying language semantics.

The idea of reflectogram was proposed by Tanter et al. [START_REF] Tanter | Partial behavioral reflection: Spatial and temporal selection of reification[END_REF] as a visual depiction of the control flow between the base and the meta-level. Our work proposes to concretize this depiction as an explicit programming language entity. We present an extended model for the reification of the reflectogram based on additional analysis described in this paper. We validate our approach through a new prototype implementation. This revised implementation uses byte-code instrumentation instead of a custom VM, making it compatible with the production Pharo VM and its JIT. Finally, we detail a case study on unanticipated tracing showing that all five dimensions are needed in practical applications and a unified abstraction (such as the reflectogram) is warranted.

The contributions of this work are the following:

• The presentation of different dimensions of meta-control that have been previously treated separately in literature.

• A model for the reification of the reflectogram.

• An implementation of our proposition and its validation.

This paper is an extended version of our previous work [START_REF] Papoulias | Reifying the reflectogram: Towards explicit control for implicit reflection[END_REF] that provides the following additional contributions:

• An analysis of the interaction between meta-control dimensions and language semantics in class-based OO languages in terms of: scoping, inheritance and first-class entities.

• Several extensions to the initial model that are based on our additional analysis, including the introduction of the class ReflectoPoint which now seperately represents a single point (meta-jump) of the reflectogram.

• A second implementation of our proposition that is based on byte-code instrumentation, on top of Reflectivity1 for Pharo2 and is now compatible with a production VM that integrates a JIT. This allowed us to further discuss implementation options comparing to our previous results on top of a JIT-less dedicated VM.

The rest of this paper is organized as follows. Section 2 presents the different dimensions of meta-level control. Section 3 presents our analysis on meta-control and language semantics in class-based OO systems. Section 4 presents our extended model for the reification of the reflectogram. Section 5 illustrates a case study on unanticipated tracing using our approach. Section 6 details the new prototype implementation of our approach in Pharo and compares different implementation options. Section 7 compares related work. Finally, Section 8 concludes the paper and discusses future perspectives.

Dimensions of Meta-Control

Temporal Control

We refer to the temporal control of implicit reflection as the ability of runtime installation, activation, de-activation and removal of reflective facilities. Temporal control allows a programmer to define when an event will actually be reified by controlling the time of its activation. In essence, setting up meta-actions for events such as the one we described on Script 1 can either be done statically (at compile or load time) or dynamically at run time. In this latter case, trivial conditions like the countingFlag of Script1 are redundant since meta-actions can be installed, enabled, disabled or removed during execution: ... "code whose messages will be counted"

MsgSend disable

Temporal control of reflective facilities at runtime can support unanticipated behavioral reflection as was first illustrated by Redmond et al. [START_REF] Redmond | Supporting unanticipated dynamic adaptation of application behaviour[END_REF] for the Iguana/J framework [START_REF] Redmond | Iguana/J: Towards a dynamic and efficient reflective architecture for Java[END_REF]. Röthlisberger et al. [START_REF] Röthlisberger | Unanticipated partial behavioral reflection: Adapting applications at runtime[END_REF] further optimized this approach by supporting unanticipated partial behavioral reflection in Geppetto. Examples include the temporal control of profiling facilities at runtime to facilitate memoization and caching. Röthlisberger et al. give such an example for web applications in [START_REF] Röthlisberger | Unanticipated partial behavioral reflection: Adapting applications at runtime[END_REF].

Spatial Control

Spatial control was introduced (as such) by Tanter et al. [START_REF] Tanter | Partial behavioral reflection: Spatial and temporal selection of reification[END_REF] to support a partial reflection scheme in Reflex. This is in spite of the fact that analogous mechanism predate Reflex (such as the CLOS MOP [START_REF] Kiczales | The Art of the Metaobject Protocol[END_REF]), but which do not distinguish between the different dimensions of their facilities. Spatial control allows a programmer to narrow the scope of implicit reflection to specific entities (objects, classes, methods etc.) and operations thus optimizing performance. In a model supporting spatial control our example from Script 1 would be written as follows: The difference here on Script 3 (line 1) with our initial example is that a specific class is targeted to be interceded rather than the whole system. Implementations of spatial control -such as the one of Reflex [START_REF] Tanter | Partial behavioral reflection: Spatial and temporal selection of reification[END_REF] -provide even finer control over what is reified. This is accomplished by targeting single operations on a sub-method level. Other approaches restrict reifications to specific objects over particular executions as in the case of Bifrost [START_REF] Ressia | Object-centric reflection[END_REF]. With spatial control unnecessary jumps to the meta-level (e.g., for classes other than SomeClass) can be avoided resulting in an execution speed-up of reflective code.

Placement Control

On the other hand, placement control allows a programmer to define the relative timing of an action in relation to its event as exemplified by Tanter et al. [START_REF] Tanter | Partial behavioral reflection: Spatial and temporal selection of reification[END_REF], but also in works related to method slots [START_REF] Zhuang | Method slots: Supporting methods, events, and advices by a single language construct[END_REF] and wrappers [START_REF] Brant | Wrappers to the rescue[END_REF]. For example, user-defined actions can be triggered before or after an event or even totally replace the default semantic action. This is shown on lines 4 and 5 of Script 4 where two different meta-actions are registered to be triggered for message sends of SomeClass. The first on line 4 is a logging meta-action registered to be triggered before the actual message send at the base-level code of SomeClass. While the second action (line 5) is our counter increment example registered to be performed after the event of the message send.

Spatial, temporal and placement control can be used in a variety of contexts where partial reflection is applicable. The most prominent examples can be found in implementations of AOP frameworks [START_REF] Tanter | A versatile kernel for multi-language AOP[END_REF].

Level Control

Level control refers to the ability of assigning different reflective behavior to different meta-levels of a reflective tower [START_REF] Wand | The Mystery of the Tower Revealed: A Non-Reflective Description of the Reflective Tower[END_REF]. Conceptually in OO languages we can say that we operate in a new "higher" meta-level whenever a new reflective action is triggered from within the meta-level itself. This process can continue indefinitely if reflective actions are not carefully coded. In this case the problem of infinite meta-recursion occurs [START_REF] Chiba | Avoiding confusion in metacircularity: The Meta-helix[END_REF].

A simple case of infinite meta-recursion illustrating the problem is given on Script 5. On lines 1 to 3, we register (through the message #on:do:) a callback for the MessageReceived event (line 2) of the instance anObject (line1). Essentially, we want the block closure on line 3 to be triggered every time the instance anObject receives a message. Alas, on line 3 in order to increment a message counter (message #incrementMessageCounter) we send another message to the instance anObject from within the meta-level. This new message send will re-trigger the MessageReceived event, re-triggering the callback on line 3, and resulting in an infinite recursion. Denker et al. [START_REF] Denker | The Meta in meta-object architectures[END_REF] first proposed a level control mechanism to solve the metarecursion problem in OO languages through the reification of the metaContext, which represents the level in which a meta-jump occurs. The metaContext is an implicit entity of the meta-level, in the sense that the developer does not invoke it explicitly but rather executes code or binds meta-objects to specific meta-levels (as shown on Script 6). As described in [START_REF] Denker | The Meta in meta-object architectures[END_REF] in order to control the meta-level and avoid meta-recursion, Denker et al. provide a way to run a block-closure one meta-level higher than the code outside the block as follows:

Script 6: Code execution with a metaContext [START_REF] Denker | The Meta in meta-object architectures[END_REF] [ ... code executing on meta-1 ... ] valueWithMetaContext ... More recently and in another context (that of AOP) the idea of execution levels has been proposed [START_REF] Tanter | Execution levels for aspect-oriented programming[END_REF][START_REF] Tanter | Execution levels for aspect-oriented programming: Design, semantics, implementations and applications[END_REF]. These execution levels provide a concrete solution to the problem of aspect loops (the equivalence of meta-recursion in AOP) for languages such as AspectScript [START_REF] Toledo | AspectScript: Expressive aspects for the Web[END_REF] and AspectJ [START_REF] Kiczales | An overview of AspectJ[END_REF].

Besides being a solution to the meta-recursion problem, level control can prove useful in other contexts of meta-circularity. Examples include the profiling of meta-level execution itself through reflection.

Identity Control

When base-level objects are responsible for their own reflective operations it is hard to allow finer control over reflective behavior. Identity control is the factoring of reflective operations out of the targeted base-level objects. This decomposition was investigated by Bracha and Ungar through Mirrors [START_REF] Bracha | Mirrors: Design principles for meta-level facilities of object-oriented programming languages[END_REF] but has been studied in different contexts as well [START_REF] Ferber | Computational reflection in class-based object-oriented languages[END_REF][START_REF] Cazzola | Remote method invocation as a first-class citizen[END_REF]. AmbientTalk [START_REF] Mostinckx | Mirror-based reflection in AmbientTalk[END_REF] was the first mirror-based implementation specifically targeting implicit reflection.

With identity control the meta-object (mirror-based or otherwise) assumes the identity of the receiver of the reflective method, bypassing the object's control altogether. From this perspective the problem is also closely related to the ideas of both subject and context-oriented programming [START_REF] Harrison | Subject-oriented programming (a critique of pure objects)[END_REF][START_REF] Gassanenko | Context-oriented programming[END_REF][START_REF] Hirschfeld | Context-oriented programming[END_REF]. Indeed these two paradigms deal with variations of object behavior that conceptually do not depend on one specific object, but rather on the execution context and its state.

Identity control can prove useful in situations such as the one depicted in Figure 2. In Figure 2 anObjectInpector wants to inspect the slots of a base-level object. This object (aPersistentObject) supports persistency (on a file or on a database) through reflective intercession. This means that the semantics for accessing instance variables of a persistent object have changed through reflection to synchronize the state of the object with external data storage. Let us now assume that this was achieved by instructing the compiler to transform each read and write access to instance variables into meta-level calls. For example, in this case each read access of instance variables in the class PersistentObject will be redirected to the meta-level method #instVarAt which has been overridden from Object to provide the additional functionality.

Although this change in semantics for aPersistentObject is desirable, it does not make sense in the case of anObjectInspector. The object anObjectInspector (as do most programming tools) wants direct access to the slots of aPersistentObject without triggering the back-end (i.e., database) logic. Bracha and Ungar suggest that for such cases reflective facilities that are not part of the language kernel should be used. In this example a separate read access method from the one depicted in Object»#instVarAt: -and which the ObjectInspector»#instVarAt: invokes -can be used. This is the case of the #objInstVarAt: method of ObjectInspector which has read access through direct virtual-machine support to object slots bypassing the targeted object's control. What has essentially changed here between Object»#instVarAt: and ObjectInspector»#objInstVarAt: -which perform the same operation -is the identity of the receiver of the reflective action. In the first case the receiver is aPersistentObject while in the latter it is anObjectInspector.

ObjectInspector

+ instVarAt(anIndex) + objInstVarAt(anObject, anIndex) Object + instVarAt(anIndex) ... In summary, identity control besides solving problems as the one we described above promotes a stricter separation of concerns between base-level and metalevel functionality.

Meta-control and Language Semantics

Using meta-level facilities as the ones we described in Section 2 presents certain challenges in class-based OO languages. In this section we report and categorize these issues, using mainly an instance and a class entity as our running examples. Nevertheless, similar issues apply to other OO entities such as environments, packages, methods, processes and contexts.

Meta-control and Scoping Semantics

The ECA model for implicit reflection we saw in Section 1 describes events that are implicitly triggered at specific program execution points. The definition of these execution events though are highly dependent on the concrete implementation of a reflective framework. While the developer may expect an event of the form "anEntity on: <Event> do:..." to always behave the same way, we will shortly see that an <entity3 , event> pair does not unambiguously define a reflective operation.

Our first example on Script 7a below involves a terminal instance and two events (on lines 1 and 3 respectively): Script 7a: Scoping: Reducing vs. Specializing Now, on line 1 of Script 7a above, the event MsgSend (a method invocation) which by itself has a global scope (can happen anywhere) is reduced to the scope of a specific object. Script 3 also shows an example of such a scoping. But then on line 3 the event PassedAsArg (passing a reference of an entity in a dynamic method invocation) which (as with MsgSend) has by itself a global scope (can happen anywhere) may have different interpretations. On the one hand as before (line 1) it may be interpreted as reducing the scope of the event, to the object's scope. On the other hand though it may be interpreted as specializing the event (i.e., the event remains global but is only triggered if this specific object is passed as an argument). Indeed passing even a specific object as an argument (in a dynamic environment) can happen anywhere.

So far we can say that depending on the event, meta-control can either reduce the global scope of an event or specialize it with a condition (while it remains global). The situation becomes a little more complicated on Script 7b. Here, we have the same event as line 3 of Script 7a but the entity is now the class of anInstance. In this case, depending on the implementation we can either: 1. Treat the class as a scope and more specifically, as a set of lexical scopes (methods) from which we will intercess all PassedAsArg events (regardless of which object is passed), similarly to the event of line 1 (ie reduce the scope).

2. Treat the class as a set of runtime entities and trigger the PassedAsArg event whenever an object of the specific class is passed as an argument, as in the event of line 3 (ie specialize).

3. Finally, if the underlying language supports first-class classes, there is a third option: Treat the class as an object itself and trigger the PassedAsArg event whenever the class itself is passed as an argument.

Meta-control and First-class entities

This last case (first-class entities) is the intended mode of operation of our second example below (Script 8). In this example, starting at line 1, the MsgReceive event is specialized by the first-class instance of (anInstance class) with the condition that the dynamic method invoked has the signature #basicNew (line 3). Essentially, this snippet simulates the ObjectCreation event (signaled whenever an instance of a specific class is created), showing that this third choice (of treating classes as first-class in implicit reflection) is not a marginal but a very useful case.

Meta-control and Inheritance

Finally, we discuss inheritance. Consider a class hierarchy (as the one depicted in Figure 3 originating from Object with a subclass A then a subclass of A named B and finally, a subclass of B named C. Assuming that MsgReceive here treats its target (say the class B) as a set of runtime entities, what does a reflective MsgReceive event (as the one we saw in the above snippet) mean when applied to class B for instances of C and for the methods of A ? Here we have the following (canonical) outcome:

Object A C B cInstance + methodOfA … + methodOfB … + methodOfC …
• Concerning messages received by instances of B that invoke methods inherited from A the canonical response is to intercept them.

• Concerning instances of C the canonical approach is to intercept only those messages that invoke methods of B and A (but not methods of C).

However, this is not always the desired outcome. Consider, for example, that the canonical approach here will also intercess all methods of Object (the root of the hierarchy) for the instances affected. This is a problem as Object includes in most systems critical system methods that should not be intercepted. Propagating reflective behavior automatically inside the hierarchy chain like that may not be the desired outcome, especially for long hierarchies where the developer is subclassing without actual knowledge of the inherited functionality. Similar issues arise in class-based OO languages for other events such as IVRead (instance variable read) and IVWrite (instance variable write).

Summary

In summary, given the above ambiguities in terms of scope, first-class entities and inheritance, we believe that models of implicit reflection should make the distinctions mentioned in this section between different cases explicit. Alternatively reflective frameworks should allow developers to decide for each case programmatically.

Reifying the Reflectogram

The notion of reflectogram was introduced by Tanter et al. [START_REF] Tanter | Partial behavioral reflection: Spatial and temporal selection of reification[END_REF] as a conceptual illustration to describe meta-level behavior to human readers:

[...] A reflectogram illustrates the control flow between the base-level and the meta-level during execution.

For example, in the left part of Figure 4 we see a diagram from Tanter et al. describing spatial control and partial reflection, while in the bottom part of Figure 4 we see a depiction from the same paper of temporal control. Other researchers have used similar control flow illustrations to describe different dimensions of meta-level behavior as the diagram we reproduce from [START_REF] Denker | The Meta in meta-object architectures[END_REF] (right part of Figure 4) describing level control.

Given the versatility of the reflectogram for describing meta-level behavior, the rest of section describes our proposition of reifying it as an explicit metaobject. This meta-object is passed as an argument at runtime to conditions and implicit actions invoked by the underlying execution environment. Our goal is to unify the control of meta-level execution under a single abstraction for end-users.

Reifying the Reflectogram

Our proposal (shown in Figure 5) in its more general form extends the Event-Condition-Action model of implicit reflection (depicted in Figure 1) by establishing a one-to-many relation of both the condition and the action with the The relationship is one-to-many in the sense that a single action or condition can be registered for multiple objects. Upon each invocation, the reflectogram corresponding to the particular object that triggered the event creates a new reflectopoint that will be passed as an argument to the meta-level.

Besides holding a reference to that targetObject, the reflectogram should provide meta-information through each reflectopoint for the currently triggered event which -depending on the implementation -can be used to parametrize conditions and actions at runtime.

Compared with our initial model [START_REF] Papoulias | Reifying the reflectogram: Towards explicit control for implicit reflection[END_REF] the introduction of the reflectopoint makes explicit the fact that there is a new meta-object generated for each metajump. This meta-object can now control the outcome of individual reflective operations. This allows us to make a clear distinction between:

• Reflectopoints, representing single-points (jumps) on the reflectogram • and the reified reflectogram itself, which through event registration controls the overall evolution in time of a target object.

Furthermore, in order to address the issues identified in Section 3 we introduce one level of indirection between the ReflectoGram and its targeted object through the extended class Target described in detail in Section 4.3.

Event Registration. The reflectogram controls the spatial dimension of implicit reflection at runtime through the methods #on:when:do: and #on:for:do:when:. The latter method is either a static or a class-side method depending on whether classes in the target language are first class or not. Registering an event for a specific object can be modeled as follows: As seen on lines 4 and 5 of Script 9, conditions and actions in our model receive an argument (reflectopoint) which describes and controls the "shape" of the reflectogram for each meta-level jump of the associated base-level object. The class-side method #on:for:do:when: is used for the initial registration of an event. Its instance-side counterparts #on:when:do: provides the same functionality in order to register more events at runtime from within the meta-level.

It is worth noting here that while we are assuming a single meta-level for our system, both conditions and actions depicted in Figure 5 can be considered as first-level implicit meta-objects. That is, objects that are invoked implicitly during specific events by the underlying execution environment [START_REF] Maes | Issues in computational reflection[END_REF]. From this perspective both the reflectogram and the reflectopoints can be seen as secondlevel explicit meta-objects, in the sense that their domain is the control of the first implicit meta-level of conditions and actions.

The Reflectogram API

The API of our model is organized into five distinct protocols corresponding to the five dimensions for meta-level control discussed in Section 2:

Temporal Protocol. Methods #enable, #disable and #remove as their name suggests control the actual triggering of events. Implementors can choose to provide static counterparts for convenience (such as #enableFor:, #disableFor: etc.).

Spatial Protocol. Methods #on:when:do:, #on:for:do:when: control spatial selection by registering events for specific objects as it has been described above.

Placement Protocol. Methods #defaultAction and #returnValue: control the placement of meta-actions. The reflectogram can invoke the default base-level action from within the meta-level thus implicitly defining which meta-level statements will be executed before and which statements after the actual event. Regardless of whether the default action has been triggered from within the meta-level the value that will be returned to the base-level can be explicitly set, thus facilitating total replacement of base-level semantics.

Level Protocol. Methods #processMetaLevel and #objectMetaLevel return the height of the currently executing meta-level action or condition as in the meta-level tower model. The #processMetaLevel returns the process-wide meta-level height, while the #objectMetaLevel returns the number of metalevels that have been triggered due to events of the reflectogram's target object.

Identity Protocol. Finally, methods #at:, #at:put: and #perform:withArgs: provide read, write (for slots) and execution reflective facilities (for message sending) for the target object. These methods are implemented separately from core reflection and their corresponding message sends are received by the reflectopoint rather than the target object. This way the identity of the receiver of reflective methods is controlled as was described in Section 2.5.

A usage example of the reflectogram is depicted on Script 10 where we solve the meta-recursion problem that was described in Section 2.4 (Script 5) by explicitly controlling the meta-level execution flow: ] Lines 1 to 3 of Script 10 register the MessageReceived event for the instance anObject. On line 4 -as before -a trivial condition is registered checking a message-counting flag. Then on lines 5 to 11 a meta-action is registered for the MessageReceived event. On line 6 the reflectopoint is explicitly disabled thus temporarily allowing message sends to be received by anObject without interception. On line 7 the message #incrementCounter is send to anObject without resulting in an infinite recursion since the reflectopoint has been disabled. Then on lines 8 to 9 the value that will be returned to the base-level is set to the default semantic action for MessageReceived events. This default action corresponds to the evaluation of whichever message send (received by anObject) was intercepted and triggered the meta-jump. Finally, on line 10 the reflectopoint is re-enabled before returning control to the base-level, as to be able to intercept further message sends to anObject.

Handling Scoping, Reifications and Inheritance

In Figure 5 although each ReflectoGram is still associated with a single target object (as with our initial model) it has now multiple Targets (for the same object) which differentiate between different events, scopes, hierarchy policies etc. This class Target introduces one level of indirection between the ReflectoGram and the targetedObject in order to address the issues identified in Section 3 concerning scope, inheritance and first-class entities. In Figure 6, we see that each target apart from each association with exactly one event, stores multiple Mode objects (scope, hierarchy, reification slots) that disambiguate the exact semantics of an <event,target> pair according to the following rules: Scope (issue described in Section 3.1) SingleScope Treat the target as a single logical scope (even if this is a composite scope). For example, in Script 7b, the class of line 1 will be treated as a single logical scope comprised of a set of methods. MultiScope Treat the target as a set of runtime entities. For example, in Script 7b, the class of line 1 will be treated as a set of its instances, and trigger the PassedAsArg event whenever (from multiple scopes) an object of the specific class is passed as an argument. By Default Treat the target with default scoping mode defined in the event itself. For example, a PassedAsArg event can always be a multiscope event (concerning only sets of runtime objects and not scopes). This option partially solves the problem by making the convention explicit.

MsgSend MsgReceived IvRead

Reification (issue described in Section 3.2)

Instance Treat the target as an instance (i.e., if it is first-class) and not as a set of either scopes or other instances. For example, in Script 8, the class is treated as a terminal instance to simulate the ObjectCreation event. Entity Treat the target as the semantical entity it represents (i.e., a class as a set of objects or methods, a package as a set of classes etc.), following the scoping rules (above). By Default We believe that treating all reifications as entities is the most logical default behavior. Nevertheless, as we show in Section 3.2 it is useful to allow the programmer to override this.

Hierarchy (issue described in Section 3.3)

Flat Ignore the class hierarchy and operate only on the set of either methods or objects belonging to the target. Inheritance Propagate inheritance rules to the hierarchy as is described in Section 3.3. By Default We believe that by default all targets should be treated as Flat to avoid surprises while propagating reflective behavior, but nevertheless allow end-users to override it if necessary.

From the point of view of the end-user the above model can be integrated in an extended event registration API as follows: Here, the programmer can optionally set the policies for reification and hierarchy (line 3). Furthermore, scoping (line 4) is made explicit by organizing events into scoping hierarchies (i.e., the PassedAsArg inherits from MultiScopedEvent). Finally, the limitedTo: directive on line 5 can programmatically restrict the propagation of the reflective behavior (in a set of methods) even in the case that an inheritance mode is set as the hierarchy policy.

The Reflectogram in Action

This section presents the implementation of a non-trivial tracing framework where the code that will be traced is not known a priori (i.e., is unanticipated) but is being instrumented on the fly at runtime. Message-based profiling [START_REF] Bergel | Counting messages as a proxy for average execution time in Pharo[END_REF], for example, uses such a tracing approach to approximate execution time of selected methods. Through this example, we aim to show that all five dimensions of control co-occur in practical applications and a unified abstraction (such as the reflectogram) is warranted. In the code snippets below the extended revised event registration described in Section 4.3 is used, while the event MsgSend inherits here from SingleScopedEvent.

Figure 7 shows the core classes of our tracing framework, which include:

CallGraph. The entry point of the output call graph of our tracing process.

CallGraphNode. Individual nodes of the output call graph holding the actual meta-information that has been traced. For our framework, this metainformation includes: the receiver of a message send, its class, the selector and the arguments passed along with the message call.

ExecutionTrace. Users subclass ExecutionTrace adding the entry point symbol of the code to be traced by invoking the inherited #run: aSymbol method (where aSymbol corresponds to a method name). Also inherited are the corresponding output call graph and the process (i.e., green thread) where the tracing of a targeted method will take place.

CallTrace. Finally, CallTrace implements the condition and send callbacks (Script 12) which are bound to traced objects at runtime. These callbacks then delegate meta-level control to methods #inTracingScope:, #addGraphNode:, #executeNode: and #return:, respectively (Script 13).

ExecutionTrace CallGraph As seen on lines 2,7,8 and 9 of Script 12 since the reflectogram and its points are reified as first class entities they can be passed as arguments beyond the scope of conditions or meta-actions. On line 2, a reflectopoint is passed to the #inTracingScope: method to determine if the meta-event that triggered the conditionCallback happened inside our tracing process or not. On line 7, it is passed to #addGraphNode: to gather the meta-information needed to update the call graph. Then, on line 8 it is passed to #executeNode: to perform the default base-level action and gather its return value. Finally, on line 9 it is passed to the #return: method which resets both the call graph and the reflectogram appropriately for further processing. Method #inTracingScope: (lines 1 to 3) the level protocol of the reflectopoint is used (line 3) in order to determine whether we are intercepting a method call that originated from the base-level of our tracing process (processMetaLevel = 1). If not #inTracingProcess: will return false and the corresponding metaaction (lines 5 through 9 on Script 12) will not be invoked.

Method #addGraphNode: (lines 5 through 13) the reification slot of the reflectopoint is used in order to gather meta-information about the intercepted call and update the call graph. The reification slot stores event-specific information for each meta-jump. This information can include: the sender, receiver, arguments and context of message sends, name and values of variables accessed, the active process, the targeted object, the type of the event etc. Method calls are intercepted every time a message is sent to a new receiver (from within a traced object). On lines 8 through 11 the identity protocol is used in order to extract the class of this new receiver and avoid the meta-recursion problem in case this receiver was previously being traced.

Method #executeNode: (lines 15 to 27) a new call trace is being created and is being assigned to the new receiver at runtime via the spatial protocol (lines 19 to 25) using the extended event registration API. Then on lines 26 to 27 the placement protocol is being used to perform the default base-level action and gather its return value. Since the base-level action is a method call to a newly-traced object it will re-trigger the meta-level for all new method calls from within its scope before returning.

Method #return: (lines 29 to 31) is the equivalent of an after-action. Here we update the call graph (to point to the node that we have previously added) and re-enable the reflectopoint (line 31) for our traced object through the temporal protocol. The reflectopoint had been previously disabled for convenience (in order to avoid unnecessary meta-jumps) on the beginning of the meta-action callback (line 7, Script 12).

Implementation

Previously, the prototype implementation of our model for the reflectogram was part of a dedicated virtual machine targeting the Pharo platform: the metaStackVM4 [START_REF] Papoulias | Remote debugging and reflection in resource constrained devices[END_REF]. Essentially, through VM support, instrumentation checks can be performed on the objects themselves while they are being interpreted by the underlying execution environment. We implemented the metaStackVM by extending the standard Stack VM5 [START_REF] Miranda | Cog blog. Speeding up Croquet and Squeak with a new open-source VM from Qwaq[END_REF] of Pharo, in Slang [START_REF] Ingalls | Back to the future: The story of Squeak, a practical Smalltalk written in itself[END_REF]. Slang uses a subset of the Smalltalk syntax with procedural semantics that can be easily translated to C.

Currently, we report on experimentations made with a new implementation of our proposition using byte-code instrumentation, on top of Reflectivity6 . This fact made our current implementation compatible with a production just-in-time VM, and allowed us to further discuss implementation options comparing to our previous results. Reflectivity itself is based on the Gepetto model [START_REF] Röthlisberger | Unanticipated partial behavioral reflection[END_REF][START_REF] Denker | The Meta in meta-object architectures[END_REF] which uses lower-level abstractions (such as links and hooksets) apart from that of metaobjects in order to provide a stricter separation of concerns between handling of events (hookset responsibility) and meta-level delegation (link responsibility). More specifically, byte-code instrumentation in Reflectivity is performed at runtime (as in [START_REF] Röthlisberger | Unanticipated partial behavioral reflection[END_REF]) using extension modules of the Opal compiler7 allowing us to define:

• Sets of related base-level events that are described by reified objects (such as abstract syntax nodes).

• Meta-objects (any object can play this role) to which control will be delegated at runtime.

• A link between the events described by the AST nodes and the meta-object. Links can dynamically control the activation/deactivation of meta-level behavior.

Our own model does not cover (but uses) these concerns to offer higher-level abstractions that are more suitable for end-users. The rationale for our current choice to base our solution on top of a byte-code instrumentation framework is twofold. On the one hand, a customized VM (as in our previous implementation) is not a viable solution in the long run, unless the extensions become part of the vendor's VM for the platform. On the other hand, our previous experiment depended on a JIT-less VM which puts a performance penalty when compared to the state of the art. Both implementations of the reflectogram are available at http://ss3.gemstone.com/ss/mSVM.html together with the benchmarks presented in this section.

We evaluated both solutions though a micro-benchmark to measure the overhead introduced to normal execution with and without reifying the reflectogram. The benchmark is based on Tanter et al. [START_REF] Tanter | Partial behavioral reflection: Spatial and temporal selection of reification[END_REF] and measures the slowdown introduced for 10 6 messages sent to a test object when a) no instrumentation is present b) instrumentation is loaded but is disabled c) instrumentation is enabled d) instrumentation is enabled and the reflectogram is being reified.

For each platform, we used the most direct messaging event depending on the implementation. For example the metaStackVM uses the MessageReceive event send for the test object itself (since the VM has access to the runtime instances). Our current implementation uses the MessageSend event, which is a messaging event from within a specific scope (i.e., for a method that is being instrumented).

We present the results relative to normal execution for each platform individually measuring the slowdown introduced.

We report average execution times µ = 1 N N i=1 t i in milliseconds (ms) over 100 runs of the bechmarks (each run comprising 10 6 message sends), using the standard deviation σ = 1 N N i=1 (t i -µ) 2 as a measure of uncertainty/error for the measurements.

The average slowdown 8 is calculated as a derived quantity z of two directly measured variables x, y, where z = x/y, whence the standard deviation of z can be calculated as a propagation error using the formula: ∆z

z = ∆x x 2 + ∆y y 2 .
Where z is the the derived quantity (slowdown) and x, y the directly measured averages of the benchmarks.

In order to avoid skewing the results by the warmup time of the JIT we followed a similar procedure as the one described by J. Ressia for Bifrost [START_REF] Ressia | Object-centric reflection[END_REF] namely making sure that:

• Benchmarked methods are created in advance. 8 reported as x times the speed of normal execution • Method lookup tables are filled by repeated execution before the measurements.

• Measured methods compute constant time arithmetic operations for which there are no further optimisations provided by the VM.

As we see in Tables 1 and2 when instrumentation is loaded into the environment but is disabled for the benchmarked object, there is no additional overhead. This is important for practical reasons to avoid slowing down the whole system when instrumenting only a part of it [START_REF] Tanter | Partial behavioral reflection: Spatial and temporal selection of reification[END_REF]. For example, implicit reflection in both cases introduces an 8.66x (for bytecode instrumentation with Reflectivity) and 8.61x overhead (for our non-JIT customized VM) but only for the benchmarked object operating in an instead mode with reifications9 . In fact for bytecode instrumentation with Reflectivity when only a before directive is used10 without any reifications for events the slowdown introduced can be as low as 1.22x.

But while adding the reification of the reflectogram to the metaStackVM introduces a 1.59x slowdown compared to implicit reflection without such reification, in the case of bytecode instrumentation the additional slowdown for using the reflectogram is 2.42x. Nevertheless the added benefit of having the reflectogram operating on top of the vendor VM (in the presence of JIT compilation) with a faster underlying infrastructure allows for further optimizations [START_REF] Marr | Zero-overhead metaprogramming: Reflection and metaobject protocols fast and without compromises[END_REF] that we have not yet explored. Our results point us towards a synergetic approach, where both bytecode instrumentation and the VM are involved.

Related Work

In Section 2 we presented five dimensions of meta-control that have been previously treated separately in literature. Table 3 While Iguana/J [START_REF] Redmond | Iguana/J: Towards a dynamic and efficient reflective architecture for Java[END_REF][START_REF] Redmond | Supporting unanticipated dynamic adaptation of application behaviour[END_REF] was the first to introduce unanticipated changes (temporal control) and spatial control for the Java platform, it was Reflex [START_REF] Tanter | Partial behavioral reflection: Spatial and temporal selection of reification[END_REF] that introduced partial behavioral reflection (supporting spatial, temporal and placement control). On the other hand, due to implementation constraints Reflex did not allow for dynamic definition of meta-level behavior at runtime as did Iguana/J. This is in spite of the fact that analogous mechanisms predate both Iguana/J and Reflex (such as the CLOS MOP), but do not distinguish between the different dimensions of their facilities. These three types of control (placement, spatial and temporal) were first available during runtime in Gepetto for Smalltalk [START_REF] Röthlisberger | Unanticipated partial behavioral reflection[END_REF], with later extensions to the Gepetto implementation covering level control [START_REF] Denker | The Meta in meta-object architectures[END_REF]. Bifrost added an object-centric model to runtime reflection expanding spatial control to execution runs [START_REF] Ressia | Object-centric reflection[END_REF]. AmbientTalk [START_REF] Mostinckx | Mirror-based reflection in AmbientTalk[END_REF] was the first mirror-based implementation specifically targeting implicit reflection and has support for temporal, spatial and identity control.

Our own implementation manages to cover all five dimension of meta-control through the reflectogram reification. It is close to Gepetto [START_REF] Röthlisberger | Unanticipated partial behavioral reflection[END_REF] but additionally deals with identity control [START_REF] Denker | The Meta in meta-object architectures[END_REF].

Aspect-Oriented Programming. As discussed in Section 2, the problems presented in this paper have direct analogies to issues presented in AOP literature. In the context of AOP, the dimensions of spatial, temporal and placement control are embedded in the abstractions of aspects, namely: advices and join points. Moreover, the recent proposal of execution levels [START_REF] Tanter | Execution levels for aspect-oriented programming[END_REF][START_REF] Tanter | Execution levels for aspect-oriented programming: Design, semantics, implementations and applications[END_REF] solves the equivalent problem of meta-recursion by avoiding aspect loops.

Subject and Context-Oriented Programming. Finally, as we discussed in Section 2.5, the problem of identity control is closely related to the ideas of both subject and context-oriented programming [START_REF] Harrison | Subject-oriented programming (a critique of pure objects)[END_REF][START_REF] Gassanenko | Context-oriented programming[END_REF][START_REF] Hirschfeld | Context-oriented programming[END_REF]. These two paradigms deal with variations of object behavior that conceptually do not depend on one specific object. On the contrary these variations are linked to the general execution context and its state. Our solution, instead of providing an implicit variation of behavior on the target object, gives the programmer an alternative way to explicitly access its reflective behavior. With identity control the meta-object assumes the identity of the receiver of the reflective method, bypassing the object's control altogether. This basic approach can nevertheless be used to build more elaborate abstractions.

Limitations. From a model perspective, our solution presents some limitations compared to the model of Reflex or Gepetto, which are focused on extensibility. These models introduce abstractions (such as links and hooksets) apart from that of meta-objects in order to provide a stricter separation of concerns between event handling (hookset responsibility) and meta-level delegation (link responsibility). Other solutions such as Bifrost provide additional support for compound metaobjects allowing for composition of meta-behavior. Our approach presents a single unifying entity (the reflectogram) for meta-level control aiming at explicit handling of control flow from within the meta-level itself.

From this perspective, the reflectogram is more appropriate as an end-user abstraction rather than an implementor's abstraction since it does not focus on extensibility or composition. On the other hand, the reflectogram is described through the Event-Condition-Action model which all implicit reflection schemes (including Bifrost, Gepetto and Reflex) share and can thus be implemented -as we showed through our current implementation -as an extension on top of them.

Conclusion

Our work presents five different dimensions of meta-control for implicit reflection that have been treated separately in literature, namely: temporal and spatial control, placement control, level control and identity control. We discuss how these dimensions interact with language semantics in class-based OO languages in terms of: scoping, inheritance and first-class entities. We have proposed an extended model for the reification of a previously purely descriptive notion -that of the reflectogram [START_REF] Tanter | Partial behavioral reflection: Spatial and temporal selection of reification[END_REF] -arguing that such reification can unify the control of meta-level execution in all five dimensions, while expressing properly the underlying language semantics. We have also presented an additional prototype implementation of this reification in the Pharo programming environment which uses byte-code instrumentation -and is now compatible with a production VM that integrates a JIT compiler. We have validated our approach through a case study on unanticipated tracing.

In terms of future work, we would like to provide a formal semantic representation of the reflectogram and experiment with a more synergetic approach for implementing it where both bytecode instrumentation and the VM are involved. Finally we would like to provide benchmarks for larger examples and programming tools in a way where the impact of the framework itself is measured (as in our micro-benchmarks) rather than the slowdown of the meta-level application logic.

Script 1 :

 1 Implicit Reflection ExampleMsgSend when: [ countingFlag = true ] do: [ messageCounter := messageCounter + 1 ]

BlockClosureFigure 1 :

 1 Figure 1: Implicit Reflection as an Event-Condition-Action model

Script 2 :

 2 Temporal Control Example MsgSend do: [ messageCounter := messageCounter + 1 ].

Script 3 :

 3 Spatial ControlSomeClass on: MsgSend when: [ countingFlag = true ] do: [ messageCounter := messageCounter + 1 ]

Script 4 :

 4 Placement ControlSomeClass on: MsgSend when: [ countingFlag = true ] before: [ Transcript show: 'A message will be sent from SomeClass' ] after: [ messageCounter := messageCounter + 1 ]

Script 5 :

 5 The meta-recursion problem anObject on: MessageReceived do: [ anObject incrementMessageCounter ]

[[

  ... code executing on meta-2 ... ] valueWithMetaContext ] valueWithMetaContext

Figure 2 :

 2 Figure 2: Inspecting an intercessed object

  anInstance on: MsgSend do: [...] anInstance on: PassedAsArg do: [...]

  Script 7b: Scoping: Reducing vs. Specializing anInstance class on: PassedAsArg do: [...]

Script 8 :

 8 Simulating ObjectCreation anInstance class on: MsgReceive when: [:selector | (selector = #basicNew) | (selector = #basicNew:)] do: [...]

Figure 3 :

 3 Figure 3: A simple hierarchy with class B as a reflection target

Figure 4 :

 4 Figure 4: Diagram of the reflectogram in literature: Tanter et al. (left and bottom) [30] and Denker et al. [7] (right)

Figure 5 : 9 :

 59 Figure 5: Our extended proposal: Reifying the Reflectogram

Script 10 :

 10 Solving the meta-recursion problem with the reflectogram

Figure 6 :

 6 Figure 6: Different modes for targets of the reflectogram

Script 11 :

 11 Extended Event Registration: Handling different modes programmatically Reflectogram on: aTarget as: Entity -> Flat for: PassedAsArg "class inheriting from MultiScopedEvent" limitedTo: [:method | "conditon limiting installation in a set of methods"|] when: [:reflectopoint | "reflective condition" ] do: [:reflectopoint | "reflective action" ]

Figure 7 :

 7 Figure 7: Core classes of our tracing framework

Script 12 :

 12 Tracing Callbacks conditionCallback ^[ :reflectopoint | self inTracingScope: reflectopoint ] sendCallback ^[ :reflectopoint | reflectopoint disable. (self addGraphNode: reflectopoint) returnValue: (self executeNode: reflectopoint). self return: reflectopoint ] On Script 13 we see these delegate methods in more detail: Script 13: Meta-control methods using the Reflectogram reifications receiver as: Entity -> Flat for: MsgSend limitedTo: [:method | true ] when: [:rpoint | newCallTrace conditionCallback value: rpoint ] do: [:rpoint | newCallTrace sendCallback value: rpoint ]

Table 1 :

 1 Instrumentation Benchmark with Bytecode Instrumentation in the presence of a JIT

	10 6 msg-sends over 100 runs -SLOWDOWN (Bytecode-JIT)
	Case	Time µ (ms) Time σ (ms) Slowdown µ	Slowdown σ
	No instrumentation	9.00 ms	0.00 ms	1.00	0.00
	Disabled instrumentation	9.00 ms	0.00 ms	1.00	0.00
	Before-hook	11.02 ms	0.14 ms	1.22	0.01
	Instead-hook	77.91 ms	0.97 ms	8.66	0.11
	Reflectogram Reification	188.87 ms	6.73 ms	20.98	0.75
	Reflectogram / Instead	-	-	2.42	0.09
	10 6 msg-sends over 100 runs -SLOWDOWN (mSVM-no-JIT)
	Case	Time µ (ms) Time σ (ms) Slowdown µ	Slowdown σ
	No instrumentation	48.10 ms	0.52 ms	1.00	0.00
	Disabled instrumentation	47.52 ms	0.90 ms	0.99	0.02
	Enabled instrumentation	414.08 ms	22.07 ms	8.61	0.48
	Reflectogram Reification	658.08 ms	69.91 ms	13.68	1.46
	Reflectogram / Instead	-	-	1.59	0.19

Table 2 :

 2 Instrumentation Benchmark with a dedicated VM, inline-caching no-JIT

Table 3 :

 3 summarizes the facilities of their corresponding implementations and compares them with our implementations of the reflectogram. Comparison in terms of Meta-Control Facilities

	Iguana/J	Reflex	Gepetto Gepetto-Ext
	[21, 22]	[30]	[24]	[7]
	Temporal		(partially)
	Spatial
	Placement	×
	Level	×	×	×
	Identity	×	×	×	×
		AmbientTalk Bifrost Reflectogram
		[17]	[23]
	Temporal
	Spatial
	Placement	×
	Level	×	×
	Identity		×

http://scg.unibe.ch/research/reflectivity

http://pharo.org/

instance, class, package etc.

http://ss3.gemstone.com/ss/mSVM.html

https://ci.inria.fr/pharo/view/VM/job/PharoSVM/

http://scg.unibe.ch/research/reflectivity

http://scg.unibe.ch/research/OpalCompiler

meaning that the reflective action fully replaces base-level functionality

meaning that the reflective action is executed before the base-level functionality, but not replacing it

http://esug.org.

Acknowledgments

The authors would like to thank Prof. Eric Tanter for his valuable feedbackon the previous version of this work -regarding related literature in the context of AOP and for helping us strengthen our presentation. We will also like to thank our anonymous reviewers for their thorough work and constructive suggestions. This work was partially sponsored by the European Smalltalk Users Group:


Agnieszka Rusinowska
email: rusinowska@gate.cnrs.fr

The not-preference-based Hoede-Bakker index

Keywords: Hoede-Bakker index, feasible strategy, success, failure, decisiveness JEL Classification: C7, D7

The paper concerns a certain modification of the generalized Hoede-Bakker index -a notion defined for a social network of players. In the original Hoede-Bakker set up, preferences of players are involved. It is assumed that a player has an inclination either to accept or to reject a proposal, but due to the influence of others, his final decision may be different from his original inclination. In this paper, we propose the not-preference-based (NPB) generalized Hoede-Bakker index, where feasible strategies instead of players' inclinations are considered. We show that if all feasible strategy profiles are equally probable, then the NPB generalized Hoede-Bakker index is a 'net' Success, i.e., 'Success -Failure', where Success and Failure of a player is defined as the probability that the player is successful and fails, respectively. Moreover, under the assumption of equal probabilities of all feasible strategy profiles, we show that the probability that a player is lucky (Luck) equals the probability that he fails (Failure). Since Success -Luck = Decisiveness, it follows that, under the same assumption, the NPB generalized Hoede-Bakker index is equal to the probability that a player is decisive.

Introduction

The concept of the Hoede-Bakker index has been introduced in the Journal of Mathematical Sociology in 1982 [START_REF] Hoede | A theory of decisional power[END_REF]. Some properties of the Hoede-Bakker index, including its sensitivity to voting power paradoxes, have been analyzed by Rusinowska and De Swart (2007). In [START_REF] Rusinowska | Generalizing and modifying the Hoede-Bakker index[END_REF], a natural generalization of the Hoede-Bakker index, coinciding with the absolute Banzhaf index [START_REF] Banzhaf | Weighted voting doesn't work: a mathematical analysis[END_REF]) has been presented. Moreover, the authors proposed several modifications of the Hoede-Bakker index that coincide with the Rae index [START_REF] Rae | Decision-rules and individual values in constitutional choice[END_REF]), the Coleman indices [START_REF] Coleman | Control of collectivities and the power of a collectivity to act[END_REF][START_REF] Coleman | Individual Interests and Collective Action: Selected Essays[END_REF], and the König-Bräuninger index [START_REF] König | The inclusiveness of European decision rules[END_REF].

In the Hoede-Bakker set up, a social network is considered in which players have to make a decision about accepting or rejecting a given proposal. It is assumed that each player has an inclination either to accept or to reject the proposal. The players may influence each other, and as a consequence of this influence, the final decision of a player may be different from his original inclination. Following [START_REF] Braham | The impossibility of a preference-based power index[END_REF], where the impossibility of a preference-based power index is discussed, we look 'critically' at the Hoede-Bakker index based on players' inclinations. The aim of this paper is to bring the concept of the (generalized) Hoede-Bakker index closer to the measurement of power defined as the ability of a player to affect an outcome. We introduce a not-preference-based (NPB) version of the (generalized) Hoede-Bakker index and investigate what precisely this NPB index measures.

There are basically two approaches to power indices: the axiomatic approach and the probabilistic one. In [START_REF] Straffin | Homogeneity, independence, and power indices[END_REF][START_REF] Straffin | Probability models for power indices[END_REF], two closely related probabilistic models which give the Shapley-Shubik index [START_REF] Shapley | A method for evaluating the distribution of power in a committee system[END_REF] and the absolute Banzhaf index [START_REF] Banzhaf | Weighted voting doesn't work: a mathematical analysis[END_REF], respectively, are proposed. [START_REF] Straffin | Homogeneity, independence, and power indices[END_REF][START_REF] Straffin | Probability models for power indices[END_REF] considers two different assumptions about voting behavior: the independence assumption, which says that 'players vote completely independently' (which is equivalent to assuming that each player will vote 'yes' with probability one half on any given proposal), and the homogeneity assumption, which means that 'a common set of values tends to influence the choices of all players'. Furthermore, Straffin asks the question of effect on outcome, i.e., what is the probability that the vote of a player will make a difference in the outcome. It is proven [START_REF] Straffin | Homogeneity, independence, and power indices[END_REF]) that under the independence assumption, the answer to a player's question of effect on outcome is given by the absolute Banzhaf index of the player, while under the homogeneity assumption, the answer to this question is given by the Shapley-Shubik index of the player. The model also suggests modifications leading to other measures of voting power. One modification concerns the partial homogeneity assumption, according to which there are various blocs of players who are homogeneous among themselves and behave independently of other players. [START_REF] Straffin | Homogeneity, independence, and power indices[END_REF][START_REF] Straffin | Probability models for power indices[END_REF] defines a power index which gives the answer to a player's question of effect on outcome under the partial homogeneity assumption. Another modification is to vary the probability distribution, i.e., to consider a probability distribution different from the uniform one, and to impose the general independence assumption and the general homogeneity assumption. This leads to a number of 'intermediate' indices. [START_REF] Straffin | Probability models for power indices[END_REF] also asks the question of group-individual agreement, i.e., what is the probability that the group decision will agree with a player's decision. This is, of course, the question originally considered by [START_REF] Rae | Decision-rules and individual values in constitutional choice[END_REF]. In [START_REF] Straffin | Probability models for power indices[END_REF], power indices which give the answer to the question of group-individual agreement under the independence assumption and the homogeneity assumption, respectively, are defined.

In this paper, we follow the probabilistic approach, but apply another probabilistic model to the Hoede-Bakker set up, i.e., the model proposed by [START_REF] Laruelle | Assessing success and decisiveness in voting situations[END_REF]. The model will be recapitulated later on. We consider the concepts of (ex ante) Success, (ex ante) Luck, (ex ante) Decisiveness, and (ex ante) Failure of a player, meaning the probability that the player is successful, lucky, decisive, and fails, respectively. We prove that if all vote configurations are equally probable, then (ex ante) Luck is equal to (ex ante) Failure. Consequently, we give an argument against pessimistic thinking that 'It is more likely that I will fail than be successful', by showing that under the assumption of equal probability of all vote configurations, (ex ante) Success is not smaller than (ex ante) Failure. Subsequently, we apply the probabilistic approach to an analysis of the NPB generalized Hoede-Bakker index. We show that if all strategy profiles are equally probable, then the NPB generalized Hoede-Bakker index is a 'net Success', i.e., (ex ante) Success -(ex ante) Failure. Moreover, the relation between (ex ante) Luck and (ex ante) Failure is applied to prove that the NPB generalized Hoede-Bakker index is also equal to (ex ante) Decisiveness if all strategy profiles are equally probable.

The structure of the paper is as follows. In Section 2, we recapitulate the concepts of the Hoede-Bakker index [START_REF] Hoede | A theory of decisional power[END_REF] and the generalized Hoede-Bakker index [START_REF] Rusinowska | Generalizing and modifying the Hoede-Bakker index[END_REF]. Section 3 concerns a modification of the Hoede-Bakker index, introducing the not-preference-based version of this index. In Section 4, we recapitulate the probabilistic model developed in [START_REF] Laruelle | Assessing success and decisiveness in voting situations[END_REF], and we prove the relation between Success and Failure. Using the probabilistic approach, in particular, the relation between Success and Failure proved in Section 4, we show in Section 5 what precisely is measured by the not-preference-based Hoede-Bakker index. Finally, in Section 6, we draw some conclusions. In particular, we discuss the importance of the NPB generalized Hoede-Bakker index and its added value in contrast to the work done by [START_REF] Rae | Decision-rules and individual values in constitutional choice[END_REF] and [START_REF] Straffin | Probability models for power indices[END_REF].

The Hoede-Bakker index

Let us first recapitulate the definition of the Hoede-Bakker index [START_REF] Hoede | A theory of decisional power[END_REF]. We consider the situation in which n ≥ 1 players (actors, voters) have to make an acceptance-rejection decision. Let N = {1, ..., n} be the set of all players. Each actor is supposed to have an inclination either to say 'yes' (denoted by 1) or 'no' (denoted by 0). Let i be an inclination vector (i.e., an n-vector consisting of ones and zeros and indicating the inclinations of the actors), and let I denote the set of all inclination nvectors. Of course, |I| = 2 n . Players may influence each other. Due to influences of the other actors, the final decision of a player may be different from his original inclination. Each inclination vector i ∈ I is then transformed into a decision vector b which is also an n-vector consisting of ones and zeros and indicating the decisions made by all the players. Formally, there is an operator B : I → B(I), that is, b = Bi, where B(I) denotes the set of all decision vectors. We also introduce the group decision gd : B(I) → {+1, -1} which is a function defined on the decision vectors b, having the value +1 if the group decision is 'yes', and the value -1 if the group decision is 'no'. Let i c = (i c 1 , ..., i c n ) denote the complement of i ∈ I, that is, for each k ∈ {1, ..., n}

i c k = 1 if i k = 0 0 if i k = 1 . (1)
Moreover, let

i ≤ i ⇐⇒ {k ∈ N | i k = 1} ⊆ {k ∈ N | i k = 1}. (2)
Let gd(B) be the composition of B and gd. Hoede and Bakker (1982) adopted the following two axioms:

∀i ∈ I [gd(Bi c ) = -gd(Bi)], (3)
∀i ∈ I ∀i ∈ I [i ≤ i ⇒ gd(Bi) ≤ gd(Bi )]. (4)
Axiom [START_REF] Braham | The impossibility of a preference-based power index[END_REF] means that changing all inclinations leads to the opposite group decision. According to axiom (4), the group decision 'yes' cannot be changed into 'no' if the set of players with inclination 'yes' is enlarged.

Given gd(B), the Hoede-Bakker index of player k ∈ N is defined as

HB k (gd(B)) = 1 2 n-1 • {i: i k =1} gd(Bi). (5)
In [START_REF] Rusinowska | Generalizing and modifying the Hoede-Bakker index[END_REF], instead of imposing (3), the authors adopted the following two axioms (together with (4)):

gd(B(i 1 , ..., i n )) = +1, if i k = 1 f or each k = 1, 2, ..., n (6)
gd(B(i 1 , ..., i n )) = -1, if i k = 0 f or each k = 1, 2, ..., n. (7)
If all players have the same inclination, there is no reason to assume that the group decision may be different from this common inclination. Moreover, given gd(B), the generalized Hoede-Bakker index of player k ∈ N is defined by

GHB k (gd(B)) = 1 2 n • ( {i: i k =1} gd(Bi) - {i: i k =0} gd(Bi)). (8)
Example 1 In order to illustrate the notions mentioned above, we consider a three-player social network given in Figure 1. Players 1 and 2 are not influenced, i.e., they always decide according to their own inclinations, but they do influence player 3. Player 3 is assumed to follow players 1 and 2 only if the influencing players have the same inclinations. Otherwise, player 3 just follows his own inclination. Concerning the group decision, in order to stress that the (generalized) Hoede-Bakker index depends on gd(B), we consider two cases. First, we consider a group decision which is equal to the decision of a majority of players (the group decision denoted by gd). This means, of course, that the group decision is 'yes' if and only if at least two players decide for 'yes'. Next, we consider unanimity, i.e., we assume that a group decision is 'yes' if and only if all three players say 'yes' (the group decision denoted by gd ). Table 1 presents the group decision in both cases.

Table 1 Group decision for Figure 1 i Bi gd(Bi) gd (Bi) i Bi gd(Bi) = gd (Bi) (1,1,1) (1,1,1) +1 +1 (0,0,0) (0,0,0) -1 (1,1,0) (1,1,1) +1 +1 (0,0,1) (0,0,0) -1 (1,0,1) (1,0,1) +1 -1 (0,1,0) (0,1,0) -1 (0,1,1) (0,1,1) +1 -1 (1,0,0) (1,0,0) -1
Note that axioms (4), ( 6) and ( 7) are satisfied in both cases. This means that we can calculate the generalized Hoede-Bakker index (see definition ( 8)) for both cases. Axiom

(3) holds if we consider the group decision gd, but it is violated in the case of gd . Hence, we are not able to determine the (original) Hoede-Bakker index if we consider the group decision gd . This shows the restrictiveness of the (original) Hoede-Bakker index as already noticed in Rusinowska and de [START_REF] Rusinowska | Generalizing and modifying the Hoede-Bakker index[END_REF]. By virtue of formulas ( 5) and ( 8), we get the following results:

GHB k (gd(B)) = 3 -1 + 3 -1 8 = 1 2 = 3 -1 4 = HB k (gd(B)) f or k = 1, 2, 3 GHB 1 (gd (B)) = GHB 2 (gd (B)) = 2 -2 + 4 -0 8 = 1 2 GHB 3 (gd (B)) = 1 -3 + 3 -1 8 = 0.
As one can see, switching from gd to gd did not change the generalized Hoede-Bakker index of either player 1 or player 2, but it did decrease the index of player 3.

The not preference-based decisional power index

In [START_REF] Braham | The impossibility of a preference-based power index[END_REF], the authors discuss the impossibility of a preference-based power index. According to the 'core theorem of the measurement of power' (Braham and Holler 2005), 'if power is the ability of k to affect an outcome, then a measure of k's power must exclude any reference to k's preference with respect to affecting that outcome'. Hence, the (generalized) Hoede-Bakker index as based on voters' inclinations cannot be treated as a measure of power (defined as the ability of a player to affect an outcome) if we treat player k's inclination to say 'yes' or 'no' as player k's preference to say 'yes' or 'no'.

In this section, we propose the not-preference-based version of the Hoede-Bakker index. Let N = {1, ..., n} denote, as before, the set of all players (actors). Instead of assuming that player k ∈ N has 'inclination' i k either to say 'yes' (i k = 1) or to say 'no' (i k = 0), we assume that player k chooses a feasible strategy (which we will call just a strategy) f k from among two possibilities: I will say 'yes' (i.e., f k = 1), or I will say 'no' (f k = 0). Choosing strategy f k by player k is equivalent to player k's preliminary decision (i.e., his decision before any influence of others) either to say 'yes' or to say 'no'. As soon as player k has made a preliminary decision about which strategy (s)he chooses, a confrontation with real life takes place, which, as everybody can experience, may bring a lot of influences of the others. Due to influences of other players, a final decision of player k may be different from his feasible strategy (meant as his preliminary decision). Let f = (f 1 , ..., f n ) denote a strategy profile. It is an n-vector consisting of ones and zeros, and indicating strategies (preliminary decisions) of the players. Let F denote the set of all possible strategy profiles. Of course, |F | = 2 n . Similarly as in [START_REF] Hoede | A theory of decisional power[END_REF], we define an operator B : F → B(F ), assigning to each strategy profile f ∈ {1, 0} n , a (final) decision vector B(f ) ∈ {1, 0} n . This covers situations where a player, due to the influence of others, makes a final decision which is different from his preliminary decision (strategy).

In order to see that the preferences (inclinations) of a player do not have to coincide with his strategies, let us consider the following example. A husband has to make a decision about buying an expensive and beautiful house. He would love to buy it, his inclination for buying is 'yes', but he decides not to do it. His strategy, meant as a preliminary decision, is 'no', since such a purchase would bring serious financial problems. He already tries to enjoy the thought how many 'substitutes' he can buy for the money 'saved'. Unfortunately, or fortunately, his wife is quite determined and she uses a typical blackmail. She just says 'either this house or I disappear'. Although the man's preliminary decision was 'no', under the strong influence of his wife, and evaluating all 'for and against', his final decision is 'yes'.

Another example we like to mention concerns a birthday cake. Suppose I am invited for a birthday party of one of my friends. Of course, a very tempting birthday cake will be served during the party. I will have to say either 'yes' (I will try it) or 'no' (I will not). My inclination is positive: I would love to try the birthday cake since the cake has been bought in the best bakery in town. Nevertheless, since I want to realize my New Year decision 'No cakes this year', I choose the strategy 'no'. This is a preliminary decision, made before facing the influence of other players, and with such a strategy I enter my friend's apartment. Nevertheless, since I seem to upset seriously my friend by my strategy, and being influenced additionally by other participants of the party, my final decision is 'yes'.

Similarly as in [START_REF] Hoede | A theory of decisional power[END_REF], we also define a group decision, assigning to each decision vector B(f ), a group decision gdB(f ) ∈ {+1, -1}, where gdB(f ) = +1 if the group decision is 'yes', and gdB(f ) = -1 if the group decision is 'no'. Adopting axioms ( 4), ( 6), [START_REF] König | The inclusiveness of European decision rules[END_REF] with inclination vector i = (i 1 , ..., i n ) ∈ I replaced by strategy profile f = (f 1 , ..., f n ) ∈ F , we propose the following definition: Definition 1 Given the composition gd(B), the not-preference-based (NPB) generalized Hoede-Bakker index of player k ∈ N is given by

GHB k (gd(B)) = 1 2 n • ( {f : f k =1} gd(Bf ) - {f : f k =0} gd(Bf )). ( 9
)
Let us introduce the following notations. Let for k ∈ N

F 1+ k := {f ∈ F | f k = 1 ∧ gd(Bf ) = +1} (10)
F 1- k := {f ∈ F | f k = 1 ∧ gd(Bf ) = -1} (11)
F 0+ k := {f ∈ F | f k = 0 ∧ gd(Bf ) = +1} (12)
F 0- k := {f ∈ F | f k = 0 ∧ gd(Bf ) = -1}. ( 13
)
Using these notations, we can write for

k ∈ N GHB k (gd(B)) = |F 1+ k | -|F 1- k | + |F 0- k | -|F 0+ k | 2 n . ( 14
)
In an analogous way, given the composition gd(B), we can also define the not preferencebased Hoede-Bakker index of player k ∈ N as

HB(k) = 1 2 n-1 • {f : f k =1} gd(Bf ), (15)
and using the notations above, we have for k ∈ N

HB(k) = |F 1+ k | -|F 1- k | 2 n-1 . (16)
Nevertheless, since there seems to be a serious drawback of the (original) Hoede-Bakker index, we will focus on the NPB generalized Hoede-Bakker index.

In the remainder of this paper, we will need more notations, based on the ones introduced above. Let for f = (f 1 , ..., f n ) ∈ F and k ∈ N , f k = (f k 1 , ..., f k n ) be defined as follows:

f k j = f j if j = k 1 -f j if j = k f or j = 1, ..., n. (17)
Moreover, let for k ∈ N

F 1++ k := {f ∈ F 1+ k | gd(Bf k ) = +1} (18)
F 1+- k := {f ∈ F 1+ k | gd(Bf k ) = -1} (19)
F 0-- k := {f ∈ F 0- k | gd(Bf k ) = -1} (20)
F 0-+ k := {f ∈ F 0- k | gd(Bf k ) = +1}. (21)
We have, of course, for k ∈ N

|F 1+ k | = |F 1++ k | + |F 1+- k | (22) |F 0- k | = |F 0-- k | + |F 0-+ k |. ( 23
)
Example 2 Let us consider the example just mentioned above, concerning a decision about buying an expensive and beautiful house. The situation is modeled as a four-player social network given in Figure 2. There are four players in this game: W -wife (player 1), H -husband (player 2), M -mother of W (player 3), and F -father of W (player 4). All players but the husband are not influenced by anyone and they decide according to their strategies. The husband is fully influenced by his wife, and consequently, he always follows her strategy. The parents of the wife do not influence anybody: they have their own strategies which they will follow, but they do not want to influence their children.

The group decision is defined by the majority of the players: they will decide to buy the house if and only if at least three players will say 'yes'. 2 presents the group decision for our example.

Table 2 Group decision for Figure 2 f Bf gd(Bf ) f Bf gd(Bf ) (1, 1, 1, 1) (1, 1, 1, 1) +1 (0, 0, 0, 0) (0, 0, 0, 0) -1 (1, 1, 1, 0) (1, 1, 1, 0) +1 (0, 0, 0, 1) (0, 0, 0, 1) -1 (1, 1, 0, 1) (1, 1, 0, 1) +1 (0, 0, 1, 0) (0, 0, 1, 0) -1 (1, 0, 1, 1) (1, 1, 1, 1) +1 (0, 1, 0, 0) (0, 0, 0, 0) -1 (0, 1, 1, 1) (0, 0, 1, 1) -1 (1, 0, 0, 0) (1, 1, 0, 0) -1 (1, 1, 0, 0) (1, 1, 0, 0) -1 (0, 0, 1, 1) (0, 0, 1, 1) -1 (1, 0, 1, 0) (1, 1, 1, 0) +1 (0, 1, 0, 1) (0, 0, 0, 1) -1 (1, 0, 0, 1) (1, 1, 0, 1) +1 (0, 1, 1, 0) (0, 0, 1, 0) -1 Note that all axioms (4), [START_REF] Hoede | A theory of decisional power[END_REF], and (7) (with inclination vector i = (i 1 , ..., i n ) ∈ I replaced by strategy profile f = (f 1 , ..., f n ) ∈ F ) are satisfied. By virtue of definition ( 9), we get

GHB W (gd(B)) = 6 -2 + 8 -0 16 = 3 4 GHB H (gd(B)) = 3 -5 + 5 -3 16 = 0 GHB M (gd(B)) = GHB F (gd(B)) = 4 -4 + 6 -2 16 = 1 4 .
The NPB generalized Hoede-Bakker index, defined in a social network with possible influences between players, seems to be an interesting notion. The question is what precisely this index measures. In order to answer this question, we apply a probabilistic approach. In Section 4, the probabilistic model, describing the notions of Success, Decisiveness, Failure and Luck will be recapitulated. In particular, in Section 4, we will show the relation between Failure and Luck. Next, this relation will be used in Section 5 to prove what precisely the NPB generalized Hoede-Bakker index measures.

4 Is Failure more likely than Success?

Sometimes in common parlance one misunderstands the difference or relation between the concepts of success, luck, and decisiveness. According to [START_REF] Barry | Is it better to be powerful or lucky?', Part I and Part II[END_REF], a very simple relation between these notions holds: 'Success' = 'Decisiveness' + 'Luck'.

A simple and elegant probabilistic model for measuring 'success' and 'decisiveness' in voting situations has been presented in [START_REF] Laruelle | Assessing success and decisiveness in voting situations[END_REF]. In this paper, we recapitulate some notions of this model, stressing the concept of 'failure'. Once a proposal is submitted, voters cast votes, voting either 'yes' (abstention included) or 'no'. The vote configuration S refers to the result of voting where all voters in S vote 'yes', and all voters in N \ S vote 'no', with N = {1, 2, ..., n}. Hence, k ∈ S means that k's vote was 'yes'. For n voters, there are, of course, 2 n possible vote configurations. The vote configurations leading to the passage of a proposal are called winning configurations. Let W be the set of winning configurations, representing an N -voting rule. A voting rule is assumed to satisfy the following conditions:

(i) N ∈ W (ii) ∅ / ∈ W (iii) If S ∈ W , then T ∈ W for any T containing S (iv) If S ∈ W , then N \ S / ∈ W .
Condition (i) says that the unanimous 'yes' vote configuration leads to the passage of the proposal. Condition (ii) means that the unanimous 'no' vote configuration leads to the rejection of the proposal. According to condition (iii), if a vote configuration is winning, then any other vote configuration containing it is also winning. Condition (iv) means that if a vote configuration S leads to the passage of the proposal, then N \ S leads to its rejection, which implies, of course, that the game is proper. As mentioned in [START_REF] Laruelle | Assessing success and decisiveness in voting situations[END_REF], in certain cases this condition is not necessary. In particular, we do not need condition (iv) in our paper, since all results shown in this paper hold without condition (iv).

We have some 'ex post' concepts that depend on the voting rule used and the resulting vote configurations after a vote is cast [START_REF] Laruelle | Assessing success and decisiveness in voting situations[END_REF]. After a decision is made according to an N -voting rule W , if S is the resulting vote configuration and k ∈ N , -Voter k is said to have been successful in (W, S) if the decision coincides with his vote, that is, iff

(k ∈ S ∈ W ) or (k / ∈ S / ∈ W ) ( 24
)
-Voter k is said to have been decisive in (W, S) if he was successful and his vote was critical for it, that is, iff

(k ∈ S ∈ W and S \ {k} / ∈ W ) or (k / ∈ S / ∈ W and S ∪ {k} ∈ W ) ( 25
)
-Voter k is said to have been lucky in (W, S) if he was successful but irrelevant (i.e., his vote was not critical for it), that is, iff

(k ∈ S ∈ W and S \ {k} ∈ W ) or (k / ∈ S / ∈ W and S ∪ {k} / ∈ W ) (26)
-Voter k is said to have failed in (W, S) if he was not successful in (W, S) (i.e., the decision was different from his vote), that is, iff

(k / ∈ S ∈ W ) or (k ∈ S / ∈ W ). ( 27
)
A probability distribution over all possible vote configurations is incorporated into the model. A probability distribution may be represented by a map p : 2 N → [0, 1], associating with each vote configuration S ⊆ N its probability p(S) of occurring, where S⊆N p(S) = 1. That is, p(S) is the probability that all voters in S vote 'yes', and all voters in N \ S vote 'no'. [START_REF] Laruelle | Assessing success and decisiveness in voting situations[END_REF] consider also the following 'ex ante' concepts, where by 'ex ante' they mean: before the voters cast their votes. Let (W, p) be an N -voting situation, where W is the voting rule to be used and p is the probability distribution over vote configurations, and let k ∈ N . Then:

-Voter k's (ex ante) Success is the probability that k is successful:

SU C k (W, p) := P rob(k is successf ul) = S:k∈S∈W p(S) + S:k / ∈S / ∈W p(S) (28)
-Voter k's (ex ante) Decisiveness is the probability that k is decisive:

D k (W, p) := P rob(k is decisive) = S : k ∈ S ∈ W S \ {k} / ∈ W p(S) + S : k / ∈ S / ∈ W S ∪ {k} ∈ W p(S) (29)
-Voter k's (ex ante) Luck is the probability that k is lucky:

L k (W, p) := P rob(k is lucky) = S : k ∈ S S \ {k} ∈ W p(S) + S : k / ∈ S S ∪ {k} / ∈ W p(S) (30)
-Voter k's (ex ante) Failure is the probability that k fails:

F AIL k (W, p) := P rob(k f ails) = S:k / ∈S∈W p(S) + S:k∈S / ∈W p(S). (31)
For any voting rule W , probability distribution p and voter k, we have

SU C k (W, p) = D k (W, p) + L k (W, p) (32)
F AIL k (W, p) + SU C k (W, p) = S⊆N p(S) = 1. (33)
From the last two equations, one may immediately derive, for an arbitrary probability distribution p, that F AIL k (W, p) ≤ 1 -D k (W, p) and F AIL k (W, p) ≤ 1 -L k (W, p). This means, of course, that not being decisive is at least as likely as failing, and not being lucky is at least as likely as failing.

Let us assume that all vote configurations are equally probable, that is,

p * (S) := 1 2 n f or each S ⊆ N. (34)
The following theorem holds.

Theorem 1 If all vote configurations are equally probable, then (ex ante) Luck of a voter is equal to (ex ante) Failure of this voter, and it is not greater than 1 2 , that is, for any voting rule W and any voter k

∈ N L k (W, p * ) = F AIL k (W, p * ) ≤ 1 2 . ( 35
)
Proof. Note that, for each k ∈ N

|{S : k ∈ S ∧ S \ {k} ∈ W }| = |{S : k / ∈ S ∧ S ∈ W }| (36)
|{S : k / ∈ S ∧ S ∪ {k} / ∈ W }| = |{S : k ∈ S ∧ S / ∈ W }|. (37)
Hence, from equations (34), ( 36) and (37), we get for any W and k,

S : k ∈ S S \ {k} ∈ W p * (S) = S:k / ∈S∈W p * (S), (38)
S : k / ∈ S S ∪ {k} / ∈ W p * (S) = S:k∈S / ∈W p * (S), (39)
and therefore, by virtue of (30) and (31), L k (W, p * ) = F AIL k (W, p * ). Moreover, by virtue of (32) and (33

), 2F AIL k (W, p * ) + D k (W, p * ) = 1, and since D k (W, p * ) ≥ 0, we get F AIL k (W, p * ) ≤ 1 2 .
Since F AIL k (W, p * ) ≤ 1 2 for any W and k, then using (33), we immediately conclude that SU C k (W, p * ) ≥ 1 2 which means that Conclusion 1 If all vote configurations are equally probable, then (ex ante) Failure is not greater than (ex ante) Success, that is, for any voting rule W and any voter k

∈ N F AIL k (W, p * ) ≤ SU C k (W, p * ). ( 40
)
This conclusion is an argument against all pessimists who say that it is more likely to fail than to be successful. The situation is, in fact, the opposite if all vote configurations are equally probable. In Section 5, we will apply the probabilistic model recapitulated in this section, in particular, Theorem 1, to the analysis of the NPB generalized Hoede-Bakker index.

5 What do we measure?

The question arises what precisely is measured by the NPB generalized Hoede-Bakker index. Is it Decisiveness, Success, or maybe something else? In order to answer this question, we apply the probabilistic approach [START_REF] Laruelle | Assessing success and decisiveness in voting situations[END_REF] to the notions introduced in this paper. As recapitulated in the previous section, we assume vote configurations S (possible results of voting) and the set W of winning configurations, representing an N -voting rule. In our analysis, we do not consider B(f ) (decision vector) and gd (group decision) separately, but we consider strategy profiles f and the composition gd(B). While the 'ex post' concepts considered in [START_REF] Laruelle | Assessing success and decisiveness in voting situations[END_REF] depend on the voting rule and the resulting vote configuration after a vote is cast, our 'ext post' concepts depend on the composition gd(B) and the strategy profile f . Similarly, while the 'ex ante' concepts in [START_REF] Laruelle | Assessing success and decisiveness in voting situations[END_REF] concern the situation before the voters cast their votes, our 'ex ante' notions concern the situation before the voters choose their feasible strategies. We propose the following equivalent concepts:

-k's vote is 'yes' iff k's strategy is 'yes' / k ∈ S iff f k = 1.
-W is equivalent to F + representing gd(B), where

F + = {f ∈ F | gd(Bf ) = +1}. ( 41
)
-We impose a condition equivalent to condition (34):

p * (f ) := 1 2 n f or each f ∈ F. (42)
-Conditions (i), (ii), (iii), and (iv) in Section 4 are by definition equivalent to axioms ( 6), ( 7), (4), and (3), but with f ∈ F instead of i ∈ I, respectively. -Voter k is said to have been successful under (gd(B), f ) iff

f ∈ F 1+ k or f ∈ F 0- k . (43)
-Voter k is said to have failed under (gd(B), f ) iff

f ∈ F 0+ k or f ∈ F 1- k . (44)
-Voter k is said to have been decisive under (gd(B), f ) iff

f ∈ F 1+- k or f ∈ F 0-+ k . ( 45
)
-Voter k is said to have been lucky under (gd(B), f ) iff

f ∈ F 1++ k or f ∈ F 0-- k . ( 46
)
-Let us assume that all strategy profiles are equally probable. Then: Voter k's (ex ante) Success is equal to:

SU C k (gd(B), p * ) = |F 1+ k | + |F 0- k | 2 n , (47)
Voter k's (ex ante) Failure is equal to:

F AIL k (gd(B), p * ) = |F 0+ k | + |F 1- k | 2 n , (48)
Voter k's (ex ante) Decisiveness is equal to:

D k (gd(B), p * ) = |F 1+- k | + |F 0-+ k | 2 n , (49)
Voter k's (ex ante) Luck is equal to:

L k (gd(B), p * ) = |F 1++ k | + |F 0-- k | 2 n . ( 50
)
For any gd(B) and k ∈ N , we have

SU C k (gd(B), p * ) = D k (gd(B), p * ) + L k (gd(B), p * ), (51)
F AIL k (gd(B), p * ) + SU C k (gd(B), p * ) = 1. ( 52
)
-It is also true (see Theorem 1) that for any gd(B) and k ∈ N :

L k (gd(B), p * ) = F AIL k (gd(B), p * ). ( 53
)
By virtue of ( 14), (47), and (48), we get that if all strategy profiles are equally probable, then the NPB generalized Hoede-Bakker index is equal to

(ex ante) Success -(ex ante) F ailure, (54)
that is,

* ) = SU C k (gd(B), p * ) -L k (gd(B), p * ) = SU C k (gd(B), p * ) -F AIL k (gd(B), p * ) = GHB k (gd(B)).
This result is in the line with the result obtained in [START_REF] Rusinowska | Generalizing and modifying the Hoede-Bakker index[END_REF], where using a different method it was shown that the generalized Hoede-Bakker index of a player is equal to the probability that the player is decisive, and consequently, that the generalized Hoede-Bakker index coincides with the absolute Banzhaf index. This result was shown under assumptions that all vote configurations (coalitions) as well as all inclination vectors are equally probable.

Conclusions

The original Hoede-Bakker index is based on players' inclinations which may be understood as players' preferences. In the NPB (generalized) Hoede-Bakker index we do not refer to players' inclinations, but to players' strategies treated as preliminary decisions. For many reasons, my real preferences do not have to coincide with my plans (strategies). My final decision may be also different from my strategy if someone is able to influence my preliminary decision. What does our not-preference-based index measure? In order to answer this question we consider the concepts of (ex ante) Success, (ex ante) Decisiveness, (ex ante) Luck, and (ex ante) Failure of a player, meaning the probability that the player is successful, decisive, lucky, and fails, respectively. We show that if all strategy profiles are equally probable, then the NPB Hoede-Bakker index is equal to '(ex ante) Success -(ex ante) Failure' which we can call the 'net Success'. On the other hand, if all strategy profiles are equally probable, '(ex ante) Luck' is equal to '(ex ante) Failure', and consequently, '(ex ante) Success -(ex ante) Failure' is equal to '(ex ante) Decisiveness'. Hence, the NPB (generalized) Hoede-Bakker index of a player is equal to the probability that the player is decisive if all strategy profiles are assumed to be equally probable. Of course, strategy profiles which count for (ex ante) Luck of a player are different from the strategy profiles which count for (ex ante) Failure of the player, since being lucky means that the player is successful but irrelevant, while failing means that the player is not successful. But what we have proved is that the probability that a player is lucky is equal to the probability that the player fails if all strategy profiles are equally probable.

What is the added value of the NPB generalized Hoede-Bakker index in contrast to other established measures? First of all, our NPB Hoede-Bakker index is defined for a social network, where players may influence each other when making decisions. The fact that the NPB Hoede-Bakker index takes into account the distinction between the strategy of a player (his preliminary decision) and his final decision, contributes to the originality of the NPB Hoede-Bakker index. From this point of view, it seems to be interesting and innovative to deliver a deeper analysis of the measure defined in a set up different from the one in which most measures have been defined. Since many real situations may be represented by a social network with influences between actors, the analysis of different measures in a social network is of importance.

Apart from the evident relation to the model introduced by Laruelle and Valenciano (2005), the paper is, of course, also related to the works done by [START_REF] Rae | Decision-rules and individual values in constitutional choice[END_REF] and [START_REF] Straffin | Probability models for power indices[END_REF]. In [START_REF] Rae | Decision-rules and individual values in constitutional choice[END_REF] and [START_REF] Straffin | Probability models for power indices[END_REF], indices which give the answer to the question of group-individual agreement, or differently speaking, to the question of Success of a player, are introduced and analyzed. [START_REF] Straffin | Homogeneity, independence, and power indices[END_REF][START_REF] Straffin | Probability models for power indices[END_REF]) also introduces indices which give the answer to the question of effect on the outcome, or differently speaking, to the question of Decisiveness of a player. Although related to the notion of Success, our NPB generalized Hoede-Bakker index happens to be 'net Success = Success -Failure', if all strategy profiles are equally probable. Hence, the NPB generalized Hoede-Bakker index is a measure still different from the notion of Success. The question appears, why one should be interested in measuring 'net Success'. First of all, we agree that 'the question of effect on the outcome may not be the best one for political theorists and legislators to ask, and they may be more interested in the question of group-individual agreement' [START_REF] Straffin | Probability models for power indices[END_REF]. This would support the motivation for the interest not only in Decisiveness, but also in Success. Nevertheless, we find looking only at Success somewhat 'too optimistic'. If a player only focuses on the measure which tells him whether the group decision coincides with his strategy, he does not have to see explicitly when the group decision was different from his strategy. From this point of view, the NPB generalized Hoede-Bakker index seems to show reality better than Success. We may have reasons to be happy, because of our Success, but we also must see our Failure. Another interesting aspect of the NPB generalized Hoede-Bakker index is its relation with Decisiveness. We have proved that if all strategy profiles are equally probable, then the NPB generalized Hoede-Bakker index of a player is equal to the Decisiveness, defined as the probability that a player is decisive. First of all, this gives us technical support when calculating different measures in a social network. As one may easily realize, calculating Success is technically easier than calculating Decisiveness. When we determine Success of a player, for each strategy profile, we must only check whether the group decision resulting from this profile coincides with the strategy of the given player or not. We do not have to worry about whether this would also be the case if the player changed his strategy on his own. With our result that the NPB generalized Hoede-Bakker index is equal to Decisiveness (under the assumption

Figure 1 A

 1 Figure 1 A three-player social network

Figure 2 Ac

 2 Figure 2 A four-player social network

Corollary 1 Corollary 2

 12 Given gd(B), for each k ∈ N GHB k (gd(B)) = SU C k (gd(B), p * ) -F AIL k (gd(B), p * ). Given gd(B), for each k ∈ N GHB k (gd(B)) = D k (gd(B), p * ). (56)Proof. By virtue of (51), (53), and (55), we have for each k ∈ N D k (gd(B), p

of equal probability of all strategy profiles), the only thing which we have to count is Success. When we have calculated Success, we get immediately Failure, since Success and Failure together cover all possibilities, and next, thanks to our result on the NPB generalized Hoede-Bakker index, we get immediately Decisiveness.

Summarizing, there are at least three components which contribute to the importance of the NPB generalized Hoede-Bakker index. First of all, this not-preference-based and refined index is defined for a social network, and hence, may be useful for an analysis of many real life situations. Next, as a 'net Success' it seems to be more realistic than Success, since it takes into account both Success and Failure. Finally, it simplifies calculations when determining different measures in a social network, giving, in particular, an immediate answer to the question of Decisiveness.