Yet Another Language Feature wishlist

Monkey Archive Forums/Monkey Discussion/Yet Another Language Feature wishlist

Nobuyuki(Posted 2013) [#1]
Hello hello, I didn't want to messy up Shinkiro's thread on Monkey productivity increasers with my language feature requests, since he specifically requested that this not happen, but as it would happen I ended up writing a bunch of these out anyway and thought "why let all that text go to waste"? Anyway, so, here's another thread where we can talk about our pet language features we wanna see in Monkey, and perhaps how we would use them if they were available.

I will try to stick to core additions to the language, and avoid feature requests on mojo. It would be nice to see a thread just about core monkey/brl stuff, but we'll see how it goes! And now, without further ado:

* Generic Interfaces. This one's probably big. Once this is in, we can probably do a lot of things. Like improving the standard libraries and container classes, introducing a more thorough and extendable hierarchy. I hear Mark's working on this one right now.

* TypeOf/typeid/Is operator. Using TypeOf would be nice for a lot of things; assigning a type, comparing types, etc. Basically, reflection lite. Having type introspection without having to import reflection allows trans to still optimize-out unreachable code while giving us one of the nicer things reflection also gives us. Some examples:

* Async support as a first-class citizen of Monkey. A way to define methods as asynchronous with a piece of complimentary syntax (Like VB.NET's new Await operator) which would let us assign values from asynchronous methods in an imperative manner, pending successful completion of the async method. For example,
Field MyImage:Image = Await LoadImageAsync("default.png")

MyImage returns NULL until LoadImageAsync() has done its job. VB paired this with a function modifier called Async which, along with our friends Property and Abstract, would fit in just fine with Monkey syntax.

For how .NET does this, see here:
Very cool.

* More syntactic sugar with Select statements. Previously, Select broke when combined with Generics, so I'm a bit wary to use it in lieu of Elseif statements, as it provides little syntactic sugar as-is. VB.NET extends Case syntax with the Is operator by allowing shorthanded expressions and comparing to those which evaluate to True, such as "Case Is > 5". However, lexically, this is not the same type of comparison Is makes in other situations, . This can be resolved by changing the syntax to something like this:

  Select something  'Evaluates until reaching the first True statement
    Case 1  'Equals is implied for backwards compatibility
    Case = 2
    Case > 5 
    Case = -50 To -10
    Case <> 0 And Case > -100  'Either 0 or less than -100
    Default  'Between 0 and -100, unless it's from -50 to -10
  End Select

Edit: Regarding the syntax, the keyword Case would be substituted for the expression (in this case, something) at compile-time and evaluating for True. VB.NET syntax might still make more intuitive sense here, if multiple evaluations are separated using commas instead of logical ops, but would still not be lexically equivalent to the aforementioned Is operator. eg:
Case 1 To 4, 7 To 9, 11, 13, Is > maxNumber

AdamRedwoods(Posted 2013) [#2]
RE: TypeOf
can't this be done with Casting(something) and checking against null? I don't see the advantage.

RE: Async
sounds great. not sure how this would be implemented in a cross-language environment, though. i just use a loop and a flag with miniB3D async loading.
in your example, wouldn't you still have to check if MyImage is null before allowing drawing? does it auto-assign later or do we need to keep calling LoadImageAsync?

RE: Select
I agree with this, it would be nice!

AdamRedwoods(Posted 2013) [#3]
My current wishlist is:

- Better 3rd party integration. Add #CC_LIBS as described in my GitHub comment (would allow wxMonkey without trans compilation).
- Extern New(args) support. even if it was only Method New()="CreateThis" support.

...not so much language features but Mojo:
- Mojo rgba4444 (DXGI_FORMAT_B4G4R4A4) and rgb565 internal textures all targets. (great for mobile, desktop for testing)
- Mojo desktop PNG4 support (i submitted picopng to Monkey already)
- Mojo glfw3, with desktop features (borderless windows, clipboard)

dragon(Posted 2013) [#4]
TypeOf is possible with casting:
If MyClass(MyObj) Then Print "Goal"

Async/Await look dangerous to me...
btw: why we get error at DrawImage(null), but not PlaySound(null) ?
DrawImage should safe as possible - accepting null

rgba4444 / 565 is very useful

Gerry Quinn(Posted 2013) [#5]
I'd like a Protected access qualifier to replace Private so that we could for example get at nodes when we want to extend List.

Goodlookinguy(Posted 2013) [#6]
My wishlist at this point is pretty small: Operator overloading and anonymous functions. Both would be a great asset to Monkey and are both extremely possible with the way Monkey translates.

Edit: Oh yeah, agree with the person above. A Protected keyword would be great. I still think Private should be there, but Protected could be added alongside it.

Nobuyuki(Posted 2013) [#7]
Are casting operations defined in a cross-platform way? I thought on some platforms, casting is implementation-specific and such behavior shouldn't be relied upon. Casting objects is black magic as far as I'm concerned.

Task-based Async operates by having some sort of layer over a Task-based interface system in .NET. Await combined with a call to a function with the Async modifier seems to hint to the compiler to unroll something behind the scenes which handles the actual asynchronous methods and sends the appropriate contents back to the variable being assigned the result of the task. The link on Task return types below explains it more, it sounds like some sort of variation auto-unboxing, which Await invokes. In Microsoft's terminology, "The task is a promise to produce an actual [returnType] object after the requested data has been downloaded and the task has run to completion. To retrieve the [returnType] value from the Task, apply an Await operator to the call."

On my initial glance, it appears to be a very glossy layer of sugar over an extremely common scenario where async would be used. However, I'm not familiar with typical asynchronous usage patterns. Here is more info on this feature: about task-based asynchronous patterns about the Task<T> return type and how the Async keyword works magic on Return syntax how control flow occurs with this usage pattern

The implementation would most likely heavily lean on brl.thread. And yes, you'd still have to check for Null, unless you adapt the control flow in such a way that your main execution block depends on the tasks' completion or timeout, or set it to something else first with a blocking call. These are the typical cases in almost every scenario, either a loading bar where the main thread isn't blocked by heavy asset pulls, or a placeholder image being shown while the asset's being loaded.

For example:
'In the init method....
placeholder = LoadImage("Default.png") 'Blocking call
img = placeholder

img = Await LoadImageAsync("BigFile.png")

'In the render method.....
DrawImage(img, 8,8)   'Will draw placeholder until LoadImageAsync() returns

@Gerry Quinn
I'd love Protected as a directive, too.

ImmutableOctet(SKNG)(Posted 2014) [#8]
I honestly think templates/generic classes need their own form of preprocessor. But on the topic of the casting work around, this doesn't work with non-object types. If you attempt to cast your template/generic class's type as an 'Int', 'Float', 'Bool', or 'String', you will be given an error at compile-time, not runtime. The only other solution I can think of is allowing us to check if something is an 'Object' by casting it as such:

The lazy way to make this work for trans without any major edits is to convert all template/generic-class related lines with the non-object types on them to their object-wrapper counterparts (List<Int> to List<IntObject> for example), but that sounds terrible (Not to mention a debugging nightmare). But the whole idea of "We should check on runtime what should be checked on compile-time" seems like it'd be horribly inefficient, not to mention bad practice for such a basic check.

In terms of main features I'd like to see, here's the main few that seem viable:

* Protected: The fact that this isn't already a part of Monkey is sad, here's my thoughts on it.

* A preprocessor for templates/generic classes (As stated above):
Perhaps with a '$' prefix, instead of '#'?

* Optional stack allocation of classes, or at the very least structs:
This would be very nice to have, and it's not like you can't make things heap-allocated on targets which hate the stack. Everything is garbage collected in Monkey anyway, it's not like there's a real difference to the user. Plus, this would make threads a bit more friendly on some targets.

* Some form of template/generic-class support for reflection. (This drove me crazy at one point)
* Template/generic functions, so I don't have to make a new class for every function (Or group of functions). (Even C# has that)

By the way, am I the only one who misses 'Preview' when making a forum post? And on the topic of the forum, why can't I search through people's posts like I used to? (Or at the very least my own) At least make it so I can search the forum without an input if I have a username.

Paul - Taiphoz(Posted 2014) [#9]
Loading Bar's : I would love to see a monkey standard loading system which presents a nice themeable loading bar with the monkey logo on it, this would apply to all targets but some would use it less like html5, even that would use it when loading stuff on the fly.

Improved DrawText: I would like to see DrawText get an overhaul so its a bit more feature rich, things like wordwrapping, scrolling , alignment etc.. and the ability to load custom fonts.

More Single Target Focus: - Mark already has some 3D support on the roadmap which is cool, and i cant wait, but I would also like to see more work done on Target specific features, personally I would like to see more work done on Android specific services and features, but the other targets could use some 1 on 1 time as well.

IDE: I know this isnt a code thing, but I would love more work done on the ide to really bring it on par with Jungle, not only would this be good for the community but it would also pressure ziggy to make jungle even better, so its win win for us, personally I would love to see some more asset managment type stuff, the IDE's know where we put all our assets, .data folders so it should be a relativly easy thing to make the IDE seek that folder and manage whats inside it, things I would like to see here would be the ability to flag files for include or exclude when building, allowsing us to keep our wip art and sound in there while in development but only have it copy over to the build folder when were actually using it in the project, the ability to preview images and get basic information from them, like position of the mouse as it hovers, possibly the ability to frame out image strips, same goes for audio having a little play button where we can get a clip of what the auido sounds like would be nice, finally the ability to move things around, rename , edit, delete, with edit opening a pre selected default editor.

ElectricBoogaloo(Posted 2014) [#10]
NO!!! Leave my IDE alone!! Grrrrrr!!!!
I'm happy with the IDE as-is, and it's good that there's other options out there for those who aren't.
Best of both worlds, IMO.

Image quads would be a nice addition (or whatever it is you call it when you suggest 4 co-ordinates, and it drawn the image within those points!)
I've come across a few occasions where that'd be something helpful, but it's more low-level than I typically like to delve.

AdamRedwoods(Posted 2014) [#11]
- an asset packer for desktop. need a way to wad up those files. it could be done with the DataBuffer class and some new wrapper functions for images and sound. the WAV loader would need some memory routine lovin', instead of strict fread()'s.

Re: Compile-time type checking...
To me, that sounds like it would be non-trivial to implement. The only way I can think of off the top of my head is to create different versions of a generic class to handle each type differently. seems a little bloated.

run-time checking seems ok for now, this post and Samah's brilliant answer seems to be the best solution thus far:

ziggy(Posted 2014) [#12]
For me it is Delegates. I would kill for propper delegates support.

maltic(Posted 2014) [#13]
In descending order...

Protected access modifier.

Don't force objects to have an implicit New() method.

Generic Interfaces.

Improved DrawText.

ElectricBoogaloo(Posted 2014) [#14]
Oooh, just thought of something..
Tweak the GLFW compiler stuff so it can add icons!

dragon(Posted 2014) [#15]
i think Bluetooth + WLAN is a very important feature