Re: [fonc] Other interesting projects?
Hi Chris, glad to have you around! On Sun, May 9, 2010 at 9:50 PM, Chris Double chris.dou...@double.co.nz wrote: On 10/05/10 04:59, Alan Kay wrote: There are already quite a few Smalltalk elements in Factor (and the postfix language itself (for most things) could be used as the byte-code engine for a Smalltalk (looking backwards) and for more adventurous designs (looking forward)). Factor already has a Smalltalk implementation (a parser and compiler to Factor code) that Slava did a while back as a proof of concept. I'm not sure how performant or complete it is however. Dan Amelang has been moving Nile to a really nice place, and it would be relatively easy to retarget the OMeta compiler for this (particularly the JS grounded one) to ground in Factor. Is there a Nile grammar somewhere? I tried searching for it and didn't come up with anything. I see Dan's github repository but it doesn't seem to include the Ometa definition. There is a preliminary version of the Nile grammar embedded in the Ometa-based Nile-to-C compiler in my nile repository. I hope to finalize (i.e., remove the ugly warts from) the Nile syntax in the next couple weeks. In addition, Alex and I have been working on the formal semantics of Nile. In the end, I hope to have both a small, clean language and a small, clean compiler for others to play with. I hope to pique your interest! Dan ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Other interesting projects?
FYI, there are some failed experiments left over in this grammar. Like the [ exprs:xs ] syntax for tuples and the whole idea of tuple reductions (e.g., ∧[ expr:x ]). Dan On Sun, May 9, 2010 at 11:02 PM, Alessandro Warth alexwa...@gmail.com wrote: Hi Chris, Here's the nile parser that I wrote in OMeta/Squeak. Cheers, Alex On Sun, May 9, 2010 at 9:50 PM, Chris Double chris.dou...@double.co.nz wrote: On 10/05/10 04:59, Alan Kay wrote: There are already quite a few Smalltalk elements in Factor (and the postfix language itself (for most things) could be used as the byte-code engine for a Smalltalk (looking backwards) and for more adventurous designs (looking forward)). Factor already has a Smalltalk implementation (a parser and compiler to Factor code) that Slava did a while back as a proof of concept. I'm not sure how performant or complete it is however. Dan Amelang has been moving Nile to a really nice place, and it would be relatively easy to retarget the OMeta compiler for this (particularly the JS grounded one) to ground in Factor. Is there a Nile grammar somewhere? I tried searching for it and didn't come up with anything. I see Dan's github repository but it doesn't seem to include the Ometa definition. Chris. -- http://bluishcoder.co.nz ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Public archives?
Hi, Is there some reason why the archives could not be public? I wanted to point out the extremely interesting pointers that have come up recently to some friends, but I'm left with the annoying choice between copying and pasting all the stuff myself, or requiring them to subscribe in order to read the archive (or doing something naughty like subcribing a bot to the list). It's a pity because the list has recently become a wonderful feast of links to the most interesting things. -- http://rrt.sc3d.org ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] An actor-based environment for prototyping
Hi Dale et al. This sounds like a great project, and I'd like to find out more. (Have you looked at David Reed's 1978 MIT thesis on distributed transactional object operating systems. In my opinion this was one of the very best next steps wrt objects (and it was influenced by Actors)). And you are right that Actors were closer to my original concept of objects. Actors came out of the first implemented Smalltalk (72) (which was very Actor-like) -- my notion of objects was heavily influenced by the ARPAnet and the soon to be Internet -- and Actors stayed with something more like this and were both a great next step from what we were doing at PARC, and also got to some of the theoretical issues better than we did. The drive at PARC was to invent and build personal computing, and to try to do it in a language that children could program in. (The former succeeded better than the latter.) After the first round of hardware and software design and implementation, Xerox was unwilling to fund the next logical machine after the Alto (eventually they did but too late), and this forced the fringe people (us) to have to optimize software for the first time (we had been making things run fast enough via HW). And this brought forth rather different versions of Smalltalk which were less adventurous than the original but much more practical (Smalltalk-76 was about 180 times as fast as Smalltalk-72). Carl Hewitt's research was not primarily aimed at building whole real-time systems, so Actors and Smalltalk diverged quite a bit. However, I still think the most interesting version of Smalltalk was 71 which was never implemented [1]. It was an attempt to combine my earliest notion of objects, LOGO, Carl Hewitt's most interesting work (PLANNER, which was the strongest influence on the later Prolog), and some of David Fisher's control definition ideas. This was what we called pattern directed invocation or call by desire. Smalltalk-72 was a weaker version of this, and it's hard to see at all in Smalltalk-80 (a programmer really has to want to program this way to do it). Also in [1] towards the end, is a discussion of how many improvements in software came from improvements in late binding, and that some of these eventually got put into HW to remove most of the inefficiencies that usually come with late binding something. When LINDA came along in the 80s, this got me thinking harder about the step to call by need. This was already in PLANNER as antecedent theorems (Prolog only tried to do the consequent theorems which have a control structure that allows backwards reasoning, and is rather similar to procedure calls). CMU had been doing considerable explorations into forward reasoning (OPS-5) with some terrific optimization mechanisms (Forgie et al). LINDA provided a kind of metaframework for pretty much building any kind of control structure and these could be driven by patterns. These allowed one to think about a kind of goal oriented publish and subscribe coordination mechanism in which no messages were sent (but in which messages were only received). One way to think of this is that each object has two bulletin boards. One has characterizations of needed resources, and the other has characterizations of resources made available by the object. These bulletin boards are now all put into a LINDA-like matching space which does the (considerable) work of brokering. If one could come up with a great way to express the characterizations, then one would have removed one of the difficulties of scaling a message sending system, by removing the need to know the name or IDs of the receivers. In effect, one would not send messages, but only receive them. I think the big power here would be in finally getting more strongly to a more independent but highly practical way to provide semantics. (One of our favorite examples over the years is the question if you don't know the name of the sine function, then how could you still invoke it? ... APL has a very funny completely non-intuitive way of naming sine, etc.) This question is a very good question when you are trying to find powerful and useful resources on a large network People who have taken the trouble to really understand and build Actor systems (like you!) are well set up to ponder and design and criticize one of the next logical qualitative leaps in object design and communication. Cheers, Alan [1] http://www.iam.unibe.ch/~ducasse/FreeBooks/SmalltalkHistoryHOPL.pdf From: Dale Schumacher dale.schumac...@gmail.com To: Fundamentals of New Computing fonc@vpri.org Cc: Tristan Slominski tristan.slomin...@gmail.com; Steven Teleki st...@teleki.net; Dion Stewart dion.stew...@visi.com; John Heintz j...@gistlabs.com; Ian Buchanan ibucha...@squian.com; David West da...@transcendencecorporation.com Sent: Sun, May 9, 2010 4:38:20 PM Subject: [fonc] An actor-based environment for
Re: [fonc] Fonc on Mac Snow Leopard?
Hi Jakob, I'm always interested in Carl's ideas (he's one of the few in our field that really has unusual and interesting slants on computation). The whole point of the OMeta in JS embedding is that both JS syntax and semantics can be buried (that is JS winds up being like an assembly code). If it had more reflection, then much more could be done. Cheers, Alan From: Jakob Praher j...@hapra.at To: Fundamentals of New Computing fonc@vpri.org Sent: Sun, May 9, 2010 2:41:53 PM Subject: Re: [fonc] Fonc on Mac Snow Leopard? Personally I was very excited about the Carl Hewitt's work on ActorScript [1] lately. IMHO something like Lively Kernel could provide the client infrastructure for this Client Cloud computing. What is your opinion on his work? I also liked the notation he uses in the paper. What I do not like about JS is its imperative verboseness. I also have mixed feelings about JSON. I like the idea of beeing able to express something more denotational, e.g. in ways that keeps focussing on the simplest solution, and then use something like equational reasoning to derive at more performant and complex systems. In the end syntax matters and maybe there is no syntax that works for every solution. So I see a high value in building Syntax understanding into libraries (This kind of homoiconicity is what I like from LISP-like langauges). Also Gilad Bracha did some work on parser combinators using a Self like language called Newspeak [2]. I found the IDE (I think it was called Hopscotch) very interesting in that it mirros the browser. Indeed the current version is running on top of Squeak. Maybe Lively and Newspeak could join forces? Taking the Idea of Hopscotch beyond a single language would be great. Mozilla Lab's Bespin Project focuses on a kind of Emacs for the Web. What I would really like to see is some kind of Worldwide live development environment where projects are really living things and people can take different views on them. With real semantic mappings between individual notations and syntax. -- Jakob [1] - http://arxiv.org/abs/0907.3330 [2] - http://newspeaklanguage.org/ Am 09.05.10 01:06, schrieb Alan Kay: By the way, people on this list should look at Dan Ingalls' Lively Kernel. (http://www.lively-kernel.org/) Dan is also one of original authors of the NSF proposal for STEPS and we claim successes in the Lively Kernel as STEPS successes as well. That said, LK is much more like the bootstrapping of Squeak was, in that a known architecture was adapted to the purpose of using JS as the machine code for a new operating system and live environment. Again, there was the small dedicated team at Sun under the direction of the master designer/builder (Dan). And once they got a few versions bootstrapped they opened it up to interested open sourcers, and there is a lively mailing list for Lively. We like Lively and pay a lot of attention to it because it covers some of the functional ground that needs to be covered for a complete system. The main difference is that they are not trying for really small really relational models. However, the adaptation of the Smalltalk architecture here is very efficient for building things (as it was almost 40 years ago). So this is worth looking at. And we could imagine this as what STEPS might be like to a community, except that we are trying to invent new more compact more powerful ways to express programmatic ideas. At best, something like this is several years in STEPS' future. Cheers, Alan From: Jakob Praher j...@hapra.at To: fonc@vpri.org Sent: Sat, May 8, 2010 12:25:12 PM Subject: Re: [fonc] Fonc on Mac Snow Leopard? Hi Alan, just out of curiosity: I am wondering why VPRI is not aiming at a more community oriented style of innovation. Do you think the communcation effort is not worth the cost since you do not gain enough or even loose some freedom and / or speed by discussing archictural concepts more publicly? Does this imply that in your opinion open (source) projects only work (good) if there is something to be build incrementally (like a bazaar). I am also asking since I am interested in innovation through open communities. I am wondering why there is not more discussions (which I am sure you have internally at the VPRI) brought onto lists. Maybe one could discuss not only the implementation but also concepts behind the design? Having a daytime job I know that sometimes catching up with a lively community is a challenge, on the other hand seeing where things are going and maybe also join forces in early stages might be interesting, no? For instance there could be other people doing PoC work. Thanks, Jakob Am 08.05.10 18:03, schrieb Alan Kay: Glad you are interested, but don't hold your breath. We've got quite a bit more to do this year. It's not an incremental project like many open source people are used to. We actually throw away much of our code
[fonc] Program representation
Hi, When reading about the TCP/IP implementation in OMeta it strikes me that parsing the ASCII-art is still text. Isn't it kind of silly to spend all that syntax on representing something as fundamental as a table? So I was wondering, have you, at vpri, been contemplating alternative program representations besides text? It seems to me that if you had a richer model of representation it would be easier to make readable code. The stuff that Jonathan Edwards been working on at http://subtextual.org/ has been very inspiring for my own thinking on these matters. Representing conditionals as tables seems like a brilliant approach. For my self I was thinking that maybe one could embed a programming language on top of a more graphical language, like HTML and see what comes out of it. BR, John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Program representation
On 2010/05/10, at 18:21 , John Nilsson wrote: When reading about the TCP/IP implementation in OMeta it strikes me that parsing the ASCII-art is still text. Isn't it kind of silly to spend all that syntax on representing something as fundamental as a table? ASCII-art is not so bad. If NASA use it! http://en.wikipedia.org/wiki/HAL/S So I was wondering, have you, at vpri, been contemplating alternative program representations besides text? It seems to me that if you had a richer model of representation it would be easier to make readable code. The stuff that Jonathan Edwards been working on at http://subtextual.org/ has been very inspiring for my own thinking on these matters. Representing conditionals as tables seems like a brilliant approach. For my self I was thinking that maybe one could embed a programming language on top of a more graphical language, like HTML and see what comes out of it. HTML sounds to me somewhat limited. Try TeX. But in any case, contrarily to ASCII-art, these are serialized representations, and it would be better to use Lisp sexps. Googling for 2d parser or 2d expression parsing: http://www.eecs.berkeley.edu/~fateman/papers/pres.pdf http://www.moralfiber.org/eylon/berkeley/cs282/report.pdf -- __Pascal Bourguignon__ http://www.informatimago.com ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Program representation
On Mon, May 10, 2010 at 6:54 PM, John Zabroski johnzabro...@gmail.comwrote: Schematic tables are a separate issue entirely. First of all. Thanks for the explanation about the thinking wrt the TCP/IP implementation. I'll have to peruse the code with that in mind. My questions was, as you pointed out, about a separate issue entirely. The ASCII-art was just the trigger for my question. My concern/thinking was rather that the if the aim of the project is to make programs simpler, one dimension worth exploring is the media used to convey the program to humans. In the end it all boils down to communication between humans. I'm mainly involved in ERP-development, an area I understand is not addressed by this project, which focuses more on the desktop. I do think most of the thinking is transferable though, and in my experience one of the biggest code smells is when one basically transcribes requirements and specifications perfectly legible for humans into something legible for the computer, a process that unfortunately results in lots of information loss. I can for example imagine that instead of writing some comments about where a piece of code comes from one could ideally just include the entire discussion thread that resulted in the code, complete with presence indicators and all. Maybe even have the system suggest updates when involved parties leaves the organisation. Another thing worth exploring is to add graphical examples executing the code in question. The elusive sine functions would probably be better described by a simple wave plot, or a unit circle diagram with the relationships plotted on it, than a formal description of its algebraic properties. Basically code is not only about computing, it's also about communicating with humans. So if the code can be expressed in a rich media I think lots could be made about it's simplicity. BR, John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Program representation
Can you provide an end-to-end exemplary situation in Enterprise Resource Planning (ERP) software where FONC ideas are relevant? You sort of jumped off that stream of thought and onto modeling sine waves graphically, etc. I work in various roles of ERP/CRM/BI software, and so I understand the domain very well -- but I also know it is such a huge domain that when one person says they want to apply an idea to ERP, another person may be totally clueless as to what that would mean, since they have a very different conception of ERP. We typically don't build ERP solutions the way Fortune 500 companies do, because we find we can avoid that complexity. That is an important point: There are mathematical differences in how you approach ERP architecture, and your topology will determine a lot about how you construct applications and what programmers physically must type out to accomplish changes, and how you soak test such a system. On Mon, May 10, 2010 at 2:22 PM, John Nilsson j...@milsson.nu wrote: On Mon, May 10, 2010 at 6:54 PM, John Zabroski johnzabro...@gmail.comwrote: Schematic tables are a separate issue entirely. First of all. Thanks for the explanation about the thinking wrt the TCP/IP implementation. I'll have to peruse the code with that in mind. My questions was, as you pointed out, about a separate issue entirely. The ASCII-art was just the trigger for my question. My concern/thinking was rather that the if the aim of the project is to make programs simpler, one dimension worth exploring is the media used to convey the program to humans. In the end it all boils down to communication between humans. I'm mainly involved in ERP-development, an area I understand is not addressed by this project, which focuses more on the desktop. I do think most of the thinking is transferable though, and in my experience one of the biggest code smells is when one basically transcribes requirements and specifications perfectly legible for humans into something legible for the computer, a process that unfortunately results in lots of information loss. I can for example imagine that instead of writing some comments about where a piece of code comes from one could ideally just include the entire discussion thread that resulted in the code, complete with presence indicators and all. Maybe even have the system suggest updates when involved parties leaves the organisation. Another thing worth exploring is to add graphical examples executing the code in question. The elusive sine functions would probably be better described by a simple wave plot, or a unit circle diagram with the relationships plotted on it, than a formal description of its algebraic properties. Basically code is not only about computing, it's also about communicating with humans. So if the code can be expressed in a rich media I think lots could be made about it's simplicity. BR, John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Program representation
(sorry if similar is already in use...). like having documentation in a hypertext form, and having code contain links into the docs, and from the docs back into the code?... markup could be done similar to a wiki, and the editor can interpret comments containing wiki-links as linking elsewhere (other modules, documentation entries, ...) this could be maybe combined with a tabbed interface, and maybe also support inline-expansion. for example, certain links could be expanded inline, and so looking up the comment for a line of code could, say, expand to a several paragraph explanation, and collapsing it dispells it again (larger documents would be accessed via tabs). I guess it would be a notable improvement on having to edit external files for the documents, and an improvement on javadocs-style comments (which make code less readable by sticking large gobs of text in the middle of it...). similarly, it could be possible to edit whatever contents are pulled up in links, or maybe have an option to add in an expand edit comment (essentially an inlined glob of text, likely itself stored in another document). this would all be in addition to an IDE supporting the more usual jump to method and encapsulate operations, ... (but, maybe called code could be optionally expanded inline, or same-function could could be split out to elsewhere). as for pictures?... well, I guess some people like flowcharts/..., but personally I don't like them all that much (or, at least on the small-scale). I can more easily imagine them being used to describe things like library dependencies, ... but, when used to describe code, one almost may as well just be using assembler... or such... - Original Message - From: John Nilsson To: Fundamentals of New Computing Sent: Monday, May 10, 2010 11:22 AM Subject: Re: [fonc] Program representation On Mon, May 10, 2010 at 6:54 PM, John Zabroski johnzabro...@gmail.com wrote: Schematic tables are a separate issue entirely. First of all. Thanks for the explanation about the thinking wrt the TCP/IP implementation. I'll have to peruse the code with that in mind. My questions was, as you pointed out, about a separate issue entirely. The ASCII-art was just the trigger for my question. My concern/thinking was rather that the if the aim of the project is to make programs simpler, one dimension worth exploring is the media used to convey the program to humans. In the end it all boils down to communication between humans. I'm mainly involved in ERP-development, an area I understand is not addressed by this project, which focuses more on the desktop. I do think most of the thinking is transferable though, and in my experience one of the biggest code smells is when one basically transcribes requirements and specifications perfectly legible for humans into something legible for the computer, a process that unfortunately results in lots of information loss. I can for example imagine that instead of writing some comments about where a piece of code comes from one could ideally just include the entire discussion thread that resulted in the code, complete with presence indicators and all. Maybe even have the system suggest updates when involved parties leaves the organisation. Another thing worth exploring is to add graphical examples executing the code in question. The elusive sine functions would probably be better described by a simple wave plot, or a unit circle diagram with the relationships plotted on it, than a formal description of its algebraic properties. Basically code is not only about computing, it's also about communicating with humans. So if the code can be expressed in a rich media I think lots could be made about it's simplicity. BR, John -- ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Program representation
On Mon, May 10, 2010 at 8:55 PM, John Zabroski johnzabro...@gmail.comwrote: Can you provide an end-to-end exemplary situation in Enterprise Resource Planning (ERP) software where FONC ideas are relevant? You sort of jumped off that stream of thought and onto modeling sine waves graphically, etc. Depends on what you mean with end-to-end. I can definitely see how a meta language like OMeta or M can come in handy to define up DSL for various tasks like data transfer or GUI definitions. The chain of meaning is really important to separate the meanings that are tied to actual business meaning from the technical approach. I envision a system where you describe high level business goals and flows in a language entirely free of technical junk. I wonder how much of the architecture and implementation that could be derived from such a high level. Another thought is that I think a good business system should be flexible enough to allow users to program it according to their whims. Possibly with the assistance of a department specific developer. To enable this while still maintaining the integrity of the system will be a interesting challenge. I work in various roles of ERP/CRM/BI software, and so I understand the domain very well When I said ERP I was actually thinking the whole suite of applications like CRM and BI too. The system I base my experience on is a rather simple system. A single webserver against a single rdbms handling a few hundred users developed and maintained by a single team of developers, but enough interfacing with other systems and teams to feel the pain. BR, John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Program representation
On Mon, May 10, 2010 at 11:29 PM, BGB cr88...@hotmail.com wrote: like having documentation in a hypertext form, and having code contain links into the docs, and from the docs back into the code?... For example. I guess it would be a notable improvement on having to edit external files for the documents, and an improvement on javadocs-style comments (which make code less readable by sticking large gobs of text in the middle of it...). Another improvement would be to get rid of the inherent ordering and context of a text file. Instead one could surround a piece of code, i.e. a method, with context relevant that piece such as dependencies, usages, supplements and complements. The code bubbles project is very interesting in that regard. well, I guess some people like flowcharts/..., but personally I don't like them all that much (or, at least on the small-scale). I can more easily imagine them being used to describe things like library dependencies, ... but, when used to describe code, one almost may as well just be using assembler... Have a look at Conal Elliotts Tangible Functional Programming http://conal.net/blog/posts/tangible-functional-programming-a-modern-marriage-of-usability-and-composability/ he has some interesting examples of a style of visual programming that might actually be useful. BR, John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Program representation
- Original Message -
From: John Nilsson
To: Fundamentals of New Computing
Sent: Monday, May 10, 2010 3:33 PM
Subject: Re: [fonc] Program representation
On Mon, May 10, 2010 at 11:29 PM, BGB cr88...@hotmail.com wrote:
like having documentation in a hypertext form, and having code contain
links into the docs, and from the docs back into the code?...
For example.
I don't know of an example...
I guess something like this could be done by an IDE and using XML, but I don't
know of an IDE which does this.
Visual Studio allows putting XML into doc comments for sake of
documentation-writing, but this is different.
I am I guess imagining having a much closer connection between the docs and
code, which is a little different (although the basic mechanism is similar).
a little lighter-weight could be to use wiki-style references:
/* See [[MyApp.Docs.Foo]] for further info on this. */
this defining a comment containing an external link.
or, for purely external comments:
/*[[MyApp.Focs.Bar]]*/
which the IDE could see as a normal comment, but it is located elsewhere.
/**[[MyApp.Focs.Baz]]*/
would be similar, but work more like doc-comments and assert that the following
item is documented by the referenced item.
the documentation system could in general be structured somewhat after a wiki.
I guess it would be a notable improvement on having to edit external files
for the documents, and an improvement on javadocs-style comments (which make
code less readable by sticking large gobs of text in the middle of it...).
Another improvement would be to get rid of the inherent ordering and context
of a text file. Instead one could surround a piece of code, i.e. a method, with
context relevant that piece such as dependencies, usages, supplements and
complements. The code bubbles project is very interesting in that regard.
yep, this depends a lot on the language structure and semantics.
for example, a language could use namespaces, and support multiple namespaces
per file.
namespace Foo {
... stuff scoped in Foo ...
}
namespace Bar {
... stuff for bar ...
}
namespace Foo {
... more stuff in Foo ...
}
AFAIK, C# can be used like this, but this is not the common practice (where
typically source files are organized along with their respective namespaces,
and it is more common to have a single namespace spread between several related
files, rather than multiple namespaces in a single file...).
dependencies can also be given via using, which can be placed either within
the namespace, or within the toplevel (although AFAIK with different semantics).
for BGBScript I have considered a similar feature, although I am more borrowing
from ActionScript's syntax:
package Foo {
import Bar;
...
}
one oddity though is that I may actually allow multiple toplevels, each of
which potentially having potentially different collections of
packages/namespaces.
it will not be possible to reference between one toplevel and another, rather
only references may be passed.
unlike many existing languages, the toplevel is not assumed to be absolute.
the idea is that this will allow creating toplevels which have less access to
the rest of the app, such as to allow for sandboxing. for example, the default
toplevel can see directly into the C toplevel, but an app may have reason to
create a more restricted toplevel, which will only be able to see namespaces
which it is given (likely excluding the C toplevel).
the idea here is that binding environments are also first-class objects (so, a
namespace is not so much a location in some fixed tree-structure, rather a path
through a series of slots relative to some known location).
however, there are still some technical issues to be addressed here...
note:
an issue at present is that some code (ordinary functions) are use
dynamic-scoping for the toplevel, whereas closures use lexical scoping for the
toplevel (later, both may be made to be lexically-bound).
note that even though the locals and toplevel are semantically
lexically-scoped, both use a different way of implementing the bindings.
well, I guess some people like flowcharts/..., but personally I don't like
them all that much (or, at least on the small-scale). I can more easily imagine
them being used to describe things like library dependencies, ... but, when
used to describe code, one almost may as well just be using assembler...
Have a look at Conal Elliotts Tangible Functional Programming
http://conal.net/blog/posts/tangible-functional-programming-a-modern-marriage-of-usability-and-composability/
he has some interesting examples of a style of visual programming that might
actually be useful.
yes, will have to look at this...
I was more thinking about traditional program-charts, which personally seem not
all that good of a way of doing this, given the very low density of this
representation, and level of effort needed to
Re: [fonc] Program representation
Anyone ever hear of Doug Engelbart? Ever type his name into Google? Ever looked
to see how the code and documentation for his system was organized?
Cheers,
Alan
From: BGB cr88...@hotmail.com
To: Fundamentals of New Computing fonc@vpri.org
Sent: Mon, May 10, 2010 5:50:31 PM
Subject: Re: [fonc] Program representation
- Original Message -
From: John Nilsson
To: Fundamentals of New Computing
Sent: Monday, May 10, 2010 3:33 PM
Subject: Re: [fonc] Program
representation
On Mon, May 10, 2010 at 11:29 PM, BGB cr88...@hotmail.com wrote:
like having documentation in a hypertext form,
and having code contain links into the docs, and from the docs back into
the
code?...
For example.
I don't know of an example...
I guess something like this could be done by an IDE
and using XML, but I don't know of an IDE which does this.
Visual Studio allows putting XML into doc
comments for sake of documentation-writing, but this is different.
I am I guess imagining having a much closer
connection between the docs and code, which is a little different (although the
basic mechanism is similar).
a little lighter-weight could be to use wiki-style
references:
/* See [[MyApp.Docs.Foo]] for further info on
this. */
this defining a comment containing an external
link.
or, for purely external comments:
/*[[MyApp.Focs.Bar]]*/
which the IDE could see as a normal comment, but it
is located elsewhere.
/**[[MyApp.Focs.Baz]]*/
would be similar, but work more like doc-comments
and assert that the following item is documented by the referenced
item.
the documentation system could in general be
structured somewhat after a wiki.
I guess it
would be a notable improvement on having to edit external files for the
documents, and an improvement on javadocs-style comments (which make code
less readable by sticking large gobs of text in the middle of
it...).
Another improvement would be to get rid of the inherent
ordering and context of a text file. Instead one could surround a piece of
code, i.e. a method, with context relevant that piece such as dependencies,
usages, supplements and complements. The code bubbles project is very
interesting in that regard.
yep, this depends a lot on the
language structure and semantics.
for example, a language could use
namespaces, and support multiple namespaces per file.
namespace Foo {
... stuff
scoped in Foo ...
}
namespace Bar {
... stuff for
bar ...
}
namespace Foo {
... more stuff
in Foo ...
}
AFAIK, C# can be used like this,
but this is not the common practice (where typically source files are organized
along with their respective namespaces, and it is more common to have a single
namespace spread between several related files, rather than multiple namespaces
in a single file...).
dependencies can also be
given via using, which can be placed either within the namespace, or
within the toplevel (although AFAIK with different semantics).
for BGBScript I have considered a
similar feature, although I am more borrowing from ActionScript's
syntax:
package Foo {
import
Bar;
...
}
one oddity though is that I may
actually allow multiple toplevels, each of which potentially having
potentially different collections of packages/namespaces.
it will not be possible to
reference between one toplevel and another, rather only references may be
passed.
unlike many existing languages,
the toplevel is not assumed to be absolute.
the idea is that this will allow
creating toplevels which have less access to the rest of the app, such as to
allow for sandboxing. for example, the default toplevel can see directly into
the C toplevel, but an app may have reason to create a more restricted
toplevel,
which will only be able to see namespaces which it is given (likely excluding
the C toplevel).
the idea here is that binding
environments are also first-class objects (so, a namespace is not so much a
location in some fixed tree-structure, rather a path through a series of slots
relative to some known location).
however, there are still some
technical issues to be addressed here...
note:
an issue at present is that some
code (ordinary functions) are use dynamic-scoping for the toplevel, whereas
closures use lexical scoping for the toplevel (later, both may be made to
be lexically-bound).
note that even though the locals
and toplevel are semantically lexically-scoped, both use a different way of
implementing the bindings.
well, I guess some people like flowcharts/...,
but personally I don't like them all that much (or, at least on the
small-scale). I can more easily imagine them being used to describe
things
like library dependencies, ... but, when used to describe code,
one almost may as well just be using
assembler...
Have a look at Conal Elliotts Tangible Functional
Re: [fonc] Fonc on Mac Snow Leopard?
On Mon, May 10, 2010 at 10:46 AM, John Zabroski johnzabro...@gmail.com wrote: Alan, If I took the time to write an idea memo, would you (and possibly others) at VPRI take the time to comment on it? It would mainly be example-driven and use an interweaving storywriting style, since I am not well-versed in scientific writing style, but, if necessary, I could cite and compare to various academic work. I'll read it. Dan ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] An actor-based environment for prototyping
Hi Alan, Thanks for the encouragement. After a little searching I found Naming and Synchronization in a Decentralized Computer System, D. P. Reed, 1978 [1]. Is that the paper you had in mind? It looks interesting, but I haven't had a chance to absorb it yet. I'm glad to hear we're on the right track regarding Actors. At this stage, I'm working at the small end of the continuum, focusing on a small number of powerful and composable mechanisms. I'm about to launch a new blog to discuss some of our findings. I'll post something here when it's available. I'll have to give some thought to the larger-scale blackboard mechanism. It seems like it will take a few combined abstractions to get there. Some kind of unification or matching along with perhaps an auction or marketplace. Maybe the work of the complexity folks, using Agent-Based Modeling, could inform this effort. I think there's more foundational work to do before I'll be ready to tackle these issues, but it is good to let it percolate. I'm convinced that there is important progress to be made using actors, and I plan to continue in that vein. Thanks again, Dale [1] http://portal.acm.org/citation.cfm?id=889815 On Mon, May 10, 2010 at 7:28 AM, Alan Kay alan.n...@yahoo.com wrote: Hi Dale et al. This sounds like a great project, and I'd like to find out more. (Have you looked at David Reed's 1978 MIT thesis on distributed transactional object operating systems. In my opinion this was one of the very best next steps wrt objects (and it was influenced by Actors)). And you are right that Actors were closer to my original concept of objects. Actors came out of the first implemented Smalltalk (72) (which was very Actor-like) -- my notion of objects was heavily influenced by the ARPAnet and the soon to be Internet -- and Actors stayed with something more like this and were both a great next step from what we were doing at PARC, and also got to some of the theoretical issues better than we did. The drive at PARC was to invent and build personal computing, and to try to do it in a language that children could program in. (The former succeeded better than the latter.) After the first round of hardware and software design and implementation, Xerox was unwilling to fund the next logical machine after the Alto (eventually they did but too late), and this forced the fringe people (us) to have to optimize software for the first time (we had been making things run fast enough via HW). And this brought forth rather different versions of Smalltalk which were less adventurous than the original but much more practical (Smalltalk-76 was about 180 times as fast as Smalltalk-72). Carl Hewitt's research was not primarily aimed at building whole real-time systems, so Actors and Smalltalk diverged quite a bit. However, I still think the most interesting version of Smalltalk was 71 which was never implemented [1]. It was an attempt to combine my earliest notion of objects, LOGO, Carl Hewitt's most interesting work (PLANNER, which was the strongest influence on the later Prolog), and some of David Fisher's control definition ideas. This was what we called pattern directed invocation or call by desire. Smalltalk-72 was a weaker version of this, and it's hard to see at all in Smalltalk-80 (a programmer really has to want to program this way to do it). Also in [1] towards the end, is a discussion of how many improvements in software came from improvements in late binding, and that some of these eventually got put into HW to remove most of the inefficiencies that usually come with late binding something. When LINDA came along in the 80s, this got me thinking harder about the step to call by need. This was already in PLANNER as antecedent theorems (Prolog only tried to do the consequent theorems which have a control structure that allows backwards reasoning, and is rather similar to procedure calls). CMU had been doing considerable explorations into forward reasoning (OPS-5) with some terrific optimization mechanisms (Forgie et al). LINDA provided a kind of metaframework for pretty much building any kind of control structure and these could be driven by patterns. These allowed one to think about a kind of goal oriented publish and subscribe coordination mechanism in which no messages were sent (but in which messages were only received). One way to think of this is that each object has two bulletin boards. One has characterizations of needed resources, and the other has characterizations of resources made available by the object. These bulletin boards are now all put into a LINDA-like matching space which does the (considerable) work of brokering. If one could come up with a great way to express the characterizations, then one would have removed one of the difficulties of scaling a message sending system, by removing the need to know the name or IDs of the receivers. In effect, one would not send messages, but
Object Ontology... Was: [fonc] Fonc on Mac Snow Leopard?
Salut, Comme illustration, j'ai decidé a repondre en français... Si tu n'as pas une contexte pour les mots de cette langue, c'est probablement assez difficile a comprendre ce que je dis. --- (this will help if you don't have any french: http://translate.google.com/#fr|en) In order to understand what you're trying to say, it might be that I need to understand your context a bit better (LOL!)... You say it is less important the meaning or intended purpose of a library you then go on to say it's more important to know what does it do? How can you separate what something does from its context. If I provide you with a car, then take you to an extremely cold place like the arctic... you'll find the wheels don't work AS THEIR INTENDED PURPOSE very well. What the car does has therefore been obscured or shifted by its context. This particular car's intended use is to allow people to comfortably and rapidly move their bodies and other things to other places. This is reasonably obvious. Its effectiveness is hampered by an unintended context shift... you could say its meaning has been obscured by its context shift. Take the car into space and you'll find that the context shift has changed its meaning totally. It's no longer useful for its INTENDED PURPOSE. I'm saying the intended purpose of something needs to be recorded as well as the form that it takes as well as the context that the form is appropriate to. We presently just record the form (you represent this by the word data). If I write something in the data that is french of the current times, and you see it 200,000 years later, without a context (and the further you travel from the original context, the more you'll need to define the context), we end up in a circumstance where you can no longer understand the original meaning of the sentence. Put another way... a husk is useless without the kernel it holds. It has no information of its own, it's simply a holder for something else. It has no meaning, only form. The thing we need to take from our physical universe which we haven't succeeded at yet is that we really need only ONE interface to interacting with objects, and objects indeed have information inside them and that this information is objects too... that we need to bind the intent and context with information in order to recreate the most useful aspects of our physical universe which would also provide effectively a most useful computing experience. Information *is* code, code *is* information. For an object to be looked at (/rendered / represented) requires running some code. This is a sort of quantum level of event where looking at something actually changes its state. Thus there is only acting-being (english isn't particularly good at representing my meaning here - what i'm talking about is when an object *is* in terms of it running a primary loop of eventfulness - taking up memory, waiting for events, etc.). To make objects that transform effectively according to their created intention as their context changes would be extremely beneficial from a maintenance standpoint... otherwise we just end up manipulating sets of data unintelligently. It's surely the difference between interacting with information as (at-some-level-) in a sentient universe, or the decision that we live in an atrophying entropic universe. One yields object-oriented programming (or its further-reaching intended future extension) and the other yields procedural programming (where disparate separate entities perform operations on non-intelligent, dead data). Julian. On 11/05/2010, at 3:01 PM, BGB wrote: I disagree... personally, I often find it far more useful, not to add meaning to data, but rather to strip meaning and intention from the data. so, content is stripped of nearly all meaning, becomming essentially raw data to be interpreted however is as-needed for a given task. for example, code as well can become data, being itself stripped of meaning, and becomming essentially entries in a database. the database doesn't concern itself with how it is to be used, as the code which uses it can use it any way it sees fit. one can then, for example, write something which operates on this data, and in turn produces more data, or maybe executable code, ... so, the big question is not the meaning of the data, or even how or what one will do with it, but the form this data will take... (FWIW, meaning may well itself be a misnomer of sorts, when in reality there is no real meaning to things beyond that which are attributed to them after the fact). to some extent this also applies to API design: it is less important the meaning or intended purpose of a library; typically, what is of much greater concern is the more solid aspects: what does it do? what API functions does it export? what sorts of semantics and behavior can be expected? ... context then is not meaning or
