[Prev][Next][Index][Thread]

Re: MIME for Dylan sourcecode?

In article <KFFGEJIJDNFKKAAA@mailcity.com>, 
andrewa@functionalobjects.com wrote:

> On Mon, 3 Sep 2001 05:15:03   
>  Bruce Hoult wrote:
> >It's a pain that even the simplest Dylan program needs several source 
> >code files.  This makes life harder for beginners, makes Dylan less 
> >suitable as a scripting or CGI language, and even keeps Dylan off a 
> >certain wll-known progrmaming language comparison web page.
> 
> We have had similar thoughts, and I thought a couple of years ago
> we started some conversations with Gwydion about how to address
> this. Anyway, that's irrelevant now, now is a great time to get
> this standardized.

That may have been before I joined the Gwydion maintainers -- or maybe 
even before Gwydion was spun off from CMU.

Or it may have been on some private mailing list that I didn't (or 
don't) know about.  I think I'd prefer that anything that *can* be 
discussed on the newsgroup *should* be.  Dylan needs all the visibility 
it can get and I've seen fairly convincing arguments that what projects 
become popular is strongly correlated with whether they are organized 
primarily via open, discoverable, lurkable, newsgroups (e.g. Linux) or 
mailing lists (e.g. xBSD).


> >This similarity to RFC822 makes me wonder whether it would be 
> >appropriate to extend this to allow the current three+ text files (LID 
> >file, exports file, source code file(s)) to be combined into a single 
> >text file using MIME.
> 
> Our plan was actually much simpler. Because all the different file
> types are of the same format (header then body), and the header
> keywords are basically compatible, we thought we'd allow
> hello-world.dylan to contain everything it needed to be compiled.

That's fine by me.  The simpler we can make it the better as anything 
that grows to multiple files or modules can revert to the existing 
mechanism.


> I think this is a cleaner design, and is certainly easier for
> developers to code themselves. I think it is important that
> our hello-world application looks as simple as it can.

Agreed.

Actually, I've got a dirty little secret: I don't at all understand the 
significance or ramifications of how the foo-exports.dylan file is 
organized.  Every program I've ever seen puts it in the "dylan-user" 
module, but your sample puts it in the "helloworld" module.  I didn't 
know this was valid, and in fact it fails in d2c with an "Attempting to 
use library helloworld before it is defined" error.

I also don't understand the rules for the "define library" and "define 
module" declarations themselves.  Why aren't the "define module" 
declarations nested within the "define library" ones?  Does the scope of 
the "define library" extend to the end of the file?  Is it possible to 
have more than one "define library" declaration in the same file?


> One further possibility, we could define a standard 'dylan-script'
> library and module, thus allowing helloworld to look like:
> 
> ------------------------------------------------
> library: dylanscript
> module: dylanscript
> 
> define function main(name, arguments)
>   format-out("Hello, world!\n");
>   exit-application(0);
> end function main;
> 
> // Invoke our main() function.
> main(application-name(), application-arguments());
> ------------------------------------------------
> 
> Now that's concise, and makes Dylan look like a real scripting
> language.


Well, actually, for the lurkers, that can trivially be reduced to:

------------------------------------------------
library: dylanscript
module: dylanscript

format-out("Hello, world!\n")
------------------------------------------------



The main issue with this is that you can't tell before opening
a .Dylan file whether it is a source file or a combined
project/source file.

With regard to te compiler, we'd considered a system in which if you 
used "d2c foo.dylan" instead of the usual "d2c foo.lid" then the 
compiler would act AS-IF the user had typed "make-dylan-app foo; d2c 
foo.lid".  The "make-dylan-app" script creates a default foo.lid and 
foo-exports.dylan file.


> I think it is important that our hello-world application looks
> as simple as it can.

I do worry, however, that there should be a clear and obvious path from 
a trivial throw-away "script" to a full-blown application.  The MIME 
idea has a bit more bulk, but myself I find it prefectly acceptable to 
have that bulk initially generated by a script or the IDE (wizard, 
project template, whatever ... C++ and Java users certainly accept 
this), and it is trivially obvious to see how to extend it, or even 
split it into the constituent files later.


Do you have thoughts on how best to let a Dylan "script" be compiled and 
run in a single command?  We need 1) a way to tell the compiler to do 
that, and 2) some mechanism to reuse the executable from last time if 
the source code hasn't been modified (as with e.g. JavaServerPages).  
Basically the same functionality as a trivial makefile, but without 
actually having one.

-- Bruce
Follow-Ups: References: