Virtual Types

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark

DarScott
Posts: 227
Joined: Fri Jul 28, 2006 12:23 am
Location: Albuquerque
Contact:

Re: Virtual Types

Post by DarScott » Fri Jun 21, 2013 9:58 pm

I think people are going to be astonished about how long this takes (using your "trite" example above):

Code: Select all

   doSomething item 95 of line 4201 of x
Assuming I understand what you are proposing.


Maybe the above can be translated to this:

Code: Select all

   doSomething char 12044 to 12091 of x
I'm assuming that can be accessed in time related to the length of the chunk not in time related to the position.

If there are multiple chunk connections to a string value, then a change to the length of the chunk can then change all other chunks to the right. (The implementation would have to find the parent string, then find all chunks connected to the string.) This would have the same behavior as passing a chunk expression, except for those cases that change the chunk location such as putting a comma in the middle of an item. So, what I propose here would still work for this:

Code: Select all

   doSomethingTo2Things   item 3 of line 17 of x,   item 8 of line 34 of x
Unless you stick a LF or comma into the first reference.


However, one advantage of passing the chunk expression is that it allows optimization in the future.

DarScott
Posts: 227
Joined: Fri Jul 28, 2006 12:23 am
Location: Albuquerque
Contact:

Re: Virtual Types

Post by DarScott » Fri Jun 21, 2013 10:40 pm

Ah, it slowly comes to me. I see the problem with passing a child element as a single entity instead of the the path of keys from a root array.

Code: Select all

   put x["a"]["b"]["c"] into y  -- no copy
   doSomething  y["d"]["e"]
But when doSomething modifies its parameter, then a partial copy is forced for y. The value for x remains unchanged.

(I have been working with functional programming and keep forgetting how things must be when branches and leaves are mutable.)

I'm convinced.

And for consistency, chunks can be similar--a chunk path is created.

I do use the reference parameter as a working variable. If I am returning a value I might use that variable to accumulate pieces, even chars. I think I will do that less. That is, in a sense, I do that trite example you mentioned.

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: Virtual Types

Post by LCMark » Sun Jun 23, 2013 4:08 pm

I think people are going to be astonished about how long this takes (using your "trite" example above):
Anymore astonished when they realize how long this takes:

Code: Select all

  repeat 100 times
    add 1 to item 95 of line 4201 of x
  end repeat
Essentially, the by-ref semantics we are discussing come down to the same thing.

This really is a case of where optimization solves the performance 'problem' for such things - as the same process that will optimize the use of the by-ref parameter in the case above is exactly the same as the one that would optimize the use of the chunk expression in the above loop. (Indeed, it's identical, the fetch is hoisted out of the loop to the start, and the store is pushed out of the loop to the end - the alias analysis to prove that this can be done safely is the key thing and is needed whether a ref parameter is used, or if a direct chunk is used).

DarScott
Posts: 227
Joined: Fri Jul 28, 2006 12:23 am
Location: Albuquerque
Contact:

Re: Virtual Types

Post by DarScott » Sun Jun 23, 2013 4:26 pm

Yes, I think more astonished. The handler could have been written by another person or written several days before.

I think this creates a responsibility for the handler writer to consider (for now) performance in the case of chunks and array elements. It also creates a responsibility in describing allowed parameters and a vocabulary might need to be developed for that.

DarScott
Posts: 227
Joined: Fri Jul 28, 2006 12:23 am
Location: Albuquerque
Contact:

Re: Virtual Types

Post by DarScott » Sun Jun 23, 2013 4:33 pm

I assume chunk references will create a requirement for representing chunks out of order and of arbitrary depth and repetition. Also each item chunk would have its own delimiter carried along with it. With recursion, this can get deep.

If it is allowed here, then maybe it can be allowed other places like this:

Code: Select all

   get item 3 of char 200 to 300 of x

DarScott
Posts: 227
Joined: Fri Jul 28, 2006 12:23 am
Location: Albuquerque
Contact:

Re: Virtual Types

Post by DarScott » Mon Jun 24, 2013 3:03 pm

The discussion on the Use LiveCode list on small numbers is, to me, an indication of why (virtually) getting rid of numbers is has some benefits. Whether those are worth the cost of breaking the places numberFormat comes into play is a reasonable question.

This is totally WYSIWYG, so intermediate values make sense. These are potential (virtual) strings from the result of arithmetic:

42
123.456789
1.05*10^-32
-infinity

The meaning would be exactly that of the (virtual) string.

Getting rid of numbers means that something is needed to ease changes to legacy scripts that use numberFormat. A simple function or operator could be used to force application of numberFormat to a numeral, say, numberFormat(x) or num(x). The function could essentially do what &empty did before.

Locked

Return to “Engine Contributors”