search

tuura / plato

A DSL for asynchronous circuits specification
Other
12 stars 2 forks source link

Make concepts into a cabal library package #9

Closed mvdan closed 8 years ago

mvdan commented 8 years ago

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

snowleopard commented 8 years ago

So, I propose the following course of action:

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

snowleopard commented 8 years ago

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

mvdan commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

Yep, that's the point.

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

mvdan commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

@mvdan Agreed.