Hi folks,
after 30 years of programming with different languages (basic, pascal,
C, asm, tcl, php, bash...) I come to the conclusion that none of them
is satisfactory for me. I would like a language that needs few strokes
on the keyboard, with little punctuation, but very precise, expressive,
powerful and smart, without hidden features or pitfalls. So I started
to design a new language from scratch, paying attention to not being
deviated from existing ones: this is an important point for me. Then I
stumbled upon this forum, and found a similar project. After reading a
few messages here and there, I am thinking that my ideas are very
different and heretic: I started my design knowing that yes, pascal is
the better language I know, but this is not a good reason to borrow too
much from it because it has several weaknesses.
To better explain, I
will make two examples on how heretic I am. Let's talk about verbosity:
var lab1: Tlabel;
lab1 := Tlabel.create;
lab1.left := 10;
lab1.top := 20;
...
Here, "lab1" is cited 3 times, not counting the declaration. A WITH
clause would help little:
lab1 := TLabel.create;
with lab1 do begin
left := 10;
top := 20
end
Now lab1 is cited 2 times, but with, begin end have come in. What about
of, instead:
lab1.: create; left=10; top=20
The trick is the colon. It means "repeat from the start of the line,
until the physical line end". This is a task for the lexer/parser; the
compiler doesn't see the colon. In this example the compiler, reading
from the parser, reads "lab1", ".", then "create", then ";". A complete
statement. A note about this: "lab1.create" is interpreted as
"lab1 := Tlabel.create" (what else could be this statement: a
constructor invocation without assignment?). Then the compiler goes on
for a new statement and, because the parser still has a colon pending,
the compiler reads "lab1.left=10;". Then it reads "lab1.top=20". Then
the physical line ends, so the parser frees the colon. (You also see "="
instead of ":="). This idea goes even further because the colon can be
implicit: when the compiler expects more tokens, but they are not
there, an implicit colon is assumed:
var
// after a "var" keyword, shouldn't be an identifier?
// but there is not: so the compiler tells the parser
// "assume an implied colon"
int x // here the compiler reads "var int x"
int y // and here "var int y"
end // this "end" closes the (implicit) colon
This paradigm is simpler and more consistent than the normal pascal
way. A pascal compiler, while parsing a var block, must always check
that the next token is not a keyword (procedure, function, type,
absolute, external...). At a certain point, freepascal had to forbid
declaring object variables after its methods, just because of that
ambiguity.
You may ask "why the type specifier stays before the identifier, as in
C?". Because I think it is better, but the explanation is long.
Second heretic idea. One of the best things of pascal is its strong
typing system. But it is not strong enough, especially when some kind
of automatic type conversion is desired. Let assume we write a
procedure "print" to output human readable data. We want to print
messages, numbers, and perhaps other kind of data. There are two ways:
write several overloaded versions of print, each accepting a particular
type, or write only one: "print(st: string)". The overloaded version
forces us to write a new version every time a new type is introduced;
taken to the extreme, every time we introduce a new type, we must add
overloaded functions for every thing our program can do (print on
console, set caption of something, writing data to disk, send data over
TCP and so on). The second version, "print(st: string)", is much more
versatile: it can print anything, provided that we convert to string
for it, so the program gets filled of inttostr floattostr
format(blabla) and so on. And here is the heretic idea: a hierarchical
type system with automatic conversions (I would call them "promoters").
The most universal type is string: it can describe everything. It is
too generic, too. So let's create a new type "text", which is a string,
but a very precise string - a human readable one; and write the
function print(st: text). Now, when introducing a new type, we write a
promoter for this type, which generates a human readable string. This
way, the single print() can print anything. We can put it in a unit and
forget it. The key for this is: string is a sequence of byte complete
with a length. Strings can be concatenated searched indexed and so on
as usual. Another type "text" *is* a string, and still another one is
UTF8 (derived from text). Each of them are beasts on their own. All the
operators and functions operating on strings can be applied to text and
UTF8, because UTF8 is "text" which is "string", but certain operations
(say, search) can be overloaded/overridden: the function
pos(...) operates in a certain way on string and text, and in another
one on UTF8. This concept is simply inheritation extended to simple
types too.
I have other heretic things in my mind, but for now it should be
enough. Let me know what do you think.
Regards,
Linuxfan
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
mseide-msegui-talk mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
