Below is a list of questions that are commonly asked by people who are new to Particles, Parsers and Scroll. If you have a question not listed here please ask us on Twitter or by posting a message to the World Wide Scroll Subreddit.
Particles was originally called Scroll Notation and before that Tree Notation.
Particles is a simple syntax that Scroll is built on top of.
For programmers, this might give you an idea of the structure behind Particles:
particleBreakSymbol = "\n" // New lines separate particles
edgeSymbol = " " // Increasing indent to denote parent/child relationship
interface Particle {
subparticle: Particle[]
atoms: string[]
}
Code or information represented in parsers therefore always has a similar appearance - it is indented to show structure, rather than (necessarily) using the symbols you might see in traditional programming languages such as C++ and Java - and languages intended for data storage and communication, such as XML and JSON.
This simple, yet powerful, base structure may looks a little like Python, Visual Basic, YAML - or 'Domain Specific Languages' written 'on top' of existing programming languages. This isn’t by accident: such languages were designed to look similar to natural language, using words over symbols and indentation to denote structure.
Here’s an example of a minimal HTML document represented in parsers:
html
body
div おはようございます
One important feature of Particles is that due to its simplicity and consistency, parsers are easy to write - and code or information represented in parsers is easy to syntax check (and highlight) - and autocomplete.
(Thank you to @vakradrz for this answer)
There is only 1 binary. Particles is more like binary than it is like a programming language. Particles is a basic building block that you can build higher level languages on top of. Particles is an error-free base syntax like binary.
This is our current stack of computer languages:
1 Binary => 1,000+ Syntaxes => 10,000+ languages
In the future we think the stack may look like this:
1 Binary => 1 Particles => 10,000+ Scroll microlangs
We all use software tools to build software. Particles makes building these tools easier, and as more people join the Particles ecosystem there may be significant network effects. If Jane is building parsers and tools for automating train schedules, and John is building parsers and tools for doing cancer research, even though their 2 domains are very different, they can share a lot of the tools and code.
Particles is the base level syntax. Generally users use the higher level Scroll, which is built on Particles and makes Particles useful. Scroll is written in Parsers, which is also built on Particles.
Particles may seem similar to notations like JSON, XML, YAML or S-expressions. However, Particles is the most minimal, has an isomorphism to Euclidean geometry, and the concept of syntax errors does not exist. These differences may make Particles substantially different and may cause a significant improvement in computing.
The data science app Ohayo is in part an experiment to test these 3 advantages of Particles.
Currently all Node.js npm projects contain a package.json file. While this is simple, it could be simpler using Particles, and better. Let's take a look.
{
"name": "mypackage"
"version": "2.1.1"
"description": "A package",
"repository": {
"type": "git",
"url": "git://github.com/username/mypackage"
}
}name mypackage
version 2.1.1
description A package
repository
type git
url git://github.com/username/mypackageIt may look like the only benefit is fewer syntax characters, but there's actually more we can now do. Our package.scroll file would have Parsers to get typechecking, autocomplete, tailored syntax highlighting, support for multiline strings, strings without quotes that don't require escaping, comments, and more.
Note: the JSON example above works correctly, but JSON and Particles are not equivalent by default, since JSON does not support certain structures and Particles does not implement all JSON types by default. If you want JSON features such as keys with spaces, numbers, or arrays, you'll need to use Parsers such as Dug that has a 1-to-1 relationship to JSON.
In the example below, Particles is used as a base for a math Scroll Dialect where traditionally S-Expressions/Lisp might be used.
multiply
add 1 1
add 2 2(* (+ 1 1) (+ 2 2))The second example contains 13 parts, whereas the first only has 7. There are also infinite ways to represent the second example, since the compiler ignores insignificant whitespace, whereas in the first there is only 1 way to represent that particular structure.
Check out the Ohayo project or the Parsers Designer.
A good place to start is with our simple Parsers Designer.
Everywhere! Anywhere you use programming languages or encodings, you can use Particles. Hopefully a Particles Ecosystem will grow, if Particles turns out to be a good idea. Until then use it wherever and don't be shy about asking for help.
This is the base Particles:
particleBreakSymbol = "\n" // New lines separate particles
edgeSymbol = " " // Increasing indent to denote subparticles
interface Particle {
parent: &Particle
subparticles: Particle[]
atoms: string[]
}
This tree-like Node called Particle is the data structure in Particles. Types like booleans, ints and vectors only exist at the higher level once Parsers is added.
Parsers and Scroll (which is written in Parsers) is where additional concepts can be added like strings, integers, booleans, control flow, assignment, encapsulation, functions, and so forth.
Example:
if true
print Hello world
In Particles, the units of measure are atoms and particles. Each line is equal to one particle. The example program above has 5 atoms and 2 particles. In this language the particleType is determined by the first words (if and print). Notice how the second line in the program above is indented by one space, this makes the print particle a subparticle of the line above it, the if particle.
Parsers add the additional concept of typed atoms, which can be thought of as placeholders and type information for words. Parsers define new languages with particleTypes and atomTypes. In the example language above, the word "true" would be in a boolean atom type.
Here is a longer spec.
Particles uses a single space to indent blocks which indicates parent/child relationship. You can only increase the indent level one level at a time.
Yes. Particles only uses the \n character to separate particles/lines. \r is either ignored or treated as a content character. In practice it's easier to drop all \r :).
Particles supports all encodings. This is perfectly valid Particles:
html
body
div おはようございます
In fact, there is no such thing as an invalid Particles document at the base level, just as there is no such thing as an "invalid binary sequence".
Usually when using Particles you use a higher level grammar, implemented with Parsers, and so you can still have invalid programs in that language (because of typos, for example) even though your Particles is valid.
In Particles you never need to escape characters. If your particle spans across multiple lines, simply indent the child lines by one space more than their parent, leave the rest of the line as is, and ensure your particleType definition treats child particles as one block. Some parsers might have the notion of escape characters in certain places, but there's no such thing at the Particles base layer.
No. A subset of Particles does, but for perfect one-to-one matching you'll want to use parsers specifically designed for that language.
Yes! The ScrollSDK provides Particles support for TypeScript and Javascript, but someday there may be Particles and Parser implementations in all programming languages, similar to how most languages nowadays have JSON libraries.
If you want to build a Particles library for your language, the swim tests are intended to help!
Particles is free, open source, and public domain. The Particles Lab is a distributed research group started in Hawaii that works on the core Particles infrastructure projects. The plan is to build the infrastructure needed to test whether Particles is a good idea. If it is, get a broader Particles ecosystem growing.
Yes! Particles is ready for early adopters. If you use Particles today, you probably will want to stay up to date with what's happening as the tooling is still rapidly evolving.
If you'd prefer to wait until most of the details are settled, late 2024 is probably a better time to start using it.
Thank you for asking! There's plenty of work to be done. Particularly important needs now are someone with project management skills to help organize and lead the team, someone to do community organizing/evangelism, dev leads to make libraries in various languages, testers to do cross platform testing, and more. Get in touch if you want to help.
Look for a "Paste and indent" command. For example, in Sublime Text you can click Edit->Paste and Indent, or press Cmd+Shift+v.
No. We strongly recommend using an editor that supports Particles with syntax highlighting, indentation help and more (if we don't have support for your favorite editor yet, please help us add it!). If you are finding it difficult to use Particles, that's just because the editor support is in the early stages. Please let us know what problems you are having so we can get them fixed.
By creating 1 file in parsers, you get a new programming language with autocomplete, syntax highlighting, type-checking, help, integration tests, compiling, and more. The goal of Parsers is to help you create a new, robust, well tested language as easily as possible.
Yes! As of ScrollSDK 35, Parsers supports other notations. Originally only prefix notation was supported without writing a decent amount of target code.
Yes! While not supported at the base Particles level, your individual particles can certainly have inline trees. Often your parsers will have particles that contain content written in traditional languages like Javascript, Lisp, or Python. Or you could even have inline trees written in Particles, except using something like the pipe character as particleBreakSymbol instead of the newline character.
It is largely accurate to say Particles is S-Expressions without parenthesis. But this makes them very different! Particles gives you fewer chances to make errors, easier program concatenation and ad hoc parser writing, easier program synthesis, easier visual programming, easier code analysis, and more.
No. It is largely accurate to say Particles is S-Expressions without parenthesis. However, Particles has a useful geometric isomorphism that S-Expressions/Lisp lack, that might have significant network effects.
If you have parsers with a root particleType named folder, and you want to rename the keyword of that particleType to project, you can easily do it with an ad-hoc regex: s/^folder/project/. This would be type safe, even if you started parsing in the middle of the document. You cannot do that with S-Expressions, as you'd have to first parse the document into a Tree data structure, and could not operate on it as a string.
Easy program concatenation. For example, in Particles you can create valid new programs simply by appending strings, whereas in Lisp you might first have to do some parentheses removing and inserting.
In Lisp you have to escape certain characters. In Particles, you never need to escape characters. (Note: although you are 100% free to design parsers that implement escape characters, that is almost never necessary).
You can read the half-baked papers about Particles.
The basic gist of the theory is that all structures are trees, Particles is all you need to represent trees, and by building things up from Particles we might be able to make things simpler AND better.
Syntactically there's no question--it was HAML. See the origin story below if you are curious why. Semantically there's been a lot of influences from thousands of languages. Particularly influential ones are Lisp, Haskell, Racket, ANTLR, TypeScript, C#, Python, Scheme, Javascript, COBOL, Rebol, Mathematica, APL, R, Red-Lang, Fortran, Forth, C++, JSON, XML, HTML, CSS, SQL, somewhat, but not necessarily, in that order.
Breck Yunits et al. came up with Particles circa 2012. However, it turns out in 2003 Egil Möller proposed "I-Expressions", or "Indentation-sensitive syntax", an alternative to S-Expressions in Scheme that is 80% similar to Particles. A few implementation details weren't ideal, but the core is largely the same.
Not sure. Perhaps because it was pitched as a different way to write Lisp, and that was it. With Particles, coming up with an improved way to write Lisp was never a primary goal. Our primary goals have been to enable visual programming, simpler APIs, cleaner code and program synthesis, for which Particles is an ideal tool.
If Particles turns out to be a good idea, below is the origin story.
The year was 2012. Barack Hussein Obama was president, Prettier hadn't been released yet, and humans talked to other humans more than Alexa. Our startup NudgePad was building a visual web page editor in our office in San Francisco, which was located in the backroom of a warehouse that built wooden pianos by hand. In comparison to Nudge Inc., the wooden piano business was _booming_. With NudgePad, users could drag, drop and edit their web pages without touching any code. It worked awesome, at least 1 percent of the time. As the user was editing their pages visually, we coded NudgePad to read and write the language HAML, which I had learned at my previous job. I ended up needing to write my own HAML parser and code generator for reasons long since forgotten. Because we were a broke startup, I kept trying to cut syntax from the language to save time and money. Every now and then I would remove some syntax character from our HAML clone and still somehow get everything in NudgePad to work. Eventually the language was just spaces, newlines, and colons. And then there was an "aha!" moment. I remember I was walking to work, going over the code in my head, and had just reached the 101 overpass when I realized I could dump the colons! I went straight to my desk, opened up my editor, and a couple hours later had removed the colons and everything still worked. I remember at the time thinking that was potentially a profound idea but I _was positive_ someone had built it already. I thought there was no chance it hadn't been invented yet because it was so simple. But for years I'd ping folks in industry, post on message boards, and do a lot of Google searches. It took me years of searching for it before I thought maybe no had noticed and leveraged this idea before. 5 years later I had another "aha" moment when I realized it would also be a good base notation for _any_ type of computer language, and wrote a paper about it. Which went on to be cited over (editor's note: it says "zero" here, is that correct?) times.
Thank you for reminding us the web was not built in a day!
If you round up, 10%. But in the 90% chance that this is not a good idea, attempting to prove that it is a good or a bad idea seems to be a promising line of research.
Rule #1. Put it in a parser.
End of Rules.