Bored

I'm incredibly bored, so I thought I'd write 2 probably incredibly bad ideas.

1. Indentation instead of braces
2. For memory management, we use either a manual memory management, or a garbage collector. But what if instead, we used both? Having the compiler determine if some data should be allocated using alloca, malloc, an object cache, arena allocator, etc, and if it should be freed using deference, deletion, refcounter, or garbage collection, and if garbage collection, to create mutexes for "entry points" for which to search from. Then have GCs run in their own threads while the other stuff in running.

I can think of more bad ideas too.

3. To have the compiler detect bufferoverflows by assigning at each point in the program, a "max" value to each int etc, and a "min" value, then warn if "max" for the int at various position, is over the buffer's min size etc.

>>1-2
1. Both are necessary.  Imposing either leads to unusable syntactic diarrhoea (just look at Python and Lisp).
2. Compilers (especially JIT compilers) will generate manual allocations and frees if possible.
3. Buffer overflows are a language flaw for anything other than assembly.

4. Everything which isn't I/O should be precalculated by the compiler.

>>3
3. But, although many languages stop bufferoverflows, they usually use runtime checking, not compile time. Actually, I'm not aware of any languages with compile time buffer checking. Are there any?

Call it Python

>>3
will generate manual allocations and frees if possible.
That's wrong, probably they will use the stack, but malloc and free are slower than a good garbage collector.

>>6
That's wrong, probably they will use the stack
Right, sorry, that's what I meant.

malloc and free are slower than a good garbage collector.
Maybe less space efficient due to fragmentation, but slower?  Come on.

malloc and free are slower than a good garbage collector.
How do you expect to implement a garbage collector without malloc and free?

>>7
It's probably more space efficient, actually, but it is slower.
I'm assuming a generational copying GC. Allocation is as free as stack allocation (bump a pointer) and deallocation is O(alive), but you need 2 times or so the size of your heaps of space.
Allocation with malloc is expensive, deallocation is O(dead), but the space needed is just the size of the heap.

>>8
Really, really carefully.

>>8
subleq

qUICK asm question!! can i use the rep prefix before a funtcion to call it repeatedly?

x86 architecture is crap.

ALL HAIL THE LISP MACHINE

>>12
hOW about you tyr!!

>>12
No.

>>12
No, because x86 is ``non-orthogonal''.