PureBasic Forums - English

IdeasVacuum wrote:Thanks Demivec, in fact I do exactly that in another app - but solutions for Val() as it is now was not my interest when I started this post - it was about the design of the function. I've asked if a 3-wheeler car would be better with 4 wheels, but all the responders defend the 3-wheeler as if their life depends on it

@IdeasVacuum: I know you didn't want 'solutions' but instead a remedy. I provided the example for two reasons. The first was to show that it was possible to return another value and second, that this value had to be selected from the range of the output which produced its own problems (Danilo points these out).

I had neglected to extend the example to actually meet your needs by changing the range of the output :

Hi Demivec

Well no, I wasn't looking for a remedy either, I was simply asking if others agreed that the design of the Val() function could be better than it is..... maybe the English language needs an enhancement too

I do think your remedy delivers a more logical result though. I wrote a similar sort of thing for a bespoke macro language (CAD app).

IdeasVacuum wrote:Well no, I wasn't looking for a remedy either, I was simply asking if others agreed that the design of the Val() function could be better than it is..... maybe the English language needs an enhancement too

It's unfortunately not about whether or not Val should be improved in the manner you desire, but whether it can be improved in the manner you desire.

The function returns an integer. Integers cannot represent the results you desire unless you select arbitrary sentinel values. There are no sentinel values that could be expected to never arise in real use.

As long as it remains a function that returns an integer, it must always return a number. It cannot not do so. What you want is simply not possible. The only way to return those values is for the return of the function to be a float or double.. and we have functions for that already.

I think a strong case can be made that ValF("") and ValD("") should return NaN.

I understand the OP's reasoning for Val("") returning NaN but it is not possible given the requirement that any integer returned be valid.

chris319 wrote:I think a strong case can be made that ValF("") and ValD("") should return NaN.

I understand the OP's reasoning for Val("") returning NaN but it is not possible given the requirement that any integer returned be valid

I agree with this, even though I know I have old code that relies on Val/ValF returning 0 for empty strings

Although in any situation where valid numeric strings are critical, they should be safely checked with a RegEx or one of the many IsNumeric() procedures, before being processed.

This is where I really have a problem with PureBasic and is one of the reasons I haven't bought a copy.... yet.

Every other BASIC I ever used, never split VAL() the way PureBasic does.

I mean really why the deviation? VA() VALF() VALD()...

It's counter intuitive...

jmcbride wrote:This is where I really have a problem with PureBasic and is one of the reasons I haven't bought a copy.... yet.

Every other BASIC I ever used, never split VAL() the way PureBasic does.

I mean really why the deviation? VA() VALF() VALD()...

It's counter intuitive...

That's a pretty feeble excuse for not using PB.

I've been using BASIC since 1965 on mainframes, minis, and micros, and every implementation is different. PureBasic is actually one of the better BASICs. It's cross-platform, it generates fast code, it has all kinds of nifty built-in features, it integrates well with code written in other languages, and contrary to popular opinion it's pretty good at creating OOP code.

After 50 years of programming I have chosen to convert several million lines of Assembler, COBOL, VB, and PowerBasic code into PB. That either says a lot for PB or the state of my mind.

As for whether VAL() should be changed, I suspect it's best left as is, and any special end-condition usage handled in user code.

jmcbride wrote:I mean really why the deviation? VA() VALF() VALD()...

Type casting is a challenge that can be handled in a large variety of ways. PB is consistent at making type-dependant commands have a command variation for each different type, by by appending the type to the command. For instance Val for quads (really, all integers, because a quad can easily be truncated to any other size of integer), ValF for floating point, and ValD for Double Value fp's (these last two cannot have bytes simply truncated to reduce the storage size). Take a look at the list for PEEK and POKE, if you think the three for Val is too much!

Anyway, if the compiler does NOT have some method of handling the variety of types, then it must choose one type to return, and that means it will be unnecessarily slow. That, or you may have to manually do conversions yourself. Every method has its own pros and cons.

Having said that, PB is very different from 80's basics (Having numerous variable types is just one new thing!). Many of us who have come to PB after experiencing a different flavor of Basic have created macros to try to mold PB to fit our past Basic Language experiences...but after a short while, the new syntax becomes second nature. Heck, I even forgot I did that until a month ago when I was looking at some of my first PB code. Point is, your attitude is kind of throwing the baby out with the bath water. If such a tiny variation is throwing you off base, then you should probably consider returning to your old Basic--there will be quite a few things you have to get used to, and trust me--ValF (as simple as it is) will NOT be the most challenging.