Need help! Removing `codeExprDoc` from `drasil-printers`? by balacij · Pull Request #4509 · JacquesCarette/Drasil

balacij · 2025-12-06T01:28:07Z

I will annotate this PR for discussion, but this PR and branch are expected to be deleted in the end.

The goal of my work is to move the Drasil.Code.* modules from drasil-lang into drasil-code. However, that work is currently impossible because it would create a cyclic dependency between drasil-printers and drasil-code:

drasil-printers relies on CodeExpr and the other modules in Drasil.Code (namely code variables) for describing how CodeExpr can be rendered into Docs for human-readable, non-code purposes (I suppose ASCII variants).
drasil-code relies on drasil-printers for said rendering function and more (e.g., rendering functions for ModelExpr, Sentence, Symbol, etc.).

`CodeExpr` to `Expr`.

balacij · 2025-12-06T01:29:53Z

code/drasil-printers/lib/Language/Drasil/Plain/Print.hs

-- | Create code expressions for a document in 'Doc' format.
-codeExprDoc :: PrintingInformation -> SingleLine -> C.CodeExpr -> Doc
-codeExprDoc pinfo sl e = pExprDoc sl (codeExpr e pinfo)


This function is used by drasil-code for a single purpose: rendering CodeExpr-based quantity constraints into human-readable text for outputting input value constraint violation messages (see stable/ changes).

This seems like reasonable functionality - where does it belong? And maybe it should be in two stages (i.e. codeExprDoc would get fed the results of codeExpr e pinfo so that codeExpr would not be needed here).

balacij · 2025-12-06T01:32:46Z

code/drasil-printers/lib/Language/Drasil/Printing/Import/CodeExpr.hs

-{-# LANGUAGE GADTs #-}
-
-- | Defines functions to render 'CodeExpr's as printable 'P.Expr's.
-module Language.Drasil.Printing.Import.CodeExpr (codeExpr) where


The reason why I tried to delete this file at all is because, well, it is odd. CodeExpr is intended for rendering into GOOL (solely, to my knowledge), not necessarily rendering comments. Considering it is only used for a single purpose (the input constraint violation error messages), I'm not sure if the approach taken to outputting messages is a good one.

I could be wrong here as well!

But I neglected to also mention the initial reason I was looking at this code at all: drasil-printers and drasil-code have a cyclic dependency that we are currently avoiding through pushing some code from drasil-code into drasil-lang. This includes the "code variable chunks" and CodeExpr. My goal is to be able to move the drasil-code-related code from drasil-lang into drasil-code.

I certainly agree with that goal.

balacij · 2025-12-06T01:34:10Z

code/stable/glassbr/src/cpp/InputParameters.cpp

        std::cout << ", but is expected to be ";
        std::cout << "between ";
        std::cout << 0.1;
-        std::cout << " (d_min)";


While here we output a variable name in "implementation" Stage, in other areas, we have the flexibility of printing any general CodeExpr.

Indeed. But removing this output points to a real problem, i.e. these changes should not do that!

balacij · 2025-12-06T01:34:40Z

code/stable/projectile/projectile_m_l_nol_u_u_v_f/src/julia/InputParameters.jl

        print(Float32(0.0))
        print(" and ")
        print(pi / Float32(2.0))
-        print(" ((pi)/(2))")


For example, $\frac{\pi}{2}$.

balacij · 2025-12-06T01:38:44Z

code/drasil-code/lib/Language/Drasil/Code/Imperative/Modules.hs

      printConstraint' _ (Range _ (Bounded (_, e1) (_, e2))) = do
        lb <- convExpr e1
        ub <- convExpr e2
-        return $ [printStr "between ", print lb] ++ printExpr e1 db ++
-          [printStr " and ", print ub] ++ printExpr e2 db ++ [printStrLn "."]
+        return $ [printStr "between "] ++ printExpr lb db ++
+          [printStr " and "] ++ printExpr ub db ++ [printStrLn "."]
      printConstraint' _ (Range _ (UpTo (_, e))) = do
        ub <- convExpr e
-        return $ [printStr "below ", print ub] ++ printExpr e db ++
+        return $ [printStr "below "] ++ printExpr ub db ++
          [printStrLn "."]
      printConstraint' _ (Range _ (UpFrom (_, e))) = do
        lb <- convExpr e
-        return $ [printStr "above ", print lb] ++ printExpr e db ++ [printStrLn "."]
+        return $ [printStr "above "] ++ printExpr lb db ++ [printStrLn "."]


One question to ask ourselves first is: What do we want the format of the constraint violation messages to be?

I somewhat like these, but I would also like to see CON$X$ (where CON$X$ is a label we defined in the SRS for a constraint) added as a prefix.

I agree that more traceability in constraint violation messages would be even better.

balacij · 2025-12-06T01:47:22Z

One solution to all of this is to split up drasil-printers. The rendering code for each language would move somewhere closer to the definition of said data types. We might still need a dependency-less drasil-printers-like library that the code can use for general "printing utilities," however.

Another solution (the one I decided on for this PR) is to delete codeExprDoc entirely. This way, we would need to figure out what we really want in our constraint violation messages.

However, if we wanted to maintain the status quo with this PR for the sake of maintaining the status quo, we should be able to avoid converting the constraint maps of Exprs into maps of CodeExprs until necessary for executable code generation. Leaving them as Exprs, we would be able to use our ASCII Expr printer to print out the same expressions (with one new configuration option: using the "implementation" stage versions of our variable symbols).

JacquesCarette · 2025-12-10T17:19:10Z

code/drasil-code/lib/Language/Drasil/Code/Imperative/Modules.hs

    convTypeOO, VisibilityTag(..))

-import qualified Drasil.GOOL as OO (SFile)
+import qualified Drasil.GOOL as OO (SFile, SValue)


These imports (of SFile and SValue), as well as ProcProg` all seem to point to something being odd here.

JacquesCarette · 2025-12-10T17:21:56Z

code/drasil-printers/lib/Language/Drasil/Plain/Print.hs

-- | Create code expressions for a document in 'Doc' format.
-codeExprDoc :: PrintingInformation -> SingleLine -> C.CodeExpr -> Doc
-codeExprDoc pinfo sl e = pExprDoc sl (codeExpr e pinfo)


This seems like reasonable functionality - where does it belong? And maybe it should be in two stages (i.e. codeExprDoc would get fed the results of codeExpr e pinfo so that codeExpr would not be needed here).

JacquesCarette · 2025-12-10T17:22:40Z

code/drasil-printers/lib/Language/Drasil/Printing/Import/CodeExpr.hs

-{-# LANGUAGE GADTs #-}
-
-- | Defines functions to render 'CodeExpr's as printable 'P.Expr's.
-module Language.Drasil.Printing.Import.CodeExpr (codeExpr) where


I certainly agree with that goal.

JacquesCarette · 2025-12-10T17:24:11Z

code/stable/glassbr/src/cpp/InputParameters.cpp

        std::cout << ", but is expected to be ";
        std::cout << "between ";
        std::cout << 0.1;
-        std::cout << " (d_min)";


Indeed. But removing this output points to a real problem, i.e. these changes should not do that!

balacij added 2 commits December 1, 2025 12:06

drasil-lang: Switch RawContent's CodeBlock constructor from using

3618724

`CodeExpr` to `Expr`.

Need help! Removing codeExpr from drasil-printers.

19f6953

balacij commented Dec 6, 2025

View reviewed changes

balacij changed the title ~~Need help! Removing codeExpr from drasil-printers?~~ Need help! Removing codeExprDoc from drasil-printers? Dec 6, 2025

balacij mentioned this pull request Dec 8, 2025

WIP: Writing about rendering and code generation in Drasil #4510

Closed

JacquesCarette reviewed Dec 10, 2025

View reviewed changes

Conversation

balacij commented Dec 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

balacij Dec 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

balacij commented Dec 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

balacij commented Dec 6, 2025 •

edited

Loading

balacij Dec 6, 2025 •

edited

Loading

balacij commented Dec 6, 2025 •

edited

Loading