Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add dot-dsl exercise #162

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Add dot-dsl exercise #162

wants to merge 1 commit into from

Conversation

ageron
Copy link
Contributor

@ageron ageron commented Oct 21, 2024

This one did not have any test cases in the problem specs, so I had very little guidance.

The goal of the exercise is to implement a DSL that looks like the Dot format:

    graph {
        graph [bgcolor="yellow"]
        a [color="red"]
        b [color="blue"]
        a -- b [color="green"]
    }

The DSL I came up with looks close enough:

    graph = buildGraph { bgColor: Yellow } [
        node "a" { color: Red },
        node "b" { color: Blue },
        edge "a" "b" { color: Green },
    ]

However, I feel like the fun and interesting part was designing this DSL. Now the users just need to implement the buildGraph function that reads the DSL commands and builds a graph: it's okay, but not super interesting, IMHO. Perhaps it's enough to get the users familiar with the idea of a DSL and how to build one in Roc.

Another option would be to make the tests agnostic to the DSL itself, as long as it can build the right graphs. For example:

import DotDsl exposing [buildGraph, dslCommandsForGraph1, dslCommandsForGraph2, ...]
expect
    result = dslCommandsForGraph1 |> buildGraph
    expected = { bgColor: ..., nodes: ..., edges: ...} # graph 1
    result == expected

expect
    result = dslCommandsForGraph2 |> buildGraph
    expected = { bgColor: ..., nodes: ..., edges: ...} # graph 2
    result == expected

...

This way the user gets to come up with their own DSL, which is the interesting part, and they also get to use it to build a few graphs. But perhaps this does not give users enough guidance. They could just define dslCommandsForGraph1 to be equal to the expected graph 1, and make buildGraph the identity function, it wouldn't be very interesting. Or perhaps we can guide them a little bit in the docs, by suggesting a DSL like the one I designed. I'm not sure, WDYT?

Note: if we stick to the current approach, perhaps I can add a test that requires the user to use the DSL to build a specific graph? For example:

# use the DSL to create this test graph
expect
    result = dslCommandsForTestGraph |> buildGraph
    expected = { bgColor: ..., nodes: ..., edges: ...} # test graph
    result == expected

Copy link
Contributor

@isaacvando isaacvando left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea of having the students come up with the DSL themselves! I agree that that is the most fun part.

@ageron
Copy link
Contributor Author

ageron commented Oct 24, 2024

Sounds good, I'll update the exercise then, thanks for your feedback, Isaac.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants