Hopscotch Notation (& Compiler)

hah, i blame my reading issues xD what did u mean then?

i was thinking you wanted the syntax to be

instead of the contractions of it (o, g, u)

7 Likes

Ah my bad; that’s something completely different. My syntax would still have much of the same problem that you have to learn what’s the way to do it

5 Likes

If your intention is to have a clear way to represent Hopscotch code in a textual way, I feel like the contractions would hurt that goal, since self.variable is basically identical to the original Hopscotch code while s.variable needs additional explanation.

^^ this

7 Likes

fair, i think you both are right - im down for the change :+1:

to be clear, this is the new syntax:

// ways to declare a variable:
local.var = "first way to declare a local var"
var = "second way to declare a local var"
object.var = "declare an object var"
game.var = "a game variable"
user.var = "an user variable"

// object variable specifications:
object.var = "stands for self"
self.var  // or do you prefer this way?
original_obj.var = "attaches the original object"
"monkey".var = "attaches 'monkey'"

// built-in hs attributes:
self.position
self.z_index
self.rotation
original_obj.position
original_obj.z_index
original_obj.rotation
"monkey".position
"monkey".z_index
"monkey".rotation

((@Awesome_E too))

6 Likes

what if i did it like so?

local var = "first way to declare a local var"
var = "second way"
object var = 7
self var   // do you prefer this way?
game var = 7
user var = 7

object var = "stands for self"
self var   // do you prefer this way?
original_obj var = "attaches the original object"
"monkey" var = "attaches monkey"

basically if a parameter is followed by a dot (.), it means its a default orange hs variable. if its followed by a space ( ), its a variable created by the user

object some_weird_variable = floor(7 * game FPS) / object returned_value ^ 2

that is the downside tho ^^ really weird

object:some_weird_variable = floor(7 * game:FPS) / object:returned_value ^ 2

or i can do a colon (:) but it starts to get heavy


CONCLUSION: PLEASE VOTE

which notation for declaring variables; a dot, a space or a colon?
  • game.variable
  • game variable
  • game:variable
0 voters
which way to prefix an object variable when you attach to yourself? object or self?
  • object.variable
  • self.variable
0 voters
6 Likes

I like this a lot. If you want to keep it as close to HS as possible, then you could also follow block names, so “set local pointCount = 10”

I like what you have though

7 Likes

yeah i do too, but the only and big reason why i hate it as well at the same time is how confusing it is when its put inside some math (was shown above) :sweat_smile: if we find some workaround somehow to that inconsistency, def down for that syntax

ill think of some pros and cons of that coding wise :+1:

8 Likes

@polygons okay yeah, sorry for the tag but this is really important

if you’d like to get tagged for deciding on the syntax of a word in the future, vote here


quicklinks:
ongoing poll 1, ongoing poll 2

8 Likes
  • turn = 90
  • turn_degrees = 90
0 voters
7 Likes

this post will be where i note every changes


additionally, i decided to change the syntax position.x and position.y to x_position and y_position - easier for me and probably more intuitive for yall

9 Likes

neither; setting that equal to something is unintuitive. Perhaps one of these?

turn degrees 90
turn degress (90)
7 Likes

agree with this minus typo, maybe even turn_degrees(90)

set_angle = 90 makes more sense

6 Likes

i honestly really like that, but i need to actually be sure if i can code it that way - since it no longer consists for splitting each line by the equal sign

but i think i can do it so yeah

also, turn_degrees will be the official syntax

7 Likes

You can make all parameters in parentheses

5 Likes

I like this. Maybe for times when it is necessary to avoid confusing a dot could also be used for a user created variable, but with spaces preferred.

Definitely something like this. Maybe even turn(degrees: 90)? Although the lack of parentheses is kind of nice, maybe only include them for things where it could be confusing without them? Like
set text to "Hello" color (h 200 s 50 b 50)
And maybe quotes could be used for strings.

I really like the idea of spaces being allowed between the block name and parameter key.

6 Likes

im still thinking of the douability of parenthesis instead of equal sign - basically im coding both of them at the same time

if you have multiple inputs, the equal sign way would be to write

position = 100, 100
position = ...
    100,
    100

but for parenthesis, how do you write that?

position (100), (100)
position (100) (100)
position (100, 100)

and not to forget multiline but we’ll talk about that later

EDIT: poll is two posts below




unless people dont agree with me, this is really confusing with me haha

the syntax i used in the op is the following

text = "hello", hsb(200, 50, 50)

so im guessing with parenthesis, itd be

text ("hello"), (hsb(200, 50, 50))

or something similar to that
for this block tho, i prefer the equal sign syntax

7 Likes

What if you said something like

setpos(300,300)

5 Likes

so the third option, okay

ill make a poll tho, easier for me

  • position (100), (100)
  • position (100) (100)
  • position (100, 100)
0 voters

@Cobalt_Phoenix @Nobody @RoadOcean @/Petrichor (already voted) @Heracc

9 Likes

No not the third option, “position” doesn’t make sense because that doesn’t mean anything on its own

I’m saying setpos is better because it’s shorter and makes sense out of context, and I just included the parenthesis that had no space and commas which wasn’t on there with the other options

6 Likes

spaces are optional

if more people disagree with the use of position both for the variable (s.position) and the block, im gonna open a poll. but general rule is no contraction and snake_case (not camelCase or anything unofficial), so thats why i used position at first place

8 Likes