Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

Ideal Language

Name: Anonymous 2011-10-11 13:10

There a many tiresome tidbits with C++, Objective C/C++ and D, so I sat down and wrote this syntactical Idea.

Important points:

   + interface and implementation are distinct and are designed to remove repeated code pieces, such as type signatures. that also allows just having to change the types in the interface, but not in the implementation

   + readable syntax, partly borrowed from ObjC, partly from C++, partly from Go
   + no more platform-dependent cruft, thanks to modules and a "real" runtime library
   + compiletime type detection makes it possible to omit type definitions almost completely (already possible with LLVM)



/**
* #####################
* #  Class Definition #
* #####################
*/
module MyModule.Hello;

interface (class Hello)
    /* array types are declared with `[<type>]',
       instead of `<type>[]' */
    var ([Char])  name;
    /* if the function doesn't take any arguments,
       the [] can be omitted */
    func Hello;
    func ~Hello;
    func setName [(String) newname];
    func getName [] -> (String);
end;


/**
* ########################
* # Class Implementation #
* ########################
*/

import Sys;
implements MyModule.Hello;

implementation (class Hello)
    func Hello =
    {
        /* const string literals are prefixed with a '$'
           in const string literals, every character is
           treated 'literally' - hence the name.
           a string literal without a prefixed '$' is also
           a literal string, but escape sequences are
           processed in a non-const literal string.

          $"foo" could thus also be written as:
            const("foo")
        */
        Sys.LogF($"Class <%p> has been created!", Object.ToString(self));
    };

    func ~Hello =
    {
        if(self.name != nil)
        {
            delete self.name;
        }
        Sys.LogF($"Class <%p> has been destroyed!", Object.ToString(self));
    };

    func setName =
    {
        /* allocate, reallocate and deallocate are
           keywords, and can be overloaded by
           defining 'func operator allocate(Object ob, int size)'
           for all types, or 'func operator allocate(<type> ob, int size)'
           for specific types.
           even in overloaded functions, the global
           standard 'allocate' family functions are
           accessible through 'Object.alloc', 'Object.realloc',
           and 'Object.dealloc'. */
        self.name = allocate (newname.length()+1);
        /* (const-)array methods are available through the
           'Array' type, as static members. */
        Array.copy(self.name, newname, newname.length());
    };

    func getName =
    {
        /* typecasting is done via '<expr> as <type>',
           eg:
                (['h', 'i'] as String) => "hi"
                (10 as Char)           => '\n'
                (5.2 as Integer)       => 5
                (5 as Long)            => 5.0
            et cetera.

            if typecasting is not possible, eg:

                ("foo" as Char) => cannot cast a string to char

            a 'Sys.Exceptions.TypeCastError' is thrown:

                Exception 'Sys.Exceptions.TypeCastError' thrown at
                "yourfile.src", line 32213:

                    Cannot cast type 'Object.StringLiteral' to 'Object.Char'
        */
        return (self.name as String).dup();
    }

end;

/**
* #################
* # Main Function #
* #################
*/


/* as long as the function doesn't return, it doesn't need
   an explicit type either */
func main()
{
    /* similar to C#4, variables do
       not require an explicit type
    */
    var h;
    /* classes created with 'created' are allocated
       on the heap, and are similar to the
       function-style initiation of classes
       in C++. They don't need to be explicitly
       deallocated. */
    h = create Hello;
    h.setName("World");
    Sys.LogF($"Hello, %s!", h.getName());
}


Your Opinion?

Name: Anonymous 2011-10-11 13:13

If it ain't Lisp, it's crap.

Name: Anonymous 2011-10-11 13:24

var ([Char])  name;
what a waste of key presses just to do a simple
char* name;

end;
classes and functions use different syntax to end/begin which is also horrible idea


func name2 =
{
}

func name =
{
};

func main()
{
}


three different functions, three different inconsistent syntax usage

Name: Anonymous 2011-10-11 13:33

GC is shit

Name: Anonymous 2011-10-11 13:56

>>2,4
kill yourselves.

Name: Anonymous 2011-10-11 14:06

>>3
what a waste of key presses just to do a simple
Breaking news! char* is a pointer. It may be an array. but it may also not be an array. It may be a pointer to an int* pointer. Which, in turn, may, or may not be an array. Catch my drift here, ``brah''?

Having a consistent type declaration syntax makes that kind of ambiguity impossible.

three different functions, three different inconsistent syntax usage

The first two are to be used in interfaces. An var (static Integer) foo; might thus be implemented this way:

foo = 42;

And why use a different syntax for functions? It's basically the same idea, even though not the same semantics.
Keep It Simple, Stupid!

The semicolon at the end of func2 is optional.

Name: Anonymous 2011-10-11 14:34

var h;
You shouldn't allow unitialized variables in a language with type inference. That's calling for silly bugs.

    /* classes created with 'created' are allocated
       on the heap, and are similar to the
       function-style initiation of classes
       in C++. They don't need to be explicitly
       deallocated. */
I see what you're trying to do but this syntax is bad and there's no point in allocating those instances on the heap instead of the stack.

end;
Terrible!

        /* allocate, reallocate and deallocate are
           keywords, and can be overloaded by
           defining 'func operator allocate(Object ob, int size)'
           for all types, or 'func operator allocate(<type> ob, int size)'
           for specific types.
           even in overloaded functions, the global
           standard 'allocate' family functions are
           accessible through 'Object.alloc', 'Object.realloc',
           and 'Object.dealloc'. */
One doesn't allocate an object but space for it. I guess you're trying to make the use of memory pools more convenient and failing.

if typecasting is not possible, a Sys.Exceptions.TypeCastError' is thrown
An exception for a static cast error makes no sense because it can be verified at compile-time. Be more clear.

Please take a look at OCaml, >>1.

Name: Anonymous 2011-10-11 15:00

>>1
Would you code in it?

Name: Anonymous 2011-10-11 15:31

>>8
In an instant. I'd consider it the sane middleware between C++ and D.

C++ as such is a great tool, but as flexible as a bar of titanium metal.
D is a great tool too, but utterly infested with GNUicisms, and as portable as VisualBasic.

Name: Anonymous 2011-10-11 15:45

Wow, it uses printf() style strings.  How advanced and totally original and safe.

Name: Anonymous 2011-10-11 15:55

>>9
C and assembly are magic pens which let you draw everything. Common Lisp is a helpful maid that will do anything reasonable you ask her and remember everything you say.

Name: Anonymous 2011-10-11 16:14

All that and you don't even have proper support for properties? Getter and setter methods, really?
I also see you were too cheap to add a length property to your arrays. Allocating raw memory for your "string", that's not tiresome at all. We already have a language where arrays and pointers are all but interchangeable, you don't want that shit when you purport to be higher level.

Name: Anonymous 2011-10-11 17:43

$_;

Name: Anonymous 2011-10-11 18:32

>>11
>magic pens that let you draw anything.

yeah, but they are REALLY fine pens, so it might be difficult to draw something big.

C also tends to smear ink sometimes.

Name: Anonymous 2011-10-11 18:46

>>14
Learn to quote, my man.

Name: Anonymous 2011-10-11 19:15

>>12
We already have a language where arrays and pointers are all but interchangeable
Which one?

Name: Anonymous 2011-10-11 19:19

>>16

This happens when you pass an array as a parameter to a function in C.

Name: Anonymous 2011-10-11 19:46

Ugliest fucking language I have ever seen.

Sys.LogF made me fucking barf.

Name: Anonymous 2011-10-11 19:59

;

Name: Anonymous 2011-10-11 19:59

/* array types are declared with `[<type>]',
       instead of `<type>[]' */


Why?

Name: Anonymous 2011-10-11 20:02

That's not lojban.

Name: Anonymous 2011-10-12 3:40

The urge to create a new language is inescapable for new programmers.  It can be good to go through the exercise.  Just be aware that every new programmer has done this and that your new language is absolutely not ideal, no matter how much you love it.

Name: Anonymous 2011-10-12 6:13

>>22
your new language is absolutely not ideal

Funny, the people who invented ObjectiveC thought the same, when they merged smalltalk with C. And now, every Apple fanboy/girl ever uses ObjectiveC like it's a gift from god.

Boy, sure is just a really strange coincidence, no?

And frankly, I'm not an apple user, nor do I own anything remotely applesque, but the interface/implementation 'idea' in ObjectiveC is a good one, one that should be supported

Name: Anonymous 2011-10-12 9:16

>>23
You can do the same thing in C, in fact it is what ooc has done.

Name: Anonymous 2011-10-12 12:13

I don't care what the syntax looks like as long as it doesn't have GC.

GC is shit.

Name: Anonymous 2011-10-12 12:42

>>25
BUT WHAT ABOUT THE FIOC?

Name: Anonymous 2011-10-12 12:50

>>1
Try out Haskell

Name: Anonymous 2011-10-12 13:06

>>25
kill yourself faggot.

Name: Anonymous 2011-10-12 14:22

Programming Language Checklist
by Colin McMillen, Jason Reed, and Elly Jones.

You appear to be advocating a new:
[ ] functional  [ ] imperative  [ ] object-oriented  [ ] procedural [ ] stack-based
[ ] "multi-paradigm"  [ ] lazy  [ ] eager  [ ] statically-typed  [ ] dynamically-typed
[ ] pure  [ ] impure  [ ] non-hygienic  [ ] visual  [ ] beginner-friendly
[ ] non-programmer-friendly  [ ] completely incomprehensible
programming language.  Your language will not work.  Here is why it will not work.

You appear to believe that:
[ ] Syntax is what makes programming difficult
[ ] Garbage collection is free                [ ] Computers have infinite memory
[ ] Nobody really needs:
    [ ] concurrency  [ ] a REPL  [ ] debugger support  [ ] IDE support  [ ] I/O
    [ ] to interact with code not written in your language
[ ] The entire world speaks 7-bit ASCII
[ ] Scaling up to large software projects will be easy
[ ] Convincing programmers to adopt a new language will be easy
[ ] Convincing programmers to adopt a language-specific IDE will be easy
[ ] Programmers love writing lots of boilerplate
[ ] Specifying behaviors as "undefined" means that programmers won't rely on them
[ ] "Spooky action at a distance" makes programming more fun

Unfortunately, your language (has/lacks):
[ ] comprehensible syntax  [ ] semicolons  [ ] significant whitespace  [ ] macros
[ ] implicit type conversion  [ ] explicit casting  [ ] type inference
[ ] goto  [ ] exceptions  [ ] closures  [ ] tail recursion  [ ] coroutines
[ ] reflection  [ ] subtyping  [ ] multiple inheritance  [ ] operator overloading
[ ] algebraic datatypes  [ ] recursive types  [ ] polymorphic types
[ ] covariant array typing  [ ] monads  [ ] dependent types
[ ] infix operators  [ ] nested comments  [ ] multi-line strings  [ ] regexes
[ ] call-by-value  [ ] call-by-name  [ ] call-by-reference  [ ] call-cc

The following philosophical objections apply:
[ ] Programmers should not need to understand category theory to write "Hello, World!"
[ ] Programmers should not develop RSI from writing "Hello, World!"
[ ] The most significant program written in your language is its own compiler
[ ] The most significant program written in your language isn't even its own compiler
[ ] No language spec
[ ] "The implementation is the spec"
   [ ] The implementation is closed-source  [ ] covered by patents  [ ] not owned by you
[ ] Your type system is unsound  [ ] Your language cannot be unambiguously parsed
   [ ] a proof of same is attached
   [ ] invoking this proof crashes the compiler
[ ] The name of your language makes it impossible to find on Google
[ ] Interpreted languages will never be as fast as C
[ ] Compiled languages will never be "extensible"
[ ] Writing a compiler that understands English is AI-complete
[ ] Your language relies on an optimization which has never been shown possible
[ ] There are less than 100 programmers on Earth smart enough to use your language
[ ] ____________________________ takes exponential time
[ ] ____________________________ is known to be undecidable

Your implementation has the following flaws:
[ ] CPUs do not work that way
[ ] RAM does not work that way
[ ] VMs do not work that way
[ ] Compilers do not work that way
[ ] Compilers cannot work that way
[ ] Shift-reduce conflicts in parsing seem to be resolved using rand()
[ ] You require the compiler to be present at runtime
[ ] You require the language runtime to be present at compile-time
[ ] Your compiler errors are completely inscrutable
[ ] Dangerous behavior is only a warning
[ ] The compiler crashes if you look at it funny
[ ] The VM crashes if you look at it funny
[ ] You don't seem to understand basic optimization techniques
[ ] You don't seem to understand basic systems programming
[ ] You don't seem to understand pointers
[ ] You don't seem to understand functions

Additionally, your marketing has the following problems:
[ ] Unsupported claims of increased productivity
[ ] Unsupported claims of greater "ease of use"
[ ] Obviously rigged benchmarks
   [ ] Graphics, simulation, or crypto benchmarks where your code just calls
       handwritten assembly through your FFI
   [ ] String-processing benchmarks where you just call PCRE
   [ ] Matrix-math benchmarks where you just call BLAS
[ ] Noone really believes that your language is faster than:
    [ ] assembly  [ ] C  [ ] FORTRAN  [ ] Java  [ ] Ruby  [ ] Prolog
[ ] Rejection of orthodox programming-language theory without justification
[ ] Rejection of orthodox systems programming without justification
[ ] Rejection of orthodox algorithmic theory without justification
[ ] Rejection of basic computer science without justification

Taking the wider ecosystem into account, I would like to note that:
[ ] Your complex sample code would be one line in: _______________________
[ ] We already have an unsafe imperative language
[ ] We already have a safe imperative OO language
[ ] We already have a safe statically-typed eager functional language
[ ] You have reinvented Lisp but worse
[ ] You have reinvented Javascript but worse
[ ] You have reinvented Java but worse
[ ] You have reinvented C++ but worse
[ ] You have reinvented PHP but worse
[ ] You have reinvented PHP better, but that's still no justification
[ ] You have reinvented Brainfuck but non-ironically

In conclusion, this is what I think of you:
[ ] You have some interesting ideas, but this won't fly.
[ ] This is a bad language, and you should feel bad for inventing it.
[ ] Programming in this language is an adequate punishment for inventing it.

Name: Anonymous 2011-10-12 15:01

>>29
Go back to reddit.

Name: Anonymous 2011-10-12 17:03

>>29
You require the language runtime to be present at compile-time
C-tard detected. Kill yourself. fucking faggot.

Name: Anonymous 2011-10-13 0:13

>>31
[ ] You require the compiler to be present at runtime
[ ] You require the language runtime to be present at compile-time

I saw that and thought of Perl 6.

Name: Anonymous 2011-10-13 2:26

>>29
You made me sad. :(

Name: Anonymous 2011-10-13 4:45

>>32
I saw it and thought of all interpreted languages

Name: Anonymous 2011-10-13 11:33

clojure and clojurescript

Name: Anonymous 2011-10-13 14:49

>>34
Most of them don't require the full power of both at all stages.

Don't change these.
Name: Email:
Entire Thread Thread List