AltME groups: search

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!.

I want to have a real structure type, not having a structure be equivalent 
to a reference to a structure.

This is something that could be added at Red level (in the core set 
of datatypes or as a user-defined type). Red/System will have to 
interface with C libraries mainly, that's why I took the C-like way 
to manage structs as references instead of values.

I noticed that in one of your structure examples one of the fields 
had a type of pointer! without a qualifying type. Are you supporting 
this?

It's a typo I guess.

the thing is that red/system isn't actually a semantic equivalent 
to REBOL its hard to keep an exact REBOL syntax equivalent.

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).

though it would be a welcome separator (ignored like a whitespace).

would make a lot of data readable by rebol directly which cannot 
be currently used.

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.

Max: that would be an issue as in french, for example, you write 
decimals with a comma. Also, I thinks it's too valuable to use in 
some literals to make it transparent for some rare use-cases.

well, use of comma as an alternative for decimals is a waste of a 
character.   commas have given me headaches in many apps where I 
had to build a string parser from scratch instead of just loading 
the string.

I have made a much more thorough set of parse rules for words in 
R3, including replicating the exact behavior of errors triggerd (except 
the Near field). See http://issue.cc/r3/1302for details.

Max: if you need to make commas LOAD-transparent in a string!, it 
is as easy as: replace/all string "," " "

C's struct! type is a roundabout way of specifying memory layout. 
A more direct way for specifying memory layout would certainly be 
nice, but if you want to interface with C-like code a lot, you'll 
want memory layout (storage) specifiers that allow you to mimic C 
(ABI) semantics.

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.

I'm hoing to expand them to be a full R3 code version of TRANSCODE, 
in a module.

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.

Then I'd keep the pointer! type as a specifier for the target platforms 
"pointer type".

Andreas, the target platform's pointer type points to something. 
Unless you know at least the size of that something, let alone its 
type, it is unsafe to use such a pointer. It is best to pretend that 
an untyped pointer is not a pointer at all, just a pointer-sized 
opaque value like R3's handle!. You can then explicitly convert that 
value to a typed reference in order to be able to use it as a pointer.

With the focus on pointer-sized, not on opaque. The opaqueness is 
a separate issue, but you _need_ a specifier for pointer-sized values.

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.

It's a value you can do nothing with :)

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.

But I agree with you also about your last comment. Things like arrays 
are a PIA to interface with using R2's struct!.

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]]

>> make struct! [a [pointer!]][0]
** Script Error: Invalid argument: pointer!

Not at the source level, Doc. Just because that won't work in R2 
doesn't mean it won't load.
>> load "make struct! [a [pointer!]][0]"
== [make struct! [a [pointer!]] [0]
]

Brian: you're right, it has been a long day... :-)

That is a special case in R2 that makes everything difficult. It 
was a good change.

But, that solution would turn MAKE into a keyword, so I couldn't 
use it anymore for making a malloc( ) wrapper for example. It could 
work with some tweaks in the compiler, but I'm not sure such hack 
would be desirable.

No, the R2 model turns MAKE into a keyword. The R3 version can just 
be a function.

Make: I agree, fixed arity is a cleaner way.

Make: I was thinking in Red/System context. I would need to turn 
MAKE into a keyword in order to spot literal struct! values.

You would want to do that anyways for other literal values, though 
the function use would be a fallback in case the spec is an expression.

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?

I guess I could do the fallback on expressions in order to use it 
as a function too.

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...

Wait, is
    a: &[integer! 0]
equivalent to:
    a: &[struct! [value [integer!]] 0]  ; a has a value of null
or this:

    a: &[struct! [value [integer!]] [0]]  ; a points to an integer with 
    a value of 0
I would prefer the former. Then this code:
    a: &[integer! [0]]

might be equal to the latter, with the integer being allocated as 
a local variable on the stack.

Or you could insist on this instead:
    a: 0
    b: & a

Callbacks: the first step is to be able to output a DLL ;-)

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"

is
   a: &[integer! 0]
equivalent to:
    a: &[struct! [value [integer!]] 
0]  ; a has a value of null

Yes, it is.

It would therefore be equivalent to
a: &[struct! [value [integer!]] 0]

if structs don't require any storage space (except padding) on their 
own.

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

Wait, there's a mistake in my example in the blog: 
    p: &[integer! 0]
is not equivalent to :
    p: struct [value [integer!]]


The struct value takes an additional storage space for the integer 
value while the pointer doesn't. :-(

Wait, doesn't the STRUCT function take a parameter for the initial 
value?

STRUCT: it is a keyword, not a function. The memory space it takes 
is zero-filled.

I figured as much, since the type system would need this to be a 
keyword because the type returned is derived from the argument.

Hmm, that may be a stupid question, but: why not simply use a POINTER 
keyword similar to STRUCT for pointer declaration.

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.

Well, you don't really need a POINTER keyword if pointers are just 
syntactic sugar for struct references. Then & could be the keyword 
for both.

Right. And language-specific and library-specific on any given platform. 
That is why it needs to have a good way to specify it.

For C and a given platform (and a given compiler, for some weird 
corner cases), default alignment/padding behaviour is specified.

Right. And since that changes from platform to platform and compiler 
to compiler we need a way to match those differences, with declarations 
or options or pragmas, same as the C compilers do.

Otherwise we can just drop the whole attempt at easier integration 
with C and go with a much more sensible storage layout dialect (think 
e.g. Erlang bitstrings).

Another important issue is that the defaults be settable on a per-platform 
or per-app basis, and that the behavior of Red/System is explicitly 
defined in a cross-platform way. We don't want to repeat the mistakes 
of C just because we're interfacing with C.

A lot of the stuff we have to integrate with will have C interfaces, 
but those interfaces will have struct layouts in them that were declared 
with precision for binary compatibility, using the pragmas and stuff 
that C was retrofitted with to allow such precision. We need those 
kinds of abilities from the beginning, or we'll have to retrofit 
it on later just like C did.

I'd use a different and far more powerful dialect for that.

But if you don't have a way to specify the padding and maybe alignment, 
you won't be able to interface with C code that sets that stuff too.

One dialect for conveniently interfacing with C ("structs"), a different 
dialect ("records"?) for 100% precise control over bit layouts. Plus 
a way to convert between the two.

The former quite possibly replicating some C quirks, probably a few 
of the most important ones, as needed.

You are a little spoiled on Unix-like platforms, Andreas. On Windows 
there is no standard C compiler; there are a bunch of competing ones 
instead. Each has its own quirks and defaults. Since Red is not itself 
written in C, you can't just go with the quirks of the same compiler 
it is written in. And different libraries are compiled by different 
people with different compilers. If you want to interface with them, 
you have to be specific.

Thanks guys for the insights and propositions. I found it a bit difficult 
to follow in realtime, I'm not sure that AltME is the best tool for 
such conversations. Maybe we should give a try to the Red web forum 
next time: http://groups.google.com/group/red-lang?

Nenad , how would reading something in a forum be better than reading 
it here?

Well, usually, you have more time to read and reply on a web forum 
before the post you're referring to, gets lost in the flow of new 
ones.

AltME is nice, but sometimes, when users are posting too fast on 
deep topics, I have a hard time following the conversation. My english 
is not that good, so I have to check for some words exact spelling 
or meaning when reading/posting. Also, I like to take time to think 
about things before saying them, especially when the topic is deep/complex. 
The old REBOL ML was great for that. That's why I was proposing moving 
such conversations to Google groups, which is just a web front-end 
to a ML.

With mailing-lists, you can have a threaded view of conversations 
in your email client, so you can easily follow replies to differents 
posts. I usually have no issues following replies on AltME except 
when several users are talking together and posting replies fast, 
it becomes hard to follow in realtime.

I guess that in AltME, if we could have a way to "mark" the post 
we're replying to when required, and the ability to switch to a "threaded" 
view, that would help a lot. In such "threaded" view, related posts 
could be grouped together with a [+] button somewhere allowing to 
unfold it and see all the replies to a given post. If posting while 
a thread is unfolded, the post would be considered a reply without 
having to "mark" the post related to the reply.

Error message is shorter than the previous one, I guess it is a good 
sign. ;-)

If you need some external eyes to look at your code or test it (I 
can test on OS X), you can "gist" it  (https://gist.github.com/) 
and put the link here. I, Andreas, or someone else could have a look 
at it.

I'd guess a bus error is an invalid address

(I've used `otool -h hello` to have a look into the headers)

FYI: I'll be offline for the next 3 days, I'm taking some rest in 
Spain. I should be able to check my emails once a day.

Doc said "I found it a bit difficult to follow in realtime, I'm not 
sure that AltME is the best tool for such conversations"... I must 
say that I have a problem to follow conversation on blog if it's 
in french only. And I always found it strange that someone writes 
comment under article written in english in a different language... 
usualy in french.

One even cannot use google translator to translate the page, because 
google thinks, that it's already in english. It's not able to translate 
just a partial content (without manually copying it to some translate 
forms). It's simply a very bad habit.

I think my BBS allows you to translate on a message by message basis

Spain: I was in Barcelona, it was very nice, brought a several sun 
burns ;-)

Because github is the most known one, there's a lot of programmer 
there, so that the place where Red can get the most visibility.

I reported a couple of possible bugs in the GitHub Issue Tracker. 
I didn't fid it very bug friendly.

Once again, I'm not a git fan. I use it because that's the only way 
to be on github.

Sure, but that was Subversion just a few years ago, and it will be 
something else a few years from now

Google Groups: do you have a better option?

Not a perfect one, but many alternatives work better

A online tool like Github is making contributions both easier to 
do and easier to integrate back in the main project.

Regarding Google Groups, I think the point is that it isn't about 
a new project in a vacuum, but that it needs to compete with AltME. 
If it's considerably worse, people will never leave here

Yeah, but there's a launch barrier to break

Anyway, either attract a new community in Google Groups, or replace 
it with something that can compete with AltME, but don't complain 
that people won't trade AltME for Google Groups

Btw, there's the #red-lang IRC channel on freenode for realtime chat 
(just a reminder).

I have opened a Google Groups ML mainly for the peoples not part 
of REBOL's community. It would be easier for me to have only one 
channel of communication, but if there's several, I'll adapt to what 
people prefer to use. Having only AltME channel would feel for newcomers, 
like Red if was a private club only for a selected few.

like Red if was a private club
 => like if Red was a private club"

If AltME could have a pure web client (supporting search engines 
indexing), threaded conversations, an email bridge for reading and 
posting, and an open API, it would probably become the best solution 
for online communities (of developers or other kinds).

There's been such a plan for half a decade. It was made to depend 
on R3

I've made a change in red-lang.org domain's DNS setup, we'll see 
in 3 hours if it fixes the naked domain redirection issue.

Redirection of red-lang.org to www.red-lang.org seems to be working 
ok now from here (testing from REBOL console). It might need a few 
more hours for the DNS change to propagate everywhere.

The issue re-opening feature was a contextual option. I still need 
to adjust a bit to github's logic.