World: r3wp

Yep, this discussion is recurring. There are pros and cons.
I would like to know the opinion of Carl about this.

#[none] could be a special "transient" value which impacts the behavior 
of DO .

Allowing to passthru a chain of functions without breaking the flow.

That would destroy the locality of errors. Every time you pass through 
none, it takes you further away from the code that resulted in the 
none in the first place. The further you pass it through, the harder 
it is to figure out where it came from. We have been careful about 
the balance about where none is passed through, but there are still 
some tweaks to go.

The INDEX? case has been covered by a CureCode discussion, and it 
looks like a good idea. For LENGTH?, the same behavior of returning 
none when passed none would make just as much sense. Under no circumstances 
should INDEX? or LENGTH? return an integer when passed none, not 
even 0.

Davide, REBOL doesn't have a neutral value for any type. This is 
by design. What we have instead is a value that can be used to mean 
nothing: none. And we have control structures to convert non-values 
to a default value: ANY and DEFAULT. R3's control structures are 
built around that principle, including the changes to the ordinal 
functions and EXTRACT.

@BrianH: Agree on that point 100%, but...

>> append "mystring" none   
== "mystringnone"

That does not have the right "feeling" to me.

Again, this is the awkward dynamic between consistency and intuition. 
 If you can state an invariant, like "If S is a string, then append 
S FOO is equivalent to append S to-string FOO" (for example) then 
it might be like "oh, it makes sense once you know that rule".  But 
you've got to find the layer at which people program, and this is 
when I start using the phrase "tail wagging the dog" because people 
are being asked to program at the APPEND layer so the implementation 
details of append should be secondary to what is sensible.

We can't make it trigger an error, because appending none is valid 
in some circumstances. And having the word "none" appended is good 
for flagging errors in developers' code. Really, the error is that 
you didn't screen for none when clearly (by your reaction) you didn't 
want to append none.

But we can only know that not screening for none was an error by 
your reaction. For others, it wouldn't be an error.

And since REBOL can't see your reaction, it has to go by what you 
said to do, not what think you wanted it to do.

join "a" any [ find "x" "abc" copy "" ]

One just has to be prepared for the failed find

I know what you mean, as appending none to a block does add a "none". 
 Though APPEND [A B] NONE currently seems to do the same thing as 
APPEND [A B] 'NONE.  I would be interested to know the side effects 
of saying APPEND [A B] NONE gave [A B] while APPEND [A B] 'NONE gave 
[A B NONE].

What you said to do is append none to a string. By your reaction, 
you wanted to append an empty string to the string. That means this 
(assuming that you don't know that the none is there):
>> append "mystring" any [none ""]
== "mystring"

The need for none to be explicitly converted to other values, rather 
than implicitly, is an intentional design choice that has been applied 
to a great deal of R3. It is not an error.

It wasn't Fork , it was DavidE

Sorry, you're right, I was using Fork's example code.

As for the side effects of not appending none, Fork, that woulld 
ruin blocks that contain fixed-length records of positionally accessed 
data, a common useage pattern. If nothing is appended, the positions 
of the subsequent stuff would be off.

<<Note: Though it's weird to be called Fork (blame Reichart, he made 
this account for me)... I think it would be more confusing with another 
Brian.>>

I see your point.  Hmm.

Ever consdier an operator which converts none! types into none words 
and passes everything else through unmodified?

>> join "a" any [ find "x" "abc" copy "" ]
pretty common idiom (though, you don't need of the copy)

Why would we need to convert #[none] to 'none ? The value #[none] 
is more useful; because of ANY and DEFAULT. Neither of those will 
convert 'none to a default value, but they will convert #[none].

when seeing the "NONE stuff" discussed, the expression like


 parse "123" [(r: copy "result: ") copy s any "x" (append r s) to 
 end]


looks as the situation, where the result obtained from R3 is more 
useful.

>> join "a" any [ find "x" "abc" copy "" ] 

I will use this idiom, thanks. 

But still I think that having "idioms" in programming language  is 
a  symptom of something not really correct.

All programming languages are inherently limited. You have a limited 
number of built-in words and concepts. Because of this there will 
only be a limited number of concepts that can directly be supported 
by the language without combining words. To form other concepts, 
you need to combine words - aka composing functions. As more concepts 
are shared, the best combination of words to express them will be 
shared and refined as well. These combinations of words are idioms. 
Idioms are not a symptom of something which is not correct, quite 
the opposite. The ability to form idioms is a sign of a healthy language 
that is more powerful, able to handle more complex concepts. Idioms 
are always an inherently good thing.

Ladislav, for PARSE yes.

The trick for language design is not to get rid of idioms, but instead 
to do whatever you can to make possible to make simple idioms more 
powerful. This is usually done by making the different parts of the 
language fit together better, and and more flexibly. You get more 
flexibility by making the core concepts simpler, and then making 
them as widely and consistently applicable as you can without breaking 
them. Consistency is key here, and not just key in a positive way. 
More consistency means that you can fit more of the parts of the 
language together better. However, you have to limit consistency 
to places where it makes sense, and has real benefits. False consistency 
can get in your way.

Added bug#1626 (LENGTH?) and bug#1627 (APPEND and INSERT) about #[none] 
passthrough. #1627 was added to be dismissed.

>> append #{} 15
== #{3135}
>> append #{} "15"
== #{3135}


Why if I append an integer to a binary it is first converted to an 
ascii string?

IMHO it should be like this:
>> append #{} to-char 15
== #{0F}

R3 has the kind of behaviour you want. R2 won't be changed as it 
will break many scripts. I agree with you that R3 method is more 
logical.

It is consistent with to-binary:
    to-binary 15
    == #{3135}
    to-binary "15"
    == #{3135}

Yes, R3 seems more logical !

>> append #{} 10
== #{0A}

This could be handy :

>> head insert #{} [1 2 3 4]
** Script error: invalid argument: [1 2 3 4]
** Where: insert
** Near: insert #{} [1 2 3 4]

Yes. If it's not in CureCode, you should put it there.

R3 has that behavior as well. Don't know how likely it would be to 
add to R2, but if it is added with R3 behavior it would be helpful.

Or rather, R3 has the ability to insert blocks into binaries, not 
the ability to complain about it and trigger an error as in your 
example :)

>> head insert #{} [1 2 3 4]
== #{01020304}

We don't yet have a CureCode project for R2.

Alternative way R2/R3
>> to-binary to-tuple [1 2 3 4]
== #{01020304}

Nice! But you have to do it in sections of 10 or less, due to the 
length of tuples; not a complaint, a gotcha to look out for.

12 for R2

11, sorry

now i'm wrong, 10

... look at the red light.
FLASH !!!!!!!!!!!!!!!!!!!

Hello - hope someone can find the newbie mistake I'm making here. 
 Wanted to use REBOL to tackle a need to get data from Salesforce 
using their SOAP API.  New to SOAP, WSDL and Salesforce, but using 
SoapUI mananged to do this POST (edited only to hide personal info):

POST https://login.salesforce.com/services/Soap/u/19.0HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: text/xml;charset=UTF-8
SOAPAction: ""
User-Agent: Jakarta Commons-HttpClient/3.1
Host: login.salesforce.com
Content-Length: 525


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:partner.soap.sforce.com">
   <soapenv:Header>
      <urn:CallOptions>
         <urn:client></urn:client>
         <urn:defaultNamespace></urn:defaultNamespace>
      </urn:CallOptions>
   </soapenv:Header>
   <soapenv:Body>
      <urn:login>
         <urn:username>[jort-:-xxxxxxxxxxxxx-:-com]</urn:username>

         <urn:password>xxxxxxxxxx78l6g7iFac5uaviDnJLFxxxxx</urn:password>
      </urn:login>
   </soapenv:Body>
</soapenv:Envelope>

and get the desired response:

HTTP/1.1 200 OK
Server: 
Content-Encoding: gzip
Content-Type: text/xml; charset=utf-8
Content-Length: 736
Date: Fri, 02 Jul 2010 20:32:14 GMT


<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns="urn:partner.soap.sforce.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><loginResponse> 
......

Then using SoapUI I am able to send a successful Logout message.


Using REBOL 2.7.7.3.1, I created an "upload" string containing the 
POST block above without the "POST " at the beginning, set my url 
to:

>> url
== https://login.salesforce.com/services/Soap/u/19.0

and tried this:

>> response: read/custom url reduce ['POST upload]

but consistently get a Server 500 error:


** User Error: Error.  Target url: https://login.salesforce.com:443/services/Soap/u/19.0 
could not be retrieved.  Se
rver response: HTTP...
** Near: response: read/custom url reduce ['POST upload]

For completeness, here's the upload value:

>> print mold upload
{https://login.salesforce.com/services/Soap/u/19.0HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: text/xml;charset=UTF-8
SOAPAction: ""
User-Agent: Jakarta Commons-HttpClient/3.1
Host: login.salesforce.com
Content-Length: 525


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:partner.soap.sforce.com">

   <soapenv:Header>
      <urn:CallOptions>
         <urn:client></urn:client>
         <urn:defaultNamespace></urn:defaultNamespace>
      </urn:CallOptions>
   </soapenv:Header>
   <soapenv:Body>
      <urn:login>
         <urn:username>[jort-:-researchpoint-:-com]</urn:username>

         <urn:password>metrics12378l6g7iFac5uaviDnJLFVprDl</urn:password>
      </urn:login>
   </soapenv:Body>
</soapenv:Envelope>}

Would appreciate any help you can give!

Why is there a one byte difference in the cotent-lengths?

And why is the soap body formatted that way?  Anytime I've had to 
send soap messages I had to strip out all unnecessary newlines etc 
from the soap body.

Hi Graham - sorry to be dense - how did you determine there was a 
1 byte difference in length?


Re. the soap body format, I just copied/pasted from the SoapUI screen....I 
will have to test and see if the newlines are the problem - Thanks 
for the suggestion!

sorry ... I misread it.