When people design a language to represent a data structure, they often do a poor job with literals (i.e. the constant values for each data type). And that causes problems with operator overloading. I recommend that you give each data type its own literal format, so you can distinguish, say, a short 0 from an unsigned long 0 or a 64 bit floating point 0. Same goes for composite literals (e.g. a constant of type array or struct or array-of-struct) and floating point numbers.
> On Nov 3, 2022, at 11:06 AM, Percy Camilo Triveño Aucahuasi > <percy.camilo...@gmail.com> wrote: > > Thanks Sasha! > > A nice advantage about parentheses is that most editors can track and > highlight the sections between them. > Also, those parentheses can be optional when we detect new lines (in the > case some users don't want to deal with many parentheses); in that case, we > would just need to ask indentation. > > Percy > > > On Thu, Nov 3, 2022 at 12:47 PM Sasha Krassovsky <krassovskysa...@gmail.com> > wrote: > >> Hi Percy, >> Thanks for the input! New lines would be no problem at all, they’d just be >> treated the same as any other whitespace. One thing to point out about the >> function call style when written that way is that it looks a lot like the >> list style, it’s just that there are more parentheses to keep track of, >> though it does make it more obvious what delineates a subtree. >> >> Sasha >> >> >>> 3 нояб. 2022 г., в 10:35, Percy Camilo Triveño Aucahuasi < >> percy.camilo...@gmail.com> написал(а): >>> >>> Hi Sasha, >>> >>> I like the function call-style variant. Quick question about the parser: >>> Do you think we can parse with new lines too? that way it would be even >>> more similar to a json-like/declarative approach and could mitigate a bit >>> the nesting issue (which would make it easier to read as well) for >> instance: >>> >>> sink( >>> project( >>> filter( >>> source( >>> …) >>> …) >>> …) >>> …) >>> >>> Percy >>> >>> >>>> On Tue, Oct 18, 2022 at 5:54 PM Sasha Krassovsky < >> krassovskysa...@gmail.com> >>>> wrote: >>>> >>>> Hi everyone, >>>> We recently had some discussions about parsing expressions. I currently >>>> have a PR [1] up for that taking into account the feedback. Next I >> wanted >>>> to tackle something for ExecPlans, as manually specifying one using >> code is >>>> currently cumbersome. I’m currently deciding between 2 variants: >>>> >>>> - Function call-style: This would be a similar syntax to the >> expressions, >>>> where we would have something along the lines of >>>> `sink(project(filter(source(…)…)…)…)`. The problem with this syntax is >> that >>>> it involves tons of nesting, which although an improvement over >> handwriting >>>> the C++ code, is still cumbersome to write. On the other hand, this >> syntax >>>> is pretty intuitive and meshes well with the expression syntax. A minor >>>> modification could be to make the last argument rather than the first be >>>> the input to a node, which would at least keep a node’s parameters >>>> together. >>>> >>>> - List style: This syntax completely eliminates nesting and would >> probably >>>> be easier to write but has a steeper learning curve. Essentially, since >> we >>>> know how many inputs each type of node takes, we can implicitly >> reconstruct >>>> a tree from a list of node names (formally, we are converting from/to a >>>> pre-order traversal of the query tree). For example, it would look >>>> something like: >>>> >>>> ``` >>>> sink >>>> project <list of names/expressions> >>>> filter <expression> >>>> source >>>> ``` >>>> >>>> The key is that we know that a source takes no inputs, and so source >> nodes >>>> are leaf nodes. To take an example with a join, it could be something >> like >>>> >>>> ``` >>>> order_by_sink <sort key> >>>> hash_join <join arguments> >>>> filter <expression> >>>> source >>>> filter <expression> >>>> source >>>> ``` >>>> >>>> Since we know that a join always takes two arguments, we interpret the >>>> first (filter source) slice as the first argument and the second as the >>>> second argument. It should be noted that the current C++ code already >>>> resembles this kind of syntax, it just has much more clutter. >>>> >>>> Thanks! >>>> Sasha Krassovsky >>>> >>>> [1] https://github.com/apache/arrow/pull/14287 >>
