Concepts previously defined can be reused without defining again.

[jrbeaumont]

For example, in one concepts file I define:

circuit a b = ... <> initialState <> ... 
  where
  initialState = initialise a False <> initialise b False

and translate this.

Next I create a new file which contains:

circuit a b = ... <> initialState <> ...

and translate this, without defining initialState as the same as previous (assuming the initial states want to be the same).

The result should include this initialState concept with no error throne, possible a note suggesting it's using a saved initialState concept.

[mvdan]

This within the same Haskell program, as in the same hint interpretation context? Or different runs of the whole translate binary?

[jrbeaumont]

Different runs of the binary.

At the moment, if I translate one scenario in one file, and then try to translate a different but related scenario I have to redefine concepts which could be reused.

This isn't urgent, just putting something down for reference. There's a few options for this.

[snowleopard]

@jrbeaumont Perhaps, what you want to do is to be able to import several scenarios from the same file? Then you will be able to reuse part of specs when defining several concepts.

[jrbeaumont]

That's what I was thinking. It might be easier.

[jrbeaumont]

With the option to specify just one of the scenarios in the file if desired.

[snowleopard]

Ideally we should do it via module export list:

module Concept (scenario1, scenario3) where

-- This is exported
scenario1 = commonPart <> ...

-- This is not exported
scenario2 = commonPart <> ...

-- This is exported
scenario3 = commonPart <> ...

-- This is not exported
commonPart = ...

@mvdan Is this difficult to implement in hint?

[mvdan]

@snowleopard you mean with (not in) hint? What you can do is compile a module and access its named objects, which IIRC includes unexported ones too. So you could, for example, compile two concept modules and let them share bits.

This of course raises lots of little questions. For example, would one import the other in the regular Haskell way? Would the two be called module Concept? That last one might make hint not work as we intended as it would probably think that it's compiling the same module twice, overwriting or failing over the first compilation.

[snowleopard]

What you can do is compile a module and access its named objects, which IIRC includes unexported ones too.

The point is: it's best to use Haskell's module system. Export lists are useful, because they allow to hide information, which is great for big projects. So, ideally we should be able to read export lists with hint.

Would the two be called module Concept?

No, the module names will be different. Module name shouldn't be important for the concepts -> STGs translation procedure (except, perhaps, for name qualification, e.g. ModuleName.conceptName).

[mvdan]

So, ideally we should be able to read export lists with hint.

That is of course supported. And that's what we're doing currently to get the concept itself from the module.

No, the module names will be different.

Then simply compile this as a haskell program with multiple modules. If it compiles as a regular Haskell program (cabal), it will compile with hint.

[snowleopard]

@mvdan Thanks for the clarification! Sounds good.

[jrbeaumont]

That does sound good :)

[jrbeaumont]

Some further exploration on this:

If I define a concept file, called Myconcepts.hs, that contains the following

module Myconcepts where

import Tuura.Concept.STG

test1 a b c = [rise a, rise b] ~|~> rise c <> [fall a, fall b] ~|~> fall c

test2 a b c = handshake a b <> handshake b c

note that the module is defined Myconcepts

And now, I define a concepts file called test.hs which is in the same directory as Myconcepts.hs, and import Myconcepts, and contains the following:

module Concept where

import Tuura.Concept.STG
import Myconcepts

circuit a b c d e = interface <> test1 a b c <> test2 c d e <> initialState
    where
        interface = inputs [a, b] <> outputs [d, e] <> internals [c]

        initialState = initialise0 [a, b, c, d, e]

Translating test.hs will result in a correct output.

[snowleopard]

@jrbeaumont Great! One question: I presume the top line of Myconcepts.hs should actually be:

module Myconcepts (test1, test2) where

as otherwise test1 and test2 are not exported?

[jrbeaumont]

@snowleopard It works without this.

An issue I have noticed is that, if these files are both not in the plato directory, then it cannot load the Myconcepts module.

[snowleopard]

It works without this.

Weird. It sounds like a potential problem. What if the user would like to hide some internal details?

An issue I have noticed is that, if these files are both not in the plato directory, then it cannot load the Myconcepts module.

This can probably be dealt with by provinding a path to the imported file. Not sure how it's done in hint but it should be possible. I think all user-created files should live somewhere in the user-specified directory, not in the plato directory.

[jrbeaumont]

Weird. It sounds like a potential problem. What if the user would like to hide some internal details?

It does work with it as well!

This can probably be dealt with by provinding a path to the imported file. Not sure how it's done in hint but it should be possible. I think all user-created files should live somewhere in the user-specified directory, not in the plato directory.

I am looking into this now, so far I have found a way to import the Myconcepts file, but it says Failed to load interface for 'Myconcepts'

EDIT I have managed to load the Myconcepts file as well. Just need to add the ability to include necessary files to load their modules

[snowleopard]

It does work with it as well!

You mean, if you do

module Myconcepts (test1) where

then hint will complain about missing test2?

I have managed to load the Myconcepts file as well

Great! If you manage to make it work smoothly, you'll need to mention this in the paper.

[jrbeaumont]

You mean, if you do

Yes, it does complain about missing test 2.

Great! If you manage to make it work smoothly, you'll need to mention this in the paper.

At the moment it doesn't work smoothly. I know how to implement it, but I would need to implement arguments for translate/main.hs to include --include/-i commands or something like that, preferably for as many includes as desired.

[jrbeaumont]

@snowleopard For this, my feelings are that I won't have time to edit the paper effectively and implement this, unless you believe I have enough time post-submission of the paper to implement this.

[snowleopard]

@jrbeaumont As long as you are confident you can implement it before the conference/demo, it's fine to mention this in the paper. It shouldn't take more than a few sentences anyway, because from the point of view of the reader, it's not a very interesting feature (but is surely very important).

[jrbeaumont]

OK I'll do that then. I think it's important :)

[mvdan]

Still subbed to this issue, so just dropping by to confirm it indeed is important :)

[jrbeaumont]

I think we could probably close this now. Do you agree @snowleopard?

[snowleopard]

@jrbeaumont Can you document this feature in the README/manual?

[jrbeaumont]

I was going to sort the FSM translation and then document all of these.

[snowleopard]

Then I suggest to keep this issue open until the relevant documentation is in place.

[jrbeaumont]

Good idea.