AltME groups: search

Hmm, maybe a reverse question - what is missing in R3 in order to 
use it instead of R2? Just curious ....

It would be messy. R2 can't be touched, so it would have to be done 
through the Library interface. That's less powerful than the R3 extensions 
interface, so you'd have to develop a separate library in C that 
mimicks R3 extensions. Some functionality such as callbacks would 
still be pretty much impossible

What you would be developing is already in R3, so It's a lot simpler 
to just interface R2 and R3. Probably the most straightforward option 
for that is 0MQ

Ah yes, that's a good point.

If you're approaching it from a theoretical standpoint, then yes, 
this whole situation could have been avoided by doing things such 
as implementing the new extensions interface in R2 first

R2 is in the backwards-compatibility phase of its existence. No new 
changes are being made to it that would break a lot of R2 code.

That being said, something like this might be possible to add on 
to R2 as a library, though I haven't given much thought as to how.

To integrate the extension interface into R2 would be a huge task, 
and I'm not quite sure how to get around the lack of extendable objects 
(to build the module system on, since extensions are integrated with 
the module system). Adding the handle! type would be easy; adding 
the command! type would be a bit harder.

It would be rather difficult to fake the command! type if you are 
doing the library method, but you could use a similar method to that 
used to fake the closure! type. I am not sure how much you could 
replicate the value marshalling, and callbacks would likely be impossible.

Have you looked into what would be necessary to make a host DLL wrapper 
for R3 that could be loadable with LOAD/library? Is it possible to 
make a host with LOAD/library directly?

To be more concrete: I mean a lib interface that uses the INIT, CALL, 
QUIT structure on the C side. Uses the access to parameters via frames 
and same return concept. And callbacks like done in R3.

Which would diminsh the usefullness of such a project

There are some rounding problems though, so it maybe can't be made 
easily, but probably using a trick.

:) well, it's a good group for this, as Doc would consider these 
things at some point.

With e defined, the hyperbolic cos, sin, tan, etc. are easy (REBOL 
doesn't have these), and maybe also normal cos, sin, tan!? At least 
for complex numbers, but not so sure about reals. Maybe a better 
mathematician can tell us that? Ladislav?

John, in a real REBOL-like language + is implemented using ADD; all 
operators redirect to their associated functions. You could do a 
similar trick with a compiled REBOL-like language like Red. This 
brings up another question though: Will Red implement operators in 
a fixed-predefined-set way like R2, or in a user-defineable way like 
R3? I hope the latter, though the former would make sense for Red/System, 
at least in the pre-Red stage of its development.

User-defined operators are really nice, I think. Being able to write 
things like:

remove 42 from [1 2 3 42 177 280]

where FROM is just a simple FIND.

For now in R3 there are some restrictions about the kind of functions 
you can make an operator from - number of arguments and such. It 
is planned to eventually relax one of the restrictions, and allow 
function!, closure! and command! functions to be used. However, even 
in Red there will likely need to be a fixed format to the arguments 
of such a function: 2 args with no refinements, the first arg corresponding 
to the left side and the second arg corresponding to the right.

To make a FROM op you would need to make a FROM~ wrapper function 
around FIND; you wouldn't be able to make an op from FIND directly.

there could be various forms to the ops.  there can be a way to tell 
the op building process to be unary binary or ternary.

Yeah, operators with only 2 arguments sounds like a good idea. More 
and it fastly become too complex leading to confusion.

Maybe NOT can be defined as a function this way?


not: func [value][either none = :value or (false = :value) [true][false]]

Will Red implement operators in a fixed-predefined-set way like R2, 
or in a user-defineable way like R3?

 Op! will be user-defined as they were in R-sharp interpreter. Here's 
 a short extract of R-sharp's boot script:

+:  make op! :add
-:  make op! :subtract
*:  make op! :multiply
/:  make op! :divide
=:  make op! :equal?
<>: make op! :not-equal?

Exactly, safer and cheaper to do with a compiler.

no size limits, but it's obviously a lot easier to blow the stack 
if you pass around lots of large structs as values

as i said, it's a portability mess

other compilers rewrite the function to take an additional parameter 
with a pointer to storage used for returning the struct

(this pointer is then sometimes passed via a register, others pass 
it via the stack)

Would that behavior be standardized for a particular calling convention 
and ABI? For instance, that seems like the kind of thing that would 
have been standardized by stdcall or fastcall, but maybe not for 
cdecl or pascal.

afair it's a mess in all of them

Sorry for all the questions - I haven't needed to write a C compiler 
yet. All the languages I've written compilers for or hand-compiled 
were really specific about this kind of thing.

i have a handy reference by agner fog for intel platforms somewhere

Kaj: "I tested the new section headers on Syllable Desktop.

memmap_instance() RO overlap RW (08048000 + 00001000 -> 08048000)"


besides the entry point address being a problem, this could also 
be due to segment alignment, which we basically ignore, at the moment. 
could you try changing "page-size: 4096" to "page-size: 1" and see 
where that gets us?

I have to set the start address back to the Linux one to be able 
to compile with a changed page size

A page size of 1 works on Linux, but on Syllable the load error is 
still exactly the same

It seems logic! can't be used as a return value (last expression 
of a function) yet

When I use NULL I get a smaller executable than with 0. Is that correct? 
The Windows backend emits four bytes, but the ELF backend says something 
about ignoring NULL

NULL: a bit strange, need to check the sources for that.

logic!: that's odd, see the 'foo function in test-logic.reds (foo: 
func [a [logic!] return: [logic!]][a])

Strange...will look into that in a few minutes.

The difference may be between a variable and a constant

I can't reproduce your issue here, can you give me a short example 
of a function making the compiler produce that error?

Ok, will try with a similar pattern of code.

Can't reproduce using:

bar: func [a [integer!] b [integer!] return: [logic!]][
	either zero? a [
		either zero? b [
			print "00"
		][
			print "11"
			false
		]
	][
		false
	]
]
either bar 1 1 [print "KO"][print "OK"]
either bar 0 1 [print "KO"][print "OK"]

It is probably a 'false word reduction issue.

Kaj, I've just pushed a commit that should fix your issue.

I believe that the same "get-word" syntax will be used should  function 
pointers be  introduced at a later date

I'm a hudge militant of both the typed variable way (easy to interface 
C libraries) and the untype variable ( code more readable less maintenance 
etc...) This paradoxe tends to push me to imagine a world where the 
software will know what I need what ever the real sturcture behind 
is lets call it predictable type variable. How we do that ? I don't 
know but it seems fun enough to spend some brain cells  thinking 
of that. the idea is realy that interfacing external c/c++ java what 
ever library and maping it to the language innher variable and code 
will be absolutly transparent. (something like the .NET librabry 
browser but easier... Or more easyly we can have both system cohabiting 
side by side on the language schemes

though in rebol not having type for vars and () for function arg 
submition, make difficult to identify var content  distinguish var 
from function ... Maybe then  a syntaxique item like th e $ in php 
for vars or the @ in ruby for tables would be an interesting point... 
Sorry I try to think about rebol syntaxe structure like someone seing 
it for the first time

Shad, typed variables with type inference handles the readability/maintenance 
problem pretty well, which is why several statically typed languages 
have been retrofiting type inference into them recently. Fortunately, 
Red is planned around that from the start.


Your "predictable type variable" proposal (I don't know the standard 
term either) sounds useful. Many languages do this through reflection 
facilities, but that kind of thing requires dynamically typed variables 
at least as an option if you are going to use the reflection facilities 
of the language you are interfacing with - this is necessary for 
C++ at least because there isn't a shared standard for encoding that 
information in a static way. It would be more useful for integrating 
with .NET or CORBA objects, since direct field access is prohibited 
anyways for those so there's no extra overhead in the field access 
itself, just in the runtime discovery, and ahead-of-time static compilation 
has shared rules that work on a binary standard.

Awi, that would be great, I would love to see Red run on such platform 
but I'm afraid Red's memory footprint would be a bit too high for 
a 60KB of RAM (but this might be specific to the netduino platform?). 
OTOH, Red/System compiler should work nicely there. If you want to 
help for such port, we need two things:


- a target file format emitter (I guess it would be the firmware 
file format)
- a native ARM7 code emitter as Red/System back-end. 


Let me know if you want to start working on these parts, I would 
provide additional documentations.

I would install a Damn Small distro instead.

We've had a pattern of people who came to our mailing list shouting 
enthusiastically that they had found out that the "GNU C compiler" 
would compile to PowerPC or something, that they would compile Syllable 
to it over the weekend and report afterwards

And if you don't know all the parts intimately, they can easily pose 
a big problem to a particular developer

It can easily take me half a year to create a next version of Syllable 
Server, and that's on the same architecture

Doc - there is many such small platforms, even x86 based IIRC. Gumstix 
is e.g. for real, a bit pricey, but definitely not vapor - http://www.gumstix.com/store/catalog/product_info.php?products_id=256

I have updated the 0MQ binding to the latest Red version, and moved 
it to a Fossil repository:

vsm-data1	[integer!]  ; unsigned char [ZMQ_MAX_VSM_SIZE] (default 
30)

 => we will need a better way to handle such arrays when interfacing 
 with third-party libs...

What's the new syntax for a pointer field in a struct?

Actually it isn't a new syntax, it's just that the compiler wasn't 
checking it deep enough until now.

What you're saying, that's a pointer to an integer, right? But I 
need a pointer to a bigger memory area here

Yes, it's just to reserve the space for a pointer that's used by 
0MQ, but not by Red

I mean, don't use the word 'handle! as an alias because it will likely 
be a built-in datatype in Red, and in all Red/System functions and 
datatypes exported to Red.

That would be just a little code, and it's obvious that you have 
to develop your programs to stay in sync with a language that's in 
alpha status

No, that's a good reason to *add the handle! type to Red/System* 
now, as a preemptively reserved word. Not a reason to use the word 
handle! to refer to a completely different thing.

Perhaps it could be a name for a non-dereferenceable void pointer 
type, since that's the closest C equivalent.

Basically, Red's handle! type would be the same as R3's handle! type. 
Opaque value that is pointer sized, but can't be used as a pointer 
without typecasting, and no arithmetic possible. No conversions to 
other datatypes either in typesafe code.

That's in Red. Red/System is a different context

Yes, but Red/System's main purpose is to do things with Red data, 
so it needs to have access to Red's types, even if its own literal 
types are different. So Red/System needs to have a handle! type, 
even though Red/System code would need to typecast values of that 
type to something else in order to be able to do anything with them.

Yes, a temporary difference in declaration, because as of now, there 
is no handle! type to declare

Why? That would be the behaviour in Red. Red/System's task is to 
actually be able to do something with a pointer

Unless you want to make Red a true capabllities language, but you 
are opposed to that concept

In a strongly typed language, which even Red/System is, dereferencing 
a pointer means getting a value back that is of a known type; pointer 
arithmetic means adding in increments of the size of that type. A 
void pointer references nothing, and that nothing has no size. You 
must be required to typecast to another pointer type explicitly if 
you want to dereference the pointer, or to know how much to increment 
or decrement it.

I'm not under a strong impression that this is planned. So currently, 
I need to treat Red/System as weakly typed

It is not currently planned *by Doc* to have Red/System be a complete 
language, since he only needs it to access a few system libraries 
and implement the Red runtime. He's said that others are welcome 
to contribute the necessary changes to make Red/System a more complete 
language.

I understand the burdens of future programs, but I've written a program 
right now that I have to keep working

Well, it can't become strictly strongly typed, as a certain amount 
of type breakage is the whole point of its existence. You can't be 
strictly strongly typed if you have typecasting, pointer arithmetic, 
literal pointer values, or the ability to call C code. Red/System 
is supposed to be strongly typed with those rule breakers, in order 
to shield Red itself from those features.

You wanted to know if the appointed error locations are correct. 
That seems to be alright, and the error for a struct is nicely descriptive, 
but an error for a function definition is rather unspecific:

Oh wait. I have to use a block for #define, and then it works. But 
not ALIAS

And the error output for a function starts at the offending parameter, 
so that's actually pretty good, but it's not obvious

Here's a message that's not very clear:

As a nitpick, there's an excess space in the message, before the 
comma

So it seems that there is no way anymore to pass a null pointer to 
a function or to compare a pointer to null

but `as pointer! [integer!] 0` is fine, if it works. the spec needs 
a fix so that the examples match the syntax spec, though.

Thanks. The 0MQ binding is a nice test case

I was a bit confused yesterday about ALIAS usage, due to this ticket: 
https://github.com/dockimbel/Red/issues/39.I jumped on fixing it 
too fast without first checking the specification, so I mistakenly 
extended ALIAS beyond its original purpose (which is just for aliasing 
struct! declarations, as described in section 4.5.5 of the specification).

I just pushed a new commit that reverts back some of the changes 
I did for aliased types yesterday, and fixes the compiler errors 
reported by Kaj.

I have uploaded a patched version of the 0MQ binding here: http://static.red-lang.org/tmp/red-0mq-fixes.zip

Among the changes, 'null is now a global variable defined as a null 
pointer.

I need a pointer to a struct of which only 0MQ knows the structure. 
So any pointer will do, unless you want to make Red/System strongly 
typed

dockIbel one cool thing thqt could help promoting RED would be to 
do a openSUZE minimal distro using their tool that gives a linux 
ready to use out of the box with all needed to code or enhance red

I know it zas made for Illumination software creator and was a good 
enightenment for it

could be a good way in a middle term to have tools + OS etc in a 
single CD

You're right, I should add a mention about it on red-lang.org.

Kaj: I pushed a few fixes and changes on ALIAS support, it now behaves 
strictly as described in the specification. For the 0MQ binding, 
you need to replace [struct! message!] occurences with [message!] 
to make it compilable with the new version.

Have a new batch of issues, but will research more first

a/count: p/count

a/count: p/value

4.6.2: right too, it is a typo.

Red/System requires at least a 32-bit CPU.