Loading ...
Sorry, an error occurred while loading the content.

Re: Spirit syntax -- another suggestion.

Expand Messages
  • Vladimir Prus
    ... for ... I think that it is possible to write a metaprogram that will take a general expression tree and reparse it assuming whatever precedece you like.
    Message 1 of 20 , Jun 1, 2001
    • 0 Attachment
      Joel de Guzman wrote:

      >> Actually, *this* code can be made to work. Blitz library uses this syntax
      for
      >> array assigments.
      >> Array<int> a;
      >> a = 1, 2, 3, 4, 5;
      >> This is acomplished by making operator= return special object. This is not
      >> likely to work in case of initialzation, anyway.
      >> --

      >but still:

      > a, b | c

      >will be

      > a, (b | c)

      >and not what we want:

      > (a, b) | c

      > Gosh if you could make that work, I want that!

      I think that it is possible to write a metaprogram that will take a general
      expression tree and reparse it assuming whatever precedece you like.
      This is not easily done, though. I actually think that we need some
      metalanguage, most likely functional, which will be mapped to template
      metaprograms. But this is not easily done as well.

      --
      Regards,
      Vladimir
    • Vladimir Prus
      ... Because someone who... has CS degree, or worked with various parser generators, or something else -- in short, he has some previous knowledge which
      Message 2 of 20 , Jun 1, 2001
      • 0 Attachment
        Joel de Guzman wrote:

        >I can never understand why someone who can comprehend
        >complex abstractions, build intricate applications and frameworks,
        >communicate on such a high technical level, absorb all the syntax
        >rules of c++, find *a versus a* "confusing", while, on the other
        >hand, a 'newbie' find it to be not confusing at all.

        Because "someone who..." has CS degree, or worked with various parser
        generators, or something else -- in short, he has some previous knowledge
        which conflicts with different notation. Dale Gerdemann's example about
        fractions is exaggerated, yet very correctly represents the problem.

        As for "newbie" -- really, person who *never* heard anything about grammar
        will see no difference. However, it is very dangerous to give extra weight to
        "newbie"'s opinion, as you seem to do. While newbie might have a fresh mind,
        he also might try the parser for one or two simple tasks and, naturally,
        won't find any problems.

        >I argue that it is *not* about clarity of syntax at all. It is, plain
        >and simply, about personal preference. Nothing more.

        Clarity and personal preference are related. Actually, I would like to recall
        Greg Colvin's statement
        I don't have a strong opinion, but am glad to see the argument
        and experimentation towards finding a nice, clean syntax.

        I think that the argument now becomes to be non-productive, and no
        experimentation that I am aware of is happening. I therefore think that
        *all* syntaxes should be implemented, so that they could be tried in
        practice. This can be done, for example, by providing a number of namespaces
        namespace Spirit { // default meaining of operators
        }
        namespace Spirit_foobar { // another meaning
        }
        etc.
        After that, and experimentation, a table should be filled, stating
        1) How many persons like and dislike each syntax
        2) How those persons used Spirit
        3) Which were issues with each syntax.
        After that, better syntax can be selected, or the table can be given in
        documentation.

        I think this is the best way to deal with syntax questions.

        --
        Regards,
        Vladimir
      • joel de guzman
        ... general ... I spent an hour thinking about this if it is indeed possible. I d say now that it isn t. Here s the reason: an expression: a, (b | c)....
        Message 3 of 20 , Jun 1, 2001
        • 0 Attachment
          From: "Vladimir Prus":

          > I think that it is possible to write a metaprogram that will take a
          general
          > expression tree and reparse it assuming whatever precedece you like.
          > This is not easily done, though. I actually think that we need some
          > metalanguage, most likely functional, which will be mapped to template
          > metaprograms. But this is not easily done as well.
          >

          I spent an hour thinking about this if it is indeed possible. I'd say now
          that
          it isn't. Here's the reason:

          an expression:

          a, (b | c).... explicit grouping

          which explicitly groups (b | c) cannot be distinguished, using any meta-
          programming techniques, from:

          a, b | c.... implicit grouping (precedence groups (b | c) automatically)

          The problem is that we cannot overload the parentheses () for
          grouping. There's no way to know whether the user typed the
          first or the second expression.

          Cheers,
          Joel de Guzman
        • Gary Powell
          ... but still: a, b | c will be a, (b | c) and not what we want: (a, b) | c Gosh if you could make that work, I want that! Joel de Guzman
          Message 4 of 20 , Jun 1, 2001
          • 0 Attachment
            >>

            but still:

            a, b | c

            will be

            a, (b | c)

            and not what we want:

            (a, b) | c

            Gosh if you could make that work, I want that!

            Joel de Guzman

            <<

            It's possible using expression templates. (but not easy.)
            You build a tuple of

            tuple< commaOperator, a, tuple<orOperator, b, c> >

            as you evaluate the expression,

            in the operator=(), you'd then parse the tuple.

            but you'd have to parse the tuple for the commaOperator, and either build a
            new tuple, or just evaluate it with some special case code.

            tuple< orOperator, tuple<commaOperator, a, b>, c>;

            Definitely ugly stuff. (And it may surprise experienced users because the
            order of operations, is left to right, not in C/C++ priority.)

            Yours,
            -gary-


            gary.powell@...
          • joel de guzman
            [snip comma ops] ... a ... As I mentioned in my other post, how do you distinguish explicit grouping?: a, (b | c).... explicit grouping a, b | c.... implicit
            Message 5 of 20 , Jun 1, 2001
            • 0 Attachment
              [snip comma ops]
              >
              > It's possible using expression templates. (but not easy.)
              > You build a tuple of
              >
              > tuple< commaOperator, a, tuple<orOperator, b, c> >
              >
              > as you evaluate the expression,
              >
              > in the operator=(), you'd then parse the tuple.
              >
              > but you'd have to parse the tuple for the commaOperator, and either build
              a
              > new tuple, or just evaluate it with some special case code.
              >
              > tuple< orOperator, tuple<commaOperator, a, b>, c>;
              >
              > Definitely ugly stuff. (And it may surprise experienced users because the
              > order of operations, is left to right, not in C/C++ priority.)
              >

              As I mentioned in my other post, how do you distinguish explicit grouping?:

              a, (b | c).... explicit grouping

              a, b | c.... implicit grouping (precedence groups (b | c) automatically)

              Cheers,
              Joel de Guzman
            • joel de guzman
              From: Vladimir Prus ... Bruce and I are doing experimentations on syntax. ... namespaces ... Bruce did that I think with a special include file that
              Message 6 of 20 , Jun 2, 2001
              • 0 Attachment
                From: "Vladimir Prus"

                > I think that the argument now becomes to be non-productive, and no
                > experimentation that I am aware of is happening. I therefore think that

                Bruce and I are doing experimentations on syntax.

                > *all* syntaxes should be implemented, so that they could be tried in
                > practice. This can be done, for example, by providing a number of
                namespaces
                > namespace Spirit { // default meaining of operators

                Bruce did that I think with a special include file that
                implements his experimental syntax.

                > namespace Spirit_foobar { // another meaning
                > }
                > etc.
                > After that, and experimentation, a table should be filled, stating
                > 1) How many persons like and dislike each syntax
                > 2) How those persons used Spirit
                > 3) Which were issues with each syntax.
                > After that, better syntax can be selected, or the table can be given in
                > documentation.
                >
                > I think this is the best way to deal with syntax questions.
                >

                Fair enough, but, isn't this getting to be a 'design by commitee' kind of
                thing?

                Cheers,
                Joel de Guzman
              • David Abrahams
                ... From: joel de guzman ... It appears to be. One fundamental thing that makes boost work is that the library author gets to
                Message 7 of 20 , Jun 2, 2001
                • 0 Attachment
                  ----- Original Message -----
                  From: "joel de guzman" <isis-tech@...>

                  > > namespace Spirit_foobar { // another meaning
                  > > }
                  > > etc.
                  > > After that, and experimentation, a table should be filled, stating
                  > > 1) How many persons like and dislike each syntax
                  > > 2) How those persons used Spirit
                  > > 3) Which were issues with each syntax.
                  > > After that, better syntax can be selected, or the table can be given in
                  > > documentation.
                  > >
                  > > I think this is the best way to deal with syntax questions.
                  > >
                  >
                  > Fair enough, but, isn't this getting to be a 'design by commitee' kind of
                  > thing?

                  It appears to be. One fundamental thing that makes boost work is that the
                  library author gets to decide. Nobody does any work s/he doesn't believe in.
                  I'm not saying that the discussion has run out of useful suggestions or
                  points-of-view, but Joel (and anyone else he's working with) should get
                  final say over the design of his library.

                  -Dave
                • joel de guzman
                  ... in ... of ... in. ... That said, I still welcome suggestions, criticisms and comments regarding Spirit syntax. I always want to keep an open mind and I
                  Message 8 of 20 , Jun 3, 2001
                  • 0 Attachment
                    From: "David Abrahams" <abrahams@...>:

                    > > > namespace Spirit_foobar { // another meaning
                    > > > }
                    > > > etc.
                    > > > After that, and experimentation, a table should be filled, stating
                    > > > 1) How many persons like and dislike each syntax
                    > > > 2) How those persons used Spirit
                    > > > 3) Which were issues with each syntax.
                    > > > After that, better syntax can be selected, or the table can be given
                    in
                    > > > documentation.
                    > > >
                    > > > I think this is the best way to deal with syntax questions.
                    > > >
                    > >
                    > > Fair enough, but, isn't this getting to be a 'design by commitee' kind
                    of
                    > > thing?
                    >
                    > It appears to be. One fundamental thing that makes boost work is that the
                    > library author gets to decide. Nobody does any work s/he doesn't believe
                    in.
                    > I'm not saying that the discussion has run out of useful suggestions or
                    > points-of-view, but Joel (and anyone else he's working with) should get
                    > final say over the design of his library.
                    >
                    > -Dave

                    That said, I still welcome suggestions, criticisms and comments regarding
                    Spirit syntax. I always want to keep an open mind and I learn a lot from
                    you guys. Yet as Larry Evans noted, we might be focusing our attention
                    too much on the 'look and feel' issue. I would hope to see more discussion
                    on implementation issues.

                    Thanks,
                    Joel de Guzman
                  • Gary Powell
                    As I mentioned in my other post, how do you distinguish explicit grouping?: a, (b | c).... explicit grouping a, b | c.... implicit grouping (precedence groups
                    Message 9 of 20 , Jun 4, 2001
                    • 0 Attachment
                      As I mentioned in my other post, how do you distinguish explicit grouping?:

                      a, (b | c).... explicit grouping

                      a, b | c.... implicit grouping (precedence groups (b | c) automatically)


                      You can't. I apologize, as I was going through the long history of boost
                      postings, I hadn't got to your answer before I replied.

                      The only way out is to make a "grouping" function. (Can you say Ick?!?)

                      a, group_ick(b | c) ....

                      Or in addition to Bjarne's whitespace function calls, add overloading of
                      global operator()! (along with my other suggestion of overloading
                      operator;()!

                      -gary-

                      gary.powell@...
                    Your message has been successfully submitted and would be delivered to recipients shortly.