AltME groups: search

Jaime thanks for asking...But there's not a simple answer.

The point I am about to make applies to any proposed variant in ORCA 
vs REBOL.


The problem with changing fundamental behaviour is that it makes 
it hard to port applications: think a few years ahead when ORCA is 
a fully operational REBOL clone, and (as an example) (unlike REBOL) 
runs on PDAs. I'd like to use ORCA so I can run an application in 
a PDA; but I want to use REBOL for all my other platforms. And I 
don't want to have to pick through code and/or support two source 
versions because of avoidable differences in behaviour.


On the other hand, an ORCA-only application might benefit from the 
"more correct" implementations of basic operations.


One possible way to square that circle is to have a set compatibility 
flag:
    system/orca/xor: false  ;; gets me REBOL XOR behaviour

I just have to wrap that in an 'attempt and I can keep a common source 
that will run under either.


[I appreciate that there may be performance issues doing it that 
way -- may be better to have compatibly options specified in an orca.r 
file that is only processed at start-up....I'll leave the details 
to the people doing the design]

IIRC Doc did not planned to be 100% compatible either. IIRC he wanted 
to introduce two layers to networking. It comes from his experience 
when working with networking (Uniserve etc.). I think that redesign 
is the right time for language to correct/improve some of concepts. 
I expect REBOL 3.0 to go that route. 2.0 was rewrite too.

Maybe we could use Google Groups beta ?
http://groups.google.com/intl/en/googlegroups/about.html


create, join and search email-based mailing lists, and designate 
your group as either public or restricted.

Postings to both Usenet and mailing lists appear in 10 seconds and 
are indexed within 10 minutes.

Jamie, Henrik, if there are bad ops or stupid parts in R2, be sure 
to mention them to those creating R3. Either RT will fix the problems 
or explain why they aren't problems. In the long run, it would be 
a good thing if Orca and REBOL were to be more compatible.

We don't know what Orca's going to be, either :-)

It' s up to Carl to choose a license that will either unify or divide 
efforts

All the ones I mentioned are LGPL and GCC and Linux are even worse: 
GPL. So if you don't want to use Boron because it's LGPL, you can't 
use all that other software, either

I never saw the REBOL mezzanines be declared PD, either

Nope, but I wrote most of the R3 mezzanines and all of the recent 
changes to the R2 ones, and my contributions were either MIT licensed 
or contributed under the condition that they be open sourced under 
a permissive license - no copyright transfer agreed to. And the host 
code is in the open portion of R3 - I haven't seen any closed source.

I don't have access to the r3lib source either for the same reason.

>> a: [[1][2][3][[4]]]
== [[1] [2] [3] [[4]]]

One level:

>> b: copy a while [not tail? b] [either block? first b [b: change 
b first b] [++ b]] b: head b
== [1 2 3 [4]]

All levels (not cyclic reference safe):

>> b: copy a while [not tail? b] [either block? first b [change b 
first b] [++ b]] b: head b
== [1 2 3 4]

The WHILE trick above needs the same CHANGE/part (whoops):

>> b: [[1] 2 [[3] [4]] [[5]]] while [not tail? b] [either block? 
first b [b: change/part b first b 1] [++ b]] b: head b
== [1 2 [3] [4] [5]]

>> b: [[1] 2 [[3] [4]] [[5]]] while [not tail? b] [either block? 
first b [change/part b first b 1] [++ b]] b: head b
== [1 2 3 4 5]

Also, in R2 operators are evaluated by DO itself, which has a set 
of keywords that it transforms from operator to prefix function syntax. 
R3 does this swap by value, not by name, so operator renaming is 
possible. However, this leads to behavior like this:
>> f: func [a op b] [a op b b]
>> f 1 get quote / 2
== 2

>> f: func [a op b] [op a b]
>> f 1 get quote / 2
** Script error: op operator is missing an argument
** Where: f
** Near: f 1 get quote / 2


This is why, when you are accepting and calling function values, 
it's best to either limit yourself to the types of functions you 
are expecting, or use APPLY.
>> f: func [a op b] [apply :op [a b]]
>> f 1 get quote / 2
== 0.5
>> f 1 :divide 2
== 0.5

A bitset is just a collection of N bits which are either set or cleared.

hum... either that was sarcasm or you mean, what is the company I 
now work for?

If datatypes equals words, like word! = 'word!, then maybe the refinement 
in type?/word isn't needed? But what are the consequences? The next 
two examples would return the same:

>> find [integer! 42] integer!
== [42]
>> find [integer! 42] 'integer!
== [integer! 42]


I came to think of this, because I find myself writing things like 
the following all the time now:

	either find [block! paren!] type?/word value [ ...
and
	switch type?/word value [ ...


If datatypes equals words, only type? without the refinement would 
be needed.

I know, I today can write things like


 either find [#[datatype! block!] #[datatype! paren!]] type? value 
 [ ...


but I don't do that, because it has too much syntax for my taste, 
and therefore isn't very readable.

I didn't need a CASE-like statement so far in Red/System, so it's 
there yet. Current implemented control flow statements: IF, EITHER, 
UNTIL, WHILE, ANY, ALL. So implementing CASE should be doable.

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.

Cool either way, for those of us not running on IBM mainframes (which 
have this standard in hardware) :)

Doc, by multibyte chars I wasn't talking about variable-size, I was 
talking about fixed-size with Unicode support. A char! would have 
a single size, but that size would either be 1, 2 or 4 bytes depending 
on whether the base plarform supports ASCII, Unicode2 or full Unicode.

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.

AltME isn't the answer, but blindly picking the seemingly most popular 
for each infrastructure part isn't, either

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

Kaj: I agree with your arguments, I don't plan to use that syntax 
at Red level, I would rather rely on either issue! or binary!.

None of this affects user code written in either language though.

None of this affects user code written in either language though.

When I realized that Peter was talking about user code, not code 
from Boron itself, I said "Cool." and then just clarified something 
based on what Peter said next. It was not steering the conversation, 
though I apologize if it gave that impression. License compatibility 
for contributions is a real problem (which is why I reacted to the 
FUD remark), but it is a problem with limited scope, and is solveable 
even within that scope. My response to that FUD remark gives the 
overview of the limited scope of the problem, and how to get around 
it (relicensing with author permission). No unsolveable problems.

Maybe NOT can be defined as a function this way?


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

send: func [  ; Send message.
	socket		[pointer!]
	data		[pointer!]
	size		[integer!]
	flags		[integer!]
	return: 	[logic!]
;	/local		message [pointer!]
][
	either zero? as-message message data size none none [
		either zero? send-message socket message flags [
			zero? end-message message
		][
			end-message message
			no
		]
	][
		no
	]
]

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

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.

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.

#define doesn't work, either:

As far as i know, Red/System executables don't rely on C libraries 
either unless they are explicitly declared in the program.

Only following this whole cool stuff here from the side, but what 
would be really cool is, if Red can live without any specific C lib 
binding. Either by providing the used functions itself in a sideeffect 
free version or by adding support to a OS free lib that can run on 
bare metal.

NOT is evaluated the same as other functions. As BrianH says, only 
two levels of evaluation, same rules as in REBOL. In the specification, 
it is listed under the "Infix Operators" category, I should either 
move it out or add some notes.

Along with some additional pre-processor directives added (#if, #either, 
#switch), this now enables the Red/System runtime being fully writen 
in Red/System itself.

NULL will be adapted to cop with that (either using polymorphism 
or by replacing it by a NULL? macro).

Float support will either be added at Red level or at Red/System 
level, depending on how the Red compiler will be built.

either as-logic 0 [
	no
][
	yes
]

Compiling /users/administrator/Red/test.reds ...
*** Compiler Internal Error: Script Error : Invalid path value: 1
*** Where: comp-either 

*** Near:  [emitter/branch/over/adjust/on c-true negate offset expr/1]

dummy: func [return: [integer!]] [0]
either as-logic dummy [
	no
][
	no
]

Peter, the compilation error in the new type casting tests was not 
the right one. Variable initialization cannot happen in EITHER blocks 
now since today's following commit: https://github.com/dockimbel/Red/commit/31b87b9565004574174ba3bf02b4dfaa2db665f2

It is caused by NULL clashing with EITHER return type static analysis. 
I am giving NULL an any-pointer! pseudo-type to solve that.

Yes, it's not great, either. The problem with PRIN is compounded 
in Red/System because now you get prin-int and such

either as-logic as-message message data size none none [

We don't have goto and longjumps, either, so there's little leeway 
for implementing a transparent error trapping framework

If you want the function to return a logic! status and a result to 
be able to handle it locally, the result needs to fetched through 
a pointer, which also raises complexity. We can't handle addresses 
very well yet, either, because get-words only work for native functions

x: does []
either true [x] [x]

*** Compiler Internal Error: Script Error : equal-types? expected 
type1 argument of type: word
*** Where: comp-either 
*** Near:  [last-type: either equal-types? t-true t-false]

In this case, I don't need EITHER to return a value

The crash is on the EITHER not on the DOES

I don't do IRC, either. It's not integrated, just more fragmentation

Updated the C and 0MQ bindings for the unset EITHER return value 
fix

This either exposes my preparations for thread safe code, or the 
fact that I haven't written any substantial applications yet :-)

#include %../SDL.reds


log-error: does [  ; Log current SDL error.
	print [sdl-form-error newline]
]


red:	as-byte FFh
green:	as-byte FFh
blue:	as-byte FFh

screen:		as sdl-surface! 0

event:			declare sdl-event!
mouse-event:	declare sdl-mouse-motion-event!

either sdl-begin sdl-init-all [
	screen: sdl-set-video-mode 640 480 32  sdl-software-surface

	either as-logic screen [
	while [all [
		sdl-await-event event
		event/type <> as-byte sdl-quit
	]][
		if event/type = as-byte sdl-mouse-moved [
			mouse-event: as sdl-mouse-motion-event! event

			if as-logic (as-integer mouse-event/pressed?) and FFh [

    unless plot screen  mouse-event/x-y and FFFFh  mouse-event/x-y >>> 
    16  red green blue [
					log-error
				]
			]
		]
	]
	][
		log-error
	]

	sdl-end
][
	log-error
]

Red/System [ ]

#include %GTK.reds

argc-reference: declare integer-reference!
argv-reference: declare handle-reference!
argc-reference/value: system/args-count
argv-reference/value: as-handle system/args-list

_gtk-begin argc-reference argv-reference

_window: gtk-new-window gtk-window-top-level
_label: as gtk-widget! 0

either as-logic _window [
	_label: gtk-new-label "Good riddens!"

	either as-logic _label [
		gtk-append-container  as gtk-container! _window  _label
	][
		print "Failed to create label.^/"
	]


 g-connect-signal  as-handle _window  "destroy"  as-integer :gtk-quit 
  none
	gtk-show-all _window
	gtk-do-events
][
	print "Failed to create window.^/"
]

I never liked either GTK or Qt. The reason I'm binding one anyway 
is that we want native platform user interfaces for Red. Linux and 
BSD don't have a native interface, but if you have to appoint one, 
you have to appoint two: GTK and Qt

I've tried including two bindings in one program that both include 
the C library binding, and I can't get it to do a single pass over 
the nested include, either with relative or absoltue paths to the 
C library binding

Anyway - not sure if such a news article for OSNews is not a bit 
preliminary ... no bindings yet, no possibility to use standard channes 
(market), no RED yet = not much of a REBOL featureset either. Achievement 
is great - RED gets us onto mobile OSes, still far superior to R2 
or R3, except that Red/System is mostly a C with REBOL syntax. I 
can understand, why Doc wants to work on RED itself some bits too 
:-)


Anyway - I am here to do some testing with HTC Sensation. The fun 
part comes, when the bridge is going to be done. Imagine having parse 
and REBOL like series handling, with access to stuff like SMS, calendar, 
address-book, and other APIs :-)

GCC either rewrites atexit directly or redirects atexit calls to 
__cxa_atexit via libcc, I don't exactly remember.

Missing double-quote in:

http://static.red-lang.org/red-system-specs.html

either a > 0 [print "TRUE"][print "FALSE]

CASE helps "flatten" the nested IF or EITHER constructions.

In REBOL we tend to use CASE instead of EITHER because CASE is faster 
when there are more than 2 tests. Flat is just a side benefit. Of 
course, an optimizing compiler could change the resulting code from 
one to another when it's appropriate, just like most modern C/C++ 
compilers do.

I hope you have a CASE/all option. We used the CASE/all style in 
the R3 module system code to great benefit, mostly in maintainability 
but also in speed, when compared to the nested IF and EITHER code 
it replaced. It enabled us to add features and simplify code at the 
same time.

IF, UNLESS, EITHER, CASE and SWITCH all make sense to compile in 
a compiled language because they all translate to branches and/or 
index lookups in the generated code, and optimizing that would need 
some decent compiler support. If anything, CASE is the most general 
(the others can all be implemented with CASE), and would benefit 
the most from optimization.

Yuck (no offence). Triggering an error or returning none would be 
better. There are even some languages that trigger an error on compilation 
in that case, but that requires either an interesting type system 
or some dataflow analysis, so that is not likely a good idea to put 
in Red/System.

Can you analyze EITHER, CASE and SWITCH to determine whether the 
results the clauses return are the same type? I guess the same would 
go for ANY and ALL, if you have those.

I hardly mentioned REBOL anymore, either, but it's necessary to introduce 
Red

The people who are supposed to be wise don't get it, either:

Since we either do a Lua GUI or perhaps can adopt Red ;-) and do 
the GUI there, I think there will be some choices.

either any-struct? type [
	either as-logic value [

on-quit: function [  ; Register handler for normal program termination.
;	handler		[function! []]  ; Callback
	handler		[integer!]
	return:		[logic!]
][
	#either OS = 'Syllable [
		not as-logic _on-quit handler none none
	][
		not as-logic _on-quit handler
	]
]

Hm, I'm not sure either if the wrapper function can currently be 
written like I said. You'd have to use the specific declaration as 
function! type for the function pointer, but the Red/System type 
checker may not currently support getting the function pointer in 
the right type

#if and #either are easily replaceable by "if" and "either" with 
an optimising compiler

#switch is the same as #if/#either.

#either macroname cond [ a if macroname ] [ b if macroname ] either 
macroname

either macroname [ c ] [ d ]

I am able to disrupt R2 compilation session to the state, where its 
restart is needed. Not a big deal, but maybe you will see something 
obvious. The code causing it is as follows:

print ["led-set-language: " led-set-language 3 lf]


The trouble is, that led-set-language does not return any value (void). 
This is understandable, that 'print has problem with such a clause. 
The error returned was:

Compiling led/led.reds ...
Script: "Red/System IA-32 code emitter" (none)

*** Compiler Internal Error: Script Error : Out of range or past 
end
*** Where: resolve-path-head
*** Near:  [second either head? path [
compiler/resolve-type path/1
]]


Correcting the issue (moving function call away from the print block, 
I get another error:

Compiling led/led.reds ...
Script: "Red/System IA-32 code emitter" (none)

*** Compiler Internal Error: Script Error : Out of range or past 
end
*** Where: resolve-path-head
*** Near:  [second either head? path [
compiler/resolve-type path/1
]]


This error repeats, untill I restart the R2 compiler session, which 
is a proof, that I corrected the source code, as aftern the R2 restart, 
I can get clean pass ...

One question towards library wrapping and type casting. One DLL function 
is defined as:

typedef bool (WINAPI *LSN_OPENCARD)(void);//open led card 


When I defined the return type of wrapper funciton as LOGIC!, it 
was always true. When I defined it as an integer, it was either 1, 
or some really high integer number. So i took Cyphre's advice towards 
R2's interface, and in R2 I used CHAR, and in Red/System, I used 
BYTE! type.


Pity construct of a type return: "as integer! [byte!]" is not allowed, 
but at least I now get correct result - 0, or 1, in my print statement, 
where I do: print [as integer! led-open-card lf]


So my question is - why using Red/System's LOGIC! did not work? Is 
C level BOOL a clearly defined type, or can it be defined in various 
ways, so I can't say, that I can automatically use LOGIC! = BOOL 
logic, when wrapping stuff?

Making IN and TO as OP! looks ok.
=> looks better than -> but it a bit similar >= and <=

I'm not sure if it reduces readability. Especially if we put string! 
value in a word (I'm not sure either if anyone uses this)

;rebol
>> to t 5
== "5"

;topaz
t: string!
x => t

Are there R3 docs in this area? I've look here:
http://www.rebol.com/r3/docs/concepts.html
and:
http://www.rebol.com/r3/docs/guide/network.html

Those docs either seem to be for R2 or am missing.

When thinking more about it...maybe the kwatz! shouldn't be separate 
datatype (as in fact it is identical with binary!). Instead of that 
you could intorduce KWATZ? native which will check the 'flag'. So 
possible usage:

parse data [
	set val binary! (
		either kwatz? val [
			;make the value valid
		][
			;treat normal properly loaded binary! stuff
		]
	)
]


this way the 'kwatz-flagged' binaries are treated same way as 'properly-loaded' 
binaries without the need to change all functions to support some 
hybrid kwatz! datatype.

Is your bytecode polymorphic, or is it statically typed? A polymorphic 
VM like REBOL's wouldn't have problems with higher-level series like 
unicode!, but to support that on a static-type VM you would need 
either a lot of opcodes or compiling to a lot of code to support 
it.

I'm not sure about that either Max. We'll let John catch his breath 
and he may have a reason.

May be using either Github issues or wiki

t: [...]
f: func [c t f] [either c t f]
f ... t ...

Geomol - it is just that you depreciate psychological factors. Ppl, 
especially with previous experience with RT, are very carefull here. 
In the end, you might just wonder, why noone is interested in such 
a model anymore. And in the end, it is just end result, which matters. 
You either get some community surrounding World, or you might wonder, 
why while your product is excellent, noone really cares anymore. 
Or - you might end up finding some nice niche e.g. embedded market, 
having lots of customers, etc. There is many possibilities, how your 
decision might influence something.


What I really don't understand is one thing - you sound too protective. 
You have full right to sound that way. But what escapes my mind is 
- "when I get nothing from doing so?".  And what do you get from 
actually not doing so? Also - do you expect any harm, caused to the 
business side of your project, by eventually open-sourcing?


As for me - I am used to commercial and licensed products. I just 
wanted to point out, that in the end, your attitude, might be contraproductive. 
If you keep product developed, ppl might feel safe, but ppl might 
also be carefull with their contribution to the project, because 
such kind of REBOL related project already failed big time. Not your 
falt, that's for sure, but the negative assumption is in the air 
nonentheless.

hmm, just tested, and load "=>" does not work in R2 either

My opinion is that there needs to be a "common syntax rule", (either 
allowing #"<" as a syntax separator character or not)

The escape decoding gets done too early. The decoding should not 
be done after until the URI structure has been parsed. If you do 
the escape decoding too early, characters that are escaped so that 
they won't be treated as syntax characters (like /) are treated as 
syntax characters erroneously. This is a bad problem for schemes 
like HTTP or FTP that can use usernames and passwords, because the 
passwords in particular either get corrupted or have inappropriately 
restricted character sets. IDN encoding should be put off until the 
last minute too, once we add support for Unicode to the url handlers 
of HTTP, plus any others that should support that standard.