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

Groups > comp.lang.c > #148065 > unrolled thread

How to parse attributes?

Back to article view | Back to comp.lang.c

Contents

  How to parse attributes? Philipp Klaus Krause <pkk@spth.de> - 2019-11-20 09:41 +0100
    Re: How to parse attributes? David Brown <david.brown@hesbynett.no> - 2019-11-20 10:05 +0100
      Re: How to parse attributes? Philipp Klaus Krause <pkk@spth.de> - 2019-11-20 11:05 +0100
        Re: How to parse attributes? David Brown <david.brown@hesbynett.no> - 2019-11-20 12:35 +0100
    Re: How to parse attributes? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-20 11:06 +0000
    Re: How to parse attributes? Öö Tiib <ootiib@hot.ee> - 2019-11-20 23:16 -0800
      Re: How to parse attributes? Philipp Klaus Krause <pkk@spth.de> - 2019-11-21 10:39 +0100
        Re: How to parse attributes? Öö Tiib <ootiib@hot.ee> - 2019-11-21 02:51 -0800
          Re: How to parse attributes? James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-21 05:00 -0800
        Re: How to parse attributes? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-22 02:21 +0000
          Re: How to parse attributes? Keith Thompson <kst-u@mib.org> - 2019-11-21 20:41 -0800
            Re: How to parse attributes? Philipp Klaus Krause <pkk@spth.de> - 2019-11-22 09:15 +0100
            Re: How to parse attributes? David Brown <david.brown@hesbynett.no> - 2019-11-22 09:48 +0100
              Re: How to parse attributes? "A. K." <minforth@arcor.de> - 2019-11-22 02:00 -0800
                Re: How to parse attributes? David Brown <david.brown@hesbynett.no> - 2019-11-22 11:41 +0100
                Re: How to parse attributes? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-24 14:02 +0000
                  Re: How to parse attributes? raltbos@xs4all.nl (Richard Bos) - 2019-11-25 16:21 +0000
              Re: How to parse attributes? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-22 17:46 +0000
                Re: How to parse attributes? Keith Thompson <kst-u@mib.org> - 2019-11-22 10:53 -0800
                  Re: How to parse attributes? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-23 00:08 +0000
      Re: How to parse attributes? scott@slp53.sl.home (Scott Lurndal) - 2019-11-21 15:57 +0000
      Re: How to parse attributes? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-22 08:21 +0100
      Re: How to parse attributes? Bart <bc@freeuk.com> - 2019-11-22 12:11 +0000

Page 2 of 2 — ← Prev page 1 [2]

#148101

=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> writes:
>On Wednesday, 20 November 2019 10:41:27 UTC+2, Philipp Klaus Krause  wrote:
>> C2X has attributes.
>> Implementation in the front-end seems straigtforward, except for one
>> bit: Keywords are treated as normal identifiers in attributes.
>> 
>> E.g. the following
>> 
>> int i;
>> 
>> void f(void)
>> {
>> 	[[const::int]] i++;
>> }
>> 
>> is valid C.
>> 
>> So far, a plain lex / yacc parser, would recognize keywords as tokens in
>> the lexer, where we don't know if we're in an attribute-specifier.
>> That makes it hard to allow keywords in attributes. Of course one could
>> create lots of rules for yacc for all the individual keywords, but that
>> doesn't look like a clean solution to me.
>> 
>> Is there an easy solution that I overlooked?
>
>I haven't had reasons to make lex/yacc parser for 15 years but I
>vaguely remember that it wasn't difficult for to make lexer to realize
>that we are in /* const::int */ comment or that we are in 
>"  const::int " string literal so what is the  problem for it to
>realize that we are in [[ const::int ]] attribute now?

Traditionally, the preprocessor removed comments prior to passing
the source to the compiler; even in a more modern integrated compiler,
I'd expect the pre-processing to occur before the compiler lex phase
just to keep things simple.

The point about handling strings stands, however.

[toc] | [prev] | [next] | [standalone]

#148113

> I haven't had reasons to make lex/yacc parser for 15 years but I
> vaguely remember that it wasn't difficult for to make lexer to realize
> that we are in /* const::int */ comment or that we are in
> "  const::int " string literal so what is the  problem for it to
> realize that we are in [[ const::int ]] attribute now?

That's a truism. There's nothing to be unsure about.

[toc] | [prev] | [next] | [standalone]

#148118

On 21/11/2019 07:16, Öö Tiib wrote:
> On Wednesday, 20 November 2019 10:41:27 UTC+2, Philipp Klaus Krause  wrote:
>> C2X has attributes.
>> Implementation in the front-end seems straigtforward, except for one
>> bit: Keywords are treated as normal identifiers in attributes.
>>
>> E.g. the following
>>
>> int i;
>>
>> void f(void)
>> {
>> 	[[const::int]] i++;
>> }
>>
>> is valid C.
>>
>> So far, a plain lex / yacc parser, would recognize keywords as tokens in
>> the lexer, where we don't know if we're in an attribute-specifier.
>> That makes it hard to allow keywords in attributes. Of course one could
>> create lots of rules for yacc for all the individual keywords, but that
>> doesn't look like a clean solution to me.
>>
>> Is there an easy solution that I overlooked?
> 
> I haven't had reasons to make lex/yacc parser for 15 years but I
> vaguely remember that it wasn't difficult for to make lexer to realize
> that we are in /* const::int */ comment or that we are in
> "  const::int " string literal so what is the  problem for it to
> realize that we are in [[ const::int ]] attribute now?
> 

I've never used such tools at all, which is a good thing as I didn't 
know quite how restrictive they are. My syntax needs the flexibility, eg:

   a := 5 mb          # ie. 5 x 1048576 (5 million for 5 x 1000000)
   asm mov ax, 0

mb, mov, ax have special meanings here, but otherwise can be used as 
normal identifiers:

   int mov, mb, ax

Sometimes, an actual reserved word needs to be used as an identifier 
(real example):

   `exit(1)

'exit' normally is used to break out of a loop, but here I need to call 
the foreign function "exit" in the C library.

-----------------------------

However, even here using a manually written lexer and parser, dealing 
with:  [[const::int]] is a little tricky, if my "`" trick can't be used.

A reserved word or identifier both have a "symptr" field in the token 
data pointing into the symbol table (a reserved word is an identifier 
which matches a certain set of symbols so its token code is different).

By ensuring "symptr" is null for all other kinds of symbols (a one-line 
change), then a value that is not null means this is a name - either 
reserved word or identifier.

The following function (not C, but easy enough to follow) is a sort of 
proof of concept:

-----------------------------------
function readattribute:unit=
!positioned at "["
     ref strec d,e

     lex()                          ! read second [
     checksymbol(lsqsym)
     lex()
     d := lx.symptr
     if d = nil then serror("Name expected") fi
     lex()

     checksymbol(dcolonsym)
     lex()
     e := lx.symptr
     if e = nil then serror("Name expected") fi
     lex()
     checksymbol(rsqsym)
     lex()
     checksymbol(rsqsym)
     lex()

     println "Attribute seen:", d.name, e.name

     return createunit0(j_exit)            ! some dummy return value
end
-----------------------------------

A bit fiddly, but source input of:

    print [[const :: int ]]
    print [[abc :: def ]]

displays:

    Attribute seen: const int
    Attribute seen: abc def

(const/int are also reserved words here. Open "[" is normally used for a 
set constructor, which isn't allowed outside an expression, hence the 
'print')

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web