PortProduct prefixing, auto-generating notation

[DigitalBrains1]

Using a Synthesize annotation, we can specify names for the ports of the generated component.

Currently:

• PortName "" indicates an auto-generated name is wanted.
• PortProduct "pre" [ Portname "a", PortName "" ] creates two ports named pre_a and pre_X, where X is auto-generated.

This has two undesirable aspects:

• It is impossible to get rid of the prefix for some of the ports in a PortProduct.
• PortName "" is a bit of a misnomer.

After some internal discussion, we suggest

• Add a friendly name AutoName that does the exact same as PortName "" and keep the latter for backward compatibility.
• Add AbsPortName s which gives the port the name s without any of the prefixes of the enclosing PortProducts.

Note that the current documentation regarding prefixes is wrong, this is based on actual behaviour of CλaSH 1.0.1.

[DigitalBrains1]

On a related note, PortProduct "pre" [ PortName "suf" ] generates the name pre_suf. Personally, to get that result, I'd like to write, e.g., PortProduct "pre_" [ Portname "suf" ] so I am free to choose whether I actually want that underscore or not.

[martijnbastiaan]

On a related note, PortProduct "pre" [ PortName "suf" ] generates the name pre_suf. Personally, to get that result, I'd like to write, e.g., PortProduct "pre_" [ Portname "suf" ] so I am free to choose whether I actually want that underscore or not.

Maybe we could add a "t_separator" option to Synthesize?

[DigitalBrains1]

To me, it's perfectly natural to write PortProduct "pre_" [ PortName "suf" ] or PortProduct "camel" [ PortName "Case" ] or some such construction. I'd prefer that simplicity, but if you want the explicitness of

, t_output = PortProduct "camel" [ PortName "Case" ]
, t_separator = ""

I'd be fine with that as well.

[leonschoorl]

We should also think about how this interacts with makeTopEntity from #729

[martijnbastiaan]

We discussed this offline: Adding t_separator would break backwards compatibility, so we should refrain from doing that the "dumb" way. We propose the following upgrade path:

1. [1.2] Adding a "smart constructor" for Synthesize.
2. [1.2] Deprecate using the Synthesize smart constructor.
3. [1.2] Encourage users to use defSyn nm { prop = ... }
4. [1.4] Remove the smart constructor for Synthesize

Correct @leonschoorl @DigitalBrains1 ?

[DigitalBrains1]

I think that is what we discussed. But: how does CλaSH know when we write:

{-# ANN f def #-}
f a b = ...

that it should fill in the default for Synthesize and not some other annotation? I think you'd have to write:

{-# ANN f (def :: TopEntity) #-}

and then I'd rather use defSyn.

[martijnbastiaan]

Yeah, excellent point. I'll edit it in.