[OT] What should be in a programming language?
Denis Koroskin
2korden at gmail.com
Fri Oct 23 05:58:55 PDT 2009
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.
More information about the Digitalmars-d
mailing list