AltME groups: search

If you set the compilation logs to 3 (-vvv) and take only the entries 
starting with ">>" you'll get a feeling of what such IR would be. 
In fact, just recording these steps instead of reducing them directly 
to native code, would almost give you a good IR to start making optimizations 
(other than the very trivial ones that I've included in IA32.r).

Hey guys ! AltME is cool, but what about using Red lang Google Groups 
to spread the world all reflexion (?) ?

And maybe having new blood, new way of thinking, new point of view 
?
What do you think ?

there might be some ideas to rip out of that compiler.    my favorite 
low-level feature was that all types where natively the same size 
in ram and where all aligned to that size.     in E all datatypes 
where 32 bits in RAM


so for example, chars actually had 4 bytes which you could dump bytes 
into, making them ideal for many purposes which strings and numbers 
are commonly used instead.  you coud compare chars with LONGS as 
though they where both integers, etc.

Max: the current supported types in Red/System are all of same size. 
Makes a lot of things easier, but I will need 8 and 16-bit sizes 
very soon, so the simplicity of implementation will probably suffer 
a little from that.

And it would ensure a single source for discussion

There's not very much you can do with Red on Syllable yet, and the 
integration is awkward, but it's a start

Sorry, it does allow out-of-band notes and bug reports to appear 
in the same interface, just not literate mixed code and docs.

The original Java case benefits more from the concept than REBOL 
would because there are many addon standards like JavaDoc that need 
managing, but at least have been agreed upon by their community. 
We don't have that kind of agreement in the REBOL community. Also, 
the structure of the Java language is very limited, so it's a bit 
easier to parse it and have its structure just be in the background 
even though the language wasn't designed for that like Smalltalk 
was for its browser. For Red, since it's so early, things like integrated 
documentation can be developed along with the language, so something 
like this would make more sense. However, if Red is going to have 
even a large fraction of the power of REBOL then it won't be as structured 
as Java, making it a little more difficult to retrofit a Code Bubbles 
interface onto existing code. This is why you would need an IDE to 
understand code written in this kind of IDE: A Code Bubbles style 
interface doesn't generate code with story structure the way scripts 
are structured, so you can't just read the code without the context 
of the IDE.

I compiled the Hello World example on the graphical version of Syllable 
Server, and then ran it with WINE

I didn't realize that the word wrapping was something it did; I thought 
it was something *you* did in that message. So I put in my own line 
endings, which ended up in the wrong place because they word wrap 
at fixed indexes as if they weren't rendering with a proportional 
font. If they are word wrapping that way, they should use an editor 
with a fixed-length font and a margin line.

What they are doing is using the Usenet message format in Google 
Groups, and that means ~78 character lines iirc. That format was 
designed for composing messages in terminals (like in R3 chat) or 
in special editors that use fonts like Courier when composing messages. 
It's surprising that they didn't relax the format a little for groups 
that aren't mirrored on the real Usenet, but when you "Show original" 
(in the "More options" section) the message is formatted for Usenet 
and email.

Question: I created my fork.

And now I created a branch on my computer, but where am I supposed 
to work exactly ? 

I mean, I only see the source files in a sub dir called /red-system

i'd suggest to keep the TBD comments and delete the rest

It was missing a to-integer conversion: power-of-2?: func [n [integer!]][if 
zero? n - 1 and n [to integer! log-2 n]]

I see that you use a lot, nested EITHER structures.
Personnaly I prefer flat CASE structures, more readable.
And i also think CASE could be faster.

But I can't apply my previous commits, they failed.
I just applied your commit and now it's ok.
So it's ok.

but syscall support is nice (and lean) on it's own :)

When I see how Carl fights with various libc versions...I wonder 
if syscalls are not an easier path even if it can have some minor 
porting costs here and there? Anyway, a libc mapping will be possible 
soon, so all options are open.

Kaj: I've installed the Windows binary from this archive: http://mark.ossdl.de/2011/01/zmq-and-pyzmq-for-windows/

Right, I ran into the preprocessor zeal before, and replaced some 
other values with variables

No, I mean that when you say that your long-term strategy is to compose 
Red/System code in Red, thus making preprocessor macros unnecessary 
in Red/System, you could start that strategy much earlier by composing 
the code in REBOL. What you learn from doing so and the code you 
write can be adapted to Red later once that exists.

BrianH: red for dalvik, I think that is really a good idea! there 
is and will be a whole bunch of android devices out there, so this 
would be great.

I know it's early, I am surprised by how fast and wide it's moving 
at so early stage.

Kaj: you should wait that I add all the type & specs checking to 
the compiler and some unit tests (this week). It will make the compiler 
more usable.

When I compile the tests on Linux and try to run them on Syllable, 
I get this in the kernel log:

Indeed, exactly the same as on Linux, as it's the same executable, 
and the same readelf

DLL generation support could be added for Windows without too much 
effort (just by extending the PE.r code), but for Linux, it requires 
both work at the linker and at the compiler level for PIC support.

Code looks somehow cleaner and easier to read than the linux loader. 
:-)

readelf gave me the impression that section and program headers are 
the same

Wouldn't position-independent code be required even on Windows if 
you wanted to support address space layout randomization (ASLR) and 
other such tricks?

But at least for PaX-based Linux ELF ASLR, full ASLR requires "position-independent 
executables" (PIE) which are  ELF binaries with a special type flag 
and PIC.

Some basic ASLR (stack randomisation and mmap-base randomisation) 
was added to the mainline Linux kernel in 2.6.12:
http://lwn.net/Articles/121845/

New revision released: preprocessor replaced by a new one running 
at block-level (so much more accurate now). Includes and simple macros 
are now also possible.

http://www.agner.org/optimize/promise convertor for obj files from 
PE, ELF to Mach-O and vice versa if it would help

Ask, and I'm sure you will get a LGPL version.

there is. and where do you get the idea from that this library is 
for tutorial purposes?

I've updated the 0MQ binding again to the latest Red, and implemented 
the remaining 0MQ functions:

Good job! It's nice seeing Red/System implementation near R2/R3 ones. 
I'll need to find some free time this weekend to start playing with 
0MQ and Red/System.

The code uses the new preprocessor. It's starting to look quite nice, 
and I've split off the examples into separate files, to the binding 
is now a proper separate library/#include file

A link for Andreas: http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachOTopics/1-Articles/dynamic_code.html


I was thinking about using some similar trick for ELF to allow efficient 
PIC support (avoiding the indirection table). It works by having 
a fixed offset between CODE and DATA segments in memory, so DATA's 
start address can be calculated at runtime, and all globals can be 
accessed using a simple offset.


It should be enough to reserve enough space for CODE segment (let's 
say 10MB) and make DATA entry point fixed? I wonder if the relative 
offsets between segments are preserved when the segments are moved 
by OSes (I hope so)?

And...REALLY cool Bolek.

I'd been phantasising about that, and about porting my 6502 emulator 
:-)

If I would port the emulator and someone would do a 6502 backend, 
then yes :-)

Binding systems such as SWIG are way too heavy for Red, and C functions 
are neither foreign nor alien to Red/System, so FFI and ALIEN would 
be too heavy as well :-)

Agreed with Kaj.
 

AFAIK, it might be possible to interface with C++ at very low-level, 
to be able to instanciate C++ objects and call their methods from 
Red. Same solution for obj-c interfacing, which will be required 
at some point to port Red to iOS.

The Io one is likely simplest, and BSD licensed, so you might be 
able to use some code from it

changing currently my serverbackends from rebol to luajit/FFI. what 
a relief and cool experience to just drop some c header inline and 

access the appropiate lib in seconds. the mapping is nice also.  
thought that this feature is quite important for Red.

with the last beta you can detect also a real firework of new and 
planned very usefull bindings there.

a feature like this defines a real 'multipropose language' as I stated 
many times before.

I'll make sure that Red won't lag behind on that aspect. But, as 
Kaj says, binding to a library like SWIG might be overkill for Red, 
I'm pretty sure that we can come up with much shorter and better 
integrated solution for Red (remember that we will have PARSE support 
and ability to use dialects).

Interfacing with C++ functions and objects requires matching the 
name mangling and structure layout conventions, and those are different 
between compilers. There are some attempts to standardize these conventions, 
but their success is limited. This is why the developers of most 
Unix clones tend to hate C++. The best solution on most platforms 
tends to be to use C wrappers or one of the binary object interop 
standards like COM or CORBA.

Nick: french talks passed through Google's translation service really 
do look weird...but the meaning seems mostly preserved. About Red, 
the potential is huge: draw a triangle with C, Lua and REBOL on each 
corner and put Red in the middle, you'll get a feeling of the possibilities. 
;-)

But maybe you mean the possibility of rather easy usage of different 
targets/backend, and Red being  a glue language? Well, IIRC Reichart 
suggested REBOL being renamed to Glue, in the past. So will we have 
Red Glue? :-)

But maybe you mean the possibility of rather easy usage of different 
targets/backend, and Red being  a glue language?


No, it's actually the opposite. I meant capturing the possibilities 
of these tools and merging them in one unique tool: Red.

The old Red mentioned on the page from Kaj's link never made it public 
AFAIK and seems burried six feet under decades of computing history. 
So, no name conflict there ;-)

well..... if you search red language in google, you already have 
the 3rd entry and several hits on the first results page, so I  guess 
it not that big a deal  :-)

sure, that's what I said above, you need to use "red language" - 
the thing is that "language" needs to be part of the query and I'm 
guessing that there will be lots of pages where this word will not 
be included. I just think that if you are going to be creating a 
new language, uniqueness in naming is only a plus and now would be 
the time to determine that rather than after its use is widespread

I think that the language name alone is not the typical query that 
someone would do. Here's two examples:


- Tiobe index relies on "<language> programming" as its search query 
to mesure the popularity of a programming language (see http://www.tiobe.com/index.php/content/paperinfo/tpci/tpci_definition.htm)


- For Cheyenne web server (not a language, but uses a common name), 
people coming to the web site with only "cheyenne" as a search keyword 
are very few. A vast majority use "cheyenne server" or "cheyenne 
web" or "cheyenne rebol". Anyway, after been online for a few months/years, 
Cheyenne's web site appeared on first page if you search for that 
word only (while there's really a *lot* of others resources not related 
to this web server).


There's also another point to consider. If the target name is not 
strongly associated with an existing brand or a popular product, 
you'll see a lot of unrelated results on first page (that's the case 
for "Red"). So, AFAIU page ranking algorithm, once Red language will 
spread larger, I'm ready to bet that the cross-reference links of 
Red-related site (and back-references to Red's home site) will push 
it rapidly on the first page, or even in the top 3 list.

I have to say I'm not a fan of the something in 14.7 of the system 
specs: "Support 0 and 1 as valid boolean results". That is a bad 
practice, and putting it into Red/System might lead to it leaking 
into Red. Just because it's C level doesn't mean it needs to repeat 
C's mistakes. It's better to stick to the REBOL-like, Lisp-like truth 
values.

Call the boolean type uint1! and be done with it. For a systems programming 
language, 0/1 as valid boolean results makes eminent sense.

byte! (and uint8!) is certainly better than char!.

Max: variable type inference for functions locals should be easy 
to add. I'm against having an inference engine in Red/System, but 
if some rules are trivial to implement and give a significant advantage, 
I'll surely do it.

Right, that's something to consider too. But I've often found such 
notation a bit hard to read and remember. Also to consider: hex syntax 
opens a hole in the "no digit as first character in words" rule. 
I hoped that I wouldn't have to break that rule again for other literals.

I think that readable trumps consise in this case, Maxim. And for 
a compiled language, to-long 33, to-short 33 and to-byte 33 can be 
resolved at compile time with no overhead.

Doc, if Red/System doesn't need to be Unicode-aware, you should replace 
the string! type in it with a binary! type and just have compiler-resolved 
string-to-binary conversions of string literals in the source. Have 
real strings only exist at the Red level.

should be 7Fh, and 7Fh is the DEL char of course

Red/System could be able to make values of all of Red's types, while 
not itself using all of its types in its own code. Red/System source 
could contain literals of Red's string! type, but its compiler will 
convert those literals to Red/System's binary! type. Then Red/System 
can make string! values explicitly by doing the conversions itself, 
or calling functions to do so. Make the Red/System language types 
a strict subset of the Red types, and don't pretend that you really 
support strings and chars in your language unless you have Unicode 
support built in. Then Red's built-in Unicode support would be written 
in Red/System code operating on binary! data :)

And then no code that calls C with char* types would pass in values 
of the string! type unless they have been converted to binary! first, 
implicitly by the compiler or explicitly by the code.

You might want to make it more explicit in the system design and 
docs that this is your approach, and add binary! and byte! as explicit 
types a lot sooner. Then you can do a tiny amount of type inference 
to at least have the compiler be smart enough to do the conversions 
when it can, so runtime conversions can be minimized.

Same with the bit!, bitset!, logic! group. Bits and bitsels are storage 
types, but logic values are what conditional expressions work with. 
This also has the benefit of letting the compiler avoid putting in 
if 0 checks all over the place and just go by condition codes instead, 
especially for inlined control flow code.

Array! and pointer! literals: I'm not satisfied myself with that, 
but that's the best I could come up with, so far. If you have better 
propositions, I'll be glad to adopt them.

So, I finally chose to use the & character (already used in C and 
other languages to mean "address of") with a datatype description 
for pointer! literal form.

Right, & word and a block!.

Since we use AND and OR instead of & and |, there's no conflict with 
making & be a prefix builtin operator. Cool.

I have mixed feelings about it. Pointer arithmetic is considered 
appropriate in a systems programming language if you want to make 
sure from the beginning that it is unverifiable. If you want a safer 
language, C++-style references are better. But the main problem with 
this is the same problem with R2's struct! type: It's too C-centric. 
Many languages other than C support actually passing structures into 
functions and returning structures, not just passing and returning 
pointers (or references) to them. Because of this I found the R2 
FFI model to be unusable to interface with the code that I really 
needed to call, which was as a matter of course never written in 
C.

Max: p[20]:  0 and  p[13 string!]: "hello"


These are not valid syntax in REBOL nor will be in Red. You're stretching 
the syntax a bit too far with putting a colon at the end of a block!.

You need to look at it as if you were building a dialect for REBOL 
that compiles to native code, but trying to keep the syntax and semantics 
as clean and familiar (from the REBOL user POV) as possible (trying 
to avoid C pitfalls while retaining its possibilities).

The C-like way is to manage structs as structs. The reference limitation 
is only for function parameters and return types. Other languages 
(which also have libraries that we might want to access) support 
passing structs as parameters, and for internal use we definitely 
want to support in-memory structs.


Still, we have objects for in-memory structures, so we're good there. 
If you want to see a structure as a reference type, it could just 
be a metaphor for binary conversions. In that case, dropping the 
pointer type and just using struct! for that would work pretty well, 
and make dereferencing the pointer a simple matter of syntax, rather 
than a operator or built-in function.

And a leading comma is like + or - or . as a number prefix.

It still doesn't handle the full set of Unicode, just ASCII, but 
I can reverse the charsets to be complemented opposites and it will 
handle those too.

I.e. while you can get rid of pointer! and just use &[integer!], 
that is fine. But if you specify integer! as always being a 32-bit 
integer, you lose out in hiding cross-platform quirks.

You could just say that all references are structs, and that the 
pointer! type is a shortcut for making a struct! with a single field 
named value.

Andreas: that's the idea. All Red/System features are here to serve 
either the interfacing with OS and third-party libs (mostly C libs) 
or to serve the upper layer (Red) needs.

Though I would change this:
    p: &[pointer! [string!] 0]             ;-- char **p = 0
to this:
    p: &[&[string!] 0]                         ;-- char **p = 0

You can get rid of the pointer! name altogether and still keep the 
syntactic shortcut.

But you might be able to get by with only structure references and 
not have real structure variables. Then structs would be conversion 
metaphors.

That is all fine and well, but won't help you interfacing with C 
code.

Sure it will, Andreas. The explicit conversion is just there to catch 
bugs in your code. The handle! type is just to interface C code that 
takes a void pointer. All other pointers would be struct! references. 
And this code:
    &[integer! 0]
would just be a syntactic sugar shourcut for this:
    &[struct! [value [integer!]] #{00000000}]
or something like that.

And then all C int* values would just correspond to that type.

btw, when allocating arrays, the use of /value should not be required. 
 just like in C and REBOL's use of path notation, it should adapt 
to what is being pathed. 

using: 
p: &[array! [20 integer!] 0]

should be used with 
p/4: 123 

in fact:

 p/4/value: 123 

would be used for:
p: &[array! [20  &[integer!]] 0]

So the opaque pointer-to-? type would be called handle! for compatibility, 
and typed pointers would be handled by struct! references. And you 
can do inline struct! values like this:
    #[struct! [value [integer!]] [0]]

which is the serialized syntax for a struct! in R2, on R2 platforms 
that support structs.

The & syntax would be for struct references and the # syntax for 
struct values. And if you initialize your struct reference with a 
integer it will be a pointer value, but if you initialize it with 
a block then an inline struct could be built and then referred to 
with the reference. So this:
    a: &[integer! 0]
would be the same as this:
    a: &[struct! [value [integer!]] [0]] 
or this:

    set a: &[struct! [value [integer!]]] & #[struct! [value [integer!]] 
    [0]]

And you can use make struct! instead of #[struct! ] since the compiler 
can do the same thing in both cases, and then R2 wouldn't complain.

I think string! should be char*, &[string!] should be char**, and 
&[pointer! [string!]] should be char***. But maybe I'm missing something 
:)

What's the problem with making MAKE a keyword? You don't have function 
values in Red/System, and you don't want it redefined without the 
compiler knowing about it. Speaking of which, typed function references 
with overloaded &[function! [...]] syntax?

And if MAKE is a keyword, depending on the expression it could fallback 
to calls to different functions.

considering callbacks are just pointers, its not that big a deal 
to provide the capabilities...  all you need is a way to get the 
address of a function rather than call call it, and you're good to 
go.  this could be achieved easily with get-word notation...

Are there conceptual problems (exports and such) or is it just a 
matter of writing out the files properly?

I'd have the &[] syntax to always mean "pointer to", i.e. a reference 
type.
And as far as I understand the current spec,
  a: &[integer! 0]

means "a pointer to an integer!, with the pointee's address being 
0"

I prefer to think of it as syntaxtic sugar, but basically yes. And 
structs should be padded explicitly somehow, with a sensible default.

I was thinking that none could be a none! type, and then autoconvert 
to the particular reference type on assignment. Or it could be of 
type handle! in Red/System, with a predefined 0 value.

Andreas: could work and it  would be more consistent with struct. 
The other option is using & both for pointer and struct references.