Haskell good first issues

This issue describes a performance anomaly in Haskell benchmarks where earlier benchmarks in a group appear to negatively impact the execution time of later benchmarks. When run individually, the later benchmarks perform significantly faster, suggesting an interference or resource contention issue when benchmarks are executed sequentially within the same process. The user is seeking a solution or a way to run each benchmark in a separate process.

The `morph --deep` command incorrectly fires the lambda of a dispatch target before reducing the dispatch itself, leading to inconsistent results compared to the top-level run. This bug causes formations with both a lambda and a dispatched attribute to be unreachable during a deep walk. The proposed fix is to reduce the dispatch before descending into the target, mirroring the behavior of the top-level run.

A program that doesn't start with 'serve' can hang indefinitely if it asks a question by reference. This happens because the program's input channel is closed, but the system attempts to send an answer, leading to a deadlock. The issue proposes adding a check similar to the 'served' function to prevent this hang.

This issue proposes adding a new `ebnf` command to the project. This command should output the project's grammar in Extended Backus-Naur Form (EBNF) format, specifically tailored for LaTeX inclusion using the `naive-ebnf` package. The example provided shows the desired output structure.

This issue describes a bug where rewriting data objects incorrectly binds their bytes to `as-bytes`, leading to literals reducing to `⊥` (bottom) in the eo-runtime. This is due to changes in how `number` and `string` voids are declared, making the `as-bytes` binding obsolete for them. The problem affects various parts of the system, including XMIR writers and sweet printers, and prevents other issues from being merged.

The release workflow for `ubuntu-24.04` binaries has been failing since version 0.0.117 due to a conflict between two GHCup installations on the runner. This prevents new binaries from being published, causing downstream consumers to receive 403 errors when trying to access them.

This issue proposes adding a new GitHub Actions workflow to test the round-trip capability of the `objectionary/home` repository through the `phino` tool. The workflow will parse XMIR files, rewrite them using `phino`, regenerate `.eo` sources from the rewritten XMIR, and then compare the dataization results before and after this process to catch reader and printer bugs.

The XMIR reader incorrectly rejects applied `base="⊥"` elements, despite the `dc`/`dca` rules defining their reduction. This prevents many XMIR documents from being parsed, as applied terminators are common in practice. The proposed solution is to replace the restrictive guard with a more general application handling mechanism, aligning with existing `Φ` and `ξ` branches.

This issue describes a bug in how the `domain` count is handled in the `phino` rewrite system. Specifically, a bound `ρ` (rho) is still being counted as a positional slot, preventing dispatched atoms from saturating correctly. The proposed fix is to exclude `ρ` from the `domain` count when it's bound, similar to how void `ρ` is already excluded.

This issue describes a bug where compilation errors are not reported to STDERR when the output is redirected to STDOUT using the `--output=/dev/stdout` flag in Gren. When output is directed to a file, errors are correctly sent to STDERR, but this behavior breaks when STDOUT is used for output.

This issue proposes the implementation of a Piet interpreter, a visual esoteric programming language. It lists existing interpreters and compilers, and outlines desired features like support for different image formats (PPM P3/P6, XPM) and LLVM integration, with several dependencies on other issues.

The current CORS implementation in Hydra allows any origin to access the API, creating a potential security vulnerability. The suggested fix is to replace the generic CORS middleware with a more restrictive one that enforces a same-origin policy, controlled by a CLI flag.

The Hydra TUI incorrectly recalculates the contestation deadline after a `EventLogRotated` event. This leads to the displayed deadline being significantly in the future, potentially causing users to miss the actual fanout window. The fix involves reading the correct contestation deadline directly from the `State.ClosedState`.

The `prettyDatumUtxo` function in the Hydra Cardano API has a bug where it calls `error "absurd"` on a constructor (`TxOutSupplementalDatum`) that can be legally passed to it. While currently unreachable due to how it's called, this could cause crashes in debug or error logging scenarios. The suggested fix is to either constrain the function's type or properly handle the supplemental datum.

This issue highlights a lack of end-to-end test coverage for the `canSideLoadSnapshot` and `SideLoadSnapshot` functions in Hydra. Specifically, it points out that scenarios for sideloading snapshots with different `headId`, invalid multisigs, or conflicting on-chain state are missing. The suggested fix is to add these negative test cases to prevent regressions, similar to a bug fixed in a recent PR.

The HTTP server's "wait for completion" handlers for recovering commits, decommits, and snapshot loading are not correctly correlating events to specific requests. This means that if two clients make concurrent requests, they might receive the results of each other's operations, leading to incorrect behavior. The fix involves adding identifier matching to ensure events are correctly linked to their originating requests.

This issue highlights a missing test case for JSON roundtripping of `SeenSnapshot`. The current implementation excludes `signableBytes` from JSON encoding and reconstructs it later, but there's no test to ensure this reconstruction correctly preserves the original `AckSn` signatures. This could lead to silent failures in snapshot confirmation after a restart if the encoded and decoded representations diverge.

The `mkThreadId` function in Hydra Logging silently returns 0 when parsing a `ThreadId` fails. This can lead to all log lines showing `threadId: 0`, making it impossible to distinguish between different threads in traces. A suggested fix is to hash the displayed form or use the string verbatim on parse failure to maintain distinguishability.

The current implementation of authenticated messages in the Hydra node discards the signature after verification. This means that there is no on-disk evidence to prove the authorship of a message for audit or replay purposes, which could be problematic for dispute resolution.

The monitoring port in the Hydra node currently binds to all network interfaces, exposing metrics publicly. This is inconsistent with the API host, which defaults to localhost. The suggested fix is to add a `--monitoring-host` option to allow users to specify the binding interface, defaulting to localhost for security and consistency.

The `validateRunOptions` function in Hydra Node incorrectly accepts an empty `hydraScriptsTxId`, leading to potential misconfigurations where the network cross-check is skipped. This can cause the CLI to submit to the wrong chain without immediate error. The suggested fix involves enforcing that `hydraScriptsTxId` is not empty and ensuring the `--network` flag correctly matches the specified network.

The `incrementTx` function in Hydra crashes when `depositScriptUTxO` is empty due to an unguarded call to `List.head`. This can happen if a lookup fails, leading to a `Prelude.head: empty list` error. The suggested fix involves handling the empty list case more gracefully, either by taking the input directly or returning an `Either` type.

This issue identifies a bug in how `DecrementObservation.distributedUTxO` pairs spent transaction inputs with newly created outputs. It incorrectly associates the spent inputs with decommit outputs, leading to "ghost references" that could confuse indexers or clients. The suggested fix involves adjusting the indexing to correctly map inputs to the new outputs.

The `Num` instance for `ContestationPeriod` can cause runtime panics when performing subtraction or negation that results in a negative value. This violates the protocol's assumption that `ContestationPeriod` should always be positive. The suggested fix is to remove the `Num` instance or implement its operators to explicitly error out, guiding users towards safer construction methods.

This issue proposes removing default values from command-line options for the hydra-node to improve the user experience. Instead of relying on potentially nonsensical defaults, the application will prompt users for necessary parameters and provide clear instructions on how to obtain them. This change aims to guide users more effectively in configuring the hydra-node.

This issue proposes the creation of a new repository, 'hydra-recipies', to consolidate and standardize various configurations for running a Hydra node. The goal is to provide clear, idiomatic examples for different setups, such as running with or without a Cardano node, using Docker or Nix, and configuring peers and network parameters, thereby simplifying the onboarding process for new users.

The project currently has provisional support for GHC 9.14, relying on `allow-newer` settings for its dependencies. To achieve full support, these dependencies need to be updated to be compatible with GHC 9.14. The issue suggests contributing to these dependencies by opening pull requests to their repositories.

This issue proposes the design and implementation of an LLVM IR bytecode Instruction Set Architecture (ISA). It involves creating a new bytecode format for LLVM Intermediate Representation, which will likely require significant design and engineering effort.

This issue proposes exploring the integration of WebAssembly (WASM) bytecode into the Wrench course. The goal is to determine its feasibility and potentially implement default example algorithms using WASM.

This issue proposes adding new metrics to improve the health-checking capabilities of the 'head' component. The suggested metrics include the number of expected peers, the etcd quorum threshold, the count of failed transactions, and potentially the average confirmation time per peer.