/tech/ - Technology★

>>1009197 (OP)

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 D
Ritchie every time they read their fairy tales.
My students never shut up about Ceesus's
holy book.

>>1009216

That's way out of scope for me, the idea here is that you'd still be working with regular JSON datastructures.

>>1009222

I believe in God so making it refuse to run on non-Unix systems is clearly the logical conclusion here.

You know Scheme? Do that.

>>1009229

>Any docs, beyond there two lines?

I've only been writing this for 4 days, of course there aren't any docs.

>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

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.

>No need for them. If it starts with '/' - it's a get. Assignment has special syntax.

Inconsistencies complicate things. I don't like them.

>Or why not json instead of syntax - ugly, but save on parser?

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?

>>1009222

> g*d

OK, who left the door to the oven open?

>>1009265

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...)

>>1009279

>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]
  }
}

myFunction {a, b, c} = ...

>>1009294

<Tor users can't delete posts

Meant this for the first code block.

myFunction [a, b, c] =
  { calculations:
    { allitems: join [0, 1, 3] a b
    , other: sum [c, a, 8]
    }
  }

>>1009297

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]
    }
  }

>>1009300

v4 I wish I could delete posts

myFunction [a, b, c] =
  { calculations:
    { allitems: join [[0, 1, 3], a, b]
    , other:    sum [c, a, 8]
    }
  }

>>1009270

You have to open the oven to stuff things inside.

The unix weenie is immunized against all dangers: one
may call him a virgin, neckbeard, freetard, nogames, it
all runs off him like water off a raincoat. But call him a
weenie and you will be astonished at how he recoils,
how injured he is, how he suddenly shrinks back: “I’ve
been 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.

<: a
<- "Enter number #" [=> n] ": "
<= [=> n] [->]
<= n [+ [=> n] 1]
>: [? [> [=> n] [=> nn]] c a]

<: c
<= r [=> [=> l]]
<: l
<= l [+ [=> l] 1]
<= r [+ [=> r] [=> [=> l]]]
>: [? [== [=> l] [- [=> n] 1]] f l]

<: f
<- "The result is " [=> r] "\n"

<:

>>1009294

Because quite frankly alot of those characters are just redundant.

>>1009387

Then why did you want to make a LISP that used JSON objects instead of lists?

Why would you use JSON for this?

if you are good at criticism but end up yourself at LISP you have failed

>>1009405

So it could be reimplemented easily.

>>1009414

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.

>>1009225

>>1009268

>no argument

SAGE

>>1009522

<eval

Couldn't figure out how to parse it into an ADT and evaluate it?

>>1009528

Didn't have time to write a parser. eval() did the job well enough and was considerably better than hardcoding it.