search

ourPLCC / plcc

A Programming Languages Compiler Compiler
GNU General Public License v3.0
4 stars 2 forks source link

Java/ #130

Open StoneyJackson opened 2 weeks ago

StoneyJackson commented 2 weeks ago

I propose the following changes related to the generated Java/ directory.

  1. Move the responsibility of cleaning up Java/ into plcc. plcc knows how to create it; so it best knows how to clean it.
  2. [BREAKING] Make cleanup of Java/ unconditional. This is the common case.
  3. [BREAKING] Don't allow the user to specify a different directory. All of the scripts (rep, parse, ...) require the directory to be Java/, and they do not take a parameter to specify the directory. The alternative is to add this parameter to these scripts making them more complicated and making the scripts harder to use.
jashelio commented 2 weeks ago

Agreed. I would disagree with #3 if this were a commercial tool, but it is a teaching tool, so it’s fine. - Jim

On Apr 30, 2024, at 5:26 PM, Stoney Jackson @.***> wrote:

I propose the following changes related to the generated Java/ directory.

Move the responsibility of cleaning up Java/ into plcc. plcc knows how to create it; so it best knows how to clean it. [BREAKING] Make cleanup of Java/ unconditional. This is the common case. [BREAKING] Don't allow the user to specify a different directory. All of the scripts (rep, parse, ...) require the directory to be Java/, and they do not take a parameter to specify the directory. The alternative is to add this parameter to these scripts making them more complicated and making the scripts harder to use. — Reply to this email directly, view it on GitHub https://github.com/ourPLCC/plcc/issues/130, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEH53GSNYZPSL7JYGJ77HADZAAD6VAVCNFSM6AAAAABHBAQPYGVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI3TENBXGQ4TGNA. You are receiving this because you are subscribed to this thread.

StoneyJackson commented 2 weeks ago

True... Alternatively, we could always require a target directory. That's what I advocated in #133 for the specification file. Maybe we should adopt The Zen of Python - PEP 20... then...

If we follow "Explicit is better than implicit," then we should require a path to the generated language system.

plccmk ./mylang.plcc ./mylang
scan ./mylang < hello.mylang
parse ./mylang < hello.mylang
rep ./mylang < hell.mylang

Worth considering.

jashelio commented 2 weeks ago

My gut tells me this is going too far. Right now the plcc script creates a directory named Java (or Python, I guess), and all the other scripts assume that that is where the generated code is.

The only advantage of the scenario you describe below is that we could actually store several systems in one directory. But I hardly see that as useful.

Jim

On May 1, 2024, at 2:32 PM, Stoney Jackson @.***> wrote:

True... Alternatively, we could always require a target directory. That's what I advocated in #133 https://github.com/ourPLCC/plcc/issues/133 for the specification file. Maybe we should adopt The Zen of Python - PEP 20 https://peps.python.org/pep-0020/... then...

If we follow "Explicit is better than implicit," then we should require a path to the generated language system.

plccmk ./mylang.plcc ./mylang scan ./mylang < hello.mylang parse ./mylang < hello.mylang rep ./mylang < hell.mylang Worth considering.

— Reply to this email directly, view it on GitHub https://github.com/ourPLCC/plcc/issues/130#issuecomment-2088892960, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEH53GVQ2NWP5WBX54FTCJLZAEYMDAVCNFSM6AAAAABHBAQPYGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBYHA4TEOJWGA. You are receiving this because you commented.

StoneyJackson commented 1 week ago

I agree with the original.