Collections (real collections!) in Turing

[DemonWasp]

What is this: This is an implementation of *some* of the Java Collections Framework in Turing. There will be substantial API differences, mostly caused by issues with OOP in Turing.

Preface: I did this mostly out of the spirit of "can-I-do-this", but also partially to make it easier for students using Turing to learn more complex data structures than simple arrays (and therefore easier to move to a more powerful language with better support for these, including but not limited to C++/Java). While I have run some tests, I can make no promises about the correctness of the entire API; if you run into bugs or unexpected behaviour, post and complain, I'll try to fix it. While I have attempted to code both clearly and for speed, I make no guarantees about speed (the code is relatively clear); Turing is a fickle beast at best when it comes to speed and I've run no tests related to speed. I am also not done this.

Getting Started: First, you need to understand OOP, particularly Turing's muddied version of it. See Cervantes' excellent tutorial; you will need to understand all of it before my submission will make much sense. You should also know how to cast pointers in Turing.

What does the Collections framework do for me? The framework supplies some commonly-used data structures for your use. So far, we have Lists, which store objects in a given order, modifying that order only as you explicitly tell them to; we also have Maps, which store a set of key-value pairs (though they do not guarantee any order at all). We do not yet have Sets, and we currently have only four actual implementations (ArrayList, LinkedList, DLinkedList, HashMap).

How do I use Collections?
First, you will need to use the include directive to add Collections.t to the top of your code. This directive tells Turing to substitute the contents of "Collections.t" for the line specified. You do not need to include Lists.t or Maps.t, as these are included by Collections.t.

You can then access any of the "public" classes defined in Collections.t, Lists.t and Maps.t (see below). These classes and type are all marked as pervasive which means that you do not need to import them into any classes of your own. To add your own classes into the Collection classes, you will need to extend Element. Here is a simple example - a wrapper for Turing's string type that allows you to put those strings into Lists and Maps:

Turing:

class BasicString     inherit Element     export myString, assignValue     var myString : string     body proc construct ()         className := "Element.StringElement"     end construct     body proc destroy ()         % do-nothing     end destroy     proc assignValue (newValue : string)         myString := newValue     end assignValue     body fcn toString () : string         %put "StringElement::toString()"         result "\'" + myString + "\'"     end toString     body fcn hashCode () : int         var hash : int := 0         for i : 1 .. length (myString)             hash += ord (myString (i))         end for         result hash     end hashCode     end BasicString type pervasive BasicStringPtr : ^BasicString class BasicStringImpl     inherit BasicString         body fcn equals (e : ^Element) : boolean         if e -> className not= className then             result false         end if         var other : BasicStringPtr := cheat (BasicStringPtr, e)         result other -> myString = myString     end equals end BasicStringImpl

The basics of this:
1. We need to implement construct() so that we can set the className of the object. This is used by equals() to ensure that our casts are legitimate (see below).
2. Although destroy() is available, we have no need for it in this class, as it does not allocate any memory by new.
3. assignValue() is specific to this class, and does not override anything in Element. It's a fairly standard setter.
4. toString() is like the Java method of the same name - it provides a String representation of the object. You do not have to override this, but the default implementation just lists the className variable.
5. hashCode() is only needed if you're going to use a collection that needs hashes. Override it to provide any integer, as well-distributed as possible over the integers.
6. equals() compares this object to another object. Note the className check happening before the cast ("cheat"), to ensure that we never cast a pointer incorrectly.
7. We have the type line and the BasicString/BasicStringImpl nonsense because Turing doesn't appear to have a forward class-declaration mechanism, nor does it have a forward type-declaration mechanism. Yes, it sucks; sorry.

Now, an example of what we can do:

Turing:

include "Collections.t" include "BasicString.t" % Set up our map object. var map : ^Map new HashMap, map map -> construct () % Create a key-value pair and insert it into the HashMap var key, value : ^BasicString new BasicStringImpl, key new BasicStringImpl, value key -> construct () value -> construct () key -> assignValue ("some key") value -> assignValue ("myValue") map -> insert (key, value) % Make a new key with the same value as the original key to retrieve the object var otherKey, otherValue : ^BasicString new BasicStringImpl, otherKey otherKey -> construct () otherKey -> assignValue ("some key") % Retrieve the value using the other key (which is equal to key according to BasicStringImpl.equals() ) put map -> retrieve (otherKey) -> toString () % Free all the memory used by the Map object. map -> destroy () free map

This is just a simple example. You can do a LOT more with it.

Notes:
- Since Turing doesn't support templating, there is currently no way to ensure that anything inserted into a given collection is of a certain class. You will also have to manually cast ("cheat") every time you retrieve something, or else only use the Element API (as seen in the example; I used toString() ).

All comments / suggestions / criticisms are welcome. I'm not planning on continuing to work on this unless people seem to be interested in using it; as I said, I mostly did this to see how it would be, whether it was possible in such a restrictive language as Turing, etc.

[DemonWasp]

Sorry for double post, it seems I can only attach 5 files at a time. Next time I'll archive them.

[copthesaint]

Is this kinda like a class in java? I don't understand exactly what your posting sorry.

[DemonWasp]

They're actually exactly like classes in Java (Turing's classes are fairly similar to Java's, just less powerful and usable). If you know Java, I assume you're familiar with List, LinkedList and ArrayList...? That's what I've implemented here (as well as Map/HashMap).

If you don't know Java, have you read and understood Cervantes' tutorial, mentioned in my first post?

[copthesaint]

Ohh cool you made a dynamic array? If you did that is awsome because I'm sure Many people would want this to use.

[SNIPERDUDE]

These days Turing support files, classes, and imports seem to be growing in popularity. For example (I know it's only the three of us so far), all of us who have posted on this thread have created some form of support.

Your various classes, copthesaint's Turing 360, and my LGUI (custom Turing GUI class).

Anyhow, looks promising. Does anyone know what is to become of OpenT?

[DemonWasp]

OpenT is toast as far as I know. Their domain isn't registered. If they were still alive, I'd be implementing some kind of syntax to use these natively in Turing.

If you have any suggestions as to what you'd like to see added to this (assuming you're still coding in Turing...), feel free. If anyone who's actually learning in Turing is using these / becomes capable of using these before they graduate to another language, let me know what you think (please!).

What I'd do to Turing syntax:

1. Allow forward class declarations.

2. Allow cheat to be used on pointers. Better yet, replace cheat with some kind of operator like so:

code:

var specificVar : ^Specific := cast baseVar to ^Specific

3. Allow variable-length arrays to be passed as a result from functions. This would permit the toArray() function from the Java API, however useless it may be.

4. Replace Turing's current new syntax with the C++/Java syntax: Object myObj = new Object()

4.1. As the previous point implies, constructors would now be optional, and would have the same name as their class.

5. Lists/sets/maps/queues would be easy:

code:

var myList : list of {type}

where type is any primitive, record or object. This includes the following:

code:

var playerProfiles : map of ( string, list of ^Profile )

which would of course be a map from Turing's string primitive to a list of Profile objects (presumably multiple profiles indexed by player name).

6. Allow Turing keywords to be used as object names, particularly the IO functions (put, get, read, write). So when you say:

code:

class SomeClass     export put     proc put ()         % Output code here     end put end SomeClass var instance : ^SomeClass := new SomeClass() put instance

it would, instead of saying "invalid put object", execute the class in the put method (and if you specified a stream in your put command, it would route output from the put() method to that stream automagically. This would be like Java's toString() or C++ operator-overloading, except limited to the put, get, read, write operations.

7. Allow overloading based on parameter list type. This is the standard in Java/C++/probably lots of other languages, and it's a whole lot nicer than separate method names for everything.

8. At the very least, add an instanceof operator, if not access to the className of a given object.

[SNIPERDUDE]

So do you think Holtsoft is actually going to produce the open-source code they've been promising?

EDIT:

Hmm, turns out they don't even have their website up anymore...

[DemonWasp]

Yup, Holtsoft is well and truly dead. I would assume that this means no open-source code (they may have looked at it and gone "oh gods, we can't release this").

If students are lucky, this means that schools in Ontario will end up switching to another language. I would assume VB would be the likely candidate (C++ is harsh, Java is too complex for a newcomer, most other languages aren't likely to be considered by the schoolboard...). If the students are really lucky, they'll switch to another language; maybe Python, which I've heard is easy to learn.

What's more likely is that schools will stick with an increasingly-outdated Turing as the inertia to change is high. Sadly, OpenT could have stepped in here and made life a lot better for students, but no such luck.

P.S. If anyone on the original OpenT team can point me to how to set up / build / run the original OpenT code (their GoogleCode SVN is still up), I'd be much obliged.

[saltpro15]

oh lord no not basic, basic should be killed with fire. hopefully c++ but I know the intellectual capacity of the gr9 and 10's coming into CS in the next few years that unless some brain transplants occur, there's a better chance of water catching on fire.

[DemonWasp]

It's really not the fault of the students. C++ is a complicated, difficult language. There are hundreds of hidden complications that stem from issues a beginner cannot understand (generally, they can't even understand the reason for the complication immediately - I know I frequently couldn't). Even in a year-long course at that level, I would have had a hard time picking up C++ (point of reference, I taught myself enough Java to "get by" that year of CS).

Normally I would agree that BASIC is an awful language. It is! But VB .NET improves a few things (or so I've heard, latest version of VB I've used was 6, and it lacked proper OOP capabilities among other issues), and really it's the only option for a real GUI in a high-school-level program. Theoretically, you could do so with C++ or Java or whatever else, it's just easiest (and the most immediate response) in VB.

In all honesty, schools should probably be looking at Pascal (which is what was generally used before Turing, as I recall, hence Holtsoft compared their performance in teaching to Pascal's) and Python. Ideally, it'd be a language that abstracts you away from the minutiae of the machine enough that newcomers can get comfortable writing small, useful applications before they get into the heavier stuff.

[copthesaint]

Actually word is that That they are switching to Ruby. Now this as I was told is not a 'For sure thing' but yea that's what I've heard, and I know for sure that they are using a new language at the end of the year. Well this is for The best, Maybe.
The reason why I've heard is because I'm still in grade 10 and Btw I'm teaching myself java and I am still at the basic hence, I haven't posted any programs in java.

Also just a question off topic did you figure out how to make a custom text field? couldn't figure it out.

[SNIPERDUDE]

I'd agree with Python as the next. Just an opinion.

[darkangel]

I have to admit, Python is an amazing Language. It took me less than an hour and I had written my first program. It was a web spider that went to each of my favorite websites and downloaded any new content into a folder. So I wouldn't have to go looking for it.

As long as they teach Python 3K and not the 2.X. 3K is more like other languages thus decreasing the time it would take for a new student to switch out of Python and into another language.
Also, hated VB with a firery passion. PHP made my life as a Web Application Programmer soooo much easier. After all, nothing can beat it's documentation
(ex php.net/commandNameHere)

[Analysis Mode]

Turing is, according to my CS teacher, a rip-off of C++ and Pascal that some guy made just so he could earn money (and he did, just look at how many schools in Ontario use Turing). But I have to emphasize the fact that in most CS competitions and online judges (SPOJ, USACO Training Pages / contests), Turing is not an admissible language (apart from CCC Stage 1 and ECOO). In fact, I doubt anyone outside of an Ontario high school uses Turing. Also, Turing is quite slow, I hear. In Gr 10 at our school, Pascal is taught. It is a simple, powerful language and anyone staring at a Pascal program can kind of figure out what it's doing. C++, which I use, is an even more powerful language but yes, it is more difficult to learn, as random things DO happen.