VID Expression Optimization

Domains GUI
1

I've really dodged looking at any of the GUI dialects and discussions, and the debates on "what's a face, what's a pane, what's a panel"...glancing at it I don't see any there, there. My experience with the implementation of the GOB! left me thoroughly unimpressed and reinforced how likely non-interesting it is. When it comes to UI, need I point out that things like SeaDragon were being demonstrated 17 years ago.

But given that I was going through all the Rebol 3.0 Front Line blog entries, I did stop to look when a post ventured into some philosophy.

The post I stopped to read was VID Expression Optimization. For commentary, I'll reproduce it below, all copyright to Carl.

When VID was created for R2, it was a revolutionary new approach to GUI construction, and we did not yet know what was common and what was not. Now, for R3, I think we know more, and we should use that knowledge.

In R2, VID faces were described mainly with a style name, followed by a sequence of datatypes. For example, you could write:

button "Here" "There" red green 100x32 [browse home]

So, we placed a high value on expressing modifications in a minimal way. This made VID powerful for expression a great number of variations of styles easily, but we should ask, is that the most common usage?

Well, it's great for demos, but beyond that, most applications do not use that many variations of style, and when they do, they normally define them in a style-sheet for easier management, not within the description of a panel.

This is the CSS concept, where variations are provided via property names. I like this approach because it makes the GUI more readable to those who are not experts. You can see more than the value, you get to know what the value relates to.

For example it is clear to write variations of properties in this way:

width: 20%
area-color: blue
text-color: white
edge-color: silver

So, indeed, that looks a lot like CSS (or should I say that CSS looks a lot like REBOL, interestingly enough), although not totally identical, it is close enough that HTML-aware users will not fear it.

In other words, we do not need to allow ten or more variations of face (style) properties via direct, unnamed datatypes. Instead, let's allow just a few of the main ones, and put the test into a property sheet format with named fields.

I mention this because as we move to the finalization of VID for the standard built-in GUI method, we want to evaluate the usage patterns and apply RISC concepts to make them optimal for users.

We can now re-examine and optimize the top level grammar of VID. I think we can say that, in order of importance, we have:

  1. style (the name, e.g. BUTTON, PANEL)

  2. contents (e.g. button text, panel block)

  3. name (the set-word label for it)

  4. action (what to do on events)

  5. variations (of the style)

Let's take an example:

user-name: field "default name"

Now, if for some reason you need that field to look different, such as use white text on black box area, you would first want to ask yourself if that should be defined as a new style in the style sheet. But, if not, you could write:

user-name: field "default name" with [
    area-color: black
    text-color: white
]

This specification is simple and clear. Yes, it is a bit more wordy than VID in R2, but I think it is a better approach.

Some of you may be asking, is the word WITH really necessary? To that I would reply in RISCish way: "what is more common?" Is style variation the most common... probably not.

Something like this is will be much more common:

panel [
    button "Yes"
    button "No"
]

It's quite common, so it seems to me it makes a better choice for the use of a block.

Finally, I want to mention that this subject can go on and on, and everyone will have their opinions. But, let's set opinions aside, because we must think in terms of usage, not in terms of REBOL dialecting capability, which we know is quite unbounded.

Copyright © Carl Sassenrath 2008

2

Yeah, this is kind of what I mean when I say it's always seemed like gibberish. I'm guessing the "Here" is what the button says when you're not hovering it, and "There" is when you are? (Though that sounds backwards).

Couldn't at least the foreground and background colors be done with a PATH!, like red/green, and if you wanted to set just the background color you could do /green?

I dunno. @rgchris's StyleTalk makes a lot more sense.

My first impulse here was "wow, this looks like it would be an interesting job for FENCE!". Having another part of speech as an array type, to take on meaning in your dialect in that position:

user-name: field "default name" {
    area-color: black
    text-color: white
}

Even looks like CSS, eh?

(I do not see there being any wisdom in picking alternate terminology from CSS for when you're drilling down to the implementation properties. Very diminishing returns.)

I think those are the main things I have to say at the moment. When I get the inkling to look a little more into this I'll add to this thread.

Although seeing this WITH pattern reminds me of something...

Trailing Words To Add "Refinements" In Ordinary EVAL

I've been tempted sometimes by the idea of variadic lookahead to implement syntaxes even in non-dialected code, where you could tack words on the end of something to be more competitive with other languages. e.g. with IMPORT being able to say FROM.

JavaScript:

import "module-name";
import { export1 as alias1 } from "module-name";

Should we be not able to do that because it's not in a block?

import "module-name"
import ["module-name"]
import [[export1 as alias1] from "module-name"]

import/partial "module-name" [export1 as alias1]

But to play devil's advocate for a moment, would it really kill the language to be able to look nice?

import "module-name"
import [export1 as alias1] from "module-name"

There was a backlash to ELSE that worked by literal looking ahead for the word "ELSE" (and Ren-C's ELSE certainly does not do that).

I do think literal lookahead for specific words is inelegant to allow in the main evaluator. It puts keywords into a part of the substrate that brags on being able to override and rename essentially anything: you can alias my-import: :import but you can't do my-from: :from. Having your hands cuffed on renaming is supposed to only happen once you've crossed the (Rebol -> Dialect) barrier.

Ren-C allows you to do it with variadics if you really want to, and I'm not sure if we have complete experience to say that it's bad in all instances. :man_shrugging: