Path: news.daimi.aau.dk!poe From: Jacob Seligmann Newsgroups: comp.lang.beta Subject: Re: BETA questions Date: 28 Apr 1995 16:09:05 GMT Organization: DAIMI, Computer Science Dept. at Aarhus University Lines: 59 Approved: mailtonews@daimi.aau.dk Distribution: world Message-ID: <3nr3v1$f3f@belfort.daimi.aau.dk> NNTP-Posting-Host: daimi.daimi.aau.dk Mark Nowiasz wrote: > - The (only yet existing) Compiler did NOT correctly implement the BETA > language (no repetitions of static elements, one has to use (* instead > of {, etc. ) In my opinion, there's a strong difference between a compiler not implementing a language correctly (i.e. generating code with wrong behavior) and merely not providing an implementation of *all* the language's features (i.e. refusing to compile certain constructs), especially if these exceptions are clearly documented as is the case with the Mjolner BETA compiler. As for your concrete examples, I believe repetitions of non-simple objects will be implemented in the next version of the compiler; meanwhile, you can use the simple trick described in the FAQ, Question C04. I hardly find the "(* ... *)" versus "{ ... }" distinction an issue. > - The compiler gave out (relatively useless) warnings ("a run-time check > will be generated here") but stopped at real errors ("...stopped because > of semantic errors") without any indication where the error occured. I agree that the "a run-time qualification check will be inserted here" warnings can be annoying at times. I believe that's why there's an explicit compiler switch ("-noquawarn") to disable them. (Simply include this switch in the BETAOPTS environment variable to disable the warnings permanently.) For some reason, line numbers are not stored in the intermediate abstract syntax tree (.ast) representation, and are therefore not shown when a compilation halts due to semantic (as opposed to syntactic) errors. This is not a problem if you're working in the integrated Mjolner environment using the Sif hyper-structure editor, but is clearly unacceptable in batch settings. I hope this will be fixed in a future version of the compiler. In any case, you can always examine the .lst file produced when the compilation stops to find the culprit. > - BETA-programs are very large (> 250k even for a simple "Hello World" program) > and REALLY slow (see below) The reason why "Hello World"-type programs are so large is that both the run-time system (~75Kb, including the garbage collector) and the basic BetaEnv library (~175Kb) are linked into the executable. If you think 250Kb for "hello world" is bad, you should see its X/Motif counterpart! Shared libraries would solve this problem. As a side note, it is my experience that BETA programs tend to grow much more slowly in size than programs written in most other languages (particularly non-object-oriented ones) probably because the language itself encourages the the programmer to reuse components throughout. /Jacob Seligmann ------------------------------------------------------------------------ Systematic Software Engineering A/S Phone: 86 15 18 66 Frichsparken Direct: 86 15 18 22 - 116 Soeren Frichs Vej 42 K Fax: 86 15 19 66 DK-8230 Aabyhoej, Denmark E-mail: jas@systematic.dk ------------------------------------------------------------------------