Hi everyone,
I’d be fine with switching it to add(x, y). I’ll look into round-trip support,
I imagine we can massage the ToString implementation a bit as well to make it
easier to parse back.
Did anyone have opinions about the syntax for FieldRefs or Scalars? Scalars of
the form $type:value ma
Another advantage of "add(x, y)" is that this matches our current string
representation for expressions.
Although that might give the impression that we support anything that we
output as string, and so that raises the question if we want to make this
explicit: if we add parsing capabilities, woul
SQL is nearly universally understood so unless there is a compelling
reason I tend to use that as my default.
I don't see any particular advantage to favoring "(add x y)" over "add(x, y)"
I will acknowledge that there are downsides to supporting x + y, I
think you listed these out already.
So, f
I don't see the point of having two different syntaxes.
Also, IMHO lisp-style is harder for many people, so I would rather a
more "traditional" syntax (though Lisp is historically traditional, of
course ;-)).
Le 10/10/2022 à 21:10, Sasha Krassovsky a écrit :
Yes that makes a lot of sense!
Yes that makes a lot of sense! I’d agree that it would probably be fine to have
two different syntaxes, seeing as the use-cases are a bit different.
Did anyone else have any thoughts? Either on the lisp-style syntax for Arrow’s
Expressions or on having two different syntaxes? (Weston or Antoine
Hi Sasha,
I agree with your points. However Gandiva is kind of specialized in computing
arithmetic expressions and it offers little to none non-arithmetic operations.
So it is very helpful if its parser understands natural math expressions.
Considering that Gandiva is a relatively independent
Hi Jin,
I agree it would be good to standardize on a syntax. To me, the advantages of
the lisp-style syntax are:
- don’t have to define/implement any kind of precedence rules
- has a uniform syntax (no distinction between prefix and infix operators)
- avoids having “special” functions that have a
Hi Sasha and Weston,
I'm the author of the mentioned Gandiva parser. I agree that having one
unified syntax is ideal. I think one critical divergence between Sasha's
and my proposals is that mine is with C++/Python imperative style (foo(x,
y, z), a+b…) and Sasha's is with Lisp functional style ((f
Hi Weston,
I’d be happy to donate something like this to Sunstrait if that’s useful, I was
thinking of proving out a design here before going there. However we could also
just go straight there :)
Regarding infix operators and such the edge case I was thinking of is that a
user could potentiall
Currently Substrait only has a binary (protobuf) serialization (and a
protobuf JSON one but that's not really human writable and barely
human readable). Substrait does not have a text serialization. I
believe there is some desire for one (maybe Sasha wants to give it a
try?). A text format for S
Hi David,
Could you elaborate on which part of my proposal overlaps with Substrait? I
don’t see anything in Substrait that allows me to do something along the lines
of
Expression e = Expression::FromString(“(add !.a $int32:1)”);
in the code.
Sasha
> On Oct 5, 2022, at 1:35 PM, Lee, David
I believe this is what substrait.io is trying to accomplish..
Here's some additional info:
https://substrait.io/
https://www.youtube.com/watch?v=5JjaB7p3Sjk
-Original Message-
From: Sasha Krassovsky
Sent: Wednesday, October 5, 2022 11:29 AM
To: dev@arrow.apache.org
Subject: Parser for
12 matches
Mail list logo
