[A86] Re: Alternative Language compiler for the z80.
[Prev][Next][Index][Thread]
[A86] Re: Alternative Language compiler for the z80.
> I have literally had these same thoughts off and on for the past year or
so.
> I have not been able to visualize what this new language should be.
> Should it be a strict subset or C, or should it be something completely
> different? I feel intuatively that such "small-impact" language should be
> possible. I especially like the idea of an on calc compiler. Here are a
> few possible features that I see this "X" programming language having:
I have been using C for six years, and as such am very comfortable writing
in a C style language, and don't like to user other languages with different
syntax styles (like Pascal). With that in mind, I'm sure that other users
will feel differently. C does not have the easiest syntax to learn and use,
but I don't think anyone capable of writing in assembly language would have
trouble picking it up. Informative error messages would be good. I have
helped several people who have very little computer experience pass the
beginning college level programming courses that were taught using C++, and
by the end of the semester they seem to get the hang of the basic syntax, so
this alone shouldn't be an issue. We aren't trying to make another BASIC.
There are a lot of "features" of C that are generally unecessary and over
complicate the language. An example is comma expressions. Other than a for
statement, I don't think I have ever used them, and even in that context I
don't use them anymore (I feel it is bad style). Things like structs and
unions are very useful, but complicate the parser and code generator. If at
some point you want an on calc version, you'd want to consider these types
of things. If this isn't an issue, then pretty much anything goes.
> (1) Language should be procedural - (unless someone can produce a
> satisfactory simplistic OO model)
Definitely. There is no place for true object oriented programming on the
calc. We are looking to build a glue language for easily writing small,
efficient programs, not something more bloated than TI-BASIC. At least,
that is my goal. Object oriented techniques are of course usable in C.
Function pointers, jump tables, etc. But it doesn't need to be a part of
the language.
> (2) Java style object file production - In other words, one object file
> being produced for one source file. None of this header file buisness.
I disagree. It is a must to assemble everything together. If it is to
generate "normal" programs, then you are limited 8k. If you want to use
techiniques similiar to Zelda 86 to have larger programs, that is possible,
and the process could be assisted by the compiler or assembler. The object
code still needs to be generated all at once (or in two stages).
The traditional compile -> assemble -> link phase does not work when you
can't easily generate relocatable code. There are different ways this could
be done. You could either have a single program that uses the preprocessor
to include all the source files (if there even is a preprocessor), or it
could be a different feature of the language, or the compiler.
> (3) Possibly loosely typed - I'm still not sure about this one. Strong
> typing would be nice, but is it neccessary?
Depends on the type of the language. Pascal, for example, is strongly
typed, but differently from C++. As I remember, you can't do casting (been
a very long time). What happens when you assign a word to a byte? Or a
byte to a word? In the first case, you'd issue a warning if there wasn't a
cast. But in the second case, should you still issue a warning if there
isn't a cast?
> (4) Pointers - Full pointer support, including function pointers
Most definitely.
> (5) Structs - Full support for multilayer structs.
This would get hairy to implement on an on-calc compiler. Though, maybe if
the language were written in itself :)
> (6) Base Types - This part has perhaps bothered me the most about language
> X. I've always loved programming in C and C++, but I've always felt that
> the choice of base compiler types was awkward. I'm sure there is an ANSI
> standard for it, but just because it is standardized doesn't make it feel
> less akward. You have int, char, float, long. This might not get a
> positive response from my fellow programmers, but I suggest that langauge
X
> have a single base type as the "byte". To me this is simple and elegant.
> All other types would be derived from this somehow within the language.
I agree. I hate having to write "unsigned char". It would be much easier
to write "uchar". I am unaware of a portable header file that has these
defined (I think C99 has something about this, but I don't have any info on
it currently).
Would the default type be signed or unsigned? I think that the signedness
of a type should be a part of the type, rather than an add on as it is in C.
Possibly eliminate ambiguity and always specify the signedness as part of
the type. A nice set of types, similiar to Pascal, would be sbyte, ubyte,
sword, uword, sdword, and udword. Unfortunately, that does look messy. But
it also looks messy when you have to write it out, and then there is a
default signedness. I'm open to suggestions here.
I don't know how floating point should be handled. It might be nice to have
native support for it, and implement it using the ROM calls. Though, it
might be better off to just have a set of well documented function calls for
it. I believe TIGCC does floats natively using the TI-OS, but I don't know
how it does it internally.
> (7) Operator Support - This has also bothered me quite a bit. How should
> operators be handled in the language. It seems to me that operators are
no
> more than syntatical sugar for "special" functions. Usually I percieve
> "special" features as inelegant and unclean. I've always leaned towards
> simple consistant interfaces. C appears to provide two interfaces for
> simular things: functions and operators. But I can't invision a langauge
> maid entirely of operators or one made entirely of function calls. Just
> take a look at LISP/SCHEME syntax for this idea taken to the extream. Yet
I
> don't know how the new language should handle this.
I'd like to take some time to learn LISP, especially after reading some very
cool stuff about it, but haven't had the time. Do you have any good
websites or books to recommend? I haven't looked yet, so maybe a Google
search will be all I need.
When I first saw this paragraph, I thought, great, where's he going with
this? I'm glad you're not in favor of overloading operators as in C++. I
think in a language like C++ this has merit, especially with templates and
things like STL. But for a simple langauge like this, it has no place. You
definitely need function calls and operators. Making something close to C
or Pascal should be fine.
> Anyway, that is a partial brain dump of things I've thought about. A
> descussion in this forum might not lead to any more clear a vision than i
> already have in my head, but you never know. Its funny, I feel totally
> capable of working with any laungage but I can't articulate to myself a
> simple new language to meet the properties expressed by David Phillips
> above. Maybe this means such language doesn't exists. (hardly a proof
> though 8-) ).
A lot of weird languages exist. Just because you know there is a simple way
to do something doesn't mean it's easy to figure out :) It's amazing how
long it can take to see the really elegant solution.
Sometimes a good way to work out an idea for this type of thing is to just
sit down and start writing a program using the fictitious language. See
what seems natural, and how it looks. We can work on things like a formal
definition and grammer later.
Another point you didn't bring up, but reminded me of, is a standard
library. This would be very nice to have, but I don't know of a good way to
do it. Depending on what it did, it could be done several different ways.
Perhaps the best way would merely be to have an include file, or several
include files, with useful functions that people would want to use. The
compiler would only include functions that are actually used by the code
(unfortunately, this is much more difficult than it seems). Alternatively,
there could be a special declaration for functions that are actually used.
A function would be things like a sprite routine, or a wrapper for a
floating point ROM call. Although it could be beneficial to have libraries
shared between programs, it would probably be best to make every program
standalone, at least on the 86. On calcs with shells that support these
features, alternative methods could be explored.
References: