Pith. sign in

REVIEW 2 major objections 4 minor 17 references

Intent Preserving Generation of Diverse and Idiomatic (Code-)Artifacts

T0 review · 2 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read The paper claims that intent, described once as a wiring diagram of typed abstract idioms, can generate idiomatic programs, behavior specifications, and task descriptions that stay semantically coherent.

desk verdict A clean, well-specified framework for generating synchronized artifacts from one abstract intent, but the 'intent preserving' guarantee rests on an unverified assumption about the educator's fragment library, not on the generation machinery. read the letter →

arxiv 2508.03642 v1 pith:W6DWO7OK submitted 2025-08-05 cs.SE

Oliver Westphal This is my paper · ORCID
classification cs.SE
keywords programgenerationexerciseabstractimplementationswiringdiagramsconcreteidiomsintentpreservationHaskellIOprogramsbehaviorspecifications
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper proposes that the intent behind a generated artifact—for example, read a number, read that many values, sum them, print the sum—can be captured once as a wiring diagram of typed abstract operations, and that many different artifacts can then be derived from that one diagram. Instead of writing a separate monolithic generator for each artifact kind, an educator writes small concrete fragments for each abstract operation for each artifact kind, and the framework chooses one fragment per operation and composes them. The paper demonstrates the idea on Haskell IO programs, on behavior specifications in an existing console-IO specification language, and on natural-language descriptions of tasks. If the approach works as claimed, a single shared description yields sample solutions, testable specifications, and task texts that stay behaviorally coordinated, and the number of distinct artifacts grows combinatorially as concrete fragments are added.

What carries the argument

The central object is the abstract implementation: a labeled, acyclic wiring diagram in which abstract idioms (typed operations, some marked as producing IO side effects) are connected by black data-flow wires and by red wires that totally order the IO effects. The two transformations that carry the argument are substitution—cutting out one idiom and inserting a more detailed diagram with the same external interface—and merging—cutting out a pattern of idioms and replacing it with a single idiom; both preserve the outside interface and must not create cycles in the combined data-flow/effect order. A second kind of idiom, the APPLY idiom, acts as a catalyst: alternatives split an atomic idiom into a function application plus parameters, and merge rules consume the APPLY idiom by folding it into a neighboring idiom. Concrete idioms are functions from inputs to artifact fragments plus silent outputs, and higher-order cases are handled by allowing partial outputs with holes that downstream idioms fill in, which avoids non-idiomatic beta-reducible expressions in generated code.

What would settle it

Define a small abstract implementation for the running example and give MODIFIED SUM two concrete idioms with different semantics—say one that sums all values and one that sums only values not equal to the second parameter—while keeping the same generated specification; if the two resulting programs are tested against that specification and one fails, the claim that a consistent original diagram guarantees coherent artifacts is refuted. A simpler check: generate the same abstract implementation twice with READ LIST realized by two concrete idioms that read values in different orders; identical console input should produce identical program behavior, and any divergence shows the process changed the intent.

Watch

Extended reading notes

Core claim

On the paper's own terms, the central claim is that an intent is a data-flow structure rather than a behavior predicate: an acyclic wiring diagram whose boxes are abstract idioms with typed inputs and outputs and whose red wires fix a total order on the boxes that perform IO. From this diagram, artifacts are generated by picking, for each abstract idiom, a concrete idiom appropriate to the target artifact kind, resolving data dependencies along the black wires, and combining the resulting fragments in any total order compatible with both data flow and IO order. Substitution replaces one idiom with a more detailed diagram having the same outer interface, and merging folds a pattern of idioms back into one; these two operations, driven by per-idiom alternative implementations and merge rules, produce variants of the diagram that realize the same intent. The paper shows that this process turns a four-step example intent into twenty distinct idiomatic Haskell programs and, by changing the artifact kind of the concrete idioms, into a matching IO-behavior specification and a verbal task description. Because every concrete fragment is handwritten, the generated programs are idiomatic by construction, and because all artifacts come from one diagram, they are coordinated as long as the idiom collection is consistent.

Load-bearing premise

The load-bearing premise is that the educator's handwritten set of concrete idioms, alternatives, and merge rules is mutually consistent, because the generation process does not check coherence and a single inconsistent fragment pair can silently produce artifacts that contradict each other.

Editorial extensions

If this is right

  • One abstract implementation yields multiple distinct artifact kinds—program, specification, and description—that describe the same behavior, because only the concrete idioms change.
  • Swapping one abstract idiom, such as replacing SUM by PRODUCT, changes the intent uniformly across every artifact derived from the diagram, without rewriting the other fragments.
  • The number of generated variants multiplies: given two READ LIST, one READ LOOP, six MODIFIED SUM, and two MODIFIED SUM FOLD concrete idioms, the example produces 20 programs, and adding one new fragment multiplies all compatible combinations.
  • Data-flow variants such as merging a loop with its summation or its print continuation change the decomposition of the code but not the observable IO behavior, so the same intent can be presented at different difficulty levels.
  • Abstract patterns with dashed boxes and refinement rules act like a grammar for intents, so the framework can also vary which behavior is generated, not only how one behavior is realized.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The framework's real product may be the idiom library: authoring cost is front-loaded into writing consistent concrete idioms and merge rules, and the combinatorial payoff makes larger libraries increasingly valuable, so reuse across courses could be the decisive factor.
  • The stated coherence assumption invites an automated check that the paper does not develop: randomly sample generated programs and specifications from the same abstract implementation and run the property-based tests from the paper's earlier work to hunt for inconsistent idiom sets before exercises reach students.
  • Because concrete idioms are functions into any monoid of fragments, the same machinery could generate non-code artifacts such as configuration files, circuit layouts, or test data, as long as an educator supplies matching fragments and a merge-compatible idiom set.
  • A natural next experiment is difficulty modeling: the generator knows exactly which concrete idiom and which data-flow variant produced each exercise, so collected student performance data could be correlated with those choices to predict task difficulty.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

2 major / 4 minor

Summary. The paper presents a framework for generating multiple related artifacts (Haskell IO programs, behavior specifications, natural-language descriptions) from a single abstract specification, called an abstract implementation: a wiring diagram of typed abstract idioms with data-flow and IO-effect ordering. For each abstract idiom, an educator supplies sets of concrete idioms (artifact fragments) for various artifact kinds, and the framework composes chosen concrete idioms according to the wiring. Two diagram transformations (substitution and merging) generate variants of the abstract implementation, including context-sensitive fusion of idioms (e.g., folding a sum into a read loop). The paper also introduces abstract patterns, a grammar-like mechanism for varying the underlying intent. The central claim is that this approach is 'intent preserving': all artifacts generated from one abstract implementation realize the same intent. The paper is explicit, however, that the framework does not check coherence; it assumes the educator's set of concrete idioms, alternatives, and merge rules is mutually consistent (Section 4.1), and that preservation of intent of transformations 'cannot be enforced or checked automatically at the level of abstract implementations' (Section 3.3).

Significance. The framework is a clean, compositional alternative to monolithic generators for programming-exercise tasks, and the paper's emphasis on deriving code, tests, and descriptions from a shared abstract structure is practically motivated and plausible. Strengths include: no fitted parameters (so no fit-to-data circularity); a fully worked, reproducible-looking example with concrete Haskell fragments; and unusual intellectual honesty about the coherence assumption, which is stated directly and not hidden. If the intent-preservation claim could be made formal or at least validated by automated checks, the approach would be a useful contribution to the TFPiE community. As it stands, the significance is limited because the central guarantee is explicitly delegated to the educator, and the paper offers no method or evidence that such a delegation is practical beyond a single hand-crafted example.

major comments (2)
  1. [Section 4.1 / Section 3.3] The paper's central claim of 'intent preserving' generation is not established; it is assumed. Section 4.1 states that the generation process 'does not do anything to check coherence' and that 'validation of concrete idiom sets, alternatives, and merge-rules is therefore the responsibility of the educator.' Section 3.3 concedes that preservation of intent by alternative implementations and merge rules 'cannot be enforced or checked automatically at the level of abstract implementations.' This is not a peripheral caveat: all guarantees about different artifacts being realizations of the same intent rest on this unverified premise. For example, two concrete idioms with the same signature but different behavioral semantics (e.g., two READ LIST realizations that consume different numbers of inputs) would silently produce mutually contradictory programs, specifications, and descriptions while the pipeline reports success. Since the paper's own testing framework [16] could, in principle, verify behavioral equivalence among generated concrete programs and between programs and specifications, this is fixable: the authors should either re-scope the title and abstract from 'intent preserving' to 'intent preserving up to an educator-provided, externally validated idiom library,' or add an automated compatibility check over the concrete idiom set.
  2. [Section 5.4] The only quantitative evidence for the framework's utility is the statement that 'we get a total of 20 slightly different concrete programs' from the example idiom library (Section 5.4). This is a combinatorics count, not a validation of diversity, idiomaticity, or intent preservation; it merely reflects the number of hand-written fragments and substitutions. The paper provides no evaluation of whether these 20 programs are actually behaviorally equivalent, whether they are idiomatic by any criterion, or whether the effort of constructing the idiom library is justified by the resulting variability. Adding a small automated equivalence check (e.g., using the [16] framework) for all or a sample of the 20 programs would substantially strengthen the central claim.
minor comments (4)
  1. [Section 2 / Figure 1] In Figure 1, the specification expression is shown aligned with the data-flow diagram, but the text does not explain how the alignment was obtained; this is a key step in the motivation (inferring composition boundaries from a specification) that the paper then abandons. A sentence clarifying that the alignment is only illustrative would avoid confusion.
  2. [Section 5.3] The graphical notation for 'higher-order' idioms, especially the partial-output type 'Int<Int,Int>' and the fragment 'if ... then 2*x ... else ...' in the MODIFIED SUM FOLD figure, is difficult to read in the rendered text. A concise textual explanation of the hole-filling mechanism, with a concrete example of the final β-reduced expression, would improve accessibility.
  3. [Section 3.3] The text says 'For SUM, we get the following alternative version' but the figure and surrounding discussion actually refer to a 'MODIFIED SUM' idiom from the running example. This naming inconsistency makes the transformation harder to follow.
  4. [Throughout] The paper lacks a reference to a public prototype implementation or repository. Section 8 mentions 'a prototype implementation' but gives no URL or artifact availability information; adding this would support reproducibility, which is otherwise one of the paper's strengths.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the generation pipeline is a constructive composition over hand-written concrete idioms, and the coherence caveat is an explicit assumption, not a circular derivation.

full rationale

The paper makes no empirical predictions and fits no parameters. Its derivation chain is constructive: an abstract implementation is the input; substitution and merge rules transform it; then each abstract idiom is replaced by an educator-supplied concrete idiom, and the resulting fragments are combined in an order compatible with the data-flow and IO-effect ordering. Idiomaticity and diversity are inherited from the hand-written fragment library and from the combinatorial number of choices, not derived from the generator itself. The only point that could resemble circularity is the title claim of 'intent preserving', since Section 4.1 explicitly disclaims any formal connection: 'there is no formal connection between the wiring diagram of the abstract implementation and the artifact resulting from the generation procedure other than the generation process itself', and 'The generation process does not do anything to check coherence but assumes that the set of concrete idioms is built such that possible results are coherent by construction.' Section 3.3 similarly concedes that preservation of intent 'cannot be enforced or checked automatically at the level of abstract implementations.' This is an honest and load-bearing validity caveat: the framework's guarantee is conditional on the educator's library being mutually consistent. But it is not a circular reduction in the sense of an output being defined in terms of the claimed prediction or a fitted parameter being renamed as a result. There is no equation in which the generated artifact is used to define the abstract implementation, and no benchmark is predicted from fitted data. The self-citations [15,16,17] supply prior tooling and example languages; they are not used as the sole justification for the central claim. Accordingly, the derivation is self-contained as a constructive engineering proposal, and the coherence assumption should be weighed as a correctness/validation risk rather than as circularity.

Assumptions & free parameters 0 free parameters · 4 assumptions · 2 invented entities

The central claim rests on four assumptions: well-formedness of diagrams as a sufficient model of realizable behavior; educator-authored coherence of the fragment library (the main load-bearing one); order-independence of fragment combination; and intent preservation of the transformations, which the paper admits is not checkable. There are no fitted numerical parameters; the framework introduces conceptual constructs (APPLY idioms, abstract patterns) whose correctness is internal to the framework and unverified. The multicategory perspective in Section 7 is a re-description, not an added assumption.

assumptions (4)
  • domain assumption Well-formed abstract implementations are acyclic wiring diagrams over typed abstract idioms, with a total IO-effect order compatible with the data-flow order (Section 3.1).
    The paper defines well-formedness structurally but does not prove that every acyclic diagram with compatible orders corresponds to a behavior realizable in the target languages; this is a modeling assumption about the artifact domain.
  • domain assumption Concrete idioms, alternative implementations, and merge rules are authored by the educator such that all artifacts generated from them are semantically coherent by construction (Section 4.1).
    This is the load-bearing assumption behind 'intent preserving': no part of the pipeline verifies it, so the central guarantee is delegated to the human author.
  • domain assumption Combining concrete fragments in any total order compatible with data-flow and IO effects yields a valid artifact of the target kind (Section 4).
    The framework concatenates fragments (e.g., vertical gluing of Haskell code) and relies on fresh-name generation to make any compatible order valid; scoping interactions between fragments (let-bindings visible across fragment boundaries) are assumed manageable.
  • ad hoc to paper Substitution and merging transformations preserve intent; asserted informally in Section 3.2 and stated to be uncheckable in Section 3.3.
    This is a correctness premise specific to this framework; the paper explicitly says intent preservation 'cannot be enforced or checked automatically at the level of abstract implementations'.
invented entities (2)
  • APPLY idioms (catalysts)
    purpose: Split an atomic abstract idiom into a function application so that surrounding idioms can merge with it, enabling context-sensitive program variants without naming every idiom combination.
    APPLY idioms are internal scaffolding: the paper says they are 'not intended to actually be instantiated by concrete artifact fragments' (Section 3.3). No external falsifiable handle exists; their correctness rests on the same uncheckable intent-preservation assumption.
  • Abstract patterns with dashed non-terminal boxes
    purpose: Grammar-like refinement system that varies the underlying intent, not just its realizations (Section 6).
    Dashed boxes stand for broader classes of behavior, refined by educator-supplied rules 'similar to how a context-free grammar produces words'; this is a framework construct without external verification, and the paper notes the required effort is higher.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Intent Preserving Generation of Diverse and Idiomatic (Code-)Artifacts." pith.science (2026). https://pith.science/paper/W6DWO7OK

@misc{pith2026250803642,
  author       = {Pith},
  title        = {Pith review of: Intent Preserving Generation of Diverse and Idiomatic (Code-)Artifacts},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/W6DWO7OK}},
  note         = {Machine review of arXiv:2508.03642}
}
read the original abstract

When automatically generating programming exercise tasks one often also needs to automatically generate programs. At the very least when providing sample solutions is part of automated feedback. But programs can also be used as part of the exercise task description to communicate a task's requirements. Writing good program generators that produce varied yet idiomatic code while being easily adaptable for new tasks is challenging. The challenges are intensified if task generation requires additional artifacts, like a more general behavior specification for testing or additional textual descriptions. Manually writing generators for multiple different but strongly related artifacts gets complicated quickly. We present an approach where instead of writing monolithic generators for multiple connected artifacts one specifies a small set of abstract building blocks and for each such building block defines sets of concrete realizations for various kinds of artifacts. Then the intended structure of the resulting artifacts is specified as a composition of the small abstract building blocks. This abstract description then serves as the common source from which related artifacts can be derived automatically. The approach is generic in the kind of artifacts it can produce and is therefore adaptable to a wide range of contexts.

Figures

Figures reproduced from arXiv: 2508.03642 by the authors.

Figure 1
Figure 1. Data-flow diagram and corresponding specification expression smaller intents and ideally our description of intent should also be composed out of smaller building blocks in the same way. We could describe intent with a specification expression in the language from our previous work [16] [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. shows a few possible realizations of our example intent. Two concrete realizations for the same operation can be used interchangeably. In this case the two fragments labeled READ LIST can replace each other allowing us to build a total of six slightly different idiomatic programs from the given fragments. All of these programs have the same observable IO-behavior. n <− readLn READ LIST xs <− replicateM n readLn READ… view at source ↗
Figure 3
Figure 3. Lifting of idiom realization. This procedure of defining realizations for each of the boxes and then combining them according to the specified data-flow works for arbitrary kinds of artifacts. In the same way we derive programs, we can also derive the specification expression in [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: Intermediate steps of substitution (top) and merging (bottom) operations In the rest of this section we will explore how these two transformations can be used to find different variations of abstract implementations that still preserve the original intent. 3.2 Combinin…
Figure 5
Figure 5. Figure 5: Program built from concrete idioms When generating Haskell program code this way of handling these higher-order arguments may seem unnecessarily complicated. After all we could just generate programs containing non-idiomatic applica￾tions of lambda-expressions and then…
Figure 6
Figure 6. Figure 6: Another concrete program artifact new concrete idiom for reading the list induces a new program variant for every compatible expression of the summation and vice versa. Therefore, the more concrete idioms we already have for other abstract idioms the more new variants …
Figure 7
Figure 7. Figure 7: Example system of abstract patterns (excerpt) Templates, or template-like approaches, are also often used for automatic generation of exercise task variants [11, 14]. Our system can be seen as a multi-level template approach, i.e., abstract implementa￾tions are templat…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

17 extracted references · 10 canonical work pages

  1. [16]

    In Jurriaan Hage, editor: Proceedings Eighth and Ninth International Workshop on Tre nds in Functional Programming in Education , EPTCS 321, Open Publishing Association, pp

    Oliver Westphal & Janis V oigtl¨ ander (2020): Describing Console I/O Behavior for T esting Student Submis - sions in Haskell . In Jurriaan Hage, editor: Proceedings Eighth and Ninth International Workshop on Tre nds in Functional Programming in Education , EPTCS 321, Open Publishing Association, pp. 19–36, doi: 10. 4204/eptcs.321.2

    work page 2020

  2. [1]

    In: Proceedings of the 55th ACM Technical Symposium on Computer Science Education V

    Doga Cambaz & Xiaoling Zhang (2024): Use of AI-driven Code Generation Models in T eaching and Learn- ing Programming: a Systematic Literature Review . In: Proceedings of the 55th ACM Technical Symposium on Computer Science Education V . 1, SIGCSE 2024, ACM, p. 172–178, doi: 10.1145/3626252.3630958. Oliver Westphal 129

    arXiv 2024

  3. [2]

    Proceedings of the Royal Society A 477(2250), doi: 10.1098/ rspa.2021.0099

    John D Foley, Spencer Breiner, Eswaran Subrahmanian & Jo hn M Dusel (2021): Operads for complex system design specification, analysis and synthesis . Proceedings of the Royal Society A 477(2250), doi: 10.1098/ rspa.2021.0099

    work page arXiv 2021

  4. [3]

    Spivak (2019): An Invitation to Applied Category Theory: Seven Sketches in Compositionality

    Brendan Fong & David I. Spivak (2019): An Invitation to Applied Category Theory: Seven Sketches in Compositionality. Cambridge University Press, doi: 10.1017/9781108668804

    doi:10.1017/9781108668804 2019

  5. [4]

    International Journal of Artificial Intelligence in Education 27, pp

    Alex Gerdes, Bastiaan Heeren, Johan Jeuring & L Thomas V a n Binsbergen (2017): Ask-Elle: an Adaptable Programming Tutor for Haskell Giving Automated Feedback . International Journal of Artificial Intelligence in Education 27, pp. 65–100, doi: 10.1007/s40593-015-0080-x

    doi:10.1007/s40593-015-0080-x 2017

  6. [5]

    Mathematics in Computer Science 3, pp

    Bastiaan Heeren, Johan Jeuring & Alex Gerdes (2010): Specifying Rewrite Strategies for Interactive Exer- cises. Mathematics in Computer Science 3, pp. 349–370, doi: 10.1007/s11786-010-0027-4

    work page doi:10.1007/s11786-010-0027-4 2010

  7. [6]

    In Ute Schmid, Emanuel Kitzelmann & Rinus Plasmeijer, editors: Approaches and Applications of Inductive Pro- gramming, Springer, pp

    Emanuel Kitzelmann (2010): Inductive Programming: A Survey of Program Synthesis T echn iques. In Ute Schmid, Emanuel Kitzelmann & Rinus Plasmeijer, editors: Approaches and Applications of Inductive Pro- gramming, Springer, pp. 50–73, doi: 10.1007/978-3-642-11931-6_3

    work page doi:10.1007/978-3-642-11931-6_3 2010

  8. [7]

    Triet H. M. Le, Hao Chen & Muhammad Ali Babar (2020): Deep Learning for Source Code Modeling and Generation: Models, Applications, and Challenges . ACM Computing Surveys 53(3), doi: 10.1145/ 3383458

    work page 2020

Show all 17 references
  1. [8]

    London Mathematical Society Lecture Note Series, Cambridge University Press, doi: 10.4204/eptcs.321.2

    Tom Leinster (2004): Higher Operads, Higher Categories . London Mathematical Society Lecture Note Series, Cambridge University Press, doi: 10.4204/eptcs.321.2

    2004 doi

  2. [9]

    In: Proceedings of the 2022 ACM Conference on International Computing Education Research - V olume 1 , ICER ’22, ACM, p

    Sami Sarsa, Paul Denny, Arto Hellas & Juho Leinonen (2022 ): Automatic Generation of Programming Exer- cises and Code Explanations Using Large Language Models . In: Proceedings of the 2022 ACM Conference on International Computing Education Research - V olume 1 , ICER ’22, ACM...

    2022

  3. [10]

    New Structures for Physics, pp

    Peter Selinger (2011): A Survey of Graphical Languages for Monoidal Categories . New Structures for Physics, pp. 289–355, doi: 10.1007/978-3-642-12821-9_4

    2011 doi

  4. [11]

    Kumar (2002): A tutoring system for parameter passing in programming lan- guages

    Harsh Shah & Amruth N. Kumar (2002): A tutoring system for parameter passing in programming lan- guages. In: Proceedings of the 7th Annual Conference on Innovation and T echnology in Computer Science Education, ITiCSE ’02, ACM, p. 170–174, doi: 10.1145/544414.544464

    2002

  5. [12]

    Preprint, doi:10.48550/arXiv.1305.0297

    David I Spivak (2013): The operad of wiring diagrams: formalizing a graphical lang uage for databases, recursion, and plug-and-play circuits. Preprint, doi:10.48550/arXiv.1305.0297

    2013 doi arXiv

  6. [13]

    Computer Languages, Systems & Structures 52, pp

    Eugene Syriani, Lechanceux Luhunu & Houari Sahraoui (2 018): Systematic mapping study of template- based code generation . Computer Languages, Systems & Structures 52, pp. 43–62, doi: 10.1016/j.cl. 2017.11.003

    2017 doi

  7. [14]

    In: Proceedings of the 50th ACM Technical Symposium on Computer Science Education , SIGCSE ’19, ACM, p

    Anderson Thomas, Troy Stopera, Pablo Frank-Bolton & Ra hul Simha (2019): Stochastic Tree-Based Gener- ation of Program-Tracing Practice Questions . In: Proceedings of the 50th ACM Technical Symposium on Computer Science Education , SIGCSE ’19, ACM, p. 91–97, doi: 10.1145/32873...

    2019

  8. [15]

    In Michael Hanus & Claudio Sacerdoti Coen, editors: Functional and Constraint Logic Programming , LNCS 12560, Springer, pp

    Oliver Westphal (2021): A Framework for Generating Diverse Haskell-I/O Exercise T asks. In Michael Hanus & Claudio Sacerdoti Coen, editors: Functional and Constraint Logic Programming , LNCS 12560, Springer, pp. 97–114, doi: 10.1007/978-3-030-75333-7_6

    2021 doi

  9. [17]

    In: Proceedings of the 15th International Symposium on Functio nal and Logic Programming , LNCS 12073, Springer, pp

    Oliver Westphal & Janis V oigtl¨ ander (2020): Implementing, and Keeping in Check, a DSL Used in E- Learning. In: Proceedings of the 15th International Symposium on Functio nal and Logic Programming , LNCS 12073, Springer, pp. 179–197, doi: 10.1007/978-3-030-59025-3_11

    2020 doi

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.