PSON examples (possible)

Here some examples of notation.

BTW, why am I posting here instead of on wiki?  Mainly because it is quicker to post here than on my wiki.  Mediawiki is slow. Too many clicks.  In twiki I had comment mode. (TBD: install twiki on my webhost. Want ACLs.)

Anyway, examoples - of the PSON possible "copmpact" notation, andf then the correspondingly fully parehthesized version (although I may not use quotes, etc., everywhere):

a: b c d
a: [b,c,d]


a:b c d
a:[b,c,d]


a: b, c, d
a:[b,c,d]

a: b, c, d;
a:[b,c,d]

a: b c d, e f
[a:[b,c,d],e,f]
or
a:[[b,c,d],[e,f]]
?

a:b c:d e:f
{a:b,c:d,e:f}

a: b c:d
{a:b,c:d}


a: b c: d
{a:b,c:d}


a: b=c d=e f=g
a:{b=c,d=e,f=g}


a: b=c d e f=g
a:[b=c,d,e,f=g]
??

a:[b=c,0:d,1:e,f=g]
??

a: b=c d e f=g h:i
??


a: b c d
a: [b,c,d]



a b:c d
[a,b:c,d]
??
[0:1,b:c,1:d]
??

It seems a bit weird to have
a: b c d => a: [b,c,d]

but


x a: b c d => [x a:b,c,d]

??
Is this really what I want?

It seems to mean that label: at the beginning of a string means something different than in the middle.

a,b,c: d e,f
[a,b,c:[d e],f]


a,b, x c:d e,f
[a,b,[x,c:d,e],f]

a,b,c:d e,f
[a,b,c:[d e],f]


a,b,c:d,e,f
[a,b,c:d,e,f]

Mixing array and name syntax

So, straight array syntax and straight name=value is handled in many ways

Array: [ a, b, c, d ]
Struct: { k1=v1, k2=v2 }

Or , paren-less (or implicit parens):
Array:  a, b, c, d
Struct:  k1=v1, k2=v2

Q: but what about intermixing - having a key-value appear in the middle of a list of values:

a, b, c, d=e, f, g, h

Should this be interpreted as a struct in an array, or what?

(Again, emphasizing: this is just for convenience. Explicit parens always available.)


(1) implicit struct element

[ a, b, c, {d=e}, f, g, h]

(2)  explicit in same array/struct, inside/in addition to sequence

A different way of looking at it might be to say "All array notation is really just implict name=value pairs":

I.e.

Array: [ a, b, c, d ]

is equivalent to

Array: { 0:a, 1:b, 2:c, 3:d }

This would suggest that

[ a, b, c, d=e, f, g, h]

should be

{ 1:a, 2:b, 3:c, d:e, 4:e, 5:f, 6:g, 7:h }

although even that is not so explicit as one might like: we may want to emphasize that elements "named" d and 4 actually point to the same value, not to different elements that happen to have equal values.

(3) explicit in same array, but outside of sequence

Rather than creating an aklis to the positional notation, put iot oustide positional:

[ a, b, c, d=e, f, g, h]

should be

{ 1:a, 2:b, 3:c, d:e, 4:f, 5:g, 6:h }

This seems to be what I have wanted to do most often with keyword arguments for functions:

add( 1, 2) 

add(1,2,modulo=16) 

add(modulo=16,1,2)

we want to refer to the positional "1" and "2" using the same names, irrespective of where the keyword parameter is written.




BOTTOM LINE:  I think I prefer (3) explicit in same array, but outside of sequence

 

 

Relaxation

Talking with someone about GNU make passes - first evaluating the dependency graph, and then building it..

.SECONDEXPANSION http://www.gnu.org/software/make/manual/make.html#Secondary-Expansion - a kluge, IMHO.  Although it may be good enough.

One of my friends got annoyed enough by passes that he wrote his own build tool. (Hi, Mark!)

Suggested relaxation - basically, keep passing over, until changes stop happening.

Observation: in a language like Perl or Make, with sigils like $var, each pass might strip a sigil.  1st pass $VAR, second $$VAR, third $$$$VAR, etc.  Ugly!  I hate counting backquotes.

Languages that use unadorned variable names look prettier.

But are they any more or less likely to have infinite relaxation cycles?  Probably no more.

--

How does this relate to my desire to set a bit in text to say "Never parse this?"  Not much.  Or, rather, that may be the key to reducing user errors with relaxation. Set the bit, and never substitute no more.

--

Hey, maybe this is the key: there are two types of text, syntactic text - into which substitutions may be done - and non-syntactic, terminal, finalized text.

If you arrive at terminal text you are done, done, done.

Syntactic text may continue, or may stop relaxing when there are no more changes.

Most languages make terminal text harder to express - quoted string.

I've worked with languages that make syntactic text harder and uglier - e.g. Algol W with 'IF' 'ELSE' quoted keywords.

Key is notations that allow us to go from easy syntactic / ugly terminal text, through ugly syntactic / unquoted, easy, terminal text.  Points in the middle...

Google calendar scrollbar oscillation

For the past week have been plagued by oscillation of the scrollbars in Google calendar.

In Chrome.  Typically when fullscreen on my 1200x1920 monitor.

Scrollbars on, scroll bars off.

Changing window size remedies.

Just goes to show that Google can have annoying bugs, just like anyone else.

VNC client evaporation

Today have been plagued by my VNC client "evaporating".

Probably because my VNC window is pretty large, 1200 high by circa 6000 wide, to span all of my displays.

Nested structure without parentheses

In my thoughts about PSON (Pseudo Object Notation), descended from Pseudo-XML and earlier Perl-SQL notation:

Stipulate the usual: nice parens and quotes.  I'm just looking to strip out visual clutter ad create a more human readable subset - e.g. so that muy debug lines can be parseable.

Earlier I blogged about letting = be a tighter binding strength than :. so that

s: a=1, b=2, t: 7

becomes

s: { a=1, b=2 }, t: 7

 There's no need for binding strength.  Can just have any name = or name : without an atom\

s= a=1 b:2, t=7

yielding

s= {a=1 b:2}, t=7

---

Delineating the end of the struct is an issue. Hinted at above by s= a=1 b:2, t=7

We can use whitespace separated elements, comma-separated, semi-colon separated, period separated as a hierarchy of nesting:

         a b, c, d, e; f g h, i j k

         (((a b), c, d, e); ((f g h), (i j k)))

Not general, because only three levels.  But human friendly, similar to what I do naturally in real life.

Q: intermixing : and = binding, and the blank/comma/semicolon separated lists?  Who binds first?

<angle brackets in titles confuses blogger>

If you put angle brackets in the title of a blogger post, like this:

<angle brackets in titles confuses blogger>

blogger gets confused and decides that it is an untitled post - whereas if there is truly bno title, blogger guesses from the first line.

Not clear that this is a bug, but certainly a feature of questionable merit.

Yet another quotification issue.