ChrisGreaves wrote: ↑04 Jun 2021, 19:55
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:-
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