search

vmware / database-stream-processor-compiler

Infrastructure to run programs written in high-level languages on top of the Database Stream Processor (DBSP) runtime.
Other
16 stars 2 forks source link

Added Syntax RFC #4

Closed Kixiron closed 2 years ago

Kixiron commented 3 years ago

Rendered

ryzhyk commented 3 years ago

I vote we stick to using issues as RFCs. The lifetime of a PR is generally much shorter than an issue, and once a PR has been merged github does not have a way to comment on it. In addition, issues have mechanisms for progress tracking and cross-referencing.

mihaibudiu commented 3 years ago

How should we comment line by line?

From: Leonid Ryzhyk @.> Sent: Monday, September 20, 2021 8:29:38 AM To: ryzhyk/differential-datalog-v2 @.> Cc: Subscribed @.***> Subject: Re: [ryzhyk/differential-datalog-v2] Added Syntax RFC (#4)

I vote we stick to using issues as RFCs. The lifetime of a PR is generally much shorter than an issue, and once a PR has been merged github does not have a way to comment on it. In addition, issues have mechanisms for progress tracking and cross-referencing.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fryzhyk%2Fdifferential-datalog-v2%2Fpull%2F4%23issuecomment-923034818&data=04%7C01%7Cmbudiu%40vmware.com%7Ce3f2025d5d3c4fe406aa08d97c4b7594%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637677485805156169%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=j0nFyHZWhFrORz9u3G0NtpLdPq16i2RcZrX84dFylYU%3D&reserved=0, or unsubscribehttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAET7TMV74HNBE2XT23JZWB3UC5HOFANCNFSM5EMFOW7Q&data=04%7C01%7Cmbudiu%40vmware.com%7Ce3f2025d5d3c4fe406aa08d97c4b7594%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637677485805166159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=n28o1gG45ttuGHI%2BJjL56s7phjDzD4%2BHbuocbV%2BcTks%3D&reserved=0. Triage notifications on the go with GitHub Mobile for iOShttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04%7C01%7Cmbudiu%40vmware.com%7Ce3f2025d5d3c4fe406aa08d97c4b7594%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637677485805176149%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DB4c5iHh0ziZe63%2BzuPMIm0Q5CYf4JezcCB9KObR5Lk%3D&reserved=0 or Androidhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04%7C01%7Cmbudiu%40vmware.com%7Ce3f2025d5d3c4fe406aa08d97c4b7594%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637677485805176149%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1%2BZXb0HCQN2QuPXkzND1JNzkptP4DNTfj6bcYP4%2BSNg%3D&reserved=0.

ryzhyk commented 3 years ago

How should we comment line by line?

By selecting the line you want to comment on and clicking "quote reply" :) I know, it's not ideal, but otherwise there's no way to do it at all.

Kixiron commented 3 years ago

We can still comment on lines after a merge, you just link the line in the repo

ryzhyk commented 3 years ago

We can still comment on lines after a merge, you just link the line in the repo

Sure, but we still need an issue for that. So where do I put feedback on the PR? In the PR or in an issue?

Kixiron commented 3 years ago

In the PR if it's open, we'll only merge it once we've deemed it "finished"

ryzhyk commented 3 years ago

In the PR if it's open, we'll only merge it once we've deemed it "finished"

.. and then create an issue to track implementation progress? It kind of works, but I still don't buy this model. Firstly, not every RFC is a PR. Second, it's not obvious to me when an RFC should be considered finished. I don't want to argue forever about process issues, so let's do whatever works for you, I just don't understand why not use a proven model that works well for well established projects.

mihaibudiu commented 3 years ago

In P4 land the spec is a markup document which is evolved by making PRs against it. Issues are filed with desired improvements, and some issues (the bigger ones) have a special structure to track progress. A spec issue also tracks an implementation issue that matches it. The spec is a different repository, BTW. It has been working fine for a few years.

Kixiron commented 3 years ago

Rustc works very much the same way, we shouldn't need a separate repo since we're so much smaller though, we can keep things in-tree

mihaibudiu commented 3 years ago

In addition, we have a google doc where we keep track of discussions that are made during periodic meetings. Here is an example of a tracking issue: https://github.com/p4lang/p4-spec/issues/929

ryzhyk commented 3 years ago

PS. Also, syntax for closures is missing.

mihaibudiu commented 3 years ago

BTW: writing a converter from DDlog-1 to DDlog-2 is a first priority - at the very least to generate tests. So we should also write a grammar for DDlog-1 using this tool.

ryzhyk commented 3 years ago

BTW: writing a converter from DDlog-1 to DDlog-2 is a first priority - at the very least to generate tests.

Sure

So we should also write a grammar for DDlog-1 using this tool.

I don't think it's necessary. We already have a parser for DDlog-1. I will implement the converter as ddlog-1 compiler feature.