Skip to content
This repository has been archived by the owner on Feb 20, 2024. It is now read-only.
This repository has been archived by the owner on Feb 20, 2024. It is now read-only.

Problem with XML literals #20

Open
@mindplay-dk

Description

I love the simplicity of the XML literal syntax evaluating to simple constructor calls, and to get a feel for it, I decided to write some basic parser combinators - I figure it would be really awesome to compose grammars out of XML literals.

You can see here what I got so far:

@entry
def test {
  var parser =
    <Match value="hello"/>
  console.log(parser.parse("hello"))
  console.log(parser.parse("foo"))
}

class Result {
  var input string
  var offset int
  def isSuccess bool {
    return false
  }
  def isFailure bool {
    return false
  }
}

class Success : Result {
  over isSuccess bool {
    return true
  }
}

class Failure : Result {
  over isFailure bool {
    return true
  }
}

class Parser {
  def parse(input string) Result
}

class Combinator : Parser {
  var children List<Parser> = []

  # The compiler uses this function to append children
  def <>...</>(child Parser) {
    children.append(child)
  }
}

class Match : Parser {
  var value string
  over parse(input string) Result {
    if input == value { 
      return Success.new(input, 0)
    } else {
      return Failure.new(input, 0)
    }
  }
}

var m = Match.new("hello")

@import {
  const console dynamic
}

It doesn't work quite the way I was expecting though - it seems there's a limitation that all constructors must have an empty list of arguments?

Actually, at first, I thought that attributes were being mapped to constructor arguments - that attribute-names were kind of like "named arguments" to the constructor, but they're actually properties being set after the construction of the object instance.

The problem is that many objects (such as simple string-matcher like in my example) can't have any meaningful empty constructor - a string-matcher that doesn't know what it's supposed to match isn't a valid string-matcher, so this design kind of forces me to initialize objects in an invalid state.

Wouldn't it make more sense for attributes to actually be "named arguments" in a sense, mapping against argument-names in the constructor, so that the values would be evaluated prior to constructing the objects, so they can be initialized in a valid state?

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions