Inline type annotation and a notation for source data inputs about transforge HOT 9 CLOSED

source label : Type would be better, because a data input might source its input from either another transformation or from an actual data source. Or, perhaps clearer, input label : Type.

from transforge.

For readability, you could use a synonym like Contour = R2(Ord, Reg) to say source 3 : Contour.

from transforge.

In fact, the source keyword is probably not the best choice; it is long and may be read as a regular operation. A special symbol like # is more appropriate, or we could leave it away completely and understand any number as a source.

The shortest notation would be to do Type number. Then using just Type would be an anonymous source, and using just number would be just a reference to a source without typing it (as the type may have been already fixed somewhere else). Example:

size R1(Obj) 1
size R1(Obj)
size 1

Or, more readable:

size R1(Obj) #1
size R1(Obj)
size #1

However, this notation would not generalize to the ability to type non-source expressions inline. That's why I prefer something like:

size (#1 : R1(Obj))
size #1

Only the notation for an anonymous source remains to be decided, because I think size (# : R1(Obj)) looks awkward. Perhaps
size (* : R1(Obj)) or size (#? : R1(Obj))?

from transforge.

Even though size (# : R1(Obj)) looks awkward, both the explanation and the implementation would be simpler, so that's what we'll go with.

Also, the ; semicolon operator would be useful for resetting the stack. It would enable us to write something like #1 : Type; f #1 #1 --- in other words, you could define the types of input sources before using them.

from transforge.

For maximum correspondence between Python code and parsed expressions, I would suggest @ or ^ as an alternative to the type annotation symbol, :, and to use either None or ... for unlabelled sources and plain integers for labelled sources.

Or perhaps really using the special 'source' keyword is most straightforward and most explicit. Compare:

(((select inrel) (source 1 : R3a(Obj, Reg, Nom))) (source : R1(Obj)))

to:

(((select inrel) (1 : R3a(Obj, Reg, Nom))) (... : R1(Obj)))

The latter is shorter, but the former communicates intent much better. However, in the Python version, the other version is preferable:

select(inrel, Source(R3a(Obj, Reg, Nom), 1), Source(R1(Obj)))
select(inrel, 1 @ R3a(Obj, Reg, Nom), ... @ R1(Obj))

from transforge.

I think it's best to use - or + for shortcuts rather than ~, as we can use the unary version for anonymous sources and the binary one for labelled sources. As before:

select(inrel, Source(R3a(Obj, Reg, Nom), 1), Source(R1(Obj)))
select(inrel, 1 -R3a(Obj, Reg, Nom), -R1(Obj))
select(inrel, 1 +R3a(Obj, Reg, Nom), +R1(Obj))

from transforge.

In commit 084f591, sources started using integer labels internally, too.

from transforge.

Use square brackets for types? This would make graphs easier to read, would be consistent with Python's typing module, and would make expressions easier to read too.

from transforge.

The new notation is now used for cct, see quangis/quangis-workflow@36d1f8f

Given that the solution to issue #72 will require that labels are only meaningful during the parsing stage, we no longer need to worry about Python-compatible notation for labelling. ~T will indicate a source; a number will indicate a source that is to be replaced by another expression (possibly a source expression) during parsing.
With that, I think this issue can be closed.

from transforge.