[OT] What should be in a programming language?

[Jason House]

Yigal Chripun Wrote:

> 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),


That's an important one that I forgot to list: an ownership scheme similar to Bartosz's (I'd favor a slight reduction in annotation, but the same basic thing)


> 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 like scala's concept of multiple input tuples, and the freedom to use () or {} when specifying a tuple. I might be slightly stricter with how each tuple is used such that the library writer says which form is allowed. This has the awesome side effects of making libraries look like part of the language.


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


The AST macro stuff predates my participation on this list. Have any good links explaining how it works? I've been thinking of allowing expressions, statements (and friends) as object types and then allowing mixing in of those objects...

#var declareX = Statement ("int x=3");
#mixin declareX;

... or something along those lines...


> 
> I'd remove static from the language completely and instead would have 
> metaclasses.

I agree with no statics. What are metaclasses? I like how scala defines singletons for statics (object in scala type declaration)

> 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 {}

There seems to be redundency here. Why would you/others want that? Super verbose code makes it tough to attract users.
 
> everything is an object and no special treatment for specific types

I don't think "everything is an object" works under the hood, but I do like making that transparent. A lot of the items allow transparent use of reference and value types (scope by default unless explicitly marked/allocated, and transitive const by default unless passed by ref)