openQM

[John R. Stokka]

So I'm doing a port over to openQM.  Interesting since I haven't done a port in some time...

I guess it doesn't like the word LET as in...

LET X = 0

So that's going to take some time... lol

Yes I'm old.

John

It probably doesn't like REM either, lol ;)

[Jan Van Schalkwyk]

You should simply try x = 0 (LET is gone)

Use * instead of REM

Cheers

Jan

[Brian Speirs]

Ha! So, QM got publicly released in 2001, and in 2017 someone notes that it doesn't support LET! I guess that demonstrates the usage of that most important of BASIC statements in the MV community!

REM works just fine.

I'm sure a little program to strip out leading 'LET ' strings would solve your problem fairly quickly.

Cheers,

Brian

[Martin Phillips]

Hi John,

 

We considered implementing LET way back at the start of QM but had never seen it used in real multivalue Basic programs so we decided not to support it.

 

Rather than stripping out all the redundant LET tokens, you could simply do

   $define LET

at the top of the program or in an include record that you import everywhere. This will replace LET with nothing.

 

 

Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England
+44 (0)1604-709200

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

[John Stokka]

Martin, 

Thank you for the suggestion to ease my migration.

My question for you is why wouldn't you just put it in there.

Of course I could AND NOW WILL HAVE TO change every program I ever wrote over a period of 30+ years OR you guys could just ignore the token like every other implementer of BASIC in the history of man.

Come on man. :)

Respectfully with a we bit of sarcasm,

John

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

[Martin Phillips]

Hi John,

 

If this issue is affecting many programs, please let me know what version of QM you are using and I will look to see if we can include LET as a patch to the compiler.

To unsubscribe, email to: mvdbms+un...@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+un...@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+un...@googlegroups.com

[John R. Stokka]

Wow!  Now that's what I call responsive!  I just downloaded the latest release a few days ago so whatever that is.  Feel free to email over a patch.  It will save me a ton of program changes (and others as well I'm sure in the future)'. I'm windows 64 bit btw

John R. Stokka

(515) 707-7106

[Martin Phillips]

Hi John,

There is a patch available for release 3.4-11 to add the LET statement. To install this, logto the QMSYS account and type

    *PATCH  292

[Ian Harper]

I am constantly blown away at the responsiveness of OpenQM! Kudos.

[John Stokka]

They already got my patch complete!  Boom!  Wow!  Patch 292 is on the system.  Impressive!

5 stars for Martin!

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

[geneb]

On Tue, 5 Dec 2017, Ian Harper wrote:

> I am constantly blown away at the responsiveness of OpenQM! Kudos.
>

It's one of the reasons that I recommend them to anyone that's looking
into migrating to a different MV platform. You will NEVER see that kind of
responsiveness out of any other mvdb vendor.

g.


--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!

[Jan Van Schalkwyk]

So will you also be patching the REM? :-)

[Kevin Powick]

On Tuesday, 5 December 2017 13:55:59 UTC-5, Jan Van Schalkwyk wrote:

So will you also be patching the REM? :-)

I'd like a patch, or rather a feature update, that allows me to use C style comment tokens.

 // this is a comment

 /* Everything between these tokens
    are comments */

--

Kevin Powick

[Martin Phillips]

Hi Kevin,

 

The // style comment cannot be added because // in QM is an integer divide operator. Thus

   A = B // C

would be ambiguous as to whether C is a comment or a divisor.

 

We probably could implement the /* … */ style comment though it would require a significant compiler change. I am against doing this simply to make QMBasic closer to C because it is a step along the way to a language that is neither multivalue Basic nor C and hence confusing for all users.

 

 

Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England
+44 (0)1604-709200

 

 

 

From: mvd...@googlegroups.com [mailto:mvd...@googlegroups.com] On Behalf Of Kevin Powick

Sent: 05 December 2017 20:07
To: Pick and MultiValue Databases

--

[John Stokka]

I'm going to chime in here again... I'm very impressed with some of the things I see in QM.  Having prrogrammed in many different languages.  I've spent the last few years in mostly the .NET world around things like c#, etc.

One of the best things I've seen is the compiler directives such as $DEFINE, $IFDEF, and $IFNDEF.  I'm not even sure if that form is correct but you know what I mean and that goes to show how prevalent they are.

I can't believe they were never implemented in D3.

As I'm doing a port I was wanting to maintain compatibility with D3 and it's pretty difficult to make it backward compatible because they never added this fundamental thing and thus I'm using them very sparingly while they would make the port so much easier if they were available on D3.

That being said more kudos to you for embracing this fundamental and very robust addition.

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

[Glen Batchelor]

  Martin, there are a lot of other high-level languages, including Progress ABL, that use /* */ as quoting strings so it's not just a C-thing. I prefer this style of quoting over #, ! or just * since many code editors automatically detect /* */ quoting but not the previous examples as they are often operators. I'm not a QM user so take this as an outside opinion.

Glen

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

[Tony Gravagno]

The /* ... */ syntax is easily implemented with a user pre-processor. It doesn't need to come from the DBMS provider. There is a startling discrepancy in this industry where people insist on doing things themselves that they should not, like MD5, JSON, EDI, PCI, whatever, and then they insist that code-related features must come from the DBMS provider. Code is just another kind of data and I'm surprised MV people have never been enthusiastic and proud of their ability to manipulate their own code. If I'm not mistaken, isn't the QM compiler written in BASIC to some extent?

[Kevin Powick]

Hi Martin,

Thanks for the reply.

I hadn't considered the issue with integer divide (D3 doesn't have it), and of course have no insight wrt compiler internals.  This was just a "nice to have" option for me.

I don't think users would be confused or that it would somehow corrupt the language from being a version of MV basic.  Though, I always found it odd that in the MV world, an asterisk was chosen as both a token for comments and the multiplication operation.  Now that is confusing. ;-)

Again, this was just a "nice to have".  I've lived without it for too many years to really worry much about it anymore.  This thread was just an opportunity to mention the idea, again. 

--

Kevin Powick

[Jeff K]

For multi-line comments without a leading REM, *, etc., I've used this before:

0023 $IFDEF COMMENT

0024

0025 This is a comment

0026 So is this

0027 And this, too...

0028

0029 $ENDIF

However, it won't work for /* inline comments */ or // end-line comments.

End-line comments are easy enough using  ;*  though.

[Wols Lists]

It struck me that just as * can be either multiply or comment depending
on context, why not // as divide or comment. It just has to be the first
token ie after a newline or ; just like *. For those people who like C++
style (or those context sensitive editors that expect it), that might be
a simple idea to implement :-)

Cheers,
Wol