Re: Need input on designing a new language

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]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.