Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!world!esegue!compilers-sender From: praxis!itcp@relay.EU.net (Tom Parke) Newsgroups: comp.compilers Subject: Re: Need input on designing a new language Keywords: design Message-ID: <1990Jun6.150355.1655@esegue.segue.boston.ma.us> Date: 6 Jun 90 15:03:55 GMT References: <1990Jun4.044526.14926@esegue.segue.boston.ma.us> Sender: compilers-sender@esegue.segue.boston.ma.us Reply-To: Tom Parke Organization: Praxis, Bath, UK Lines: 66 Approved: compilers@esegue.segue.boston.ma.us klefstad@opera.ICS.UCI.EDU (Ray Klefstad II) writes: >>>Thats the heart of my problem, simple to implement. It would be easier for >>>me if I forced the user, programmer, to declare all the procedures before >>>the function body occurs... >> >>You have to decide where your priorities lie: ... >It is really more complex than that. There are (at least) four issues one >must consider when designing a general purpose language: > 1) programming ease > 2) compiler speed > 3) ease of compiler implementation > 4) language support for good software engineering - how well is the language specified - what degree of consistency checking is available (eg. type checking) - what support for modularity and re-use is there. 5) compiler portability 6) source (of programs in the new language) portability 7) reliability of compiler (similar to 3 but I like the extra emphasis) 8) efficiency of compiled programs - degree of possible optimisation - how close to the hardware (inverse of portability)? 9) how extensible is the language? 10) how dynamic is the language? I make it at least 10, any others? For subprogram declaration 8 is also significant, the more you know about a procedure before you call it the greater the scope for procedure call optimisation, for some risc architectures this can be very significant. >You asked for opinions about forward declarations and I gave it. You >didn't ask for opinions about your decision to invent and implement a >new programming language, but I will give mine anyway. Me too. Frankly, if you're worried about whether procedures need declaring before use I'd suggest you've either finished the design or started in the wrong place :-) >If your motivation is to learn something about programming language >implementation, then it's a good idea. If your motivation is to invent >yet-another-programming-language, then I predict NO ONE will ever use it. If you want to learn about programming language *design*, then it's a good idea. But lay your hands on every language spec you can find first... If you wish to learn about programming language implementation, try writing a compiler for a subset of your favourite language and then adding bits - see what's easy and what isn't ! >One more thing to consider is the purpose of your language. Who will >use it? [and more relevant points] He's right. Every programmer and his dog thinks he can design a better programming language, somehow it's only natural. But all the problems in the languages we know should make us pause and think. Having one or two better ideas isn't the hard part - it's avoiding the mistakes :-) Tom (My opinions and spelling are my own) [bah, I fixed the latter -John] -- Send compilers articles to compilers@esegue.segue.boston.ma.us {spdcc | ima | lotus}!esegue. Meta-mail to compilers-request@esegue. Please send responses to the author of the message, not the poster.