Welcome to Val Discussions!

[kyouko-taiga]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community and let anyone contribute to the design and development of the Val programming language. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded (we ask everyone to follow our code of conduct).

[dtristram]

Hi, Dave Abrahams has been spreading the word about Val at Adobe. I'm a senior engineer in the Digital Imaging organization there.

[dtristram]

question: are there plans in Val for something like swift function builders? They are called something else now I believe.

[kyouko-taiga]

It's something we'd love to explore. I'm very interested in embedded DSL and I'm sure I'm not the only one.

Unfortunately there are a lot of other more urgent issues we need to address before we can really dig into features like function builders.

[dtristram]

yes, I can imagine. perhaps a layer that has been written for Swift could be ported to operate with Val.

[dtristram]

question: After I built a DSL in Swift using function builders I wanted to write scripts in it. Are there any plans for a Val-based scripting runtime?

[dtristram]

The DSL I built was a shorthand for specifying a scene graph. Identifiers followed by lists in braces were convenient for creating my DAG. But I was limited by only being able to use my language at compile time. It would have been nice to be able to read code in my DSL and then interpret it as though it had been defined statically at compile time. So, I used the "scripting" term here to describe this. I guess the runtime interpretation of code is really only part of what a REPL or a complete scripting runtime would need.

[kyouko-taiga]

IIUC, you're after meta-programming features. We haven't explored that aspect of the design yet.

[dtristram]

well, I'd like to read code in my DSL from a file into a running program written in Val and interpret/run it.

[kyouko-taiga]

If you can settle for an interpreter, then the answer is easy. You have two choices:

1. Use the features that Val will provide to build an embedded DSL, which will be parsed by Val's compiler.
2. Write your own parser in Val and use it to parse programs written as strings in a Val file.

In both cases, the idea is to extract some data (e.g., an AST) that you can feed to an interpreter. You can do that in Swift or any other programming language.

The advantage of the first approach is that it leverages the existing infrastructure to implement parsing and type checking. It will also be faster because you won't have to deal with parsing and type checking at runtime, unless you need to check for constraints that can't be expressed in Val's type system.

The advantage of the second approach is that you can parse any string at runtime. So you could generate programs on the fly and feed them to your parser and then interpreter. If I understand your requirements correctly, I guess you'd have to use that technique.

One way to get around parsing at runtime would be to provide a way to construct the data structure that is built by your parser. For example, LLVM has a textual syntax that you can parse but it also provides an API to assemble IR programs programmatically.

[dtristram]

thanks, I appreciate the discussion