fyi: true references in clipper

Hi group,

Thinking i want to share this

Array (and thus Object) and Block being reference types means that its
actual value is somewhere in the heap, which a reference refers to (much
like a 'pointer') being the 'actual' data hold in variables for these types;
this simplifies passing them to functions since the contained reference is
sth like a two-byte address only; this is called the reference-nature of
said types (in contrast to the other types which really contain the data
themselves; type character is a special case)

Therefore, arrays passed to functions (without the @ operator) do not
involve copying the contained data, only the 'pointer' is copied; accessing
that array from within the function through subscripts therefore access the
array's original contained data; re-assigning the passed array itself from
within the called function, does not propagate back to the caller

At the other hand, passing variables (lvalues) with the pass-by-reference
operator @ to functions, allows the orginal variables to be changed by the
function that is called; this also applies to Array (and Object) and Block
types, but on another level (compared to the other types passed by means of
the @ operator); whenever Array (and Object) and Block are passed as
arguments to a function by using the @ operator, whenever re-assigned from
within that function, also the original variable's contained 'pointer' to
the heap is _overwritten_ by another 'pointer' (to a different place in the
heap)

So far so good (commonly known)

But here's sth i wasn't aware of, and thanks go to Przemek for the lead

Much like in C++, a variable (of any type) can be initialized to 'reference'
another variable (within the same function)

/// GOOD

LOCAL cHello := "hello world"
LOCAL cRef := IIF( .T., @cHello, )

The trick is using IIF() which allows for using the @ operator since

/// BAD

LOCAL cHello := "hello world"
LOCAL cRef := @cHello

doesn't compile

But (to my expectations) the most surprizingly supported behaviour is that
the RETURN of a function can also be a 'reference' to another variable,
although (and according to C++ prescription) in that case, beware to only
reference STATIC variables, since LOCALs (created on the stack) will loose
their value when the function is returning

/// MODULE 1

STATIC cHello := "hello world"

FUNCTION ref ()
RETURN IIF( .T., @cHello, )

FUNCTION salute ()
QOUT( cHello )
RETURN NIL

/// MODULE 2

FUNCTION main ()
LOCAL string := ref()

salute() // "hello world"
string := "bye world" // changing cHello from MODULE 1!!!
salute() // "bye world"

RETURN NIL

Clipper is really amazing! :-)))

Frank



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Hey Frank,

Thank you for your thoughts!

> Clipper is really amazing! :-)))

It is!! ;-))

And [x]Harbour is its successor ;-))

Patrick

Hi Patrick,

> Thank you for your thoughts!
>
>> Clipper is really amazing! :-)))
>
> It is!! ;-))
>
> And [x]Harbour is its successor ;-))

I second that without doubt - now, if only my endeavour could be moved into
these waters, a real (and fast) transpiler for my (o)ceans project (still
targeting clipper at first) would be veryyy welcome, then to enlarge the
project's scope to all the additional features of the harbours; s.o. could
do me a real favour regarding this :-| <g>

See you

Frank




--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Dear lohen:

On Monday, July 30, 2012 9:34:55 AM UTC-7, lohen no_underscores wrote:
....
> I second that without doubt - now, if only my
> endeavour could be moved into these waters, a
> real (and fast) transpiler for my (o)ceans
> project (still targeting clipper at first)
> would be veryyy welcome,

Did you use any 3rd party libraries? Is your code Clipper 5.3, or something else? Either (x)Harbour can take Clipper 5.3 + most of Clipper Tools (??? Harbour folks, yes?) straight up.

> then to enlarge the project's scope to all
> the additional features of the harbours;

This is going to take intentional programmer effort. There are "100" ways each programmer can and does code operator interfaces over his/her life, multiplied by the number of programmers, then the number of available GUIs (as just an example). Computers are not yet smarter than ourselves.

David A. Smith

Hi David,

"dlzc" schreef in bericht
news:b3e5bb5c-b565-4bb1-8392-abf67089ecbf@googlegroups.com...

On Monday, July 30, 2012 9:34:55 AM UTC-7, lohen no_underscores wrote:
....
>> I second that without doubt - now, if only my
>> endeavour could be moved into these waters, a
>> real (and fast) transpiler for my (o)ceans
>> project (still targeting clipper at first)
>> would be veryyy welcome,

> Did you use any 3rd party libraries? Is your code Clipper 5.3, or
> something else? Either (x)Harbour can take Clipper 5.3 + most of Clipper
> Tools (??? Harbour folks, yes?) straight up.

It's sth else, there are two aspects to that:

Syntactically the project's language first needs to be transpiled into pure
Clipper (or [x]harbour); after that phase it is syntactically legal .prg
code, at least still now for the Clipper target (compiler) only (which i do
not expect problems with for the [x]harbour's compilers, except perhaps
class(y) based constructs which aren't fully supported (yet?) by the latter
compilers, like class messages allowing for real virtual behaviour - just
like what is possible for instance objects - which requires class objects,
inheriting from each other in parallel with the inheritance scheme of
instance objects, but this is in se not about Clipper syntax unable to be
compiled by [x]Harbour, more about runtime library differences)

The other aspect is in api's (also with respect to 3rd party libraries); the
project uses its own diverging names (a totally redesigned naming scheme,
compared to vintage names for functions, also from 3rd party libraries - but
still now only with respect to a handful of libs), which are transpiled into
the legacy names if during build it is said to do so, or transpiled into OO
calls; these calls most of the time are wrappers for native types,
eventually calling the vintage functions (by their legacy names), but this
can be done differently when the sources to these would be available (as in
the [x]harbours, so here they could benefit from performance improvement,
not in Clipper (with closed sources))

The emphasis of this is to escape from legacy, from procedural style (also
from cryptic function names) and have more C++ elements in the project's
language proper

The idea originated from a long time ago, always having cursed
one-namespace-only sharing of function names; so, for the project's double
aim of getting away from both procedural paradigm and legacy names,
everything is redesigned in an OO jacket, with the aid of both a mechanism
supporting native types through OO, and emulating namespaces (for functions
that do not fall in the category of native types, nor real classes); all of
these introduce total polymorphism (regardless it being transpiled back into
legacy names, depending on a build setting (and only in certain
circumstances, depending on what the project differentiates into
internalized/externalized ports of api's)); this was its first aim

Later, other features were added but yet limited since all of these require
Clipper-language (and -compiler (still at this point)) compatible constructs
(some of them runtime-constructs); the shown 'reference' feature will make
it into the project's language, transparent for users (only the transpile
output will contain the IIF(.T.,@<var>,) code) but of course introducing yet
another C++ borrowed syntax element, to say the type& notation

Transpile functionality is presently available, but it is slow, and not
based on parser and lexer technology; at this point it is sufficient to
show-case the project, and regarding 3rd party libraries, as said, there are
a handful inserted (also with redesigned api's); the project has a
reasonable code base and porting the api documentation is going on as we
speak (alot already done also), but it must be stressed that there are two
among which currently don't exist in a [x]Harbour port (using .c code still
pretty much linked with the Clipper extend system (and beyond))

My mentioned concern is with the performance (and some other aspects) of the
transpile process; here, professional intervention would be welcome

However, the project is a blueprint, although the concept can evolve into
the [x]Harbour compilers, both at language syntax level and even 3rd party
library coverage (although this is alot of work, i can tell); the project's
language stands on its own, but _always_ needs an underlying compiler; so
yes, the [x]Harbour's are Clipper's present and future; (o)ceans' would very
much like to grow along - not being competition, just another presentation
of the language we all love (isn't that a one-liner to score with<g>)

>> then to enlarge the project's scope to all
>> the additional features of the harbours;

> This is going to take intentional programmer effort. There are "100" ways
> each programmer can and does code operator interfaces over his/her life,
> multiplied by the number of programmers, then the number of available GUIs
> (as just an example). Computers are not yet smarter than ourselves.

I think you got this right, very indeed - let's just watch it from this
perspective: does innovation only applies to the performance we gain, the
bits we can squeeze, the features the language is elegantly to present?
(list to complete ... OS compatibility among others)

Wouldn't innovation also cover the challenge improving the api's on a
formalistic level (more natural thanks to namespaces and polymorphism
(perhaps with additional mnemotechnical value))?

This was the scope it got started with, and ever since with a very modest
expectation with respect to its applicability (or reception)

Nevertheless, it is there now, thought i could just as well make mention of
it ;-)

Regards,

Frank



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Dear lohen:

On Monday, July 30, 2012 1:40:43 PM UTC-7, lohen no_underscores wrote:
....
> Syntactically the project's language first needs to
> be transpiled into pure Clipper (or [x]harbour);
> after that phase it is syntactically legal .prg
> code, at least still now for the Clipper target
> (compiler) only (which i do not expect problems
> with for the [x]harbour's compilers, except
> perhaps class(y) based constructs which aren't
> fully supported (yet?) by the latter compilers,
> like class messages allowing for real virtual
> behaviour - just like what is possible for
> instance objects - which requires class objects,
> inheriting from each other in parallel with the
> inheritance scheme of instance objects, but this
> is in se not about Clipper syntax unable to be
> compiled by [x]Harbour, more about runtime
> library differences)

Klas needs to weigh in on this. I made one class, one time, he helped me tremendously, and I did not delve further. How much either compiler implements Class(y) behavior is part of what got Harbour reinvigorated.

....
> The emphasis of this is to escape from legacy,
> from procedural style (also from cryptic
> function names) and have more C++ elements in
> the project's language proper

Then I think any effort you put into "baby stepping" into (x)Harbour will be wasted time. You "should" move straight to OOP.

....
> >> then to enlarge the project's scope to all
> >> the additional features of the harbours;
>
>
>
> > This is going to take intentional programmer
> > effort. There are "100" ways each programmer
> > can and does code operator interfaces over
> > his/her life, multiplied by the number of
> > programmers, then the number of available GUIs
> > (as just an example). Computers are not yet
> > smarter than ourselves.
>
> I think you got this right, very indeed -
> let's just watch it from this perspective:
> does innovation only applies to the
> performance we gain, the bits we can squeeze,
> the features the language is elegantly to
> present?

Innovation is driven by need. A new task needs done, error handling needs done better, the operating system no longer supports the old procedures.

> (list to complete ... OS compatibility among
> others)

Yes.

> Wouldn't innovation also cover the challenge
> improving the api's on a formalistic level (more
> natural thanks to namespaces and polymorphism
> (perhaps with additional mnemotechnical value))?

I would not call that "innovation", more "administrivia" (though that will get me hit). If it makes it orders of magnitude easier to troubleshoot, ororders of magnitude easier to maintain, then it would be innovation. APIsshould be "static" in the same sense that the Clipper language is calls toa Clipper API built into CLIPPER.LIB. You can extend, but not redefine.

> This was the scope it got started with, and
> ever since with a very modest expectation
> with respect to its applicability (or
> reception)

Better newsgroups for this discussion, but thanks for bringing it here.

David A. Smith

Hi David,

>> Syntactically the project's language first needs to
>> be transpiled into pure Clipper (or [x]harbour);
>> after that phase it is syntactically legal .prg
>> code, at least still now for the Clipper target
>> (compiler) only (which i do not expect problems
>> with for the [x]harbour's compilers, except
>> perhaps class(y) based constructs which aren't
>> fully supported (yet?) by the latter compilers,
>> like class messages allowing for real virtual
>> behaviour - just like what is possible for
>> instance objects - which requires class objects,
>> inheriting from each other in parallel with the
>> inheritance scheme of instance objects, but this
>> is in se not about Clipper syntax unable to be
>> compiled by [x]Harbour, more about runtime
>> library differences)
>
> Klas needs to weigh in on this. I made one class, one time, he helped me
> tremendously, and I did not delve further. How much either compiler implements
> Class(y) behavior is part of what got Harbour reinvigorated.

No, I am afraid I cannot help Frank with OOP "stuff" on the level he is
doing it with the (o)ceans project. It is rather the other way around :-)

Regards,
Klas

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Hi David,

"dlzc" schreef in bericht
news:32e8a05f-4ef0-4903-8c4b-2526f0be6087@googlegroups.com...

>> ... which requires class objects,
>> inheriting from each other in parallel with the
>> inheritance scheme of instance objects, but this
>> is in se not about Clipper syntax unable to be
>> compiled by [x]Harbour, more about runtime
>> library differences)

> Klas needs to weigh in on this. I made one class, one time, he helped me
> tremendously, and I did not delve further. How much either compiler
> implements Class(y) behavior is part of what got Harbour reinvigorated.

Perhaps next year a developer's guide for the project will materialize; i'm
not decided yet about its scope, regarding OO f.i., should it be written
from the ground up, or will a crash course to the project's specific needs
suffice? Not to forget it is neither for me a subject totally well known
(and my knowledge is very much bound to what i grapsed about Class(y))

Apart from that, with respect to [x]Harbour (and reasonably true with
respect to so many implementation, through other OO libraries (for Clipper
then)) documentation going far beyond api's, or the basics, is sth ppl
should take a chance on writing, imo (but then with respect to Clipper's
successors); alto then again, as (most) everyone is lacking the time, i
think this is a good reason to parallel Open Source projects with a
Commercial branch (as in xHarbour's case) - anyhow, i've had this discussion
with some friends in private, opinions remaining divided :-|

>> The emphasis of this is to escape from legacy,
>> from procedural style (also from cryptic
>> function names) and have more C++ elements in
>> the project's language proper

> Then I think any effort you put into "baby stepping" into (x)Harbour will
> be wasted time.

I'm not sure i understand what is referred to here :-) Perhaps mentioning
again, Clipper's standard libraries aren't OO either, and yet i found a way
to write in OO style and have the transpile process output in what the
Clipper runtime can cope with; the same is possible for [x]Harbour; but you
pbly meant sth else?

>> I think you got this right, very indeed -
>> let's just watch it from this perspective:
>> does innovation only applies to the
>> performance we gain, the bits we can squeeze,
>> the features the language is elegantly to
>> present?

> Innovation is driven by need. A new task needs done, error handling needs
> done better, the operating system no longer supports the old procedures.

Then it's just me? To want getting rid of awkward and cryptic function
names (as in CT), anyhow here it is where my 'need' originated from; but
regardless, i understand what you're saying; only, is it so far fetched to
want a redesigned api? Moreover, since it is not competition: the legacy
(or vintage) names may well remain what they are (or were); the project's
'presentation' innovates on that formal aspect; would i remain standing
alone with this, for the rest of the [x]Harbour's lifetime? If ever the
urge arises from those projects to also with respect to that aspect,
introduce new ideas, in order to not 50 years after Clipper (just a guess)
still have to deal with what legacy back then dictated, then there's this
project's show-case, perhaps just to have a glimpse of, about how it was
shapened there; and in the meantime, (o)ceans _doesn't precipitate rushing
that idea_ for those willing to step into that aspect much before; best of
both, yes?

>> Wouldn't innovation also cover the challenge
>> improving the api's on a formalistic level (more
>> natural thanks to namespaces and polymorphism
>> (perhaps with additional mnemotechnical value))?

> I would not call that "innovation", more "administrivia" (though that will
> get me hit).

I have no problem with that

> If it makes it orders of magnitude easier to troubleshoot, or orders of
> magnitude easier to maintain, then it would be innovation. APIs should be
> "static" in the same sense that the Clipper language is calls to a Clipper
> API built into CLIPPER.LIB. You can extend, but not redefine.

It's not choosing for the easiest path, changing api's; but still somewhere,
sometime, wouldn't it be great to have a new set to play with, especially
when it is more memory friendly; remember the Clipper 5.0 DB*() function
names, continued into the 5.2 version, then 5.3 emerging with some new and
some changed names; 5.2e finally integrating stuff that came from the 5.3
line (it's easy to deduct from the 5.2e Norton Guide, section "Drivers"),
and here the mess starts; how many longer will it take before redressing, in
order to smooth'en these differences: with another function based api
perhaps? Yet more cryptic names perhaps? One can picture!

>> This was the scope it got started with, and
>> ever since with a very modest expectation
>> with respect to its applicability (or
>> reception)

> Better newsgroups for this discussion, but thanks for bringing it here.

Here's fine; anyway, it's really not about any agenda either; if all else,
the project's going to live its own life somewhere on a server (having seen
nice examples of that, fyi http://sourceforge.net/projects/code-browser/ it
has its own language being programmed in, and the language as such is not
even the focus of the project;-)

Thanks David, for allowing/inviting me to comment

Best regards,

Frank



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Dear Frank:

On Tuesday, July 31, 2012 4:53:14 AM UTC-7, lohen no_underscores wrote:
....
> i think this is a good reason to parallel Open Source
> projects with a Commercial branch (as in xHarbour's
> case) - anyhow, i've had this discussion with some
> friends in private, opinions remaining divided :-|

Imagine that division should be found there! I do like open source, and having a commercial branch is almost anathema to having open source.

....
> > Then I think any effort you put into "baby
> > stepping" into (x)Harbour will be wasted time.
>
> I'm not sure i understand what is referred to
> here :-) Perhaps mentioning again, Clipper's
> standard libraries aren't OO either, and yet
> i found a way to write in OO style and have
> the transpile process output in what the
> Clipper runtime can cope with; the same is
> possible for [x]Harbour; but you pbly meant
> sth else?

I get the gist of what you are saying. Ron Pinkas developed Visual xHarbour along the lines of Visual Basic, allowing easy transition. You propose to make a variant of Clipper that will be more programmer friendly to the OOcrowd. Perhaps draw "converts".

As to what I meant, you were planning on C++-izing the language, but I incorrectly heard that you wanted to end up on C++.

> >> I think you got this right, very indeed -
> >> let's just watch it from this perspective:
> >> does innovation only applies to the
> >> performance we gain, the bits we can squeeze,
> >> the features the language is elegantly to
> >> present?
>
> > Innovation is driven by need. A new task
> > needs done, error handling needs done better,
> > the operating system no longer supports the
> > old procedures.
>
> Then it's just me? To want getting rid of
> awkward and cryptic function names (as in CT),
> anyhow here it is where my 'need' originated
> from; but regardless, i understand what you're
> saying; only, is it so far fetched to want a
> redesigned api?

The key is documentation. (x)Harbour has run for years without creating documentation different than Clipper's. (Both have some much better documentation now.) The terse 8 or 10 character name-limit of Clipper is lifted.

> Moreover, since it is not competition: the
> legacy (or vintage) names may well remain
> what they are (or were);

Across the board, a preprocessor can translate old to new, then proceed. Much as the compiler translates Clipper to C.

> the project's 'presentation' innovates on
> that formal aspect; would i remain standing
> alone with this, for the rest of the
> [x]Harbour's lifetime?

Some will join. I am an old, code-from-keyboard, self-taught, procedural programmer. Not sure how anyone would know about your efforts. Watching would be a good learning exercise for *me*...

> If ever the urge arises from those projects
> to also with respect to that aspect,
> introduce new ideas, in order to not 50 years
> after Clipper (just a guess) still have to
> deal with what legacy back then dictated, then
> there's this project's show-case, perhaps just
> to have a glimpse of, about how it was
> shapened there; and in the meantime, (o)ceans
> _doesn't precipitate rushing that idea_ for
> those willing to step into that aspect much
> before; best of both, yes?

If you cannot get new converts with your efforts, they will probably extendfrom Java or some such.

Can you link to "oceans", with a context to your meaning? Not this?
http://sourceforge.net/projects/ocea...urce=directory

....
> > If it makes it orders of magnitude easier to
> > troubleshoot, or orders of magnitude easier
> > to maintain, then it would be innovation.
> > APIs should be "static" in the same sense that
> > the Clipper language is calls to a Clipper
> > API built into CLIPPER.LIB. You can extend,
> > but not redefine.
>
> It's not choosing for the easiest path, changing
> api's; but still somewhere, sometime, wouldn't it
> be great to have a new set to play with, especially
> when it is more memory friendly;

And here is the rub. This may be more of a cultural difference:
http://www.goodreads.com/quotes/1303...lleys-beats-up

English speakers are used to hoards of "discontinuous" words stolen from other languages. And ultimately, any language must be dynamic, able to pick up new words as the Universe tends towards entropy (in the sense of more possible states).

I do not belittle your desire here. I do not think you are alone. I just cannot imagine your population of future users.

> remember the Clipper 5.0 DB*() function names,
> continued into the 5.2 version, then 5.3
> emerging with some new and some changed names;
> 5.2e finally integrating stuff that came from
> the 5.3 line (it's easy to deduct from the
> 5.2e Norton Guide, section "Drivers"), and
> here the mess starts;

It really started with dBase II to dBase III+, and got way worse by the time of Clipper S'87. That is a problem with not starting a language with a clean sheet. And there are reasons not to do that.

> how many longer will it take before redressing,
> in order to smooth'en these differences: with
> another function based api perhaps? Yet more
> cryptic names perhaps? One can picture!

I agree with the sentiment. But if you leave the sow's ear in the mix, there will always be the smell of sow to the silk purse. I browsed sourceforge and found a list of many C "modules" that could be wrapped to provide extended (x)Harbour capability. The list becomes nearly uncountable if we could use C++ "modules". I think we need revolution here, and evolution simply will not do.

> >> This was the scope it got started with, and
> >> ever since with a very modest expectation
> >> with respect to its applicability (or
> >> reception)
>
> > Better newsgroups for this discussion, but
> > thanks for bringing it here.
>
> Here's fine; anyway, it's really not about
> any agenda either; if all else, the project's
> going to live its own life somewhere on a
> server (having seen nice examples of that, fyi
> http://sourceforge.net/projects/code-browser/
> it has its own language being programmed in,
> and the language as such is not even the focus
> of the project;-)
>
> Thanks David, for allowing/inviting me to comment

I always enjoy a conversation where I do not end up stepping on toes. And rather than "allow", I welcome the opinions of someone that has been in thetrenches, and contributes to the conversation.

Clipper is a "Swiss Army Knife", and you want it to be a bit more of a machine shop. Or Clipper is a one-man-band, and you want it to be more of an orchestra.

I'd be happy with an open source GUI, that (x)Harbour could interface with along the lines of an RDD.

I hope I have not hijacked this thread. Please do not take me being only 1of 2 responders as anything other than an indication of how many people get involved in this newsgroup. There may be lots of people that will be more encouraging if you post to an (x)Harbour newsgroup (if your NSP carries it, comp.lang.xharbour is one for xHarbour). For Harbour, Klas might recommend:
https://groups.google.com/forum/?fro.../harbour-devel
.... with the proviso to "beware of the noise".

David A. Smith

Hi David,

"dlzc" schreef in bericht
news:2b6b506b-d698-44bb-bf94-50b38f73cfe9@googlegroups.com...

>> i think this is a good reason to parallel Open Source
>> projects with a Commercial branch (as in xHarbour's
>> case) - anyhow, i've had this discussion with some
>> friends in private, opinions remaining divided :-|

> Imagine that division should be found there! I do like open source, and
> having a commercial branch is almost anathema to having open source.

Complementing each other, why not? An Open Source branch to provide code
wrappers + docs + build system already (in case of my project), and the
Commerical one to provide non-wrapper (transcribed) sources + a better build
system, noone is left excluded; this externalized/internalized feature is
kind of a business model, as i figure it to become, if there's interest

>>> Then I think any effort you put into "baby
>>> stepping" into (x)Harbour will be wasted time.
>> I'm not sure i understand what is referred to
>> here :-) Perhaps mentioning again, Clipper's
>> standard libraries aren't OO either, and yet
>> i found a way to write in OO style and have
>> the transpile process output in what the
>> Clipper runtime can cope with; the same is
>> possible for [x]Harbour; but you pbly meant
>> sth else?

> I get the gist of what you are saying. Ron Pinkas developed Visual
> xHarbour along the lines of Visual Basic, allowing easy transition. You
> propose to make a variant of Clipper that will be more programmer friendly
> to the OO crowd. Perhaps draw "converts".

The last thing that the community needs is another (diverging) xBase, i'm
well aware of; so here's a more complete answer as to my hopes, about you're
saying

> This is going to take intentional programmer effort. There are "100" ways
> each programmer can and does code operator interfaces over his/her life,
> multiplied by the number of programmers, then the number of available GUIs
> (as just an example). Computers are not yet smarter than ourselves.

If the project could get wide acceptance about this redesigned api's, among
different players, it might unify instead of divide; my efforts are not in
stone, discussion is open, and with respect to sth called ontoi (native type
OO support), it is a completely parallel implementation, not competing with
the vintage way of handling them, that could in a first stage become
available to the different xBase's as to wait and see how many users will
make use of it; to take the rest of the project's ideas or leave it from
there, but it is mandatory that there should be consensus about the new
api's; in this sense, the project is but a thinktank, not a (proprietary)
business entreprise; so, imho, it is not about converts, other perhaps than
the main players to sit down together and consider; my role is not important
in this

> As to what I meant, you were planning on C++-izing the language, but I
> incorrectly heard that you wanted to end up on C++.

No, apart from mention in one of my notes, about having aimed at being
suited as a language for the C++/# paradigm (C calling convention versus
Pascal; the project is hiding the Clipper proper use of Pascal convention,
by stepping away from the use of the @ operator, under the hood inserting it
automatically where needed, and mimicing C calling convention merely
syntactically (in the argument list to messages)) - but then again, C++/#
readiness pbly involves so much more than only this aspect - there is no
technical affinity prevalence to C++; it's more that some syntax elements
are a litlle less verbose (remember Pascal: BEGIN ... END - so much typing
whereas { ... } can do just as well)

>>> Innovation is driven by need. A new task
>>> needs done, error handling needs done better,
>>> the operating system no longer supports the
>>> old procedures.

>> Then it's just me? To want getting rid of
>> awkward and cryptic function names (as in CT),
>> anyhow here it is where my 'need' originated
>> from; but regardless, i understand what you're
>> saying; only, is it so far fetched to want a
>> redesigned api?

> The key is documentation. (x)Harbour has run for years without creating
> documentation different than Clipper's. (Both have some much better
> documentation now.) The terse 8 or 10 character name-limit of Clipper is
> lifted.

Yes, that has improved; perhaps too weird to expect overall compliance (also
from 3rd parties) to adopt kind of a common vocabulary for naming messages
(or even still for functions), and/or rules to how to form good chosen names
(f.i. have SET*() names always operate as the SET() function, to say, assign
a new value or access the current one, depending on the optional argument;
in that case function names such as DBSETINDEX(), DBSETFILTER() etc, also
already should become sth else .oO sth that (o)ceans solves by the idea of
'applying' (DBSETINDEX() -> applyIndex/DBCLEARINDEX() -> clearIndex,
inspired by the TBrowse applyFocus/clearFocus pair (although already here
having straigthened vintage use of 'kill' .oO sounding so harsh;-) (as in
killFocus -> clearFocus)))), then there's the Hungarian notation aspect (it
has well been elaborated in the project's (o)ceans' notation alternative
white paper (in the docs)) .oO how much longer will there be no further
distinction for oType where 'o' only weakly denotes 'object' ... what
object? what type of object? (and so on)

Okay, this is going on and on, but this is just about the area of expertise
aimed at by (o)ceans (and it will not want to rush anything, nor anyone)

>> Moreover, since it is not competition: the
>> legacy (or vintage) names may well remain
>> what they are (or were);

> Across the board, a preprocessor can translate old to new, then proceed.
> Much as the compiler translates Clipper to C.

The current transpilation implementation is based on a multipass PP
operation .oO which turns out being too slow

>> the project's 'presentation' innovates on
>> that formal aspect; would i remain standing
>> alone with this, for the rest of the
>> [x]Harbour's lifetime?

> Some will join. I am an old, code-from-keyboard, self-taught, procedural
> programmer. Not sure how anyone would know about your efforts. Watching
> would be a good learning exercise for *me*...

:-)

> If you cannot get new converts with your efforts, they will probably
> extend from Java or some such.

Step forward! .oO i'm done, targeting Ca-Clipper as a means of blueprinting
the ideas is my only ambition :-)

> Can you link to "oceans", with a context to your meaning? Not this?
> http://sourceforge.net/projects/ocea...urce=directory

Nope, it's not (yet) on sf, someone with good SVN knowledge could help me
alot .oO preferably requiring a double trunk setup (don't know how to/if
this has been done)

But a preview, and the complete (sofar) documentation is available from the
4shared website (google for "_o_ceans")

>> It's not choosing for the easiest path, changing
>> api's; but still somewhere, sometime, wouldn't it
>> be great to have a new set to play with, especially
>> when it is more memory friendly;

> And here is the rub. This may be more of a cultural difference:
> http://www.goodreads.com/quotes/1303...lleys-beats-up

> English speakers are used to hoards of "discontinuous" words stolen from
> other languages. And ultimately, any language must be dynamic, able to
> pick up new words as the Universe tends towards entropy (in the sense of
> more possible states).

beyond my understanding (or perhaps not understanding the idiom of
expressions you're using .oO no native English speaking here;-)

> I do not belittle your desire here. I do not think you are alone. I just
> cannot imagine your population of future users.

Management?

>> remember the Clipper 5.0 DB*() function names,
>> continued into the 5.2 version, then 5.3
>> emerging with some new and some changed names;
>> 5.2e finally integrating stuff that came from
>> the 5.3 line (it's easy to deduct from the
>> 5.2e Norton Guide, section "Drivers"), and
>> here the mess starts;

> It really started with dBase II to dBase III+, and got way worse by the
> time of Clipper S'87. That is a problem with not starting a language with
> a clean sheet. And there are reasons not to do that.

Most of the time, 3rd parties setting up their brand new Class hierachies
work around that problem by introducing classes so as not having to deal
with the basic functions no longer, only using the messages and properties
from their classes; ObjectDB did so too, but especially regarding, were
there so many to make use of ODB (or FiveDB); it seems to me, xBase
programmer's tend to use the Clipper language and runtime function set at
the basis; clearing this set from ambiguities (or less understood legacy
overhaul) still is a good reason, yes?

>> how many longer will it take before redressing,
>> in order to smooth'en these differences: with
>> another function based api perhaps? Yet more
>> cryptic names perhaps? One can picture!

> I agree with the sentiment. But if you leave the sow's ear in the mix,
> there will always be the smell of sow to the silk purse.

I'm sorry, i do not know what this means

> I browsed sourceforge and found a list of many C "modules" that could be
> wrapped to provide extended (x)Harbour capability. The list becomes
> nearly uncountable if we could use C++ "modules". I think we need
> revolution here, and evolution simply will not do.

This is not at stake in this regard (i'm not sure how you went from A to B
here?)

>> Thanks David, for allowing/inviting me to comment

> I always enjoy a conversation where I do not end up stepping on toes. And
> rather than "allow", I welcome the opinions of someone that has been in
> the trenches, and contributes to the conversation.

:-)

> Clipper is a "Swiss Army Knife", and you want it to be a bit more of a
> machine shop. Or Clipper is a one-man-band, and you want it to be more of
> an orchestra.

What i'd really welcome is to succeed in getting the best of Clipper to
eventually present it in a way (i've personally researched and been provided
with by the rich 3rd party community from those days) that makes for a
platfrom to explore, derive ideas from, evaluate aspects from (it's
functional, not to forget) and help the players decide on features that are
perhaps a little bit less important (compared to web accesibility,
compatibility with/intergration of so many new technolgies), perhaps even a
little bit 'forgotten'

> I'd be happy with an open source GUI, that (x)Harbour could interface with
> along the lines of an RDD.

Answering by means of yours (previous)

>>> Better newsgroups for this discussion, but ...

> I hope I have not hijacked this thread. Please do not take me being only
> 1 of 2 responders as anything other than an indication of how many people
> get involved in this newsgroup. There may be lots of people that will be
> more encouraging if you post to an (x)Harbour newsgroup (if your NSP
> carries it, comp.lang.xharbour is one for xHarbour). For Harbour, Klas
> might recommend:
https://groups.google.com/forum/?fro.../harbour-devel
.... with the proviso to "beware of the noise".

Okay, it's an exchange :-)

Regards,

Frank



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Dear Frank:

On Wednesday, August 1, 2012 4:22:14 AM UTC-7, freenews.netfront.net no_underscores wrote:

.... yes we have gone on and on. I will just answer questions.


> > Can you link to "oceans", with a context to
> > your meaning? Not this?
>
> > http://sourceforge.net/projects/ocea...urce=directory
>
> Nope, it's not (yet) on sf, someone with good SVN
> knowledge could help me alot .oO preferably
> requiring a double trunk setup (don't know how to/if
> this has been done)
>
> But a preview, and the complete (sofar)
> documentation is available from the
> 4shared website (google for "_o_ceans")

OK.

....
> >> It's not choosing for the easiest path,
> >> changing api's; but still somewhere,
> >> sometime, wouldn't it be great to have a
> >> new set to play with, especially when it
> >> is more memory friendly;
>
> > And here is the rub. This may be more of
> > a cultural difference:
>
> > http://www.goodreads.com/quotes/1303...lleys-beats-up
>
> > English speakers are used to hoards of
> > "discontinuous" words stolen from other
> > languages. And ultimately, any language
> > must be dynamic, able to pick up new words
> > as the Universe tends towards entropy (in
> > the sense of more possible states).
>
> beyond my understanding (or perhaps not
> understanding the idiom of expressions you're
> using .oO no native English speaking here;-)

You are seeking a single, homogeneous OO language. You represent it as "hard" to remember each of the keywords, keywords that were agglomerated each time Clipper grew. Languages grow, as it becomes necessary to access new functionality. So too, your OO underpinning or overlayer, will need to grow..

> > I do not belittle your desire here. I do not
> > think you are alone. I just cannot imagine
> > your population of future users.
>
> Management?

Never dealt with management that knew much more than how to turn a computeron. But then I am not an IT pro.

....
> >> how many longer will it take before redressing,
> >> in order to smooth'en these differences: with
> >> another function based api perhaps? Yet more
> >> cryptic names perhaps? One can picture!
>
> > I agree with the sentiment. But if you leave
> > the sow's ear in the mix, there will always be
> > the smell of sow to the silk purse.
>
> I'm sorry, i do not know what this means

Reference to the saying, "you cannot make a silk purse out of a sow's ear".If the cryptic function names are in there still, your OO (if an overwrapper) will have warts / discontinuities / issues.

> > I browsed sourceforge and found a list of
> > many C "modules" that could be wrapped to
> > provide extended (x)Harbour capability.
> > The list becomes nearly uncountable if we
> > could use C++ "modules". I think we need
> > revolution here, and evolution simply will
> > not do.
>
> This is not at stake in this regard (i'm not
> sure how you went from A to B here?)

Languages need to grow, or they fall into disuse.

Being able to incorporate open source modules, is a painless way to grow.

If we are limited to C modules, because our compiler produces C, and our libraries can only talk to C, then we can only incorporate C modules.

To use C++ modules as sourceforge presents them, we need Clipper to generate C++ calls into C++ library modules. Revolution (changing from C to C++) means a complete rewrite.

....
> Okay, it's an exchange :-)


And a pleasant one. Thank you.

David A. Smith