Programmer's don't like syntactic sugar - it gets in the way of programming
If you like C, that's probably true. I am a programmer, always have been, and I like syntactic sugar more than C-style syntactic Tabasco with chunky glass chips. That, I believe, gets in the way of my programming.
based numbers, it's typical in other programming languages and mathematics to put the base at the end
C, C++, Ada, most variants of Pascal with a notation for hexa, MC68000 assembly, to name a few, put the base at the beginning. What (compiled) languages are you referring to? x86 assembly:-) ?
How do you plan to set precedence for your named operators?
None. They currently all share the same lowest-level priority.
C doesn't mandate anything with regard to parameter passing mechanics; a compiler is free to stuff e.g. 8 byte parameters into a single 64-bit register if it thinks it will help (e.g. in the case of a struct); I believe compilers do that already.
You misunderstood the problem. On old platforms, your struct would be copied in memory (expensive), so people just passed a pointer (faster). Then, the compiler no longer has the choice to copy the object.
C also mandates the use of pointers for output parameters. In that case also, the compiler has no choice. Similarly, once a programmer has decided that copying the object on platform A was too expensive and that he would therefore pass by reference (pointer), the compiler has no choice but pass by reference even if on platform B passing by value would have been less expensive.
Similarly, C++ semantics says that the copy constructor is called if you pass an object by value, so if your object has a constructor, the compiler needs to generate a 'this' pointer, and thus has to pass by reference, even if the object is small and you asked to pass by value.
The result parameter... also from Pascal.... which is not necessarily a bad thing, but it's too much of a "magic" variable for me, but then maybe I'm just too used to the C/C++ return keyword.
LX has a return keyword as well. And C++ has a 'this' pointer, another magic variable...
I'd like to actually use the encapsulation for security (you can't mess with private stuff) instead of just type safety (it's easier not to mess with private stuff)
I see. But that's a policy. For some applications (such as real-time, OS or driver development), you need this kind of insecure access. If the language claims to be universal, it has to support them.
Now, what does LX give you? Two things: the first one is that you can still use "unions" and put conditional access clauses. This means that you can ensure that type safety, for one, is not broken. This does not prevent malicious access, which is apparently your concern. For this second thing, you have Mozart. Look the part on "policy control." You can have a Mozart plug-in as part of your build system that checks that unions (or variant records) are not used in the code. This will be compile-time security.
Java has the same concept but not the fragile base class problem, simply because of its implementation.
Then, we don't talk about the same thing. To me, Java has the fragile base class problem. Consider a class framework you don't own with a root class 'Car' defining a 'Speed'. The framework hypothesis is that all cars have four wheels. You'd like to add support for 6-wheel cars in a SixWheeler class. Obviously, the place where you'd like to add a 'NumberOfWheels' member would be the base Car class, but you can't, because you don't own the framework. Even if you could, you would still have an issue if another part of the class hierarchy (say, deriving from 'Bus') already had a 'NumberOfWheels' member with slightly different semantics.
I really don't like the idea of an extension to class Foo. The point of the polymorphism is that you have a bunch of operations which can be performed on any Foo, but are implemented differently in subclasses.
And the idea of the extension is that you can add such an operation. Of course, I am not suggesting doing that for a single class, but for a whole sub-hierarchy.
Another way to view it is as follows: the (Class,Method) is a sparse 2D array. C++ forces you to organize it class by class (at least for declarations). LX allows you to select different organizations, for instance having a place which defines method "PrintItForDebugging' for all classes in your hierarchy.
I didn't mean to imply that you hadn't addressed these issues
No, but you gave me the opportunity to give more information on important questions. Thanks.
1) I'm uncomfortable with end-of-line as a statement separator, and with indentation as structure control. It seems we're mixing lexical/expressive/publication issues with language syntax.
I am actually trying to make the two of them consistent all the time. Also note that end-of-line is not the only possible separator:
if a=3 then b:=5; c:=2; else d:=8; e:=f
There is even an 'end' keyword, so you could write a whole LX program on one line if you wanted:-)
At least, please be sure that long expressions can be spread over multiple lines with interleaved comments, and that short blocks can be expressed on a single line without resorting to '(a ? b : c)' or the like.
You can:
A:= A +
B +
C
I agree with your other comments, including in many ways you're tilting at windmills...
The page you read is not a spec. The (incomplete) spec can be found there. Naturally, LX has enums. It also has distinct scalar types:
type Color is enum(Red, Green, Blue)
type speed is other real
type distance is other real
type time is other real
function Speed(distance D; time T) return speed written D/T
This depends on what you are doing. I do a lot of physics related coding. One way to create clear and readable programs is to stay as close to the mathematical notation as possible. And in physics (and mathemathics) the case is essential:
V = Volume
v = speed
Phi = flow
phi = angle
etc.
Being caseinsensitive will ban this practice.
Uh oh. Good point. I did not thing about that issue. Overall, case and style insensitivity did not receive much positive appreciation here... I may scrap them.
For example C++ always defined short to be 2, long to be 4. So anything that needed to be a certain size could depend on them.
That's wrong. The requirement is simply that sizeof(char)=sizeof(short)=sizeof(int)=sizeof(long ). On some compilers (some Cray compilers I believe), sizeof(char)=sizeof(long)=1, and all are 64-bit...
First off most language design has always been open source.
I disagree. The design of Fortran, C, C++, Pascal, Eiffel and LISP were done behind closed doors.
I don't see any attempt at a formal definition of the language.
You are right. The good news is: the formal definition exists; it is about 90 pages long. The bad news is: it's boring, it's incomplete, and it's based on a pre indentation-sensitive version. You can find it there. And yes, I know it is not finished...
Before designing a programming language you should know about operational semantics, denotational semantics and all that good stuff.
[localhost:~/Development/mozart] ddd% wc `find . -name '*.[Chc]' -o -name '*.cpp' `
163 576 5133./lx/lx.cpp
[... a few other files...]
34125 132276 1324591 total
Remember, that's a part-time job, one person, and all this code is less than 1 year old. Plus I have kids, you know:-) Version 0.01 is there to make it clear that you can't use it if you don't develop it (which actually is probably false of Mozart now...)
LX allows multiple output parameters to a function or procedure. If you can propose a syntax that is acceptable to turn that into multiple return parameters, I am likely to buy it.
Unfortunately, something like "A, B, C:= f(D, E, F)" is syntactically ambiguous (consider placing it in an argument list...)
C is still the high-level language that produces the fastest code
As any compiler expert would point out, this is extremely false. By the way, I happen to have worked on commercial Ada, C and C++ compilers for a living;-)
Style insensitivity: I tried to address that elsewhere. See other answers (I'm tired, it's 1:00 A:-)
About Koenig lookup: Look at the name of author of the paper you referenced. Look at the name of the other author of Xroma:-)
Threading: Considered, but outside the scope of the library I want to design currently. The one thing that exists is a possibility to specify that two pieces of code can execute in parallel (from the compiler point of view.) How you then thread them is your problem.
Platform-independent numeric types are there.
Code based documentation: Should be addressed by reflection. See the Mozart examples.
Comments: Only one type of comments, beginning with '--'. I hesitated with '//'. But '--' is better for lines, precisely...
PL/1 disease: The complete LX spec I have currently is about 90 pages (without the lib). That's 1/10 the size of the C++ standard. Open Source design doesn't mean design by committee. Try to insert something in the Linux kernel that Linus doesn't like:-)
Extensibility: I believe LX, with reflection, offers more than most (except LISP-family languages)
Encapsulation: It's there. Look for 'properties.'
Metadata: What do you believe reflection is for:-)
Incremental compilation: See Mozart.
Compile-time tools: See the examples on active libraries and optimizations.
OS Issues: I gave some thought:-) See the {align}, {access_size}, {address} and other pragmas.
Tabbing as program structure- Its going to cause problems [...] due to forgetting a tab (and vice versa).
As I wrote elsewhere, tabs are not accepted. I give an example showing that your problems actually happens today in C/C++, precisely because of a separating character.
Underscore ignoring- Too confusing
At some point, I will have to listen (you're not the first one to say that.) But so far, I stick to it. I'm tired of stylistic wars between my_foo, myFoo and MyFoo... And I'm sure that if I impose 'integer32', there will be people to complain that it is not 'integer_32' or INTEGER_32.
Too many keywords. Plus too much typing.
LX has about 40 keywords (+ 4 short forms like 'var' for 'variant'). C++ has over 75. No further comment:-) Most real LX examples I wrote tend to be significantly shorter than C++ equivalents, in particular with templates.
Preconditions- If one compiler uses it for optimization and another throws an error at a broken one, your code will do two VERY different things on the compilers
Throwing an error here means aborting the application. And all compilers have to implement both options (tyically, one with -g, one with -O). Not any different than the 'assert' macro in C++.
Named/out of order arguments- will cause confusion and bugs
Why do you think so? The experience with Ada seemed to indicate otherwise...
Lack of types- will cause inefficencies of too much/little space being allocated. Also having compiler defined types like integer wioll make programs too compiler dependent.
I am not sure I understand this very well (the "lack of types" part.) "int" size is unspecified in C or C++ as it is in LX (although most compilers today implement 32-bit, it used to be 16-bits). Also, LX defines types like integer_32.
Customizable for/cases/etc- It will cause confusion when programmers start taking standard language ideas and twist them.
The risk exists. Someone will write 'for ever'. So what? But the alternative is no switch on strings, which I don't like either.
You need something that is yours and yours alone if you want this to suceed.
Active libraries. Look on the Mozart web page for details.
Mea culpa. It used to be called "Xroma", and I preferred that name. Then, the person who had coined the name left the company I work for, and wanted to keep the Xroma name. I had to recode the whole stuff (full of puns like Xromasomes, Xarbon, Xode, Xid, etc) in a hurry. I realized the mistake with Mozart/Oz after having coded 15000 lines that used the Mozart terminology. I am really sorry about that, but I'm tired of recoding...
Point well taken. What I meant to say is: I have this language, it is frozen in my mind, but now it would be good if people could identify big issues before I'm done with the compiler. So let's say it's an RFC for a language, how's that?
See if this still sounds like a good idea after you track a bug down to an editor expanding tabs into spaces or spaces into tabs
There will be no bug because of that. The compiler will just not accept tabs as input. If you have tabs? meta-x untabify and you are done.
The current situation is worse. Code becomes misindented, people make mistakes and have trouble reading it. But they are still too lazy to fix it since the compiler generally gets it right...
LX offers half a dozen features that reinforce interfaces. The most significant one is probably the fact that the interface of a type behaves like the interface of a function, whereas in C++, you need the body of a type to really use it (allocate it, pass it as an argument, etc)
The concrete question is: how could I get 20% more performance AND 20% more stability out of that same hardware? How do I avoid waiting 20 hours for the compiler to crush my 10Mloc of multiply included template code? How can I write code that someone in 2010 will be able to read? How do I teach new programmers good habits (when the first thing they need to learn today is: it is interpreted, or you need to pass "large things" using pointers...)
What about: LX and Mozart are a better solution than any other option out there for any application? OK, I was being biased. What about: any large-scale application where performance and stability matter?
When C started, a big application was 8K of code, and the problem was writing compact code. Today, a small one is 8MB, and the problem is "how do I stay up for days in a row", or "if I get a TLB miss here, performance degrades by 200%"... That's what I am trying to solve.
LISP is cool, no doubt. And yes, it is reflective, user-built, user-extensible. On the other hand, it was never a language for the rest of us. One of the reasons is: Lots of Insipid and Stupid Parentheses. LISP is a bit like the Reverse Polish Notation in HP calculators. If you know how to use it, it's really great. But most people can't get used to it.
And yes, I sometime uses LISP or other functional languages. Heck - early versions of LX even had support for Prolog-style backtracking! But no, Common Lisp does not have 33 out of the 38 features, and no, 38 - 33 is not 4:-)
Expression reduction. This seems like it would be hard to implement and very confusing.[...] I think it creates too much confusion unless you can demonstrate that this would be a huge speed boost.
I did actually implement it:-) Checkout the compiler from CVS... The precise rules are written in a separate document (which I need to put on the web someday), but basically amount to "the largest that matches." People who have worked for instance on large matrices or vectors that thrash your TLB know that there is a significant speedup in combining. Well, even multimedia encoding/decoding would benefit: this is the right way to define at a high level the equivalent of low-level instructions like MMX, AltiVec, etc. But the most important readability gain in my opinion is for types (think "array [A..B] of C" being a type expression.)
The first example you showed of these was basically using them as a replacement for unions. I hate unions.
The fact that you hate them doesn't make them useless. Consider a device control register where flipping a bit in one register changes the meaning of another register. The alternative is ugly pointers.
Basically, you created much simpler syntax for dynamic memory management.
No, I tried to create a way to represent data types that you can't represent easily in C. Simple application example: Run Length Encoding (RLE) for your good old BMP files.
I can't help but see so many different types of pointers as needlessly complicated and confusing. What will you really be needing pointers for?
Two answers there. First, the existence of multiple pointer types is a consequence of having them defined "in the library" rather than "in the compiler." Any program can define a "pointer type." And all the pointer types I describe are in the library.
Second, I essentially try to fix a problem in C, C++, etc, where a pointer to allocated memory automatically can 'alias' an object on the stack. That's very bad for optimizations. This doesn't happen in LX because these would be pointers of different types.
Last, to answer your suggestion of "leaving the others out", since the language allows you to create them, if there is no library-defined pointer, alternatives will pop up (just like the many string classes at the beginning of C++)
I think you are misinterpreting where the (fragile base class) problem lies
The fragile base class problem is that you cannot extend the class. I am suggesting that the set of polymorphic operations on a type is not closed by a single definition (for C++, the class definition.) Hence, any derived class can first add the functionality to its base class if needed. A bit as if in C++ you could say:
class Foo extension {
virtual void MyNewMember();
};
class Bar : Foo {
// Can now use MyNewMember.
};
void Foo::myNewMember() {
// extends class Foo only for class Bar.
}
LX is not intended as a scripting language. Not that I don't like Perl, but it's a different problem space...
Could you illustrate why you would need RE support in the language (as opposed to in the library, where RE support already exists in many languages, including C)?
To be slightly less snide for a moment, what I'm trying to point out is that, while this is a good idea, it is slightly silly and slightly unnecessary. There are certain bases that are used... there are others that, in general, are not.
This is a computer scientist's point of view. Computer users generally use bases which are powers of 2. Some mathematical problems, however, are best expressed in other bases. Hence the capability to use arbitrary bases in LX... including for floating-point.
Don't support every base through a clumsy yet silly syntax. I'd rather be able to do the following, and only the following: 10, 10d, 12o, 0Ah, 1010b
I agree with the "I'd rather be able to", and I will consider adding support for a notation like this. On the other hand, I disagree with the "only" part.
Slashdot Mirror
Programmer's don't like syntactic sugar - it gets in the way of programming
If you like C, that's probably true. I am a programmer, always have been, and I like syntactic sugar more than C-style syntactic Tabasco with chunky glass chips. That, I believe, gets in the way of my programming.
based numbers, it's typical in other programming languages and mathematics to put the base at the end
C, C++, Ada, most variants of Pascal with a notation for hexa, MC68000 assembly, to name a few, put the base at the beginning. What (compiled) languages are you referring to? x86 assembly :-) ?
How do you plan to set precedence for your named operators?
None. They currently all share the same lowest-level priority.
C doesn't mandate anything with regard to parameter passing mechanics; a compiler is free to stuff e.g. 8 byte parameters into a single 64-bit register if it thinks it will help (e.g. in the case of a struct); I believe compilers do that already.
You misunderstood the problem. On old platforms, your struct would be copied in memory (expensive), so people just passed a pointer (faster). Then, the compiler no longer has the choice to copy the object.
C also mandates the use of pointers for output parameters. In that case also, the compiler has no choice. Similarly, once a programmer has decided that copying the object on platform A was too expensive and that he would therefore pass by reference (pointer), the compiler has no choice but pass by reference even if on platform B passing by value would have been less expensive.
Similarly, C++ semantics says that the copy constructor is called if you pass an object by value, so if your object has a constructor, the compiler needs to generate a 'this' pointer, and thus has to pass by reference, even if the object is small and you asked to pass by value.
The result parameter... also from Pascal.... which is not necessarily a bad thing, but it's too much of a "magic" variable for me, but then maybe I'm just too used to the C/C++ return keyword.
LX has a return keyword as well. And C++ has a 'this' pointer, another magic variable...
I see. But that's a policy. For some applications (such as real-time, OS or driver development), you need this kind of insecure access. If the language claims to be universal, it has to support them.
Now, what does LX give you? Two things: the first one is that you can still use "unions" and put conditional access clauses. This means that you can ensure that type safety, for one, is not broken. This does not prevent malicious access, which is apparently your concern. For this second thing, you have Mozart. Look the part on "policy control." You can have a Mozart plug-in as part of your build system that checks that unions (or variant records) are not used in the code. This will be compile-time security.
Java has the same concept but not the fragile base class problem, simply because of its implementation.
Then, we don't talk about the same thing. To me, Java has the fragile base class problem. Consider a class framework you don't own with a root class 'Car' defining a 'Speed'. The framework hypothesis is that all cars have four wheels. You'd like to add support for 6-wheel cars in a SixWheeler class. Obviously, the place where you'd like to add a 'NumberOfWheels' member would be the base Car class, but you can't, because you don't own the framework. Even if you could, you would still have an issue if another part of the class hierarchy (say, deriving from 'Bus') already had a 'NumberOfWheels' member with slightly different semantics.
I really don't like the idea of an extension to class Foo. The point of the polymorphism is that you have a bunch of operations which can be performed on any Foo, but are implemented differently in subclasses.
And the idea of the extension is that you can add such an operation. Of course, I am not suggesting doing that for a single class, but for a whole sub-hierarchy.
Another way to view it is as follows: the (Class,Method) is a sparse 2D array. C++ forces you to organize it class by class (at least for declarations). LX allows you to select different organizations, for instance having a place which defines method "PrintItForDebugging' for all classes in your hierarchy.
No, but you gave me the opportunity to give more information on important questions. Thanks.
1) I'm uncomfortable with end-of-line as a statement separator, and with indentation as structure control. It seems we're mixing lexical/expressive/publication issues with language syntax.
I am actually trying to make the two of them consistent all the time. Also note that end-of-line is not the only possible separator:
if a=3 then b:=5; c:=2; else d:=8; e:=f
There is even an 'end' keyword, so you could write a whole LX program on one line if you wanted :-)
At least, please be sure that long expressions can be spread over multiple lines with interleaved comments, and that short blocks can be expressed on a single line without resorting to '(a ? b : c)' or the like.
You can: := A +
A
B +
C
I agree with your other comments, including in many ways you're tilting at windmills...
Yes, but 10 years ago, sizeof(int)=2, today, sizeof(int)=4. And yes, I wrote "less than", but I suspect the HTML filter removed it.
type Color is enum(Red, Green, Blue)
type speed is other real
type distance is other real
type time is other real
function Speed(distance D; time T) return speed written D/T
Uh oh. Good point. I did not thing about that issue. Overall, case and style insensitivity did not receive much positive appreciation here... I may scrap them.
That's wrong. The requirement is simply that sizeof(char)=sizeof(short)=sizeof(int)=sizeof(long ). On some compilers (some Cray compilers I believe), sizeof(char)=sizeof(long)=1, and all are 64-bit...
I disagree. The design of Fortran, C, C++, Pascal, Eiffel and LISP were done behind closed doors.
I don't see any attempt at a formal definition of the language.
You are right. The good news is: the formal definition exists; it is about 90 pages long. The bad news is: it's boring, it's incomplete, and it's based on a pre indentation-sensitive version. You can find it there. And yes, I know it is not finished...
Before designing a programming language you should know about operational semantics, denotational semantics and all that good stuff.
Thanks for the recommendation :-)
[localhost:~/Development/mozart] ddd% wc `find . -name '*.[Chc]' -o -name '*.cpp' ` ./lx/lx.cpp
...]
163 576 5133
[... a few other files
34125 132276 1324591 total
Remember, that's a part-time job, one person, and all this code is less than 1 year old. Plus I have kids, you know :-) Version 0.01 is there to make it clear that you can't use it if you don't develop it (which actually is probably false of Mozart now...)
LX allows multiple output parameters to a function or procedure. If you can propose a syntax that is acceptable to turn that into multiple return parameters, I am likely to buy it.
:= f(D, E, F)" is syntactically ambiguous (consider placing it in an argument list...)
Unfortunately, something like "A, B, C
As any compiler expert would point out, this is extremely false. By the way, I happen to have worked on commercial Ada, C and C++ compilers for a living ;-)
To have fun.
Style insensitivity: I tried to address that elsewhere. See other answers (I'm tired, it's 1:00 A :-)
About Koenig lookup: Look at the name of author of the paper you referenced. Look at the name of the other author of Xroma :-)
Threading: Considered, but outside the scope of the library I want to design currently. The one thing that exists is a possibility to specify that two pieces of code can execute in parallel (from the compiler point of view.) How you then thread them is your problem.
Platform-independent numeric types are there.
Code based documentation: Should be addressed by reflection. See the Mozart examples.
Resumable exceptions are there.
Thank you for your comments.
PL/1 disease: The complete LX spec I have currently is about 90 pages (without the lib). That's 1/10 the size of the C++ standard. Open Source design doesn't mean design by committee. Try to insert something in the Linux kernel that Linus doesn't like :-)
Extensibility: I believe LX, with reflection, offers more than most (except LISP-family languages)
Encapsulation: It's there. Look for 'properties.'
Metadata: What do you believe reflection is for :-)
Incremental compilation: See Mozart.
Compile-time tools: See the examples on active libraries and optimizations.
OS Issues: I gave some thought :-) See the {align}, {access_size}, {address} and other pragmas.
Thank you for the very useful comments.
As I wrote elsewhere, tabs are not accepted. I give an example showing that your problems actually happens today in C/C++, precisely because of a separating character.
Underscore ignoring- Too confusing
At some point, I will have to listen (you're not the first one to say that.) But so far, I stick to it. I'm tired of stylistic wars between my_foo, myFoo and MyFoo... And I'm sure that if I impose 'integer32', there will be people to complain that it is not 'integer_32' or INTEGER_32.
Too many keywords. Plus too much typing.
LX has about 40 keywords (+ 4 short forms like 'var' for 'variant'). C++ has over 75. No further comment :-) Most real LX examples I wrote tend to be significantly shorter than C++ equivalents, in particular with templates.
Preconditions- If one compiler uses it for optimization and another throws an error at a broken one, your code will do two VERY different things on the compilers
Throwing an error here means aborting the application. And all compilers have to implement both options (tyically, one with -g, one with -O). Not any different than the 'assert' macro in C++.
Named/out of order arguments- will cause confusion and bugs
Why do you think so? The experience with Ada seemed to indicate otherwise...
Lack of types- will cause inefficencies of too much/little space being allocated. Also having compiler defined types like integer wioll make programs too compiler dependent.
I am not sure I understand this very well (the "lack of types" part.) "int" size is unspecified in C or C++ as it is in LX (although most compilers today implement 32-bit, it used to be 16-bits). Also, LX defines types like integer_32.
Customizable for/cases/etc- It will cause confusion when programmers start taking standard language ideas and twist them.
The risk exists. Someone will write 'for ever'. So what? But the alternative is no switch on strings, which I don't like either.
You need something that is yours and yours alone if you want this to suceed.
Active libraries. Look on the Mozart web page for details.
Mea culpa. It used to be called "Xroma", and I preferred that name. Then, the person who had coined the name left the company I work for, and wanted to keep the Xroma name. I had to recode the whole stuff (full of puns like Xromasomes, Xarbon, Xode, Xid, etc) in a hurry. I realized the mistake with Mozart/Oz after having coded 15000 lines that used the Mozart terminology. I am really sorry about that, but I'm tired of recoding...
Point well taken. What I meant to say is: I have this language, it is frozen in my mind, but now it would be good if people could identify big issues before I'm done with the compiler. So let's say it's an RFC for a language, how's that?
See if this still sounds like a good idea after you track a bug down to an editor expanding tabs into spaces or spaces into tabs
There will be no bug because of that. The compiler will just not accept tabs as input. If you have tabs? meta-x untabify and you are done.
The current situation is worse. Code becomes misindented, people make mistakes and have trouble reading it. But they are still too lazy to fix it since the compiler generally gets it right...
LX offers half a dozen features that reinforce interfaces. The most significant one is probably the fact that the interface of a type behaves like the interface of a function, whereas in C++, you need the body of a type to really use it (allocate it, pass it as an argument, etc)
The concrete question is: how could I get 20% more performance AND 20% more stability out of that same hardware? How do I avoid waiting 20 hours for the compiler to crush my 10Mloc of multiply included template code? How can I write code that someone in 2010 will be able to read? How do I teach new programmers good habits (when the first thing they need to learn today is: it is interpreted, or you need to pass "large things" using pointers...)
What about: LX and Mozart are a better solution than any other option out there for any application? OK, I was being biased. What about: any large-scale application where performance and stability matter?
:-)
When C started, a big application was 8K of code, and the problem was writing compact code. Today, a small one is 8MB, and the problem is "how do I stay up for days in a row", or "if I get a TLB miss here, performance degrades by 200%"... That's what I am trying to solve.
Without the faith, I would not do this
LISP is cool, no doubt. And yes, it is reflective, user-built, user-extensible. On the other hand, it was never a language for the rest of us. One of the reasons is: Lots of Insipid and Stupid Parentheses. LISP is a bit like the Reverse Polish Notation in HP calculators. If you know how to use it, it's really great. But most people can't get used to it.
:-)
And yes, I sometime uses LISP or other functional languages. Heck - early versions of LX even had support for Prolog-style backtracking! But no, Common Lisp does not have 33 out of the 38 features, and no, 38 - 33 is not 4
I did actually implement it :-) Checkout the compiler from CVS... The precise rules are written in a separate document (which I need to put on the web someday), but basically amount to "the largest that matches." People who have worked for instance on large matrices or vectors that thrash your TLB know that there is a significant speedup in combining. Well, even multimedia encoding/decoding would benefit: this is the right way to define at a high level the equivalent of low-level instructions like MMX, AltiVec, etc. But the most important readability gain in my opinion is for types (think "array [A..B] of C" being a type expression.)
The first example you showed of these was basically using them as a replacement for unions. I hate unions.
The fact that you hate them doesn't make them useless. Consider a device control register where flipping a bit in one register changes the meaning of another register. The alternative is ugly pointers.
Basically, you created much simpler syntax for dynamic memory management.
No, I tried to create a way to represent data types that you can't represent easily in C. Simple application example: Run Length Encoding (RLE) for your good old BMP files.
I can't help but see so many different types of pointers as needlessly complicated and confusing. What will you really be needing pointers for?
Two answers there. First, the existence of multiple pointer types is a consequence of having them defined "in the library" rather than "in the compiler." Any program can define a "pointer type." And all the pointer types I describe are in the library.
Second, I essentially try to fix a problem in C, C++, etc, where a pointer to allocated memory automatically can 'alias' an object on the stack. That's very bad for optimizations. This doesn't happen in LX because these would be pointers of different types.
Last, to answer your suggestion of "leaving the others out", since the language allows you to create them, if there is no library-defined pointer, alternatives will pop up (just like the many string classes at the beginning of C++)
I think you are misinterpreting where the (fragile base class) problem lies
The fragile base class problem is that you cannot extend the class. I am suggesting that the set of polymorphic operations on a type is not closed by a single definition (for C++, the class definition.) Hence, any derived class can first add the functionality to its base class if needed. A bit as if in C++ you could say:
class Foo extension {
// Can now use MyNewMember.
// extends class Foo only for class Bar.
virtual void MyNewMember();
};
class Bar : Foo {
};
void Foo::myNewMember() {
}
Thanks for the comments. They help.
Could you illustrate why you would need RE support in the language (as opposed to in the library, where RE support already exists in many languages, including C)?
This is a computer scientist's point of view. Computer users generally use bases which are powers of 2. Some mathematical problems, however, are best expressed in other bases. Hence the capability to use arbitrary bases in LX... including for floating-point.
Don't support every base through a clumsy yet silly syntax. I'd rather be able to do the following, and only the following: 10, 10d, 12o, 0Ah, 1010b
I agree with the "I'd rather be able to", and I will consider adding support for a notation like this. On the other hand, I disagree with the "only" part.