SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Mon, 4 Aug 2003 22:38:40 PDT7
From:	Peter Skye <pskye@peterskye.com >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: Re: Warpstock 2003 Presentation

Content Type: text/plain

Lynn H. Maxson wrote:
>
> I almost giggled with your jump past the header of the
> subroutine and then jump back as well as the need for the
> flag and associated extra coding. In fact unless you took
> care to insure name correspondence, a restriction not
> present in a subroutine invocation, it wouldn't work. No
> implementation could help you here.

Lynn, Lynn, Lynn,

Take a look at PL/I's ENTRY keyword. It's been a long time since I
disassembled same, but the concept is clear. You can call a subroutine
at different entry points.

Granted this isn't a JMP but it _does_ allow you to use the same code in
different ways.

> first let's understand that a macro in assembly language
> always produces inline code, never the option of
> out-of-line (or subroutine). Two different templates,
> invocations, and source code for the same functional
> result.

Whatever yer smokin', kin I git some too?

Code up your subroutine's header and ender, and smack dab in between 'em
write this single line:

macro . . .

Guaranteed that the code which appears in your mainline and the code
which appears in your subroutine will be, golly gee, the same. And the
work done by each will be, golly gee, the same.

Now about thet stuff yer a'smokin' . . .

> The issue is having one piece of source code which the
> programmer can invoke on an instance-by-instance basis to
> execute either inline or as a subroutine. In either case
> the programmer invokes it identically except for indicating
> the meta-programming option. Appending, for example, the
> source text "inline" prior to the statement terminator.

Sounds to me like your meta-programming option is a simple library
option. Where's that example you've been avoiding?

> If he doesn't indicate it, it defaults to subroutine.
> Thus only one set of code exists, the source template,
> which the implementation can do in one of two
> programmer-defined ways.

Methinks I blew holes in this a couple paragraphs back. :)

One set of code. Inline it anywhere you like, *including* inside the
subroutine.

> The programmer, for example, can invoke a sort routine as

A code example!

> "rc = sort(A, flda, fldb, fldc);"
> "rc = sort(A, flda, fldb, fldc) inline;"

Good, now we're getting somewhere. Semantically you're allowing the
programmer to specify whether the code should be placed inline or that a
function (assumedly using identical inline code) is called.

Avoiding register setup for the moment (it's a frivolous argument
anyway), I thought you were seeking an HLL which would automatically
identify when to inline and when to call. Was this a mistaken
assumption on my part?

And, for funners, why not use this syntax:

rc = sort(A, flda, fldb, fldc);
rc = sortinline(A, flda, fldb,fldc);

where the sort function utilizes the sortinline "macro call".

Using "inline" as a keyword (as you suggest) is a cleaner language
design because it forces all inline code to be instantly recognizable;
my sortinline() could just as easily be named sortrightnow() which
obfuscates the inline-ness of it. Still, the resulting machine code is
the same. In the old days the language designer would dream up some
identifying character for the programmer to use, i.e.

sort() - call the sort subroutine
sort#() - put the sort code inline

Such shorthand is hailed by some coders and hated by others. Same with
the question of "where should we say 'inline'?" -- it's the semantics of
the language but the parser doesn't really care and there's no special
logic that must be implemented.

> Any particular instance he can switch from one form to
> the other either by including "inline" or not: a one-word
> change. You have no such capability in assembly
> language expressible as simply or easily.

Well, there's a whole lot of things in PL/I that aren't as easily
expressed in assembler. But having an inline code macro and a separate
subroutine with a similar name are just about the same. How about
ARCTAN for example:

inline ARCTAN reg DX
or
inline ARCTAN dwValue
or
call f_ARCTAN reg DX
or
call f_ARCTAN dwValue

where the function f_ARCTAN uses the ARCTAN inline code.

Awaiting your warmest response to this one. :))

> Suppose that you had a variable-length, character variable
> which not only had an upper limit but whose use dictates a
> lower one as well. You currently have no means in an HLL
> to express this rule. Thus you, the programmer, has to
> enforce the rule (assuming, one, that you know it, and,
> two, that you remember it wherever) in every instance of
> its use.
>
> You cannot, for example, declare it as part of the data
> definition, which allows you only to specify an upper
> limit:
> dcl jimmy char (17) varying;
> Now how much of a jump to rocket science is it to be able
> to change this to
> dcl jimmy char (5:17) varying;
> Suppose if it is text, that it contains caps only:
> dcl jimmy char (5:17) varying range ((A...Z)...);

This is a much better example. I believe that Pascal has the capability
of defining a variable as a member of a set (for example the only legal
values are the characters "A, "X" and "Z" or the values (not strings!)
Dog and Cat) but I've never used that capability of the language so
can't comment on its robustness.

The ability to define a minimum length is enticing. In PL/I (at least
in the now-antiquated PL/I Level F compiler) every variable had an
associated control block which contained the declaration for the
variable (including the address of the actual data). When you called a
subroutine the address of the control block rather than the address of
the data was passed to the subroutine; the subroutine in turn could
determine what form the data existed in and could act accordingly. You
could, for example and if the language were extensible, add a BCD value
to a text string containing Roman numerals. This was typically
accomplished with a single subroutine containing multiple entry points,
one entry point for each possible combination of parameter declarations
plus a general-purpose entry point that would convert the parameters to
a common declaration.

So it's been done. In assembler. :)))

> Now you have rules embedded within (or associated with)
> the data declaration. This not only dictates the logic
> which the implementation must verify for correctness, but
> it also means that it must include the "exception" code
> as well to indicate any error in execution.

Off hand, I can't think of a situation where a value's control block
couldn't be used by code to verify the correctness of a value.

> Obviously (something which you may not have considered) it
> should allow the programmer to dictate what should occur
> in the instance of an error:
> on range (jimmy) begin; ....end;
> Just your typical PL/I-like exception handling capabilities.

This also seems easily implementable using a value's control block.
Your "on range" would parse to either inline code or a subroutine call,
either of which would review the value's control block and then check
the value itself for correctness.

> You could have hundreds and thousands of such rules
> embedded within the software of an enterprise. Now you
> find that the effect of turnover in personnel and the
> learning curve is reduced significantly. You now have a
> software tool that can immediately indicate a rule-breaking
> coding error as well as furnish the particular rule(s)
> broken. Your documentation of the rules lies in the source
> code itself. In that manner the two will never get out of
> sync nor can you change one without simultaneously changing
> the other: they are one and the same.

It seems to me that the inclusion of a value control block, as mentioned
above and in use for 40 years, implements this ability. By writing code
that uses these VCBs you can fully explain how an error occurred -- you
could even implement UNDO so your program could back up and see what
sequence of values led to the error.

> In truth, Peter, current implementations suck relative
> to what they are capable of performing.

True of all man-made creations, not just the electronic ones.

> The advantage of open source as a community of users and
> producers lies in offsetting the increase in production
> costs with the reduction in use costs.

Yes in a lot of cases. But there are a goodly number of users who don't
have the desire to contribute, who don't have the intellect to
contribute, or for whatever reason you don't want them to contribute!

(I'll be out of town for the next day or two.)

- Peter

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 04 | August | 2003 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.