negative-string values

[ChrisGreaves]

My Christmas Wish for Word2003 VBA and practically every other language that supports character string processing is to allow a data structure that includes negative-string values.

Code: Select all

Me.lblReport = Me.lblReport & " " & strWord

We have all written code like the example shown above.
Our process loops through data locating sub-strings and appends them to a report which is itself a string.

Untitled.png

Of course we end up with output like that shown above with the annoying space character at the front of the string.
I can make use of this extra instance of the delimiter by stating that the string is a self-delimiting string; Left(Me.lblReport,1) delivers the delimiter. I could have different sub-string delimiters in each record of a file, and I have had reason to do that.

But instead we code around it with various tricks:-

Code: Select all

If Len(Me.lblReport) = 0 Then
    Me.lblReport = strWord
Else
    Me.lblReport = Me.lblReport & " " & strWord
End If

or

Code: Select all

If Len(Me.lblReport) > 0 Then
    Me.lblReport = Right(Me.lblReport, Len(Me.lblReport) - 1)
Else
End If

With numeric values I can initialise them to a negative value lngCount=-1
How wonderful it would be to be able to initialize string variables to a negative character Me.lblReport=-" "

I trust experienced members of Eileen's Lounge to wrack their memories for examples of languages that support such a feature.

Thanks
Chris

[HansV]

If you use space as delimiter, the Trim function is a handy way to remove surplus delimiters.

[ChrisGreaves]

If you use space as delimiter, the Trim function is a handy way to remove surplus delimiters.

True, but only for space delimiters, and even then, blindly at each end.
I was thinking more in terms of each data item's descriptor. It would cost very little to allow a string item's descriptor's <Length> field to be allowed to go negative, and then the checking could be done in machine code instead of thousands of programmers cluttering up their code with chunks of error-prone idioms.

Too, I am puzzled that I can't recall ever seeing such a design.
I see no difference in allowing one to write "Initialize this variable to be less than a null value" for numeric data and "Initialize this variable to be less than a null value"for string data.
Cheers
Chris

[HansV]

Null is not the same as zero!
A number less than zero is still a number. A "string less than empty" is not really a string...

[ChrisGreaves]

A number less than zero is still a number. A "string less than empty" is not really a string...

Thanks Hans, and you know how I hate to argue but from the point of view of a desciptor of a string, a string is a <thing> of a specific length, and that length has/is a numeric value.
In most cases the Descriptor.Length will be set to a value greater than zero, and a null or empty string will have the Descriptor.Length set to zero.

In the example I used at the start of the thread, I would have the Descriptor.Length of Me.lblReport set to -1, so that on the first pass through the loop, where Me.lblReport = Me.lblReport & " " & strWord, that first application of the space character " " would see the Descriptor.Length rise from -1 to zero, and then the application of the strWord would see the Descriptor.Length rise to whatever was the value of the Descriptor.Length of strWord,

I'm not really arguing; I just didn't express myself clearly at the outset.
We know that even simple strings and numerics in VBA have descriptors; it's how we can say things like ByRef and ByVal. The ByRef says in effect "just use a pointer to the descriptor of the supplied value"

Cheers
Chris

[HansV]

For your amusement:

StringClass.doc

[ChrisGreaves]

For your amusement: StringClass.doc

Hah!
You thought you could tempt me away from dragging out the lawn mower and seeing if it would start up this year, didn't you?
I took a quick look (because so far it isn't raining here), and I think that you have introduced a layer of programming that does what I want.
Everything is layers, and in this case, the company's top programmer, in charge of all libraries of utility code, has effectively introduced the -veString concept as a class module, shielding me, the humble applications programmer, for the need to write that idiomatic code in every program that I write.
That keeps me, the humble applications programmer, happy.

Still and all I would be happier if it were implemented at the VBA interpreter level, or the C++ (or whatever) level, or even the hardware level. Which is after all, only micro-code, he said, drilling himself into an ever-deepening pit.

Well done Hans! For me your class module code means that my application code doesn't need to look even worse by having visible IF statements cluttering up the logic.

Cheers
Chris
P.S. Does this mean that we can't argue?
C

[HansV]

It's just a proof of concept, Chris. Since - as you rightly mention - it has bot been implemented at the interpreter or microcode level, using this for large-scale string manipulation would (probably) be very inefficient.

[LisaGreen]

Ooh Hans!

Could this be the start of a big Eileen/Hans string class? I have lots of string procs! I'll bet that others here do too!

If anyone has a mind I'd like to receive their string procs whether they are generic or for a specific purpose. I luuuv seeing how people do things!

Regards
Lisa

[LisaGreen]

For information..

There is a "Strings" object in VBA. This is the default for string functions. Strings.UCase is the same as UCase for example. It works with intellisense so typing "Strings." will show a list of string functions.

Lisa

[ChrisGreaves]

It's just a proof of concept, Chris. Since - as you rightly mention - it has bot been implemented at the interpreter or microcode level, using this for large-scale string manipulation would (probably) be very inefficient.

It is a GOOD proof of concept!
It shows that the humble application programmer need not code idioms within the application logic. That is why I developed my humungous library of VBA routines, so that detailed data tasks need not cloud the application logioc.
Your POC works, and that assures me that my wish is rational (well, you know what I mean).

That your PoC is coded at the same level as my application program makes it execution-inefficient - in one sense you have taken my idioms and embedded them in a class at the same level of VBA as my coding.

If your PoC were embedded within the interpreter, it would be much more efficient than our VBA-level code AND it would tidy up my application code.
We still aren't arguing, are we?
Cheers
Chris

[ChrisGreaves]

If anyone has a mind I'd like to receive their string procs whether they are generic or for a specific purpose. I luuuv seeing how people do things!

Knock yourself out, Lisa (attached).
Do you want them as a PKZipped template UW.dot?
Also do you want my Under.dot?
Cheers
Chris

[LisaGreen]

I'll take anything you've got Chris!! And you other people don't forget either!

Lisa

[ChrisGreaves]

I'll take anything you've got Chris!! And you other people don't forget either!

My word, Lisa! How your standards have dropped since you joined Eileen's Lounge!!
The procedures are on their way ...
Cheers
chris

[ChrisGreaves]

I trust experienced members of Eileen's Lounge to wrack their memories for examples of languages that support such a feature.

I am still interested to hear from anyone who has found a language/platform that supports –ve strings. I say “language/platform” because I used to think that there was a computer language that ran on a (mainframe) computer, but know now that there are strata of platforms, for me VBA then the Windows/VBE level, then the laptop hardware level, then the hardware microcode level and going all the way down to what used to be Nand/Nor gates.

Meanwhile, back at the ranch, and just to stay on topic, I abhor Microsoft’s use of the word “macro” to mean “a VBA subroutine with no parameters”, for that is what a macro is in VBA.
A macro in assembly language was a named collection of lines of code that was expanded inline into your program. The programmer wrote the symbolic name of the macro and its optional parameters, and the assembler generated as many lines of assembly-language code as required. The macro-assembly language had conditional statements that allowed conditional expansion; you got only as many lines as necessary, determined by your parameters.
As well, many assemblers had options that allowed you to display or hide the expanded code in the output listings.

Oldies will remember the IOCS macros for IBM 1401 Autocoder.

If we had a genuine macro-processing facility in VBA, then we humble application programmers could write application code that was more readable (I know, I know!!) but make better use of the VBA platform with pieces of code provided through forums like Eileen’s Lounge.
Our VBA code is populated with idioms that ought to be encased in a macro-generator facility in VBA.
Here is an example. I am accumulating items in a string array; I do not know how many items to expect, and so I re-dimension the array after each incoming item is loaded:-

Code: Select all

strAr(UBound(strAr)) = fld.Path & "\" & fil.Name
ReDim Preserve strAr(UBound(strAr) + 1)

At the end of the loop:-

Code: Select all

ReDim Preserve strAr(UBound(strAr) - 1)

The first chunk could be implemented by a macro used as:-

Code: Select all

Append strAr, fld.Path & "\" & fil.Name

The second chunk could be implemented by a macro used as:-

Code: Select all

Trim strAr

You might think that the time taken to craft the macros is not worth the savings in space, but there's more to this than meets the eye. The use of macros reduces the chance of coding errors. "+" when it should be "-" or vice-versa, "Lbound/Ubound", forgetting to write "Preserve" and so on. be honest. I have not seen a published measurement, but I feel sometimes that people using computers spend as much as 90% of their time fixing errors of some sort. That's expensive, but not as expensive as not detecting the errors in the first place. Any technique that reduces the possibility of error is a Good Thing.

In support of my arguments I would paraphrase Woody Leonhard in his book “The underground guide to Word for Windows” in which he said early on that Microsoft should be praised for its foresight in providing an extendible language. He was speaking of the Word2/6 language of course; Office97 was yet to come.
For the life of me I can’t think of why Microsoft did not include a true macro-processor in VBA. VBA is, after all, “the assembly language” of Office applications.
Cheers
Chris