World: r3wp

Ladislav, I have no problem in principle with adapting some of the 
code in your include stuff to make a PREBOL superset with inherent 
support for R3's modules. However, if your preprocessor doesn't support 
collecting modules with R3's module syntax, then it's of no direct 
use to me for R3 code. And the great thing about a PREBOL superset 
is that #include is *not* a function, it's a directive.

That's right.

I have had frequent need for modifying INCLUDE and EXCLUDE, but not 
as much need for the non-modifying stuff. To each their own.

The non-modifying version of EXCLUDE should be called EXCLUDING, 
if we want the part of speech right :)

Hmm, EXCLUDING's not a bad way to avoid clashing meanings for EXCLUDE.

A problem with INCLUDE is that it sounds like INSERT, but the functionality 
is APPEND (which is INSERT TAIL, ok). So what if we also want conditional 
INSERT ? I think we don't want it as often as APPEND, but it could 
be more flexible, allowing different positions to insert.

Is it really so bad to do conditional code with conditional code? 
We have IF, EITHER and UNTIL for a reason. They are not awkward.

It's not so bad, but it would be nice to have, if we could just come 
up with some good function names...

It's a pity if the reason we don't add convenient functions like 
this is just because we haven't found good names for them.

we have already weird naming conventions, e.g. in case of 'ajoin. 
So what about cinsert, cappend? ('"c" like conditional, or "a", to 
be compatible with 'ajoin)

Btw, "it's on my list" is more of a desperate cry for help nowadays. 
It's more of a "it's on my list to get done, because it's needed". 
Actually doing it myself is the last resort; getting someone else 
to do it is the preferred method. I'm more than happy to provide 
advice, but it's hard for me to budget time to program this myself.

I was thinking of "cinsert" and "cappend" too. But note, "adjoin" 
is a normal existing english word, from Anglo-French "ajoindre".

That last resort seems to happen a lot though.

Fair enough, Brian. You're handling many areas already.

Sorry, this isn't the ~Vent group :)

Just looking in the thesaurus.
Possible other names for INCLUDE / EXCLUDE:
	ENTAIL / OMIT   <- ENTAIL good for conditional append.
	ADMIT / OMIT   <-  ADMIT good for conditional insert.
Nice and short, eh?

I like explode/implode ... :-)

Looking over your %include.r docs again Ladislav, the only problems 
it has for R3 development (aside from function naming) is that it 
doesn't support collecting modules. Since all R3 development directly 
or indirectly uses R3's modules, it's only missing the main feature 
needed. But at least the rest is done, so adding module collection 
could be done by anyone who understands the semantic model of R3's 
modules well enough.

That's not a long list of people at this point, but at least it's 
not just one person :)

BrianH: so no free time on your part last days?

The non-modifying version of EXCLUDE should be called EXCLUDING
 - for me this is as good as "EXPLODE", just a mess

Last 3 or 4 months. I've been averaging about 1 day a week in front 
of a computer. I spend more time in my car.

'EXCLUDE is corresponding well to 'SUBTRACT of 'DIVIDE, which are 
non-modifying either

Then you need a laptom in your car .... :-)

laptop

I see EXCLUDE as more useful than UNION, actually, when comparing 
the usefulness of set operations

I spend all my time solving problems now. My mind is what needs budgeting, 
more than time or money. A laptop in the car wouldn't help with that.

(it is even possible to define UNION using EXCLUDE, while the reverse 
is impossible)

Ladislav, I don't really need to get into the naming mess. I have 
needed the functionality I described for the modifying INCLUDE and 
EXCLUDE for a long time now, especially as modifying set functions 
rather than just single values like ALTER. But I can continue to 
get by without. And it turns out that the set functions often need 
to allocate another series anyways, for hashing, so the modifying 
versions probably don't have enough of a benefit to be worth adding.

However, that doesn't mean that I would call your preprocessor INCLUDE 
in the standard distribution. We need a superset of PREBOL to *be* 
the new PREBOL. The functionality we are missing is the bare minimum 
that we need to make it useful for R3 development, so if we make 
a standard preprocessor it would have to have that feature. And if 
your %include.r is a better codebase to start with, cool.

certainly, the name of the function is not the most important property 
of it

...and the directives are standard

(except for COMMENT, but that looks reasonable to me, alghough I 
am not the one who requested that)

Right. For one thing, the actual including is done in response to 
the directives. The function is preprocessing, and its results are 
not actually included at the point of call :)

the function is two-purpose:

*preprocess
*plus, eventually, if desired, do the result of the preprocessing

The R3 preprocessor would most of all need to transform script modules 
to inline modules, add the code to resolve the binding issues, and 
especially handle mixins. All of the traditional PREBOL functionality 
is secondary to that, and use of the directives will be more minimal.

Mixins in R3 often serve the purpose that #include did in PREBOL, 
but currently need to be loaded from files at runtime. We need a 
preprocessor in order to get the mixin functionality from embedded 
modules. This is what is needed to do the R3 equivalent of encapping 
(host builds).

If I have to do this, I won't even be able to start until some time 
in June - I'm mostly out of town this month.

Samsung announced a bada Developer Challenge developer.bada.com/challenge.
How far away is a host-kit for ARM devices?

as far away as it was a few months ago

Carl's last words on the subject "let's do it"

Carl's not available ATM ...

...handle mixins...
 - is there already any documentation describing mixins?

At the beginning of the year I was almost ready to bet  that we will 
get it until June.(

We all were. The first negative sign for me was, when Carl announced, 
that he is not going to post montly updates. Those were much appreciated 
and motivating. I knew, that it means just one thing - Carl going 
into the cave mode. R3 is almost on-hold for 5 months ....

I hope someone will soon post something on a more positive note :-)

stop being obsessive about deadlines and you'll feel much better.

it's not about deadlines, it is about any sign of project management, 
coordinated efforts, estimated milestones, defined featureset ....

Carl is working on bug-fixing, did two releases last week, and is 
working on extracting view from the core, which he has stated a while 
ago.


What do you want Carl to do more?     AFAIK, there is nothing "unknown" 
right now.   we are simply waiting for Carl to finish this cumbersome 
task before any  of the above *can* be done.


so far, Carl has been telling us everything he's doing every step 
of the way.   some things just take time.  its not as if Carl is 
waiting doing nothing.  

He's been working his ass off  tackling huge items on the list.  
Some of the very things you (and many of us) have been "complaining" 
about for years.

two releases last week? where?