Ideal Language, part 2

What does your ideal programming language look like? Which language(s) is it based on? Which paradigm(s) does it use? Give examples of what the code looks like (FizzBuzz, Fibonacci, function/class definition).

s/*/\a

My ideal programming language already exists. And it's name is Scala.

Static typing, type inference, OPP + FP.

My ideal language is Scheme with a common module importing interface. At the moment, I can deal with the current situation but it makes things a bit more of a hassle than it really ought to be.

My ideal language would be Python, only with better standard libraries and no dependency hell when deploying programs.

I like this: Scala/Haskell/Ruby/Scheme

Qi.

It's assembly, but with a compile-time grammar engine on top of it.  So the actual code that I write might look like C, or it might look like C++, or it might look like Scheme.  Depending on my mood, I just choose which grammar layer I want to use that day, or maybe I define a completely new one for some special purpose.

Yeah, I could already do this with lex/yacc, I guess.  But I want it in the form of an IDE with a debugger that is aware of the grammar layer and can debug it.

>>8
HLA?

>>8

I wanted to do this with a scheme or a lisp a while ago. I'll get back to it...

C with several major changes;
1.asm could be embedded as commands OR as blocks,
functions can contain only ASM or mix of ASM and C.
2.all pointers = void* , and there is no "casting" whatsoever(what you request, you get, e.g. request char from int without any unions)
3.native ,optimized bitvectors with arbitrary length, not this bitfield mess.
4.Native arbitrary precision numbers(ints,float,complex) as optional, (not-default type!).
5.Standard library + all headers always included, but only parts of the program referencing them get compiled.
6.Native OpenGL,SSE and CUDA/GPGPU in the language. Yes, this isn't 1980.
7.Prototype object model from JavaScript. It is used as OPTIONAL element not forced down our throats.
8. No GC, malloc reworked to be more efficient:
8.1. command to return length of allocated space for pointer
8.2. all allocations which can made static, but required malloc in the past can be static.
9. Optional support for C++-like shared_pointer/unique_ptr features.
10. native sizeof,typeof,offsetof,and other disambiguation funcs,
but without any overhead for stored data.
11. casting eliminated from the language.
12. Operators and functions can be overloaded, but native ops and functions are compiled to same efficient code. The overloaded functions and operators define their own, hidden functions with the interface of old ops and funcs. New operators can be defined as easily as funcs.
13. Native support for varargs for functions(called as function(...)
with implicit function_argc parameter accessible for ONLY and ONLY such functions, no overhead for every function)
 and macros have same options as every function.
14. majors updates for preprocessor: macros can define elements of preprocessor, execute code, and use many LISP-like features without compiling the code. Macros are multiline by default and can be broken by #endmacro
Any expensive feature which is not used in compiled code is allowed. Preprocessor will have much more then a dozen commands.
15. Native mixins and computed gotos, function vector tables as type of (optional) object to call functions from.
15. functions which take no arguments and do not return can be created as subroutines in form of:  GOTO func_name_1,, code goto Return_add, with optional specified inlining.
16. Native support for numerous compiler extensions, without any regards to the spec(which will be used for guidance ONLY). Whichever the best/fastest compiler wins.
17. compiler should have a powerful analysis engine to activate when it cannot compile the code, and show EXACTLY why the code is wrong, giving a link to relevant funcs/concepts/specs and optional replacement for invalid code part in question.
18.CPU registers can be accesed in abstract form as R0 to R256
with register which are higher but not available can be compiled as normal code.
19. precedence of operators and many low-level compilation details can be decided at compiled by the current code(e.g. function attributes), not the compiler. After it is compiled it works without any changes to regular compiler.
20. Native library interface,e.g. import 'kernel32'
21. Many features which are provided now as standard library will be converted into language parts. Parts which are not used are simply not compiled.
22. Native support for binary file inclusion e.g. x=import("C:\data\logo.JPG")
23. fast NFA regexps are an additional type to be used by string routines and preprocessor.
24. All types, not just malloced, will return .length for their size.
25.Compiler extensions can be easily added inside the code at compile time. Syntax is not static if the coder desired it.

The principle is no performance loss for ease of use.

>>11

no lexically scoped closures with automatic memory management = shit

The principle is no performance loss for ease of use.

This is a contradiction. Hardware is not designed in any way to be convenient and trying to mold it into something convenient necessitates losing performance.

am i banned from posting on prog too?

>>11
kill yourself faggot