AltME groups: search

Do I understand correctly, that there was somebody catching a virus 
and blaming RT for it?

if r3 is a virus, it's not spreading very effectively!

That looks like a joke to me.

Not really, but then I haven't gotten a straight answer about why 
2.99.4 was flagged either. If you still have a copy of 2.99.4, put 
it in a password-protected compressed archive or else many antimalware 
products will delete it without asking you.

I wish I could find more humor in this though. SECURE not working 
really does bother me a lot; even though I joke about it getting 
R3 flagged as malware, if it actually happened for that reason I 
couldn't argue against that.

Dunno if anyone has the time for a demo contest http://synapse-ehr.com/forums/showthread.php?389-Demo-Competition

Is there any reason why line breaks are allowed inside tag datatype?
>> load {<a^/>}
== <a
>

especially in xml u might have a lot of attributes.. makes sense 
to break them into lines, doesn't it?

I am not totally frequent here but I have the sense I haven't seen 
any signal from Carl for a long.. am I wrong or did he really go 
silent?

aha ok, at least it's a "controlled disapearance"

Not sure this one is controlled. This time we are nearing almost 
6-7 months of silence. Carl simply has a day job,not a supporting 
project imo.

I am still not happy with this:

    not none ; == true


, which means, that NOT handles NONE as a logic value. At the same 
time, it is not a logic value for other logic operators/functions:

    none or none

** Script error: or does not allow none! for its value2 argument


, and am tempted to put it to the CureCode. Am I the only one disliking 
this?

yeah, but imagine a function call in stead of none in my code. A 
function, that returns none when failure (like no more data).

Geomol: yes, there *is* a reason why the NOT function is comfortable 
being argument-compatible with IF. But, then, other logic operators/functions 
should be compatible as well. The functionality like typeset or typeset 
can well be left for the UNION function.

Yeah, I understand now. Makes sense to use NONE with OR etc. Because 
it could be the return of a function, we test with OR.

There are many funny things. Also why is there a TRUE? function but 
not a FALSE? function?

Yes, but just recently, a user had to choose between:

    any reduce [expr1 expr2]

or 

    (true? expr1) or (true? expr2)

, which are equivalent for him, but not nice.

if some-func OR other-func [] would be nice to support... though 
I ALWAYS use any/all... its become a habit  :-)

[a b c d]: 42 * [1 2 3 4]

e.g. typeset or typeset is actually a union for me, and therefore 
should be performed using the UNION function preferably

I expect   true == (0 AND 0)   if that is what you mean.

but I think I understand the deeper question you are hinting at.


AND/OR actually are two completely different ops rolled into the 
same wrapper.


on one part they act like a logical comparisons, on the other hand, 
they *also* act as a "bitwise" operators.  

because of this we cannot compare data *with* logical! or none! values.


I would gladly separate both as two sets of ops.   && ||  symbols 
come to mind to use as "bitwise" ops.  

I'd keep AND/OR as logical operations *only* allowing us to compare 
any data as logic comparisons.

AND/OR actually are two completely different ops rolled into the 
same wrapper

 - yes, that is the problem. I would even add, that not just two... 
 Such a setup *might* work, if the ranges were disjoint. But, in REBOL, 
 they are not disjoint, because any value can be used as logic by 
 IF.

I think my post above gives a good clear starting point for the CC 
ticket.

To complete the informations, I should probably perform a user poll 
in here. So, here goes:


*For me, one of the main goal of logic operators like NOT, AND, OR, 
XOR is to yield a value, that is used mainly as the CONDITION argument 
of the IF, UNLESS, EITHER, etc. control functions.


*Taking NOT (which is a unary logic operator) as an example, we see, 
that it is compatible with the above mentioned main purpose. The 
goal is achieved by "delegating" other functionalities NOT does not 
perform to COMPLEMENT. It is not possible for NOT to be both compatible 
with IF and perform the operations COMPLEMENT does.


*Taking OR (which is a binary logic operator) as an example, we see, 
that it is incompatible with the above mentioned main purpose, not 
being able to correctly handle some logic combinations, that would 
be compatible with IF. As an example, see the expression
    0 or true

, which cannot be used to yield an argument for IF, although both 
its arguments *are* compatible with IF. Interestingly, there is not 
a shortage of functions that are meant to perform analogical non-logic 
operations. I would like to specifically mention the UNION function, 
which seems to be related to OR similarly as COMPLEMENT is related 
to NOT.

*The question I am asking you is:

- Do you prefer the "logical" solution used in the case of NOT, and 
apply it to other operators like AND and OR as well, or

- Do you prefer the "non-logical" solution used in case of AND and 
OR and apply it to the NOT operator as well, or
- Do you prefer to keep the current state of affairs for R3?

I don't mind AND, OR and XOR being both logical and bitwise ops. 
If there is a problem with the current behavior, I don't remember 
being tripped up by it.

There surely is a problem, why would NOT be implemented differently 
otherwise?

Atm. I prefer the same as you too (the first one), but I would suggest 
some names for the bitwise and, or and xor in the reporting of this.

I feel, the language would benefit from being a bit more strict.

I'm tripped by it EVERYTIME I try to use them... none is a valid 
value for all logic control funcs.


so in over 10 years of reboling I've never been able to use them 
to control logic flow... I've used them only as bitwise ops...

NOT is an action that generates a logic! value. I like the current 
Lisp-like treatment, having none and false being falsey values and 
everything else being truthy values, with explicit conversions already 
available if we need them. Whatever we do, please don't have zero 
values be false without explicit conversion.

I think, Carl deside these thing by trying to figure out, what makes 
most sense for a new one to programming. Or trying to make a more 
humane less computer technical language.

I also only use them as bitwise ops, but I don't remember tripping 
over it very often. I just always use ANY and ALL. NOT was probably 
designed to be friendly, rather than pure, and I do use it a lot.

C-like languages always trip me up - a mass of design flaws, the 
whole lot of them.

We can do explicit conversions, and our code becomes easier to understand 
as a result.

but brian, we cannot use AND/OR for logic comparisons...  #[none] 
breaks them and none *IS* a valid conditional value.

None is a falsey value (NOT the value returns true), but not a false 
value. If we want to have AND, OR and XOR accept none as a false 
value, this will lead to errors being ignored unintentionally. We 
can do it, but there is a drawback. Still, I prefer that to making 
a separate set of operators for bitwise operations.

I find that R3 is the right time to address these issues in the language.


R3 is already incompatible.  I don't see a reason not to clean this 
up.

Bitwise ops are computerish, logical ops are how humans think. I 
don't mind making the bitwise alternatives a little more verbose, 
or even adding a dialected BITWISE function.

TRUE? was designed to convert a conditional expression to a logical 
expression. I think it used to say that in its docstring.

Anyway, vote on Ladislav's proposal. I'm a +1.

that's an unary logic! op!; hence a black sheep :)

OK, reading the Brian's formulations, a different expression of the 
poll question might be: "Do you, REBOL users, want to have 'combined' 
logic and bitwise' binary operators, wouldn't you prefer the operators 
to be conditional?"

(NOT could also be bitwise; if u ask a hardware guy...)

What if we write a C dialect in REBOL, and confine all support for 
[! | & || &&  >> <<] ops to that? ;-)

I would probably vote for Ladislav's proposal if I knew which words 
were to be used for logical AND,OR etc. and which wold be used for 
bitwise.


For me, there is a clear advantage of additional clarity gained with 
separate  functions. I am not clear on the disadvantages (if any) 
of keeping them as single functions.

ALTER is a modifying function.

>> a: [1 2 3 4] b: [1 2 3 5]
== [1 2 3 5]
>> difference a b
== [4 5]

is exacty what I would expect of XOR on blocks.

I feel a little confused. Are you proposing that DIFFERENCE be used 
for bitwise XOR?

So logically:

>> (#"^(40)" xor #"^(C0)") = (difference #"^(40)" #"^(C0)")

the whole bitwise thing is pretty fucked up anyway. i tried to do 
a disk editor, a pic microcontroller HEX file processor, a custom 
serial communication protocol and in all cases i had to ping-pong 
between binary! issue! integer! and had to trim to the right bit/byte 
counts. it was a nightmare all the time.

Yes, Tamas, it might be a good idea to suggest some improvements, 
if you are inclined to. You just need to realize, that there already 
are differences between the behaviour of R2 and R3.

Of course, an alternative to use a completely different set of names 
can be considered as well.

If the broader problem would turn out to be unsolvable in the REBOL 
dialect, there will still be an R3 extension with a Red/System dialect

It does look a little unusual but probably the equivalents with OR 
and XOR look odd to other people.

It's a long time since I studied set theory but if I remember correctly, 
the union of two sets is not dependant upon the order of the elements 
in a set.


So shouldn't the UNION of two sets of bits really be one of three 
values {0}. {1} or {0,1}.


I know this is knitpicking but I'm very used to XOR being bitwise.

Ladislav, http://issue.cc/r3/1879is a bit complicated when you consider 
that "operator" is used in REBOL jargon only for infix operations.
Your request looks like 3 related tickets:

- Extend the INTERSECT, UNION and DIFFERENCE functions to include 
the current bitwise behavior of AND, OR and XOR, respectively.
- Make operators for those functions (maybe &, | and ^).

- Change AND, OR and XOR operators (and AND~, OR~ and XOR~ functions) 
bitwise behavior to conditional behavior.
Is this a reasonable assessment of your request?

Peter, your right about the set functions and blocks. We should mention 
that in the ticket and say explicitly that these would not be set 
functions when applied to integers and such. The problem is that 
we would need bitwise operations to apply to strings and binaries 
as well, and these functions already treat them like sets. So there's 
a bit of functionality overlap that we have to deal with or else 
something will be lost.

The goal of having less dictionary entries to remember, and having 
the ops be smart, is valid; but in this case I think the meaning 
of the set op funcs (e.g. difference, union, etc.) are *much* clearer. 
Yes, most of us see AND and OR and know what's going on (though it 
sometimes makes my brain stutter a bit when debugging, especially 
XOR :-).

Having the set operations not act like set operations for some datatypes 
is only a little confusing - not much worse than what we have now. 
Losing either the setwise or the bitwise operations for strings and 
binaries is a much bigger problem - we need both, in different circumstances.

Sorry, just binaries. Good, I was worried that they might have tried 
to implement bitwise operations on R3 strings, which (conceptually) 
don't have a bitwise definition.

Though bitwise operations are allowed on chars, so that's a little 
inconsistent.

I think that not allowing bitwise operations on strings is a pragmatic 
restriction, because the internal data might get corrupted by them, 
and at the very least the results would be different depending on 
which internal storage mode is used. I'm not sure whether bitwise 
operations on characters currently work correctly at all, for the 
same reasons. What would be the proper behavior, and how can we check?

Losing either the setwise or the bitwise operations for strings and 
binaries is a much bigger problem

 - I do not understand, how you can lose something you do not have?

OK, that is why I was suggesting a separate ticket. Do you mind a 
little rewording in the ticket, or splitting into more tickets, if 
the proposal stayes the same, semantically? This would allow us to 
make them more precise, and show competing proposals, some of which 
could be rejected in favor of others. The existing ticket seems like 
a summary of an AltME conversation, so it would be tricky for an 
implementor to follow.

Well, the setwise-vs-bitwise treatment of binaries is a real issue 
with the INTERSECT, UNION and DIFFERENCE functions, so one alternate 
proposal would be to use different function names for the bitwise 
functions/operators. This would allow one or the other proposal to 
be rejected. Also, the operators proposal would need to be seperate, 
so it could be separately rejected. We've done this with other competing 
proposals before, so it's established practice. Why don't I come 
up with a set of proposals and run them by you first?

Setwise treatment of binaries is a no-issue for me. I wonder, whether 
it really is an issue for somebody else.

But, as I said, my main concern is the "REBOL does not have conditional 
AND and OR", so, if you succeed to split it up in a way this still 
is obvious, I will be OK with it.

If it's not, then the INTERSECT, UNION and DIFFERENCE proposal could 
be accepted and the BIT-AND, BIT-OR and BIT-XOR proposal (or whatever 
you prefer as an alternate convention) could be rejected. Rejection 
of a proposal is not a problem in this case - rejection of *both* 
proposals is a problem.

Yes, I suggested the INTERSECT, etc. modification as a supporting 
matter to show how one can do without changing too much. I can imagine 
a lot of different alternatives, though.

I see it is the main purpose why the AND and OR operators are needed 
at all. We don't need them that much to yield logic values as we 
need them to yield condition values. My main argument is the comparison 
of NOT usage (which is conditional, and used a lot), versus the COMPLEMENT 
usage (which is nonconditional, compatible with AND and OR, yet used 
much less)

Yup, onetom. But mixing prefix and infix is awkward in REBOL, requiring 
a lot of parentheses. This makes REBOL code slower and uglier.

(i don't really know.. never used true?.. looks a bit silly. i got 
used to the conditional meaning of stuff, so i hardly use AND/OR 
but ANY/ALL instead :)

A little comparison of TO-LOGIC, TRUE? and FOUND?:

>> to-logic 0
== false

>> true? 0
== true

>> found? 0
== true

>> to-logic false
== false

>> true? false
== false

>> found? false
== true

onetom ~/rebol $ grep -riw AND `find . -iname \*.r` | wc -l

i ran this for OR too and 95% of the occurances are in comments or 
strings and where it's found in the code, it's usually used as a 
bit-wise operator

It confused me a bit, what exactly was meant by "conditional AND 
and OR". So it's not just, that they operate on logic values, but 
that the second operand is only evaluated, if needed.

I presume, it'll be hard to implement conditional AND and OR in REBOL, 
because it's not just a type check as with other operators.

Aha, then we're back to my original understanding, and then I don't 
understand, why you say
REBOL does not have conditional AND and OR

REBOL does to some extend:

>> true and true
== true

Isn't that a conditional AND from your (or Brian's definition)?

no its a logical one.   it only compares logic!  datatypes correctly.

(within a conditiional minset)

each operand could be a parameter for IF/EITHER/UNLESS and has it's 
very well defined logic! value

I guess, there are several problems in this. Some conditions are 
dealt with by AND and OR, the logic! ones. But not all conditions, 
IF/EITHER/UNLESS can handle is supported by AND and OR. And second, 
AND evaluate all operands, even if some are false. That is the definition 
of "conditional AND and OR" I found from a search:

http://download.oracle.com/javase/tutorial/java/nutsandbolts/op2.html


See "The Conditional Operators" a bit down and the mention of "short-circuiting" 
behavior.

Not having the "short-circuiting" behaviour is a direct bug, as I 
see it. Because this code with create an error:

if (port <> none) and (data: read port) [ ... ]


But I have a gut feeling, that logic AND isn't very REBOLish, and 
that's why we more often use ALL and ANY. It's just a feeling, so 
feel free to disagree.

yeah, i had the same feeling that it can be interpreted as the description 
of a non-complete boolean evaluation  (that was the name of the flag 
in turbo pascal ;)

it raises the question, well what are these ops... and the answer 
is that there are none.   its a strange hole in the language spec 
which has passed under the radar for a really long time.

its very possible that REBOLers think in a different way and using 
ANY/ALL is more natural, hence the unatention this has had.

I don't agree, they're only used bitwise, as this example illustrate:

>> a: 1 b: 2
== 2
>> if (a = 1) and (b = 2) [print "it's true"]
it's true

I am trying to use a slightly different formulation: IF can check 
not just logical expressions (yielding LOGIC! values), but conditional 
expressions (yielding any values). We do not have operators combining 
conditional expressions into more complex conditional expressions 
(ANY and ALL are dialects, not operators, although they can be used 
successfully).

to a digital circuit, an analog circuit is like quantum physics, 
it seems impossible, but it works .   ;-)

onetom, I guess, you can see all functions taking a block as an argument 
to be dealing with dialects. The content of the block is just words 
until the function start to interpret it and give meaning to it.

Or maybe more correctly, the content of a block is datatypes (words, 
numbers, etc), and then the function start to make sense of it.

The fact, that ANY and ALL are natives, is maybe just to make them 
faster. It should be possible to create them as functions. One project 
of mine is to figure out, what minimum set of natives is needed for 
a REBOL like language, and the rest can then be implemented as functions.

it would be a nice groundwork for implementing rebol-like languages 
over others

You use the OP function to make op! values, and 'op gets unset after 
the mezzanines finish loading because of security/stability (I think 
OP doesn't have a lot of safety checks yet). TO-OP isn't defined. 
You can't currently make an op like Geomol's FROM because you can 
only currently make ops redirect to native! or action! functions 
- you can't make the necessary wrapper function. This is all afaik, 
based on conversations with Carl; I haven't tested this very much 
yet.

it would be really nice to have this... we can make a lot of things 
look like natural language with this.

fire up R3 and type:

>> help to-op
USAGE:
        TO-OP value

DESCRIPTION:
        Converts to op! value.
        TO-OP is a function value.

ARGUMENTS:
        value

there are a lot of things I'd setup as an OP.   the FROM example 
from geomol is a really good example of how this makes code sooo 
much more readable.

There are some real limits to op! evaluation that makes them unsafe 
for general use for now. For one thing, the type of the first argument 
is not checked at call time relative to the typespec by the evaluator 
- it has to be checked by the function itself internally. This is 
not a problem with most existing ops because they map to actions 
(which have their type compatibility handled by the action dispatcher), 
or in some cases natives that perform their own internal type checking. 
I believe this was a speeed tradeoff. If you allowed full user creation 
of ops even with their current restriction to actions and natives, 
you could bypass the typespecs of natives and corrupt R3's memory. 
Adding in that typespec check to the op! evaluator would slow down 
op! evaluation a little, but would be necessary if you really wanted 
to make user-defined ops possible.

I don't mind since we need to build a stub anyways... its easy to 
add this checking there.

this forces people to make the stub, so it becomes a programming 
error, not a language bug.

brian we are talking an api issue.  what happens before application 
starts is irrelevant.   on init, let R3 do whatever it wants.


once we start running the script, have an api-minded function which 
just makes sure that any function you send to the core used as an 
op is safe.  I don't care for any limits... just document them and 
I'll live with.   whatever the core has which I can't have... who 
cares.


as far as error reporting goes, that is the reason for the stub. 
  IT will have to either handle the error appropriately or just raise 
an error.   


really, there is no technical reason for this not being done.  its 
just a question of doing it.    limited user ops are still infinitally 
better than none.

It would be theoretically possible to make unary postfix ops in REBOL, 
as long as you used a different datatype or some flag in the op! 
value which could be set at op! creation time - the evaluation model 
of REBOL could allow such a thing. Ternary ops would be trickier: 
You would have to have the second word be a get-word parameter of 
the word! type be the underlying function's third parameter, and 
the third parameter of the op would be the fourth parameter of the 
function. All ternary ops starting with the same word would need 
to be implemented by the same function, which would behave accordingly 
based on which word is passed as its third parameter. The ternary 
op value itself would be assigned to the first word, because REBOL 
doesn't have multi-word bindings.

A similar method could be used to implement unary postfix and ternary 
ops in Red, though the tricks would be in the compiler instead of 
the evaluator.