Big renames

[turion]

Renames

renames we would like to have:

• TimeDomainOf -> Time
• SyncSF -> ClSF
• SF -> SN ("signal network")
• td -> time
• arrMSync_ :: m a -> SyncSF m cl arbitrary a to constMSync, and then to constMCl

Renames we have to think about once more:

• Step ->FixedStep?
• CycleClock -> Periodic?
• theTag :: SyncSF m cl a (Tag cl) -> tagS?
• sinceStart -> sinceInit? And:
  • startClock -> initClock
  • startSchedule -> initSchedule
• sinceSimStart -> ? (Rename sinceSimStart? #30 )

Won't rename

• KeepLast -> ZeroOrderHold
• ResamplingBuffer.put -> ResamplingBuffer.input
• ResamplingBuffer.get -> ResamplingBuffer.output

Aliases to add

• ResBuf
• ParClock
• SeqClock
• absoluteS = timeInfoOf absolute, sinceStartS = timeInfoOf sinceStart, sinceTickS = timeInfoOf sinceTick

ToDo

Consistency checks

• Haddock errors
• Skim through code in PR in order to find alignment mistakes

Changes in other places (immediate)

• Article

Changes in other places (whenever they update to rhine-0.5)

• sonnendemo
• tutorial

[ivanperez-keera]

I'm not sure this belongs here, but should FRP.Rhine.ResamplingBuffer.KeepLast be called FRP.Rhine.ResamplingBuffer.ZeroOrderHold? That seems to be what it does if cl1 is discrete and cl2 is continuous.

[turion]

Yes, that sounds right.

[turion]

The step clock (where Step n produces ticks 0, n, 2*n etc. in the integer time domain) should have a better name. @ivanperez-keera any idea how that should be called properly? Something related to "logical clock" or so?

[ivanperez-keera]

Skip also sounds appropriate, doesn't it?

But, generally, yes, it seems somewhat related to clock sync, reference clocks and minor/major ticks.

I'll think about this.

EDIT: Changed phrasing not to assume something's better/worse.

[turion]

Should we maybe rename TimeDomainOf simply to TimeDomain? It would name clash with its assumed type class, which might be confusing, but this could be done with qualified imports.

[ivanperez-keera]

I don't see the name clash. Where is it?

[turion]

There is a type class called TimeDomain. I think you can't have a type class and a type (family) of the same name, right?

[ivanperez-keera]

When this happens to me, I usually add a suffix to the class. I suggest F or T for the type function, or C for the class.

Otherwise, and maybe I'm overcomplicating this (or the paper) but, to me, it seems like TimeDomain itself (the class) means something that can easily be expressed in more general (algebraic or category-theoretical) terms. If so, then maybe it would be best to name it something else?

We require that we can measure the difference between them? And what else? What do we assume about that difference?

[turion]

When this happens to me, I usually add a suffix to one. You can use F or T for the type function, or C for the class.

I'm not sure I like that. I find TimeDomainOf still better than that option.

Otherwise, and maybe I'm overcomplicating this (or the paper), but, to me, it seems like TimeDomain itself (the class) means something that can easily be expressed in more general (algebraic or category-theoretical) terms. If so, then maybe it would be best to name it something else? We require that we can measure the difference between them? And what else? What do we assume about that difference?

It definitely can, and there has been a proposal by Alan Jeffrey, deriving FRP from those axioms. There are some insights to be learned. But it's not too clear to me and I don't want to do the research right now.

[ivanperez-keera]

You should check what happened with this answer and that there is no confidential info leaked.

[ivanperez-keera]

When this happens to me, I usually add a suffix to one. You can use F or T for the type function, or C for the class.

I'm not sure I like that. I find TimeDomainOf still better than that option.

Sure. I don't think I've seen the use of 'Of' in type functions much, so it's a-typical, but that does not make it wrong. The reason why I opt for the other approach is that you can use it always. So, no ad-hoc decisions to be made for each case.

We can always revisit this when we know better.

EDIT: Better order of sentences.

[turion]

The freshly added CycleClock should maybe be called LogicalClock.

[ivanperez-keera]

Logical clocks are more general than a specific type-level step-based clock with a starting point, and they are an established concept in distributed systems.

Unless you are trying to claim that, for some reason, this is the way of implementing logical clocks in Rhine, which I would argue against, because I can think of others. And there are kinds/parts of logical clocks that this does not implement.

By the way, is it also possible to say something like '[1,3,..] in the type-level list? Because, if it is, the I guess it could be simpler (and also more general?).

[ivanperez-keera]

If implemented for general lists, I would call this ListClock. If implemented for a starting point and a delta, I would call these step clocks or fixed-step clocks (these are just my terms, nothing I've read in any literature).

[turion]

Right, logical clocks are something different from what I thought. ListClock is ok. There is already a StepClock n, it's basically CycleClock '[n] (see #50 ). Actually, how about calling CycleClock StepsClock? Then at least the relation between StepClock and StepsClock is clear.

[turion]

I can't get '[1,3,..] to work and I suspect that this can't work. Types can't be lazy or infinite.

[ivanperez-keera]

There is already a StepClock n, it's basically CycleClock '[n] (see #50 ).

I thought maybe that could be called SkipClock (because it skips steps, keeping one of n), or MacroClock (because it counts MacroTicks, in relation with a faster, global reference clock, which ticks with higher precision and counts MicroTicks).

Actually, how about calling CycleClock StepsClock? Then at least the relation between StepClock and StepsClock is clear.

I'd argue against it. The names are too similar. It will be confusing both in speech and in thinking.

[ivanperez-keera]

I can't get '[1,3,..] to work and I suspect that this can't work. Types can't be lazy or infinite.

Makes sense. Good to know.

[turion]

Won't rename KeepLast to ZeroOrderHold since the latter is usually used restrictively for digital-analog conversion. Instead, I'll add note in the docs/article.

[turion]

Also, I'll leave ResamplingBuffer's functions the same. The chance of name clash with State is so small, since ResamplingBuffer replaces its functionality.

[turion]

CycleClock should be called PeriodicClock. StepClock is an ok name, but maybe FixedStep is even better, as per your suggestion?

[turion]

On second thoughts, names shouldn't be too long. I'll add a note about fixed step length in the docs rather than changing the whole name.

[ivanperez-keera]

Which name is too long here?

[turion]

FixedStep. It's not very long, but still.

[ivanperez-keera]

FixedStep is absolutely perfect in length.

In general, and especially at the beginning, opting for longer names is better than opting for short names.

Longer names facilitate understanding, and the worst that can happen is that you'll need a search and replace, and an explanation in the paper/doc.

Shorter names make understanding harder. Search and replace is still possible, although it's generally harder to know what to replace it with because the name is not intuitively descriptive.

[turion]

Yes, actually you're right.