From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b733c10ea3655840,start X-Google-Attributes: gid103376,public From: Ted Dennison Subject: Announcement: OpenToken 1.1 released Date: 1999/05/20 Message-ID: <37444A4F.20183EE3@telepath.com>#1/1 X-Deja-AN: 480196981 Content-Transfer-Encoding: 7bit X-Accept-Language: en Content-Type: text/plain; charset=us-ascii X-Complaints-To: Abuse Role , We Care X-Trace: monger.newsread.com 927221915 216.14.8.58 (Thu, 20 May 1999 13:38:35 EDT) Organization: Telepath Systems (telepath.com) MIME-Version: 1.0 NNTP-Posting-Date: Thu, 20 May 1999 13:38:35 EDT Newsgroups: comp.lang.ada Date: 1999-05-20T00:00:00+00:00 List-Id: Version 1.1 of the OpenToken package has been released. It is available at http://www.telepath.com/dennison/Ted/OpenToken/OpenToken.html . It is also available from links on my homepage and AdaPower. The new features are: * A default text feeder function that can be redirected to whatever file you want via Text_IO. * A user's guide with a tutorial. * An example program implementing the syntax in the Aho/Sethi/Ullman Compilers book's (aka: "The Dragon Book") example 3.6. Relevant portions of the Readme file are attached below: ----------------------------------------- OpenToken Package Readme Version 1.1 The OpenToken package is a facility for performing token analysis within the Ada language. It is designed to provide all the functionality of a traditional lexical analyzer generator, such as lex. But due to the magic of inheritance and runtime polymorphism it is implemented entirely in Ada as withed-in code. No precompilation step is required, and no messy tool-generated source code is created. Additionally, the technique of using classes of recognizers promises to make most token specifications as simple as making an easy to read procedure call. The most error prone part of generating analyzers, the token pattern matching, has been taken from the typical user's hands and placed into reusable classes. Over time I hope to see the addition of enough reusable recognizer classes that very few users will ever need to write a custom one. Ada's type safety features should also make misbehaving analyzers easier to debug. All this will hopefully add up to token analyzers that are much simpler and faster to create, easier to get working properly, and easier to understand. History Version 1.1 The main code change to this version is a default text feeder function that has been added to the analyzer. It reads its input from Ada.Text_IO.Current_Input, so you can change the file to whatever you want fairly easily. The capability to create and use your own feeder function still exists, but it should not be nessecary in most cases. If you already have code that does this, it should still compile and work properly. The other addition is the first version of the OpenToken user's guide. All it contains right now is a user manual walking through the steps needed to make a simple token analyzer. Feedback and/or ideas on this are welcome. Version 1.0 This is the very first publicly released version. This package is based on work I did while working on the JPATS trainer for FlightSafety International. The germ of this idea came while I was trying to port a fairly ambitious, but fatally buggy Ada 83 token recognition package written for a previous simulator. But once I was done, I was rather suprised at the flexibility of the final product. Seeing the possible benefit to the community, and to the company through user-submitted enhancement and debugging, I suggested that this code be released as Open Source. They were open-minded enough to agree. Bravo! Future I do plan on actively maintaining this package. How actively depends on user submissions, my own schedule, and what pans out for my studies. I am proposing to do my master's thesis on this, but they seem to think it "isn't enough", even with the proposed parsing facility added. I'll admit developing a parser generator in inlined code using OO technology to do what used to have to be done with a precompiler doesn't seem to be an amazingly clever idea in hindsight, but as near as I can tell this facility is unique. It certainly should be enough work. We will see what happens. Things I would like to add soon: A string literal recognizer Things on my plate for later: Look into changing the feeder function into a stream reference. I was unfamiliar with streams when I wrote this package. It looks like they would make several things much easier to deal with, but the devil's always in the details... More recognizers The Biggie: A parsing facility in the same vein as this token analysis facility! Things you can help with: More recognizers - The more of these there are, the more useful this facility is. If you make 'em, please send 'em in! Well isolated bug reports (or even fixes). Version 1.0 has been fairly thoroughly wrung out already, but that doesn't mean you won't find any problems. Again, I hope you find this package useful for your needs. -------------------- -- T.E.D. Home - mailto:dennison@telepath.net Work - mailto:dennison@ssd.fsi.com WWW - http://www.telepath.com/dennison/Ted/TED.html ICQ - 10545591