If you could change Turing

[mirhagk]

A simple question. What do you hate most about Turing, or what feature do you find lacking. If you had the opportunity to change it, what would you change. Keep in mind that ideally you'd want to not break all of existing code, or at least break only obscure code/areas that need to be fixed.

One area for me would be the classes, the features of classes are decent enough, but the syntax is much to ugly, and scary to new users. I would change it to mirror the sytnax for types (ie object.property instead of object -> property). Another area would be forcing the user to have to explicitly declare pass-by-reference parameters in calling functions.

So:

Turing:

proc Evil(var jedi:string)      jedi:="Darth Vader" end Evil var jedi:="anakin" Evil(jedi) put jedi

would change into

Turing:

proc Evil(var jedi:string)      jedi:="Darth Vader" end Evil var jedi:="anakin" Evil(var jedi) % alternatively could be Evil(ref jedi) or some other unused keyword) put jedi

This would of course break existing code, but the compiler could simply throw a warning and compile anyways for the first release.

What would you change, add or remove?

[crossley7]

I would not endorse that change as no other language I have used with much regularity or seen significant code of has required a declaration of that. It is neither intuitive nor is it an advantage to the coder. I want as few useless words in my code as possible and in my opinion the word var falls into that category. The suggestion for classes however does make sense

also keep in mind that what you wrote up there is not an actual turing function but a procedure which works differently. Functions have their own (albeit similar) syntax using the word function (or func?) instead of procedure/proc.

something to change would be in no particular order:
foreach function (similar to python's for x in list type of thing)
no more end if/for/loop (just either use {} or indentation to determine the end)
array subscripts in the form [i][j] instead of (i,j) once again to make it an easier transition to other languages and make subscripts clear from function parameters in terms of syntax.

Now generally these are small suggestions and basically just highlight my distaste for turing style syntax and a few suggestions on what it could look like. Also I don't really care as I rarely code in Turing any more and I know that development of the language is done by people on this site as they find time to do it rather than as a full time occupation

[Tony]

mirhagk @ Tue May 29, 2012 2:15 pm wrote:

I would change it to mirror the sytnax for types (ie object.property instead of object -> property).

The issue is not of syntax but of operator precedence, where dot-operator was weighted higher than a dereference of a pointer. Possibly because C++ does the same (wrong) thing. You can still use .property, as long as you deference first

code:

(*pointer).property

vs

code:

pointer->property

[mirhagk]

@crossley when I said function I meant functions and procedures. The two only really differ in their return type (something vs nothing) so I sometimes just refer to them both as the same thing. Also I am wary about the pass-by-reference change because it does potentially break code, but on the other hand it forces the caller to realize that they are passing by reference, and that what they are passing may be altered (and hopefully also make people more aware of the fact that functions/procedures with side effects are a bad idea in general (except perhaps performance, which doesn't matter in Turing, since it's terribly slow anyways)).

I agree with the foreach and the array indices, although again the array indices will break existing code, so both should be supported for an intermediate version.

I do prefer braces to denote beginning and end of functions instead of end, but I don't think whitespace should affect code, especially with new learners (teachers would end up removing the tab keys from the keyboards just to avoid the impending tab vs space war)

@Tony yeah I figured there was some reason for it. I think Turing's syntax has always been the road of make something simple to the user, hiding the technical details of what's going on, so the whole notion of pointers should be reworked in my opinion.

[evildaddy911]

i really hate the colors, they're in an order that (at best) only makes sense to HoltSoft and fixing them takes WAAY to much time

[DemonWasp]

I believe that the colour palette is actually determined by the operating system, though I could be wrong.

[Zren]

I'd remove the bounding requirements of an array in order to pass it into a function. Similar to returning one.

Eg:

Turing:

fcn f (a : array of int) : array of int     result a end f

[Amarylis]

Zren @ Tue May 29, 2012 9:59 pm wrote:

I'd remove the bounding requirements of an array in order to pass it into a function. Similar to returning one.

Eg:

Turing:

fcn f (a : array of int) : array of int     result a end f

You can remove the upper bound requirement of an array to pass it into a function, though I don't think that's of that much help to you, I imagine?

crossley7 wrote:

foreach function (similar to python's for x in list type of thing)

A foreach function can be coded in turing itself, if one would spend the time and effort into writing java-like classes for Turing (I know that there is one in here on a 2009 post, and I've made a few of them myself), but it would not be nearly as effective, and you'd have to do so by having the foreach call up an external procedure/function

[mirhagk]

The colour palette is one thing that I think should go for sure. There aren't really any good reasons to use 256 colours anymore, so upgrading to rgb colours (while still having the colour names map to the same colour values) would be nice (yes it can be done already, but in a very roundabout way).

The array bound requirements is a good one actually, (for both returning and passing into). The only thing is that the current structure of Turing must known the bounds of an array at compile time (at least the lower bound) in order to convert them into arrays that are consistent with other languages. I don't know the best way to approach that (whether to create arrays that are non-consistent, and hence make calling other dll's more difficult, or to make it consistent and drop either support for lower bounds, or forcing lower bounds to be known at compile time)

[Amarylis]

mirhagk @ Wed May 30, 2012 6:29 pm wrote:

The array bound requirements is a good one actually, (for both returning and passing into). The only thing is that the current structure of Turing must known the bounds of an array at compile time (at least the lower bound) in order to convert them into arrays that are consistent with other languages. I don't know the best way to approach that (whether to create arrays that are non-consistent, and hence make calling other dll's more difficult, or to make it consistent and drop either support for lower bounds, or forcing lower bounds to be known at compile time)

I think the big part of the lower array bounds requirement for Turing is that it can have ANY array bounds, as opposed to having a default lower bounds (i.e. 0).

[DemonWasp]

Every time I think about what I would "fix" in Turing, I realize I'm rewriting Python, a language I don't even know properly.

1. Native lists, sets, maps; ex. set of int, list of double, map from string to myType, map from string to list of pointer to my_class. Plus, the ability to insert "sorted by X", for X either a comparison method or "insertion order" for maps / sets, etc.
   
2. For-each, with automatic type resolution: for x : list, for y : set, for x : list descending, for key, value : map
   
3. Ability to actually use library code (basically, fix import, include and so forth so there's a reasonable system for dependencies).
   
4. Threads / concurrency (preferably, the "teaching" set of concurrency constructs, as seen in uC++, rather than the "practical" set as seen in most other languages).
   
5. Better handling of multidimensional arrays. Either go the full C/C++/Java route and have arrays be pointers/reference objects, or else go the MATLAB route and have the ability to slice, dice and multiply arrays / matrices / etc.
   
6. Ability to specify subsets of the language for different skill levels / grades, so your teacher can force you to (for example) implement lists and sorts and maps and locks on your own.
   
7. Enumerations.
   
8. Remove raw pointers, replace by references in every case.
   
9. Remove / deprecate manual destruction, preferring either RAII or GC. Maybe both.
   
10. Multi-return: return 0, -1 from a function allows you to say: var a, b : int := my_function() and get a = 0, b = -1. Similarly, var arr: array 1..2 of int := my_function(2); could give you arr[1] = 0, arr[2] = 1.
    
11. Labels, break-to-label.
    
12. Working debugger.
    
13. Replace "elsif" by "else if" in all cases.
    
14. Replace "result" by "return" and "return" by "quit program".
    
15. Allow "fcn", "proc", "function", "procedure", but don't actually restrict them to void/non-void: just let the code work. Similarly, "end proc" is way better than "end my_stupid_function_name".
    
16. Allow C-style declarations ("int foo;" instead of "var foo : int")
    
17. Fix the hideously broken OO mechanism.
    
18. Increment / decrement operators (but instead of throwing words like "undefined behaviour" everywhere like C/C++ do, follow Java's example and specify it).
    
19. Error messages should link to help site / tutorials.
    
20. Cross-platform.
    
21. Infinity points for integration of database access.
    
22. Infinity points for integration of OpenGL / OpenCL / OpenAL access.
    

Greedy, I know. It looks like I want a cross between Java and Python. Maybe I should try learning Scala.

Array bounds: An array in a C-style language can be created with an arbitrary lower bound by allocating memory, then adding lower_bound * sizeof(entry) to it. Then, if byte my_array is allocated from 0x08 to 0xF, but has my_array = 0x0A, you can access my_array[-2] and it will be the first element. Array my_array effectively has bounds [-2, 6).

Allowing bounds to be an arbitrary range [lower, upper] rather than fixed range [0, size) or [1, size], is purely syntactic sugar. I find that [0, size) makes sense nearly every time.

[Amarylis]

For me, allowing overloading of procedures and functions would make my life infinitely easier, also eliminating the array bound requirements of function return types

[mirhagk]

@Demonwasp a good list of changes, a few points on some of them though,

10: Really allowing Tuples would solve this issue, or anonymous types. Having something like:

Turing:

fcn Foo():Tuple(2) return 10,20 end fcn var a:=Foo() put a[0] put a[1]

Would be sufficient for those purposes, but once you add Tuples you could go one step further and provide some syntatic sugar for the following:

Turing:

fcn Foo():Tuple(2) return 10,20 end fcn var a,b:int (a,b)=Foo()

Which would be quite awesome. I agree with some of those points (like return,result,quit thing, and the end fcn instead of end fcn_name). However some of them could be very useful. For instance allowing var a:int instead of int a allows you to not have to specify the type name, which while just convient for certain things (basically not having to write out long names), could be extremely powerful with anonymous classes and types (and could be quite amazing if you included a smart IDE with auto-completion, being able to experiment with the output of an unknown function without having to look it up).

One of the most important things for me would be the ability to call functions in compiled dll's (or the linux/mac equivalent) which would then make it possible to link in anything you wanted from another language (database access, OpenGL, OpenCL, OpenAL, better networking, threading, or whatever you need).

One way a lot of these could be implemented in one fell swoop (specifically better OOP, garbace collection, dll access, working debugger) is by compiling not to machine code, but to CIL, or Java bytecode (both of which would also make it cross-platform, well if you make the CIL mono compliant)