I'm currently writing a lisp-like programming language for manipulating and performing calculations based on JSON. It looks like pic related.
When the interpreter stops running it'll print out the final state of input JSON.
What would you guys want from such a language? What are some typical algorithms you guys use with JSON data?
Pic related is what it currently looks like.
Handling graphs (and other data structures that don't map metaphorically or idiomatically with the list structure) without autism
A complete and total refusal to run on any UNIX weenie platform.
Running unix is like believing in g*d: you're an unintelligent weenie who doesn't know what you're doing but you still gotta tell all the smart people how to live their lives via the one true way. Replace g*d and the church with AT&T and it makes complete sense.At least Jesus freax don't blow off Dennie DRitchie every time they read their fairy tales.My students never shut up about Ceesus'sholy book.
That's way out of scope for me, the idea here is that you'd still be working with regular JSON datastructures.
I believe in God so making it refuse to run on non-Unix systems is clearly the logical conclusion here.
Any docs, beyond there two lines? Because only thing I can say from them is that it's fucking ugly.
Jesus fucking christ. You market is as JSON manipulation - USE JSON LITERALS
No need for them. If it starts with '/' - it's a get. Assignment has special syntax.
Or why not json instead of syntax - ugly, but save on parser?
You know Scheme? Do that.
I've only been writing this for 4 days, of course there aren't any docs.
It's designed to be pretty easy to reimplement, so that it can be put into things like JSON schemas and interpreted by any point in a given system or be used as part of a script etc.
Inconsistencies complicate things. I don't like them.
JSON makes absolutely no sense for a programming language.
That's one really ugly language. I'm not even sure what that snippet does.
Also how is this even LISP like?
OK, who left the door to the oven open?
It's basically just spaghetticode that does some random calculations and sticks them in the resulting JSON.
It's Lisp-like in that like Lisp uses s-expressions this language uses indentifier(args...)
If you want it to be a lisp like why not use a syntax like.myFunction [a, b, c] = { calculations: { allitems: join [0, 1, 3] a b , other: sum [c, a, 8] }}Alternatively you could also declare the function with myFunction {a, b, c} = ... for if you wanted the input to be an object instead of array.
...
Actually the argument to join should be an array. So here's v3.myFunction [a, b, c] = { calculations: { allitems: join [[0, 1, 3] a b] , other: sum [c, a, 8] } }
v4 I wish I could delete postsmyFunction [a, b, c] = { calculations: { allitems: join [[0, 1, 3], a, b] , other: sum [c, a, 8] } }
You have to open the oven to stuff things inside.
The unix weenie is immunized against all dangers: onemay call him a virgin, neckbeard, freetard, nogames, itall runs off him like water off a raincoat. But call him aweenie and you will be astonished at how he recoils,how injured he is, how he suddenly shrinks back: “I’vebeen found out.”
This is a programming language I implemented a while ago. This program gets a list of numbers from standard input, adds them together, and prints them out. It's a bit like brainfuck + Tcl.] n] 1]>: [? [> [=> n] [=> nn]] c a] l]] [=> l]]]>: [? [== [=> l] [- [=> n] 1]] f l]
Because quite frankly alot of those characters are just redundant.
Then why did you want to make a LISP that used JSON objects instead of lists?
Why would you use JSON for this?
Give it back jml
if you are good at criticism but end up yourself at LISP you have failed
So it could be reimplemented easily.
The JSON came first, at work we have a form system based on JSON Schemas which we've modified to implement live calculations, our current solution is basically just running eval() with some custom functions but that's sub-par since the contents of eval() isn't run through babel, it can't be tested very well and as a result people can easily fuck it up.
The idea behind this language is to solve those problems so the next time I want to make something with JSON schema it's not as hacky, gross and prone to breaking.
SAGE
...
Didn't have time to write a parser. eval() did the job well enough and was considerably better than hardcoding it.
FFFFFLLLLLOOOOOWWWWWEEEEENNNNNSSSSS