Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #67408

Re: Untyped Variables

Show key headers only | View raw

David Kleinecke <dkleinecke@gmail.com> writes:
> On Thursday, August 13, 2015 at 11:44:36 AM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> > On Tuesday, August 11, 2015 at 5:15:52 PM UTC-7, Keith Thompson wrote:
>> >> David Kleinecke <dkleinecke@gmail.com> writes:
>> >> > On Monday, August 10, 2015 at 9:30:54 PM UTC-7, James Kuyper wrote:
>> >> [...]
>> >> >> An explanation of how you would modify the grammar rules to allow such
>> >> >> sequences, and how you would write a constraint to impose those
>> >> >> restrictions semantically, would make it much easier for us to
>> >> >> understand your objection.
>> >> >
>> >> > I've done this before.
>> >> >
>> >> > I want to define "expression" by the following syntax
>> >> >    expression = term Infix..
>> >> >    term = (Prefix ...) Primitive (Suffix ...)  
>> >> > where "..." means repeat as many tiems as desired and "A B.." means
>> >> > repeat A separated by B (as in ABABABAB ...). The C syntax is almost
>> >> > already in that shape except for two points - one of them in the cast
>> >> > expression and the other the tertiary operator. (The tertiary can be
>> >> > forced into the right shape by looking at "QUERY expression COLON" as
>> >> > an Infix).
>> >> 
>> >> I can read the C grammar and, with some work, determine whether a given
>> >> expression is valid and how it's evaluated.
>> >> 
>> >> I can't do that with your description above, at least not without
>> >> knowing what you mean by "Infix", "Prefix", "Primitive", and "Suffix".
>> >
>> > Infix is any token in the set of tokens corresponding to binary 
>> > operators. Prefix is any token is the set of token corresponding
>> > to unary operators. Suffix is better limited to either "++" or "--"
>> > and all the other postfix treated as part of the primitive. Primitive
>> > (before that last change) means what the standard means by primary
>> > expression. It is possible to add embedded expressions (OPEN
>> > expression CLOSE) to the general syntax but the standard leaves thme
>> > as primitives.
>> >
>> > The reason why the names are all changed is that imposing a more
>> > general theory of parsing onto C parsing.  
>> >
>> >> Is that intended to be the entire grammar for expressions?  Would you
>> >> not have separate rules for additive, multiplicative, shift, and so
>> >> forth, expressions?
>> >  
>> > That's the whole thing.
>> >
>> >> And you haven't said anyting about constraints.  Would the meaning of
>> >> `x + y * z` be specified by the grammar (if so, what you've written above
>> >> doesn't do that), or by an English semantic description (if so, you
>> >> haven't mentioned it)?
>> >  
>> > The semantics are quite elaborate but we are only talking syntax
>> > here. 
>> 
>> C's syntax specifies how operands are associated with operators.  Your
>> proposed syntax does not.
>> 
>> >> Note that if the binding of `x + y * z` isn't defined by the grammar,
>> >> the rule saying that it's equivalent to `x + (y * z)` would not be a
>> >> constraint; it would be a semantic description.
>> >
>> > Actually it's a consequence of assigned token precedences and is buried
>> > in the semantics. 
>> 
>> Which you haven't described.
>
> OK each infix has two precednces - left and right. Each prefix has a
> left precedence. Suffixes has right precedences. There are two stacks -
> one for prefixes and one for data. Starting from the beginning - read 
> a token. (1) If it a prefixs push it on the stack (2) If it is a 
> primitive hold is a "the value". (3) If it is suffix or infix there 
> is an error. Note that tokens like MINUS or STAR can be both prefixes
> and infixes and here the prefix version is assumed. Repeat until a value
> is found. Read one more token. (1) If it is a suffix compare its right
> precedence to the top of the prefix stack and successively code applying
> the prefix to the value until the top of the stack has less precedence
> than the suffix and then apply the suffix to the value. (2) If it is an
> infix handle the stack the same way but instead of applying push the 
> infix onto the prefix stack and the value onto the value stack. (3) If it
> is any other token you have reached the end of the expression and you
> successively pop off prefixes until you get the final value. After (2)
> you repeat from the beginning. After (1) only one new token.
>
> I brushed over a couple of minor details but you get the idea.

You've haven't mentioned parentheses.

Do you really find this easier to understand than the existing syntax?

The reference to a "stack" suggests that this is targeted at compiler
developers, not at end users.

> Any compiler is going to have to do essentially this process even if
> the work is not so clearly marked off.   

The mapping from the grammar given in the standard to code that can
parse that grammar is fairly straightforward, and likely to be more
reliable that code written from a description like yours.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-07 18:19 -0700
  Re: Untyped Variables Lőrinczy Zsigmond <nospam@for.me> - 2015-08-08 06:53 +0200
  Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-08 11:09 -0400
    Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-08 12:09 -0700
      Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-08 14:24 -0400
    Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-08 12:54 -0700
      Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-08 16:06 -0700
        Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-08 17:29 -0700
          Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-09 17:52 -0700
            Re: Untyped Variables Ian Collins <ian-news@hotmail.com> - 2015-08-10 12:57 +1200
            Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-10 08:41 -0700
              Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-10 17:06 -0700
        Re: Untyped Variables Richard Damon <Richard@Damon-Family.org> - 2015-08-08 19:44 -0400
        Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-08 20:34 -0400
          Re: Untyped Variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-09 02:03 +0000
            Re: Untyped Variables Richard Damon <Richard@Damon-Family.org> - 2015-08-08 22:52 -0400
              Re: Untyped Variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-09 04:57 +0000
                Re: Untyped Variables Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-08-09 09:58 -0600
                Re: Untyped Variables Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-10 03:54 -0700
                Re: Untyped Variables Richard Damon <Richard@Damon-Family.org> - 2015-08-09 16:59 -0400
          Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-09 18:02 -0700
            Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-10 11:01 -0400
              Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-10 13:20 -0400
              Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-10 16:54 -0700
                Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-11 00:20 -0400
            Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-10 08:11 -0700
              Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-10 17:15 -0700
                Re: Untyped Variables James Kuyper <jameskuyper@verizon.net> - 2015-08-11 00:30 -0400
                Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-11 16:50 -0700
                Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-11 17:24 -0700
                Re: Untyped Variables Richard Heathfield <rjh@cpax.org.uk> - 2015-08-12 01:37 +0100
                Re: Untyped Variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-12 04:46 +0000
                Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-12 18:12 -0700
                Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-13 12:08 -0700
                Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-13 16:25 -0700
                Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-14 10:36 -0700
                Re: Untyped Variables Bartc <bc@freeuk.com> - 2015-08-14 19:13 +0100
                Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-11 07:58 -0700
          Re: Untyped Variables richard@cogsci.ed.ac.uk (Richard Tobin) - 2015-08-10 13:53 +0000
            Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-10 08:29 -0700
              Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-10 17:01 -0700
                Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-10 17:42 -0700
                Re: Untyped Variables glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-11 02:56 +0000
            Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-10 16:50 -0700
              Re: Untyped Variables Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-11 01:39 +0100
                Re: Untyped Variables Keith Thompson <kst-u@mib.org> - 2015-08-10 19:03 -0700
                Re: Untyped Variables Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-11 11:21 +0100
                Re: Untyped Variables David Kleinecke <dkleinecke@gmail.com> - 2015-08-11 16:37 -0700

csiph-web