----- 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 make them, ...
psudeocode, plain-language descriptions, ... each seem like a much better
strategy...
granted, flowcharts make a lot more sense for much higher-level
organizational-charts and similar...
but, all this may just be my own personal opinion...
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
