Make concepts into a cabal library package

[mvdan]

This way it can be used by others easily. Should be published as well.

[snowleopard]

So, I propose the following course of action:

• Move both C-element examples from Main.hs to Test.hs.
• After that there is pretty much nothing left in Main.hs, so it can be dropped.
• Add haddock comments, see separate issue: Add haddock comments #10.
• Update .cabal file to turn it into library.
• Find an appropriate name, category and module name to release the package, perhaps concepts, Hardware, and Hardware.Concepts, respectively? See https://hackage.haskell.org/packages/#cat:Hardware and https://wiki.haskell.org/Hierarchical_module_names
• Do a formal v0.0.1 release, tagging the source code.
• Push to Hackage!

A useful reference: http://begriffs.com/posts/2014-10-25-creating-package-hackage.html

[snowleopard]

I've pushed a major source structure refactoring, addressing two tasks above. Feedback welcome.

[mvdan]

I would add another item: formally tagging our first release, e.g. v0.0.1 on git. Anything that is pushed to hackage should be tagged on git.

[mvdan]

Move both C-element examples from Main.hs to Test.hs.

I had this in mind, will post a PR soon.

After that there is pretty much nothing left in Main.hs, so it can be dropped.

Sure. It could be turned into our simulate executable, but I don't know what the easiest course of action would be since we'd have to hard-code what is being simulated. The same applies to what I'm building - how will the user specify the haskell file containing the circuit, initial state, etc? Surely it has to be at compile time, but I don't know if we could do it via build flags, by modifying the cabal file, ...

[snowleopard]

I would add another item: formally tagging our first release, e.g. v0.0.1 on git. Anything that is pushed to hackage should be tagged on git.

Added. IIRC this happens automatically when we do a github release.

[snowleopard]

It could be turned into our simulate executable, but I don't know what the easiest course of action would be since we'd have to hard-code what is being simulated.

I think we better just drop it, replacing it with tests and possibly some overview haddock section.

The same applies to what I'm building - how will the user specify the haskell file containing the circuit, initial state, etc? Surely it has to be at compile time, but I don't know if we could do it via build flags, by modifying the cabal file

Not sure yet. Maybe it's possible to use GHC API to compile a given concepts spec.hs in runtime (the filename could passed via command line). Could you check?

[mvdan]

I think we better just drop it, replacing it with tests and possibly some overview haddock section.

SGTM

Not sure yet. Maybe it's possible to use GHC API to compile a given concepts spec.hs in runtime (the filename could passed via command line). Could you check?

Remember what you said about requiring GHC to be installed to be too much? This is pretty much the same - we would have to bundle at least part of the compiler with our binary. If the compiler is modular enough this should be possible, and if it's well written enough the overhead in size should not be too large. I'll look into it.

[snowleopard]

@mvdan Good point. However, as a first step you should implement your conversion algorithm just as a library function, e.g.:

deriveSTG :: (Eq a, Show a) => CircuitConcept a -> STG a

I guess a logical place to put it inside the source tree is Hardware.Concepts.STG, where you will also create appropriate type STG a, .g import and export, etc.

There will then be a separate executable project to be plugged into Workcraft. We'll think about it later.

[mvdan]

Sure. So you can transform either at compile time by using it as a library or at runtime (though also compiling) via the executable.

[snowleopard]

Yep, that's the point.

We could later add other 'backends': FSM (probably the most straightforward one), CPOG, etc.

[mvdan]

Just so we're on the same page, STG a would be a data type, much like a struct, correct? Then showing that would actually generate the string that is the .g file.

[snowleopard]

Just so we're on the same page, STG a would be a data type, much like a struct, correct?

Yes, I think so. Note, you probably don't want to export the constructor.

Then showing that would actually generate the string that is the .g file.

I would avoid using Show for this purpose. Non-derived Show instances are frowned upon in general, so I should remove some of my Show instances too. Instead I suggest:

exportDotG :: STG String -> String
importDotG :: String -> STG String

If you make STG a Functor then the user will be free to do the renaming/retyping of labels in any way, maybe by show-ing all labels, maybe via other means. If you want to get a more fancy API you could also provide the following functions:

exportDotG' :: Show a => STG a -> String
exportDotG' = exportDotG . fmap show

importDotG' :: Read a => String -> STG a
importDotG' = fmap read . importDotG

As you can see the implementations are pretty trivial, so not sure it is worth it.

[mvdan]

Haskell is weird. In any other language, feeding a string would be horrible - you would want to feed a reader, e.g. an open file. Unless there's something I'm missing here, it looks like importDotG would require to fully read the input file and then pass it.

[snowleopard]

Yes, due to laziness it is possible to get away with passing String's around as if they were streams.

It is possible to screw up though by accidentally adding a strict function into such pipeline. But I guess such a screw up is possible in a strict language too even when explicitly operating with streams.

[snowleopard]

it looks like importDotG would require to fully read the input file and then pass it.

Not necessarily. If your STG representation is a list of arcs, just as they are represented in a .g file, then importDotG will provide arcs one by one to the consumer.

[mvdan]

@snowleopard the first two items are done, and there is an open issue about doc/comments already. I suggest we close this issue and tag as soon as first-release is completed.

[snowleopard]

@mvdan Agreed.