[OT] What should be in a programming language?

[Denis Koroskin]

On Fri, 23 Oct 2009 16:42:31 +0400, Jason House  
<jason.james.house at gmail.com> 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?
>

Agreed.

> 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.
>

A good idea probably.

> 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.
>

Yes, it's reasonable.

> 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.
>

Yup!

> 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.
>

Nice idea that solves some of the D issues quite gracefully.

> I would have a type type, usable for both compile time and run time  
> reflection.
>

I'd separate that into built-in "type" and library "Type" types.

> I've probably forgotten a number of basic things, but that should be  
> enough for now.

I believe templates are better be written in imperative style. That's why  
a built-in "type" type is needed.

Great list. I believe with upcoming finalization of D2 some of us are  
already looking into future and D3 so keep thinking. While you get your  
inspiration from D, D could also adopt some of your suggestions.