Path: news.daimi.aau.dk!news.net.uni-c.dk!howland.erols.net!news-peer.sprintlink.net!news.sprintlink.net!Sprint!newsfeed.nacamar.de!news-kar1.dfn.de!news-fra1.dfn.de!Uni-Dortmund.DE!not-for-mail From: Mark Nowiasz Newsgroups: comp.lang.beta Subject: Re: Inconsistency in the Mjoelner implementation? Date: 16 Feb 1998 13:21:54 GMT Organization: University of Dortmund Lines: 88 Sender: Mark Nowiasz; ; Message-ID: <6c9ehi$3ph@nx2.HRZ.Uni-Dortmund.DE> References: <6c1hga$39h@nx2.HRZ.Uni-Dortmund.DE> <6c293c$980@nx2.HRZ.Uni-Dortmund.DE> <6c7mga$l2k@nx2.HRZ.Uni-Dortmund.DE> NNTP-Posting-Host: sx2.hrz.uni-dortmund.de User-Agent: tin/pre-1.4-980105 (UNIX) (SunOS/5.5.1 (sun4u)) Xref: news.daimi.aau.dk comp.lang.beta:11405 Peter von der Ahe wrote: [...] > The point however was that it can be non-trivial for the compiler to > decide if the programmer wants an inserted item or not - you said it > was trivial, and it should be left to the compiler to decide. I say > that you can't let the compiler decide. Oh, I think I know what youy mean.. here's a better example for what you wanted to show: (# a_pattern : (# i, j : @integer enter j do (* do something ... *) exit (i+j) #); (* ... *) a, b : @integer; do (for i:10 repeat a->a_pattern->b; for) #) Indeed, in this case the compiler cannot determine if a new object or inserted object should be created. Nevertheless, it is possible for the compiler to decide if it should create a real new object or jutst an inserted object whenever it encounters a construct like "a->&b->c": if the b pattern contains a variable which isn't in the enter list, create a new object. if not, create an inserted object. But: why this complicated and unreadable construct just for the sake of optimization? It would be *much* better if it had been left out of BETA, for two reasons: 1. If I really would liek to help the compiler to produced optimized code, a much more logical solution would be: b : @an_object; (...) a -> b -> c; 2. BETA has got a garbage collection. Now, the advocates for a garbage collection claim that a garbage collection is very efficient and fast.. so why bother? > MN> BTW, if in the Mjolner system a -> b -> c is a synonym for a -> > MN> &b ->c, does the example above work correctly? > No, it loops forever. Oh, wow.. this means that Mjolner systems does not conform to the BETA specification. Well, in earlier versions it didn't, either, but at least it said so when compiling (e.g. repetition of references). This behaviour is extremely dangerous: a BETA programmer relying on thie feature of inserted objects would get no compiler warnings, nevertheless the code - produced by the compiler- would be incorrect. Worse, it produces extremely inefficient code: (for i: 1000 repeat i -> putInt; for); This would generate 1000 new putInt objects, which could be avoided if putInt would be static reference to an object.. and if the compiler should really generate inserted objects, the programmer would have to know the code of putInt to make sure that a subsequent call to putInt won't have unwanted sideeffects. OK, so why is the feature of "inserted objects" in BETA? It could easly be avoided by explicitly instantiating static objects, it leads to a breach in the inner logic of BETA and the Mjolner compiler doesn't implement it, resp. implements it wrongly. Regards, Mark -- |\ _,,,---,,_ Mark Nowiasz (buckaroo@blackbox.free.de) /,.-'' -. ;-;;,_ PGP-Key available at keyservers/request. |,4- ) )-,_..;\ ( '-' http://www.free.de/~buckaroo/ '---''(_/--' -'\_) IRC: Buckaroo | Voice: +49 177 2190385