[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Please drop the ^main^ thing
This page is part of the web mail archives of SRFI 103 from before July 7th, 2015. The new archives for SRFI 103 contain all messages, not just those from before July 7th, 2015.
- To: Derick Eddington <derick.eddington@xxxxxxxxx>
- Subject: Re: Please drop the ^main^ thing
- From: Abdulaziz Ghuloum <aghuloum@xxxxxxxxx>
- Date: Sat, 26 Sep 2009 11:37:14 +0300
- Cc: Abdulaziz Ghuloum <aghuloum@xxxxxxxxx>, srfi-103@xxxxxxxxxxxxxxxxx
- Delivered-to: srfi-103@xxxxxxxxxxxxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=DLNBPvktK6biGR3aBiOImPEjKqsTHNY7aLgb755cqMU=; b=VBFnBDxHtzgjS2Z2JTYE99mDXQfjZxB0RvMaQhVVBROEac0TDuYF/JG0fbNMlwLgeP 2mJ/WLSlNASrwrr4FfStpgvSMs6hoOihajkWLoV7aIUhTlcSx5MgLk+Y8tygRgWKOxKM uJ9EgdhO5pYyf3l25Z+dX0y4FfH0RtHZAtFDQ=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=FV+vOn6JpAvs3FWhMRJJuRd+674sKHPuybpyyBIPrtZaOuvYuaLIHaNWxaO9Mu245n 2cnLxsd50y8bM09mqEQZzIhvWp0xGC8SkarMg8pHwcEheasuoRS+NW+rvJZN3ZKiOwlw E6fWy26/KC+XTHTDecU27j0UzxQz7LJbNHF9Q=
- In-reply-to: <1253908037.12583.171.camel@eep>
- References: <3D65C774-615C-4099-A88D-2FCDB32C4370@xxxxxxxxx> <1253903002.12583.147.camel@eep> <1253908037.12583.171.camel@eep>
On Sep 25, 2009, at 10:47 PM, Derick Eddington wrote:
On Fri, 2009-09-25 at 11:23 -0700, Derick Eddington wrote:
PLT's implicit file name is "main.sls", and it avoids conflicts by
prepending #\_. E.g., (foo main) => "foo/_main.sls",
(foo _main) => "foo/__main.sls", and so on.
I think I can live with this more than ^main^.
It should also be noted that PLT's implicit file name is supported
for libraries with a single-component name. I.e., PLT does not
having an implicit file name for longer library names like
I don't like that since many packages I have are already one level up;
meaning, all the problems that the implicit file are supposed to solve
will still be there. So, if we do adopt the implicit main, it should
be supported at all levels.