There is a bug in NeoHaskell's action system that prevents actions from being executed when used inside nested modules. This issue arises because of how actions are serialized and then deserialized using Data.Dynamic, which fails to properly match the event types of nested modules.
Details
NeoHaskell adopts a structure similar to the Elm architecture, but instead of calling commands "commands," NeoHaskell refers to them as "actions." For example, to read a file, you use the readText action, which publishes an object into a queue for asynchronous execution by an action worker. Importantly, the submission and execution of actions are entirely decoupled, leading to serialization of the action into an UnknownValue (Data.Dynamic).
Actions in NeoHaskell are polymorphic over a type variable representing the event type, similar to Elm's message type system. The main process is as follows:
Event Registration: At the beginning of the application, action handlers are registered for the main event type of the user application. For example, the readTextHandler is registered for the main event type.
Issue with Nested Modules: When attempting to execute actions within nested modules, actions are not executed because the Data.Dynamic type casting process expects the top-level event type of the user application rather than the nested module's event type. This mismatch causes the action handler to fail, and thus, actions in nested modules are not executed.
Problem Scenario
If a user tries to perform an action, such as reading a file inside a nested module, the action will not execute because the action handler is looking for the top-level event type instead of the nested module's event type.
Proposed Solution
To address this issue, we need to modify NeoHaskell's initialization process to ensure that nested modules are treated as part of the user application. Specifically, we should:
Register Nested Module Handlers: Ensure that action handlers are registered for nested modules in addition to the main application module. This will allow nested modules to manage their own event types and ensure their actions are executed properly.
Multiple Registrations: By registering handlers for nested modules, actions will be registered multiple times for the appropriate event types, avoiding type mismatches during execution.
Action Items
Update the initialization process to include nested modules as part of the user application.
Ensure that action handlers can be registered multiple times for different event types corresponding to nested modules.
Validate that actions in nested modules execute correctly without type casting errors.
NickSeagull
commented
1 month ago
Description
There is a bug in NeoHaskell's action system that prevents actions from being executed when used inside nested modules. This issue arises because of how actions are serialized and then deserialized using
Data.Dynamic, which fails to properly match the event types of nested modules.Details
NeoHaskell adopts a structure similar to the Elm architecture, but instead of calling commands "commands," NeoHaskell refers to them as "actions." For example, to read a file, you use the
readTextaction, which publishes an object into a queue for asynchronous execution by an action worker. Importantly, the submission and execution of actions are entirely decoupled, leading to serialization of the action into anUnknownValue(Data.Dynamic).Actions in NeoHaskell are polymorphic over a type variable representing the event type, similar to Elm's message type system. The main process is as follows:
Event Registration: At the beginning of the application, action handlers are registered for the main event type of the user application. For example, the
readTextHandleris registered for the main event type.Issue with Nested Modules: When attempting to execute actions within nested modules, actions are not executed because the
Data.Dynamictype casting process expects the top-level event type of the user application rather than the nested module's event type. This mismatch causes the action handler to fail, and thus, actions in nested modules are not executed.Problem Scenario
If a user tries to perform an action, such as reading a file inside a nested module, the action will not execute because the action handler is looking for the top-level event type instead of the nested module's event type.
Proposed Solution
To address this issue, we need to modify NeoHaskell's initialization process to ensure that nested modules are treated as part of the user application. Specifically, we should:
Action Items