Yoshimi
Connor Lane Smith
I didn't post here for a while because I wasn't sure whether the group
was still alive or not. But now there's been a couple of posts, hell,
why not?
A while ago I wrote about Yoshimi [1], a concept OS based on a
persistent purely functional virtual machine, which uses lazy
evaluation and type systems and so on to make an efficient,
user-friendly interface.
It's a bit old, and I hadn't heard of TUNES at the time (though I'd
read articles by people who were definitely inspired by it), but I
think you folks might be interested in some of the ideas.
So yeah, I hope this is of interest to someone out there. :)
[1]: http://lubutu.com/idea/yoshimi
Thanks,
cls
Cyril Jandia
Cyril Jandia
ideas in their intent; I believe both (your ideas and my questions)
also relate to TUNES' ambition to try broaden the vision and maybe
think less out-the-box as most other systems/designs do:
On identity and locality you write:
"Why is it that even with our data in the ‘cloud’,2 when we open an
application on our computer it isn’t available on our phone too? We
may be able to open a new browser tab, enter the same URL, then sign
in again, but there’s some sense of déjà vu
Everything you do on each device should therefore synchronise between
all devices. When you open a document on your desktop you ought to be
able to access it on your phone with a tap"
Just need you to confirm this: you are talking here of locality/
identity of computations/processing tools' intermediary or end result
artifacts, not about ongoing computations per se (also bound to a
location "in time", in addition to "space"), right?
On state/IO you write:
"With the exception of IO a purely functional language is entirely
deterministic, which means all other computation can be repeated at
any time and reach the same state. Therefore only IO must be logged to
guarantee persistence; anything else is just computational cache."
Again, please confirm (or clarify/elaborate): it's only about the
state of the serialization (bits) of computations artifacts on a
persistent media specifically, e.g., (as opposed to *also* embracing
transient ones, e.g., wires, volatile RAM, etc), right?
On tools you write:
"Yoshimi would use an alternative paradigm whereby all ‘files’ (or
equivalent) would each have a certain visual representation used to
render it on-screen. A PNG, for instance, would represent itself as
the image it encodes. There would be no image viewer; rather, any
window’s sole purpose would be to decorate the borders of such an
object’s visual representation. However, the same representations
would be capable of being nested within others, as in compound
documents common to word processors.
A tool can by extension be considered a function which deals with
these objects. You may choose to horizontally flip an image, which
would be a function of type (Image a ⇒ a → a), which would take an
image and return the image having been flipped."
This is what I attracted my interest, where we're maybe mostly talking
about the same opportunity aspects for a different approach, though
thru different angles. What do you think about rephrasing your
paragraph there by going even further (closer to my pov's angle,
obviously) and using "phrases (of a language)" wherever you use
"object", "transform" instead of function, intent-purpose instead of
type, and thus:
"[...]A tool can by extension be considered a (structured collection
of) transform(s) which deals with these phrases. You may choose to
horizontally flip an image, which would be a transform of intent-
purpose (Image a ⇒ a → a), which would take a phrase of Image language
and return the phrase having been flipped (thru the intent-purpose of
aforementioned transform)".
?
This is of course not just a coincidental or innocent change of
vocabulary/terminology, there: we could, I believe, devise a set of
useful, further desirable intensional properties out of these notions,
once they're agreed upon (assuming that my idea of making languages
and language instances, that is phrases, first class, and not just
computations does make sense to you, beforehand)
'Hth,
> Thanks,
> cls
Connor Lane Smith
I find it difficult to parse your writing style, so I might
misunderstand your questions, but I'll do my best. Sorry! ^^;
On 28 July 2011 09:08, Cyril Jandia <cyril....@gmail.com> wrote:
> Just need you to confirm this: you are talking here of locality/
> identity of computations/processing tools' intermediary or end result
> artifacts, not about ongoing computations per se (also bound to a
> location "in time", in addition to "space"), right?
What I mean is, all state available to the user should be available
wherever they may be. So it honestly doesn't matter where computation
actually happens, but if the user can see something they ought to be
able to see it on whichever screen they have with them. So yes, it's
about the "end result" (insofar as what one can see is an "end
result").
> Again, please confirm (or clarify/elaborate): it's only about the
> state of the serialization (bits) of computations artifacts on a
> persistent media specifically, e.g., (as opposed to *also* embracing
> transient ones, e.g., wires, volatile RAM, etc), right?
Yes; the system would do all its computation and so on, making sure to
log important IO like mouse clicks, keyboard taps, etc, and so long as
you store that information everything else that has happened can be
determined from that input: nothing in a computer happens that can't
be later recovered by repeating the exact same processing, except for
IO.
So you have state in memory, just like any process does, but it only
*needs* to store IO information on persistent storage. Any other
information that is stored to disk is just a kind of helpful but
redundant cache. Naturally volatile memory like RAM and so on would
need to store other information, but the point is that by storing IO
logs on non-volatile media we can pull out the machine's PSU, plug it
back in, and we've lost nothing but a little determinable computation.
> This is what I attracted my interest, where we're maybe mostly talking
> about the same opportunity aspects for a different approach, though
> thru different angles. What do you think about rephrasing your
> paragraph there by going even further (closer to my pov's angle,
> obviously) and using "phrases (of a language)" wherever you use
> "object", "transform" instead of function, intent-purpose instead of
> type
I'm not sure what you mean by this. By 'object' I more accurately mean
'typed data value', in the sense that one might have a PNG type, which
is an instance of the type class Image; it can therefore be used as an
input to the function horizontalFlip, which would then I suppose
'transform' the PNG into another PNG. The internals of how that works
are irrelevant, so long as the PNG defines what 'horizontalFlip' means
in the context of a PNG. If you've used Haskell you might understand
what I mean; it's fairly difficult to explain otherwise.
Thanks,
cls
Cyril Jandia
On Jul 29, 9:30 am, Connor Lane Smith <c...@lubutu.com> wrote:
> Hi,
>
> I find it difficult to parse your writing style, so I might
> misunderstand your questions, but I'll do my best. Sorry! ^^;
> On 28 July 2011 09:08, Cyril Jandia <cyril.jan...@gmail.com> wrote:
>
> > Just need you to confirm this: you are talking here of locality/
> > identity of computations/processing tools' intermediary or end result
> > artifacts, not about ongoing computations per se (also bound to a
> > location "in time", in addition to "space"), right?
>
> What I mean is, all state available to the user should be available
> wherever they may be. So it honestly doesn't matter where computation
> actually happens, but if the user can see something they ought to be
> able to see it on whichever screen they have with them. So yes, it's
> about the "end result" (insofar as what one can see is an "end
> result").
I'm interested in as well.
> > Again, please confirm (or clarify/elaborate): it's only about the
> > state of the serialization (bits) of computations artifacts on a
> > persistent media specifically, e.g., (as opposed to *also* embracing
> > transient ones, e.g., wires, volatile RAM, etc), right?
>
> Yes; the system would do all its computation and so on, making sure to
> log important IO like mouse clicks, keyboard taps, etc, and so long as
> you store that information everything else that has happened can be
> determined from that input: nothing in a computer happens that can't
> be later recovered by repeating the exact same processing, except for
> IO.
>
> So you have state in memory, just like any process does, but it only
> *needs* to store IO information on persistent storage. Any other
> information that is stored to disk is just a kind of helpful but
> redundant cache. Naturally volatile memory like RAM and so on would
> need to store other information, but the point is that by storing IO
> logs on non-volatile media we can pull out the machine's PSU, plug it
> back in, and we've lost nothing but a little determinable computation.
computation and (ii) its original input and expected output the same
way I do: without wanting to decouple completely their design intent
from their purpose (in implementations, when the transformations
occur), you still want them loosely coupled and not be forced to know
about the full history of rewritings that had to occur between the
points in time and space for the notation domains and codomains you're
interested in.
> > This is what I attracted my interest, where we're maybe mostly talking
> > about the same opportunity aspects for a different approach, though
> > thru different angles. What do you think about rephrasing your
> > paragraph there by going even further (closer to my pov's angle,
> > obviously) and using "phrases (of a language)" wherever you use
> > "object", "transform" instead of function, intent-purpose instead of
> > type
>
> I'm not sure what you mean by this. By 'object' I more accurately mean
> 'typed data value', in the sense that one might have a PNG type, which
> is an instance of the type class Image; it can therefore be used as an
> input to the function horizontalFlip, which would then I suppose
> 'transform' the PNG into another PNG. The internals of how that works
> are irrelevant, so long as the PNG defines what 'horizontalFlip' means
> in the context of a PNG. If you've used Haskell you might understand
> what I mean; it's fairly difficult to explain otherwise.
but you keep looking at the artifacts, there, in a pretty conservative
way: you assume the relevance and accessible knowledge about an inner
lingua franca expressed in terms of types and instances of those
types.
As I see it, it brings you/us the risk of having "soon" to have to
decide about the most suitable/unifying type system that will help
support whatever higher level schemes applications will want to
implement. On my side, the "bet" I'm making in my elaborations
elsewhere in the thread is it's (maybe) useful to dare having a new
look in that respect as well.
Instead of being dependent upon that sort of "type system shape-
driven" design choice, which binds you tightly and for long
afterwards, I'd like to think these computation animals in terms of a
formal language system (vs type system), where languages are seen as
first class (vs. types), and of the "purpose" the syntactical phrase
forms encountered (vs. objects or type instance). Where phrases
"tagged" by the platform (TUNES, WWW) AND the programmer as belonging
to this or that language, and to rely on the same platform to query
about them: design intent of the reified language (fundamentally
computation context-free) and purpose of the language phrases
(fundamentally context-bound).
> Thanks,
Thank you for sharing.
> cls
CJJ
Hendrik Boom
> Hi again,
>
> On Jul 27, 7:33 am, Connor Lane Smith <c...@lubutu.com> wrote:
> > Hi all,
> >
> > I didn't post here for a while because I wasn't sure whether the group
> > was still alive or not. But now there's been a couple of posts, hell,
> > why not?
> >
> > A while ago I wrote about Yoshimi [1], a concept OS based on a
> > persistent purely functional virtual machine, which uses lazy
> > evaluation and type systems and so on to make an efficient,
> > user-friendly interface.
> >
> > It's a bit old, and I hadn't heard of TUNES at the time (though I'd
> > read articles by people who were definitely inspired by it), but I
> > think you folks might be interested in some of the ideas.
> >
> > So yeah, I hope this is of interest to someone out there. :)
> >
> > [1]:http://lubutu.com/idea/yoshimi
>
> So, here are my first couple questions to make sure I follow your
> ideas in their intent; I believe both (your ideas and my questions)
> also relate to TUNES' ambition to try broaden the vision and maybe
> think less out-the-box as most other systems/designs do:
>
> On identity and locality you write:
>
> "Why is it that even with our data in the ‘cloud’,2 when we open an
First, most peoples' data isn't in the cloud, it's on their home ocmputers.
> application on our computer it isn’t available on our phone too? We
Second, most people's home computers son't make their contents available
on the net. And their ISPs wouldn't let them if they tried -- they
don't like their home customers running servers.
And so most software doesn't provide this functionality, which limits
demand for such network services from ISPs.
> may be able to open a new browser tab, enter the same URL, then sign
> in again, but there’s some sense of déjà vu
> Everything you do on each device should therefore synchronise between
> all devices.
Which why I run my own server, pay for a network service that allows
this, and use a distributed revision control system (monotone) to make
it all accessibel on those devices capable of running it.
> When you open a document on your desktop you ought to be
> able to access it on your phone with a tap"
>
> Just need you to confirm this: you are talking here of locality/
> identity of computations/processing tools' intermediary or end result
> artifacts, not about ongoing computations per se (also bound to a
> location "in time", in addition to "space"), right?
There's also security concerns if your phone falls into the wrong hands.
-- hendrik
Connor Lane Smith
> First, most peoples' data isn't in the cloud, it's on their home ocmputers.
"Most people" being whom? Most people are still using Windows XP. It's
a question of demographics.
> Which why I run my own server, pay for a network service that allows
> this, and use a distributed revision control system (monotone) to make
> it all accessibel on those devices capable of running it.
Our ability to compromise does not mean the problem has been solved.
> There's also security concerns if your phone falls into the wrong hands.
Concerns solved by cryptography.
(I can go into greater detail if you'd like.)
Thanks,
cls