Portability

I take a lot of inspiration from simple virtual machines like uxntal when it comes to portability. Uxn manages to be so simple as an underlying language, that you can implement all the basic opcodes and a couple limited devices in a weekend (I have not yet attempted this, but many others have).

For uxn, this unlocks the possibility of reimplementing the core VM on all sorts of platforms. That combined with the fact that uxn is a very solid spec that rarely breaks backwards compatibility, means you get really good portability across environments. (you can run the same programs on the web, natively, or on game consoles)

Varvara is the default platform used for uxn programs. Although it is stated to be "a computer system for uxn", which implies that there might be other systems you could write to support uxn programs too. Indeed, there is nothing in the uxn spec that couples it to varvara, but in reality I haven't found any other alternative platform in use today (besides uxnmin, which is a subset of varvara, or some capabilities builitin to emulators like uxn11, which is a superset)

One reason I think we don't have alternatives cropping up is that this would simply fragment the uxn ecosystem. Any otherwise valid uxn program that targets a different platform cannot be run on varvara and vice versa.

To be clear, I don't think this is a flaw of uxn. I don't see a compelling reason for more than one platform in the uxn ecosystem. This does limit it's ability to be used in different contexts, but having one standard ultimately helps IMO.

This is the crux of what I'm trying to achieve with dewlang, I simply don't think programs need to be be isolated to the platform they are developed for.

To give a small example of where I wished I had this is when porting my uxn game Tower of Laputa to mobile (on the web).

To integrate touch controls, I wanted to add a little dpad and jump button on screen when it detects touch. AFAIK there's not really support for touch (at least not for multitouch) in the uxn ecosystem, so this meant I needed to delve into JS.

I read through the JS touch api, going over MDN pages, and whipped together something really rough, but it worked.

A few problems with this solution

• I really would have rather stayed within the uxn ecosystem to develop this. (Though I am ultimately glad varvara does not have it's own touchscreen api, it's simpler that way)
• The dpad and button interface could be reused for other projects, but unfortunately it's in javascript, so it wouldn't work if I wanted to use it for native app (unlike uxn programs)
• Even if the dpad and button interface was in uxn, I still wouldn't be able to easily reuse the logic between games

Dewlang in contrast provides a solution for this via multilevel platforms.

Every component written in dewlang has sandboxing builtin, for example lets say you have a basic program that used dpad and button devices like so. Let's call it "game.dew"

dpad = @require("dpad")
button = @require("button")

on input
  if dpad() then move(dpad()) end
  if button() == 0 then jump() end
end

Maybe there could be a platform that has support for these natively, though that would likely just be limited to a game console.

We can solve this without touching the code. Because "game.dew" is implicilty a top level component, which means you can import it and hook it up for a keyboard device instead (for example)

keyboard = @require("keyboard")

dpadInput = null
buttonInput = null
game = @import("game.dew") | {
  dpad: fn () return dpadInput end
  button: fn () return buttonInput end
}

on keydown
   key = keyboard()
   if key == 'a' then dpadInput = [-1, 0] end
   if key == 'd' then dpadInput = [1, 0] end
   if key == 's' then dpadInput = [0, 1] end
   if key == 'w' then dpadInput = [0, -1] end
   if key == 'j' then buttonInput = 0 end
   game!input
   buttonInput = null
   dpadInput = null
end

Doing the same for touch is a bit more involved (as it includes a visual component too) but is otherwise the same process of wrapping the inter-component and providing the devices as needed.

As an added benefit, the wrapper as just as portable as the rest of the game.

Something at the back of my mind, maybe there were a good way of injecting the component itself into the wrapper, making the wrapper fully reusable as a platform.

In the future I want to explore what other uses there are for this multiplatform system and see how it holds up in other contexts.