my scheme os...
cr88192
groups. I had allready posted something similar to comp.lang.lisp and few
there seemed to care.
also sorry as this may have been posted several times or may not have, I
don't know...
I am working on an os that has a scheme interpreter. the version on my site
is a little old, but it gives the basic idea...
currently I have better integrated some parts of the os and the
interpreter, and I am adding functionality to the interpreter.
comments related to general system organization would be appriciated.
for example I have decided to represent the system symbol space as a tree
of hash tables, with certain "processes" as leaves.
I have decided to have the security based on tags that may be present/not
present and control access to symbols based on predicates that may check
for tags, ... whether dynamic or lexical behavior of tags is better...
but really I don't know what I am doing in this respect and am interested
in others' comments on these issues, and also I have little cs background...
also I am wondering if anyone cares. from what I have seen some seem
interested in a lisp/scheme based os, but I have not heard much of how
people plan to organize it.
Thien-Thi Nguyen
> also I am wondering if anyone cares. from what I have seen
> some seem interested in a lisp/scheme based os, but I have not
> heard much of how people plan to organize it.
it is like the buzzing of insects on a summer day. if you put
your head in the right cloud they are everywhere, but if you're
zipping around on a motorcycle, only a few splat on your shades
(or helmet:
http://www.glug.org/people/ttn/trips/cc-we/Pix/helmet-bug-ridden-deer-lodge.jpg
:-) until you ride into the right cloud.
sometimes people express their care w/ the questions they ask.
what questions do you ask?
thi
cr88192
> it is like the buzzing of insects on a summer day. if you put
> your head in the right cloud they are everywhere, but if you're
> zipping around on a motorcycle, only a few splat on your shades
> (or helmet:
>
>
> :-) until you ride into the right cloud.
>
> sometimes people express their care w/ the questions they ask.
> what questions do you ask?
>
beyond looking like a basic scheme system what should it be?
systems get their "shape" from the underlying os, but what I have *is* the
os. I am lacking a clear design objective and thus am designing the system
on my own without real comment from others.
how do I know what I think will be a good design others will agree with?
given I do not have to use a real fs, then what do I use? I have designed
an object system, then a model for a dbms like system (vaguely resembling
both an odb and a rdb, with a prototype object system).
in this design objects were placed in sets, how then do I arrange the sets?
if I place them in a heirarchy then it is like a conventional heirarchical
fs, though with a more flexible structure (and the added weirdness that
each behaves like a namespace...).
because the interconnections are symbols then do I allow them to be placed
in a non-heirarchical structure, or require extra connections to be
"links". or do I require it to be a strict heirarchy.
do "symbols" have to be the only means of lookup, is it useful to be able
to lookup objects based on predicates (which is the basis of the db
model...)?
do I allow interset references?
so many questions...
Ulrich Hobelmann
you need
compatibility. So I suggest you hack this thing on top of Unix or
whatever you run.
in fact most Schemes are kind of operating systems, I think PLT also has
GUI and stuff.
If you have the thing running, you can put it in the kernel, and so step
by step leave
userland. But until then, why reboot?
For existing OSes of all kinds,you might want to take a look at
http://tunes.org/Review/OSes.html
Good luck, Ulrich
cr88192
> you need
> compatibility. So I suggest you hack this thing on top of Unix or
> whatever you run.
within scheme?...
getting my os to directly run unix code would be difficult anyways, as it
is not going in that direction.
> in fact most Schemes are kind of operating systems, I think PLT also has
> GUI and stuff.
but they still have the "shape" of the os they run on, ie: a symbol can not
be a file; a directory can not be a symbol space; a process is not data...
> If you have the thing running, you can put it in the kernel, and so step
> by step leave
> userland. But until then, why reboot?
but I have allready left userland... my os could boot long before it could
run scheme (a little over 2 months ago I had little more than a "hello
world" kernel, but once I picked it up again I could code much faster as I
knew more...).
I do not make disk images though, however it is straight forward enough to
make one (given I have a shell script for it). maybe when things slow down
I will start making disk images...
> For existing OSes of all kinds,you might want to take a look at
> http://tunes.org/Review/OSes.html
> Good luck, Ulrich
>
helpful comment, though I allready know of it.
luckily some of the little bits of design info on the tunes site help guide
my design process, so I am not totally original.
I allready have the kernel, the idea to put scheme on it came later...
my kernel was really very basic, and also my scheme interpreter is rather
basic (and early on). I am trying to embed scheme deep in the os.
over time they will be developed together and will hopefully be nicely
integrated...
there is the problem that if you use an allready existing system you are
stuck in general with the design of that system. building a scheme os on
top of linux/bsd/oskit... will end up with something to some extent
resembling a conventional os, thus limiting many design choices.
I am starting out with a kernel I wrote, and a scheme system I wrote, thus
I know how pretty much all of the system workings, and quite frankly I am
blowing of most of the more conventional os designs anyways...
since I am making a toy anyways why not go all out? it doesn't matter if I
finish it or not, and maybe if someone is interested they can take my
design and build it into something useful...
over my time I have come to a conclusion: I like coding; and I like trying
to make stuff that seems cool; if it is too hard then it is not fun and if
too easy then I finish it too quickly. however I don't like coding stuff
that is not cool and I don't really like working on others' projects...
yet I also want to make stuff that others will think is cool as well, and
this becomes a little more difficult.
so I guess this is just me...
otherwise I have everything else in my life, much of which I consider more
important but not all of it fun... then there is that I hope for and cannot
get. coding, albeit fun, does not give me happiness, which is another yet
harder to achieve objective (one can hope for happiness with someone but
there is a problem if it is not mutual...).
this is also just me...
cr88192
cr88192 <cr8...@hotmail.com> writes:
> how do I know what I think will be a good design others will agree with?
by defining the set of important opinions by others to be empty. from this
you know what you want (is all that counts), and can concentrate on refining
your tastes and improving your design accordingly.
but that's a long torturous route. be honest and precise! what is the
expected consequence of this greatly sought after "agreement"?
> do I allow interset references?
do you favor cross-cultural exchange?
thi
---- and my reply ----
>> how do I know what I think will be a good design others will agree with?
>
> by defining the set of important opinions by others to be empty. from
> this you know what you want (is all that counts), and can concentrate on
> refining your tastes and improving your design accordingly.
>
> but that's a long torturous route. be honest and precise! what is the
> expected consequence of this greatly sought after "agreement"?
>
I don't know.
if the design were generally balanced and flexible then that would be good.
however in my mind it is probably difficult for people to generally agree
on design issues.
in some ways I doubt my ability to do a competent job at designing things...
>> do I allow interset references?
>
> do you favor cross-cultural exchange?
>
yeah I guess...
just placing restrictions on the structure of the system would make things
possibly easier to manage. allowing things leads to a more flexible (but
possibly harder to implement) system.
really I want a clean math-ish type design, but instead I am thinking up
half complete designs and filling the holes as I go...
at the same time I am not really stopping to write down my designs so often
my designs exist more in memory than in written form...
I have written so many half assed versions of my designs, and really no 2
really say the same thing twice...
it is possibly that I just try to use design to try to figure what to code,
but instead I just code and it almost heads in its own directions. and at
the same time I want people to know I am doing something so that maybe I
will not feel like I am alone in my efforts...
I just try to ask questions hoping people will respond, even though I lack
any real questions to ask. this is probably just a crutch for the lack of
company I feel in my real life (even though I have a girlfriend I feel as
if she is distant and doesn't care...). given that real social life doesn't
work for me I try to make it up via usenet...
does anyone think I have come very far in what has been for the most part 2
months work so far...
Rob Warnock
+---------------
| I am working on an os that has a scheme interpreter. ...
| comments related to general system organization would be appriciated.
Also see the section in <URL:http://www.plt-scheme.org/software/mzscheme/>
that talks about MzScheme running on bare hardware:
MzScheme is available in kernel form for x86 machines,
which allows MzScheme to boot without the aid of a separate
operating system. The MzScheme kernel is based on the OSKit
<URL:http://www.cs.utah.edu/projects/flux/oskit/>.
The recently-reorg'd web site(s) make it a little hard to find, but this
link should work: <URL:http://www.cs.rice.edu/CS/PLT/packages/download/
103p1/mzscheme/mzscheme.i386-kernel.tar.gz>
-Rob
-----
Rob Warnock, 30-3-510 <rp...@sgi.com>
SGI Network Engineering <http://reality.sgiweb.org/rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: aaan...@sgi.com and zedw...@sgi.com aren't for humans ]
cr88192
> +---------------
> | I am working on an os that has a scheme interpreter. ...
> | comments related to general system organization would be appriciated.
> +---------------
>
> Also see the section in <URL:http://www.plt-scheme.org/software/mzscheme/>
> that talks about MzScheme running on bare hardware:
>
> MzScheme is available in kernel form for x86 machines,
> which allows MzScheme to boot without the aid of a separate
> operating system. The MzScheme kernel is based on the OSKit
> <URL:http://www.cs.utah.edu/projects/flux/oskit/>.
>
> The recently-reorg'd web site(s) make it a little hard to find, but this
> link should work: <URL:http://www.cs.rice.edu/CS/PLT/packages/download/
> 103p1/mzscheme/mzscheme.i386-kernel.tar.gz>
>
quite what I was thinking, mostly as from what I could tell it was not yet
tightly integrated with the underlying system (oskit), and it did not
appear that work was being done on it in its own right...
I may have been wrong though, as I had not messed with it much.
in any case it does not really effect much as I am working on my own
project...
I am realizing I will have to be more careful as my reader tends to mangle
crossposts...
had been looking and had realized that r5rs doesn't in much detail explain
the behavior of the symbol space and the ports. I may have to define those
a little more.
not to seem pessimistic but I am a little unimpressed with scheme's io
model, so I am thinking of looking into other scheme interpreters to see
how they have done it (not that I don't have my own ideas, I just want to
try to be compatible).
in my mind ports should be able to be created and used anywhere in code
(and this is how I design much of my software, however for most of my code
I have ended up designing my own io subsystem...), however r5rs seems to
have the idea that ports are unidirectional and only originate in the
system...
similar goes for symbol spaces which I imagine should be not too difficult
to manipulate. I don't know what other implementations have done in this
respect, so also I will look into it.
Nick Roberts
typed:
I think your project is really very interesting and truly worthwhile. To
help direct your efforts a bit better, I would make the following
suggestion: choose a specific application (or narrow application area) for
your OS. Clearly you want to choose something that will suit LISP/Scheme
particularly well, but of course that leaves quite a lot of scope!
You might like to get into robotics. It's something that is not too
difficult to do at a not-too-expensive level -- you can get simple robot
(e.g. arm) kits and the like to connect to your PC via a serial port -- and
this is an area of application that still has a 'hot' developing future, as
well as being fun! Medical robot systems look incredibly promising at the
moment (imagine a robot 'surgeon' intelligently controlled by a LISP-based
system). You probably know that just getting a three or four-part arm to
move to a certain place without hitting anything is a very complex
application in itself (thus suited to the talents of LISP). Remember, too,
that there many different kinds of 'robot', from washing machines to space
rockets.
You might like to get into reverse engineering. There are companies that
have legions of COBOL and other legacy code still running their vital
business systems. Imagine a computer system that could do things like:
analyse a suite of COBOL programs; display various graphical visualisations
derived from the analysis; automatically generate C (or other modern
language ;-) code that would do the same thing on a new computer; perform
really sophisticated automatic transformations, such as parallelisation.
People would beat a path to your door for that kind of system.
Then there is human linguistics. Create a system that can translate in a
sophisticated way from Spanish to Swahili. Or maybe you could create a
system that advanced on the science of speech recognition (I reckon that is
in fact quite possible for a sufficiently dedicated individual). In these
applications, getting speed out of your system is likely to be of key
importance.
Then there are whole fields of statistical modelling. Supposing a local
municipality wishes to build a new road system. How will it affect traffic
flow? You need a very sophisticated statistical ('stochastic') model. How
would the economy be affected by a tax increase? Ditto. Much scope there.
Reinvent the digital desktop. Invent a system to functionally replace the
WIMP desktop paradigm with something that: is much _much_ easier to
understand, learn, and use (for the total novice user); 'knows' about
things like people (and their names), addresses, telephone numbers, and all
sorts of real-world phenomena, and intelligently helps the user to
construct letters, memos, and to keep contact information and to manage
information in general; acts as an intelligent agent that is able to scour
the Internet for resources that will interest, be of relevance to, and aid
the user; can be used equally well with different user interface technology
(keyboard+mouse and screen, speech recognition and synthesis, gesture and
head-up display).
I suggest that by picking an actual application, you will provide the focus
and grounding that your project needs. Features and compromises can then be
directed by an actual relatively well-defined goal. I think this would
probably help you a lot. Obviously you would continue to develop your
system with an eye to wider application possibilities, but in those
situations where you are faced with the question "shall I do it this way or
shall I do that way", you can obtain your answer by considering your
'canonical' application.
In a similar vein, your project needs a good name, and a much more
accessible web site. Maybe find a friend to do the web site for you.
Hopefully some food for thought! Best of luck!
--
Nick Roberts
Maxim S. Shatskih
> model
Sorry, but what is "scheme" in this context?
Max
cr88192
> I think your project is really very interesting and truly worthwhile. To
> help direct your efforts a bit better, I would make the following
> suggestion: choose a specific application (or narrow application area) for
> your OS. Clearly you want to choose something that will suit LISP/Scheme
> particularly well, but of course that leaves quite a lot of scope!
>
I would have to gain a general understanding of those fields.
I don't have much knowlege about robots, but I do know about game ai's to a
minor extent.
code absorbtion is an interesting idea. I don't imagine it would be too
difficult as I would think such a thing would not be too much different
than a normal compiler (though avoiding code inflation would probably be
more difficult).
> Then there is human linguistics. Create a system that can translate in a
> sophisticated way from Spanish to Swahili. Or maybe you could create a
> system that advanced on the science of speech recognition (I reckon that
> is in fact quite possible for a sufficiently dedicated individual). In
> these applications, getting speed out of your system is likely to be of
> key importance.
>
don't know much about this.
> Then there are whole fields of statistical modelling. Supposing a local
> municipality wishes to build a new road system. How will it affect traffic
> flow? You need a very sophisticated statistical ('stochastic') model. How
> would the economy be affected by a tax increase? Ditto. Much scope there.
>
err...
> Reinvent the digital desktop. Invent a system to functionally replace the
> WIMP desktop paradigm with something that: is much _much_ easier to
> understand, learn, and use (for the total novice user); 'knows' about
> things like people (and their names), addresses, telephone numbers, and
> all sorts of real-world phenomena, and intelligently helps the user to
> construct letters, memos, and to keep contact information and to manage
> information in general; acts as an intelligent agent that is able to scour
> the Internet for resources that will interest, be of relevance to, and aid
> the user; can be used equally well with different user interface
> technology (keyboard+mouse and screen, speech recognition and synthesis,
> gesture and head-up display).
>
sort of the idea in a not so user oriented fashion...
> I suggest that by picking an actual application, you will provide the
> focus and grounding that your project needs. Features and compromises can
> then be directed by an actual relatively well-defined goal. I think this
> would probably help you a lot. Obviously you would continue to develop
> your system with an eye to wider application possibilities, but in those
> situations where you are faced with the question "shall I do it this way
> or shall I do that way", you can obtain your answer by considering your
> 'canonical' application.
>
ok, I think in terms of data, namely like that found in dbs...
the idea is to store the data in both a highly structured and flexible way,
and to keep performance up... at the same time trying to do this without
opening big security holes and giving users appropriate data but not more
and not less, and the ability to try and protect the system from possibly
malicous code.
this is however unfocused.
generally I end up worrying about "the general system structure". and as
stated elsewhere I am noticing details not really addressed by scheme (much
of how the things, ie: ports and namespace, are to be implemented).
I am thinking that namespace structure has the ability to have a major
effect on usability, and ports a major effect on implementation...
> In a similar vein, your project needs a good name, and a much more
> accessible web site. Maybe find a friend to do the web site for you.
>
a name is a more difficult problem...
"Special K"; "Model S"; "ITRM" (Improved Teqnique for Retinning Mirrors);
"HeadRoom" (relating to a show I liked when I was younger, along with "time
trax")...
I lack a really good idea for names...
I am not so excited about site maintainence myself, nor am I so hot on
writting down my design ideas. both of those things are needed though.
cr88192
>> model
>
> Sorry, but what is "scheme" in this context?
>
scheme is a member of the lisp family.
scheme's (more r5rs') idea of ports is that they are unidirectional and are
created only by certain functions. ie: open-input-file, open-output-file,
read-char, write-char, ... and there is not even really a facility to seek
in the file (not even "rewind" like in pascal). not to mention you can't
open a file for both reading and writting and also that when you open a
file for writting (on implementations I have used) the file is
automatically trauncated.
ports only originate in certain calls and there are no facilities for just
"creating a new port" and "binding interfaces to a port".
not to mention there are lack of facilities for general "data io", as r5rs
seems to assume one is only using text io.
from what I have seen most developed scheme systems go around this anyways
and provide better io facilities, ie: "open-io-file" and "seek".
in my own code I have in general been using my own io subsystems which are
used whenever I want to "stream" data from one part of code to another when
they are structurally seperated.
in my mind even posix's io model is a little weak (as point to point
communication can only be done using sockets or pipes, and pipes can only
be sent to other processes by forking...).
luckily most other parts of r5rs are not so weak...
where r5rs is the doc describing scheme...
Christopher Browne
>>> not to seem pessimistic but I am a little unimpressed with scheme's io
>>> model
>>
>> Sorry, but what is "scheme" in this context?
>>
> scheme is a programming language that close to the core of my design.
> scheme is a member of the lisp family.
>
> scheme's (more r5rs') idea of ports is that they are unidirectional and are
> created only by certain functions. ie: open-input-file, open-output-file,
> read-char, write-char, ... and there is not even really a facility to seek
> in the file (not even "rewind" like in pascal). not to mention you can't
> open a file for both reading and writting and also that when you open a
> file for writting (on implementations I have used) the file is
> automatically trauncated.
> ports only originate in certain calls and there are no facilities for just
> "creating a new port" and "binding interfaces to a port".
> not to mention there are lack of facilities for general "data io", as r5rs
> seems to assume one is only using text io.
>
> from what I have seen most developed scheme systems go around this anyways
> and provide better io facilities, ie: "open-io-file" and "seek".
That is surely going to be necessary.
R5RS is a sort of "minimal" definition; the notion that it is
expressive enough to directly represent all the sorts of I/O
abstractions you might want to consider using is just silly, and
pretending its adequacy in that context would be equally silly.
> in my own code I have in general been using my own io subsystems which are
> used whenever I want to "stream" data from one part of code to another when
> they are structurally seperated.
> in my mind even posix's io model is a little weak (as point to point
> communication can only be done using sockets or pipes, and pipes can only
> be sent to other processes by forking...).
>
> luckily most other parts of r5rs are not so weak...
> where r5rs is the doc describing scheme...
I would strongly agree with the other poster that pointed out that it
would be a good idea to pick an application that you want your
"SchemeOS" to be good at, and write it _for that application_.
If your goal is to have some abstract, platonic design that will be
"perfect for everything," you're likely to be doomed to a process of
continually recasting bits of the design every time you hear something
new.
And you'd likely never actually get _anything_ actually working; you'd
never get out of the "talking about design" phase.
You might look at the approaches Charles Moore has taken with Forth;
he has repeatedly redesigned his versions of Forth from project to
project, building systems highly attuned to the specific application
at hand. The result of one of those projects was the design and
implementation of perhaps the oddest microprocessor around, the
MuP-21, a 20 bit microprocessor. (You can buy evaluation kits for
this for about $350; it's that real!)
If you produce a system that is useful to someone for something, then
that's a _real_ metric of usefulness. Once the system works, it may
then be worth trying to get it do other useful things.
If the "metric of usefulness" is whether or not you like the
specification, that's not so likely to lead to accomplishing anything
useful...
--
(concatenate 'string "chris" "@cbbrowne.com")
http://www.cbbrowne.com/info/languages.html
"Microsoft OS's are good because they encourage Intel to produce
faster CPUs for the rest of us to run Unix on." -- George Dau
cr88192
> That is surely going to be necessary.
>
> R5RS is a sort of "minimal" definition; the notion that it is
> expressive enough to directly represent all the sorts of I/O
> abstractions you might want to consider using is just silly, and
> pretending its adequacy in that context would be equally silly.
>
really I will probably have to rewrite what I wrote of the ports stuff to
make it useful (I just made it a thin wrapper over my os' io system, which
will not work so well if the ports originate in scheme).
my ideas will require a not so thin wrapper over my os' io system, and
another wrapper to get my code to use scheme defined ports...
outside of scheme I use the term "streams" as in general that is a more
common term.
my general thought when looking at the r5rs io definition was "is this
serious?". I guess it is not totally.
I have been looking at details in some other implementations (mzscheme and
guile) to see how they have done some stuff.
as far as I can tell each system seems to have their own ways of doing
things, I could do similar but I hope either to be compatible with mzscheme
or guile.
>
> I would strongly agree with the other poster that pointed out that it
> would be a good idea to pick an application that you want your
> "SchemeOS" to be good at, and write it _for that application_.
>
well above os's and scheme the only thing I really have an interest in is
db's, and in a more subtle respect my designs seem to be being dragged in
that direction anyways...
> If your goal is to have some abstract, platonic design that will be
> "perfect for everything," you're likely to be doomed to a process of
> continually recasting bits of the design every time you hear something
> new.
>
> And you'd likely never actually get _anything_ actually working; you'd
> never get out of the "talking about design" phase.
>
is this what happened to tunes?...
I have had that experience before, luckily I have ways of preventing that:
eventually I settle on a design and in general refuse to change it unless
something *serious* comes up...
actually it is more: once I code it one way, I am not going to go and
rewrite it another way. ie: since I have allready written it as scheme I am
not going to go and rewrite it as something else.
since I usually implement something as I think of it at that time this is
in effect a limit on my number of redesigns...
> You might look at the approaches Charles Moore has taken with Forth;
> he has repeatedly redesigned his versions of Forth from project to
> project, building systems highly attuned to the specific application
> at hand. The result of one of those projects was the design and
> implementation of perhaps the oddest microprocessor around, the
> MuP-21, a 20 bit microprocessor. (You can buy evaluation kits for
> this for about $350; it's that real!)
>
don't know much about that. I would figure the design of the cpu would
probably resemble forth quite a bit, as from what I have seen forth would
not be too far above the cpu anyways...
personally I figure forth would probably be reasonably useful if used as
the basic design of a calculator or something (probably more competent than
a normal calculator).
I am calculating, I enter numbers that are pushed on the stack, then I hit
operation buttons and a few numbers are popped and the result pushed. just
in my mind this seems more competent than a normal calculator, as you would
not have to hit m+/mr, and not have to write out numbers on more complex
calculations... the only real requirement would be that you would have to
think in an in->out postfix type fashion, but that is not hard for me
(given all my assembler experience...).
> If you produce a system that is useful to someone for something, then
> that's a _real_ metric of usefulness. Once the system works, it may
> then be worth trying to get it do other useful things.
>
> If the "metric of usefulness" is whether or not you like the
> specification, that's not so likely to lead to accomplishing anything
> useful...
ok, for the most part I am making a toy anyways so it is no big deal...
if people could find my tool useful or interesting then that holds some
value.
Charles Perkins
at least something not so commonly tried... lately.)
It makes sense that you would have trouble organizing a Lisp operating
system. You don't have the pervasive example of Unix or Windows to demand
certain conventions be followed, such as a dev/ directory for devices, a
flat process ID structure with signals and PIDs, fixed device major and
minor numbers, a heirarchical structure for linear exported data structures
(i.e. files,) interrupt tables shared by all processes, non-persistent
application memory, and the system level/user level dichotomy...
Ahem. What I mean to say is that much of the structure of a modern operating
system is that way because people assume they must be that way, and by
starting out with a different base technology you can make different
assumptions.
You will not end up with a compatible system of course, so people who'll
want to port posix programs will have to look elsewhere. Which is fine,
because there are plenty of other operating systems that will host posix
programs for them.
In structuring your own system you'll want to address the same issues that
traditional operating systems do, which are: persistence, partitioning,
identification, scheduling, interrupts, multiplexing, import/export, and
access control.
Using a higher-order language like Lisp or Scheme means that you can rely on
the language to take care of some of these issues for you. Access control
and partitioning, for example--if all programs are coded in Scheme then you
don't have to give each program it's own address space, you can use static
scoping to partition data instead. In fact, everything can run at the
highest privelege level (supervisor mode) because all you have to do to
restrict access to dangerous functions is to make sure that those functions
aren't available to user-level programs. (You could hide them by shadowing
them with a function that does nothing, for example.)
As far as file systems go, how about just making memory persistent? Page
your address space in from disk when you start up and write it back out when
you shut down. If you want to break the 4 gigabyte barrier of a 32-bit cpu
you could modify your VM to have a tag that represents objects that are not
in memory and have to be fetched first before used... incidentally pushing
some other object out of memory and onto a disk sector somewhere in order to
make room for it. You could then use Scheme's lists, vectors, and hash
tables to make your own named heirarchical store of objects and you wouldn't
ever have to open a file again. For extra points you could implement
checkpointing, sweeping through memory every few minutes with your garbage
collector and writing changed bits out to disk so that at any point you
could just hit the reset button on your computer and you'd be able to boot
right back to the point where your computer was executing before the 'fault'
occured.
Clever use of call/cc will give you a threading system, and if you're really
good you can make it interrupt-driven and therefore pre-emptive.
I would do all of the above myself but I'm not convinced that Lisp is the
way to go. I've been reading way too much functional language propaganda
lately. But if I were to build an OS on Lisp or Scheme you can bet it
wouldn't be Posix compatible and there would be no C compiler anywhere in
sight. Just repeat after me: "We don't need no steenking linker..."
Good Luck!
Chuck
"cr88192" <cr8...@hotmail.com> wrote in message
news:ucosrvf...@corp.supernews.com...
cr88192
> (Or, at least something not so commonly tried... lately.)
>
> It makes sense that you would have trouble organizing a Lisp operating
> system. You don't have the pervasive example of Unix or Windows to demand
> certain conventions be followed, such as a dev/ directory for devices, a
> flat process ID structure with signals and PIDs, fixed device major and
> minor numbers, a heirarchical structure for linear exported data
> structures (i.e. files,) interrupt tables shared by all processes,
> non-persistent application memory, and the system level/user level
> dichotomy...
>
which is why I am getting caught up in the higher level stuff. just a
simple scheme interpretter on an os is not enough...
I have been looking for ideas in a few places: mzscheme, guile, and tunes...
slowly I hammer out a general structure.
> Ahem. What I mean to say is that much of the structure of a modern
> operating system is that way because people assume they must be that way,
> and by starting out with a different base technology you can make
> different assumptions.
>
> You will not end up with a compatible system of course, so people who'll
> want to port posix programs will have to look elsewhere. Which is fine,
> because there are plenty of other operating systems that will host posix
> programs for them.
>
unless someone writes a lot of code to emulate a c/posix environment, but
this would probably be slow and some things might be more difficult to make
work correctly (and pointers might be harder to emulate...).
> In structuring your own system you'll want to address the same issues that
> traditional operating systems do, which are: persistence, partitioning,
> identification, scheduling, interrupts, multiplexing, import/export, and
> access control.
>
luckily I have had a bit of experience fiddling with the linux kernel
internals, along with a few others.
some of the terms seem a little funny though.
> Using a higher-order language like Lisp or Scheme means that you can rely
> on the language to take care of some of these issues for you. Access
> control and partitioning, for example--if all programs are coded in Scheme
> then you don't have to give each program it's own address space, you can
> use static scoping to partition data instead. In fact, everything can run
> at the highest privelege level (supervisor mode) because all you have to
> do to restrict access to dangerous functions is to make sure that those
> functions aren't available to user-level programs. (You could hide them by
> shadowing them with a function that does nothing, for example.)
>
I have a badly described system that uses tags and access predicates to
control access.
I have been thinking of how this could be done efficiently on compiled
code, and there is kind of a question: variable resolution is allready
done, however a function may be called with varying security (as in my
design the security was dynamic). in compiling lexical would be easier,
though lexical security I imagine opens holes in some cases (calling a
function that does some secure thing).
I had also figured ways in which a function with certain access could give
it to code (in a lexical fashion), in order to allow code that would
normally not have that access to aquire it.
all in all a lexical security scheme would probably be more possible in
practice, though I will probably still have to go and look at how dynamic
variables are handled in compiled code...
some details still need to be worked out here.
> As far as file systems go, how about just making memory persistent? Page
> your address space in from disk when you start up and write it back out
> when you shut down. If you want to break the 4 gigabyte barrier of a
> 32-bit cpu you could modify your VM to have a tag that represents objects
> that are not in memory and have to be fetched first before used...
> incidentally pushing some other object out of memory and onto a disk
> sector somewhere in order to make room for it. You could then use Scheme's
> lists, vectors, and hash tables to make your own named heirarchical store
> of objects and you wouldn't ever have to open a file again. For extra
> points you could implement checkpointing, sweeping through memory every
> few minutes with your garbage collector and writing changed bits out to
> disk so that at any point you
> could just hit the reset button on your computer and you'd be able to
> boot right back to the point where your computer was executing before the
> 'fault' occured.
>
have planned something similar, though objects exist in "managers" which
are responsible for storage/retrieval. objects default to being placed in
the manager used in their binding environments and some ways of hopefully
balancing between storage managers will be helpful.
this area still needs a little planning.
objects have ids, plans are to implement these ids as special objects that
will hopefully trigger loading when they are encountered. storang them back
out will probably have to be done by the storage manager (after gc'ing if
still not enough memory is free).
this is also still just ideas.
as of present whatever objects just disapear whenever the system goes off.
> Clever use of call/cc will give you a threading system, and if you're
> really good you can make it interrupt-driven and therefore pre-emptive.
>
this is a good idea. had not quite thought about threading yet.
making it interrupt driven would probably not be hard as there is no real
hard barrier between the c and scheme code... (as since my last source post
the interface between scheme and c has been improved signifigantly, along
with much of the general workings of the scheme interpreter).
> I would do all of the above myself but I'm not convinced that Lisp is the
> way to go. I've been reading way too much functional language propaganda
> lately. But if I were to build an OS on Lisp or Scheme you can bet it
> wouldn't be Posix compatible and there would be no C compiler anywhere in
> sight. Just repeat after me: "We don't need no steenking linker..."
>
I myself am not really sure of functional programming, and from what I have
seen they look like they might be difficult to implement/use...
I can't really comment as my only real functional experience was a little
fiddling with "escher" until I realized I didn't quite understand what was
going on.
it might be worth looking into again as I have a little better
understanding of "how" it would work now (as I was fiddling with it before
I really encountered lisp...).
Charles Perkins
> > First of all, my hat is off to you for attempting something different!
> > (Or, at least something not so commonly tried... lately.)
> >
> thanks dude...
Hey, no problem. I've got plenty more opinions where these came from.
>
> > It makes sense that you would have trouble organizing a Lisp operating
> > system. You don't have the pervasive example of Unix or Windows to
demand
> > certain conventions be followed, such as a dev/ directory for devices, a
> > flat process ID structure with signals and PIDs, fixed device major and
> > minor numbers, a heirarchical structure for linear exported data
> > structures (i.e. files,) interrupt tables shared by all processes,
> > non-persistent application memory, and the system level/user level
> > dichotomy...
> >
> which is why I am getting caught up in the higher level stuff. just a
> simple scheme interpretter on an os is not enough...
Hey, the making the right decisions early can save you lots of effort later.
That scheme interpreter already does most of what you'll need, if you look
at it a certain way. Since you won't be able to draw on a huge body of code
developed elsewhere I'd suggest building in a few abstractions at the start
and then exploiting them to the hilt. Such as only having one namespace--the
same chains of environments that hold references to cons cells should also
hold, for example, references to process structures and window buffers so
you can use the same operation (set!) to kill a thread, close a window,
delete a file, etc...
>
> I have been looking for ideas in a few places: mzscheme, guile, and
tunes...
> slowly I hammer out a general structure.
>
I suggest you also check out squeak-nos where they're trying to make a
self-hosted smalltalk system. They have similar decisions to make.
> > Ahem. What I mean to say is that much of the structure of a modern
> > operating system is that way because people assume they must be that
way,
> > and by starting out with a different base technology you can make
> > different assumptions.
> >
> > You will not end up with a compatible system of course, so people who'll
> > want to port posix programs will have to look elsewhere. Which is fine,
> > because there are plenty of other operating systems that will host posix
> > programs for them.
> >
> unless someone writes a lot of code to emulate a c/posix environment, but
> this would probably be slow and some things might be more difficult to
make
> work correctly (and pointers might be harder to emulate...).
>
Speaking of pointers... (see below.)
> > In structuring your own system you'll want to address the same issues
that
> > traditional operating systems do, which are: persistence, partitioning,
> > identification, scheduling, interrupts, multiplexing, import/export, and
> > access control.
> >
> luckily I have had a bit of experience fiddling with the linux kernel
> internals, along with a few others.
> some of the terms seem a little funny though.
>
That's because I just made them up. You know what I mean though... all the
things that make a general purpose operating system more than just the bare
hardware. What people who try to make an operating system in Forth (cool as
it is) fail to materialize.
Consider making the structure of the environments you allow client software
to run in do your work for you. Programs will enter an environment throuth
the read function or through the command line... make a custom environment
for the application of that read which has a scope separate from your
system-level functions, and which interacts with the system with
system-provided 'safe' functions. They can't call any functions you don't
give them, and you don't give them any functions that would harm the system.
You can provide as a part of their envirionment a reference to a shared
store through which one program can communicate with others, and that'll
give you IPC.
In Scheme, if you can't reference it then it doesn't exist. And can't be
used against you.
The objects you move out to disk (unless they are leaf objects) will have
pointers to other objects that are live. You'll want to look up
pointer-swizzling in various papers and dissertations.
Hey, I'm not convinced that Functional is the way to go either, but lazy
programming appeals to me. Maybe that's because it fits well with my lazy
thinking.
Chuck
> --
> <cr8...@hotmail.com> <http://bgb1.hypermart.net/>
>
cr88192
> Hey, the making the right decisions early can save you lots of effort
> later. That scheme interpreter already does most of what you'll need, if
> you look at it a certain way. Since you won't be able to draw on a huge
> body of code developed elsewhere I'd suggest building in a few
> abstractions at the start and then exploiting them to the hilt. Such as
> only having one namespace--the same chains of environments that hold
> references to cons cells should also hold, for example, references to
> process structures and window buffers so you can use the same operation
> (set!) to kill a thread, close a window, delete a file, etc...
>
implemented as first class objects.
namespaces are planned to be implemented as first class objects. though
technically namespaces are just lists of symbols, I figured a
namespace was deserving of its own type (though thinking of it using "map"
for queries might be useful...).
>
> I suggest you also check out squeak-nos where they're trying to make a
> self-hosted smalltalk system. They have similar decisions to make.
>
might need to take a look.
>
> That's because I just made them up. You know what I mean though... all the
> things that make a general purpose operating system more than just the
> bare hardware. What people who try to make an operating system in Forth
> (cool as it is) fail to materialize.
>
probably having to do with the "down to the matal" approach of forth.
may seem odd but I figure forth could probably be used somewhere between
assembler and a higher level language.
from what little I have seen of forth it looks like it would be good for
that.
>
> Consider making the structure of the environments you allow client
> software to run in do your work for you. Programs will enter an
> environment throuth the read function or through the command line... make
> a custom environment for the application of that read which has a scope
> separate from your system-level functions, and which interacts with the
> system with system-provided 'safe' functions. They can't call any
> functions you don't give them, and you don't give them any functions that
> would harm the system. You can provide as a part of their envirionment a
> reference to a shared store through which one program can communicate with
> others, and that'll give you IPC.
>
> In Scheme, if you can't reference it then it doesn't exist. And can't be
> used against you.
>
my idea was more to use both, this is good for general seperation, but
there are drawbacks:
consider you have a general namespace tree (which is planned in my os).
if you can step along the tree and look at things and you can see the whole
system then there is allready a possible security hole...
if you can restrict access in a more controlled sense then you can prevent
such access.
this is useful for example: if loading untrusted extensions, though just
defining what they *can* use in a new environment would probably be more
secure.
I had once defined "scope locks", which would allow this (but without
necissarily requiring a new namespace).
usage would have looked something like:
(lock-scope (denies-tag 'ext) (let
((car car)
(cdr cdr) ...)
(grant-tag-form 'ext (
;some restricted code
))))
(define-pred x 0 (denies-tag 'ext)) ;a var inacessible to those with 'ext
though "key" would probably be a better term.
the idea is that also these will be applied to users to prevent what the
user can do, or to give special privlages.
requiring keys for access is probably a lot more sensible for security:
(define-pred y 0 (requires-key 'y-key))
>
> The objects you move out to disk (unless they are leaf objects) will have
> pointers to other objects that are live. You'll want to look up
> pointer-swizzling in various papers and dissertations.
>
maybe so...
my idea was that in general given a pointer the os could figure what
manager it belongs to and ask for the oid, or maybe ask the manager to send
over the object.
my gc works by just grabbing everything on the stack/roots that might be a
pointer, then it resolves what (if any) object is being referred to, if it
referres to some object it just grabs and possible pointers from that.
given for scheme objects: values are tagged; the system knows how they are
structured; so I figure it would not be too hard to follow the links and
figure what objects to aquire...
mostly I just need to figure some way to put objects referred to by static
objects in static storage so that objects don't just disappear.
in storage objects will just have oids where pointers would have been.
or did I miss something?
>
> Hey, I'm not convinced that Functional is the way to go either, but lazy
> programming appeals to me. Maybe that's because it fits well with my lazy
> thinking.
>
can't really comment there...
cr88192
> this is part of the idea. I do have some things though, ie: symbols,
> implemented as first class objects.
>
> namespaces are planned to be implemented as first class objects. though
> technically namespaces are just lists of symbols, I figured a
> namespace was deserving of its own type (though thinking of it using "map"
> for queries might be useful...).
>
I was sitting here and I was thinking: many things I would want to be first
class objects, though many things don't structurally need to be first
class objects.
I figured I would take the idea of a box and make it a "typed" box. the
idea is that on creation they can be assigned a type and treated as first
class objects.
I am sorry if I am missusing the term, but as far as I know this is the
concept.
>>
>> I suggest you also check out squeak-nos where they're trying to make a
>> self-hosted smalltalk system. They have similar decisions to make.
>>
> might need to take a look.
>
I couldn't find info about it.
>>
>> Consider making the structure of the environments you allow client
>> software to run in do your work for you. Programs will enter an
>> environment throuth the read function or through the command line... make
>> a custom environment for the application of that read which has a scope
>> separate from your system-level functions, and which interacts with the
>> system with system-provided 'safe' functions. They can't call any
>> functions you don't give them, and you don't give them any functions that
>> would harm the system. You can provide as a part of their envirionment a
>> reference to a shared store through which one program can communicate
>> with others, and that'll give you IPC.
>>
oh the other part of the comment:
my os currently can "read" scheme code from the shell (that is currently
the main means of input).
as of yet read has not been implemented in scheme, not has write. right yet
"read" is a c based parser that reads from a string, and "write" just dumps
out to the console.
the idea of transfering code between locations via the read/write functions
has been considered, but little has been done with that yet.
I have put a little thought into "slotted" objects, as mentioned elsewhere
I have planned a "prototype object system". I have before looked at clos
and the mzscheme object system, and in my mind clos looks like a cleaner
and simpler design (though I have not messed with the mzscheme object
system much).
notable differences will show up considering I don't have classes.
current plans are to implement objects as vectors with each slot being the
slot value (except 0 with points to the structure vector).
the structure vector has a 1 to 1 mapping with the data vector (and has
slot 0 being reserved). plans would be to have each member being a symbol.
then I decide if they should be their own type or created using a "box".
I plan to reimplement ports using slotted objects, as my current ports are
weak. with ports as slotted objects it would be straightforward to
define/extend port capabilities, and they could be worked on as objects (vs
being worked on in a port specific way).
worth noting is than in my object system one can alter the structure of an
object after it is created, so if needed one could implement a filter,
ie: by defining new fields to hold old handlers and replacing the handlers
with new handlers that do something and call the old ones.
one misc idea is that when fields are added they are added to the end of
the vectors and when deleted a hole is left, also that holes are reused
with care (mostly this is just an idea for compilation optimization, but
could effect space usage).
personally I consider my object system useful, and wonder why others don't
really do similar (outside of self and vbscript).
cr88192
cr88192 wrote:
> >> I suggest you also check out squeak-nos where they're trying to make a
> >> self-hosted smalltalk system. They have similar decisions to make.
> >>
> > might need to take a look.
> >
> I couldn't find info about it.
SqueakNOS is at
http://mathmorphs.swiki.net/9
Here's a page of LISP/Scheme based OSs
http://vip.hex.net/~cbbrowne/lisposes.html
George Morrison
Aberdeen, Scotland
cr88192
cr88192 <cr8...@hotmail.com> writes:
> personally I consider my object system useful, and wonder why
> others don't really do similar (outside of self and vbscript).
what do you use your objects for?
first class means they can be assigned to a variable and passed
around. first class means system introspection is sufficient to
identify the type of that object.
other people do similar already -- any vector ("virtual" table)
approach is essentially the same. if you can't see their work,
it's not because they didn't do it. (e.g., guile object memory
layout uses a mini-language which supports custom in-core structs
design. this means you can make damn well sure SOME-OBJ is in
SOME-ADDR which is a promising amount of control (from scheme no
less) of the machine.)
thi
cr88192
sorry, I can't really understand the source as I don't really know
smalltalk, it is good for them that they are writting it I guess...
> Here's a page of LISP/Scheme based OSs
> http://vip.hex.net/~cbbrowne/lisposes.html
>
seen this before, most looked dead or unimpressive.
it is just my hope that I can make something that is at least somewhat
impressive, or at least just something that I make.
otherwise I don't have much else to do...
thinking about it maybe a good specification on how such a system is to
be organized is in line (ie: much like posix...).
this would probably be somewhere where it would be useful to know a little
more about cs.
I guess general issues would be:
general organization/structure of data within the system;
spec for interaction of software with underlying devices (for which I am
ending up doing something similar to unix);
design for abstract interfaces/protocols;
design for gui subsystem; ...
personally I am facing far more design issues than implementation issues,
and maybe why I am putting more energy into design than implementation.
otherwise I could go and finish the scheme stuff (which on the r5rs front
needs macros and a bunch of the more misc functions...). ie: it would be
quite simple to implement "string?" and the like, but I have been
preoccupied with the design.
I am not really sure which is more important.
cr88192
(I am sorry for all of this but I am having to fight with my usenet reader)
Thien-Thi Nguyen wrote:
> cr88192 <cr8...@hotmail.com> writes:
>
>> personally I consider my object system useful, and wonder why
>> others don't really do similar (outside of self and vbscript).
>
> what do you use your objects for?
>
I was refering more to using the prototype object model.
it is probably just an odity of mine but I have never really liked the
class system used on more normal object models.
in my experience with games programming often you need particular fields
for a particular object/set of objects, but that was annoying as: to gain
new fields you have to define a new class. even worse was in java every
class was almost required to be defined in its own file (making large
amounts of overhead/annoyance for making very minor changes to something).
other cases you would take something (ie: a corpse) and alter it into
something else (ie: a zombie). the problem: the dead monster it was and the
zombie it is becoming typically have different classes, requiring the old
object to be removed and a new one put in place (thus complicating the
process of retaining info about what it was/had set up).
you couldn't just add new fields if they didn't exist, and you couldn't
change the class without creating a new object.
also I find having to create new objects for something or creating wrappers
annoying, as I would rather just alter the original object.
this kind of thing can sort of be done in c, but it is not really possible
in normal "oop". this is all probably just my personal bigotry though.
> first class means they can be assigned to a variable and passed
> around. first class means system introspection is sufficient to
> identify the type of that object.
>
well then in my view I was gaining the second objective.
in my designs most everything can be assigned to a variable and passed
around, but not allways can you define new types.
consider the objects from the last post, if an object is formed from 2
vectors then normally:
vector? someobj => #t
but what if I don't want that, and how would I really tell the diference
between a vector and an object in a straightforward manner.
I made a little tweaky feature to get around this, though objects (as
implemented so far) do have their own type, however now another feature was
added to assign types to objects.
this compensates for: since I don't have classes, I can't really do class
checking. though I don't really like classes I do like the ability to have
"types" for objects, thus I will need to think of a better way to to the "A
is a B" situation. how about member 0 of the structure vector referes to a
list of all the "types" this object can be passed as (inheritence
emulation).
> other people do similar already -- any vector ("virtual" table)
> approach is essentially the same. if you can't see their work,
> it's not because they didn't do it. (e.g., guile object memory
> layout uses a mini-language which supports custom in-core structs
> design. this means you can make damn well sure SOME-OBJ is in
> SOME-ADDR which is a promising amount of control (from scheme no
> less) of the machine.)
>
I saw that, then forgot about it. it was a cool little design though.
I think somewhere I tried to make something similar, but it varied in some
ways I can't really remember (I think it had fields that served as the
count of elements that followed or something).
I can't remember.
cr88192
>>this is all probably just my personal bigotry though.
>
> Smalltalk and Javascript at least.
>
was this intended as good or bad?
>>but what if I don't want that, and how would I really tell the diference
>>between a vector and an object in a straightforward manner.
>
> One view is to say that your programs do not, and should not, be able
> to tell if it's a vector. They only need to be able to tell that it
> has certain properties (e.g. components numbered 1 and 2), and methods
> (e.g. get component numbered n); being able to tell it is a vector
> would break the abstraction, and so be a bad thing. One may take this
> view, but of course, there are counter-arguments!
>
ie: that a lot of my current practice deals with being able to tell the
difference, or at least where being able to tell the difference is
important.
sure it is useful to be able to hide most of the details, but sometimes it
is useful to not hide details.
consider you have a list, elements in the list may be of different types,
and for the purpose of printing it is pretty useful to be able to tell an
object from a vector (or a list, or a string...).
>>thus I will need to think of a better way to to the "A is a B"
>>situation. how about member 0 of the structure vector refers to a
>>list of all the "types" this object can be passed as (inheritence
>>emulation).
>
> I suspect, following the above suggested philosophy, you only need,
> for each object, an inherent 'prototypes' property (a list of the
> object's prototypes). Instead of testing if "A is a B", you test
> (member (get A 'prototypes) B).
>
I guess this would work.
so the idea is that on clone (or a function that modifies the object's
structure), a new version of the object is made pointing to the old one...
though a list might be more obvious, it would use a little more space.
though a list would have the advantage that it would be more obvious, and
the space usage would be small (a member and 1 cons per object).
I probably should get back to working on it though...
cr88192
> On Thu, 2 May 2002 20:54:54 -0400, cr88192 <cr8...@hotmail.com> wrote:
>
>> >>this is all probably just my personal bigotry though.
>> >
>> > It certainly isn't! It's a bigotry you share with the designers of
>> > Smalltalk and Javascript at least.
>> >
>> was this intended as good or bad?
>
> Neither, really. I have many years experience, but my opinion on this
> subject is that you would have to have god-like powers to really discern
> whether this is a better or worse approach than the 'strongly typed'
> approach.
>
well, I don't really know either. however I know about what I like and thus
that is what I will implement.
implementing another object system (ie: a clos clone, would also work).
I figure the details of how it was implemented would have a notable effect
on the performance of given usage patterns.
this is design philosophy, and in my mind there is quite a bit of room for
variation (ie: compare the lisp and pascal families...).
>> ie: that a lot of my current practice deals with being able to tell the
>> difference, or at least where being able to tell the difference is
>> important.
>> sure it is useful to be able to hide most of the details, but sometimes
>> it is useful to not hide details.
>> consider you have a list, elements in the list may be of different types,
>> and for the purpose of printing it is pretty useful to be able to tell an
>> object from a vector (or a list, or a string...).
>
> I think the objection (that some people would make) to that would go: the
> printing program should simply call a 'print' method for the object, which
> would then print the object in a way appropriate to its type (or contents,
> or whatever); the printing program should not have to (and should not)
> know that the object is a vector or a string or whatever, because then it
> would have to be altered every time a new type is added; this way,
> whenever you add a new type, it must have a 'print' method and will then
> work with he printing program (the printing program will not have to be
> changed in any way).
>
> I suppose the counter-argument would be that if you add a new type and
> fail to give it a 'print' method, you will only find out at run-time, and
> even then only if the program happens to try to call the 'print' method.
>
so I guess this is a design philosophy as well.
just as you might want objects to print themselves, you might want to print
the same objects in a different syntax.
maybe a comprimise may be reached: slotted objects which have a 'print'
slot will be printed by calling that slot and otherwise will be printed by
a default printer (a slot dump).
consider hypothetically this approach were used to such an extreme that
integers had their own printers, in which case different types would be
needed, ie: for decimal and hex ints.
>> I guess this would work.
>> so the idea is that on clone (or a function that modifies the object's
>> structure), a new version of the object is made pointing to the old
>> one... though a list might be more obvious, it would use a little more
>> space. though a list would have the advantage that it would be more
>> obvious, and the space usage would be small (a member and 1 cons per
>> object).
>
> The idea is that when you create an object, you set its prototype(s) to
> the (usually specially defined for the purpose) object(s) which will give
> it the default methods and properties you want. The mechanism is: if an
> attempt is made to call a method or access a property of the object, first
> the object itself is searched for a method or property of the given name,
> if that fails its protoypes are searched (in order if there are many), and
> then their prototypes are searched, and so on. When cloning an object, you
> simply copy its prototype list. An object can be mutated dynamically by
> simply changing its prototype(s).
>
this is a slightly different implementation teqnique than I had planned.
I imagine this approach would be better when dealing with "high delta" type
objects, wheras I consider mine better for "low delta".
consider each object has data and structure, whenever an object is cloned
then just the data is copied, but when a field is added both are changed.
I figure that for the most part a cloned object will closely resemble its
parents (differing only in field values), but occasionally objects will
need to be modified.
as far as I can remember self was implemented in a similar fashion, but
really I don't know much about it.
>> I probably should get back to working on it though...
>
> Heh ;-)
>
usenet is using much of my coding time...
I was reading about "T", which seems to be a more defined and slightly
different scheme. some of the details don't quite match with my design
though, ie: t assumes a conventional fs...
I could use t as a "supplementary" design.
I am figuring maybe I might need to plan "the system in general".
cr88192
> cr88192 <cr8...@hotmail.com> writes:
>
>> other cases you would take something (ie: a corpse) and alter it
>> into something else (ie: a zombie). the problem: the dead monster it
>> was and the zombie it is becoming typically have different classes,
>> requiring the old object to be removed and a new one put in place
>> (thus complicating the process of retaining info about what it
>> was/had set up). you couldn't just add new fields if they didn't
>> exist, and you couldn't change the class without creating a new
>> object.
>
> Common Lisp provides the function change-class, that will preserve an
> instance's identity (and as many of its features as possible), while
> assigning it to a new class. So it's a problem that has been solved.
>
maybe I missed this when reading about clos. in my mind clos is one of the
better designed object systems I have seen.
most object systems don't seem so good however, so I consider this a rare
feature...
cr88192
exists...
functions I have so far:
new-object . slots - create new object with slots
clone-object obj - clones object obj
object-get-slot obj slot - gets value in slot from object
object-set-slot obj slot val - sets slot in obj to val
object-add-slots obj . slots - add slots to obj
I consider this to be a start. hell I have enough to reimplement ports.
I was thinking of making ports be objects with a few default feilds:
read-char; write-char; input-ready?; eof-object?; ...
considering generally increasing the competence of the io system.
I was remembering once using a language (a basic I think) and using record
based io, this has been something most other languages I have used have
lacked.
I can add this back into my core io system and also into the scheme io
system. I was considering making the possibility of records variable sized
but "just happening" to be uniformed sized on normal files. I think this
approach would allow for better message driven io...
one thing I was also remembering is that since there is was no "position"
in the record files that seeking was not necessary, in this case muliple
threads could do io and not have to use mutexes (on the caller level at
least...).
also cool is that it could probably be better applied to
non-stream/asynchronous devices as well...
I was thinking: how to deal with raw data? I could use strings or some
special raw data type... maybe "byte vectors", or some object that is
printed as a block of mime characters...
I could just implement all the things I am missing from r5rs though (ie:
macros, and all the misc funcs...).
cr88192
is taking a lot longer and is a bit larger than I had thought...
mostly it consists of a bunch of scheme extensions and some info about
organization. even if I don't finish my os this might possibly be useful
for someone writting similar.
hell it could probably also be used as extensions to a scheme interpreter
as well, I don't know.
cool is that my design allows multiple namespaces and something resembling
processes, and organizes my thoughts about security. then I wrote (lightly)
about my object system, and some other stuff...
at least it should be a whole lot easier to read than it was to write...
this time around I decided to try to use a word processor (so I can get
nice pagified output), however it is annoying as the one I am using keeps
crashing and whoever made it forgot some stuff (ie: undo).
I might have to switch over to a new program considering how bad this
(kword) is... it was nice (at first), but after a few hours it gets pretty
tiring. maybe there is a newer version that works better.
Thomas Bushnell, BSG
You might be interested in the Sky project.
cr88192
>
> You might be interested in the Sky project.
>
> http://www.becket.net:8080/cgi-bin/skywiki.pl?SkyWiki
>
there were some interesting ideas there. a while back I came up with 2 ui
designs, one I mildly talked about on usenet (a 3d gui), and another 2d one
that I didn't. the 2d one was very similar to what was described on the
site.
my design however looks at things different, as my design more looks at
things from the command line/repl type view. the symbol space is reasonably
important and is a larger part of the spec. other parts of the system are
smaller parts of the spec.
still it needs much work and the highlevel parts still need definition.
most of the other system details are not really included as that have not
really been worked out yet.
it looks like it got a little mangled but still should be readable...
I skimmed through and tried to clean it up a little...
though not much I will post what I have written so far:
------
General Language Features
Environments
environments will be composed of multiple "layers", each layer may contain
bindings. a binding is considered to exist in an environment if it is
defined in one of the lower layers, however bindings that exist above the
level of the environment will not be considered as part of the environment.
any environment can conceptually exist as the top level environment of a
running program.
I will define some functions:
environment? obj will return #t if obj is an environment
current-env will return an environment containing the current bindings
create-empty-env will create an environment containing no bindings
insert-env-bindings env env2 will insert bindings from env2 into env (where
changes to env2 will be reflected in env).
lookup-env-binding env sym lookup sym in env returning the value
create-env-binding env sym val create binding of val to sym in env
walk-env-binds env proc walk along env passing all visible bindings to
proc, proc will be a function accepting 1 argument (the variable being
looked at).
Namespaces
a namespace will be a path available for a symbol lookup. I will define
that multiple namespaces may exist and will be unique to a given thread.
the namespaces will be considered a list that is not necissarily bound in
the environment. each element in the list will point to a corresponding
namespace, or variable that references the namespace. the order of the
namespaces in the list will determine the search order (where the first
element is searched first). conceptually functions that modify the scope
will be considered as working on one or more of the environments in this
list.
get-namespace-list will return a list of the current namespaces
lookup-namespace sym will return the environment bound in namespaces as sym
insert-namespace-env env will insert env into the namespaces as the first
to search
bind-namespace-env sym env will create a binding in namespaces of env to sym
I will define some namespaces:
system-root this will be the root namespace of the system
working-bindings this will be the equivalent of the "current directory".
general-bindings this will be the general/system wide bindings (ie: r5rs
binds)
process-bindings this will be the current bindings for a given process/top
level
thread-bindings these will be local to the current thread/current lexical
position
thread-keys (optional) these will be the keys giving access to resources
however these will be considered optional and may vary between threads
Variables
variables will be considered objects that inherently bind a name to some
object.
variable? obj will return #t if obj is a variable
get-var-name obj will return a symbol naming obj
set-var-name obj name will set the name of obj to name
get-var-data obj will return the data of the variable
set-var-data obj data will set the data field of the variable
(optional extensions)
get-var-pred obj returns a predicate that controls access to obj
set-var-pred obj pred sets the predicate of obj to pred
other implementation specific features may exist.
Keys
keys will be the primary security measure in my design. the idea is that:
to access a variable one needs the predicate for the variable to evaluate
to true. the predicates will be forms that check the status of the keys
(and possibly some other features), and return either #t or #f for allow or
deny access.
keys will normally be defined in the thread-keys, but may also be defined
in the environment (in which case the keys will have a lexical behavior).
hopefully keys will be implemented in such a way that they cannot be copied
or forged easily (ie: an encrytpted symbol checksum and their own address).
keys will also have 2 states: active and inactive, an active key is used to
effect to outcome of predicates, whereas an inactive key exists to control
its own security.
on access to a key it also has a predicate that is checked to verify that
access is allowed. additionally any code that shadows vars also needs
access to a given variable in order to shadow it.
key-active? key returns #t if key is active
key-inactive? key returns #t if key is inactive
key-exists? key returns #t if key exists
with-key key thunk calls thunk with an active version of key
without-key key thunk calls thunk with an inactive version of key
key-activate key returns an active version of key
key-deactivate key returns an inactive version of key
Objects
I will define my design as having a "prototype object system". the idea is
that classes do not exist, and the way objects are created is either by
creation functions or clone. additionally objects may be modified by adding
or removing slots.
each object is considered as having so many slots, each slot has a given
name.
currently I define:
object? ob will return #t if ob is an object
new-object . slots defines a new object with slots
clone-object ob clones ob and returns the clone
object-get-slot ob slot gets slot from ob
object-set-slot ob slot val sets slot in ob to val
object-add-slots ob . slots adds slots to ob
Threads
threads are independantly executing objects. each thread has its own
namespace lists (but not necissarily its own environment).
thread thunk executes thunk in its own thread
thread-with-namespace thunk lst executes thunk with the namespace list
given in lst
System Organization
Environments Tree
the namespace system-root will be bound to the same environment in all
places in the system, but may not necissarily be bound in all threads.
in each environment a sub-environment may be referenced by creating a
binding for it in the parent.
an idea for a layout:
system-root shared root for the system
processes bindings for process environments
proc~d environments for each process
devices bindings for system devices
command place where various "commands" would be placed
r5rs all the generic data
program locations for each program to store persistent data
others may be added later.
additionally I will define : as being system-root.
I will define:
(define (working-env) (lookup-namespace 'working-bindings)))
(define (enter-env x) (bind-namespace-env 'working-bindings
(lookup-env-binding (working-env))))
(define (cd . lst) (map (lambda (x) (enter-env x)) lst))
these may be implemented differently.
Processes
each process will be a collection of threads that operates in its own space.
: processes proc~d where ~d is the "pid".
new-process returns the pid of a newly created process space
get-pid-env pid get the associated environment for a given pid
Craig Graham
Which version are you using? Latest version of KWord is 1.2.0 (for KDE3).
I'm using 1.1.1 (on KDE2.2.2) for wordprocessing , and it's not to bad
- don't see that many crashes (StarOffice/OpenOffice is much better, but
takes to long to load).
BTW. I've been following your ideas on making scheme the OS - wasn't that
sort of the idea behind Oberon (but with a Pascal derived different
language)?
LAters,
Craig.
--
You wish.
Joe Marshall
"cr88192" <cr8...@hotmail.com> wrote in message news:ud8pvr5...@corp.supernews.com...
> General Language Features
>
> Environments
> environments will be composed of multiple "layers", each layer may contain
> bindings. a binding is considered to exist in an environment if it is
> defined in one of the lower layers, however bindings that exist above the
> level of the environment will not be considered as part of the environment.
> any environment can conceptually exist as the top level environment of a
> running program.
>
> I will define some functions:
> environment? obj will return #t if obj is an environment
> current-env will return an environment containing the current bindings
> create-empty-env will create an environment containing no bindings
> insert-env-bindings env env2 will insert bindings from env2 into env (where
> changes to env2 will be reflected in env).
The ability to capture an environment (via current-env) coupled with the
ability to inject bindings (via insert-env-bindings) will make it impossible
to compile efficiently. The compiled code would have to do a deep search
for the variables each time and could not cache the values because
someone might inject new bindings.
(By the way, current-env has to be a special form because the environment
is not available at apply time.)
>
> Objects
> I will define my design as having a "prototype object system". the idea is
> that classes do not exist, and the way objects are created is either by
> creation functions or clone. additionally objects may be modified by adding
> or removing slots.
> each object is considered as having so many slots, each slot has a given
> name.
>
> currently I define:
> object? ob will return #t if ob is an object
> new-object . slots defines a new object with slots
> clone-object ob clones ob and returns the clone
> object-get-slot ob slot gets slot from ob
> object-set-slot ob slot val sets slot in ob to val
> object-add-slots ob . slots adds slots to ob
A `prototype' object system will be very difficult to make persistent.
(Each object is its own schema!) How would you define multimethod
dispatch in this kind of system?
cr88192
didn't think of that. really my os is running an interpreter so I might
miss some compile specific details.
in my interpreter the environment is available at apply time so I missed
that detail.
luckily those details are not used much and are not very important, so I
can just remove them.
>>
>> Objects
>> I will define my design as having a "prototype object system". the idea
>> is that classes do not exist, and the way objects are created is either
>> by creation functions or clone. additionally objects may be modified by
>> adding or removing slots.
>> each object is considered as having so many slots, each slot has a given
>> name.
>>
>> currently I define:
>> object? ob will return #t if ob is an object
>> new-object . slots defines a new object with slots
>> clone-object ob clones ob and returns the clone
>> object-get-slot ob slot gets slot from ob
>> object-set-slot ob slot val sets slot in ob to val
>> object-add-slots ob . slots adds slots to ob
>
> A `prototype' object system will be very difficult to make persistent.
> (Each object is its own schema!) How would you define multimethod
> dispatch in this kind of system?
>
actually the way I had it implemented the schema is shared until the
object's structure is changed, in which case a new one is created based on
the old one, and a reference to the old one is stored. for storage I had
figured they would probably be broken into a few pieces and reassembled on
load. I don't figure it would be too hard.
I didn't really think of multimethods though. some way of shoehorning
multiple lambdas into a single slot maybe?... it is my understanding that
multimethods conceptually require a form of static typing, which would also
be work (as my interpreter currently only has untyped lambdas).
ok, oo stuff is not my strong point (as I have not had much "oop"
experience...).
but hell, it is a draft spec, I can change whatever I want.
how about the design overall?
Joe Marshall
"cr88192" <cr8...@hotmail.com> wrote in message news:ud8ut64...@corp.supernews.com...
>
> but hell, it is a draft spec, I can change whatever I want.
> how about the design overall?
>
Sounds ambitious and fun. Have you read Jonathan Rees dissertation?
Jonathan A. Rees.
A Security Kernel Based on the Lambda-Calculus.
Ph.D. dissertation, MIT, 1995.
Reprinted in part as MIT AI Memo 1564, March 1996.
cr88192
that is pretty cool. though in such a scheme "system-root" would have to be
removed and programs environments would need to be created carefully.
I can't see why that couldn't be used in my design allready.
much of what was written in the spec is "half implemented" allready,
similar goes for r5rs. the writting of the spec was intended both to define
what I am making and help me decide what direction to go and how things
will be put together.
thinking about it I still did not think of an efficient way in which my
security scheme would be applied in compiled code. I could allways just use
the teqnique of having a few strategicly placed checks and leaving
everything else open (assuming that a compiler doesn't compile the checks,
ie: if a var's predicate is an empty list).
I had initially started out by writting a compiler for my os but gave up on
that because working with it was a *major* *pain*. an interpreter, though
massivly slower, is a good temporary option. I am trying to write the
interpreter internals in such a way that changing out parts to compiled
code shouldn't be difficult.
originally all the builins works sort of like mini evals, but since then I
have made it to where primatives work just like they were being called by
normal c code, also calling out of eval is not too much of a problem.
as of right yet I am not recoding the compiler as of how much of a pain it
would be right now.
a few bits of the interpreter (ie: the c to scheme interface) were written
in assembler as a few things (ie: building a function call from a list)
were not really straightforwardly possible in c.
ie, in c: you are calling a function that accepts a certain number of args
and you need to build the args list from something, ie: a list;
2 options: you can use a simple assembler fragment; you can use something
(ie: a switch statement) for all the numbers of args. I chose the first
(though the second might be more portable...).
cr88192
after several hours of bashing). I have concluded that I will probably have
to rewrite eval (and the horrid mess attached to it).
in the time I have been working on my interpreter I have often had to make
changes to eval (often taking the form of kludges to make stuff work).
lots of other nearby code was tied into the workings of eval (the
environments, much of the basic r5rs implementation, ...), and was tweaked
out accordingly.
in the time eval and everything around it (much of the interpreter really)
had become a horrid mess, but it still worked and I could mess with it.
I made a few minor changes in the core of the mess and now the whole thing
doesn't work right. I have found it quite difficult to follow the code to
try to locate bugs.
after this bashing I have concluded that eval is dead.
I will have to rewrite eval and all the systems that were tied to it, in
general this was a large chunk of the interpreter.
luckily I can probably do things better this time around, since I know a
little better how it works. also this time the environment will probably
not be based on eval (but the other way around...).
Andres Soolo
>> I will define some functions:
>> environment? obj will return #t if obj is an environment
That's not good. The following definition would comply:
(define (environment? obj)
#t)
>> current-env will return an environment containing the current bindings
>> create-empty-env will create an environment containing no bindings
>> insert-env-bindings env env2 will insert bindings from env2 into env (where
>> changes to env2 will be reflected in env).
>
> The ability to capture an environment (via current-env) coupled with the
> ability to inject bindings (via insert-env-bindings) will make it impossible
> to compile efficiently. The compiled code would have to do a deep search
> for the variables each time and could not cache the values because
> someone might inject new bindings.
One possible solution is to separate a certain set of 'global' bindings
from the 'local' ones and only allow that kind of generic mutation to
the 'global' environments. This allows for efficient compilation--
assuming that formal arguments and the variables created with (let...)
(for many systems, this is redundant) are considered to be 'local' and
it also allows some environments to be first-class objects. The downside
is additional complexity of the specification and a little loss of
orthogonality. You could have flat global environments, analogous to
Python's dictionaries or Perl's hashes, or you could allow them to be
multilayered too--for example, by implementing them internally as alists.
--
Andres Soolo <so...@ut.ee>
History books which contain no lies are extremely dull.
cr88192
> In alt.os.development Joe Marshall <prunes...@attbi.com> wrote:
>>> I will define some functions:
>>> environment? obj will return #t if obj is an
>>> environment
>
> That's not good. The following definition would comply:
>
> (define (environment? obj)
> #t)
>
I don't see the problem here, internally my design (after I have began the
major eval rewrite) can tell the difference between environments and other
stuff.
it will return #f if obj is not an environment.
>>> current-env will return an environment containing
>>> the current bindings
>>> create-empty-env will create an environment containing no
>>> bindings
>>> insert-env-bindings env env2 will insert bindings from env2 into env
>>> (where
>>> changes to env2 will be reflected in env).
>>
>> The ability to capture an environment (via current-env) coupled with the
>> ability to inject bindings (via insert-env-bindings) will make it
>> impossible
>> to compile efficiently. The compiled code would have to do a deep search
>> for the variables each time and could not cache the values because
>> someone might inject new bindings.
>
> One possible solution is to separate a certain set of 'global' bindings
> from the 'local' ones and only allow that kind of generic mutation to
> the 'global' environments. This allows for efficient compilation--
> assuming that formal arguments and the variables created with (let...)
> (for many systems, this is redundant) are considered to be 'local' and
> it also allows some environments to be first-class objects. The downside
> is additional complexity of the specification and a little loss of
> orthogonality. You could have flat global environments, analogous to
> Python's dictionaries or Perl's hashes, or you could allow them to be
> multilayered too--for example, by implementing them internally as alists.
>
I came up with a thought:
adding new ones as long as they don't shadow ones in lower environments
when they are used in the upper environments then there is no problem. I
had not planned to do that anyways.
also I had figured: when dealing with namespaces in this way if one
namespace is changed then it is possible for the bindings to be different
as well, thus symbol lookups would allways be needed.
my idea: thread-bindings and process-bindings are allways searched first,
and changes to these will result in udefined behavior (which in the case of
compiled code would be that the change is not reflected). also I might
define it that thread-bindings may contain an undefined value.
I could disallow access to these by defining that the predicates for these
are allways #f (except maybe to eval, define, let, and friends).
also an advantage would be that lexical and global keys would override
dynamic keys which I consider as clearing some things up.
it would be helpful if anyone has some better ways to handle
environments/namespaces...
cr88192
> adding new ones as long as they don't shadow ones in lower environments
> when they are used in the upper environments then there is no problem. I
> had not planned to do that anyways.
> also I had figured: when dealing with namespaces in this way if one
> namespace is changed then it is possible for the bindings to be different
> as well, thus symbol lookups would allways be needed.
> my idea: thread-bindings and process-bindings are allways searched first,
> and changes to these will result in udefined behavior (which in the case
> of compiled code would be that the change is not reflected). also I might
> define it that thread-bindings may contain an undefined value.
> I could disallow access to these by defining that the predicates for these
> are allways #f (except maybe to eval, define, let, and friends).
> also an advantage would be that lexical and global keys would override
> dynamic keys which I consider as clearing some things up.
>
> it would be helpful if anyone has some better ways to handle
> environments/namespaces...
>
resolved in one namespace is not tried in others, and all symbols have an
inherent namespace...
consider I have "lexical-bindings" which is managed by the
interpreter/compiler, by default symbols are resolved there.
now consider I also have "functional-bindings", these are also managed by
the interpeter.
however all symbol lookups inherently *only* go to lexical bindings. now
consider I add a reader syntax, say #' which means: lookup symbol in the
functional namespace, and lexical namespace is thus not checked...
now consider namespaces may only be extended, say by adding layers (where
even things like define are considered as adding layers, though technically
probably not). in this respect at a given time (ie: compiler/run time) a
given namespace is considered static, thus static symbol resolution may be
used.
I can make other namespaces work similarly.
however a dynamic namespace does not behave the same, niether really does a
flat namespace, so I will need to figure this out.
additionally I am figuring one can plop environments in a given namespace,
but I will consider these static at compile time.
actually this is probably just an obvious observation though...
Alex Shinn
cr88192> I plan to reimplement ports using slotted objects, as my
cr88192> current ports are weak. with ports as slotted objects it
cr88192> would be straightforward to define/extend port
cr88192> capabilities, and they could be worked on as objects (vs
cr88192> being worked on in a port specific way). worth noting is
cr88192> than in my object system one can alter the structure of an
cr88192> object after it is created, so if needed one could
cr88192> implement a filter, ie: by defining new fields to hold old
cr88192> handlers and replacing the handlers with new handlers that
cr88192> do something and call the old ones.
This is similar to Guile's soft ports, which lets you define ports as a
vector of procedures to use for reading/writing characters and strings.
With this definition you can define a procedural port that performs
whatever filter action you want, and chain any number of these together
- no need to modify the original source port at all.
This seems like a very simple but useful feature - do any other schemes
offer this ability? The CLOS-like systems could achieve this by making
port procedures generic, but that seems clumsy. Using srif-6 you can
get away with the following:
(define (port-filter1 in proc)
(let ((out (open-output-string)))
(proc in out)
(open-input-string (get-output-string out))))
;; apply any number of procedural filters to the data from `in' port
(define (port-filter in first . rest)
(let ((p (port-filter1 in first)))
(if (null? rest)
p
(apply port-filter p rest))))
;; helper proc to create line-based filters
(define (line-filter proc)
(lambda (in out)
(let loop ((line (read-line in)))
(cond ((not (eof-object? line))
(display (proc line) out)
(loop (read-line in)))))))
;; helper proc to create character-based filters
(define (char-filter proc)
(lambda (in out)
(let loop ((c (read-char in)))
(cond ((not (eof-object? c))
(display (proc c) out)
(loop (read-char in)))))))
;; example: rot13 stdin
(define (make-ceasar-char n)
(let ((table (make-string 256)))
(do ((i 0 (+ i 1)))
((= i 256) #f)
(string-set! table i (integer->char i)))
(do ((i 0 (+ i 1)))
((= i 26) #f)
(let ((shift (modulo (+ i n) 26)))
(string-set! table (+ i 65) (integer->char (+ 65 shift)))
(string-set! table (+ i 97) (integer->char (+ 97 shift)))))
(lambda (c) (string-ref table (char->integer c)))))
(define rot13 (char-filter (make-ceasar-char 13)))
(define p (port-filter (current-input-port) rot13))
but this is very inefficient and also requires the ports to be read all
at once. It seems to me that rather than string-ports, the basic unit
should be soft/procedural ports, with string-ports as the special case.
--
Alex
cr88192
> This is similar to Guile's soft ports, which lets you define ports as a
> vector of procedures to use for reading/writing characters and strings.
> With this definition you can define a procedural port that performs
> whatever filter action you want, and chain any number of these together
> - no need to modify the original source port at all.
>
illustrate some capability of my object system as applied to ports...
> This seems like a very simple but useful feature - do any other schemes
> offer this ability? The CLOS-like systems could achieve this by making
> port procedures generic, but that seems clumsy. Using srif-6 you can
> get away with the following:
>
I don't really know about that, I wouldn't really be supprised.
in my experience this kind of feature is quite useful, as ports/streams are
used as the basic form of communication.
I can make an interface between the scheme ports and my os' streams, but
they don't match too well and the interface would be clumsy/inefficient.
as of now I am rewritting the scheme system (right now though there are
distractions preventing me from working on it much...).
Rob Warnock
+---------------
| This is similar to Guile's soft ports, which lets you define ports as a
| vector of procedures to use for reading/writing characters and strings.
| With this definition you can define a procedural port that performs
...
| This seems like a very simple but useful feature - do any other schemes
| offer this ability?
MzScheme does. It calls them "custom ports":
<URL:http://www.cs.rice.edu/CS/PLT/packages/doc/mzscheme/node123.htm>
The make-input-port and make-output-port procedures create ports with
arbitrary control procedures:
(make-input-port read-char-proc char-ready?-proc close-proc
[peek-char-proc]) creates an input port.
...
(make-output-port write-proc close-proc) creates an output port.
...
Ports created by make-input-port and make-output-port are immediately
open for reading or writing. If the close procedure does not have any
side-effects, then the custom port does not need to be explicitly closed.
If you don't need to get control on *every* character, MzScheme also
provides "string ports":
<URL:http://www.cs.rice.edu/CS/PLT/packages/doc/mzscheme/node121.htm>
Scheme input and output can be read from or collected into a string:
(open-input-string string) creates an input port that reads
characters from string.
(open-output-string) creates an output port that accumulates
the output into a string.
(get-output-string string-output-port) returns the string
accumulated in string-output-port.
...
-Rob
-----
Rob Warnock, 30-3-510 <rp...@sgi.com>
SGI Network Engineering <http://reality.sgiweb.org/rpw3/>
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: aaan...@sgi.com and zedw...@sgi.com aren't for humans ]
cr88192
I have been doing a bit of info gathering pertaining to the
design/implementation of scheme interpreters (so hopefully I can write one
that is worthwhile).
also I had discovered: scheme seems to be an fpl; and I seem to be able to
figure out what is going on in fragments of haskel code (though not well as
I don't really know haskel).
keep in mind I will not change languages as I allready have too much effort
invested in scheme...
for possible future use I was considering the possibility that variables
could have multiple "names", ie: a print name; a graphic; and a spatial
location; maybe a text description; or whatever else might be realavent for
identifying the object. my idea is that a variable having the first 3 would
be equivalent to an icon in a gui, and that maybe there would be general
"containers" that plan to organize and display their objects in a certain
way, but the objects might display similar regargless of container... maybe
the containers could be layered or have pieces cut into smaller ones.
I am figuring it could be possible to have an ide by placing environments
in appropriate containers or similar.
in all possiblility though integration would not be that good, maybe one
goal would be to define in reasonable detail the interaction of the object
system and the gui, and maybe provide rather highlevel interfaces. hell
maybe (write-container '(some list of objects) some-container) or similar,
with the container adjusting itself for the objects placed into it.
this is of course assuming I have a gui...
Ray Dillinger
I was thinking I might share with you some of the things I've
been thinking about in terms of a programming environment -
you may find them useful when thinking in terms of an operating
system as well.
Basically, I've been thinking about the implications of treating
certain kinds of higher-order values (graphics, animations, sounds,
animations-with-sound, and 'interactive graphics' ) as their own
"types" in the set of disjoint top-level types in a scheme system.
With each having its own external representation, and amenable to
read-write invariance (well, the function references in interactive-
graphics would probably not be read-write invariant unless read
back by the same procedure that had written them). Animations-with-
sound get their own type because the synchronizations required
don't allow you to consider the sound and animation really
separately. Interactive-graphics would be a way of bundling a
graphic with an 'interaction map' that specified scheme procedures
to call and alternate images to show if clicked on, dragged,
dragged across, doubleclicked, given keyboard input, etc.
I have an opinion (which I know that lots of folks don't share)
that these types of values are fundamental units the same as text
and numbers, and ought to be part of the language's type system.
We have been coming up with one method after another of simulating
them with various abstractions and combinations of other kinds of
values, but the fact is they are a fundamentally different experience
and not really related to the things we've been using as abstractions
for them. They should be treated as entities in their own right with
ways to do everything you need to do without breaking the paradigm
of them just being values.
It could be done as libraries, of course, but I think it's more
fundamental than that. So I'm thinking, I guess, about a "niche
language" for UI or multimedia, based on scheme - maybe too far
out to be considered a scheme dialect, maybe not.
This would require an editor hack to display these values as graphics
in the source code (either themselves, or scaled-down selves with
"click for a closer look" functions, or in the case of sounds a
"play/stop/rewind" interactive-graphic with appropriately mouseable
and keyboardable buttons) instead of as character strings - the
external character representation would be pretty meaningless to
most people.
Of course, that's only the beginning of actually supporting these
types; next you have to have primitives that operate on them,
functions that create them according to various parameters, tools
to "draw" or "import", inserting them the same way keyboard input
inserts characters, functions that transform, compose and combine
them, etc. And then you get into functions like (layergraphic g1
g2 ...) that take graphics and produce a new graphic (interactive
or otherwise) made by treating each argument as one layer.
The entire desktop is nothing but one big complicated interactive-
graphic, composed according to layering rules from the interactive-
graphics (windows) of the programs that get started as child
processes of the one that puts up the desktop. In turn, it hands
each child process a few callback procedures that allow the child
processes to access information or make requests for particular
types of handling or operating system access.
When you can pass around, compose, and display multimedia objects in
your programming environment the same way you do text, there's really
not much difference between programming a command shell and programming
a windowing system. And for those who'd really like to erase the
distinction between the programming environment and the command shell,
that is possible with existing scheme systems and it could be done here
too. I had been thinking of a basically unix-like system, but a
language like this as the fundamental basis would simplify unix by
annihilating the distinctions between shell and windowing system,
stdin/stdout and gui programs, character streams and object streams,
etc.
Anyway, this was the original vision of the "Ocelot Project" - which
failed to attract the interest of anyone but me originally, got stuck
on a shelf for several years while I did a sixty-hour-a-week dotcom
trip, and has only recently come back off the shelf and into active
development again. I'm working at the moment on a simple compiler,
and with the near-term plan of just enjoying building a seriously
highly-optimizing compiler that does not require any C/C++
development tools - at all - to be fully useful and able to access
lowest-level hardware (and also has native support for Unicode,
full numeric tower, etc). The longer-term vision described above
will probably resurface when I am have this in a good shape, but
building the multimedia stuff is still years away. I am a slow
programmer when working in large complex systems, but I do enjoy it.
Bear
Frode Vatvedt Fjeld
symbolics and lisp-machines?
--
Frode Vatvedt Fjeld
cr88192
creating disjoint types in a scheme system is not too difficult, before the
last interpreter broke there was a facility for defining psuedo-disjoint
types, and guile has a facility for disjopint types.
a good system for defining the printers for various "surfaces" would
probably also be needed. many expect the types to be self printing, but I
have held that it is useful for a printer to choose how the object should
be displayed, but it is also useful for an object to provide its own
printer.
maybe they are checked in this order: object defined printer; default
surface printer; default type printer.
> It could be done as libraries, of course, but I think it's more
> fundamental than that. So I'm thinking, I guess, about a "niche
> language" for UI or multimedia, based on scheme - maybe too far
> out to be considered a scheme dialect, maybe not.
>
I figure whatever will be considered a scheme dialect if normal scheme code
will work in it...
> This would require an editor hack to display these values as graphics
> in the source code (either themselves, or scaled-down selves with
> "click for a closer look" functions, or in the case of sounds a
> "play/stop/rewind" interactive-graphic with appropriately mouseable
> and keyboardable buttons) instead of as character strings - the
> external character representation would be pretty meaningless to
> most people.
>
seems interesting, I had not thought of generating thumbnails of graphics
to be used in source, but had just figured inserting the full sized graphic
would be good enough.
> Of course, that's only the beginning of actually supporting these
> types; next you have to have primitives that operate on them,
> functions that create them according to various parameters, tools
> to "draw" or "import", inserting them the same way keyboard input
> inserts characters, functions that transform, compose and combine
> them, etc. And then you get into functions like (layergraphic g1
> g2 ...) that take graphics and produce a new graphic (interactive
> or otherwise) made by treating each argument as one layer.
>
maybe this sort of thing could be done, but combining layers I consider
useful for producing "static" output, or maybe something that is done in
the background.
> The entire desktop is nothing but one big complicated interactive-
> graphic, composed according to layering rules from the interactive-
> graphics (windows) of the programs that get started as child
> processes of the one that puts up the desktop. In turn, it hands
> each child process a few callback procedures that allow the child
> processes to access information or make requests for particular
> types of handling or operating system access.
>
I had imagined more like fixed size clippings of planes that contained
objects.
I think it should be possible to "scroll" a region over a plane to be able
to see/hide things, however some things might want to work on fixed size
planes as well.
one would take a clipping from one plane and set it with some position and
scale in another.
the desktop would just be a clipping of a plane that is projected on the
user's screen...
however in each plane each clipping could be treated as a layer as well...
> When you can pass around, compose, and display multimedia objects in
> your programming environment the same way you do text, there's really
> not much difference between programming a command shell and programming
> a windowing system. And for those who'd really like to erase the
> distinction between the programming environment and the command shell,
> that is possible with existing scheme systems and it could be done here
> too. I had been thinking of a basically unix-like system, but a
> language like this as the fundamental basis would simplify unix by
> annihilating the distinctions between shell and windowing system,
> stdin/stdout and gui programs, character streams and object streams,
> etc.
>
well, I had been considering in general blurring the lines between: shell;
text/code editor; word processor; gui; and code...
I see no reason why a wordprocessor like program cannot have little +/-
buttons to show/hide blocks of code, or maybe why code cannot contain
formatting.
ok, this is a little unfocused.
> Anyway, this was the original vision of the "Ocelot Project" - which
> failed to attract the interest of anyone but me originally, got stuck
> on a shelf for several years while I did a sixty-hour-a-week dotcom
> trip, and has only recently come back off the shelf and into active
> development again. I'm working at the moment on a simple compiler,
> and with the near-term plan of just enjoying building a seriously
> highly-optimizing compiler that does not require any C/C++
> development tools - at all - to be fully useful and able to access
> lowest-level hardware (and also has native support for Unicode,
> full numeric tower, etc). The longer-term vision described above
> will probably resurface when I am have this in a good shape, but
> building the multimedia stuff is still years away. I am a slow
> programmer when working in large complex systems, but I do enjoy it.
>
I am not a very fast coder either.
it might be interesting to take a look for useful info/code.
maybe when it gets more the time to design the gui I will try to
"formalize" the gui, much as I have tried the system/language in general...
still much definition is needed in this part of the system, along with a
new scheme interpreter.
Jens Axel Søgaard
> This would require an editor hack to display these values as graphics
> in the source code ...
Simple bitmaps are supported by DrScheme.
Screenshots:
http://www.htdp.org/2002-05-09/Book/curriculum-Z-H-8.html
http://www.cs.rice.edu/CS/PLT/packages/drscheme/tour/slide3.htm
--
Jens Axel Søgaard
Ray Dillinger
cool! when did this happen?
Bear
Jens Axel Søgaard
I don't know exactly. But I found this in a file named history:
Version 44: September 9, 1996
Engine:
Saving bitmaps fixed on all platforms; editor can now save
"inlined" images instead of only references to images
Version 0.23: August 23, 1995
Editor can display images (types depend on wxWindow compile flags)
Thus my best bet is: long ago.
--
Jens Axel Søgaard
Andreas Fuchs
> I have an opinion (which I know that lots of folks don't share)
> that these types of values are fundamental units the same as text
> and numbers, and ought to be part of the language's type system.
> We have been coming up with one method after another of simulating
> them with various abstractions and combinations of other kinds of
> values, but the fact is they are a fundamentally different experience
> and not really related to the things we've been using as abstractions
> for them. They should be treated as entities in their own right with
> ways to do everything you need to do without breaking the paradigm
> of them just being values.
I do share your point of view that these data representations
are a kind of type themself, but I would like to add a comment to your
(IMHO rather crude) image of media types like video, audio,
audio-and-video: How about multiplexing? Not only is video-and-audio a
type in its own regard, but so is video-and-subtitles-and-audio!
Scheme's lazy evaluation seems wonderfully well suited for this kind of
task. Selective demultiplexing of (video,>1 audio,subtitles-as-xml)
streams might even be beautiful with lazy playback functions. (-:
I am speaking of somebody who has done nothing in this field yet, but I
am interested in the Ogg Vorbis project, for one. They are doing a
stream protocol which supports multiplexed packet data substreams. If
you plan to do media types, I suggest you apply the lessions these
people learned into your project. (-8
Please keep the group (or at least, me) informed of the progress you
are making, it sounds like a great project.
--
Andreas Fuchs, <a...@acm.org>, a...@jabber.at, antifuchs
cr88192
> ok, to describe what I have been doing recently.
> I have been doing a bit of info gathering pertaining to the
> design/implementation of scheme interpreters (so hopefully I can write one
> that is worthwhile).
> also I had discovered: scheme seems to be an fpl; and I seem to be able to
> figure out what is going on in fragments of haskel code (though not well
> as I don't really know haskel).
> keep in mind I will not change languages as I allready have too much
> effort invested in scheme...
>
ok, I have put a little more work into compiler/interpreter. in now
compiles basic code into a opcode type format.
I was rather delayed as I have been feeling crappy most of the day and had
been caught up in the calling convention+tail recursion.
after a little thought I figured it out:
forms don't return, they only apply. a form sets itself up, computes its
args, then jumps to the closure body. the closure body does whatever,
cleans up, then returns.
a form can also just compute its args, shift its args on the stack to
occupy the space of the parent args, then jump to the closure in case of
tail calls.
only lambda forms return.
all this probably seems obvious and I should have realized it sooner, but
as stated earlier I have been feeling crappy.
if this were done in native code a little fudging would be needed to
interface with c code, but this is no big deal...
I am wondering if ebp is really needed, or if I can use it to point to the
closure. objects on stack can allways be referenced realative to esp (as
far as I can remember...).