# (My own language) TileW@! programming language

Wrote this over about 18 hours of today. I thought you guys would be happy, and also I want some feedback. I plan to add many things to make it a functional language in the future.

I made a document with some example programs I used for testing, as well as information on how to write programs and to run them.
Document: Highly Recommended
https://snap.berkeley.edu/project?user=odysseus_ssb&project=W%4011%20Language

R to run code (will also do input if there is no stored code)
C to input code

It's pronounced Wall.
Will check post tomorrow.

Umm...

Edit: Actually it's in a custom block...

Edit 2: Probably ADD CURSOR or REMOVE CURSOR.

Edit 3: (from a post on my other account) It looks a lot like Befunge.

I got an error from your first sample program:

Also, when I run it from the community site page rather than from the Snap! editor, I get an error even just on Hello world:

Otherwise looks nice. I had some trouble reading your code, but the comments help a little, but I didn't see the comments until I happened to reduce the stage size in order to read a long block. There's that little yellow line going off to the right, but that wasn't enough to catch my eye. I think you should attach a (boldface, one-line) comment to the hat block saying "look right for comments" or something like that.

On the other hand, you could consider Harvey's Law of Documentation: Any time you are tempted to comment a piece of code, rewrite it instead. Preferably, rewrite it to be less clever. I know this law is the opposite of what your other CS teachers tell you, but they're wrong.

more

A program is a tree structure of procedures. In a well-designed program, the procedures near the root (the ones called directly by the main program) have broad jobs to do ("read the input" for example), and the ones at the leaves handle details that really don't affect the logic of the program.

Now, if programmers weren't lazy, for every program there would be a documentation tree with the same shape as the program tree, with each node corresponding to the procedure at the corresponding node in the program tree. So there would be broad documentation of the big pieces, and very specific documentation of the little pieces.

But that's never going to happen, because programmers are lazy. So, given that you're only going to be given part of the documentation tree, do you want the top part or the bottom part? Answer: The top part will be much more helpful in understanding the program logic. The bottom part consists mainly of trivial comments:

So, when I say not to comment your code, I don't mean not to write documentation. I mean to write high-level documentation about how the program works. If you feel the need to comment a low-level detail, either you're being clever (e.g., taking advantage of some adventitious detail of the bit patterns representing numbers) or you're not using data abstraction (NEW POINT, X VALUE OF POINT, Y VALUE OF POINT, SET X VALUE OF POINT, SET Y VALUE OF POINT).

I definitely try to follow this rule in my own code... Any time I find myself typing /* I think "Uh oh, how can I make this more straightforward?"

If you want to see an example of high-level program documentation that I wrote, there's one here: ucblogo-code/plm at master · jrincayc/ucblogo-code · GitHub. "PLM" stands for Program Logic Manual, which is something IBM used to sell for their big mainframe computer software, because back then the expectation was that everything was open source (not free, though, in either sense) and that some of their customers would have programmers on staff who'd want to personalize the software they used.

Cool, it’s kind of similar to S1ML. But there is an error as posted above. Also one of the list elements in the compile is not identified.

Which of the two errors posted above are you referring to?

This one

Previously it was working. I believe something is causing the cursor coordinates to be deleted which is the cause of this error. I will investigate.

I think it's working now. For the move direction commands (<, >, ^, v) I changed from a blank to 0xblank so that the movement always has a number input.

I tried it and it worked for me. Idk what was happening or why it isn't now.

Also I have been doing some work on trying to implement a system for brackets to introduce some math. It hasn't been going well so I might first add a more limited system (maybe it will even help with keeping this an esolang.)

I'm still getting "expecting a list but getting text" from "!Hello world!"

There's supposed to be a space between the ! and Hello World
"! Hello World!"
I don't know if that's the code you're running or just what you typed. Also you need to place the 1 at the start of the program. It should entirely look like;
"1

! Hello World!"

2 New Updates: Rename + Update to language itself
W@11 has been renamed to TileW@!!, pronounced 'Tilewall'. The exclamation marks are to recognise Snap! as the founding component of the project.

Version 0.2 has been released (assuming the project still up for "W@11" is considered 0.1). 0.2 has added operations, but due to some limitations of my scripting, I am not yet able to have multiple operations in the one block.

• Operations: +, -, *, /, ^, % and abs are now all operations. Commands with number inputs can use Operations. For example "(1)+(5)" will be read as 6. I am quite unhappy with the current limitations of the system. Wrapping input in quotation marks prevents this from occuring.
• Execution Time Meter: This meter changes how long will be waited between executing instructions. Set to 0 for fastest execution, and 1000 for ease of following the program running.
• Bugfixes: A multitude of bugs were addressed in 0.1, as well as a bug in which using the scroll commands (>, <, ^, v) with a number following them would cause an error in the code for removing the cursor. The add and remove indicator blocks now occur within the move cursor blocks, hopefully making for a more robust system.

TileW@!!

Documentation will continue to be found at same document.

Today I plan to add a few more features for Version 0.2.1. After this I have no exact plans.

@bh rate my documentation : link

The hello world example works now.

I tried this:

2 >,,v,
! Hello World!,,<

(your second sample program) and got "expecting a list but getting text."
I expect I'm still doing something wrong... Part of the problem is that I can't type multi-line text into the ASK AND WAIT thingy; I have to copy paste it.

I was with you until "for each object :"; beyond that point it got too detailed. Here's what I'd prefer to see:

for each object :
get properties
draw edges
draw nodes


If you need more details, attach them to comments on the subprocedures, and even then, prose is better than line-by-line code comments, e.g.,

draw edge:
This is basically the standard way to draw a line segment given its endpoints (pen up, go to start, pen down, go to end) except that we are given 3D coordinates for the endpoints and have to convert them to a 2D projection.

3D to 2D:
I don't know, this isn't in your documentation and I can't find it in your code either! It happens by magic in between ROTATEXYZ and DRAW??

Well, S1ML actually has a retro-looking code editor, kind of like Powershell (Or DOS if you think Powershell is disgusting).

For W@11, there's no code editor. I'm confused as to how you code or anything.

i mean as its made in Snap! and has some similar bts parts

bash, powershell, dos, idc but yeah S!ML has a editor like that. the output is a different story though. no mean to hijack the thread but could you possibly give me some ideas for S!ML as in more tags?

Sorry, but I've never used S1ML before.

alright:/ well you can try it or look at the tag list and tell me if something is needed or could be added if you want

The > Function takes an input after itself so it would be > 2.
Also (and I think I'm going to change this because it's really unintuitive) the > doesn't prevent the moving at the end of the cycle so it would move a third time and wrap around to the beginning.

True. I'll have to bugfix that (maybe it's because I saved in the middle of implementing a feature)

I've been doing it in Google Docs, but I see how I could quite easily make it a thing in the Snap! project so I will. (TileW@!! IDE?)

New update 0.2.1

• Bug Fixes (all example programs should run)
• New ~ Operation: Give coordinates as two parenthesized numbers e.g. (1)(2) to have it report value of that tile
• New 'make' Command: Sets this tile's value to the input.

Reminder to always use quotation marks ("") unless you intend it to be operated on, although most text shouldn't be processed incorrectly.

Working on making a basic IDE, if anyone can contribute a method for having multiple operations within the one command while still controlling the order with parenthesis I would appreciate it.