Re: Defining a library in one file

Part of the reason for my conservatism here is that I think some aspects of
this could be knocked out with a day of hacking from any of a few of us.
Other parts may well be quite involved and I've no idea how well those
parts would go.  I'd rather see us making direct, immediate and incremental
improvement that we can put in 2013.1 and 2013.2 than get bogged down in
trying to work out how to correctly massage the library / module code or
some of the other details.

 - Bruce



On Fri, Feb 22, 2013 at 12:02 PM, Bruce Mitchener <[email protected]
> wrote:

> I think that improving the ability to write a simple script and run it is
> a good thing. I also think that making it easier to deal with using
> libraries / modules is a good thing.
>
> I have a couple of concerns here though ...
>
> In "Replacing the LID file", you talk about the library vs module header.
> If this is for scripting, then the name of library doesn't really matter,
> as it is entirely transient, no?  This isn't really meant for creating a
> permanent library or executable, is it? I don't really think it should be.
> Libraries and executables are going to need additional metadata in the
> future for packaging systems and future tools.
>
> For libraries that are intended for re-use and re-distribution, I don't
> think having a build file + source is that unreasonable. (The library file
> ... well, that's up for debate and I'd love to see that improved.) I can't
> think of a language that encourages truly single-file libraries for general
> use. Certainly not Python, Clojure, Haskell, Common Lisp, Scala, Java, etc,
> etc.
>
> You say that at least 10 repos within dylan-lang could be single-file
> libraries. I'd like to understand that better. Which 10?
>
> I think that dylan-compiler should also take a special command for this:
>
>    dylan-compiler -script foo.dylan
>    dylan-compiler -exec foo.dylan
>
> That would indicate that it should build and run the thing.  With -script,
> it could have additional useful behaviors:
>
>
>    - Delete the build products afterwards.
>    - Set the build configuration to use the dylan, common-dylan and other
>    libraries that are part of the Open Dylan distribution rather than building
>    everything from scratch as we do in a normal library / executable situation.
>
> Having -exec would indicate that it should do a normal build in-situ and
> not remove anything afterwards, but that it should execute the resulting
> executable. Note that we don't currently have a command in dylan-compiler
> for executing a build product as that's currently in dylan-environment
> only. (There's a newly opened bug about this.)
>
> Regarding replacing the library file ... I have a couple of concerns.
>
> For a single file library or script, we can, right now, inline the define
> library / module stuff into the main dylan file and that works without new
> syntax / use of headers.  (That gets us down to 2 files, a LID and a Dylan
> file for a small library / executable.)  This works today.
>
> Should these new headers work everywhere? How about in a multi-file
> project? Does anyone really have a good handle on actually implementing
> these headers or would it end up derailing the implementation of the more
> important portions of this? (I personally don't know that area of the code
> well enough to dive in currently.)
>
> There's been plenty of talk over the years about simplifying library and
> module management for all use cases. I'm not sure that we should undertake
> this directly here ... is this the sort of syntax / structure that we want
> to live with going forward and to support more generally / broadly?
>
> I'm just asking questions here and want to be convinced.  Perhaps it would
> be better to split this into multiple DEPs, with a focus on running scripts
> first and to let us gain experience with what the issues involved with that
> are?
>
>  - Bruce
>
>
>
>
> On Tue, Feb 19, 2013 at 8:30 AM, Carl Gay <[email protected]> wrote:
>
>> On Sat, Feb 16, 2013 at 11:00 PM, Carl Gay <[email protected]> wrote:
>>
>>> Hi.  I would like to get feedback on a proposal for a way to define
>>> Dylan libraries with a single file rather than the current minimum three
>>> files: LID file, library file, main program file.  You can read it
>>> formatted<https://github.com/cgay/website/blob/single-file-library-dep/source/proposals/dep-0006.rst> and
>>> reply here with your comments, or plain<https://github.com/dylan-lang/website/pull/40/files>and leave your comments directly in the document.  The latter requires a
>>> github account.
>>>
>>> Thanks.
>>> -Carl
>>>
>>>
>> There is a new draft at a new location:
>>
>> http://opendylan.org/proposals/dep-0006.html
>>
>> Changes:
>> * Added a Revision History link so you can see detailed changes.
>> * Switched from multiple Use-Library/Module headers to single
>> Use-Libraries/Modules.
>> * Renamed Module-Exports header to Export-Names.
>>
>>
>> _______________________________________________
>> hackers mailing list
>> [email protected]
>> https://lists.opendylan.org/mailman/listinfo/hackers
>>
>>
>

_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers