Evolving the Apologue UI

Apologue's UI has changed in various ways over the last year. When it started, it was basically a single screen and only worked on iPad. I later reworked it, breaking things up to make it usable on iPhone. But I'm reaching the limits in the current model.

Earlier this month I began work on a revamped UI. It retains some significant similarities, but the changes should make things more maintainable going forward. It'll also hopefully help improve the workflow on larger screen devices (iPhone 6 Plus and iPad).

On the larger screen devices (in landscape modes) the project list will be displayed. The right pane will display the various views (edit, results, internals, and documentation). On smaller screen devices, the project list will be displayed first, then switch over to the other views once a project is selected.

This is still under development. It'll be a while (likely late May or early June) before this is ready for use, but I think it'll be very helpful going forward.


The UI updates will eventually be brought to Retro as well. This will take longer though. Since Apologue only supports iOS 8 and later it can leverage updates to UIKit that aren't available to Retro (which supports iOS 7 as well). I'll have to consider what to do when iOS 9 is released. Do I need to keep iOS 7 support at that point, or would it make sense to push the minimum version forward to 8?

Values and Variables in Parable, Part 2

Following up on yesterday's posts, I've made the following changes in Parable:

  • values now track and restore the data type
  • added variable! to create a variable with an initial value
  • added value! to create a value with an initial value

So now we can create and initialize both forms with a single line of code:

#100 'foo' variable!

'hello, world!' 'message' value!

It's a minor change, but certainly can be useful in helping to further reduce the need for excess code.

Variables and Values in Parable

Parable has two closely related simple data structures: variables and values. These differ in a couple of minor ways, and both are useful in their own ways.

In both cases, the data consists of a slice with an attached name. The differences come in how you interact with them. Let's consider this. Assuming that we want to hold a simple value and refer to it by name, we could do:

"create a variable named foo"
request 'foo' define

"store 100 into it"
#100 &foo #0 store

"fetch the value stored in foo"
&foo #0 fetch

Variables simplify this slightly to:

"create a variable named foo"
'foo' variable

"store 100 into it"
#100 &foo !

"fetch the value stored in foo"
&foo @

As you can see, the @ and ! functions basically act like the equivalent functions in Retro/Forth, and all three serve as a simple means to clean up the code visually. Rather than manually specifying the offset, this lets the code be more concise, which is often beneficial.

Parable also provides values. These are subtly different - let's look at the same example using them.

"create a value named foo"
'foo' value

"store 100 into it"
#100 to foo

"fetch the stored value"
foo

This looks a little like parsing, which Parable avoids. What actually happens is this: The value function constructs a new function, which either updates or returns a stored value. When the to function is encountered, it sets a global flag that tells the next value to update the stored item with whatever is on the stack. The function then resets the flag. If the flag is already clear, the created function will return the stored item.

Keeping the source readable is always a useful goal, and values can help significantly here. For instance, if we want to add a number to a stored item, we could do it in one of these ways:

"with simple byte code access"
request 'foo' define
#100 &foo #0 store
#200 &foo [ #0 fetch + ] sip #0 store

"using variable"
'foo' variable
#100 &foo !
#200 &foo [ @ + ] sip !

"using value"
'foo' value
#100 to foo
200 foo + to foo

It should be evident that the value approach is significantly more concise than the others. But variables still have their uses. Specifically, they are faster than values, since they do not need to check the global flag before doing the store or fetch. So longer running code can save some time by using variables. (I personally don't think it's worth the readability tradeoff to drop to simple byte code access functions for even better performance).

So all of this is in response to a question: 

I have to go with yes. Arrays are incredibly useful, but there is no case where I'd prefer them over either variables or values for accessing a single named data element.

Thinking about this before I wrote this post did make me consider how to further improve these pieces of functionality. Very soon Parable's value function will be updated to additionally store the type of the stored value. So the extra step of using one of the type conversion functions can be dropped which will make them even more useful (and distinct from variables, which will not track the type of the stored item).

Unicycling

As a teenager I used to ride a unicycle very frequently. My first one was a cheap 20" which I loved. I quite literally rode it until it died (I was rather clueless regarding maintenance, and the bearings eventually gave out while the cranks fused to the hub.). I then spent a couple of years riding my dad's larger 24" uni, which proved satisfying for distance riding, though far more difficult for offroad and tricks. After going off to college I stopped riding.

A couple of years ago I started thinking about trying this again, so I purchased a muni (mountain unicycle). This was probably not the best choice. Due to the tire (3" diameter!) it was a bit too high for comfortable starts, so I only tried riding it a couple of times before giving up.

Recently I decided to try again. I've lost some weight, and really want to start riding once more. I have spent a little time each day practicing, and am slowly improving. I can make it about halfway around a block now, though keeping in a straight line is almost impossible, and I need a lot of space for turns. I expect to be able to go significantly further after a couple of weeks of riding.

For now I had to set it aside again, due to the seat bolts working loose. I can't ride until Friday or Saturday when I'll be able to go out and get the tools I need to fix it. But I'm eager to keep working at it this time.