This Elixir function finds the first character in a string that does not repeat. It first constructs a map to store the frequency of each character. Then, it iterates through the string again, returning the first charact...

The `first_non_repeating_char` function first handles the edge case of an empty string by returning `nil`. For non-empty strings, it calls `build_frequency_map` to create a map where keys are characters and values are their counts. This map is built by iterating through the string once using `Enum.reduce`. The `build_frequency_map` helper uses `Map.update` to efficiently increment counts. Subsequently, `find_first_unique` iterates through the original string again. For each character, it checks its count in the `frequency_map`. If the count is 1, that character is returned immediately. If no such character is found after checking the entire string, `Enum.find_value` implicitly returns `nil`. The time complexity is O(N) because we iterate through the string twice, and map operations are O(1) on average. The space complexity is O(K), where K is the number of unique characters in the string, to store the frequency map.

FUNCTION first_non_repeating_char(string): IF string is empty THEN RETURN null END IF CREATE an empty map called frequency_map FOR EACH character in string: INCREMENT count for character in frequency_map END FOR FOR EACH...

This Elixir function implements an iterative binary search algorithm to find a target integer within a sorted list. It works by repeatedly dividing the search interval in half. If the target is less than the middle eleme...

The `iterative_binary_search` function initializes the search boundaries `low` to 0 and `high` to the last index of the `sorted_list`. It then calls the `perform_search` helper function. The `perform_search` function iteratively checks if `low` is less than or equal to `high`. If it is, it calculates the `mid` index. The element at `mid` is compared to the `target`. If they match, the index `mid` is returned wrapped in `{:ok, mid}`. If the `middle_element` is less than the `target`, the search continues in the right half by recursively calling `perform_search` with `low` set to `mid + 1`. If the `middle_element` is greater than the `target`, the search continues in the left half by recursively calling `perform_search` with `high` set to `mid - 1`. If `low` becomes greater than `high`, it means the target is not present in the list, and `:not_found` is returned. The time complexity is O(log N) because the search space is halved in each step. The space complexity is O(1) for the iterative version, as it only uses a few variables to keep track of the search boundaries. Note that `Enum.at/2` on Elixir lists is O(N), making the effective complexity O(N log N) for lists. For true O(log N), one would use `Array` or `Vector` which offer O(1) element access.

FUNCTION iterative_binary_search(sorted_list, target): IF sorted_list is empty THEN RETURN "not_found" END IF SET low = 0 SET high = length(sorted_list) - 1 WHILE low <= high: SET mid = low + floor((high - low) / 2) SET...

This Elixir code demonstrates distributed process communication using `GenServer` and `ETS` for a process registry. The `Registry` module allows processes to register themselves by name and other processes to look them u...

The `DistributedMessenger.Registry` uses `GenServer` to manage a local `ETS` table. `ETS` (Erlang Term Storage) is a high-performance, in-memory data store suitable for this purpose. The `register/2`, `lookup/1`, and `unregister/1` functions provide a GenServer API to interact with the `ETS` table, mapping process names to their PIDs. The `Worker` module starts as a `GenServer`, registers its PID with the `Registry` using its given name, and then waits for messages. When a `{:process_message, sender_pid, message}` is received, it processes it, increments a counter, and sends a `{:processed, name, :ok}` reply back to the `sender_pid`. The `Client` module uses `Registry.lookup/1` to find the target PID. If found, it sends the message using `send/2` and then uses `receive/1` to wait for a specific reply, including a timeout. The `Worker.terminate/2` callback ensures that the process is unregistered from the `Registry` when it shuts down. This system allows for dynamic discovery and communication between processes, even across different nodes in an Elixir cluster. The time complexity for registry operations is typically O(1) on average for ETS. Message sending and receiving are also O(1) in terms of network hops for local processes, but can involve serialization/deserialization overhead for remote processes. Space complexity is O(N) for the registry, where N is the number of registered processes, and O(S) for each worker's state.

Define a Registry module (GenServer). In init, create an ETS table. Implement handle_call for: {:register, name, pid}: Insert name-pid into ETS. {:lookup, name}: Lookup name in ETS, return pid or :not_found. {:unregister...

This Elixir code implements an event sourcing aggregate root for an `Account`. The `Account` module maintains its state (balance, version) by replaying a list of events. When a new event is to be applied, it checks for v...

The `Account` module uses `GenServer` to manage the state of an account aggregate. The state includes `account_id`, `balance`, `version`, and a list of `events`. The `init/1` callback takes an `account_id` and a list of `initial_events`. It uses `replay_events/2` to reconstruct the aggregate's state by iterating through these events and applying them sequentially using `apply_event_to_state/2`. The `apply_event_to_state/2` function handles different event types (`:account_created`, `:deposit`, `:withdraw`), updating the balance and incrementing the version. Crucially, `handle_call({:apply_event, event}, ...)` checks if the incoming `event.version` is exactly one greater than the aggregate's current `state.version`. This is the version conflict check: if it fails, the event is rejected, preventing out-of-order application. If the version is correct, the event is applied, and the aggregate's version is updated. The `Account.Registry` module (a separate GenServer with ETS) is used to manage the PIDs of active account aggregates, allowing them to be found by `account_id`. This ensures that only one process represents a given account at a time, preventing race conditions. The time complexity for replaying N events is O(N * E), where E is the complexity of applying a single event. Applying a new event is O(E) plus the cost of appending to the events list (which can be O(L) if not optimized, where L is the number of stored events). Space complexity is O(N * E_size) to store N events, where E_size is the average size of an event.

Define `Account` module (GenServer). State: `account_id`, `balance`, `version`, `events`. In `init({account_id, initial_events})`: Initialize state with 0 balance and version 0. Replay `initial_events` to reconstruct sta...

This Elixir code defines a fault-tolerant data processing pipeline using the `with` statement. Each stage of the pipeline is a separate function that returns either `{:ok, result}` on success or `{:error, reason}` on fai...

The `Pipeline.process/1` function utilizes Elixir's `with` statement for sequential execution and error handling. The `with` statement evaluates each clause from top to bottom. If a clause matches (e.g., `{:ok, stage1_result} <- stage1(data)`), the matched value is bound to the variable (`stage1_result`), and execution proceeds to the next clause. If a clause does not match (e.g., `stage1(data)` returns `{:error, reason}`), the `with` statement immediately exits and evaluates the `else` block. The `else` block catches the first matching pattern, in this case, `{:error, reason}`, allowing for specific error reporting. If no `{:error, reason}` is returned but the `with` statement fails for another reason, the catch-all `_` pattern handles it. Each stage function (`stage1`, `stage2`, `stage3`) is designed to return either `{:ok, value}` or `{:error, reason}`, making them composable within the `with` statement. This ensures that the pipeline is fault-tolerant; a failure in any stage prevents subsequent stages from executing with potentially invalid data. The time complexity of the pipeline is O(S), where S is the number of stages, as each stage is executed at most once. Space complexity is O(1) beyond the input data, as intermediate results are passed directly between stages.

Define a `process` function that takes data. Use a `with` statement: Clause 1: `{:ok, result1} <- stage1(data)` Clause 2: `{:ok, result2} <- stage2(result1)` Clause 3: `{:ok, result3} <- stage3(result2)` ... (more stages...

This Elixir code defines a supervisor that manages a single worker process. The supervisor is configured with a `:one_for_one` restart strategy, meaning if a child process crashes, only that specific child will be restar...

The `MyApp.Supervisor` module uses Elixir's `Supervisor` behavior to manage child processes. The `init/1` callback defines the children and the supervisor's options. The `:one_for_one` strategy ensures that if `MyApp.Worker` crashes (e.g., due to an exception in `handle_info(:crash, state)`), the supervisor will attempt to restart only `MyApp.Worker`. The `max_restarts` and `max_seconds` options prevent runaway restarts by limiting the number of restarts within a given time frame. The `MyApp.Worker` is a `GenServer` that maintains a simple counter state. Its `handle_call/3` function handles synchronous requests to increment the counter, and `handle_info/2` is used to simulate a crash. The time complexity for starting the supervisor and its children is O(N), where N is the number of children. Space complexity is O(1) for the supervisor itself, and O(S) for each worker, where S is the size of its state.

Define a Supervisor module. In the init callback: Define a list of child specifications. Set the supervisor strategy to :one_for_one. Configure max_restarts and max_seconds. Return {:ok, {self(), opts, children}}. Define...

This Elixir GenServer implements a state machine. It allows for defined transitions between states based on incoming events. The `perform_transition/2` helper function dictates the valid state changes. This pattern is fu...

The `StateMachine` module uses `GenServer` to maintain its current state. The `init/1` callback sets the initial state. `handle_call(:get_state, ...)` provides a way to query the current state without altering it. `handle_cast({:transition, event}, ...)` is the core of the state machine; it receives an event and uses the `perform_transition/2` helper to determine the next state. If the transition is valid, the state is updated; otherwise, an error is logged, and the state remains unchanged. The `perform_transition/2` function uses pattern matching to define valid state-event pairs, returning `{:ok, next_state}` for valid transitions and `:invalid_transition` otherwise. This ensures that only permitted state changes occur. The time complexity for a transition is O(1) due to pattern matching. Space complexity is O(S) where S is the size of the state data.

Define a GenServer module. Implement `start_link` to initialize with an initial state. Implement `transition` (cast) and `get_state` (call) client functions. In `init`, store the initial state. In `handle_call(:get_state...

This Elixir code demonstrates advanced stream processing using Elixir's `Stream` module. It chains multiple transformations: an initial mapping to modify each element, a filtering step to select specific elements, and a...

The `StreamProcessor.process_stream/1` function takes an Elixir `Stream` as input and applies a sequence of transformations using the pipe operator (`|>`). The first transformation, `Stream.map(&transform_initial/1)`, doubles each number and adds 1. The second, `Stream.filter(&filter_intermediate/1)`, keeps only numbers that are both odd and greater than 5. The third transformation, `Stream.map(&transform_final/1)`, applies conditional logic: if the number is even, it's squared; if it's odd, 10 is added. Finally, `Enum.to_list/1` consumes the stream, forcing the evaluation of all transformations and collecting the results into a list. The lazy nature of `Stream` ensures that memory usage remains low, as only one element (and its intermediate transformed states) is processed at a time. The `sample_stream/1` function generates a finite stream for demonstration. The time complexity is O(N * T), where N is the number of elements in the stream and T is the average time complexity of the transformations. Since the transformations are O(1) each, the overall time complexity is O(N). The space complexity is O(1) for the stream processing itself (excluding the final list), as only one element is held in memory at any given time during the transformation pipeline.

Define a `process_stream` function that accepts a stream. Pipe the stream through a series of transformations: 1. `Stream.map(&transform_initial/1)`: For each element, apply `transform_initial`. `transform_initial` doubl...