DEFSYSTEM : Design Proposals : Specification of an operation target, in the 'perform' function; more proposals, in tangent

Hello,

I consider, there must be a better means than this, feasible, a means by
which there may be presented a design proposal on a project -- presented,
to co-developers on a project.

(I consider, the proposal for such would be another proposal, tangential to
this one.)

Begging your pardon, if it jars as I try to get to the point -- rather,
points -- of this. 

I've approached what was my primary point to this, along the main thread of
this message.



% Exposition

I'd like to say, firstly, that I'm not yet far-familiar with Defsystem 4. 

Considering that ASDF has been used across numerous packages available via
the Debian package repository, and that ASDF seems to be "done",  and I'd
been considering as that "that was the end of it", I've used ASDF
conventions, when making system definitions.

I'm aware that one system definition facility may use the system-definition
files made for another.[1] 

In regards to what I had wanted to propose, firstly, on this message: 

I had been sketching-out a proposal for operations to be named INSTALL and
PACKAGED-INSTALL. I was doing this in part to the making of a PUBLISH
operation. This was predicated on the want for to use such as ASDF in the
management and publication of material to a web-site. (Then, it became
apparent that it might be of use towards the production and distribution of
software packages.)

It was during the process of sketching-out the matters, upon which I came to
consider that there is grounds for a propsal affecting how system
operations are performed.

I'll address the proposal onto the PERFORM function, such that is defined in
ASDF.


% Description

There is a prospect for the definition of a generic PERFORM function, in
such that would have a function signature like as so:

 (PERFORM TARGET SOURCE OPERATION)


In regards to the order of arguments in that lambda-list: I would propose
that ordering, in consideration of: 
- That PERFORM behaviors per components would be more variable than PERFORM
behaviors per operations (this, in consideration of standard method
dispatching). 
- Furthermore, the ordering, there, it would keep both of the TARGET and
SOURCE arguments in an ordering before the OPERATION argument -- "all
together, on one little subset"

In the operations of a standard method combination, that argument-ordering 
would have the SOURCE and TARGET arguments specialized-onto,  "after" the
OPERATION specializer.


In the lambda-list for that function, in comparison onto the PERFORM
function defined in ASDF (and on the assumption that there may be a
function to which ASDF:PERFORM would be analogous, and which would be
defined in Defsystem 4) there would be added the TARGET parameter. 

The TARGET parameter may be used for the representation of a target for a
multi-output-capable operation (e.g. INSTALL), as well as for a
single-output-capable operation (e.g. an operation occasioning the loading
of source code into the current Lisp image)

For example, one could define some methods, specialized like as follows:

(PERFORM HTML-FILE SGML-FILE INSTALL)
(PERFORM HTML-COLLECTION SGML-FILE INSTALL)
(PERFORM PDF-FILE SGML-FILE INSTALL)
(PERFORM SGML-FILE SGML-FILE INSTALL)

(PERFORM PDF-FILE LATEX-FILE INSTALL)
(PERFORM HTML-COLLECTION LATEX-FILE INSTALL)

The set of methods with the SGML-FILE SOURCE specializer could be defined as
to execute the shell-command, "jw", but executing it with some few
different command-line arguments, per each method.

The methods with the LATEX-FILE SOURCE specializer, I might not be able to
implement, well. I can read manual pages on shell commands, sure, but I am
not much familiar with LaTeX.



As for how the proposed sort of  PERFORM function would affect operations
for the compilation and loading of Common Lisp source components:

In order to apply a TARGET or a SOURCE object representing the current,
running Lisp image, one could define a special class for the
representation, or one could use the object NIL. I propose that NIL would
be used.


One could define methods on the proposed PERFORM function, specialized like
as follows.

(PERFORM NULL CL-SOURCE-FILE INSTALL) 
^ would be similar to ASDF (PERFORM LOAD-OP CL-SOURCE-FILE) .
^ would occasion the compilation and loading of the code represented in the
CL-SOURCE-FILE, into the current, running Lisp image


In how that would be operated:

(PERFORM PATHNAME CL-SOURCE-FILE INSTALL) 
^ would be similar to ASDF (PERFORM COMPILE-OP CL-SOURCE-FILE) .
^ would result in the compilation of the source file, with an output to the
given PATHNAME .
^ may result in the production of a file containing any output generated
during the compilation; that file may be given a pathname with a different
pathname-type, otherwise using the same values as the PATHNAME argument
value; that file may be generated in some implementation-specific kluding
on CL:DRIBBLE, or in a Defsystem4-local handling about output streams.


In regards to the loading of CL source components into a non-local lisp
process: More than the following would need to be proposed, but here may be
a point to it.

(PERFORM OUTBOUND-SWANK-SESSION CL-SOURCE-FILE INSTALL)
^ ?
^ would occasion the loading of the file into the image to which the
OUTBOUND-SWANK-SESSION is connected ?
^ might be tabled in implementation, as until a lisp image would be proved
to be able to be connected to another lisp image, via a SLIME-context SWANK
connection.


In regards to the building of CL core files:

(PERFORM CORE-FILE-REPRESENTATIVE SYSTEM INSTALL)
^ would occasion the activation of a lisp session running the core file
represented in the CORE-FILE-REPRESENTATIVE object
^ would occasion the loading of the SYSTEM into the resulting Lisp process


% Conclusion

I am aware that this proposal may appear to have been addressed rather "out
of the blue". I consider that that would not serve to obviate that this
proposal may be considered onto Defsystem development.

I consider that this PERFORM function, proposed, would really help  in
implementing some things I've been trying to implement, but which I've
found something of a hangup about, when trying to address it onto a
(PERFORM SOURCE OPERATION) pattern.

Given that Defsystem 4 might be regarded as being a system still in
development, I consider that this might be addressed without a massive
side-affect to systems implementors.

Considering projects, distribution of source code, and branching of the
codebase: It might be proposed if there would be initialized a branch on
Defsystem 4 - perhaps, a prototype for a Defsystem 5, if this would be
done, if - a branch, such that this proposal may be addressed onto. I would
propose as such, if the implementation of such a PERFORM function would
occasion significant incompatibility onto existing systems.

That I would propose this PERFORM semantics, before implementing it, and
before then presenting a patch for it, I consider: It is something like a
matter of project etiquitte (sp?), besides if it would be a part to a
normal systems-development process -- like, when given a matter of which
one would not be so certain, and/or a matter that (in implementation) may
broadly affect the existing implementation, then proposing it, before
endeavoring to implement the matter, in full.

I am aware that a formal systems development process, onto free/open source
projects, might appear to some as constituting a burden. I am aware that
the implementation of a procedural formalization might be approached in
such a manner that might occasion a burden, and might be approached in a
manner that would not.


I will admit that I have not worked within a formal software engineering
shop, but I am aware that some formal processes may be used in such. SEI's
Capability Maturity Model might stand to the making of one example of such.

I consider that if it would be fit for a privately-developed project, it
would be fit for a publicly-developed, FOSS project.

Then, that a part to an involving system may be more clearly operable by way
of a GUI than by way of a command-line, and that a GUI for such may be
implemented onto CLIM, I consider that that may stand as an end for
consideration.

I will have to get into the Defsystem 4 codebase, so as to demonstrate if
and how this proposal would be implemented. I consider, that should be
rather easier than either writing or reading this proposal.


Thank you.


--
Sean Champ


[1] Like in "Speaking on experience", I've made ASDF use CL-HTTP style
system definitions, onto a one codebase -- had done so, in order to load
CL-XML, but using ASDF (which I have been familiar with), using ASDF in
lieu of the CL-HTTP-style system definition facility used in CL-XML. 

It could be a tangential matter of proposal, to propose a next matter
(considering if this would not have been done, already, into Defsystem 4,
and perhaps it has been). I would like to put it to attention, while I have
my own attention to it : 

One may support the loading of "other-system" system definitions into a
Defsystem 4 environment; it might be fairly trivial to work-out. 

I expect that  it would involve some little work, in some
Defsystem-4-specific definition on macros, standard functions, and (as for
ASDF) generic functions; the operations, defined, would need to match the
behaviors made in other system-definition facilities,  but would do so, in
the environment of Defsystem 4. 

Then, as for the sake of the user, there could be some kludging involved, in
regards to symbol packages -- e.g. making the package name ASDF be, in
Defsystem 4, a nickname on an DEFSYSTEM-ASDF-COMPAT package. 

So, then, whether one would use Defsystem 4 or ASDF, one could still load an
ASDF system definition; when using Defsystem 4, one could load an ASDF
system as a Defsystem 4 system definition. Such would be the end of the
proposal.

Whether before or after that, there could be proposed: A system-component
editor (gadget?) onto CLIM.

I consider: that an object-oriented programming environment may serve to
support some conventions for system-to-disk access, in a resolution
different than that of 'the file'. One could simply (?!) encode/decode
slot-values onto blocks on a disk. That might serve to support some more
efficiency, in the loading of on-medium information into a CL programming
environment -- like, storing the parsed values, rather than storing the
thing to parse, again.

(There could be 'import' and 'export' operations, supported with that, as
for interchange of information across systems.)

I consider that a system definition facility may serve to establish, onto a
discrete portion of information,  establishing a "sense of 'file'"
regardless of how the information would be stored onto a storage medium.

I hope that these proposals may be worked out, in what manner of process and
in more form, henceforward. I consider it was not inappropriate, to have
raised the suggestions, now.



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV