Python! No, seriously now, what do you think would comprise the ultimate programming language? I think:

- optional garbage collection which is on by default
- as native as C (none of this VM shit)
- modern language features like packages
- operator overloading with a slew of new operators (like slicing)
- continuations and other LISPy things
- concise, less-typing syntax
- macros
- __maybe__ an intermediate code which can be compiled to native code on various OS's once to generate executabels

I'm asking this because I'm going to write another compiler this semester.

Disassemblers are more fun to write, let alone a heck of a lot easier, I think.

If you're just writing a compiler, could you not use a language that already exists? Like, write another C compiler?

[quote author=Banana fanna fo fanna link=topic=10292.msg96395#msg96395 date=1106537562]
- concise, less-typing syntax
- macros
[/quote]

Those tend to lead to horrible lazy code.  Macros are the root of many evils, and many hard-to-find problems.  As an example:

#define MAX(a,b) (a<b?b:a)

.......
int c = 4, d = 10;
c = MAX(c++, --d);

Because of the macro expansion, that will expand to:
c = (c++<--d?--d:c++)
Which will, of course, return 8 (because --d is run twice), which is a completely unexpected result.

Anyway, that's my argument against Macros.  Take it how you like :)

There's nothing wrong with a thoughtful, well-written macro. That macro is stupid. It ought to be a function.

People rail on about macros being bad, but I think that's crap. Macros are an incredibly useful tool. Like anything, they can cause problems when they're misused.

"garbage collection" and "native" don't go together...

Actually, you can make a native program which has a garbage collector.  It's just not necessarily going to run as fast as a GC-free language, since the compiler will need to convert all references to complex types into extra record-keeping code to ensure that the reference count is right so it can be garbage collected on schedule.

But as native as C? You're supposed to be able to cast between numbers and strings and pointers freely, with no type checking, and insert assembler code virtually arbitrarily.... ;)

[quote author=Arta[vL] link=topic=10292.msg96430#msg96430 date=1106581714]
There's nothing wrong with a thoughtful, well-written macro. That macro is stupid. It ought to be a function.

People rail on about macros being bad, but I think that's crap. Macros are an incredibly useful tool. Like anything, they can cause problems when they're misused.
[/quote]

So any macro that uses a variable more than once is "stupid"?  Any macro that uses a variable more than once will succumb to that problem, unless the programmers using the macro are aware that it's a macro and that it might have that effect.

[quote author=Adron link=topic=10292.msg96555#msg96555 date=1106638691]But as native as C? You're supposed to be able to cast between numbers and strings and pointers freely, with no type checking, and insert assembler code virtually arbitrarily.... ;)[/quote]

I see your point.  From his statement of "as native as C (none of this VM shit)", I took it merely to mean that he wanted processor-native code, as opposed to interpreted bytecode.  It would complexify the language a bit (and introduce extra work for programmers who wanted to do casting), but I still think he could make a machine-native garbage collector.  It'd merely require a convention such as "You must keep a visible reference to an object or it'll go away, even if your inlined assembly still knows about it" for garbage-collected objects.  He already specified that garbage collection would be optional, so arbitrarily crafted pointers would be declared as not-garbage-collected.

I was thinking something along the lines of:

[code]
class MyClass extends GarbageCollected {
  ...
}
[/code]

[quote author=Banana fanna fo fanna link=topic=10292.msg96615#msg96615 date=1106690348]
I was thinking something along the lines of:

[code]
class MyClass extends GarbageCollected {
  ...
}
[/code]
[/quote]

Then you need to implement multiple inheritance which is icky.

But if all you're doing is create a class to inherit from to get garbage collection, you might as well use C++ and write a garbage collector for it, or use one of the existing ones ;)

That wouldn't be a bad idea of garbage collection wasn't a bad idea in the first place.

Nothing like keeping track of your garbage yourself... :P

[quote author=tA-Kane link=topic=10292.msg96628#msg96628 date=1106693320]
That wouldn't be a bad idea of garbage collection wasn't a bad idea in the first place.

Nothing like keeping track of your garbage yourself... :P
[/quote]

Garbage collection is the best.

Btw, I think having all user variables *not* stored on the stack may be a good idea for a language... especially not arrays...

[quote author=dxoigmn link=topic=10292.msg96622#msg96622 date=1106691806]
[quote author=Banana fanna fo fanna link=topic=10292.msg96615#msg96615 date=1106690348]
I was thinking something along the lines of:

[code]
class MyClass extends GarbageCollected {
...
}
[/code]
[/quote]

Then you need to implement multiple inheritance which is icky.
[/quote]

Not if it's done right.

[quote author=tA-Kane link=topic=10292.msg96673#msg96673 date=1106704437]Btw, I think having all user variables *not* stored on the stack may be a good idea for a language... especially not arrays...[/quote]

Why?  Extremely short life arrays are much better on the stack, and if you're concerned about buffer overflows then:

1) You need a better programmer.
2) You could design the language to automatically check all load/stores to some/all arrays and abort on overflow.  This is a performance hit, and it's not backward compatible with some C wizardry, so it isn't done in C/C++.  Java does it, which is one reason it's such a nuisance to be clever with pointers.

[quote author=Banana fanna fo fanna link=topic=10292.msg96701#msg96701 date=1106711522]
[quote author=dxoigmn link=topic=10292.msg96622#msg96622 date=1106691806]
[quote author=Banana fanna fo fanna link=topic=10292.msg96615#msg96615 date=1106690348]
I was thinking something along the lines of:

[code]
class MyClass extends GarbageCollected {
...
}
[/code]
[/quote]

Then you need to implement multiple inheritance which is icky.
[/quote]

Not if it's done right.
[/quote]

For example, instead of "extends", try "implements".  Interfaces are a good thing.  ;)

Ah...how about automatic boundschecked arrays?

[quote author=Banana fanna fo fanna link=topic=10292.msg96845#msg96845 date=1106791659]Ah...how about automatic boundschecked arrays?[/quote]

Isn't that what I said? :)  Anyway, I'd suggest making that optional too (but maybe default to on).  I've occasionally found use for using "zero-length" arrays to alias other data types (especially variable length data that immediately follows a structure in memory), and bounds checking would ruin that.