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

Make targets extensible #99

merged 4 commits into from Mar 4, 2017


None yet
2 participants

dahlia commented Mar 2, 2017

Target class

This patch makes more targets can be added. In order to decouple target-specific backend from the intermediate compilation, I need to introduce a new typeclass named Target. This new class has the following purposes:

  • Every target can have its own configuration specific to the target language. So target-specific settings need to be interpreted by the corresponding target. Meanwhile, these settings ideally should be altogether with settings of other targets and package metadata: package.toml file.

    To achieve that, Target's parseTarget function takes only the part of the settings needed by each target. If it returns errors, or has successfully parsed the part the result is automatically propagated and merged to the result of the whole build process.

  • Instead of defining the common types for error/successful result to be used by every target and the whole build process altogether, Target makes each target to define their own types for the internal representations and functions to render them to the outer representation. For error types (CompileError), they have to be rendered to error messages to be printed (showCompileError), and for successful result types (CompileResult), they have to be rendered to ByteString to be finally written to object files (toByteString).

  • Every target has its own name. Although it's not used by CLI yet, there are APIs to discover a corresponding target by its name text. It determines the section name for the target in package.toml file. (Read the below.)


To build a package to a target, its package.toml need to has a settings specific for the target. It's configured to targets.{targetName} section in table. See examples/package.toml:

version = "0.3.0"

name = "nirum-examples"

The above field is for Python target and determines the PyPI distribution name. See also docs/ for details.

Template Haskell

To implement discovery of Target instances, I need to add some amount of Template Haskell. Nirum.Targets.List module is only for it, and it's used by Nirum.Targets module. buildPackage function takes a target name string, and Template Haskell magic finds the proper target instance from the given string. I'd hacked it to implement target discovery without Template Haskell for more than a month, but found Template Haskell is necessary to implement it.

Python's PyPI distribution name

As I mentioned above, now generated doesn't hardcode its name field to TestPackage anymore. Instead, it's determined by in the package.toml file. #41 is fixed.

@dahlia dahlia self-assigned this Mar 2, 2017

@dahlia dahlia requested review from kanghyojun, Kroisse and heejongahn Mar 2, 2017


This comment has been minimized.


kanghyojun commented Mar 3, 2017

👏 👏 👏 👏 👏 👏 👏 👏 👏 👏 👏 👏

@dahlia dahlia force-pushed the dahlia:package-metadata branch from 0cf06c4 to 68cae83 Mar 3, 2017


This comment has been minimized.


kanghyojun commented Mar 3, 2017

오늘안에 보겠습니다 ㅋㅋ

@dahlia dahlia merged commit 02f67c8 into nirum-lang:master Mar 4, 2017

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
continuous-integration/travis-ci/pr The Travis CI build passed

@dahlia dahlia added the cmp:compiler label Aug 26, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment