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

Re: MIME for Dylan sourcecode?

On Mon, 3 Sep 2001 13:45:02   
 Bruce Hoult wrote:
>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).

I agree, let's keep this on info-dylan.

>> >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.

Precisely, it is important that whatever we choose scales nicely
to the current multiple file model.

>> 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.

Right, the compiler needs to implicitly put any module and
library definitions inside a project style .dylan file into
the dylan-user module. This is definitely a slight change from the
language as specified, but it seems a logical one to me at least.

>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?

It would have been possible to nest the modules inside the containing
library definition, but I think the Dylan designers wanted to
keep them conceptually separate. It also allows for defining
new modules in separate file, which can be useful for libraries
that need different module definitions for some reason (maybe
debug vs development, or possibly for different platforms).

>> 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")
>------------------------------------------------

Good point! Now that's really competitive with any other
scripting language.

>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.

That's okay for a command line interface, it is more problematic
in an IDE, what does opening 'foo.dylan' mean? That's why I
suggested that we make the project style file explicit in the
header, so it can be quickly determined by reading a few bytes.

>> 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.

I don't think we'll win any friends with that solution, it won't look
good on the language comparison site compared to other scripting
languages.

I also have a strong dislike of language constructs that can only
be generated by wizards, code needs to be human readable and
human maintainable.


>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.

That's an interesting question, but I don't think it matters how
we choose to do that within the two different implementations. 
Two possible solutions would be to have a Dylan interpreter, or to
do a JIT-style compiler.

>-- Bruce

Cheers,

Andy

---
Andy Armstrong
andrewa@functionalobjects.com




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