Text Only | Text with Attachments

QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: FellippeHeitor on October 29, 2020, 12:13:40 pm

Title: DIM syntax from FreeBASIC
Post by: FellippeHeitor on October 29, 2020, 12:13:40 pm
How outraged would the community be if we borrowed the alternative syntax of DIM from FreeBASIC, so that instead of:

Code: QB64: [Select]

we could:

Code: FreeBasic: [Select]
  1. DIM AS INTEGER a, b, c

As per https://www.freebasic.net/wiki/KeyPgDim

Note that there's nothing being developed in that direction, but it's something that's been in my mind for a while now.

Also notice that it wouldn't be incompatible with former programs, since the existing syntax would remain untouched.

Also notice that both syntaxes can co-exist.

Also notice I haven't checked our DIM parser for the feasibility yet, so this could all be hypothetical in the end.

Let me hear from y'all.
Title: Re: DIM syntax from FreeBASIC
Post by: bplus on October 29, 2020, 12:23:52 pm
@FellippeHeitor   I would love that! I wish I could do that about every time I start using OPTION _EXPLICIT

EDIT the rest:

Never mind I just looked at your syntax again ;-))
Title: Re: DIM syntax from FreeBASIC
Post by: RhoSigma on October 29, 2020, 12:27:16 pm
I guess many people will love it, cause it saves a lot of keystrokes if somebody wanna go the "written" type way. For me personally it won't make any difference, as I'm a hardcore type suffix user.
Code: QB64: [Select]
  1. DIM a%, b%, c%
  2. 'or even different types in the same DIM line
  3. DIM i%, l&, s!, d#, t$
Title: Re: DIM syntax from FreeBASIC
Post by: bplus on October 29, 2020, 12:31:05 pm
Yeah, if it doesn't make old code bad, steal away!
Title: Re: DIM syntax from FreeBASIC
Post by: Dimster on October 29, 2020, 01:15:48 pm
I'm not familiar with FreeBasic and your link to same did answer my thoughts on SHARED but I can't seem to find REDIM in FreeBasic. Do you think there could be an issue with Re dimming a FreeBasic Dim'd variable?
Title: Re: DIM syntax from FreeBASIC
Post by: FellippeHeitor on October 29, 2020, 01:22:18 pm
No issue at all.
Title: Re: DIM syntax from FreeBASIC
Post by: SMcNeill on October 29, 2020, 01:26:38 pm
I’ve always thought something similar would be nice, but I think it could be a little closer to our existing syntax to use with a few parentheses.

Instead of:

DIM AS INTEGER a, b, c

How about:

DIM (a, b, c) AS INTEGER, (d, e, f(10)) AS SINGLE

You’d basically define blocks of variables, delimited by parentheses, all as an unique variable type.
Title: Re: DIM syntax from FreeBASIC
Post by: FellippeHeitor on October 29, 2020, 01:27:23 pm
It'd work too. Whichever would be easier to parse internally, really.
Title: Re: DIM syntax from FreeBASIC
Post by: SpriggsySpriggs on October 29, 2020, 01:30:08 pm
Sure! I don't see any problem with that.
Title: Re: DIM syntax from FreeBASIC
Post by: Dimster on October 29, 2020, 01:31:13 pm
It's ok I found Redim info in FreeBasic
Title: Re: DIM syntax from FreeBASIC
Post by: Petr on October 29, 2020, 01:32:48 pm
I'm also for.
Title: Re: DIM syntax from FreeBASIC
Post by: FellippeHeitor on October 29, 2020, 02:43:02 pm
True!
Title: Re: DIM syntax from FreeBASIC
Post by: Bert22306 on October 29, 2020, 06:13:25 pm
I don't know if there's an advantage to create a syntax exactly like FreeBasic's, or more similar to C, because otherwise, Steve's idea would be easier to adapt to.

DIM (a, b, c) as _FLOAT, (d, e, f) as DOUBLE

Also DIM SHARED, of course, same way.

It's more like what we do now, but without all the repetition. Yes, this seems like a useful improvement to me too.
Title: Re: DIM syntax from FreeBASIC
Post by: johnno56 on October 29, 2020, 06:27:53 pm
I think that the change makes 'Dim' simpler to use. My only niggling concern would be, are the changes being made to make QB64 more efficient or to make QB64 more like FreeBasic? Just a thought...
Title: Re: DIM syntax from FreeBASIC
Post by: TempodiBasic on October 29, 2020, 07:52:00 pm
Hi
this kind of perspective to let more easyness to type is powerful!
With Steve's structure maybe that it is easy to manage the syntax by Parser.

At first time to avoid these writing  I used to put suffix to variables
but with new QB64 types I  don't like mystyping the suffix  like for example  an _UNSIGNED LONG  becomes a LONG
so I have put in working the keyword  DEFINT DEFSTR DEFDBL DEFSNG...and in this direction there are the keyword of expansion _DEFINE! This solves with a workaround and limiting the firstletterofVariable.

This C like and Pascal like feature can be interesting, but is it  expanded to the parameter of the SUB/FUNCTION or there we must type type type like we do now?
Title: Re: DIM syntax from FreeBASIC
Post by: FellippeHeitor on October 29, 2020, 08:29:27 pm
Quote from: johnno56 on October 29, 2020, 06:27:53 pm
I think that the change makes 'Dim' simpler to use. My only niggling concern would be, are the changes being made to make QB64 more efficient or to make QB64 more like FreeBasic? Just a thought...

Changes would be made just to type less. Don’t overthink it :-)
Title: Re: DIM syntax from FreeBASIC
Post by: Pete on October 29, 2020, 08:45:03 pm
I'M OUTRAGED... YOU USED THE F-WORD!

Well just because I hate FB as a hole... I mean a whole, doesn't mean some parts of it are not worth a look. This DIM format is a good example. I'm for it.

Pete
Title: Re: DIM syntax from FreeBASIC
Post by: johnno56 on October 29, 2020, 09:19:19 pm
Fillippe,

I think the change is a good one. But I'm reminded of the old question "How do you eat an elephant?" "One bite at a time."
This time, 'Dim' is changed, one bite. Eventually the elephant will be unrecognizable... But that's just me... over-thinking is what I do... lol

Pete,

If, I had been aware of your dislike of FreeBasic, I would not have used the word FreeBasic... lol (I'm not a fan of FreeBasic either...)
Title: Re: DIM syntax from FreeBASIC
Post by: Cobalt on October 29, 2020, 09:45:42 pm
Nay says I.

So I'm the only one who doesn't care for it I guess.
Title: Re: DIM syntax from FreeBASIC
Post by: Pete on October 29, 2020, 10:17:35 pm
Quote from: johnno56 on October 29, 2020, 09:19:19 pm

Pete,

If, I had been aware of your dislike of FreeBasic, I would not have used the word FreeBasic... lol (I'm not a fan of FreeBasic either...)

I forgive you, because you included an elephant joke... which reminds me. Why do jungle ducks have flat webbed feet? To stomp out flaming jungle fires. Why do elephants have big flat feet? To stomp out flaming jungle ducks.

As if Cobalt didn't feel bad enough about this thread, already. :D

Pete
Title: Re: DIM syntax from FreeBASIC
Post by: johnno56 on October 30, 2020, 12:27:33 am
Thanks Pete! It took me over half a century to forget the 'flat webbed feet' joke! Looks like I will be taking it to my grave... *sigh*
(but the flaming ducks IS a classic! lol)
Title: Re: DIM syntax from FreeBASIC
Post by: Unseen Machine on October 30, 2020, 03:28:38 am
@Fellippe

It sounds fine to me but i'd much rather see type definitions that support arrays and have the broken linking to external libraries issue sorted out before you go adding features that do nothing for the languages capabilities. Also, if your thinking about adding stuff, are enumeratioun blocks possible!

Unseen

P.s. FB Sucks!
Title: Re: DIM syntax from FreeBASIC
Post by: luke on October 30, 2020, 03:49:05 am
I intensely dislike the parenthesisation approach for some reason.

The DIM AS INTEGER X, Y, Z is fine. Parser-wise it should just checking if the second element is AS, then copying the code that does the list parsing.
Title: Re: DIM syntax from FreeBASIC
Post by: Richard Frost on October 30, 2020, 04:10:07 am
It'd be a nice addition, but the variable type _BITCOIN would be better.
Title: Re: DIM syntax from FreeBASIC
Post by: FellippeHeitor on October 30, 2020, 05:42:08 am
Quote from: Unseen Machine on October 30, 2020, 03:28:38 am
@Fellippe

It sounds fine to me but i'd much rather see type definitions that support arrays and have the broken linking to external libraries issue sorted out before you go adding features that do nothing for the languages capabilities. Also, if your thinking about adding stuff, are enumeratioun blocks possible!

Unseen

P.s. FB Sucks!

Unseen, I understand your beef. But not implementing this won't make me automatically know how to implement your long awaited features, which are beyond my abilities.

All the changes required to implement this will be done on the .bas source, while any of your wishes would require c knowledge, which I only scratch.

I take this as a vote in favor.

I take the thread as a vote in favor too.

As I mentioned in the first post, there isn't even guarantee it will make it to the code base any time soon either.

To those against, I remind you it won't ever affect you if it gets added.

Thanks to all for chiming in.

PS: Pete was my worst fear and who I'd see ever getting outraged :-D - this thread was started with mostly you in mind.
Title: Re: DIM syntax from FreeBASIC
Post by: Unseen Machine on October 30, 2020, 06:47:13 am
Quote
Unseen, I understand your beef. But not implementing this won't make me automatically know how to implement your long awaited features, which are beyond my abilities.

Fair enough but i think you are under rating yourself mate.

With your new way would this be allowed?

TYPE aType
 X, Y, Z AS Single

Unseen
Title: Re: DIM syntax from FreeBASIC
Post by: FellippeHeitor on October 30, 2020, 06:49:20 am
There's a lot to consider beyond DIM/REDIM: TYPEs, SUB/FUNCTION parameters, DECLARE LIBRARY blocks, STATIC, SHARED, all scattered. Not gonna be an easy task when undertaken.
Title: Re: DIM syntax from FreeBASIC
Post by: bplus on October 30, 2020, 12:01:59 pm
Quote from: luke on October 30, 2020, 03:49:05 am
I intensely dislike the parenthesisation approach for some reason.

The DIM AS INTEGER X, Y, Z is fine. Parser-wise it should just checking if the second element is AS, then copying the code that does the list parsing.

It's also more typing.

But if you write a new FUNCTIONs? INTEGERS(a, b, c(), z... ) might be easier to add?

Oh what about UDT's?

DIM AS UDT  a, b c(), z
probably going to be difficult also.

Does OPTION _EXPLICIT check some kind of array list or lists?
Title: Re: DIM syntax from FreeBASIC
Post by: Pete on October 30, 2020, 01:05:04 pm
Quote from: FellippeHeitor on October 30, 2020, 05:42:08 am
PS: Pete was my worst fear and who I'd see ever getting outraged :-D - this thread was started with mostly you in mind.

I figured as much. I hope my reply didn't knock you too far off your chair. The fun in being a forum admin is to see how many times you can "ask" the members these types of questions, while preventing an all out uncivil war. Kudos, you did a great job with this one. Also kudos from the old guard for keeping QB64 more of an updated version of QuickBASIC. I never felt like I had to abandon it to learn something new. You need FreeBASIC for that! Oops, now you've got me using the F-word.

Pete
Title: Re: DIM syntax from FreeBASIC
Post by: FellippeHeitor on October 30, 2020, 01:07:32 pm
❤️
Title: Re: DIM syntax from FreeBASIC
Post by: Dav on October 30, 2020, 01:42:32 pm
Chiming in a little late here, I wouldn't be bothered by seeing this DIM usage option added.

- Dav
Title: Re: DIM syntax from FreeBASIC
Post by: Bert22306 on October 30, 2020, 05:21:06 pm
Quote from: luke on October 30, 2020, 03:49:05 am
I intensely dislike the parenthesisation approach for some reason.

The DIM AS INTEGER X, Y, Z is fine. Parser-wise it should just checking if the second element is AS, then copying the code that does the list parsing.

Hmmm. Coming from Luke, this is disconcerting. Not sure you dislike parentheses, but the advantage would be, you can put more in a single DIM statement? If you say DIM AS INTEGER, then everything in that DIM statement must be INTEGER.

I have multiple lines of DIM in many of my programs, so this idea sounds really useful to me. I was going to put that sentence in parentheses, but now I hesitate!
Title: Re: DIM syntax from FreeBASIC
Post by: FellippeHeitor on October 30, 2020, 05:31:27 pm
Code: QB64: [Select]
  1. DIM AS INTEGER a, b, c, AS SINGLE d, e, f

I believe the above would be valid.
Title: Re: DIM syntax from FreeBASIC
Post by: luke on October 30, 2020, 07:15:03 pm
Quote from: Bert22306 on October 30, 2020, 05:21:06 pm
I have multiple lines of DIM in many of my programs, so this idea sounds really useful to me. I was going to put that sentence in parentheses, but now I hesitate!
What Fellippe said, though people who put too much on one line tend to have something to hide (especially those who use colons...).

Also I worked out why I don't like it, aside from the extra syntactic noise: it looks like you're declaring a tuple, not multiple separate variables.

You can't have this in function signatures because the comma becomes ambiguous:
Code: [Select]
FUNCTION f(AS INTEGER a, b, c) is c integer or single?

Ironically the parenthesised approach would be unambiguous here:
Code: [Select]
FUNCTION f((a, b) AS INTEGER, c)but I still think this looks like some kind of compound object/type.


Type declarations are unambiguous:
Code: [Select]
TYPE t
    AS INTEGER a, b, c
END TYPE

And STATIC & SHARED should follow same semantics as DIM.
Title: Re: DIM syntax from FreeBASIC
Post by: FellippeHeitor on October 30, 2020, 07:16:45 pm
Life will be easier if FUNCTIONs (and by extension DECLARE LIBRARY blocks) are excluded from this.

@Dav thanks for chiming in!
Title: Re: DIM syntax from FreeBASIC
Post by: SMcNeill on October 30, 2020, 08:01:14 pm
Quote from: luke on October 30, 2020, 07:15:03 pm

You can't have this in function signatures because the comma becomes ambiguous:
Code: [Select]
FUNCTION f(AS INTEGER a, b, c) is c integer or single?

c would be an INTEGER as it’s right of the AS INTEGER syntax, just as with a DIM statement.

DIM AS INTEGER a, b, c <— all these would be integers, so why not with the FUNCTION?

FUNCTION f(AS INTEGER a, b, AS SINGLE c) <— Wouldn’t this be the way to designate c as a single, if so desired?


Though still, I prefer the parentheses approach, just cause it’s closer to our existing syntax of TYPE after the VARIABLE.  DIM x AS type...
Title: Re: DIM syntax from FreeBASIC
Post by: FellippeHeitor on October 30, 2020, 08:02:29 pm
Let's see whatever's easier to parse.
Title: Re: DIM syntax from FreeBASIC
Post by: STxAxTIC on October 30, 2020, 08:30:16 pm
As Luke said (but using different words), whenever I see (a, b, c) in parentheses I see a vector, not a list of variables. Abusing parentheses for this might bite us down the road.

My main beef is in the ordering of tokens here.

This line looks normal:

Code: QB64: [Select]

... But this looks weird:

Code: QB64: [Select]

Because suppose I don't like "y" anymore, and delete it, then I just have:

Code: QB64: [Select]

Which is gonna be what, an error? Yuck. Propose this:

Code: QB64: [Select]

It looks better. On the left we have DIM, on the right we have the TYPE, and in the middle, the guts. It's especially less confusing than

Code: QB64: [Select]
  1. DIM AS INTEGER a, b, c, AS SINGLE d, e, f

Disgusting.
Title: Re: DIM syntax from FreeBASIC
Post by: FellippeHeitor on October 30, 2020, 08:33:36 pm
Code: QB64: [Select]

This would break compatibility with ourselves if suddenly that syntax turned x into an INTEGER, instead of a SINGLE. No deal.
Title: Re: DIM syntax from FreeBASIC
Post by: STxAxTIC on October 30, 2020, 08:34:26 pm
So it won't work because it's not implemented yet. Check.
Title: Re: DIM syntax from FreeBASIC
Post by: FellippeHeitor on October 30, 2020, 08:58:48 pm
Quote from: FellippeHeitor on October 30, 2020, 05:31:27 pm
Code: QB64: [Select]
  1. DIM AS INTEGER a, b, c, AS SINGLE d, e, f

I believe the above would be valid.

After further discussion (have you guys not joined http://discord.qb64.org yet?), the above would not be valid, so one single AS clause per line in the new alternative syntax.

Code: QB64: [Select]
  1. DIM AS INTEGER a, b, c ', etc...
  2. DIM AS SINGLE d, e, f ', etc...
Title: Re: DIM syntax from FreeBASIC
Post by: Aurel on October 31, 2020, 04:28:08 pm
In general i don't know DIM is used to declare/define variable it
SHOULD declare Dimension called array
so my question is why DIM is used for a simple variable?
Title: Re: DIM syntax from FreeBASIC
Post by: luke on October 31, 2020, 10:31:52 pm
1) UDTs
2) OPTION _EXPLICIT
Title: Re: DIM syntax from FreeBASIC
Post by: TempodiBasic on November 01, 2020, 01:05:08 pm
following Luke
3) no typing suffix
4)type of data BIT and _MEM have no suffix to declare them
http://www.qb64.org/wiki/Variable_Types (http://www.qb64.org/wiki/Variable_Types)

PS: Thanks to Fellippe to remember me the suffix of _BIT... ( watching at the above wiki table I have thought that the screen of my pc was dirty and that suffix was a piece of dust! LOL) so it lasts _MEM with no suffix to declare it
coding without suffix
Code: QB64: [Select]
  2. a = 10
  3. d = 3.5
  4. b = a/d
  5. c= STR$(b)

coding with suffix
Code: QB64: [Select]
  1. DIM a%,  b#, c$, d!
  2. a% = 10
  3. d! = 3.5
  4. b# = a%/d!
  5. c$= STR$(b)
  6. _PRINTSTRING(1,1) c$
  7.  
this last has an old fashion, but I must use so much SHIFT and or AltGrad on my keyboard...
let you imagine if you are working with handle of images or files, with color32bit, or memory address using _OFFSET, or big numerical data  using _INTEGER64 and _FLOAT...
Title: Re: DIM syntax from FreeBASIC
Post by: FellippeHeitor on November 01, 2020, 01:06:16 pm
_BIT data suffix is `
Title: Re: DIM syntax from FreeBASIC
Post by: SMcNeill on November 01, 2020, 01:07:29 pm
And ~’ for unsigned bits, and ‘n for number of bits.
Title: Re: DIM syntax from FreeBASIC
Post by: TempodiBasic on November 01, 2020, 01:15:07 pm
about syntax:
I find interesting the idea to use
Code: QB64: [Select]
  1.  DIM set of variables AS TYPE
, in this case DIM and AS TYPE work like {} of the other languages and for this reason for each AS TYPE must be typed a DIM... and this brings to a result similar to the discussion on Discord to let declare one type of data for line of code with the new syntax of DIM
Code: QB64: [Select]
  1. DIM AS INTEGER a, b, c ', etc...
  2. DIM AS SINGLE d, e, f ', etc...

Surely old and new syntax CANNOT be mixed on the same line of code!  (as you can see code is a SINGLE variable  :-P)

Text Only | Text with Attachments