Hello, Peter Van Roy <[email protected]> wrote:
> >> I believe the reasons is this: An URL can be any address involving
> >> "http", "ftp", local files and possibly other schemes. Often the
> >> contents at such an URL can be READ, but not WRITTEN. E.g. we can
> >> read from a WWW address but we cannot write to it.
> >> Therefore it makes sense to use URLs for reading and filenames for
> >> writing.
> >> In light of this, maybe Mozart should be changed to allow "stdin"
> >> as a valid URL.
...
> > So for now, it suffices to add in the functor File a function that
> > reads from stdin (something like {ReadListStdin ?L}).
> > It's a patch but I think it's the best (and maybe the only thing) I
> > can do so far.
...
> The bug is in File.oz: instead of reading from a URL using '{New
> Open.file init(url:...)}', the Read routines should read from a file
> using '{New Open.file init(name:...)}'. That fixes the problem,
> since 'stdin' is allowed as a file name. See the documentation for
> Open here:
> http://www.mozart-oz.org/documentation/system/node55.html#chapter.open
> I've fixed the version of File.oz on the Supplements Web site here:
> http://www.info.ucl.ac.be/~pvr/ds/mitbook.html (under heading 'Mozart
> system supplements') It's not a good idea to have 'stdin' as a valid
> URL, since this would introduce a dependency between valid URLs and
> valid file names. The Open module keeps URLs and file names
> completely separate.
But how about having something like init(url:...), init(name:...), or
init(stream:...), where the ellipsis after stream: could be stdin,
stdout or stderr?
For me, even having only init(name:<ressource>) would make sense, when
thinking of <ressource> as e.g.:
"http://..."; - have some HTTP ressource,
"file://..." - have some filesystem (accessible) ressource,
or even:
"webdav://..." - WebDAV ressources may be writable, but will have to be
retrieved from remote site first,
"mailto://..."; - send stream per mail,
and of course:
"stdin:", "stdout:", and "stderr:" - for the standard streams, and
"pipe:..." for reading from or writing to a command.
This mechanism in turn would need to have some basic or widely used
protocol types (file, http, ftp, ...) implemented and a way to
implement new protocol types.
Or (where, if so?) does this conflict with some idea of what Mozart/Oz
is thought to be?
Eckard
signature.asc
Description: PGP signature
_________________________________________________________________________________ mozart-users mailing list [email protected] http://www.mozart-oz.org/mailman/listinfo/mozart-users
