I've tried to use the Wiki discussion page with no avail so here are
some observations and opinions as e-mail.

I've looked over the "Programmer's Manual" and over "Unorganized
notes..." only.
From my very limited reading results that from a BASIC programmer
perspective, things are not quite strait forward.
Looks like what you offer is a collection of subroutines that emulate
multivalue BASIC statements and functions.
If my understanding is correct then the audience should be C++ and
PostgreSQL programmers who want to emulate existing multivalue
applications.
Looking at the programming examples it is apparent that a conversion
to Exodus is far from trivial.
BTW, jBASE has C++ at its core too so theoretically they can come to
the market with a similar product.

Some notes:
1) "For example, traditional multivalue basic has a TRIM() function
which returns a new string. However there was no TRIM X statement
which would modify the string in-place which in many cases would be
much faster." This statement is not true. If the destination is the
same as the source TRIM executes in place. If there are characters to
TRIM there is no difference between TRIM in place and trim in a new
variable except for the space allocation. If you trim, data has to
move anyway. Same goes for CONVERT etc.

2) It is not clear if the user is required to manage memory
allocation. For example if I use replacer(...) and I replace something
with something much bigger am I required to do anything special such
as reallocate the space ?

3) Why not add the default functions to your include; less worries
for the programmer.
#include <exodus/program.h>
programinit() <----

4) Because you use the C++ compiler directly, you have to use
functions instead of the classical syntax such as extract(A...)
instead of A<..>. In my opinion this is a step backward and may
result in cryptic code. Earlier implementations of the Nelson
database used functions and evolved to the current speech like syntax.

5) It is not clear if Exodus is type-less or not.

6) You should include a list of reserved words.

P.S. I had once to convert a system from PICK to JBASE and even thou
these systems are very similar it took almost a year to get it live.
The syntactic and semantic differences were minor but in too many
places for comfort. Now I imagine myself having to rewrite all those
programs in a C++ dialect. Different reserved words, different name
conventions (cannot use period in names etc.) different syntax and
probably semantic differences too. To convert an existing multivalue
BASIC system to C++ is possible but, in my opinion, in many cases
impractical.

On 31 Oct, 03:14, x <lucian_p... (AT) yahoo (DOT) com> wrote:
Did you sign up/login? You have to login to reduce wiki defacement by
bots.

Kind of but it is much deeper than that. Every single operator works
precisely to mv rules. As far as I am aware there is only one
exception - which is regarding the precedence of the concatenate
operator compared with the logical operators (and/or) but I believe
this is manageable.

var aa="2";
var bb=2;
printl(aa+bb);
printl(aa^bb);//this is Exodus's concatenate operator, essential
equipment for mv programming

4
22

Exodus benefits from having a concatenate operator even if it is ^
instead of :

also we have a WHOLE new way of writing expressions.

PRINT OCONV(DATE(),"D")

becomes ...

a(3).oconv("D").printl();

.... or a mix of the two if you prefer ...

printl(a(3).oconv("D"));

This may be a bridge to far for long term mv programmers but is the
mainstream way of doing things for new programmers. Exodus caters to
both crowds.

The new way of being read left to right can be consider easier to read
and write than the old way. For example in the original statement the
OCONV is on the left of the expression but its key parameter is far
away on the right side, whereas in the new way the .oconv("D") is all
together. In larger expressions the old style becomes really quite
hard to read.

No way. The primary audience is mv application programmers. I dont
even know what a C++ or PostgreSQL programmer looks like.

Anybody can do the same as Exodus and they are free to copy Exodus
since it is BSD/MIT licenced.

Jbase has a complex compiler which converts JBASIC into C source ...
which is then compiled into native code. Exodus is an observation that
you can use C++ to reasonably morph the syntax of mv basic into a
"curly bracket language" syntax and thereby eliminate the need for a
special mv language and compiler at a stroke. I pitch this as a
revolution.

The other tricky bit which Exodus has solved (for postgres at least)
is how to make mainstream databases seem like a mv database to the
Exodus programmer.

OK

Absolutely not!

Application programmers wouldnt have a clue. Programming Exodus doesnt
require any more fundamental knowledge than that for mv basic.

BTW I can imagine long term mv programmers hating the "replacer"
syntax in exodus but I cant think of anything better at the moment.

A<3>='abc'
A<4,3>='xyz'

becomes ...

replacer(a,3,"abc");
replacer(a,4,3,"xyz");

.... or in Exodus's OO syntax (which is the way new programmers expect
to work) ...

a.replacer(3,"abc");
a.replacer(4,3,"xyz");

which is rather long winded but manageable.

apart from the lack of "=", it isnt much worse than classic mv
"x=replace(x,3,0,0,'xyz')"

notice that Exodus allows the multivalue and subvalue to be omitted
unlike classic mv

I could do the following instead but both are cryptic.

rep(a,3,"abc")
rep(a,3,"xyz")

or

a.rep(3,"abc")
a.rep(3,"xyz")

the following isnt too bad but cannot be done.

a(3)="abc";
a(4,3)="xyz";

round brackets on the left does work for dimensioned arrays though.
there are no problems with exodus syntax for dimensioned arrays.

in the end loss of <> and [] is sad but not unmanageable. I have not
really pitched the advantages of

any suggestions?

I was tempted to do that and it may be done in the end however for now
I decided to expose a slightly richer programming environment that
will allow OO programming for people who want to do such things. The
documentation on that isnt done because I havent settled on a syntax.

Yes the loss of the <> [] angle and square brackets in Exodus is very
sad aesthetically but I dont think it is more cryptic.

C++ has one trick up its sleeve that you might not be aware of. You
can define round brackets to mean anything you like so I am toying
with the idea of using round brackets to do extraction since that is
so common.

aa=bb(11,2);

Of course round brackets mean that you can no longer visually tell if
it is dynamic extract or a dimensioned access (which is implemented
properly in exodus too). Despite the visual confusion I decided for
now to allow round brackets to do extract since it is so common.

It is this type of decision that I was looking for input.

.... but to reject exodus on its negatives is to miss all the advances
in syntax.

One that comes to the top of my head is the short circuiting of "and"
and "or" operations. I mean the right hand side of "if a=b and c=d" is
not evaluated

Yes, because its variables behave EXACTLY like mv variables. Otherwise
it would be impossible to port programs to Exodus.

I will. Right now I am looking for feedback on the Exodus syntax
before it is frozen.

I quite agree for one thing.

We arent really converting to C++ because Exodus doesnt expose any C++
functionality direct to the programmer. The programmer only needs to
know the Exodus programming manual. They do not need to open a C++
manual even once.

Anybody who WANTS to merge C/C++ programming into Exodus is free to do
so merely by doing things like #include <string> ... but then they
need to know about c++ strings. It is difficult to get over the fact
that C++ is a kind of chameleon that is whatever you want it to be
within its fundamental restrictions. It isnt a scripting language for
example .. but mv programmers are used to compilation.

thanks again for your comments.

On 1 Nov, 16:35, "Jeff Caspari" <mu... (AT) idt (DOT) net> wrote:
Yes.

One that *looks* like javascript but behaves exactly like Pick basic.

No.

It is directly compiled by any standard C++ compiler.

Don't think that Exodus is C++ though ... there isnt a char, string,
int or pointer in sight! Exodus just uses C++'s raw keywords like if
for else case { } etc ... everything else is pickesque functions that
any pickie can grasp in seconds.

There is a programmers manual at:

http://devwiki.neosys.com/index.php/...mer%27s_Manual

Yes but that sounds frightening whereas the Exodus programmer can if
they like remain utterly unaware where or how the data is being
stored.

For those who are interested, Exodus is just using postgres to store
and retrieve blobs of data (records) using a primary key. All Exodus
sql files have one just two columns: "key" and "data" ... which is
exactly what pick has.

When you issue some classic pick SSELECT statement in Exodus, behind
the scenes it looks into its classic pick dictionaries and generates
an sql query that extracts the required fields out of the blob on the
fly and sselects on the extracted data ... which is exactly what pick
does.

What Exodus DOESNT do is try to split up its record into sql columns.
With apologies to Blazing Saddles ... "Columns? We dont need no
stinking Columns"

so if you issue a SSELECT command in exodus like this ...

SELECT CLIENTS WITH MARKET_CODE EQ "XYZ"

.... and your pick dictionary has said that market code is in field3,
exodus will generate an sql statement something like this.

select key from clients where exodus_extract_text(data,3) = 'XYZ'

Because it is the database engine itself that must correctly sort/
select extracted data, and the database has no clue about concepts
such as pick date and time, then different extracts also convert the
data to the format understood by the database e.g.

exodus_extract_date()
exodus_extract_time()
exodus_extract_datetime()

there is also exodus_call() which executes a function back in the main
exodus process. This is the only way to do calculated fields at the
moment. The postgres plugin could in principle call Exodus functions
directly but there isnt a plan to implement this at the moment.

Exodus's SSELECT has some other tricks too. If a dictionary defines a
field to be a simple translation/lookup into another file, then
exodus's "sselect2sqlselect" function automatically generates a
suitable sql "join"

"dawn" <dawnwolthuis (AT) gmail (DOT) com> wrote



IMO. YMMV.

--
frosty

Time to dive into this discussion.....

Way back when we started the project that ultimately became QM, we
looked very seriously at using the power of C (not, at that time, C++)
to provide the basis and develop a set of extensions to the language.
I was also involved in a very similar exercise in my days working on
PI/open. In both cases, we came to the conclusion that it was the
wrong way to do it.

Ok, Basic is an old langauge but it is still used in its many variants
and langauges such as VB.Net are definitiely contemporary. By
comparison to C++, Basic is (my opinion, like all of this) much
quicker to learn and quicker to develop in. I would be interested to
know how long it would take a novice programmer with absolutely no
experience to learn the Exodus language to the point of developing a
simple sales order processing system. I have taught a Basic course for
many years and regularly take total beginners to this point in one
week.

One of the great things about multivalue Basic is that it is a stable,
well defined langauge. There are variants but they are fundamentally
similar and programs I wrote twenty years ago will still run today. On
the other hand, Microsoft keep moving the goalposts for their
programing languages to the extent that I have just spent four weeks
converting an application to run on the latest systems without adding
any new functionality. Microsoft see this as progress. I find it
amazing that the user community puts up with it. As soon as Exodus
takes the programmer into C++, all development and maintenance
activity becomes controlled by the whims of Microsoft (et al).

So what are the aims of Exodus? If the target is to take existing mv
applications and migrate them, the differences are so great that it is
a rewrite. I set about writing some comments on the differences based
on a quick skim of the manual but I gave up as it quickly became clear
that this is not Basic, it is not C++, it is some curious hybrid. If I
were a C++ programmer with no mv experience, this would be a whole new
language that has a vague similarity to C++ in places.

Sorry Steve, I don't see it going anywhere. Maybe I will be wrong.


Martin Phillips, Ladybridge Systems

PMJI - Martin, as I see it, MV is not as standard as we'd like either.
The issues you've described for Microsoft changes are trivial compared
to issues during a MV>MV migration. I'm not speaking up for
Microsoft. Rather, I'm pointing out that we frequently talk about
migration from one MV environment to another as though it's all just
MV, and yet it can take months to actually do a migration. The
learning curve is huge and once someone does it once they really don't
want to do it again. Maintaining cross-platform BASIC code is
non-trivial despite the fact that it's "all BASIC".

I'm not participating in this Exodus discussion because it's still in
development, and while I don't have a lot of confidence that it will
take off, I also don't think adoption would be any more radical than
when any of us adopt any other MV platform.

2 devaluated cents.
T

Neither do I but it has its first client my company and that has to be
a milestone of some sort. We hired a C++ ace to buff it up for six
months.

A very encouraging opinion. Thank you.

On Nov 2, 2:14*pm, Tony Gravagno <nos... (AT) nospam (DOT) invalid> wrote:
Tony makes very good points. Nobody likes to port a good, complete
project. But there often is no choice. And porting R83 to Unidata is
a lot easier for a Pickie than would be porting R83 to VB or C++ or
QBasic. Not trivial, but not impossible. So the bottom line is that
Martin is a little closer to the mark in the real world. At least in
the real world in which most of us who have been Pickies for many
years live and work.

And FWIW in that real world it's very difficult to see why anyone
would consider porting from an old Pick to anything except QM. Not to
downgrade the truly magnificent systems like Cache but rather to
consider the cost versus benefits of the trip to QM versus the trip to
Cache for instance.

Completely new development may be another story but completely new
development in Pick is as rare as Great French Army Victories.

BobJ

On 3 Nov, 16:58, Robert Joslyn <bobjoslyn... (AT) gmail (DOT) com> wrote:
Just to correct one potential misunderstanding: Porting to Exodus C++
is not comparable with porting to VB/QB. Exodus provides C++ with pick
operators and variables that behave *precisely* like pick operators
and variables. This is impossible in VB/QB.

a='2'
b=2
print a+b

Pick: 4
VB/QB: 22

this is just one of a host of differences that are nigh on impossible
to port to new languages whereas in C++ you can make up variables that
work like pick as fast as pick. I called Exodus's pick variable "var"

var a="2";
var b=2
printl(a+b);

Exodus say 4 as you would expect.

Steve asked for help and instead took a beating. He did what he
thinks is best and in the end the market will confirm or not his bet.
From a business perspective I just hope he is not putting all his egs
in one basket. The multivalue concept is not married to the BASIC
language, it just happened to become a very happy couple. I don't see
the future his way but I was wrong many times over so I have to give
him some slack.

Lucian