Alternative syntax for Stamp

Sarcasm commented 3 years ago

Right now the stamp language provides this syntax:

folder myProject
file myProject/index.js
 data
  console.log("Hello world")
file myProject/readme.md
 data
  # My Readme

I'm wondering if it could not be simplified like this:

myProject/
 index.js
  console.log("Hello world")
 readme.md
  # My Readme

Directories can discriminated from files thanks to the final /. Children of directories are files. Children of files, is file content.

Would that still qualify as a treenotation language?

breck7 commented 3 years ago

Love it! How would you do file permissions?

Also, you could come up with your own name. Building a tree language is cheap so could build a whole new one.

Happy to team up on a Twitch call and pair program one out.

breck7 commented 3 years ago

I guess you could add the restriction to not allow spaces in filenames, then just do index.js Writeable or something. Lots of options

Sarcasm commented 3 years ago

For permission yes, I think it could be specified after the filename. Maybe a bad idea, but could be in a chmod-like format:

foo.py +x
 #!/usr/bin/env python
 print("hello world")

breck7 commented 3 years ago

Here's a quick prototype. I just started it but gotta run to a conference

Sarcasm commented 3 years ago

Maybe the presence of a shebang is enough to warrant the execution bit. And like now, other permissions could be omitted.

breck7 commented 3 years ago

You know what I only use that execution bit once in a blue moon. This Stamp alternative could be dead simple (expands to plain vanilla non-executable files) without file permissions.

Just playing with the demo in the Designer I like yours better than mine.

It reminds me of a better https://www.gnu.org/software/emacs/manual/html_node/emacs/Dired.html

breck7 commented 3 years ago

Would you be interested in making your own repo and running with that idea?

I could contribute over there. I'd love to hear how much the experience currently sucks of building one's own Tree Language (my guess is very bad).

I think it would be worthwhile and would be a user myself.

Sarcasm commented 3 years ago

I attempted something (link at the end). Not sure I will push it further but I was happy to give it a try.

Regarding my experience.

Some nice things:

The IDE:
- Completion in the text editor, although this tree language does not benefit from it, the grammar did.
- "Explain" was very useful when writing the grammar.
The various examples, in the IDE and on Github were useful to understand how to make a grammar.
When thinking about Domain-specific language (DSL), I like to give a tree notation representation a try, I like its terseness.

Less nice things:

The IDE:
- Would be nice to have a bigger text editor in the IDE.
- I understand "Execute" and "Explain", but not "Compile". A Tool Tip for these actions could be helpful.
- The auto-generated Readme has a lot of wasted space, multiple lines between a section title and its content.
- Typing multiple f in the text editor produce something weird, the fs get smaller / closer to each others (font ligature?).
- The errors, grammar and language could be better integrated. Right now, grammar errors are in the same pane as the auto-generated Readme, it's a bit confusing. In my browser (Firefox), the inline errors do not appear immediately, unlike the error lists ("Grammar/Language Errors"). I have to type a whitespace to see the inline error. But if I move the cursor with the mouse I do not see it.
Some examples weren't up-to-date / complete. For example the Chuck example does not execute, I did not realized initially that it was a todo. Maybe "Execute" could be greyed out in this case or an message indicate that execute() isn't implemented.
Finishing the grammar with a newline is an error. Maybe newlines should not be the separator, but instead something like an imaginary 'startOfLine' character. Right now newlines (nodeBreakSymbol) 'separate' nodes, but maybe there should be the possibility to set other modes so that it 'start' a new node.

breck7 commented 3 years ago

@Sarcasm finally got back to this. This is awesome!

I find it way better than Stamp. Feels natural. I made a few tiny changes to your code above (just changed execute methods to compile for consistency. The other reductions in code were just to temporarily make the link shorter). Named it "Clay". Playing around with it made me think of shaping a full project fluidly.

I want to go through your feedback and address the individual points, but just wanted to say this is awesome. Better than Stamp and really as simple as possible. Kudos.

Sarcasm commented 3 years ago

Hello,

I just try the Clay example, and it looks like there is an issue with the package.json generated content:

breck7 commented 3 years ago

You are right. This should work:

breck7 commented 3 years ago

Two reasons for this:

1) The core TreeNode methods are not great. Some methods I often make mistakes with, such as getLines. I think some subpar methods could removed, some can be better named, and some more helpful core methods could be added. Perhaps there should be fewer public methods, but the ones remaining should be fantastic and foolproof. Or maybe there's a missing pattern(s) that would make core easier to use. Not sure. All I know is that I wish the core API was better!

2) In this specific example, I changed the compilation of the parent file block to use childrenToString instead of getLines. Given a Tree like:

a
 b
  c
  d

Then "childrenToString" of "a" returns simply the text block:

b
 c
 d

I find this to be a very common pattern when embedding non-tree languages in a tree language and use it often. Using methods designed for tree languages inside "blob", non-tree language blocks can be tricky, and generally just dumping those blobs is what you want, in which case "childrenToString" works great. This situation should probably be well documented in future Grammar docs. The code currently parses non-Tree language blobs like this just like any other Tree Node, and I think there are some theoretical issues that could be resolved there. It's definitely one of the places that needs some good FAQs, as I was just having a long conversation with another dev on this very topic.

breck7 commented 3 years ago

Just for clarity, a diff of the fix:

Sarcasm commented 3 years ago

The fix makes sense, childrenToString() looks more natural/correct than iterating over the lines, thank you.

breck7 commented 1 month ago

I finally got around to this!

https://scroll.pub/blog/stamp.html

breck7 / scrollsdk

Alternative syntax for Stamp #120