Path: csiph.com!eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Rod Pemberton" Newsgroups: alt.os.development Subject: Re: C parser ramblings, language design, etc Date: Sun, 27 Dec 2015 17:35:13 -0500 Organization: Aioe.org NNTP Server Lines: 169 Message-ID: References: NNTP-Posting-Host: n4wpt9zq8xR26Ttf9mo2BA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/12.16 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com alt.os.development:9052 On Sun, 27 Dec 2015 08:51:24 -0500, James Harris wrote: > On 01/10/2015 01:32, Rod Pemberton wrote: >> On Tue, 22 Sep 2015 15:04:28 -0400, James Harris >> wrote: > Replying after some absence. You may have already got past > the points below. Feel free to ignore if you have. Nope ... Since the method I was using for branch labels is not correct, I'll probably rewrite the code to work with one of the two methods for generating them which I posted. I haven't decided as to which, yet, but one will be sufficient for known brace locations. I determined (and posted) the nesting levels in hope that it might help me decide ... Determining the locations of the "missing" or "implicit" braces, or which type of WHILE etc, will just be left for a future task since I don't plan on using a grammar rules based method or re-coding it at present. This part of an already rather large program that would mostly be discarded, if that was done. On merit alone, I'm hanging on to the code. Around the time you last posted, I figured out two paths I could take my command-line interpreter project, after realizing that half my OS code should be used in the command-line interpreter project and the other half should really be spun out as a pure, standalone OS. My initial path for my OS project was for an execution environment for DJGPP apps and deviated into the OS project. The first path for the command-line interpreters is towards a Windows 98/SE like OS, i.e., execution environment for DJGPP apps. I'm using "OS" loosely here. The other path would be towards a Linux kernel and/or shell on DOS. While the latter would be interesting, the DJGPP C compiler won't support full Linux apps on DOS. There is a bit of work in four or five areas I'd need to do to progress this. I _really_ haven't been motivated to do any programming since I figured out those paths for my projects ... I did do a new and small project with parsing and compiling BrainFuck, derived from my other BrainFuck and Forth and ITC projects. It combines ITC Brainfuck interpreter in C with the standard Brainfuck array in C. The ITC interpreter is a reduced, optimized, variation of my Forth interpreter. I already have other Brainfuck projects, like a single pass, no memory allocation, trivial optimizing, Brainfuck to pure C converter. Now, with a slightly different language front end or some enhancements to BrainFuck language, the ITC BF would create a very compact execution model, very embeddable. I did some work in the past on determining common BF sequences, which could provide slightly higher level language functionality. I'm wondering if I could combine it with another compact model, e.g., FSM, and whether I could find any purpose to do so, i.e., code reduction, code optimization. >>> I have been trying to get my head round what you are trying to do >>> - or, more accurately, how you are trying to do it. I think I am >>> getting closer to understanding what you have in mind. I am not >>> sure of all the details, though. >> >> ... >> >>> For example, when you see a WHILE token what other info >>> do you have available that you can look at? >> >> WHILE >> >> and anything else I code up, such as flags. > > Does your approach boil down to needing to distinguishing WHILE > in these three contexts? > > 1. at the start of a statement > 2. at the conclusion of a DO construct > 3. everywhere else (an error) (I'm not sure. The thread is somewhat stale now. My mental state on the issue is lost, but I seem to recall you asking something similar previously.) However, probably 1 and 2, but not 3. Issues with erroneous code would be for later, or as a result of failed code generation, or for the user, or for the public to fix, depending on my future time, effort, and/or desires. I.e., no proper syntax checking at the moment. E.g., I can always run my personal C code through other compilers to confirm correctness for now. In my own languages, I can simply use different keywords for each WHILE position, e.g., DO UNTIL, or use my personal preference, which is to have only one keyword, like LOOP , for an infinite looping construct. Of course, it would be breakable or exitable. > If so you might get away with setting flags BUT because C is > a recursive language you would need to save any such flag or > flags on a stack if you made a call that could end up being > recursive. ... >> Technically, I *could* walk the AST, but that is slows everything >> down. I was attempting to do this without doing so, i.e., single >> pass of AST to assembly, no walking or backtracking of ASTs whether >> as a binary tree or linked-list. > > If you can walk any sort of tree at this point then I have to suggest > it would be better to use a normal parse mechanism. With the exception > of a backtracking parser, parsing is one of the faster phases of a > compiler so you may be ill advised to try to save time with your > contextless approach. ... > It may be a bit like trying to analyse a chess > position based purely on the current board without forming a game > tree: great and revolutionary if you could make it work but probably > impractical, impossible to program, and more work in the long run. Why do you see this as any different from analyzing a chess game from the starting positions? i.e., no move history or game tree, unless artificially constructed for initial piece placement ... Depending on the pieces remaining and their positions, especially proximity, it may actually be much easier, i.e., fewer pieces and positions under attack. Positions under attack can be trimmed for computation, if the opponent is limited to short-move pieces, e.g., no queen, rook, bishop. The opponent may not be able to move into the broad attack positions of your queen, rook, bishop. IIRC, the end-games of chess up to a handful of pieces have all been solved. IIRC, you brought up a chess analogy before too. > It's an interesting idea. You might get it to work. It reminds me, > however, that when I was at school I tried to come up with an > algorithm for marking a game that some people call bulls-and-cows. > Rather than do it in a simple way I tried to do it a clever way > that would be faster than the obvious solution. But it became so > complicated that I eventually realised that it would be far better > to do the marking in the most obvious way. Even if I had got my > clever approach to work it would have been unmaintainable. Bulls and cows? ... (look up) Wikipedia says the game is similar to the commercial game Mastermind. I loved Mastermind as a kid for a year or so. However, I have no recollection as to how the game was played, or how I solved it, just that I seemed to win frequently, against other kids ... I still remember the board and pegs. The Wikipedia page on Mastermind says Donald Knuth determined an algorithm for solving it. Some mathematicians have developed their own algorithms. It seems they've determined the average game length. So, any algorithm for solving either game is measurable. Rod Pemberton -- The idea that sentient beings can be suppressed by a few simple rules is a farce. Even so, Isaac Asimov posited such rules for sentient artificial intelligence.