NewsForumsCodeLogsGallerySpecsSearch

NG does not play nice with function references

BlitzMax Forums/Brucey's Modules/NG does not play nice with function references

FireballStarfish(Posted 2016) [#1]
Hi!
I am new to BlitzMax-NG and, in a way, to this forum, seeing as this is my first post here.
I've used BlitzMax for years and been interested in NG for a while. Now I've finally gotten around to trying it out and found a couple bugs I'd like to report. I'm not sure if there's a list of known issues anywhere, as I haven't found one. But I see a bunch of other threads reporting NG problems in here, so I assume this is the right place.
I am using the BlitzMaxNG_win32_Unoffical_0_77 package from http://www.bmx-ng.com, with the newest bmk and brl modules from github.


I found NG seems to have quite a lot of trouble with data types representing functions.

Here's a simple example:
SuperStrict
Framework BRL.StandardIO

Local func(str:String) = Print
func "hello"
This code declares a local variable "func" of the type "(s:String)" - a function that takes one String parameter and returns nothing. Then Print gets assigned to this variable and called with a string literal. The official BlitzMax compiler considers this a valid program that prints "hello"; NG however refuses to compile it, saying "Unable to convert from Int(String) to (String)". This is a difference between vanilla BlitzMax and NG which I assume might arise from BRL.StandardIO being written non-SuperStrict? While this seems easily fixable by changing the declaration to 
Local func:Int(str:String) = Print
, it can be more complicated in practice. One might, for instance, want to exchange Print with DebugLog (consider a program like the one in the next codebox below). This is trivial in vanilla, but in NG it suddenly becomes impossible, because although Print returns Int, DebugLog returns void and so you cannot declare a variable with a type that matches them both.


There are more problems:
SuperStrict
Framework BRL.StandardIO

Local func:Int(str:String) = GetPrint()
func "hello"


Function GetPrint:Int(s:String)()
	Return Print
End Function
This time we don't assign Print to our variable directly, but instead call a function that returns it. Thus GetPrint gets two sets of parentheses. The first one is part of "Int(s:String)", the signature of Print (which should actually just be "(s:String)", see above issue). The second one is the empty parameter list of GetPrint itself. This is valid BlitzMax, but NG refuses to compile it because it gets confused about the many parentheses. EDIT: This works as of July 4th 2016, however trying to assign GetPrint to a local variable still leads to a compiler error:
Local printprovider:Int(s:String)() = GetPrint



EDIT: The following issues seem to have been fixed as of July 4th 2016.

Another program that doesn't compile in NG:
SuperStrict
Framework BRL.StandardIO

Local funcs(str:String)[] = [DebugLog, RuntimeError]
funcs[0] "hello1"
funcs[1] "hello2"
At first it says "Expression can not be used as a statement". When this is fixed by adding parentheses around the string literals (which is not necessary in vanilla), it complains about missing function parameters for DebugLog and RuntimeError, thinking their appearance within the array literal declaration are supposed to be calls.


And finally, here's a particularly odd one:
SuperStrict
Framework BRL.StandardIO

Local funcs:Int(str:String)[ ] = Null

funcs = funcs[..1]
funcs[0] = Print

funcs[0]("hello1")
"Expecting expression but encountered '='". Okay, let's try remove the Null assignment then, it isn't strictly necessary after all:
SuperStrict
Framework BRL.StandardIO

Local funcs:Int(str:String)[ ]

funcs = funcs[..1]
funcs[0] = Print

funcs[0]("hello1")
"Slices can only be used with strings or one dimensional arrays" But this IS a one-d... nevermind, let's do this then:
SuperStrict
Framework BRL.StandardIO

Local funcs:Int(str:String)[ ]

funcs :+ [Print]

funcs[0]("hello1")
"Unable to convert from Int(String) Array to Int(String) Array." Huh.
Turns out, all this is caused by the extra space between the brackets in the declaration of "funcs". Unlike vanilla, NG takes offense at any whitespace between those. This took me a while to figure out :)


Apart from these, I encountered a few other issues while trying to port a larger module from vanilla Bmax to NG. These were weirder - generating faulty C code or crashes - which is I haven't managed to track them down and make them reproducible with a small code snippet, unfortunately.
Despite all this, I am quite impressed with NG. I hope it'll see further development and that this will help improve it :)


GW(Posted 2016) [#2]
Part of the errors you're seeing come from the fact that Brucey broke backwards-compatability with vanilla Bmax about a month ago, disabling primitive type conversions and such.
This really borked several of my projects and now I'm stuck with using the properly working version of NG from Febuary. I can provide a download link if anyone needs it.


FireballStarfish(Posted 2016) [#3]
I don't think that's the cause, plus primitive conversions seem to be working just fine for me, "Local x:Int = 5.5" for example does the same as in vanilla. The only thing I've noticed is that calling a function with a parameter requiring an implicit conversion (like passing a Float into a function that takes an Int) spits out a compiler warning. I can indeed turn that into an error by disabling "Overload warnings" in MaxIDE, but if I don't, it compiles and runs normally as far as I can tell.
Or did you mean something else?


Derron(Posted 2016) [#4]
No he meant exactly that.

Overload warnings..brings back old behaviour but outputs hints to make things more futureproof (keeping the overloading feature in mind)

Bye
Ron


FireballStarfish(Posted 2016) [#5]
Any news on this? Is this not gonna get fixed anytime soon? Considered low priority? Just some quick response would be nice.


Derron(Posted 2016) [#6]
double post (because of double-edit).


Derron(Posted 2016) [#7]
I think sometimes Brucey just does not see all bugs reported here.


If you think all issues are connected to each other: report them as one issue. If you think they are separate: report in multiple issues.


If you do not have a github account, drop a line and I will try to open up the issues for you.


bye
Ron