JSON parser anyone?

[marielle]

Anyone having written a JSON parser/writer?

JSON is a standard for representing data in a structured way. He achieves much of the same as XML (at least when you stick to the most current use of XML) but has the advantage to adopt a syntax that is a lot more compact. Because you don't have a starting and end tag, less file space is required to store the same data.

Another advantage is that it is more directly compatible with javascript object representation than XML.

[FourthWorld]

I haven't played with JSON, but I've written a number of 5GL "construction languages" for Rev over the years. Most of these have been specific to client projects, where they can write things like:

section
title: Lesson 1
heading: This lesson provides an overview of the tutorial.
body: This is the text that goes in the body.
It can contain multiple lines, so it relies on a stop at the end of its definition./body

This gets run through an interpreter which then pulls parts from a collection of templates to build things rapidly.

Like JSON, the goal of these 5GLs has been to arrive at a very compact syntax, and also one that more closely matches the client's mental model of their work.

Using prefab templates makes it a breeze to describe things in appliction-specific terms, allowing the processor to make assumptions. In the example above, the client has a template called a "section", which always has at least a field named "Title", a field named "Heading", and one named "Body". In Transcript, "header" isn't a token, but in this client's world it's a very specific part of his layout, allowing a parser to use that token with the assumption that he's referring to a specific field. A few hours' work writing a processor for that allowed him to build his own tutorials without needing to hire me again.

I used a similar system when I made the original Rev tutorials for v1.0. I wanted to write the tutorials in a text editor so I could focus on the conceptual flow of the material without getting caught up in layout tasks, and use a template shell to ensure consistency among the final stacks. I made a few simple tags to put into the text and wrote a processor that parsed things according to those tags and built out a copy of a template shell to make the actual deliverables. Any time I needed to change the layout, with the 5GL I was always just one click away from a fresh build for the whole series.

A couple years ago I experimented with a more generalized flavor of this sort of 5GL I called "cc" (which could stand for "construction convenience", or "component copier", or "clownish concepts", as one prefers <g>), which would allow dynamic declaration of unique human-centric object "types" from any variety of templates, in addition to providing simple syntax for common objects. The idea was that once the library is active you could type "cc <ccCode>" in the Message Box, where <ccCode> is any cc instructions or a file containing cc or a field containing cc, and it would build the objects according to the specifications there.

To minimize the need for mentally doing the layout when writing cc, it included a "layoutPointer", a default location for each object based on the position of the prior object according to certain rules which govern many common GUI layouts. For example, buttons would be laid out side by side until it hits the edge of the card, then it would start a new row, while fields would extend the width of the card and be positioned vertically to one another. And of course one could move the layoutPointer to any location to start a new sequence, or ignore it altogether by including a rect in the object's definition.

It was a fun exercise, but ultimately abandoned because I couldn't find enough practical applications for it to make it worth the non-trivial effort of completing. In a fraction of the time it would have taken to finish cc I could just copy objects from my library manually. And while a small handful of UIs might be able to use an automated layout, in practice I find it's necessary to specify rects for things, and that's much easier to do visually using existing IDE tools.

But for specialized uses I still write 5GLs in Rev for clients to extend their work, at least for apps that re-use layouts like CBTs and such. Once a layout and its behaviors are hand-crafted and debugged, it's a snap to make tools to let the client create new variations of those.

[marielle]

But for specialized uses I still write 5GLs in Rev for clients to extend their work, at least for apps that re-use layouts like CBTs and such. Once a layout and its behaviors are hand-crafted and debugged, it's a snap to make tools to let the client create new variations of those.

That sounds excellent . By chance do you have any concrete example that you can afford to make public like for instance the code you use for your Rev tutorials for v1.0

[FourthWorld]

If I can dig up my old Rev tutorials I can post that one. That's a few computers back, though, so I can't say when I'll be able to dig that deep....

[marielle]

For those puzzled about this 5GL term. This means Fifth generation computer language.

This refers to an evolution over the years from very low level to higher levels computer languages. 2GL = very low level languages like Assembly rather close to machine level, 3GL a language designed to be easier for a human to understand thanks to the notion of named variable (friend_name = "henry"). 4GL are characterized by even higher abstraction and statement power. TCL or xtalk/transcript can be see as 4GL. The trade-off is that they become more domain specific (they are very good at doing some things but not necessarily able to do everything).

Well, simply read Richard's excellent article Beyond the Browser or Osterhout's paper Scripting: Higher Level Programming for the 21st Century for more info on this [Richard, the link on your page to this paper is now broken].

Fifth generation are supposed to be still a higher level of abstraction. The problem then is that persons put different meanings into that. I couldn't find any paper from a trusted source mentioning the term 5GL.

The person who edited the entry on Fifth-generation programming language on wikipedia proposes they are based around solving problems using constraints given to the program, rather than using an algorithm written by a programmer. Well, the languages he cites (Cobol, Lisp) are rather classified using other terms. I checked out a few of the contributors and none of them appear as expert (but, eh, I didn't check all contributors).

But if you run a Google search, the consensus seems to be what Richard proposes. A language that allows you to rapidly generate the source code for another language without having to do all the work or typing that final source code yourself.

Note however that if you are interested in researching this, you may have more luck by typing templating engine into Google

[marielle]

If I can dig up my old Rev tutorials I can post that one. That's a few computers back, though, so I can't say when I'll be able to dig that deep....

That would be nice.