[OT] What should be in a programming language?

Yigal Chripun yigal100 at gmail.com
Fri Oct 23 06:52:33 PDT 2009


On 23/10/2009 14:42, Jason House wrote:
> I've been thinking lately about what my ideal programming language
> would look like and what I might write if I tried to create one.
> Below is a short list of big things I'd do. What do you think of my
> ideas? What would you do?
>
> I'd look to D and Scala for inspiration, but want to allow better
> reasoning about code.
>
> I'd use D's transitive const and use transitive pure instead of
> transitive immutable.
>
> Functions can't effect glabal variables unless marked as such. I'll
> have to learn what a monad is so that some side effects can be
> hidden?
>
> By default, a function can not keep its variables past function
> scope. If a parameter or local variable is to remain for longer it
> must be marked as such in its type.
>
> Similarly, all function arguments will default to (transitive) const.
> Any mutable arguments must be marked as such. I'm unsure if ref
> arguments should come in a final and non-final form. One nice side
> effect of this is that value types vs. reference types don't require
> special consideration.
>
> I'd probably do away with out arguments in favor of return tuples.
>
> All types are not nullable by default. T and T? seem reasonable
> enough. I'd probably twist that a bit and use a beefed up variable
> declaration similar to scala. "pure? x: T = ..." would be a nullable
> immutable variable of type T.
>
> Compile time capabilities would exceed D's. I'm thinking of a simple
> marker to make anything compile time (i.e. #). #if would be like
> static if. #pure would be a manifest constant. An array with some
> compile time values would be easy [foo(7), #bar(8)]. This also means
> #switch and #foreach would exist (among other things). Generics with
> compile time arguments become templates.
>
> I would have a type type, usable for both compile time and run time
> reflection.
>
> I've probably forgotten a number of basic things, but that should be
> enough for now.

my list would be similar:
non-nullable references by default, concurrency semantics (I liked 
Bartosz' design), transitive const and everything is const by default, 
immutable as part of the concurrency ownership design,
functions would be defined as in ML: they take one tuple argument and 
return one tuple argument

i don't like the #if, etc idea and would prefer a proper AST macro 
system with proper hygiene

I'd remove static from the language completely and instead would have 
metaclasses.
other OOP changes - better separation between sub-typing and sub-classing:

type interfaceA extends interfaceB, interfaceC {}
implementation implA extends implB, implC implements interfaceA, 
interfaceD{}

auto obj = interfaceA.new(); // returns an implementation, e.g. implA

ionstead of the classic:
class A {}
class B: A {}

we'll have:
type A {}
type B extends A {}
implementation A implements A{}
implementation B extends implementation A implements B {}

everything is an object and no special treatment for specific types





More information about the Digitalmars-d mailing list