From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20091030162714.GB1025@shodan.homeunix.net> References: <3aaafc130910300855l3d7113a2hd3fcf3c4330930c1@mail.gmail.com> <20091030162714.GB1025@shodan.homeunix.net> Date: Fri, 30 Oct 2009 19:19:06 +0100 Message-ID: From: Rudolf Sykora To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [9fans] hoc's behaviour, unary operators Topicbox-Message-UUID: 94c032cc-ead5-11e9-9d60-3106f5b1d025 2009/10/30 Martin Neubauer : > * Rudolf Sykora (rudolf.sykora@gmail.com) wrote: >> (a-- b wouldn't make sense) it probably can't (can it?) be parsed >> simply with yacc... > I don't see why it would be impossible. Just introduce a binary -- > operator (cf. -1 vs. 1-2). Whether it's worth it... Yes, probably you're right that it can be done. At least partially. First, '+-' and '-+' situation should be handled (unary '+' introduced). Then: The yylex() function in hoc.y returns an 'INC' token for '++' and a 'DEC' for '--'. So if one adds a binary INC and DEC, changes the priority appropriately, it could work... BUT there are more complicated cases: Python handles correctly e.g. 2-----7, 2+-+-7, 2+++-7,... C-compiler that I use in my linux, gcc, is ok for a+-b and a-+b, also for a+-+-b, but not for a++b or a--b or any alike. >>From these more complicated examples like 2----7, I am getting an impression that it'd be better to not produce tokens like INC & DEC in the (which must then be decomposed into effectively unary operators), but to only have '+' and '-' tokens and work with them somehow... Ok. I wrote this because I was suprised that something I had expected just doesn't work in the way. I don't think I am capable of actually changing the lexer & parser of hoc, but if I try and succeed, I'll tell you. Thanks Ruda