[OT] What should be in a programming language?

[Yigal Chripun]

On 23/10/2009 19:50, Jason House wrote:
> Yigal Chripun Wrote:
<snip>
>> 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 know about this specific feature of Scala. in D you can pass a 
(type) tuple to a function and it is auto flattened to the arg list.
i.e.
void foo(int, int);
Tuple!(int, int) a = ...;
foo(a);
in ML, the arg list *is* a tuple so there's no need for an auto-flatten. 
you can always nest tuples so it's trivial to have multiple tuples as 
arguments.

example (not tested):

fun foo (a, (b, c)) = a*b + a*c
let bar = foo(3, (4, 5))

foo's signature would be: ('a, ('a, 'a)) -> ('a)

>
>
>>
>> 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...
>
http://en.wikipedia.org/wiki/Nemerle
http://en.wikipedia.org/wiki/Hygienic_macro

here's a quick summary of how it should work/look like:
macros are written in the same language, no #if, no static if.
you write regular looking functions in plain code. those macros are 
compiled separately into loadable libs that you can specify for the 
compiler to load. the language has syntax to [de]compose AST.

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

there are different models for this and this also relates to the macro 
system above. here's one model (used in smalltalk)
class Foo {
int a;
void foo();
}
the compiler will generate for Foo a singleton of the type 'Foo which 
contains all the information about Foo. for example, it'll contain the 
list of functions for Foo instances. this is the same as in D - in D we 
have Typeinfo structs that contain vtables.

class Bar {
int a;
static void foo();
}
in compiled languages (c++/d) this is done statically (foo is a global 
function in the assembly)

in smalltalk the previous mechanism is [re]used:
we have class Bar which defines it's instances
we have class 'Bar that defines Bar
we have class ''Bar that defines 'Bar
we have class Class that defines ''Bar
total of 5 levels which are required to have class shared functions/state

>
>> 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.
I was trying to convey semantics here rather than syntax. deriving a 
class from a base class is a poor way to design code and I want to 
separate two orthogonal issues -
a. subtyping and polymorphism
b. reuse of code/ implementation
>
>> 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)

c style built in types expose an implementation detail that should be 
encapsulated and hidden under the hood as you say.
there should be no syntactic difference between an int and a user 
defined type.
for example I should be able to do:
struct foo : int {}