To me it seems rather deceptive to lock in variable types. As a programmer, it would confuse me to see what looks like a variant variable converting values for me and the warnings wouldn''t help much since they shouldn''t be happening according the that line of reasoning.

If you''re going to use variants, go all the way with it and allow variables to change type from line to line. If not, require types.

Either way is a million times more clear IMO, and since it is a scripting language the programmer shouldn''t need to worry about variable types IMO and variants are a lot more convenient.


Really though, I think a dialect of Lisp with the library of functions/macros/special forms built toward the end of scripting would be a better choice for consistency. IMO, it is nice to have so few syntax rules. With a good editor, it would be as easy as any new other language for people of all skill levels.
I don''t want to hijack the thread so I''ll end short of a Pro-Lisp rant =-)

@ irbrian

- Semicolon: You don´t support semicolons at the end of statements. This can be very tricky for your parser to figure out when an assignment, for example, is finished, unless you want to disallow breaking up statements into more than one line.

- I see no advantage in your typeless initialization with the var keyword. Could you give a concrete example? The reason for which i prefer a strong typed langauge against your choice is that the compiler can guarantee that the program executes without any type errors.

@irbrian:
Hatched buried on all issues. I would like to respond to your script code example, though, as well as comment on the unknown type/value distinction.

quote:

---

Original post by irbrian
Actually, I think you''re confusing values and types here. I never said there was an unknown value, for one thing -- I said there was an unknown type, called var, which allows the type to be assigned by value. The default value of any variable that is not initialized to a specific value is always null.

---

What, then, is the type of null? What does it mean to have a null integer, for instance? null as a default for all uninitialized variables works when you have reference-based (as opposed to value-based) variables at core, such that x = 5 doesn''t infer that x is an integer variable, but rather a reference to the immutable integer value 5.

quote:

---

function printInt (var n)    if ( n.isInteger() )        print n + "\n"    else        print "Invalid Argument (" + n.TypeName() + " \''" + n + "\'')"    end ifend 

---

This code snippet indicates that you have an explicit hierarchical type system (like Java, where everything derives from Object) and use reflection up and down the hierarchy to determine exact type. I think that a dynamic typing system helps because it becomes easier to implement this feature: Since you''d have late-binding invocation by default, you''d be able to call a type() member on any object and have it return its type, and then compare that to a user-supplied list. The end user only needs to learn one function, isinstance() or something like that.

But, as you correctly point out, Your Decision is Final.

quote:

---

x = "f"        // Auto-cast, probably to 1 for string length. Log a warning!! 

---

I have a problem with this behavior as well. It is completely unintuitive to have the assignment of a string value to a variant variable (currently housing an integer) result in the length of the string value. It is also disturbing that var, in essence, just delays actual definition: the type of the variable can not be changed after first assignment, meaning that var really isn''t a variant type but rather is just a syntax for declaration without definition, possibly omitting actual type.

This makes the compiler harder to implement, for one thing, but also confuses users.

quote:

---

x = charValue ("f")    // Returns ASCII value of character ''f'' 

---

Just a question about this one: Do you have separate string and character types? I don''t think it''s necessary, and just wanted some clarification on it.

quote:

---

var y = "f"            // Typecast to string 

---

Typecast?! I thought that was a definition?

Variables that have implicit typed values instead of explicit typed variables can still lend to a well structured and typed langauge; it just all depends on the context of those variables and the use of them. For example:

// a variable with integer typed value
var integerVar = 5

// a variable with float typed value
var floatVar = 3.0

// a function taking two value types that can have an addition
// operation applied to them; either with implicit conversion
// or without it
function add( var x, var y )
return (x + y) // implies typed value to return
end

var integer2 = 6
var float2 = 8.3

// returns integer result of an integer addition
var integerRet = add(integerVar, integer2)

// return float result of float addition
var floatRet = add(floatVar, float2)

// return float result of float and integer addition
var floatRet = add(float2, integer2)

When a script like this is compiled the parser will do the type-checking based on the context of the variable. In this example the parser will check that any argument passed to the add function can have an addition operation applied to it; and any variable that is assigned its result will have a typed value based on the arguments passed to it - again, based on context - as in the above example (also, notice that there are rules of conversion here). This brings a "generic" style of programming to the language, which offers less lines of code to write.
With inheritance a strong part of the language, and passing objects around using object references, such as Java does, can be resolved by the parser.
this is just a mock example:

class A
function func( )
IO.print("A:func()")
end
end class

class B extends A
function func( )
IO.Print("B:func()")
end
end class

// this could, in theory, accept any object that
// defines func( ) with some general type-checking
// using the rules of conversion
function foo( var object )
object.func( )
end

Or you could "type" the parameter:

// specify argument type A
function foo( var A object )
object.func( )
end

var obj
obj = A
foo(obj)
obj = B
foo(obj)

The parser could then resolve the argument types of foo( ) by resolving the call to the method func( ); if the object passed implements func( ) then it is compiled, if not the compiler prints a warning to let the script writer know he passed an object that does not implement func( ).

Also, i think it''s good idea to just support a string type, you can even use a string to hold a character string of one character to just be a single character (if that makes sense to anyone).

@I_Animated:
In your examples, one might as well dispense with the var keyword, as it adds no information other than the declaration of a variable, which can be contextually inferred.

I agree with your string type, and it''s exactly what I was asking irbrian for a clarification on. A separate character type is unnecessary in a scripting language, and debatable in any high-level language.

Let your users decide.
Simple idea (may be shot down immediatly)
use HTMLish tags to turn on and off parts of the interpriter, thus changing what is- and isn''t allowed.

Like the code, form, math, amath, function, sub, ect. tags. used in my language The good thing is that you don''t need to add that meny functions, i only used a few lines of code to do the html code parser. (in VB6!).

Also an idea, let your scripting language outsource into other DLL''s, allowing Dynamic DLL usage would work wonders in any scripting language (programmers can program extentions to your game language-like libraries, and other people could use them).

(i am using JVM as in a Virtual computer, with internal memory, byte-code compiled, easier to write- can be written in minites)

Perhaps allow your script to run asm. and/or a JVM (inside your game, as in write most of your code to run in/inform/be called by/call, the JVM/Scripts (probably JVM calling a script.)

Regarding Strings:
I have no plans to create a separate character type. I was thinking of doing kind of what PHP does, and treat multi-character strings as arrays of single-character strings. Thus:

var someString = "Hello Folks!"
var someChar = someString[6]

would store the string value of "F" in the string variable someChar.

Regarding null
My thinking was that null would be a universal value... it can be assigned to any type of variable and that variable will maintain its type. Initializing a variable to null does not assign the variable a type but keeps it as unknown -- although would be redundant since uninitialized variables are set to null anyway.

@Nice Coder*
As I mentioned earlier, I decided early-on against allowing the language to be user-customizable. I think Oluseyi made a valid point earlier about avoiding "There's More Than One Way to Do It" syndrome. The idea with a scripting language is to keep things simple, and "TMTOWTDI" doesn't help. As for DLL's.. I've seen scripting languages that do that, but to me it seems like another way to make things more complicated. I feel like DLLs should be accessed within the internal application, not within the script. Maybe that's just me though.

* I sure hope Oluseyi doesn't mind that I borrowed his @ notation...

[edited by - irbrian on April 16, 2004 11:43:41 AM]

Regarding the ''var'' Keyword and Variant types
Oy. Would it make everyone happier if I kept the ''var'' keyword, but just used var''s as standard variants, but still allowed explicit creation of typed variables:

var aVariant = 7var anotherVariant = "Hello"var yetanotherVar = falseint anInt = 94print aVariant                 // Prints 7aVariant = anotherVariantprint aVariant                 // Prints HelloaVariant = yetanotherVar       print aVariant                 // Prints falseanInt = aVariant               // Errorprint anInt                    // Prints 94 

****************************************

Brian Lacy
ForeverDream Studios

Comments? Questions? Curious?


"I create. Therefore I am."

A true variant is better than what you were previously proposing IMO, but I''m still not sure why you want to keep variable types at all. If you had an IDE with intellisense, then it might help some since it could tell you what variable type you should be typing as a parameter to a function etc but otherwise it seems like extra complexity in both the script and the interpreter for no real gain. Even if you do have an IDE, you could make it show a comment line before the function or somesuch where the argument types could be listed.