sommar@enea.UUCP (10/31/87)
conybear@moncsbruce.oz (Roland Conybeare) writes: > For example, suppose I want to allocate space on the stack, but I don't >know how much space will be required until runtime (this is very important >if I want to implement function calls efficiently in an interpreter, or >write a B-tree where the user provides the size of the elements to be stored >in each B-tree). > How do I proceed? If the language does not provide this facility and >gives me no way around its restrictions, then I must find another >solution within the language, and this may be a high price to pay If this is important to you, use a language which helps you do this. Assembler if you can live without range checking. Perhaps you can do it in C. (I don't speak C, so I don't know) If you prefer programming in a controlled way, languages like Simula and Ada premit declaring arrays with the size set at run-time. Whether you will get an efficient program, using these languages depends on the *compiler*, not the language itself. > I also propose that our compilers should be extensible. My ideal compiler >would look like one of today's compilers, but decomposed into a set of modules >with explicit interfaces. Some modules would describe how to compile builtin >types. If I did not like the compiler's code generation for floating point >numbers, I could reimplement the appropriate module. If I felt that complex >numbers were essential, I could implement them. While much of this >can be done using user-defined types and functions, the important thing is >that if I have control over my types' compilation then I also control their >implementation. Seems like some people have all time in the world. But if you are that lucky, why don't you write your own compiler? The notion of a user- modifyable compiler just gives me headaches having to read the manual for it. And must say that I believe that we programmers would be more productive than all wasting our time modifying the same compiler. -- Erland Sommarskog ENEA Data, Stockholm sommar@enea.UUCP It could have been worse; it could have been Pepsi.