Re: HLA, Flex, and Bison

From: T.M. Sommers (tms2_at_mail.ptd.net)
Date: 10/14/03 

Date: Tue, 14 Oct 2003 06:01:51 GMT

Randall Hyde wrote:
> "T.M. Sommers" <tms2@mail.ptd.net> wrote in message news:ISmeb.8451$yp6.239735@nnrp1.ptd.net...
>
>>Randall Hyde wrote:
>>
>>>"T.M. Sommers" <tms2@mail.ptd.net> wrote in message news:Ooaeb.8370$yp6.232795@nnrp1.ptd.net...
>>
>>Is there a reason the file can't be made smaller? A file that large
>>is very hard to work with, and takes forever to compile, and has to be
>>recompiled in its entirety for even the smallest change.
>
> You're telling me!
> Actually, it can be made quite a bit smaller (and has been made
> quite a bit smaller, at one time it was over 105,000 lines long).
> Slowly, I've been eliminating duplicate code; I've been moving
> large blocks of C code into external procedures. The big problem,
> though, is the sheer number of productions. HLA is a *big* language.
> I could probably cut the productions in half with a better design.
> But, quite frankly, I'd rather put that effort into HLA v2.0 (if I could
> ever get back to work on it). Flex & Bison were poor choices for
> a lot of reasons. The inability to support separate compilation is
> one of them (and Rene/Betov wonders why I don't think highly
> of RosASM's inability to support linking in separately compiled
> modules).

I don't know what you meant about the inability to support separate
compilation. You can certainly call external functions from within a
yacc production.

>>May I also suggest using the standard .y and .l suffixes for yacc
>>(bison) and lex (flex) files? Typically on Unix make knows how to
>>handle them without being told, just as it knows how to make .o from
>>.c, for instance, which makes the make file easier. Also, emacs knows
>>about them, too (I *will* go there).
>
> Feel free.
> HLA v1.x is approaching the freeze point anyway. Indeed, I seriously
> doubt you'll find too many new features added to the language. Just
> maintenance stuff from here on out. The existing makefiles have served
> me well and as there have only been a few others interested in the source
> code in the past, I've never gone out of my way to change how the
> compilation behaves. To me, getting the library code consistent between
> the two OSes has been the major event of this year :-).

I've finally installed the newest bison (had to upgrade the os first),
and managed to compile the program natively on FreeBSD with only two
small changes to hlaparse.bsn:

1) comment out the definition of __STDC__ on line 612; and
2) add #include <sys/types.h> before #include <sys/timeb.h> on line 31.

I have not tested it, because the libraries will have to be fixed
first, and that looks like a big job.

The makefile is a bit of a mess right now, but I could clean it up and
send it to you if you want.

Relevant Pages

  • [PATCH] perf: avoid structure size confusion by using a fixed size
    ... Subject: perf: avoid structure size confusion by using a fixed size ... compilation units for some yet-to-be-explained reason. ... u64 data_offset; ...
    (Linux-Kernel)
  • Re: tecomp 0.6 released
    ... The idiots of Visual Eiffel didn't like this and so the ... I'm also 90% sure that tecomp can't do it because they all suffer ... Compilation time with a stupid simple command line ... I do not yet know the reason. ...
    (comp.lang.eiffel)
  • Re: Trying to resolve "Internal Compiler Error" Conflict
    ... > I have eventually found out the reason why some "Internal Compiler errors" ... > std", so collapsed during compilation. ... The "using namespace std" statement makes it possible to use objects like ...
    (microsoft.public.vc.language)
  • Re: Java and .NET (no Flames Pls)
    ... >> Well, incremental compilation never mattered much to me, for whatever ... In Eclipse, by default it compiles the code every time you ... For some reason, I thought you were talking about background compilation ... I find things like Extract Interface are pretty rarely useful since I tend ...
    (microsoft.public.dotnet.framework)
Loading