Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use index number in Signals? #183

Open
cdupont opened this issue May 5, 2017 · 2 comments
Open

Use index number in Signals? #183

cdupont opened this issue May 5, 2017 · 2 comments
Labels

Comments

@cdupont
Copy link
Collaborator

cdupont commented May 5, 2017

The Signals that already fired are now stored in the EventInfo:

 data EventInfoN n = forall a. (Typeable a, Show a) =>
    EventInfo {_eventNumber :: EventNumber,
               event        :: EventM n a,
               handler      :: (EventNumber, a) -> n (),
               _evStatus    :: Status,
               _env         :: [SignalOccurence]}

The signals are stored in a list of SignalOccurence, together with the SignalAddress:

data SignalOccurence = SignalOccurence {_signalOccData    :: SignalData,
                                        _signalOccAddress :: SignalAddress}

data SignalData = forall s a. (Typeable s, Typeable a, Show s, Show a, Eq s) =>
    SignalData {signal     :: Signal s a,
                signalData :: a}

data Signal s a where
   Signal :: s -> Signal s a

SignalAddress is a list of directions in the Event tree:

data SignalAddressElem = SumR | SumL | AppR | AppL | BindR | BindL | Shortcut deriving (Show, Read, Ord, Eq, Generic)

It is necessary that the signal occurrence points to the right signal in the event tree, otherwise one signal occurrence could fire several signals in the event tree.

An alternative design is to assign a number to the Signals in the event tree, and to use this number when storing the signal occurrence. However it is necessary to assign numbers to signals in the event tree, when receiving the event.

Advantages of the current design:

  • the Event tree can be received/stored without modification.
  • no internal is leaked toward the user (such as signal number placeholder)

Inconvenient:

  • the Signal address is clumsy and complexify the traversals
  • the Signal address is dependent on the Event tree format

Advantages of the alternative design:

  • simpler

Inconvenient:

  • need to modify the event tree before storing
  • the number can be tampered with
  • more error prone (need to check the unicity of numbers)
  • possibly exposes some internal
@cdupont
Copy link
Collaborator Author

cdupont commented May 5, 2017

data EventM n a where
    SignalEvent    :: (Eq s, Typeable s, Show s, Typeable a, Show a) => Signal s a -> EventM n a
   (...)

The s parameter is use only to recognize the signal when looking for it in the event tree using the Eq constraint.

We could add another constraint HasSignalNumber:

class HasSignalNumber s where
   signalNumber s :: Maybe Int
   signalNumber _ = Nothing

@cdupont
Copy link
Collaborator Author

cdupont commented May 5, 2017

Another possibility is to number the element of the tree depth-first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant