- Exception handling perhaps (try-catch-finally clause)
- Enumeration types (strict handling of some mini type)
- OOP with direct support for interfaces

I'm a fan of strict languages. I like languages that impose defensive programming on the language itself. It helps to prevent error prone code. If a programmer would have to be responsible or remember something for a certain code construct, well, he/she can't remember it all the time. It's not a matter of how one remembers. It's a matter of how one forgets.

Quote:Original post by Kylotan

Quote:Original post by Republicanist
Python-type semantics (if a variable was not already assigned, don't try and receive a value from it)
foo = "Hello!";
MsgBox(foo);
fou = "Hello Two!"; // oops
MsgBox(foo);

I'm not sure what your point is here: there's no error here in Python, and a strongly-and-statically-typed language would not see an error either. Some things the programmer just has to take responsibility for!

Yeah, Im not sure how useful that is either. That has nothing to do with typing strict or static. That is simply using a variable which does not exist in the environment. Although a statically typed language would notice that a reference cell that did not exist was being assigned to. So it does eliminate a certain class of very careless mistakes before runtime.

Republicanist except for the foo = "SD" ; foo = 4 example your use of strict is unorthodox. There, those things had nothing to do with strictness or not, just with binding and assignment. Which is a bit confused. As well your syntax for references implies semantics where every variable is actually a reference - common in imperative languages. However this makes the ref keyword under assignment redundant. Is that your intention?

Personally, I'd say don't implement another script language and reuse one that already exists. Not only will that save you a lot of time and effort, but there are already tons of tutorials and help boards for the popular scripting languages.

If you do insist on implementing something proprietary then for god's sake also make a debugger for it. I've seen this a hundred times before. Programmer X thinks script languages will be great and allow the designers to implement cool things. The designers then get thrown back to the dawn of computing where everyone did printf style (i.e. slow and laborious) debugging. Final result? Your nifty script language that was supposed to save loads of time ends up being the bottleneck for the project.

Quote:Original post by Daerax

Quote:Original post by Kylotan

Quote:Original post by Republicanist
Python-type semantics (if a variable was not already assigned, don't try and receive a value from it)
foo = "Hello!";
MsgBox(foo);
fou = "Hello Two!"; // oops
MsgBox(foo);

I'm not sure what your point is here: there's no error here in Python, and a strongly-and-statically-typed language would not see an error either. Some things the programmer just has to take responsibility for!

Yeah, Im not sure how useful that is either. That has nothing to do with typing strict or static. That is simply using a variable which does not exist in the environment. Although a statically typed language would notice that a reference cell that did not exist was being assigned to. So it does eliminate a certain class of very careless mistakes before runtime.

Republicanist except for the foo = "SD" ; foo = 4 example your use of strict is unorthodox. There, those things had nothing to do with strictness or not, just with binding and assignment. Which is a bit confused. As well your syntax for references implies semantics where every variable is actually a reference - common in imperative languages. However this makes the ref keyword under assignment redundant. Is that your intention?

About the ref keyword... I'm thinking of it in kind of a .NET way, where something like...

int a = 3;
ref int b = a; // a boxed
b = 2; // a still equals 3
ref int c = b;
c = 6; // b now equals 6

In the strictness category, if a language states that the programmer shall define the type of every variable, it does imply the the programmer must declare those variables first.

I believe I mean "strict" as in "tell it everything, even those small, mundane things, so that you won't have to debug the rest of the evening just to discover that you misspelled something (or renamed something, and forgot to change one reference to it...)"

Have you looked at Lua? You should probably look at some functional languages, too.

Now here's an idea:

loop {  // some codecondition(cond); // test  // some more code}

(choose your syntax)

Quote:Original post by Republicanist
About the ref keyword... I'm thinking of it in kind of a .NET way, where something like...

int a = 3;
ref int b = a; // a boxed
b = 2; // a still equals 3
ref int c = b;
c = 6; // b now equals 6

Ah it seems here that ref here denotes a reference to a reference cell. Makes sense.

Quote:[In the strictness category, if a language states that the programmer shall define the type of every variable, it does imply the the programmer must ddeclare those variables first.

I believe I mean "strict" as in "tell it everything, even those small, mundane things, so that you won't have to debug the rest of the evening just to discover that you misspelled something (or renamed something, and forgot to change one reference to it...)"

What you are talking about is explicit typing. Strict in languages usually talks about evaluation strategy or how much a term is reduced when applied. Haskell, miranda and clean are lazy or call by name (need) while most languages are strict or call by value. Instead I think you mean strong where in a statically typed language strong denotes how strict your typing rules are. For example a strong language would not allow the following:

function a = if(a = 4) Print "Hi" else 6;

This is because a = 4 has type unit while if() is expecting a boolean type. As well the bodies of the if statement do not have the same types. The first clause has type unit while the second is a natural. That is strong typing, it is useful in eliminating many types of errors but it gets in the way if you do not have a very polymorphic type system. Thus C++ is not a strongly typed language although it is statically typed since it allows terms like my example above.

Now languages like haskell, Nemerle*, F#* and ML which implement Type Inference (aka implicit typing) do not need type annotations although they are strongly and statically typed.

In haskell you can write
main = do
let foo = "Hello!"
putStr foo
let fou = "Hello Two!"
putStr foo.

You certainly cannot say haskell is not strongly typed.

Quote:Have you looked at Lua? You should probably look at some functional languages, too.

No I have not looked at Lua but I have written in Haskell, substantially in F# and Nemerle, a bit in Ocaml and even less in scheme. I have looked at scala and clean. I am also working on a functional scripting language for learning purposes.

Quote:
Now here's an idea:

loop {  // some codecondition(cond); // test  // some more code}

(choose your syntax)

I am not clear on your intention here.

* In languages with overloading based ad hoc polymorphism like any language on .NET Type inference is made difficult. Thus Nemerle only has Local type inference where as F# has global but requires you to order your files linearly so that it can properly infer types.

[Edited by - Daerax on August 28, 2008 4:17:52 AM]

The intention of the loop is that it can act as a fall-back when existing loops don't work, because, as I remember, this type of loop can represent every other kind of loop. Example:

char c;loop {  c = getc(); // read charcondition(c != EOF); // make sure it doesn't equal end of file  // do other stuff}

And yes, I know this can be represented as

char c;while( (c = getc()) != EOF){  // do other stuff}

but there are more complicated examples available.

It might also help internally; if you can do this loop, every other loop can be transformed into this loop, and automatically gain the same optimizations (or code generation code). Just thinking...

Thanks for the correction in terminology.

As I remember, call by name is different semantically than lazy evaluation. Isn't lazy evaluation an optimization and call by name where the argument is re-evaluated every time its used?

Endar, may I give a piece of advice? Make sure your language is documented, and definitely have some tutorials for it. You should also have some non-programmers, if I gauged your audience correctly, try it out, without you there helping them, because I doubt you'll be able to pay all the plane tickets...

Also make error messages intelligible. Yes I know, it seems obvious, but you wouldn't know how many unintelligible messages I find. Like the famous, "General Protection Fault." (now, how does that help me?)