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

Re: Dylan source in one file?

This is such a good idea, that we've already agreed it with
Gwydion as part of the Common Dylan initiative, and it is
already implemented in Functional Developer! Note that I'm
not sure if it made it into 2.0, though.

The next step is to have an all-in-one .lid and .dylan file,
the details of which we didn't finish but it follows fairly
logically from what you said below. So if the following were
saved to a file hello-world.dylan, a Dylan compiler could
build hello-world.exe directly from it:
  ---------8<----------
  Library: hello-world
  Module: hello-world

  define library hello-world
    use common-dylan;
  end library hello-world;

  define module hello-world
    use common-dylan;
  end module hello-world;

  format-out("Hello world!\n");
  ---------8<----------

This still isn't as concise as you'd like, so it might be worth
having a standardized 'play' library, or a more concise way of
defining a simple library and module pair.

Anyway, I think this is a very important piece of making Dylan
an easier language to get started with, and it also provides a
very natural way to support Dylan as a scripting language, which
I think is a niche it could fill extremely well.

Andy

---
Andy Armstrong
andrewa@functionalobjects.com



On Thu, 13 Jul 2000 12:00:02  
 Hugh Greene wrote:
>Just an idle thought I had yesterday ...
>
>One of the little niggles for Dylan beginners is that, for existing
>implementations using Dylan Interchange Format (DIF) files at least, every
>dylan program needs at least two source files.  One looks like
>
>  Module: dylan-user
>
>  define library foo ... end;
>  define module foo ... end;
>
>and the other like
>
>  Module: foo
>
>  // Main definitions here
>
>
>I suppose there's no reason why you couldn't define lots of things in
>dylan-user, so that might do for trivial examples.  But you can't import
>any other modules than dylan nor export things from it (because you can't
>write its module definition) so for non-trivial examples, you're still
>stuck.
>
>Now, reading the DRM definitions of the DIF and the way modules and
>libraries work, it seems the following needn't be illegal, though it might
>be tricky to implement.  All in one file:
>
>  Module: foo
>
>  define library foo ... end;
>  define module foo ... end;
>
>  // Main definitions here
>
>
>You can think of the "Module: foo" as a forward reference, which has to be
>checked when you get to the module definition.  Now, technically, you
>can't parse the library and module definition macro calls until you know
>that they're in a module which uses dylan (or otherwise provides similar
>macro definitions).  So I'm wondering whether it would be feasible and
>acceptable to implement this "forward reference" by *assuming* that the
>standard dylan library and module definitions are imported from somewhere,
>and checking that when you've processed the library and module
>definitions. 
>
>Tricky cases might include:
>
>  - The macros are imported indirectly from the dylan library/module,
>    e.g., via common-dylan.
>
>  - There are macros defined/imported which accept the syntax of the
>    standard library and module defining macros, but expand to something
>    different.  (This should still be okay, as long as the right module
>    gets defined at some point in the macro expansion!)  Note that you
>    don't need to define anything to import or call macros (minimalist
>    obfuscated Dylan, anyone? :->).
>
>And on top of all that, it introduces the possibilities of
>
>  - Breaking the flexibility of top-level definition ordering (because we
>    can't parse any other definitions, or at least not any other than
>    those in the dylan module, until we've sorted out the "real" module
>    definitions.
>
>  - Breaking backward-compatibility with existing implementations (unless
>    this all already magically works -- I haven't tested it ;-)
>
>  - Confusing users as a consequence of the above ... especially the new
>    users this idea is intended to help!
>
>  - Leading users into the habit of not having a separate file for library
>    and module definitions.  I'm not *sure* this would be a bad thing but,
>    at least in FunDev, the analogue of C's conditional compilation is
>    usually done by having separate projects sharing partially overlapping
>    sets of source files.  This tends to be needed for scaling to
>    larger projects and having library and module definitions in the same
>    files as other definitions would make this solution less obvious.  But
>    maybe some "advanced tutorial" documentation could explain this
>    "evolution" ... or maybe we'll come up with a better solution for
>    conditional compilation :-)
>
>
>Comments?  Flames?  ;-)
>
>Hugh
>
>
>


Send FREE Greetings for Father's Day--or any day!
Click here: http://www.whowhere.lycos.com/redirects/fathers_day.rdct
Follow-Ups: