AltME groups: search

I imagined a can of worms. Guess I have to read and think it all 
through at some time.

BTW, this was discussed and implemented in ALtMe some time ago

Today's Moment of REBOL Zen:

>> forever [prin now/time // 7 wait 1 loop 20 [prin bs]] 
0:00:00.000000002

forever [prin now/time // 7 wait 1 prin cr]

(remainder on time is funny)

I don't feel that they should be the other way around. The problem 
is that there is no obvious reason why it should be one way or another, 
so when trying to remember it I get it wrong about half the time. 
Using 'eol would be good, but wouldn't help the problem because we 
can't undefine 'newline in R2 because of the backwards-compatibility 
rules.

Getting an error when sending bulk email: 

** User Error: Server error: tcp 501 <>: missing or malformed local 
part
** Near: insert smtp-port reduce [from address message]

The number of email addresses is 52. 

I can send using the same settings one at a time and I have succeeded 
sending  8 addresses at one time. But it bombs on my whole list.

I did some a long time ago Henrik. It isn't fast enough to work on 
data of any size though. I can dig it out if you're interested. Can't 
remember what state of completion it's in.

the change to switch was a good thing... wasn't it also mezz code 
a wee back?  IIRC this happened at the same time... and it made A 
LOT of code much faster.

Ladislav's terms are better, in the sense of being more descriptive, 
but I'm unlikely to remember them because I've been using the old 
designations for 10+ years. I'll try, but don't give me a hard time 
if I don't get it at first.

It's nice to have an official way to express a concept, but that 
doesn't help much if it isn't the common way that the community uses 
to express that concept. It doesn't help to refer to the manual if 
that manual has been rewritten since the last time the person you've 
been talking to needed to read it. Accept that there are community 
standard terms, and hopt that the better terms in the manual win 
out eventually, or at least before the manual is rewritten again 
with even better terms.

Andreas, yes, those terms existed for quite some time....

I guess, much of my confusion here comes from the fact, that I never 
had the need for constructs.


If we follow the thought, that the none value should be shown as 
#[none] in the console, when it's a result, then the following should 
be shown as well:

>> next "abc"
== #[string! "abc" 2]


I think, most people wouldn't want that. It's not very readable. 
I still ask myself, if all those constructs are really necessary 
taking the amount of work and time used into account.

every time I save REBOL data to disk? I use this hundreds of times 
every day.

It's kinda interesting, how complexity sneak into a language like 
REBOL. I have never used constructs. I save REBOL data and code to 
disk all the time. I even created a file system/database, that is 
all about saving and loading data and code. I get along using a combination 
of simple REBOL functions like SAVE, LOAD, REDUCE and DO.

I think, that the point here is the Geomol's question:


I still ask myself, if all those constructs are really necessary 
taking the amount of work and time used into account.


The answer is quite simple, it is as with any data the Load dialect 
can represent:


- many data representable by the Load dialect aren't "really necessary"

-- other languages can usually represent less data types than the 
Load dialect can

-- the Load dialect did not have the escaped format from the start, 
and could do without it


- without the escaped format, the Load dialect cannot express values 
of the logic! type


- it is useful to be able to express values of the logic! type in 
the Load dialect
-- some languages have the advantage of being able to do that

-- it is confusing to use a word like true in the Load dialect, when 
meaning the logic value, since in the Load dialect true is a word, 
not a logic value (notice the example, where Geomol confused words 
and their values)

-- the expressibility of the logic! datatype in the Load dialect 
enhances the expressivity of the dialect, which is why it is useful 
to have it, similarly as for any other datatype expressible

-- the expressibility of the logic! datatype enhances the reflexivity 
of REBOL, since 

--- this way, the Load dialect can express values that would be otherwise 
inexpressible in it, while being used in the Do dialect

--- that means, that the Load dialect would not be usable to "speak 
about" logic values in a direct way

Ladislav, typical serialization only takes into account the data 
traversed (in the order it meets it).  in the above example, if the 
block 2 was encountered first, then it would look like this:


#[block  2  [ val3  #[block  1 [ val1 val2 ]]  val4]  ; shared block 
containing another shared block
#[block  1 ]


(I kept the ids, just to make the comparisons easier, but it would 
have effectively swapped 1 and 2)


I built such a system for a project a long time ago (I lost the code, 
unfortunately).   It stored graphics in block formats, and used shared 
sub-blocks in many objects .  So  I built a reference-safe load and 
save which completely made the above invisible... I used tags to 
refer to blocks, and  a tag-based block serialization which was very 
similar to the above.  it was quite specific to my application, but 
it could have been generalized.   I did have to make it a two-step 
process.  if it where internal, it could be done in a single pass.


 a serialization can be made more persistent (accross several serializations 
 and even sessions), but that is not what REBOL is built for, nor 
 would it be very useful within REBOL's semantics IMHO.

I solved the problem of serializing circular blocks etc. a long time 
ago, by adding DISMANTLE and REBUILD. Eg. see http://www.colellachiara.com/soft/YourValues/libs/persist.r

So, it can even be done as a mezz layer above MOLD and LOAD.

I am doing some tel. report automatic checking, and I need an advice 
- how do I get easily substracted two time values going thru the 
midnight?

>> (fourth 29-7-2011/00:02:00) - (fourth 28-7-2011/23:52:00)
== -23:50


If I substract whole date value, it returns 1, it simply counts just 
dates, not time ...

You were subtracting 23 hours and 52 minutes from zero hours and 
2 minutes. That's -23:50.

With difference, the whole date plus time was given, then the difference 
is positive in this example.

Maybe subtract on dates should only give days, if time is not given, 
else work as difference?

There is a lot of type checking in REBOL. I feel too much sometimes. 
Calling many functions involve two types of type checking, as I see 
it. Take ADD. Values can be: number pair char money date time tuple
If I try call ADD with some other type, I get an error:

>> add "a" 1

** Script Error: add expected value1 argument of type: number pair 
char money date time tuple

I can e.g. add pairs:

>> add 1x1 1x2    
== 2x3

and issues:

>> add 1.1.1 1.2.3
== 2.3.4

But I can't add a pair and an issue:

>> add 1x1 1.2.3
** Script Error: Expected one of: pair! - not: tuple!


So that's kinda two different type checking. First what the function 
takes as arguments, then what actually makes sense. If the user also 
need to make type checking, three checks are then involved. It could 
be, the first kind isn't done explicit for natives, and that it's 
kinda built in with the second kind. But for non-native functions, 
the first type checking is done:

>> f: func [v [integer!]] [v]
>> f "a"
** Script Error: f expected v argument of type: integer

I came across a funny thing with binding. We've learnt, that the 
binding of words in a block is done, when the words are put into 
the block. This little example with two functions illustrate that:

blk: []

f: func [
	v
][
	insert blk 'v
	g v
]

g: func [
	v
][
	if v = 3 [exit]
	print ["v:" v]
	probe reduce blk
	g v + 1
]


F puts the word V into the block, then calls G, that has its own 
V. When G reduce the block, we see the original value of V from F, 
even if Gs V is changed:

>> f 1
v: 1
[1]
v: 2
[1]


Then I tried this next function, which puts V in the block in the 
start, then call itself with changed V value:

f: func [
	v
][
	if v = 3 [exit]
	if v = 1 [insert blk 'v]
	print ["v:" v]
	probe reduce blk
	f v + 1
]

>> clear blk
== []
>> f 1
v: 1
[1]
v: 2
[2]


This time, we see the latest version of V. The first V, which has 
the value 1, was put in the block, and it's still there somewhere 
in the system, but we get the V value from the latest F.

Is this a problem or a benefit, or is it just a bit strange?

Cyphre, in your example, when you insert the first x in the block, 
it's the x holding the value 10. To me, the x in the block is bound 
to the outher x at the time, you insert it into the block. The next 
x, you insert in the block, is the x from the context o. So at the 
time, you insert it into the block, that x in the block is bound 
to the x in o.


So the block holds two different x, and they're bound at the time 
of insertion. That's what I meant, when I said "the binding of words 
in a block is done, when the words are put into the block".


(Words can be rebound at a later time using e.g. BIND, but I'm not 
looking at that in these examples.) I don't have time and energy 
to argue with Ladislav right now. :)

Anyway, the explanation is as follows: since the function F is called 
twice, it creates two objects having the attribute A. While the first 
object has got the attribute A set to "ok" initially, it ends up 
having the attribute A set to the "bug!" string before the F is called 
for the second time. After the second call to the function F occurs, 
the function does not "see" the first object's A attribute when setting 
the A using the a: "ok" expression.

In REBOL, literal blocks are just literal blocks. If you modify them... 
they are modified. Binding a block modifies the words inside the 
block, ie. it modifies the block. It can't get any simpler than this.


Now, you may argue that MAKE OBJECT! should bind/copy the block instead; 
the reason it does not is purely performance (as 99.99% of the time 
the copy is not necessary). In that 0.01% of cases where you need 
it... you just write MAKE OBJECT! COPY/DEEP [...] instead.

Note to self: when discussions evolve like this, don't waste your 
time, John.

And regarding the "time waste", some readers discovered something 
new, so it was not a time waste for them

And, while you discovered something new as well (see your posts above 
admitting that), I certainly did not, so, I am the one here answering 
some "time wasting" questions of yours.

And regarding the 

time waste", some readers discovered something new, so it was not 
a time waste for them"
That's right, I did not know that MAKE OBJECT modifies the block.

(and, I guess, the same applies to Gabriele as well)

 - correct, as I said, 99.99% of the time copy/deep is not necessary 
 for make object!. The only time i've had to think about using it 
 in the past 12 or so years... is the above example.

Ladislav, if you try follow my thoughts, you can figure that out 
yourself.


Steeve, maybe that law is a design flaw, that causes many problems? 
Like the example returning "bug", which started much of this conversation.


Gabriele, ... Gabriele, you strengten my tolerance, and thank you 
for that. "that kills dialecting" I've seen you writing that before, 
and it puzzles me every time. (Well, probably different understanding 
again.) Thank you for suggesting Scheme, but I don't have time to 
dig into a new language right now.

Should we let it rest?

Doing it that way shrinks the startup time and memory quite a bit. 
There's a lot of the loading process that is dedicated to reducing 
code copying.

This is also why that while most of the large mezzanine functions 
are written using FUNCT, the actual mezzanine build process converts 
those definitions to calls to the non-copying FUNC, with no preprocessing 
or copying needed at startup time. The user-level mezzanine FUNC 
is copying for safety reasons though.

Then the MAKE object! . The block given to make this time is also 
copied, as this shows:

>> b: [a: 1]
== [a: 1]
>> o: make object! b
>> third :o     
== [a: 1]
>> same? b third :o
== false
>> append b [c: 2]
== [a: 1 c: 2]
>> third :o
== [a: 1]


So the block is copied, and then that's not the reason, the example 
from Ladislav's Bindology returns "bug".

So the block is copied

 - your conclusion is wrong. the object does not "keep" the block 
 it is made from. THIRD simply generates its output each time.

Today's Long Moment of REBOL Zen:


When making an object, code in the block argument is executed. I 
found, BREAK stops further execution:

>> o: context [a: 1 break b:2]
>> ? o
O is an object of value: 
   a               integer!  1


So the B assignment isn't carried out. Ok, what about a RETURN in 
object creation then? I'll use MAKE OBJECT! instead of CONTEXT, so 
the RETURN is not handled by CONTEXT, which is a function:

>> o: make object! [a: 1 return 0 b:2]
>> ? o
O is an object of value: 
   a               integer!  1


It seems like, making objects can handle returns ... in R2 at least. 
This has changed in R3, where the result is:

>> o: make object! [a: 1 return 0 b: 2]
** Throw error: return or exit not in function


This seems reasonable. What if I use CONTEXT and use RETURN in the 
object creation? In R2 CONTEXT doesn't have a THROW function attribute, 
so my guess is, RETURN will return from CONTEXT, and the rest of 
the object isn't made, and this is what happens:


>> o: context [print "before return" return 0 print "after return"]
before return


Ok, I now want to fix CONTEXT by putting the THROW attribute in, 
and then test it by making an object using CONTEXT, but this time 
inside a function:

>> context: func [[throw] blk] [make object! blk]

>> f: does [context [print "before return" return 0 print "after 
return"] print "still in f"]


When running F, I would expect to just see the words "before return", 
but

>> f
before return
still in f


I see, that THROW doesn't work as intended, when making objects. 
This is the same in R3, where CONTEXT also doesn't have THROW, and 
when trying to fix that by changing CONTEXT, it's still the same 
behaviour as in R2.

map-each: func [

 "Evaluates a block for each value(s) in a series and returns them 
 as a block."
	[throw catch]

 'word [word! block!] "Word or block of words to set each time (local)"
	data [block!] "The series to traverse"
	body [block!] "Block to evaluate each time"
	/into "Collect into a given series, rather than a new block"

 output [any-block! any-string!] "The series to output to" ; Not image!
	/local init len x
][
	; Shortcut return for empty data
	either empty? data [any [output make block! 0]] [
		; BIND/copy word and body
		word: either block? word [
			if empty? word [throw make error! [script invalid-arg []]]

   copy/deep word  ; /deep because word is rebound before errors checked
		] [reduce [word]]
		word: use word reduce [word]
		body: bind/copy body first word
		; Build init code
		init: none
		parse word [any [word! | x: set-word! (
			unless init [init: make block! 4]
			; Add [x: at data index] to init, and remove from word
			insert insert insert tail init first x [at data] index? x
			remove x
		) :x | x: skip (

   throw make error! reduce ['script 'expect-set [word! set-word!] type? 
   first x]
		)]]
		len: length? word ; Can be zero now (for advanced code tricks)
		; Create the output series if not specified
		unless into [output: make block! divide length? data max 1 len]
		; Process the data (which is not empty at this point)

  until [ ; Note: output: insert/only output needed for list! output
			set word data  do init

   unless unset? set/any 'x do body [output: insert/only output :x]
			tail? data: skip data len
		]
		; Return the output and clean up memory references
		also either into [output] [head output] (
			set [word data body output init x] none
		)
	]
]

OK, since nobody objected, I shall proceed with the preprocessing 
directives user-poll:


- in the current INCLUDE, the PREBOL directives are made standard, 
while other directives, like COMMENT are made "user-defined", which 
means, that they are defined "on-demand" only


Since in RMA, we actually used the COMMENT directive as "standard" 
for quite some time, there is a suggestion (by Cyphre) to make it 
standard as well. Any other opinions on which preprocessing directives 
should be made "standard" and which ones should be "user-definable"?


Just a note - switching this in the code is trivial, it is more of 
a standardization issue, than a problem of work in my side.

Regarding the translation functions: yes, the directives do not suffice 
to supply all the necessary functionality. Other code is needed to 
handle the run-time translation of "marked" strings. That code was 
written by Cyphre and is influencing the behaviour of RebGUI widgets 
to show the currently required language version of the text.

Aha, actually, forget about it, my definition of the COMMENT directive 
would handle the 1 + 1 expression as well. The only difference being, 
that it would be handled during link-time, not run-time of the code, 
which may still cause some incompatibilities

Substitutions are meant to separate:


- the time when the substition was created (using e.g. the REDUCE 
function)

- the time when the substitution was translated and displayed (using 
e.g. the combination of the TRANSLATE SUBSTITUTE and SHOW functions)

I agree with Robert .. why would you want to perform an extra reduce 
?
 - exactly because the REDUCE is performed at a different time

The substitution has to be performed always at the translation time, 
while REDUCE just when you need to create the substitution

KISS in this instance means default reduce, and use a refinement 
if you don't want this behaviour

 - well, that is very much like saying, that e.g. for the TEXT widget 
 in the Laout dialect you prefer to use a code block, which should 
 (re)generate the string to be displayed every time it is SHOWn. While 
 possible, it is not KISS

But that does not matter, until it need the translation, which happens 
during run-time when the user chooses a different display language 
for widgets.

I like the SUBSTITUTE proposal, as-is. I sort of like that only strings 
are supported, because there's no default translation from datatypes 
to strings - we don't have anything like OOP asstring methods. Different 
methods of string formatting are appropriate in different circumstances. 
The moment that you pick one conversion method as the default, people 
will ask for options for other conversion methods to be supported, 
gradually making SUBSTITUTE so complex that it becomes slow, as it 
goes through the process at runtime of determining what the programmer 
wants it to do. If you decide to manage that complexity with composition 
instead, the decision-making process is done at development time, 
not runtime, and you can have unbounded complexity with no overhead.

I wouldn't mind BIND accepting function! for its context argument, 
as long you still have the error on referring to any of the bound 
words when the function isn't running. But not closure! though, since 
that context is different every time.

There was a discusson in Carl's blog about this long time ago.

Related is using POKE on e.g. time!:

>> t: 10:20:30
== 10:20:30
>> poke t 2 42
== 10:42:30
>> t
== 10:20:30

But we can change a time using a set-path!:

>> t/2: 42
== 42
>> t
== 10:42:30

So the set-path! way doesn't do the same as POKE in this case.

I've been thinking about this before, and there was a discussion 
on Carl's blog long time ago. It came to me again, when I looked 
at LOWERCASE and UPPERCASE. They work on strings, and does change 
the sting. But many functions work on string without changing them. 
That's a bit odd, or maybe difficult for new users to understand.

One more note: there is a FLATTEN function definition somewhere, 
which was defined some time ago to be used to flatten hierarchical 
blocks. It should be possible to find it here, but, since it was 
long time ago, I will try to find my version and put it to rebol.org 
or somewhere to make it more available.

more like list navigation, where one may move back and forth one 
item at a time, but never past the last item.

To be frank, it is most likely down the road before I ever use the 
new functions. I can tell just by perusing it that I would need to 
spend some time trying to understand what they do. But thanks for 
the input.

Linux also would not consider them equivalent. I understand why Mac 
OS is always canonicizing file names, but, they chose the most stupid 
way to do it, and it's a pain in the ass most of the time. In the 
end, I prefer Linux where you can end up with two files named in 
a way that looks exactly the same, but that has a file system that 
behaves in a predictable way.

I'm trying to reach a time server but having trouble.

I can get a time from my rebol based time server on my server with 
"read daytime://myserver.com"

but if I use it for any of the well known online servers I get :
>> read daytime://time-b.nist.gov
== ""
>> read daytime://nist1-ny.ustiming.org
== ""


sometimes it seems to work but more often than not I get an empty 
string

There are a few different time protocols, and the standard time servers 
don't tend to run the daytime protocol. They usually run NTP.

2 amacleod: time protocol is not very accurate, the same levely of 
accuracy you can get by reading any HTML size and distile the time 
from HTML header. OTOH NTP protocol is able to get milisecond accuracy 
but by quite difficult handshake and as far as I know not yet written 
for rebol

daytime://nist1.aol-va.symmetricom.com seems to work resonably well

I dont need to be too accurate just +- 5 seconds....


my server's time seems to be drifting. I've seen this before on an 
another computer...does a bad battery affect the time even if the 
power remains on?

It might be better to enable your server's native time sync services. 
Windows, Linux and OSX all have such services, as do many more OSes.

The hardware clocks of many computers are rather inaccurate, though 
they're getting better.. They expect you to enabe the time sync services.

It's enabled but does not sync as fast as the drift and I'm having 
trouble doing it manually...keep getting an error and I tried several 
time servers.

>> number: 1234                                       
== 1234
>> time [loop 1000000 [1 + to integer! log-10 number]]
== 0:00:00.293239
>> time [loop 1000000 [length? form number]]          
== 0:00:00.28022

On R2 version 2.7.7.2.5

My example is doing bit shifting right (decreasing value) by 2 bits 
at a time. The bits falling off each byte isn't carried over to the 
next byte.

Dunno how fast it is going to be though, exiftool looks slow, when 
called from REBOL. Might take some time to extract info from xy files 
in directory ...

I have uploaded my latest EXIF-parser version at github - https://github.com/Oldes/rs/blob/master/projects/exif-parser/latest/exif-parser.r

To sort files you can use for example:

dir: %/e/DCIM/100CANON/
t: now/time/precise
result: copy []
foreach file read dir [
	error? try [
		ctx-exif/parse-file dir/:file
		exifdate: ctx-exif/get-tag-value 306
		repend result [exifdate dir/:file]
	]
]

sort/skip result 2

print ["sorted" (length? result) / 2 "files in" now/time/precise 
- t]
result

;>>sorted 120 files in 0:00:00.153

And that limit could be increased with time.

And that limit could be increased with time.

 Exactly. As Red's compiler will be coded in Red (once the bootstrapping 
 phase will be over), every new feature added to Red will benefit 
 to the compiler itself.

It's sleep time here, but I can't resist to post a first Red/System 
source example:

#import [
	"kernel32.dll" [
		GetStdHandle: "GetStdHandle" [
		  	type		[integer!]
		  	return:		[integer!]
		]
		WriteConsole: "WriteConsoleA" [
		  	handle		[integer!]
		  	buffer		[string!]
		  	len		[integer!]
		  	written		[struct! [value [integer!]]]
		  	reserved	[integer!]
		  	return:		[integer!]
		]
	]
]

stdout: GetStdHandle -11
written: struct [value [integer!]]

prin: func [s [string!] return: [integer!]][
	WriteConsole stdout s length? s written 0
]

prin "Hello Red World!"

Since red/system is c-level and compiled you can't and don't plan 
to have runtime goodnes of rebol in it. But the code is still data, 
so do you think you could use compile time macros to keep the core 
simpler and solve many things with macros then (like lisps do)?

Janko: thanks! About compile-time macros: that's an option. You already 
have #define, but it's quite limited for now (no  multiline or parameters 
support).

I'll extend it to allow compiling several sources in a single executable, 
but I won't go past that. Red/System will live as a Red dialect, 
so will benefit from the whole Red environment. The only time it 
needs to work alone will be to produce the Red's runtime layer. But, 
as said in my blog, Red/System could be extended to a full-featured 
language if someone want to invest in it.

Intel means it for compliance ahead of time. I wouldn't expect them 
to compete with the performance of the future FPUs they want to sell 
us

This has got to be the shortest time for a working rebol clone !

I wanted to get back to the roots (80's for me) of computing, a time 
where an entire OS + programming langage could fit in a 16KB ROM 
;-).

I don't know, I'll have to dive into our loader. It's much like Red: 
the minimum we needed over time to get things working :-)

Each routine has several implementations depending on the features 
available at runtime in the CPU (SSE, SSE2, SSE3,...). So, it's a 
bit too large for my needs (I would prefer selecting the best implementation 
at compile-time).

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.

I first wrote 1MB, then I raised it thinking of possible libs that 
could get statically linked by users. But, it could be even easier, 
just hardcoding the DATA address offset somewhere in the CODE segment 
at linking time might be enough (no need to reserve fixed space in 
CODE segment).

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

The jewel names could have been a good place to pick a programming 
language name, but last time I've checked all the good&short ones 
have been taken already.

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.

That sounds good. I need to take some time tomorrow to think about 
all that and see if there's no drawback hiding somewhere.

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?

Different mode of communication. Less "real-time", more asynchronism.

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.

I haven't had the time to recreate my proposal for changes to the 
pointer/struct model as a Google Groups entry. Maybe this week, maybe 
next.

shadwolf: If you don't like REBOL nor Red, I wonder why you're losing 
your time (and our time) by posting here? Didn't you announce that 
you were leaving the REBOL community a few weeks ago?

BrianH sever ties with rebol do the things to aim commercial success 
then you can say for you interview to computers or time's magazin 
that yeah rebol was your source of inspiration for red ...

Anyway, aside from wasting time, bandwidth and trying to spill your 
negative emotions to all peoples here, do you have something useful 
to say? If not, I'll just go resume my work.

What if I create a function, the multiply a local variable of type 
integer with some global variable, and I run that function in a context, 
where the global variable is a string?
  The compiler will catch the type mistmatch at compile-time.

Are the datatypes being checked at runtime?

 Not in Red/System. Partial runtime type checking could be added at 
 Red level.

Maybe invent a syntax, where part of the function can be split up 
depending of the type(s) of the argument(s)? Right, the type has 
to be checked at runtime, but maybe only once then. REBOL has to 
check types all the time, for everything from simple arithmetic to 
function calls, etc.

Doc, I have to say, the red docs are getting really nice.


its clear now, and I was talking nonsense... I should have gone over 
them... will make sure to visit each time. they've significantly 
updated since last I visited.

I was just taking a little break from all of the cheyenne dev.

yeah, I forgot that Red lives in the same space-time continuum as 
the rest of us humans  ;-)

If you have looked at Red sources since a long time (like a week 
;-)), you should look at the Quick-Test framework added yesterday 
by PeterWood: https://github.com/dockimbel/Red/tree/master/red-system/tests
(see the readme.txt)

I might have been inspired by your ticket (I remember vaguely reading 
it a long time ago). Using AS for type casting, was a natural extension 
of the as-string / as-binary syntax from R2.

Kaj: thanks for the report. I thought we were cleanly separating 
RO and RW sections in two different LOAD segments...maybe the flags 
are not correctly set in sections (or in section headers). I'll give 
it a look this weekend if Andreas has not the time to fix it before.

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.

And since it isn't defined in the runtime now, I have to write it 
myself until that time