Flame, I respect you and your opinions, but seriously - not everything in lisp is a list. It has native data structures - vectors, floats, hash tables, etc. I'm not making this up - I promise. Oh, and those native data structures are not all represented under the hood as lists, either.
The only way that the statement that "everything in lisp is a list" is true is regarding the actual code (not what it represents). What do I mean? Well, where most languages have a special syntax that then gets parsed into a tree for the compiler to deal with, the code you write in lisp *is* that parsed tree of commands.
For instance
The above code is stored as a list - a list of functions. But that doesn't mean that everything referenced in the code is a list.
For instance, the code above set's the last element of "MyArray" to 25. "MyArray" really is an array. Lisp will by default treat it as an array of symbols (which can represent anything - functions, floating point numbers, lists, etc). However, you can specify that it is a floating point array, for instance, and the compiler will optimize it as such - i.e., it'll be a block of contigous memory of size float * # of elements, just like in Blitz or C++.
I'm not trying to advocate Lisp as the be all end-all of languages - but it does have 50+ years of design that's gone into it and if you'd take the time to reacquaint yourself with it you'd find that more and more languages are incorporating features Lisp has had for years now (closures, higher-order functions, anonymous functions, dynamic typing, interactive compilation, etc etc.) I'm not saying Blitz should become Lisp (that'd be pointless) - I'm just saying that it's a good language do draw ideas from as it has a ton of features that other languages are just finally starting to support or can't feasibly support (i.e. Lisp's macros).
I think you'd like the language if you took a look at it. It's not going to replace C++ or Blitz - it's not the right tool for extremely resource intensive things like modern games - but it's not this archaic mess, either.
Anyhow, regarding your challenge - how do you reverse a non-linear data-structure? Well, I don't think you'd necessarily want to, in the first place - and secondly, a non-linear data-structure probably wouldn't inherit from a linear data-structure anyways. You could still reverse it - it all depends on how it is stored in memory - but it wouldn't have any meaning, of course.
I'll admit the choice of using "reverse" as an example was not all that good. You wouldn't want to use reverse on anything but linear data, it wouldn't make sense. I was really just trying to get across the point that a good object hierarchy will allow you to pass "logical" types to a function and let the function deal with them appropriately, without having to specify a separate function. Do I think it'd come up often where I'd need a function that can operate on one or more dimensional arrays? No - but that doesn't mean that it shouldn't be possible.
The one thing that I wouldn't mind seeing is dynamic typing available in Blitz - with the option of statically declaring type to aid the compiler in code optimization.
Anyhow, I'll try to stop bringing up Lisp if you do me the favor of just looking into it a bit and verifying what I'm saying that not everything is a list! :)
The only way that the statement that "everything in lisp is a list" is true is regarding the actual code (not what it represents). What do I mean? Well, where most languages have a special syntax that then gets parsed into a tree for the compiler to deal with, the code you write in lisp *is* that parsed tree of commands.
For instance
(setf (aref MyArray (- (length MyArray) 1) ) 25)
The above code is stored as a list - a list of functions. But that doesn't mean that everything referenced in the code is a list.
For instance, the code above set's the last element of "MyArray" to 25. "MyArray" really is an array. Lisp will by default treat it as an array of symbols (which can represent anything - functions, floating point numbers, lists, etc). However, you can specify that it is a floating point array, for instance, and the compiler will optimize it as such - i.e., it'll be a block of contigous memory of size float * # of elements, just like in Blitz or C++.
I'm not trying to advocate Lisp as the be all end-all of languages - but it does have 50+ years of design that's gone into it and if you'd take the time to reacquaint yourself with it you'd find that more and more languages are incorporating features Lisp has had for years now (closures, higher-order functions, anonymous functions, dynamic typing, interactive compilation, etc etc.) I'm not saying Blitz should become Lisp (that'd be pointless) - I'm just saying that it's a good language do draw ideas from as it has a ton of features that other languages are just finally starting to support or can't feasibly support (i.e. Lisp's macros).
I think you'd like the language if you took a look at it. It's not going to replace C++ or Blitz - it's not the right tool for extremely resource intensive things like modern games - but it's not this archaic mess, either.
Anyhow, regarding your challenge - how do you reverse a non-linear data-structure? Well, I don't think you'd necessarily want to, in the first place - and secondly, a non-linear data-structure probably wouldn't inherit from a linear data-structure anyways. You could still reverse it - it all depends on how it is stored in memory - but it wouldn't have any meaning, of course.
I'll admit the choice of using "reverse" as an example was not all that good. You wouldn't want to use reverse on anything but linear data, it wouldn't make sense. I was really just trying to get across the point that a good object hierarchy will allow you to pass "logical" types to a function and let the function deal with them appropriately, without having to specify a separate function. Do I think it'd come up often where I'd need a function that can operate on one or more dimensional arrays? No - but that doesn't mean that it shouldn't be possible.
The one thing that I wouldn't mind seeing is dynamic typing available in Blitz - with the option of statically declaring type to aid the compiler in code optimization.
Anyhow, I'll try to stop bringing up Lisp if you do me the favor of just looking into it a bit and verifying what I'm saying that not everything is a list! :)