search

kframework / k-legacy

The K tools (deprecated, see README)
http://kframework.org
Other
146 stars 61 forks source link

kompile -- main-module should be last module #151

Open grosu opened 10 years ago

grosu commented 10 years ago

kompile --help tells us that

--main-module Specify main module in which a program starts to execute. This information is used by 'krun'. The default is the name of the given K definition file without the extension (.k).

Anybody knows why we decided to pick this default instead of simply the last module in the .k file?

Many of my students got confused because of that. They called their modified LAMBDA module different names, e.g., LAMBDA-EX1, LAMBDA-CALLCC, EX1, etc., which made them have to read the options in order to kompile their programs. Moreover, and worse, my testing scripts became close to useless, because I had to include a different option --main-module for each student.

If nobody has anything against, I think we should change the main module to the last one in the .k file.

radumereuta commented 10 years ago

This convention dates back to the ages of Perl kompile. The current implementation just copied that functionality. So, Andrei A., Traian... do you remember the logic behind it?

Regarding your new suggestion, I don't see why this is so strange. Look at C. The default, and only acceptable entry point into a program is the function 'main'. No matter where it is written.

Can you name another system that takes the last module/class/function as the default execution environment/entry point?

grosu commented 10 years ago

OBJ, Maude, Prolog, and tons of interpreted languages.

There is a difference between functions and modules. Functions can be mutually recursive, and thus their order in a file is irrelevant. But in the case of modules, they import each other as if you copy-and-paste the functionality of the imported ones into the importing ones. The only reason you may want to have a module which was not the last one as main is because you may have experimental stuff that you do not want to consider after the "main" module. But most of time, the stuff that you add after the "main" module is what you want to be the new main module.

For example, you want to extend IMP to add a new feature to it. You add a new module, say IMP-EXTENDED which imports IMP. Then you kompile without thinking imp.k and have to waste 1 minute to realize that it didn't include the new stuff that you defined ... why, ah, s**t, etc.

Grigore

From: Radu Mereuta [notifications@github.com] Sent: Thursday, November 14, 2013 5:57 AM To: kframework/k Cc: Rosu, Grigore Subject: Re: [k] kompile -- main-module should be last module (#151)

This convention dates back to the ages of Perl kompile. The current implementation just copied that functionality. So, Andrei A., Traian... do you remember the logic behind it?

Regarding your new suggestion, I don't see why this is so strange. Look at C. The default, and only acceptable entry point into a program is the function 'main'. No matter where it is written.

Can you name another system that takes the last module/class/function as the default execution environment/entry point?

— Reply to this email directly or view it on GitHubhttps://github.com/kframework/k/issues/151#issuecomment-28478361.

traiansf commented 10 years ago

I agree with the proposed change. When we were doing the compilation in Maude using perl for preprocessing it was harder to detect the last module of a definition, I think. there is also the thing that we base the detection of our syntax module based on the name of the main module... but I guess this is ok with the new suggestion, too.

BTW, quoting OBJ and Maude as good examples on how we should do things in K seems strange to me :-) Prolog has no modules, at least not in the major distributions I am aware of, and I think not in the standard either.

best wishes, Traian

2013/11/14 Grigore Rosu notifications@github.com

OBJ, Maude, Prolog, and tons of interpreted languages.

There is a difference between functions and modules. Functions can be mutually recursive, and thus their order in a file is irrelevant. But in the case of modules, they import each other as if you copy-and-paste the functionality of the imported ones into the importing ones. The only reason you may want to have a module which was not the last one as main is because you may have experimental stuff that you do not want to consider after the "main" module. But most of time, the stuff that you add after the "main" module is what you want to be the new main module.

For example, you want to extend IMP to add a new feature to it. You add a new module, say IMP-EXTENDED which imports IMP. Then you kompile without thinking imp.k and have to waste 1 minute to realize that it didn't include the new stuff that you defined ... why, ah, s**t, etc.

Grigore

From: Radu Mereuta [notifications@github.com] Sent: Thursday, November 14, 2013 5:57 AM To: kframework/k Cc: Rosu, Grigore Subject: Re: [k] kompile -- main-module should be last module (#151)

This convention dates back to the ages of Perl kompile. The current implementation just copied that functionality. So, Andrei A., Traian... do you remember the logic behind it?

Regarding your new suggestion, I don't see why this is so strange. Look at C. The default, and only acceptable entry point into a program is the function 'main'. No matter where it is written.

Can you name another system that takes the last module/class/function as the default execution environment/entry point?

— Reply to this email directly or view it on GitHub< https://github.com/kframework/k/issues/151#issuecomment-28478361>.

— Reply to this email directly or view it on GitHubhttps://github.com/kframework/k/issues/151#issuecomment-28478727 .