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

Re: MIME for Dylan sourcecode?



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.

>The DRM says little or nothing about the overall format of source code 
>files.  Dylan is intended to be compatable with environments in which 
>the source code is kept in a database, rather than in text files.
>
>Apple Dylan used a database, converting to text files only for 
>import/export.
>
>The two current implementations (Functional Developer and Gwydion Dylan) 
>both are text-file only.  There is currently an agreed common format for 
>source files and "library definition" files, both of which consist of 
>essentially RFC82-like header lines followed (in the case of source code 
>files) by a blank line and then the actual Dylan source code.
>
>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.

For example, this could be hello-world.dylan:

------------------------------------------------
library: helloworld
module: helloworld

define library helloworld
  use common-dylan;
  use io;
end library;

define module helloworld
  use common-dylan;
  use format-out;
end module;

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());
------------------------------------------------

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. This makes it hard for an IDE to know
what to do with it, but opening the file quickly to determine if
this contains project information is probably feasible. We might
need to mandate that one of the keywords used in the header
determines that this is a project file, a good example might
be 'executable'. 'Library' would be even better, if we don't
use it in other headers.

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.

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. We could even lose the 'module: dylanscript' if we
mandated that for libraries with only one exported module the
'module:' keyword could be derived.

>So, for example, the current Gwydion make-dylan-app script might create 
>something like this:
>
>
>library: helloworld
>executable: helloworld
>MIME-Version: 1.0
>Content-Type: multipart/mixed;
>              boundary=-------
>
>-------
>module: dylan-user
>
>define library helloworld
>  use common-dylan;
>  use io;
>end library;
>
>define module helloworld
>  use common-dylan;
>  use format-out;
>end module;
>-------
>module: helloworld
>synopsis: 
>author: 
>copyright: 
>
>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, I'm no expert on MIME, so I'm not sure whether this is valid 
>conforming MIME, or if it is whether this is the best way to represent a 
>Dylan program using MIME.  What I'm doing is basically taking our 
>current .lid file format, taking out the "files:" header (since the 
>files are now inline), and adding MIME headers.  I'm taking advantage of 
>the default body format for mime being the same as if "Content-type: 
>text/plain; charset=US-ASCII" was explicitly included.  Perhaps some 
>compilers might want to recognize other formats as well.
>
>I'd like to see discussion on this, including enhancements and of course 
>corrections of any idiocies I've commited.
>
>If we can get some sort of agreement then I'd be happy to do the work to 
>modify d2c to accept files in this format.

We'd be happy to support whatever we agree to, we've actually done
most of the work for it already.

What does anyone else think?

Andy

---
Andy Armstrong
andrewa@functionalobjects.com



Get 250 color business cards for FREE!
http://businesscards.lycos.com/vp/fastpath/


Follow-Ups: