Path: news.daimi.aau.dk!not-for-mail From: Erik Ernst Newsgroups: comp.lang.beta Subject: Re: Inconsistency in the Mjoelner implementation? Date: 10 Mar 1998 19:02:14 +0100 Organization: DAIMI, Computer Science Dept. of Aarhus Univ. Lines: 120 Message-ID: References: <6c1hga$39h@nx2.HRZ.Uni-Dortmund.DE> <6c293c$980@nx2.HRZ.Uni-Dortmund.DE> <6c7mga$l2k@nx2.HRZ.Uni-Dortmund.DE> <6c9ehi$3ph@nx2.HRZ.Uni-Dortmund.DE> NNTP-Posting-Host: fraxinus.daimi.aau.dk Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII X-Newsreader: Gnus v5.3/Emacs 19.34 Xref: news.daimi.aau.dk comp.lang.beta:11449 Of course I'm reading news long after "it happened," but I feel like answering this one anyway.. Mark Nowiasz writes: > Peter von der Ahe wrote: > > [..] non-trivial for the compiler to decide [..] inserted item or > > not [..] > > [example] > > Indeed, in this case the compiler cannot determine if a new object > or inserted object should be created [..] Of course, it is in general an undecidable problem whether or not allocating a new object each time has the same semantics as reusing the same object many times. But many optimizations are such that finding the exact set of cases where it is correct to apply them is just as hard as solving the halting problem. > 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, [..] Sure, agreed!! Actually, the "inserted item for better performance" idea emerged in the late 70ties I think, and it just never really went away again, it even made it into "the BETA Book." As somebody already mentioned, the Mjolner compiler does _not_ create static objects for inserted items, it always generates new objects, and I know several BETA people (including me :-) who don't think it _should_ be implemented differently, for exactly those good reasons you're giving, Mark. (Programmer aided optimization pollutes a design and doesn't help "enough" anyway, if I recall your arguments correctly) Moreover, lots of existing BETA source code works with the new-object-each-time semantics and would probably break if it were changed to a same-object-every-time semantics .. which I also think is error-prone and confusing. Well, actually, a descriptor without prefix and without attributes or SLOTs (and possibly even more restrictions) _does_ get a special treatment, such that L: (# do .. restart L #) is just as fast and memory-cheap as (L: .. restart L :L) would have been, whence the (L: :L) construct could simply be removed from the language. But it's OK for an implementation to optimize special cases like that _as_long_as_nobody_can_detect_ that there are no new objects generated for each iteration. To behave "as-if" is always enough. So why don't we just agree on forgetting about that same-object-every- time idea? In stead, "Inserted item means create a new object for each excution," period. All the existing source code works with that, because that's the reality today. We'd just have to update the documentation .. ------------------------------------------------------------ Now what's "&" good for, if "a->b->c" ("b" is a pattern) always creates a new object, i.e. it is equivalent to "a->&b->c" ? We could just deprecate it ("That's an old syntax, don't use it, it'll be removed from the language some day"), or we could make it obligatory (just make "a->b->c" a compile-time error when "b" is a pattern). I'd prefer allowing "a->b->c" even when "b" is a pattern: Just like all the other transparency properties of BETA, it is not revealed by the _application_ of the name "b" but only by the _declaration_ that it is a pattern and not an object (or dyn.ref. to object). This means that a "method call" (when "b" is a pattern) and "extracting the state of an object" (when "b" is an object, and the enter/exit-lists are used to define evaluation/assignment semantics) looks the same, LOOKS(get value from method) = LOOKS(get state of object) and that is a _nice_ property! Just like LOOKS(access object via pointer) = LOOKS(access object directly) (a static reference "is" an object, a dynamic reference "is" something which can refer to different objects, i.e. a pointer, somehow) e.g. (# t1: @text; t2: ^text; do .. (* direct/indirect access makes no difference! *) (if t1.length = t2.length then .. if); t1->t2; .. #) whereas C languages would have things like /* direct/indirect access different */ if (strlen(&t1) != strlen(t2)) ..; strcpy(t2,&t1); Even the terminology "static reference" and "dynamic reference" was chosen (deliberately) in a way that makes the difference between direct and indirect access almost invisible. IMHO, we don't want to change BETA in such a way that this transparency gets undermined. So we could just drop the "&" .. cheers, -- Erik Ernst eernst@daimi.aau.dk Computer Science Department of Aarhus University, Denmark