It occurs to me that my thread on secondary buffers shouldn't morph
into a discussion on cross-platform development, so I'm starting a new
thread here.

"Ross Ferris" wrote another advertisement for Visage, then
"Frank Winans" wrote:
of us for many reasons.

I've considered pre-processing vs inline CASE statements and external
CALLs. I like the elegance, but as Frank says, eventually you end up
with yet another flavor of BASIC that no one else uses, and that
trade-off just isn't acceptable to me as a long-term solution.

Kevin King has provided open source code to pre-process code which is
tagged for specific platforms. If you've seen the code Pete
Schellenbach uses for Accuterm, this will look familiar:
#D3 OPEN "DOS:blah"
#UV OPENSEQ "blah" ...
And then the pre-processor uncomments and compiles the code for the
current platform. While this keeps all of the code in one spot it
also puts of ton of unused code in each source module.

For my immediate needs, I have created a structure of external
subroutines for common functions that will not compile on one platform
or another. It works similar to this (real code is more detailed but
just as simple):

*-- app code
* Avoid hard-coding @WHO, U50bb, @ACCOUNT, @USER, etc
CALL DBMS.FUNCS(X.GET.ACCOUNT,WHO,ERR)
CRT "Your account is ":WHO
*--
SUB DBMS.FUNCS(FUNC,RESULT,ERR)
COMMON /MYSTUFF/ DBMS
BEGIN CASE
CASE DBMS=X.D3
CALL DBMS.FUNCS.D3(FUNC,RESULT,ERR)
*--
SUB DBMS.FUNCS.D3(FUNC,RESULT,ERR)
BEGIN CASE
CASE FUNC=X.GET.ACCOUNT
RESULT=@ACCOUNT
*-----------------------------

While not the most elegant structure in the world it works well. Code
that doesn't apply to a given platform will simply not compile, and it
will never be executed anyway, so the invalid object isn't be ported
to the target platform. The thing I don't like is that there is a
performance hit in the CALL for some platforms, but for the stuff I'm
writing now I'm not looking to shave off milliseconds. Another thing
I don't like is that I've just added a lot of new source programs to
my utility library, one for every platform, and that's just more code
to maintain. I'm not whining about that because obviously we need to
maintain different code for different platforms anyway - but more
modules mean more places where we need to say "did I handle that
function over there?".

This also doesn't deal well with those complex structures that don't
translate easily into a single simple call, like this:
CMD = "SELECT CUSTS"
EXECUTE CMD
CMD = "SAVE-LIST ALL.CUSTS"
EXECUTE CMD
By itself that's not a complicated bit of code, but then we get into
those situations where we need to capture the output, return error
codes, skip executing the second statement if the first one returns no
items, etc.


I'd be willing to participate in an open source project which attempts
to standardize common functions for different platforms. I can even
host it on our website in a separate subdomain, where we already have
a forum, FTP, CVS and SVN, MediaWiki, and bug tracking system.
Members of the project can document functions that need translation.
Others contribute the platform-specific code for that specific
function. Others can attempt to optimize the contributed code, or
contribute unit-tests which ensure that all functions do exactly what
they're supposed to do prior to release.

With a project like this, I'm much more inclined to use a
pre-processor for apps because many other apps would be using the same
pseudo-code. So for example, to get the account name as documented
above, application code would just need to do something like this:
CRT "Your account is ":$!WHO
All instances of $! functions would get pre-processed into Include
statements for common functions or into custom-generated in-line code
if required. Exactly how this is done doesn't matter and can be
changed because the underlying process doesn't impose any change on
the app code that uses it.

On this 40th anniversary of the MV DBMS, maybe it's time to take
another look at standards? Where SMA failed to get the DBMS
developers to agree I think we can make use of the tools we have in
the various platforms to create our own commonly agreed syntax.

Sigh - doing it again...
TG@ remove.munge.pleaseNebula-RnD.com

CRT "Your account is ":$!WHO
It seems to me that you are in fact looking for a meta-language that
would cover the flavor specific details.
In fact the issue has been tackled already in some respect by jBASE
and probably others, by allowing the developer to enforce specific
flavor emulations.
Any sort of language, natural or otherwise, evolves, and sooner or
later a new dialect will appear and all that standardization goes to
waste.
What is a great standard for some may be seen as illogical by others.
Evolution is the engine of progress and is defined by change.
The standards that resist the test of time are usually atomic ones, or
axiomatic if you will.
For example the IF-THEN-ELSE construct is common to many if not all
programming languages.
On the other hand even thou at physical level all bytes look the same,
data storage and access concepts is as diverse as the languages
themselves.
To get to the point, a meta-language on top of BASIC may induce an
even larger behavioral diversity for the target application and it may
also induce a performance hit and a maintenance nightmare.
In my opinion, beyond enforcing emulations as jBASE does, the platform
specific INCLUDEs is the way to go.

I guess no vendor would push for total standardization.
If all MVs are the same, what would be the incentive to buy one MV
versus another ?
Unlike manufacturing, for software you have the initial investment and
then you can multiply it at no cost therefore the cost/price incentive
is diluted.

Changing the topic, I would like to see a repository of differences
between flavors and a repository of bugs for each flavor.

Lucian

Lucian wrote:

That "in some respect" part is where things get hairy. The WHO example
was just one with which all MV people would be familiar. I have code
that's different for where some object code is found in data files and
prepended by "$". It's different where the word ".Type" or @ID may be
found. It's different where "LIKE" is required for a flavor of UV
rather than the "[foo]" syntax. It's different where there is a .OUT
file rather than having object in the Dict. I'm trying not to use
OPTIONS flags that make software compatible with some flavor because
the flags themselves have nuances and differences that make them
platform-specific. OPTIONS help to make syntax compatible from one
platform to another, and they help a great deal for some of the items
I've mentioned above (just look at the long lists of options provided
by each DBMS provider). The code I have now is 99% compatible across
all tested platforms and OS's - of course that last 1% is taking most
of my time as I work toward deployment for each platform, and that's
where I think it would help to have small libraries of code that do
platform-specific operations via Calls or maybe "meta syntax" passed
through a pre-compiler.

Full agreement, and that's where I've expressed some apprehension with
precompilers and standardization to syntax that isn't supported
natively by any platform.

Again agreed. The penalty for coding to the "wrong" standard is
having a lot of custom code that may not be portable later.

And that's what takes a bit of thought. Just to focus on INCLUDE
lines for a moment, Includes for "other platforms" need to be
commented out by a pre-processor. And the way most people code, using
editors like ED, AE, SED, JED, VI, etc, it's a pain to have primary
code out-of-line. For one thing you can't see it in the editor, and
for another in some platforms the debugger doesn't step through
include items. Software like mvToolbox from DMCons (.com) imports
code for editing and exports it back as appropriate. That's perfect
for editing but it doesn't help for the runtime. I'm not saying a
Call is the right answer or that meta syntax like $!WHO is right
either, but at least you can see the source if you step through them
at runtime. Sure, you can use a pre-processor to import Includes
in-line too, and then you can see the source lines in a runtime
debugger (as supported by the DBMS of course) but if you're doing that
a lot maybe Call is a better solution.

I'm not correcting or suggesting one solution or another, just trying
to clarify that there is a problem and that it's not solved easily by
the current/obvious mechanisms.

Gosh I hope this is making sense. It makes a lot more sense when your
head is buried in code and you say to yourself "I wish it would do
(whatever) so that I didn't need to write it like this...".

That's an argument I've made many times here when people talk about
standards. I'm a firm believer that vendors won't really collaborate
on standards because it's not really in their best interest to do so.
However, a lot of effort is expended by some of them trying to come up
with OPTIONS flags and documentation to help migrations, and even with
these resources porting code is rarely a slam-dunk.

My position is that "migration" is not a process that involves
value-add, it's a break-even proposition, the vehicle and not the
goal. We migrate from one system to another with our code as-is, and
functioning just like it does elsewhere, and _then_ we start to
customize to make use of the value-add provided by a specific vendor.
If we're in agreement that the part about migrating isn't really the
objective (except maybe for sales guys who just want your money), then
why should it be so hard? If all MV DBMS platforms conformed to base
standards as a minimum, and then had value-add beyond that, then we
could more freely choose our vendors based on their value-add
capabilities, and we wouldn't be hesitent to migrate only because that
process in itself is so painful.

All MV platforms support IF/THEN constructs, Attributes and Values,
SORT and SELECT. But there are too many places where we find one
platform just does things differently from the others, and this is
where migration is a pain. Migration should not be complicated. I'm
not talking about unique features, which are of course going to be
different. I'm talking about things like the "SH -c" vs "DOS /c" vs
"!" vs "! " (note the space after bang). There's no value-add in
different syntax for the exact same function, it's just a pain, and
that's the only thing I'm focused on here - developing third-party
extensions like $SH$ so that this specific function can be
pre-processed on any platform and work as expected, barring
OS-specific nuances of course.

Those are two very different goals but I agree that it would be
helpful for developers. Unfortunately the DBMS vendors will never air
their dirty laundry and people in these forums don't have the time to
document bugs and bug status for their vendors, let alone as a pro
bono effort for the public.

I decided to take a couple minutes with my current project to post a
couple notes here and in other forums that exemplify some of the
issues I'm having. I don't have the time or interest to vet through a
more organized or complete set of platform differences, just to
highlight some of the issues. Documenting differences between
platforms isn't much more than translating material already provided
by the DBMS vendors, and while it's interesting reading most people
are just interested in differences for very specific target platforms.
It's not that we don't know about the platform differences, the
problem is that it's just a pain to code through them. So I don't
think a a pure documentation project is going to go anywhere.
However, I do think many of us would benefit from a repository of
routines that are published to address specific issues in
cross-platform development.

No more time for rambling, off to code.

Thanks for the discussion.
T

Lucian wrote:
I just came across a good example of why Includes aren't any more
ideal than custom syntax via a pre-compiler.

01 NOT.EMPTY = 1
02 * EMPTY.VAR is not assigned
03 * Check empty var:
04 IF NOT(ASSIGNED(EMPTY.VAR)) THEN EMPTY.VAR = 1

For line 04, Unidata has its own unique syntax (regardless of ECLTYPE
or BASICTYPE):
04 IF UNASSIGNED(EMPTY.VAR) THEN EMPTY.VAR = 1

Line 4 simply won't compile for the wrong platform.
Maybe we can pass the var to a subroutine and check externally:
04 CALL CHECK.ASSIGNED(EMPTY.VAR,VAR.IS EMPTY)
05 IF VAR.IS.EMPTY THEN EMPTY.VAR = 1
For most functions this would work well, but for this specific problem
the Call will generate a Var Unassigned error on most platforms,
destroying the transparency.

So how about the Include? Well, Including code that won't compile is
no different than having it in-line.

The only solution that I can see for this one and many others with
completely incompatible syntax is to use a pre-compiler with the
following syntax:

Option 1)
#D3 IF NOT(ASSIGNED(EMPTY.VAR)) THEN EMPTY.VAR = 1
#UD IF UNASSIGNED(EMPTY.VAR) THEN EMPTY.VAR = 1

Option 2)
IF $!UNASSIGNED(EMPTY.VAR)!$ THEN EMPTY.VAR = 1

The funky codes (the "$!" stuff) would get extracted by the
pre-compiler, replaced with code appropriate for the platform, then
put through the real compiler on the target platform.

In order to generate platform-specific code, you need to know which
platform you're on and/or what the target platform is. Ironically, I
hit this example in my code that determines the platform - it's sort
of a Catch 22 when the code you need to determine the platform is
itself subject to platform-specific issues.

I'm not looking for a solution to this ASSIGNED problem. If someone
suggests a way for ASSIGNED to work on Unidata, that will be one
problem solved but something else will come up tomorrow. Personally,
I can get around these problems easily by doing some hard coding here
and there, and adding a comment to myself to come back to fix it
later. That's the way we'd do it any other time. I just thought I'd
share a decent example of the problem so you know why I'm thinking
along these lines.

T

On Jan 4, 3:28 pm, Tony Gravagno
<address.is.in.po... (AT) removethis (DOT) com.invalid> wrote:
Hmmmm,

Resisting the urge to say "I told you so", like I said in the original
thread, after having played with all of the techniques I've seen
published here (and elsewhere), we opted for the pre-compiler route
when we tackled this problem.

Hopefully you already know why your option 1) just doesn't make sense
for large scale development, but I'm afraid unless you are "really
clever", option 2) will fail pretty quickly too.

If you have an interest in Systems Archaeology, I would suggest maybe
starting back with Forth, which always intrigued me as it was the
first system that I discovered that was not only written in itself,
but allowed for extensible vocabularies through the notion of
"words" (similar in ways, though quite different to VOC/MD - and
likewise Forth dictionaries are "different", and yet ...). Tony, I
also would assume that you are familiar with the concept of Design
Patterns

Why? Because I've been "playing" with these things for over 20 years
now, and the elegance at the core of many Forth concepts has been a
recurrent theme & useful reference point through many product and
conceptual iterations, and can be readily adapted to multi-value.

However, IMHO I still think you are missing THE most important
application of this technology - sure, the platform portability is
useful, but the productivity gains in terms of head down, tail up
development (assuming anyone reading this actually DOES "real"
development) is really where the payoff is, enabling a programmer to
churn out bucket-loads of structured, optimised code.

An end-user or development company that is JUST D3 or UV is unlikely
to be attracted to the idea of being able to write code that has cross-
platform capabilities. Show him a tool that can make him more
productive TODAY, AND gain cross-platform capabilities, and you might
get attention !?!

BTW, it should also be obvious that just as we apply our Snippet
Technology to power multi-lingual support within Visage, you are not
limited to using this type of thing just for the "Basic" language - we
also use it against jScript (eg IE vs. Firefox) and have also played
with some "stuff" for generating VB.net and Java code equivalents for
traditional "pick basic" as well (contrived cases, but single source
for multiple platforms could be useful down the track for some
things), but this is well outside the gamut of what you are
considering developing.

You know where to find me if you get stuck "tomorrow", or want a
solution "today" :-)