World: r4wp

Ok, I've added (not pushed yet) a new directive for including Red/System 
libs outside of 'red context. Example:

	#system-include [%tests/hello.reds]


will load and compile the hello.reds script. Notice that relative 
include paths are resolved from Red/System root folder (%Red/red-system/).

Does that cover your need Kaj?

It should solve one big part of the problem. The other big part are 
the context sensitive #define's

I also need #include's to work the same as in Red/System: relative 
to the source the path is in

The only #include right now are Red/System includes.

Yes, those I mean

#system-include just inserts them outside of 'red context.

Or do you mean paths in #system-include?

The included file paths are left unchanged.

They are just inserted at beginning of intermediary script passed 
to Red/System.

I meant the ticket I have open

The path of the source file they came from is lost

Does such include work fine with %rsc.r?

Yes, I use them everywhere

(I mean just #include %../C-library.reds)

By the way, I think we should eventually have a search path for includes, 
but that's for the future

Yes, I use relative include paths of that form in all my bindings 
and examples

I need them to be able to install my Fossil repositories side by 
side in one main directory and then #include between them without 
changing paths

I've pushed #system-include addition, but there's probably more path-related 
patches to apply I'm afraid.

context-sensitive #define: seems to be a complicated change as it 
is the heart of the preprocessor...but context are created only during 
compilation (so after preprocessing).

It would be easer if #system-include would be like #system so that 
you could wrap an extra context around Red/Sytsem code, without introducing 
an extra wrapper file. Would that be hard?

No, trivial, I would then just remove #system-include and add an 
option to #system to have the code loaded outside of 'red context...but 
semantically, it will be a bit inconsistent with barebone #system, 
as it means "inline the Red/System code here"...Maybe I should just 
rename #system-include to solve that.

It works as it is now, but then I run into the #define problem

This form of #system-include is probably still handy

Why does it require a block?

I've changed it to #system-global, work exactly as #system but loads 
outside and before 'red context, should I push it?

Please

Done.

Works with #include with an absolute path

There's an extra problem when I wrap the C binding in a context, 
but that seems unrelated

An #enum isn't prefixed with the context

For the defines, I think the best option (and cheapest) would be 
that I prefix the one I use internally for Red.

It should IIRC.

It's worse than that. The first error I get is on one of my #define's 
that's a struct! later in Red

I guess you'll have to prefix (or suffix) them.

Which one is conflicting?

That would really butcher all my bindings. And it's too much work 
just to do temporarily for the demo

I can maybe change some on Red side, if there are not too many conflicts.

It's NONE, but I really wouldn't want you to change that in Red. 
And it's just the tip of the iceberg

Added new actions: AT, SKIP, BACK, NEXT, LENGTH-OF.

You can now do a bit more than just PRINT 1. ;-) See:

	a: 123
	a: a + 2
	print a * 6 - a

	b: [4 7 9 [11] test /ref 'red]

	print pick b 2
	print pick pick b 4 1
	print pick next b 1
	print pick next next b 1
	print pick back next b 1

	print length-of b
	print length-of next next b
	print length-of pick b 4
	print pick at b 2 1
	print pick skip b 2 1

	print pick at next b -1 1
	print pick skip next b -1 1

I'll extend FORM tomorrow so we can print more types.

#233 is back

Looking into it.

Fixed it. Going to rest now, will process other tickets tomorrow 
morning.

I'm busted, too. Night

Reading all the discussion about R/S source inclusion in the Red 
- it seems pretty complicated and confusing at best. Apart from the 
three options discussed on friday, it is the "least powerfull" one. 
It is not any kind of inlining R/S code into Red from the runtime 
point of view, hence I wonder, why it is not simply called an #include? 
I know you might want to two cases now:

#include %some.red
#include %some.reds


But that's distinguishable, and unifies the naming, as well as it 
does what the name suggests - it is just preprocessor kind of directive 
for including either the red, or r/s source into Red ....

About your proposition:


- #include is for including files, not for inlining literal code, 
which is precisely the purpose of #system* directives.


- you can't use #include to include directly two different languages, 
that would be confusing for everyone and it's a semantic mismatch 
(making users think Red/System code can be directly used in Red with 
no clear separation between the two).


- #include is a preprocessor directive, #system is a compiler directive 
(processed during compilation)


- #system* directive are not complicated nor confusing, they are 
pretty simple and should look intuitive to C users (having the habit 
to inline ASM code into C). Those users are the target users for 
Red/System (remember that most Red users will never program in Red/System).

Will there be possibility to use inlined ASM code?

Well, not coming from C kind of languages, I actually used code inclusion 
rarely. The preprocessing stuff in any language looks arcane to me, 
but that's just my feeling, as it is REALLY a long time ago, since 
I used code -> compile -> link technique (CA-Clipper - 1998 :-)


So I better wait for more "clean" way - the other method you described 
- simply what I am expecting is kind of Rebcode - writing any function 
in Red, using Red/System or C or ASM, whatever :-) But most probably 
I am confusing and create a mishmatch even in such case :-)

one small question though - what "secret project" are you guys talking 
about? :-) I expect you will not want to tell, otherwise it would 
not be secret anymore, right? :-)

Inline ASM: we might add that at some point, but you can already 
access some low-level CPU/FPU features (like stack manipulation). 
I will extend that in the future to support CPU in/out commands and 
direct registers reading/writing, so ASM support will be less necessary. 
Also, there's a cheap way to support it, adding the option to inline 
machine code directly in Red/System code flow (you would have to 
use an external ASM for generating the machine code). Something like: 
inline #{....machine code...}