New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal For Variable System Overhaul #46

Closed
cpancake opened this Issue Mar 25, 2015 · 7 comments

Comments

Projects
None yet
3 participants
@cpancake
Collaborator

cpancake commented Mar 25, 2015

Right now there are quite a few different types of variables (arithmetic variables, lists, subroutines, carriers...) and they don't play well together. I've talked it over with Berkin and here's what we came up with:

  • New syntax for expressions: [@ ... ]
  • String syntax: [@ a = 'word']
  • String concatenation: [@ myStringVar & 'another string']
  • Rant code interpreted inside strings: [@ a = '<noun>']
  • Rant code stored as an object: [@ pattern = $'<verb>']
  • List types are denoted by a list of items: [@ a = 1, 2, 3, 4, 5, 6, 7]
  • Appending / prepending to lists can be done by placing the items before or after the variable name in a list declaration: [@ a = 0, a, 8]
  • Access done through bracket notation: [@ a[3]]
  • Variable scopes. Variables created in blocks are local variables: { [@ a = 12] } [@ a] # a does not exist
  • var keyword for defining new, empty variables: [@ var a ] { [@ a = 12] } [@ a] # 12
  • Default value for new variables is "no" (like null or undefined): [@ var a] [@ a] # no
  • List initializer for initializing empty lists of a given length: [@ a = list 12; ] (default values are all no)
  • Boolean types. You know the drill: [@ a = true]

Thoughts? We'll probably fold the other variable systems into this one once it works and works well.

@TheBerkin

This comment has been minimized.

Show comment
Hide comment
@TheBerkin

TheBerkin Mar 25, 2015

Owner

Can we re-implement all of the current list functions as operators in the new expression syntax, too?

Owner

TheBerkin commented Mar 25, 2015

Can we re-implement all of the current list functions as operators in the new expression syntax, too?

@ottworks

This comment has been minimized.

Show comment
Hide comment
@ottworks

ottworks Mar 25, 2015

Ooh, this looks nice. What about type casting?

ottworks commented Mar 25, 2015

Ooh, this looks nice. What about type casting?

@TheBerkin

This comment has been minimized.

Show comment
Hide comment
@TheBerkin

TheBerkin Mar 25, 2015

Owner

Type casting is currently implicit, like in Javascript. For example, we have different operators for string concatenation (&) and addition (+), so a cast is not needed for Rant to know which type to return.

Owner

TheBerkin commented Mar 25, 2015

Type casting is currently implicit, like in Javascript. For example, we have different operators for string concatenation (&) and addition (+), so a cast is not needed for Rant to know which type to return.

@TheBerkin

This comment has been minimized.

Show comment
Hide comment
@TheBerkin

TheBerkin Mar 25, 2015

Owner

New list functions:

  • Appending (single): lst +> x;
  • Prepending (single): lst <+ x;
  • Appending (range): lst +>> x; # if it's a list, each item is added rather than the list itself
  • Prepending (range): lst <<+ x;
  • Clearing: lst!
  • List length: lst$
  • Remove item at index: lst[x]! (returns removed item)
  • Remove specified value: lst?[x]!
  • Get last item: lst[$]
  • Get index of value: lst?[x]

To use a list as a block, return it from an expression:

[@
    var lst = 1, 2, 'cats';
    lst
]
# Prints "1", "2", or "cats"
Owner

TheBerkin commented Mar 25, 2015

New list functions:

  • Appending (single): lst +> x;
  • Prepending (single): lst <+ x;
  • Appending (range): lst +>> x; # if it's a list, each item is added rather than the list itself
  • Prepending (range): lst <<+ x;
  • Clearing: lst!
  • List length: lst$
  • Remove item at index: lst[x]! (returns removed item)
  • Remove specified value: lst?[x]!
  • Get last item: lst[$]
  • Get index of value: lst?[x]

To use a list as a block, return it from an expression:

[@
    var lst = 1, 2, 'cats';
    lst
]
# Prints "1", "2", or "cats"
@cpancake

This comment has been minimized.

Show comment
Hide comment
@cpancake

cpancake Mar 25, 2015

Collaborator

We also decided to have a pattern type - like a string, but the contents aren't interpreted on creation.

  • Creation: [@ pattern = $'<noun>']
  • Execution: [@ pattern]
Collaborator

cpancake commented Mar 25, 2015

We also decided to have a pattern type - like a string, but the contents aren't interpreted on creation.

  • Creation: [@ pattern = $'<noun>']
  • Execution: [@ pattern]
@ottworks

This comment has been minimized.

Show comment
Hide comment
@ottworks

ottworks Mar 25, 2015

Why not just use block syntax for lists (because blocks don't work in expressions)? They're functionally identical, just one is assigned to a variable.

ottworks commented Mar 25, 2015

Why not just use block syntax for lists (because blocks don't work in expressions)? They're functionally identical, just one is assigned to a variable.

@TheBerkin

This comment has been minimized.

Show comment
Hide comment
@TheBerkin

TheBerkin Mar 25, 2015

Owner

While blocks and lists can both represent sets of data, they are fundamentally different in what they do:

Blocks

  • Represent a set of possibilities
  • Can only store patterns
  • Cannot be indexed
  • Items can be weighted
  • Immutable, with the exception of targets
  • Cannot be resized
  • Not actually objects - just a point in the code where the path can diverge.

Lists

  • Represent a series of objects
  • Can store any data type (number, string, pattern...)
  • Can be indexed
  • Cannot be weighted
  • Items are mutable
  • Resizable
  • Lists can be stored as objects and reused.

The fact that lists can be used as blocks does not mean they are the same thing - it is simply a useful result of their shared characteristics, as well as a convenient way to create and represent blocks from within expressions.

Owner

TheBerkin commented Mar 25, 2015

While blocks and lists can both represent sets of data, they are fundamentally different in what they do:

Blocks

  • Represent a set of possibilities
  • Can only store patterns
  • Cannot be indexed
  • Items can be weighted
  • Immutable, with the exception of targets
  • Cannot be resized
  • Not actually objects - just a point in the code where the path can diverge.

Lists

  • Represent a series of objects
  • Can store any data type (number, string, pattern...)
  • Can be indexed
  • Cannot be weighted
  • Items are mutable
  • Resizable
  • Lists can be stored as objects and reused.

The fact that lists can be used as blocks does not mean they are the same thing - it is simply a useful result of their shared characteristics, as well as a convenient way to create and represent blocks from within expressions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment