Enhancement: adding target language directives in the Frame language

[walni]

Hi,

I am playing a bit with HSMs in Frame with Python as the target language, and it works very well. As Python is a dynamically typed language, I was curious to check if was possible to use Python types & data structures directly in Frame.

For example, declaring a Python list and a list iterator in Frame:

var timeoutList:list = eval("[0.1, 1, 2, 5]") var timeoutIterator:Iterator = iter(timeoutList)

work perfectly. That means that Frame can act effortless on (at least some) Python types and data structures, possibly encouraging the use of Frame in the Python community.

To go a bit further, it would be nice to be able to write target language directives in Frame to improve integration.

For example:

-actions-

tryIncrementTimeout[timeoutIterator:Iterator]

could be followed with their Python implementation:

--- Python actions implementation in Frame ---P def tryIncrementTimeout_do(self, timeoutIterator): ---P try: ---P timer = next(timeoutIterator) ---P sleep(timer) ---P return True ---P except StopIteration: ---P return False

where ---P would indicates to the transpiler that the line represent a Python content to be passed "as is". I found that separating the Frame code with the action implementation code can be a source of errors, especially when variables or arguments are passed . With target language directives, there would be just one file to edit, transpile and import in the application software (one line of code!). The directives could be simply ignored when the targeted language is not used.

Thanks again for your very nice Frame language! walni

[frame-lang]

Hello and thanks for your interest!

Frame does have (unfortunately) undocumented syntax using backticks which directly passes through the contents to the code generators, but so far it is for types and for actions. It looks like this:

$S1[msg:`MyType`]
    |>| print(&msg) ^

-actions-

print[msg:&String] {`
    println!("{}", &format!("{}",msg));
`}

It isn't implemented for freeform use in the event handler, but that could be explored. It also is only working in the Rust code generation at the moment. I have been hoping people would be able to advocate for their languages of interest and make proposals as you have done.

Do you think literal Python in the actions would meet your needs?

[walni]

Yes, it would be great!

However, backticks are not language specific, so they will break Frame universality:

var` timeoutList:list = `[0.1, 1, 2, 5]`

maybe nice for Python users, but would very poor in terms of portability when trying to transpile the .frm to other languages.

Maybe with language annotations ? (but it looks awful):

var timeoutList:list = `ifPython then [0.1, 1, 2, 5] else myFrameNotImplementedListVariable`

An other way would be to indicate to Frame that it enter a target language implementation block:

-actions-
var timeoutList:list = myFrameNotImplementedList

-python-implementation-
myFrameNotImplementedList = [0.1, 1, 2, 5]

The Frame syntax would remain clean, and the language implementation block ignored when not the target language.

[frame-lang]

In general, though I've already obviously made exceptions, Frame is intended to be a "control plane" language and not get its hands dirty with data munging. The syntax is focused on state management and routing events to the right "executive behavior", by which I mean the target language and environment code that actually does something (like provision a server or set a pixel).

Executive behavior is ideally kept in actions. What might be a good approach is to be able to annotate an action as being language specific. Here's a possible notation:

    -actions-

    #[language=rust]
    print[msg:&String] {
        println!("{}", &format!("{}",msg));
    }

That would keep control logic separate from the execution logic. Thoughts?

FYI the (small) Frame community has a gitter community for long running discussions here: https://gitter.im/frame-language/community.

But happy to chat here or there.

Best,

Mark

[walni]

Agree that executive behavior is ideally kept in actions. Also that #[language=python] would be a very nice extension!

See you in gitter to continue discussion, thanks.