`from` isn't a transform

[not-my-profile]

The book refers to from as a transform ... which is wrong ... a from doesn't transform anything.

https://github.com/PRQL/prql/blob/35e511d9328fdb323f8c1914b942045ecbd42d35/web/book/src/reference/stdlib/transforms/README.md?plain=1#L12-L16

I think this conflation is confusing since transforms can be at any point in the pipeline while from cannot ... since it's not a transform.

[max-sixty]

~Yes, we could possibly split that section into Transforms and Keywords?~ Actually don't think this a great idea on reflection

[richb-hanover]

Contrary viewpoint warning: I suppose from is not truly a transform. Although it does turn "nothing" into a table/relation, it cannot be present in the middle of a pipeline, so probably doesn't meet the true definition of "transform".

But from a documentation standpoint, there is real value in retaining it in the current Transforms section. That page is the handy-dandy reference for all PRQL statements, and sending the reader to some other page for this one statement would be awkward.

The from page could state these limitations (not really a transform, must begin a pipeline, can't be in the middle) and I don't think anyone will be confused or led astray. Thanks.

[not-my-profile]

I did not suggest it to be removed from the transforms page but the page should be renamed to Functions if it is to list from. Or alternatively the From page should be moved out of the section but it could still be linked from the page.

I don't think anyone will be confused or led astray

I disagree. Listing from under "transforms" is just misleading.

[max-sixty]

I do think there's value in having a "PRQL primitives" grouping, basically answering "what are my tools for transforming data", which includes how to pull in data.

We've called this "Transforms", because they're mostly transforms. Possibly from isn't technically a transform, though we could define it as transforming nothing into something...

What are other ways of grouping this?

One approach would be to call it something like "Primitives", add in loop? Or even just flatten all of those to the Standard Library?

---

Re the exchange above — I would encourage us to be constructive, work towards making something better. If someone holds a different view, pursue the dialectic approach, not the eristic approach — most insight comes from the synthesis of views which look initially appear contradictory

(I'm not saying anyone said anything normatively bad, instead am raising early to direct us)

[richb-hanover]

I'm going to throw out two more thoughts for consideration, and let the considered wisdom of the group evolve an answer:

• THE fundamental concept of PRQL is "transforms stacked to create pipelines". This leads me to suggest that we keep the section named "Transforms". Each page that describes a transform (or not quite a transform - from or loop or others?) can describe guard rails for their use.

• As I was writing documentation a week or so ago, I kept stumbling over terminology. What do we call these "fundamental constructs"? Transforms? Statements? That is, are they "PRQL statements"? "PRQL transforms"? What do we call loop?

Thanks for listening

[not-my-profile]

Is there any reason why loop shouldn't be considered a transform?

[snth]

I agree that loop should probably be considered a transform.

---

from is an interesting case. Most of the transforms have conditions on the previous step in order to be valid, e.g. you can't have select {a} if there is no a column in the previous relation. The condition on from is that the previous relation has to be empty (at least in the current form of from).

I actually have a proposal for from that I've been stewing over for months now but I'm not sure this is the right time to bring it up because it's almost midnight here. I'll sleep on it and see about it in the morning.