search

michaelleejl / pyot

A domain specific language for interacting with IOT devices built with textX
MIT License
0 stars 0 forks source link

home.pyot syntax and structure #1

Open michaelleejl opened 2 years ago

michaelleejl commented 2 years ago

I like the home.pyot syntax as it stands, but a couple of things I think are worth considering.

I've sorted the issues in descending order of severity.

  1. The syntax for creating devices seems ambiguous. Currently the syntax for naming a light, light1: PhillipsHue() is no different from naming a space, Room1:. That to me seems like poor design.
  2. Actions look like annotations. The way the information architecture / hierarchy is laid out is very reminiscent of the "on X do Y" syntax. This makes me worried because actions should be fundamentally different from annotations meant to taxonomize. This is why I suggested making these hierarchical 'spaces' positional tags with a transitive property. That means to say, if I write #Home{ #Room1{} }, then anything with the #Room1 tag must also have the #Home.
  3. Functional vs Positional tags I've been thinking about what to do with functional tags, and I wonder if an "isA" keyword would be useful. That is to say, you would write something like light1: PhillipsHue() isA #discoLight. This keyword would be a suffix, while all positional tags would be prefixes - so #Home{ #Room1{ light1 = new PhillipsHue() isA #discoLight } }. We might consider establishing an explicit syntactic difference between a positional tag and a functional tag.
  4. Explicit exports. Would the programmer need to explicitly export anything? If not, is this because we can manually do it during the interpretation?

@riamundhra02 please let me know your thoughts

riamundhra02 commented 2 years ago

1.right i agree, maybe something like light1: new PhillipsHue() might work better?

2.(and 3.) i also agree with this, looking back. I quite like the isA syntax, disambiguates the tags p well. My only concern with the positional tags/annotations is, would this be straying away from the YAML syntax too much?

4.Honestly, i didnt rly think about this v hard when writing the syntax, but i do think its an important thing to consider. if were allowing files to be separated or combined, i thought imports would work like in python, where you can essentially import any python file into another w/o any explicit export statements? but am open to other ideas as well