Slick-C Language Enhancements

[Dennis]

We are considering making several enhancements to the Slick-C language for a future release of SlickEdit.  The following paper gives an overview of the changes, with examples.  We are posting this specification here in order to get feedback on the languages changes from our users.

Note:  This discussion is to address changes to the Slick-C language.  Do not post any comments about about other languages (Java, C#, Python,Perl,Ruby, JavaScript, TCL, etc.) unless it is to point out a nice feature that could be added to Slick-C.  Please post about adding support for other macro languages on another thread.

A significant portion of SlickEdit is written in Slick-C, so the language is not going away anytime soon.  We are simply trying to make it more modern and powerful.

Table of Contents

• Principles
• := operator
• Enumerated types
• #import directive
• #pragma option(strictprotos)
• Namespaces
• Interfaces
• Classes
• Introspection
• New reserved words
• Features not addressed

Principles

• Continued backward compatibility with almost all existing Slick-C code
• Maintain close language design relationship with foundation languages C/C++, C#, Java, and Objective-C
• Use or extend existing mechanisms instead of re-inventing (For example, do not rewrite the interpreter).
• Practicality -- focus on important features that are reasonably easy to add in a short time frame, which leaves us more time to spend adding features to SlickEdit.
• Performance -- Do not introduce features that carry significant run-time costs.  Also focus on features that will improve performance compared to certain idioms being used in Slick-C now.

The := Operator

The := operator is used as follows:

Code: [Select]

    id := expr;

In this statement, "id" is declared as a local variable with the same type as "expr". 

Code: [Select]

    b := false;                   // boolean b = false;
    i  := 0;                      // int i = 0;
    j  := i;                      // int j = i;
    s := "test";                  // _str s = "test";
    p := &s;                      // _str *p = &s;
    c := _process_comment(line);  // COMMENT_TYPE c=_process_comment(line);
    p := &obj;                    // Object *p = &obj;
    fp := func;                   // int (*fp)() = func;
    x := y := 0;                  // int x=0; int y=0;
    for (a:=1; a<10; ++a);        // count to 10

Enumerated Types

Slick-C enumerated types are going to be very much like C enumerated types, with the possible exception of having relaxed type checking with respect to arithmetic and bit operations. 

Code: [Select]

    enum BasicOptions {
        OPTION1=1,
        OPTION2,
        OPTION3,
     };

In addition, Slick-C enumerated types are going to introduce enumerated type flags, a convenient way to create a set of bit flags. 

Code: [Select]

    enum_flags OptionFlags {
        FLAG1=0x4,
        FLAG2, // 0x8
        FLAG3, // 0x10
        FLAGS_ALL=FLAG1|FLAG2|FLAG3
    };

#import Directive

#import is a preprocessing directive but it is more than a #include, in that it does the following:

• Imports all public declarations from a Slick-C module.
• Uses an implicit header guard to prevent recursive or multiple importation of the same module.

When processing a #import, the following rules will be in effect.

• All function definitions are treated as prototypes.
• Global variable definitions are treated as declarations.
• Static globals are ignored.
• Forms, menus, event tables and event handlers are ignored.
• #includes continue to be treated as part of the #import.

Code: [Select]

    #import “stdcmds.e”
    #import “slickedit/stringutil.e”
    #import “slickedit/search.sh”

#pragma option(strictprotos,on)

Currently, when the Slick-C compiler encounters a function call to a previously undefined function, it assumes that the function is a global function.  The function call is resolved at link time, and an error will show up at run time if the function does not exist or is not provided enough parameters.

With this option enabled, all function calls will require the function to be previously declared or imported.

This pragma will be off by default, however it's use will be strongly encouraged for new Slick-C code that uses namespaces and classes.

Namespaces

Slick-C namespaces will use "." instead of "::".  Slick-C will support two types of namespace declarations.  Slick-C will not allow un-named namespace declarations.

Code: [Select]

    // module-wide (like Java)
    namespace slickedit.tagging;   

    // scoped namespace declaration (like C++ and C#)
    namespace slickedit.search {
       . . .
    }

Namespace imports will use the C++ style using syntax.

Code: [Select]

    // pull all symbols from slickedit.tagging into current scope
    using namespace slickedit.tagging;

    // pull one symbol from slickedit.search into scope
    using slickedit.search.Regex;

    // qualified access to a symbol in the namespace
    slickedit.diff.Diff( f1, f2 );

Interfaces

Interfaces will use Java-like syntax.  They will not allow constructors, destructors, or member variables, only prototypes.  Interfaces may inherit from other interfaces.

Code: [Select]

    interface CommunicationDevice {
        void talk();
        void hangup();
    };

Classes

Classes will use Java-like syntax.

Code: [Select]

    class Phone : CommunicationDevice {
        Phone(_str number=“”) { }
        ~Phone() { }
        void talk() {
        }
        void hangup() {
        }
        static void getOperator() {
        }
        protected typeless dialer;
        private typeless line;
        private static typeless operator = null;
    };

A few notes about Slick-C classes:

• Classes can inherit from classes and/or interfaces.
• A class can only extend one class, but it may implement multiple interfaces.
• There will be no "extends" or "implements" keywords.
• Classes will not be allowed to derive from "struct" types.
• The default access level will be public. There will be a "public" keyword, but it will essentially do nothing.
• Class members will support "protected" and "private", as usual.
• There will be no concept of a package scope as there is in Java. While this is a useful feature, it is largely misunderstood by the majority of Java programmers, causing more problems that good.
• Member functions will be virtual by default, except for "static" member functions, as usual.
• "static" member variables may have initializers.
• "extern" member function prototypes are to be implemented in a DLL.
• A class is allowed one and only one constructor.
• If a class constructor takes arguments, they must have defaults.
• No explicit calls to new or delete (no new or delete keywords).
• No function overloading -- maybe for a future release.
• No operator overloading.
• No friend relationships.
• No templates or generics -- maybe for a future release.
• No final and no const.
• No C# style properties or delegates.
• No default root "object" class.
• No static constructors -- maybe for a future release.

The life-span of a Slick-C class instance is identical to that of a similar Slick-C struct.  There will be no "new" and "delete" operators.

Code: [Select]

    // construct an instance of a class, like C++
    C1 a;
    C1 b;

    // assign a class instance to another (deep copy)
    a = b;

    // An array of class instances.
    // Constructor not called here.
    C1 array[];   
    // Constructor called with no args
    // followed by deep copy.
    array[1] = a; 

Introspection

Slick-C will support introspection of struct and class instances through the following new built-in functions.  In each the functions below, "index" can be either an integer index, or a string containing the field or method name.

Code: [Select]

    v._typename()
    v._fieldindex(name)
    v._fieldname(i)
    v._getfield(index)
    v._setfield(index,value)
    v._findmethod(name)
    v._callmethod(index)
    v._instanceof(name)

The C++ API for Slick-C will be extended to include the following functions.

Code: [Select]

    vsHvarTypename(hvar)
    vsHvarFieldIndex(hvar,name)
    vsHvarFieldName(hvar,i)
    vsHvarGetField(hvar,index)
    vsHvarGetFieldByName(hvar,name)
    vsHvarSetField(hvar,index,value)
    vsHvarSetFieldByName(hvar,name,value)
    vsHvarFindMethod(hvar,name)
    vsHvarCallMethod(hvar,index,args)
    vsHvarCallMethodByName(hvar,name,args)
    vsHvarInstanceOf(hvar,name)
    vsHvarConstruct(name,args)

New Reserved Words

The following keywords will be made reserved.  Old code that uses any of these keywords as function names, variable names, or any other type of identifier will no longer compile.

• namespace
• using     
• interface
• class     
• public   
• protected
• private   
• extern   

The following identifiers will be made reserved as built-in functions.

• _typename   
• _fieldindex
• _fieldname 
• _setfield   
• _getfield   
• _findmethod
• _callmethod
• _instanceof

Features Not Addressed

The following modern language features are not going to be considered for Slick-C.

• Exception handling -- extremely big wormhole to go down and potential performance issues.
• Generics or templates -- maybe for a future, future release.
• Function overloading  -- maybe for a future, future release.
• Static constructors  -- maybe for a future, future release.

[Graeme]

Sounds great.  I have a small number of comments.  Don't know what the importance is - except for *1.

Allow initialised local static variables.
Allow local static class objects.
Allow statements to break across lines without needing binary operator or backslash - *1.
Provide int variables that are always int and can't change to float.
Maybe interfaces could include named constants.
Is there any use for references as local variables or members?

Regarding deep copy -  was any thought given to disallow copying via copy assignment just in case the copy process needs to do something special like create new copies of pointed to objects or something  - even though pointed to objects can't really be created on the heap, you can dynamically create them in an array.  The copy would have to go through a function call or would automatically go through a function call.  The function could handle copying from types different than the destination type. 

Hmm, that makes me wonder - if a pointer is holding the address of an array element or object and the array or object gets reallocated, does the allocator fix up all references or are arrays never reallocated ??.  I'm guessing they're never reallocated which save a big performance hit.

[Maybe not a language issue] Allow menus to call functions that aren't commands so that the list of _commands doesn't get cluttered by functions that can't be called other than from a menu or provide a name attribute that allow these functions to not appear in the key bindings dialog.

[Maybe not a language issue]  - allow dynamic creation of controls.

I can't see any benefit from providing function overloading or templates, especially with a dynamically typed language.

Graeme

[hs2]

Quite thoughtful enhancements - very promising !
I agree that these things are helpful/needed for extending the product w/o extending it's complexity.
At least for those 'using the source' ...
E.g. interfaces/classes could provide a more robust and flexible 'plugin' mechanism to some Slick components (e.g. instead of callback lists). This could open a new dimension to customizers

Graeme already addresses the things I'm currently aware of.
But I think there is a reason for not supporting local statics, right ? On the other hand it's not that important.

HS2

[gerde]

Would be GREAT to have the __FILE__ and __LINE__ macros (just like in C/C++);
this will make debug Slick-C a bit easier and cleaner.

[Dennis]

Great suggestion, I will add __FILE__ and __LINE__.

[Graeme]

__FUNCTION__ also comes to mind.

Also
1. #undef
2. allow macros to have arguments and provide # stringize and ## concatenate as in C/C++

I recently had a need for the latter two things.  I was trying to change the code I have for the GFileman configuration dialog into a table driven scheme because I get frustrated with having to find all the places to update when adding a new config option.  I found that this wasn't possible due to the fact that you can't store a pointer to a property  e.g. if a config item is a textbox with name SomeTextBox, then I need an entry in a table that results in a call to p_active_form.SomeTextBox.p_text.  There's no way to do this in SlickC because you can't get the address of a property "function".  I like #undef because it lets me use short names for a macro that's used over a small region, then got rid of.

Graeme

[Dennis]

1. #undef
2. allow macros to have arguments and provide # stringize and ## concatenate as in C/C++

I'm confused by your statements.  Slick-C's preprocessor already has these.  What gave you the impression that it didn't?  The first line of the Preprocessing section of the manual says "Preprocessing in Slick-C is identical to C/C++."

[Graeme]

1. #undef
2. allow macros to have arguments and provide # stringize and ## concatenate as in C/C++

I'm confused by your statements.  Slick-C's preprocessor already has these.  What gave you the impression that it didn't?  The first line of the Preprocessing section of the manual says "Preprocessing in Slick-C is identical to C/C++."

My mistake.  I came to the conclusion that they weren't supported because I couldn't find them in the help.  I thought I tried #undef but obviously I didn't or I got something else wrong.  If I want to know if a feature is supported I generally use the help index or the help search or I flick down through relevant topics looking for headings relating to that item.  Only occasionally would I read in detail from the start of a major topic if the index or search didn't show up anything.  It's quite a while since I read through the macro programming guide and I wasn't taking Slick C all that seriously at the time.

Graeme

[gerde]

Would be very nice if future releases would identify MODIFIED included Slick-C files,
and reload/recompile them BEFORE reloading/recompiling the Slick-C file the user actually asks to reload/recompile.

e.g. given a Slick-C file named 'MyDefines.e', and another Slick-C file named 'MyMacros.e', which includes 'MyDefines.e';
also given is that I modify 'MyDefines.e', then 'MyMacros.e', then ask to reload/recompile 'MyMacros.e';
as of 11.0.2, SlickEdit would only reload/recompile 'MyMacros.e', while ignoring the fact that a dependency file ('MyDefines.e') has been modified too.

maybe this is too much to ask, but as one who tries to keep things organized,
I tend to have one central Slick-C file for all my 'major' defines, one for common/utility/'service' functions/macros
(which serve other functions/macros) (just like you at SlickEdit do), etc., I find this a bit annoying
(i.e. every other compiler does it, so one might argue it is almost a standard);
and if this is too much to ask - then it would be even worse to ask to have the ability/command to reload/recompile all Slick-C files,
which include a given modified Slick-C file, but it COULD be deadly useful
e.g. if one modifies a given - and heavily used - 'define' (say username/pwd/server-name/server-port/...),
then all sources, which use this 'define' become 'stale' ...

p.s. my way of dealing with these issues has been to write a macro, which unloads then reloads all my macro files
(I use a naming convention for my macro files, so the macro can identify them easily),
except of course for the Slick-C file where this macro is coded/defined.
anyone has a better suggestion (i.e. in case answer is 'no') ?

[Graeme]

Would be very nice if future releases would identify MODIFIED included Slick-C files,
and reload/recompile them BEFORE reloading/recompiling the Slick-C file the user actually asks to reload/recompile.

This reminds me of this problem which would be worth fixing
http://community.slickedit.com/index.php?topic=157.msg561#msg561

but this doesn't seem to be what you're asking for and I'm not sure I understand what you're saying.

If mymacros.e includes mydefines.e then why do you want slick to load mydefines.e for you - if it gets loaded as part of the mymacros.e build it doesn't need loading separately.

From reading further in your post, you seem to be asking for make/dependency checking.  When you say "every other compiler does it" are you referring to C/C++ ?  If so, IDE's like Visual Studio or C++ Builder provide built in make/dependency checking but compilers themselves (e.g. GCC) do not provide it directly.

BTW - the def_macfiles string (see vusrdefs.e) contains a list of all your own macro filenames (for some reason it also includes asm.ex from slick macros I think) - you can parse it with parse_file and rebuild all your own macros in one go.  You can also set up an xml file and use Slick's hotfix mechanism to load macros.

You must have a lot of macro files for this to be a problem.  Maybe you could merge some of them.

Graeme

[gerde]

Would be very nice if future releases would identify MODIFIED included Slick-C files,
and reload/recompile them BEFORE reloading/recompiling the Slick-C file the user actually asks to reload/recompile.

This reminds me of this problem which would be worth fixing
http://community.slickedit.com/index.php?topic=157.msg561#msg561

but this doesn't seem to be what you're asking for and I'm not sure I understand what you're saying.

If mymacros.e includes mydefines.e then why do you want slick to load mydefines.e for you - if it gets loaded as part of the mymacros.e build it doesn't need loading separately.

From reading further in your post, you seem to be asking for make/dependency checking.  When you say "every other compiler does it" are you referring to C/C++ ?  If so, IDE's like Visual Studio or C++ Builder provide built in make/dependency checking but compilers themselves (e.g. GCC) do not provide it directly.
...
Graeme

Graeme, this IS half of what I am asking, and I will try to explain:
as you probably know, when a given header/file is included in C/C++, the whole header/file is actually copied to the source which includes it;
this means that any time an included header/file is modified, then when one asks to compile a source which includes it (even without modifying the source),
one is guaranteed the changes to the header/file will be picked up by the compiler (again - as the whole header/file text is added to the begining of the source file).
now - SlickEdit (and here I am guessing) works differently - and similar to the concept used in Java:
all files are compiled, and each will have its binary version (.class in Java, .ex in SlickEdit), and referenced variables/defines/whatever are taken from the binary files, rather than from the source file.
my first request has been, therefore, to make the Slick-C compiler smart enough so that when user asks to compile/load a given Slick-C file ('MyMacros.e'), the Slick-C compiler will NOT blindly use the 'MyDefines.ex' of 'MyDefines.e', but rather - first compare 'MyDefines.ex' and 'MyDefines.e', so that if 'MyDefines.e' is newer (since it has been modified too) - it will first compile/load it (as well as any other stale included files, if there are any), and only then compile/load 'MyMacros.e'.

My Second half has been to have something like 'build-all':
if one modifies a heavily used 'define' in 'MyDefines.e' (and that 'define', for example, is used in 15 different Slick-C files), then currently one has to manually load 16 files:
first 'MyDefines.e', then each and every of these 15 different Slick-C files (assuming one remembers every single file which uses this 'define' ...);
and the idea is to have a command like 'compile/load-this-file-then-any-other-file-which-includes-it:
usefull if one modifies his username/pwd/Version-control-address and/or port, and nothing else.

[Graeme]

now - SlickEdit (and here I am guessing) works differently - and similar to the concept used in Java:
all files are compiled, and each will have its binary version (.class in Java, .ex in SlickEdit), and referenced variables/defines/whatever are taken from the binary files, rather than from the source file.
my first request has been, therefore, to make the Slick-C compiler smart enough so that when user asks to compile/load a given Slick-C file ('MyMacros.e'), the Slick-C compiler will NOT blindly use the 'MyDefines.ex' of 'MyDefines.e', but rather - first compare 'MyDefines.ex' and 'MyDefines.e', so that if 'MyDefines.e' is newer (since it has been modified too) - it will first compile/load it (as well as any other stale included files, if there are any), and only then compile/load 'MyMacros.e'.

Well I still don't understand what you're saying here.  It sounds to me like you're talking about the new #import feature Dennis described, which doesn't exist yet.

In your first post you talked about MyMacros.e including MyDefines.e, and in your second post you also refer to mymacros.e including mydefines.e.  Currently, files that are #included do not have their own .ex file, so what exactly do you mean when you say mymacros.e includes mydefines.e ??

In current Slick C, there is no "uses" or import statement as in Delphi or Java.  If a variable is used in more than one source file then its definition must be included in every source file that needs to use it.  There is no One-Definition-Rule for variables as in C++ - the variable is "defined" in every source file that accesses it but only one object is allocated for it because everything goes through the names table I believe (this info should go in the help file.  For functions, currently, a function can be called without a visible prototype for that function.  You can see the proposed new feature #pragma option(strictprotos,on) in Dennis's post where a prototype can be required.  As stated by Dennis, currently, function calls are resolved at link time (I guess "link time" refers to when Slick loads the .ex file into memory).  So, other than a #include statement, I don't know what you mean when you say MyMacros.e includes MyDefines.e  - hmm, unless you're loading MyDefines.e as its own module  - if so, why do you do that ??  and if this is the case, then I suspect MyDefines.e doesn't need re-loading if it's #included in MyMacros.e.

Maybe the proposed #import mechanism is what you're looking for?  I don't know if it will result in the #imported file being recompiled if it hasn't already or is out of date.

Regarding "build-all dependent modules"  -  I guess this could be useful but it might be more work than is justified.  I've never thought about this but I wonder if you can use a rebuild command on a Slick C project that would recompile/reload all modules in the project - I guess not, coz I've never read anything about it.

Graeme

[Graeme]

This reminds me of this problem which would be worth fixing
http://community.slickedit.com/index.php?topic=157.msg561#msg561

I guess this would be trivial to fix just by forcing the load command to re-compile the module even if it hasn't changed.

Graeme

[jszakmeister]

We are considering making several enhancements to the Slick-C language for a future release of SlickEdit.  The following paper gives an overview of the changes, with examples.  We are posting this specification here in order to get feedback on the languages changes from our users.

Note:  This discussion is to address changes to the Slick-C language.  Do not post any comments about about other languages (Java, C#, Python,Perl,Ruby, JavaScript, TCL, etc.) unless it is to point out a nice feature that could be added to Slick-C.  Please post about adding support for other macro languages on another thread.

I understand the point of the above comment, but I'm disappointed to actually see it.

A significant portion of SlickEdit is written in Slick-C, so the language is not going away anytime soon.  We are simply trying to make it more modern and powerful.

Once again, I understand what you're saying here, but to be honest, Slick-C (at least for users) is full of odd rules, silly naming conventions (that aren't documented well), and has a host of facility that only a few know how to leverage.  I've been using SE for nearly 6 years, and I've barely touched the Slick-C facility precisely because I can't find documentation on the function or naming convention I need to follow, and I don't have time to spend hours searching through the code base only to find a fragile solution that breaks between releases.  The current docs are geared towards GUI's, and the most complex macro in it is a line-counting algorithm.  Something a little less trivial and much improved documentation (especially when it comes to interacting with the editer) would go a longer way than extending the current Slick-C, IMHO.

I don't mean that to be an attack against the SlickEdit team.  It's meant to be an honest criticism.  I love to write tools and automate portions of my workflow, but Slick-C has been an impediment to doing that.  In fact, the only thing that has kept me a user of SE is it's great tagging support.  Again, not an attack.  I'd love to be fully-entrenched in SE and its capabilities.  I just want to make sure I'm more productive as well. :-)

<snip>
The := Operator

The := operator is used as follows:

Code: [Select]

    id := expr;

In this statement, "id" is declared as a local variable with the same type as "expr". 

I can see that being a strong area of confusion for those who don't use Slick-C much (i.e., "Which way  do I declare this?").  While it may be acceptable to use both ways to declare a variable, a user needs to know that, so make sure to clearly document it somewhere.

In addition, Slick-C enumerated types are going to introduce enumerated type flags, a convenient way to create a set of bit flags.

I'm not sure I'd spend much time on that.  It takes only a short period of time to define the flags versus coding the actual functionality that makes use of them.  IOW, I don't think it's a big win in productivity for you or us. :-)

<snip>
#import Directive

#import is a preprocessing directive but it is more than a #include, in that it does the following:

• Imports all public declarations from a Slick-C module.
• Uses an implicit header guard to prevent recursive or multiple importation of the same module.

When processing a #import, the following rules will be in effect.

• All function definitions are treated as prototypes.
• Global variable definitions are treated as declarations.
• Static globals are ignored.
• Forms, menus, event tables and event handlers are ignored.
• #includes continue to be treated as part of the #import.

Code: [Select]

    #import “stdcmds.e”
    #import “slickedit/stringutil.e”
    #import “slickedit/search.sh”


Will the imports be namespaced?  It would be better if they were... but I can see how that would present a compatibility issue.

<snip>
Namespaces

Slick-C namespaces will use "." instead of "::".  Slick-C will support two types of namespace declarations.  Slick-C will not allow un-named namespace declarations.

Code: [Select]

    // module-wide (like Java)
    namespace slickedit.tagging;   

    // scoped namespace declaration (like C++ and C#)
    namespace slickedit.search {
       . . .
    }

Namespace imports will use the C++ style using syntax.

Code: [Select]

    // pull all symbols from slickedit.tagging into current scope
    using namespace slickedit.tagging;

    // pull one symbol from slickedit.search into scope
    using slickedit.search.Regex;

    // qualified access to a symbol in the namespace
    slickedit.diff.Diff( f1, f2 );


I find Python's "from pkg.otherpkg import SomeThingUseful" more readable and little more straightforward.

Interfaces

Interfaces will use Java-like syntax.  They will not allow constructors, destructors, or member variables, only prototypes.  Interfaces may inherit from other interfaces.

Code: [Select]

    interface CommunicationDevice {
        void talk();
        void hangup();
    };


I think this would be a handsome addition, but only if the underlying event system made use of them. :-)

<snip a lot of stuff about classes>

I think most of that is what I'd expect for a first cut of classes support.  It should be efficient, and at least follow in-line with the current scheme of how Slick-C works.

Again, if I had my choice, it would be to bolster the documentation.  New language features won't buy much when we still can't make solid use of the core. :-)  Something along the lines of Python's reference library (http://docs.python.org/lib/lib.html) would be a huge benefit.

-John

[Dennis]

jszakmeister

Let me address a few of your comments.

The Note was simply to avoid a language war and to keep everyone focused on the fact the thread was about Slick-C, not integrating a different language.

Your frustrations with the current state of Slick-C seem to be focused more on the API's and docs than the actual language.  We are improving the docs, and the API's will follow eventually.  Note, that if we transported our existing API's to any other language, they would still be what they are.

:= is a form of type inference.  Look forward to seeing this feature in other major languages in the new future.  Java is considering adopting :=.  C++ and C# are planning to use the auto keyword.  For Slick-C, type inference is a great shorthand that gets back to the roots of the language as a scripting language without sacrificing strong typing.  We are actually going further with type inference that then original spec planned, introducting the auto keyword as a third alternate, and allowing type inference with pass by reference parameters.  Example:

Code: [Select]

   save_pos(auto p);                                       // p is declared as in prototype for save_pos()
   _GetScreen(auto x, auto y, auto w, auto h);    // x,y,w,h declared as int, as in prototype
   parse someString with auto first auto rest;       // first, rest declared as _str

enum and enum_flags are productivity boosters, because they let the editor help you code.  Suppose you have the following:

Code: [Select]

enum_flags MYFLAGS {
   MYBIT0,
   MYBIT1,
   MYBIT2
};
void doSomething(MYFLAGS f);
When you call doSomething(), since it's type is an enum instead of a big dumb "int", the editor can help you by suggesting MYBIT0, MYBIT1, or MYBIT2, and other symbols with have the MYFLAGS type.  Furthermore, the compiler can prevent you from mistakenly writing:  doSomething(SOMEOTHERFLAG);

This is should be the focus of languages of the future -- making programming easier and safer by providing mechanisms that tools can use to help you instead of hinder you.  Unfortunately, recent language trends (Ruby, Boost) are going wildly in the opposite direction.  Sorry, I just violated my own rule...  (and yes, I know that Boost is a library, not a language -- I know much more about it than I care to know -- it's like knowing exactly how a toilet works.)

#imports will not be namespaced.  A symbol will always be in exactly the namespace it is declared in, whether it is imported or declared in your local module.  This just keeps things simple and continues along the premise that the language should be tool-friendly.  In fact, when we implement namespaces, you will not be allowed to do a #include or #import within a namespace.