currently, list and variables are separate. in the engine, though, they're essentially the same thing: both *variables*, just that they're different types…

alongside other loose typing, what if we could modify variables to be differently typed as well, instead of just number/string? additionally, that would allow us to separate a list into its current text format (like when you click on a list reporter now) and returning the actual list's data, maybe through a block like this:

{(foo)} :: stack #fff // returns the actual data (setting a different variable to the foo reporter links them)
{(text of [foo v] :: variables)} :: stack #fff // returns just the text

let's say we do this.

set (foo) to [bar]
(foo) // bar

but it's a string, right? so add item would crash it, unless…

add [qux] to (foo)

actually just converts it to an array/list, with the original value as the first item.

(foo :: list) // bar,qux

and similarly, running “set” on a variable that is currently a list just gets rid of its items and converts it back to a number/string.

to check types, we'd probably do something like this:

{<[foo v] is a [number v]? :: sensing>} :: #fff stack
{<[foo v] is a [string v]? :: sensing>} :: #fff stack
{<[foo v] is a [list v]? :: sensing>} :: #fff stack

i don't know how complicated this is. if it's too much like Snap!, well, maybe? but i feel like it's not really the same. yeah, maybe people could get confused about “wait, is it a list or just a number”? but… get this,

define result = (x) ~= (y) with (place)
set (x) to ((round ((x) / (place))) * (place))
set (result) to <(x) = (y)>

hmm.. what if. i don't know, this idea just sounded Really Interesting to me and could probably give numbers, strings, and lists a lot more functionality

LOL I thought this was like renaming the variables category back to data only

medians wrote:

LOL I thought this was like renaming the variables category back to data only

the moment I saw the title I knew you would be the first to comment
——–
I semi-support this, I think it's nice but it's also confusing and a little unnecessary

also, could you further explain what the difference between

(foo)

and

(text of [foo v] ::variables)

is?
I'm a little confused

Uh
This is really confusing
It sounds useful I guess? But it should definitely be an extension instead of a replacement for how variables currently work because I can't understand the suggestion at all ;-;

ilIusionator wrote:

medians wrote:

LOL I thought this was like renaming the variables category back to data only

the moment I saw the title I knew you would be the first to comment
——–
I semi-support this, I think it's nice but it's also confusing and a little unnecessary

also, could you further explain what the difference between

(foo)

and

(text of [foo v] ::variables)

is?
I'm a little confused

“foo” is the variable itself, “text of foo” is just the value. if you set another variable to “foo”, then changing that variable also changes foo (since you are giving foo itself to the other variable), while setting another variable to “text of foo” just takes foo's text and sets itself to that number/string.

knowitall1237 wrote:

Uh
This is really confusing
It sounds useful I guess? But it should definitely be an extension instead of a replacement for how variables currently work because I can't understand the suggestion at all ;-;

yeah, it might be better as an extension, but not like a whole different category. maybe there'd be a way to switch from square dropdowns to this?

about foo and text of ", isnt the value and the text the same?
it's just that the explanation you gave to illusionator is still confusing