It is currently Sat Mar 25, 2017 10:35 am



Welcome
Welcome to rfobasic

You are currently viewing our boards as a guest, which gives you limited access to view most discussions and access our other features. By joining our free community, you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content, and access many other special features. In addition, registered members also see less advertisements. Registration is fast, simple, and absolutely free, so please, join our community today. **You are not required to provide truthful information to any registration questions. Be whomever you wish to be.!


Post new topic Reply to topic  [ 7 posts ] 
Author Message
 Post subject: ARRAY.COPY
Unread postPosted: Sun Aug 21, 2016 6:50 am 
Offline
User avatar

Joined: Thu Jan 08, 2015 11:28 am
Posts: 1087
Location: .NET
Manual - ARRAY.COPY wrote:
If the Destination Array does not exist, the optional <extras> parameter specifies that <extras> empty elements are to be added to the new Destination Array before or after the copy. These elements will be added to the start of the array if the optional minus(-) sign is present. If minus is not present then these elements will be added to end of the array.

If the Destination Array already exists, the optional <extras> parameter specifies a starting index into the Destination Array. If the remaining length of the Destination Array starting at the <extras> index is less than the number of elements to be copied from the Source Array, anything that would not fit is not copied.


to be honest this is kind of a pain to read. trying to implement this and my head is already spinning. how about this?

Quote:
If the Destination Array does not exist, the optional <extras> parameter specifies the amount of empty elements to be added after the copy. If <extras> is a negative number, the elements will be added to the beginning of the Destination Array.

If the Destination Array already exists, the <extras> parameter specifies a starting index into the Destination Array. If the length of Destination Array after the <extras> index is less than the amount of elements copied from the Source Array, items that do not fit are not copied.


i am sure the description can be improved more, but it's a bit more understandable.
the problem in the first place is that <extras> is does 2 things depending on context, which is not nice, but separately they make sense. i guess the bigger issue is that some commands implicitly create new objects, when one doesn't exist. while that makes the code shorter and life "easier" i think it makes it unpredictable and inconsistent (i can't find better words).

_________________
https://github.com/evolbug
http://toobasic.jimdo.com


Top
 Profile  
 
 Post subject: Re: ARRAY.COPY
Unread postPosted: Mon Aug 22, 2016 1:26 am 
Offline
User avatar

Joined: Sun Nov 23, 2014 8:15 am
Posts: 2184
Location: romania
Evol is right
I didn't understand the first definition but I did understand the second


Top
 Profile  
 
 Post subject: Re: ARRAY.COPY
Unread postPosted: Sat Aug 27, 2016 1:07 am 
Offline

Joined: Wed Oct 03, 2012 9:53 am
Posts: 2778
Location: Colorado, U.S.
I agree, that's much better wording. Thank you. I suppose I'll have to rewrite the rest of the section to match.

It's interesting that your words treat the sign and the digits as a single entity -- a negative number -- while Paul's words treat the sign and digits as two separate things -- a flag and a (positive) value. In BASIC!, there are no negative numeric constants. The minus sign is a unary operator that operates on the (positive) numeric constant, affecting the value of the expression. That allows the parser to treat variables and constants the same way: -a is "the arithmetic inverse of the value of the variable 'a' ", and -123 is "the arithmetic inverse of the value of the numeric constant '123' ".

The manual should tell the story from the point of view of the user programming in BASIC!, not that of the developer of the BASIC! interpreter.

> unpredictable and inconsistent

Yes, those are good words to describe the result of several years of demand-driven development and organic growth. It has been observed that it is very difficult to program in BASIC! without the manual at your elbow. (Quick: how do Array.Length and List.Size differ in syntax?) That's a serious flaw.

I have worked on BASIC! so little this year that it's getting hard to remember why I did things, or even to remember what is mine and what was Paul's. But it seems to me that I have worked to make BASIC! more predictable and consistent.

I can't fix things like the Array.Length and List.Size syntax differences, because of backward compatibility. But where I can, the idea is to set a goal for how things should be. Going forward, all new things conform to the goal. As time and opportunity permit, old things are made to conform to the goal. Sadly, time and opportunity hardly ever permit.

Take optional parameters. With every new command, I think about whether it makes sense to make the parameters optional, and I've retrofit many commands to make their parameters optional. However, I have not tried to sweep the entire command set; both the code and the manual would require many hours of rework for very little gain. The result is unpredictable and inconsistent.

The goal for commands that create objects is that they all should behave the same way: if the array/list/stack/bundle exists, it is modified. If it does not exist, a new one is created. You say, "the bigger issue is that some commands implicitly create new objects, when one doesn't exist", as if this is surprising. You should think of this behavior as normal, and treat anything that behaves differently as the surprise. There should be a good -- and obvious! -- reason for the surprise. If there is not, it's a bug that should be fixed.

As you would expect, there are problems with this thinking:
- Exceptions: There are lots of them, and some are justified (like commands that create graphics objects).
- History: This is not traditional BASIC behavior, or even the original BASIC! behavior. It's something I added. It's a change. Incomplete change is one (big!) reason for the exceptions.

Consider: Array.Copy originally had no provision for copying into an existing array. It always created a new array. What you now consider surprising was the norm, the only available behavior. Is this forward progress? Or backward?

- Marc


Top
 Profile  
 
 Post subject: Re: ARRAY.COPY
Unread postPosted: Sat Aug 27, 2016 6:32 am 
Offline
User avatar

Joined: Thu Jan 08, 2015 11:28 am
Posts: 1087
Location: .NET
jMarc wrote:
Consider: Array.Copy originally had no provision for copying into an existing array. It always created a new array. What you now consider surprising was the norm, the only available behavior. Is this forward progress? Or backward?


i am not really surprised about the creation itself, i am concerned about the new functionality that gets merged with the existing command, and creates separate new rules for the case, like the "extra" means two totally different things depending on whether there is an array or not. i would have liked Array.CopyInto/CopyTo, separate command, but keeps the functionality distinct, with no "special" cases.

but this isn't the worst example of duality, ENCODE$ and DECODE$ now is my pet peeve, overloaded functions which can do... two UNRELATED things? :o

_________________
https://github.com/evolbug
http://toobasic.jimdo.com


Top
 Profile  
 
 Post subject: Re: ARRAY.COPY
Unread postPosted: Sat Aug 27, 2016 7:03 am 
Offline
User avatar

Joined: Thu Jan 08, 2015 11:28 am
Posts: 1087
Location: .NET
if you look at this description, what do you see?
Code:
ENCODE$(<type_sexp>, {<qualifier_sexp>}, <source_sexp>)

Returns the string <source_sexp> encoded in one of several ways, as specified by the <type_sexp>. The <qualifier_sexp> usage depends on the type:
Type      | Qualifier | Default    | Result
----------|-----------|------------|------------------------------------
"ENCRYPT" | password  | "" (empty) | Encrypts the source string using the password
          |           |            | parameter. The encryption algorithm is
          |           |            | "PBEWithMD5AndDES". This usage of ENCODE$() works the
          |           |            | same was as the ENCRYPT command.
----------|-----------|------------|------------------------------------
"DECRYPT" | password  |     ""     | Same as type "ENCRYPT".
----------|-----------|------------|------------------------------------
   "URL"  |  charset  |   "UTF-8"  | Encodes the source string using the format required by
          |           |            | HTML application/x-www-form-urlencoded.
          |           |            | You should omit the charset parameter.
----------|-----------|------------|------------------------------------
"BASE64"  |  charset  |   "UTF-8"  | Encodes the source string into the Base64
          |           |            | representation of binary data. See RFCs 2045 and 3548.
          |           |            | The simplest way to use this function is to omit the
          |           |            | charset parameter.


i see "encrypt" and "decrypt", two things which already have commands, so they don't need to be and even don't BELONG here.
and i see "url" and "base64", both of which explicitly tell you to omit the charset parameter.

so in my eyes this overloaded version has no reason to exist, it just creates more confusion than reason
1. encrypt/decrypt already exist
2. "url" and "base64" can be moved to ENCODE$(<charset_sexp>, <source_sexp>), as charsets, or have their own functions.

_________________
https://github.com/evolbug
http://toobasic.jimdo.com


Top
 Profile  
 
 Post subject: Re: ARRAY.COPY
Unread postPosted: Sat Aug 27, 2016 3:07 pm 
Offline

Joined: Wed Oct 03, 2012 9:53 am
Posts: 2778
Location: Colorado, U.S.
evolbug wrote:
i would have liked Array.CopyInto/CopyTo, separate command, but keeps the functionality distinct, with no "special" cases.
There is a long-standing rule that we don't add unnecessary commands because it makes the linear search of the command table slower for everyone, even if you don't use the new commands. I could also argue that having more commands to remember is no better than having related functions performed by the same command. And finally, adding more commands adds more error cases: what should Array.CopyInto do if the target array does not exist, or Array.CopyTo if the target array does exist?

I won't say my reasons for combining commands are better than your reasons for adding separate commands. I just want you do know that there are reasons.

evolbug wrote:
ENCODE$ and DECODE$ now is my pet peeve, overloaded functions which can do... two UNRELATED things?
That depends on your point of view. ENCODE$() encodes strings. That's all it does. Those things you claim are unrelated are related by the fact that they are string encodings.

- Marc


Top
 Profile  
 
 Post subject: Re: ARRAY.COPY
Unread postPosted: Sat Aug 27, 2016 3:19 pm 
Offline

Joined: Wed Oct 03, 2012 9:53 am
Posts: 2778
Location: Colorado, U.S.
evolbug wrote:
1. encrypt/decrypt already exist
http://rfobasic.freeforums.org/urlencode-urldecode-t2739.html
and in particular the last few posts, ending with
http://rfobasic.freeforums.org/post21722.html#p21722

Nobody argued with me at the time -- it seemed to be an improvement over what was there before.
The primary goal is a general-purpose string encode/decode command pair, any requested encoding is easy to add.
The secondary goal is to avoid adding many commands, see previous post.

An instance of the primary goal: in the next release there will be mougino's "ENCRYPT_RAW" and "DECRYPT_RAW", with no new commands.

For functions (as opposed to commands) the secondary goal is a little less important now than it used to be, because now the command search is a hash-table look-up, not a linear search. You can't optimize a hash look-up, so for many commonly-used functions the look-up is slower, but there are two advantages: 1) the average is faster, 2) adding new commands has almost no cost in search time.

evolbug wrote:
2. "url" and "base64" can be moved to ENCODE$(<charset_sexp>, <source_sexp>), as charsets
Oh, good point, I wish I'd thought of that. I never liked having two- and three-parameter forms of the functions, but I was thinking of the charsets as the standard Java charset identifiers, so I was blinkered by the implementation. As I said in one of those posts, I let the code guide my hand. Not always the best approach, but in the absence of anything better, it happens.

- Marc


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
suspicion-preferred