Hi Jonathan et al,
There are only a few items on this list that I feel qualified to comment
on -- and unlike Jonathan I will let that dictate the extent of my
contribution :-))))
> >5. Native image (file format) import, export, manipulation
>
> > be able to read and write image files in a wide variety of formats.
>
>
> JPEGs, GIF, TIFF, maybe BMP, PICT. What else? AutoCAD? PhotoCD?
> Each of those has many sub-formats.
>
> While we're at it, how about MPEGs, AVI, Quicktime too?
>
> I think I have to disagree, simply because of the size of the job. Or,
> rather, I think it should be postponed until the poplog empire
> has 50,000 employees.
>
> In the meantime, being able to read and write images in a couple of
> formats would be nice. I suggest JPEG and GIF
PNG would be better than GIF -- no royalties to pay to Unisys...
> I think the solution might be to emulate the kind of "plug-in" API
> used by browsers and some other kinds of software, both commercial
> and shareware. Presumably these APIs are less of a moving target, and,
> if done right, a new version of the plug-ins ought to plug-in without
> even changing anything in poplog.
Absolutely. That seems to be the way things are done these days -- to
specify an interface for, say, image-format plugins and then have someone
else implement them for you.
> I would like proper typed variables in poplog. Yes, truly.
>
> I've got used to using typed languages, and I no see no advantage
> whatever in pop11's untyped variables. (Ditto for lisp, incidentally.)
>
> If there are any advantages, someone remind me.
I entirely agree. The most flexibility I find I need these days is the sort
provided by C++, in which a variable can be declared as a base class type
and can then point to any object of a type derived from that. At least that
way the compiler can check that what you propose to do to the thing vaguely
makes sense (in that there's some virtual function that could be called for
the thing, whatever it turns out to be). That's about as untyped as I would
want to get (although I see your point about "list" vs. "list of integers".
C++ solves this kind of problem by using templates, which doesn't seem quite
right to me; much more code than feels right gets generated in order to work
within the typing constraints.) I suppose that one other advantage of
untyped variables is that your number of temporaries for each function can
be lower due to improved variable reuse, and so your implementation of
Poplog is more likely to be able to "registerize" them for you. But if this
is a consideration, it most probably means that your function is too big in
any case. I can't think of any other reason.
> (And the ability to
> use a variable without declaring it is a DISadvantage, not an advantage.)
Absolutely. As an undergraduate learning pop11, I switched this off as soon
as I knew how. As a more experienced programmer, I'm, er, "surprised" that
such a rich and fertile source of novice bugs is touted as a feature :-)))
> >15. CGI toolkit
> >
> > This project would provide a "lib cgi.p" that would let people
> > use Poplog for CGI programming. In particular, this project should
> > make it possible for UNIX people to write #! scripts easily. This
> > in turn requires support from the rationalised startup project.
>
> Too late, IMHO. CGI is the past. Servlets and server-side scripting
> languages are the way to go; or at the very least some kind of server
> process, accessed directly from the web-server. (We are talking at
> least 3-tier, in that case.)
CGI as a web technology would be waaaay too late now. And I'm not sure why
anyone would even want to do server-side scripting in pop11. Perhaps this is
an argument about the ease of producing stand-alone binaries that can be
called easily from other applications (like for example webservers).
Although for efficiency reasons you'd be better off implementing it as a
separate entity which served requests from the webserver. (Remind me: does
poplog make much use of multi-threading? Simple multi-threading extensions
would be a really neat addition if not.)
Jason
|