Over the last month, I feel like I stumbled into something very simple and profound: a new perspective on an old idea, with consequences deeper and more pervasive than I had imagined.
The idea is simply this: every user action is an act of meta-programming.
More precisely:
(1) Each user event addends a tacit concatenative program.
(2) The output of the tacit concatenative program is another program.
(3) We can understand the former as rewriting parts of the latter.
(4) These rewrites include the user-model - navigation, clipboard, etc.I will further explain this idea, why it is powerful, how it is different.To clarify, this isn't another hand-wavy 'shalt' and 'must' proposal with no idea of how to achieve it. Hammering at a huge list of requirements for eight years got me to RDP. At this point, I have concrete ideas on how to accomplish everything I'm about to describe.Users Are Programmers.
The TUNES vision is revived, and better than ever.
WHY TACIT CONCATENATIVE?
Concatenative programming is perhaps best known through FORTH. Most concatenative languages have followed in Charles Moore's forthsteps, sticking with the basic stack concept but focusing on higher-order programming, types, and other features.A stack would be an extremely impoverished and cramped environment for a user; even many programmers would not tolerate it. Fortunately, we can move beyond the stack environment. And I insist that we do! Concatenative programming can also be based upon such structures as trees, Huet zippers, and graphs. This proposal is based primarily on tree-structured data and zippers, with just a little indirect graph modeling through shared state or explicit labels (details later).A 'tacit' programming language is one that does not mention names for parameters or local variables. Many concatenative programming languages are also tacit, though the concepts don't fully intersect.A weakness of tacit concatenative programming is that, in a traditional text-based programming environment, users must visualize the environment (stack or other structure) in their head, and that they must memorize a bunch of arcane 'stack shuffling' words. By comparison, variable names in text are easy to visualize and review.My answer: change programming environments!Powerful advantages of tacit concatenative programming include:1. the environment has a precisely defined, visualizable value
2. short strings of tacit concatenative code are easy to generate3. concatenative code is sequential, forming an implicit timeline4. code also subject to learning, pattern recognition, and rewrites
5. every step, small and large, is precisely defined and typedInstead of an impoverished, text-based programming environment, we should offer continuous automatic visualization. Rather than asking users to memorize arcane words, we should offer direct manipulation: e.g. take, put, slide, toss, drag, drop, copy, paste. Appropriate tacit concatenative code is generated at every step, for every gesture. This code is easy to generate because generators can focus on short vectors of learned 'known useful' words without syntactic noise; this is subject to a variety of well-known solutions (logical searches, genetic programming, hill-climbing).
On Sep 20, 2013 10:46 AM, "Matt McLelland" <mclella...@gmail.com> wrote:
>>
>> The TUNES vision is revived, and better than ever.
>
>
> Do you have a link that would tell me what TUNES is?
Try tunes.org
>
> What is it about continuous automatic visualization that you think requires tacit or concatenative programming?
Not "requires". Just orders of magnitude better at it. Some reasons:
1. well defined environment structure at every step
2. well defined, small step movement operators
3. strong, local distinction between move and copy.
4. linear, incremental timeline built right in
5. much weaker coupling to underlying text
>
> My main question is: what's the problem with text?
Manipulating diagrams, graphs, geometries, images via text is analogous to writing text through a line editor. It's usable for a nerd like me, but is still harder than it could be.
My goal is to lower the barrier for programming so that normal people do it as part of their every day lives.
>
> From my point of view an essential aspect of programming is that we are building up an artifact -- a "program" -- that can be reasoned about independently of its edit history / method of construction.
I agree!
That gets back to the "meta" in "user actions are an act of metaprogramming."
Yet there are many advantages to modeling the method of construction, and reasoning about it, too. It enables programming by example, formal macros, staged metaprogramming.
Even better, if execution is fully consistent with method of construction, then the intuitions users gain during normal use will effectively inform them for higher order programming.
>
> Furthermore, I think it's a mistake to couple the ways of constructing / editing that artifact to its semantics as a program.
I halfway agree with this.
The programmatic 'meaning' of a graph, geometry, diagram, text, or other artifact should be controlled by the user of that artifact. Yet, it is ideal that the ways of manipulating the artifact also move it from one consistent meaning to another.
In order to achieve both properties, it is necessary that the tools and macros for operating on a structure also be programmable by the user.
>
> you made the claim that there isn't a simple way to translate from tacit concatenative programming to named applicative.
Other way around!
Tacit concatenative to applicative is trivial (albeit, not idiomatic).
> Other way around!
Oops, you're right. But my question remains: isn't the hard difference more the concatenative vs. applicative than named vs. tacit?
--
You received this message because you are subscribed to the Google Groups "reactive-demand" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reactive-dema...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
I would say that in my experience text is a much better construct form for most programs than those other forms, so I would expect text to be the 95% case. I'm including in that more structured forms of text like tables.
What I'm still not understanding is how viewing the editing of an image or graph as a tacit concatenative program is a big win.
I'm skeptical that non-programmers will ever do serious programming.
isn't the hard difference more the concatenative vs. applicative than named vs. tacit?
No. The primary challenge is due to named vs. tacit, and the dataflows implicitly expressed by use of names. If you have an applicative language that doesn't use names, then there is a much more limited dataflow. It is really, literally, just Applicative.
The artifact being constructed in a naive image editor is an image and it's not particularly fruitful to view that image as a program.
As you're saying, you can view the operations of building an image as defining a programming language and more advanced image editors show you a pipeline of such operations and let you edit it in ways that are starting to feel like programming. But when you look at things that way, the image is not the program -- the pipeline is the program.
And the best way to look at and understand that pipeline is probably structured text. Think of how the pipeline is usually presented: a stack of text descriptions of each operation (probably combined with a thumbnail of the image after that stage).
We can consider an arbitrary UI to be building a program, but you aren't really programming unless you're interested in the whole program at once.
while this is really just terminology we're hammering out, I would prefer to say that 95% of UI users aren't programming. Programming is when you care about the whole program.
So now consider the special case where the UI we're interacting with is an IDE
I see no special relationship between that primary program and the other program
we're implicitly building when we look at the IDE's UI as a programming language.
My point is that if you start with a named compositional (values can only be composed) language, it looks like it would be easy to convert to tactic concatenative. It's easy to replace uses of names with nonsense words that achieve the same data plumbing.
Some useful relationships:(1) The value models are the same in both cases.(2) Subprograms extracted from the latter are first-class values in the former.(3) Subprograms developed in the former can be used as tools in the latter.(4) The set of user capabilities is exactly equal to the set of program capabilities.
(5) Intuitions developed based on usage are directly effective for automation.These shouldn't be "special" relationships.
--
> An image could be interpreted as a high level world-map to support procedural generation with colors indicating terrain types and heights.This is common practice in games, but it doesn't IMO make artists into programmers and it doesn't make the image into a program.
I think there is a useful distinction between user and programmer that should be maintained.
How can you view playing a game of Quake as programming? what's to be gained?
I find myself agreeing with most of your intermediate reasoning and then failing to understand the jump to the conclusion of tactic concatenative programming and the appeal of viewing user interfaces as programs.
I will occasionally have to give you an error message "usage of name is illegal in this context", right? For example, violates substructural types. I still count that as an easy translation
most of your ideas sound pretty good to me, but I think there are a couple of sticking points that I'm still not on board with. I'm certainly open to the possibility that I just haven't gotten it yet, and either way I wish you the best of luck in getting your system going.
David,Great Writeup. To get down to more practical terms for laymen software engineers such as myself, what can we do in immediate terms to realize your vision?I'm a big believer in tools( even though I'm installing emacs 24 and live-tool). Is there currently a rich IDE environment core in which we can start exploring visualization tools?Here's what I'm getting at. We have rich IDEs (in relative terms), Intellij, Resharper, VS, Eclipse, whatever.. I think they are still very archaic in programmer productivity. The problem I see is that we have a dichotomy with scripting ennviroments (Emacs) as opposed to "heavy" IDEs. e.g. we can't easily script these IDEs for expermination.thought?
I find myself agreeing with most of your intermediate reasoning and then failing to understand the jump to the conclusion of tactic concatenative programming and the appeal of viewing user interfaces as programs.
Tacit concatenative makes it all work smoothly.TC is very effective for:* automatic visualization and animation* streaming programs* pattern detection (simple matching)* simple rewrite rules* search-based code generation* Markov model predictions (user anticipation)* genetic programming and tuning* typesafe dataflow for linear or modalIndividually, each of these may look like an incremental improvement that could be achieved without TC.
On Sat, Sep 21, 2013 at 12:29 PM, Matt McLelland <mclella...@gmail.com> wrote:
> An image could be interpreted as a high level world-map to support procedural generation with colors indicating terrain types and heights.This is common practice in games, but it doesn't IMO make artists into programmers and it doesn't make the image into a program.Not by itself, I agree. Just like one hair on the chin doesn't make a beard, or one telephone doesn't make a social network.But scale it up! One artist will eventually have dozens or hundreds of data-objects representing different activities and interacting. In a carefully designed environment, the relationships between these objects also become accessible for observation, influence, and extension.The only practical difference between what you're calling an 'artist' vs. 'programmer' is scale. And, really, it's your vision of an artist's role that's failing to scale, not the artist's vision. Artists are certainly prepared to act as programmers if it means freedom to do their work (cf. Unreal Kismet, or vvvv, for example). But they have this important requirement that is not well addressed by most languages today: immediate feedback, concreteness.
A team of artists can easily build systems with tens of thousands of interactions, at which point they'll face all the problems a team of programmers do. It is essential that they have better tools to modularize, visualize, understand, and address these problems than do programmers today.
I think there is a useful distinction between user and programmer that should be maintained.I think there should be a fuzzy continuum, no clear distinction. Sometimes artists are more involved with concrete direct manipulations, sometimes more involved with reuse or tooling, with smooth transitions between one role and the other. No great gaps or barriers.Do you have any convincing arguments for maintaining a clear distinction? What precisely is useful about it?
I find myself agreeing with most of your intermediate reasoning and then failing to understand the jump to the conclusion of tactic concatenative programming and the appeal of viewing user interfaces as programs.
Tacit concatenative makes it all work smoothly.TC is very effective for:* automatic visualization and animation* streaming programs* pattern detection (simple matching)* simple rewrite rules* search-based code generation* Markov model predictions (user anticipation)* genetic programming and tuning* typesafe dataflow for linear or modal
Individually, each of these may look like an incremental improvement that could be achieved without TC.You CAN get automatic visualization and animation with names, it's just more difficult (no clear move vs. copy, and values held by names don't have a clear location other than the text). You CAN do pattern recognition and rewriting with names, it's just more difficult (TC can easily use regular expressions). You CAN analyze for linear safety using names, it's just more difficult (need to track names and scopes). You CAN predict actions using names, it's just more difficult (machine-learning, Markov models, etc. are very syntax/structure oriented). You CAN search logically for applicative code or use genetic programming, it's just freakishly more difficult (a lot more invalid or irrelevant syntax to search). You CAN stream applicative code, it's just more difficult (dealing with scopes, namespaces).
Stop cherry-picking your arguments; you've lost sight of the bigger picture, or maybe you haven't glimpsed it yet. Step back. Try to address ALL these points, simultaneously, in one system, while *keeping it simple*. If you can do so with a named applicative model, I'll be impressed and interested.
A thought about bytecode: One problem with distributing things in a compiled version is that it doesnt really afford collaboration. If the primary means of distribution instead would be the source as such it's much easier to debug and fix issues discovered in imported modules. If something like a github fork was the standard way of importing it would be even better, then you are basically just a pull request away from contributing tweaks too.Things like minification as in the javascript world would have to be discouraged though, so compilation and caching should be designers so as not to be a performance problem.But, like git, this should be easy if things are based on immutable content adressable fragments. See f.ex. Datomic and/or camlistore as an approach to this. ( and docker for that matter)BRJohn
--
You received this message because you are subscribed to the Google Groups "Augmented Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to augmented-progra...@googlegroups.com.
To post to this group, send email to augmented-...@googlegroups.com.
Visit this group at http://groups.google.com/group/augmented-programming.
--
You received this message because you are subscribed to the Google Groups "Augmented Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to augmented-progra...@googlegroups.com.
To post to this group, send email to augmented-...@googlegroups.com.
Visit this group at http://groups.google.com/group/augmented-programming.
If you want to say that programming is a spectrum and UI usage is programming lite, that's fine with me, but I certainly don't see that choice of terminology as important.
look back at their tangled web of Kismet script and wish they'd learned to be comfortable with text :).
I think the important points of your viewpoint don't depend on calling ordinary UI usage programming.
One principle I hold is that surface syntax design should be almost exclusively designed for consumption by humans.
meta-programming via the same interface to code that humans use is a bad idea
The fact that UI inputs are best viewed as *streaming* programs is, to me, another good reason not to view UI inputs and programs as isomorphic. A UI input is a special kind of program.
I'd still call it local, though, because it just requires examining the current context. Unless you're talking about global linear variables, which I'd call a design error.
--
You received this message because you are subscribed to the Google Groups "Augmented Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to augmented-progra...@googlegroups.com.
To post to this group, send email to augmented-...@googlegroups.com.
Visit this group at http://groups.google.com/group/augmented-programming.
David Barbour <dmba...@gmail.com> writes:
> My own plan is to implement a streamable, strongly typed, capability-secure
> TC bytecode (Awelon Bytecode, ABC) and build up from there, perhaps
> targeting Unity and/or developing a web-app IDE for visualization. (Unity
> is a tempting target for me due to my interest in AR and VR environments,
> and Meta's support for Unity.)
When bootstrapping pervasive systems like this I think it's important to
'dog food' them as early as possible, since that makes it easier to work
out which underlying feature should be added next (what would help the
most common irritation?), and allows for large libraries of 'scratch an
itch' scripts to build up.
I would find out what worked (and what didn't) for other projects which
required bootstrapping. Minimalist and low-level systems are probably
good examples, since it's harder for them to fall back on existing
software. I suppose I have to mention self-hosting languages like
Smalltalk, Self and Factor. I'd also look at operating systems
(MenuetOS, ReactOS, Haiku, etc.), desktop 'ecosystems' (suckless, ROX,
GNUStep, etc.), as well as Not-Invented-Here systems like Unhosted. What
was essential for those systems to be usable? Which areas were
implemented prematurely and subsequently replaced?
If it were me, I would probably bootstrap via a macro system (on Linux):
* Log all X events, eg. with xbindkeys (togglable, for password entry)
* Write these logs as concatenative programs, which just call out to
xte over and over again
* Write commands for quickly finding, editing and replaying these
programs
With this in place, I'd have full control of my machine, but in a very
fragile, low-level way. However, this would be enough to start
scratching itches.
When controlling Ratpoison via simulated keystrokes becomes too tedious,
I might write a few Awelon words to wrap Ratpoison's script API. I might
hook into Selenium to make Web automation easier. As each layer starts
to flake, I can go down a level and hook into GTK widgets, Imagemagick,
etc. until some tasks can be achieved by composing purely 'native'
Awelon components.
It would be very hacky and non-ideological to begin with, but would be
ever-present and useful enough to get some real usage.
Cheers,
Chris
_______________________________________________
fonc mailing list
fo...@vpri.org
http://vpri.org/mailman/listinfo/fonc
Dear David,I am seriously interested in collaborating with you!I especially like the following points:1) Programming by text manipulation is not the only way to do programmingI actually tend to have the more "iconoclastic" view that text-based programming is "harmful" -- see my previous rant on FONC, but you mentioned what should be done, whereas I only managed to point out what should not be done.2) I like the tacit idea. I always considered the omnipresent reliance on names as means of binding things together as extremely fragile. Do you think one could treat the names as annotations with documentation purpose, without them being the binding mechanism?3) Last but not least: There is no fundamental difference between programmers and users. Both groups are just using computers to create some digital content. Any sharp boundary between the way the two groups work is maybe unnatural. I think psychology is an important factor here. I actually do think that many programmers actually like the existence of such boundary and are not motivated to make it disappear, but this is really just an opinion.
_______________________________________________
fonc mailing list
fo...@vpri.org
http://vpri.org/mailman/listinfo/fonc
The names are for people, and should favor readability over uniqueness in the namespace; like ambiguous English words context should go a long way in helping the reader understand on their own (if not, they can do some mouse over). We can even do fancy things with the names when they are being rendered, like, if they are ambiguous, underlay them with a dis-ambiguating qualifier. The world is wide open once you’ve mastered how to build a code editor! Other possibilities include custom names, or multi-lingual names, but I’m worried about different developers “seeing” different things…we’d like to develop a community that sees the same things.
The trick is mastering search and coming up with an interface so that it becomes as natural as identifier input.
From: augmented-...@googlegroups.com [mailto:augmented-...@googlegroups.com] On Behalf Of David Barbour
Sent: Tuesday, September 24, 2013 5:10 AM
To: augmented-...@googlegroups.com
Subject: Re: Personal Programming Environment as Extension of Self
It isn't clear to me what you're suggesting. That module names be subject to... edit-time lookups? Hyperlinks within the Wiki are effectively full URLs? That could work pretty well, I think, though it definitely favors the editor over the reader.
Maybe what we need is a way for each user to have a personal set of PetNames.
This way the reader sees xrefs in terms of her personal petname list, and the writer writes xrefs in terms of his.
I was actually contemplating this design at a more content-based layer:
* a sequence of bytecode may be given a 'pet-name' by a user, i.e. as a consequence of documenting or explaining their actions.
* when an equivalent sequence of bytecode is seen, we name it by the user's pet-name.
* rewriting can help search for equivalencies.
* unknown bytecode can be classifed by ML, animated, etc. to help highlight how it is different.
* we can potentially search in terms of code that 'does' X, Y, and Z at various locations.
* similarly, we can potentially search in terms of code that 'affords' operations X, Y, and Z.
I think both ideas could work pretty well together, especially since '{xref goes here}{lookup}$' itself could given a pet name.
On Mon, Sep 23, 2013 at 1:41 PM, Sean McDirmid <smc...@microsoft.com> wrote:
Maybe think of it as a module rather than a namespace. I'm still quite against namespaces or name based resolution in the language semantics; names are for people, not compilers (subtext). Rather, search should be a fundamental part of the IDE, which is responsible for resolving strings into guids.
It will just be like google mixed in with Wikipedia, not much to be afraid of.
On Sep 24, 2013, at 4:32, "David Barbour" <dmba...@gmail.com> wrote:Sean,
I'm still interested in developing a code wiki! Had that idea in mind since 2007-ish.
But I might favor a more DVCS-style approach, where edits are cherry-picked into each user's/group's private view of the wiki, and where shared code is simply published to spaces where other people can find it easily. (I'd really like some sort of content-based search, i.e. find me functions relevant to this input that will produce outputs with a given property.)
I think forcing people to use a global Wikipedia repo will (reasonably) scare too many people off. But I also think there should be one of them, as a central collaboration point to help flatten the namespaces, and perhaps another one for each large business, and another for each project, and another for each user, with different groups finding niches for themselves.
The main thing is to avoid deep namespaces like Java. There are enough words for everyone.
(Hmm. I wonder if genetic programming with TC code might be an interesting way to have little wiki-babies. ;)
Best,
Dave
On Mon, Sep 23, 2013 at 2:04 AM, Sean McDirmid <smc...@microsoft.com> wrote:
Imagine a language that comes with one shared namespace that all language users can import from and export into, let’s call it the “code wiki.” Search is built into the IDE so programmers can find things from the code wiki easily. Only one branch of versioning is supported, and like Wikipedia, vandalism is handled quickly via editors who care. At any rate, programmers are expected to vet code that they are interested in reusing, and ensure that changes to the code are reasonable (edit wars might result in explicit forking), aided by very good diff tooling.
--
You received this message because you are subscribed to the Google Groups "Augmented Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to augmented-progra...@googlegroups.com.
To post to this group, send email to augmented-...@googlegroups.com.
Visit this group at http://groups.google.com/group/augmented-programming.
For more options, visit https://groups.google.com/groups/opt_out.
Ambiguity is common in English and it’s not a big problem: words have many different definitions, but when read in context we can usually tell what they mean. For “Cowboy.Draw(Gun)” and “Artist.Draw(Picture)”, we can get a clue about what Draw means; ambiguity is natural! For my language, choosing what Draw is meant drives type inference, so I can’t rely on types driving name lookup. But really, the displayed annotation goes in the type of the variables surrounding the Draw call (Cowboy, Gun) rather than the Draw Call itself.
Language is an important part of society. Though I can use translation to talks to my Chinese speaking colleagues, that we all speak in English at work and share the names for things is very important for collaboration (and suffers when we don’t). For code, we might be taking about it even when we are not reading it, so standardizing the universe of names is still very important.
I think it's fine if people model names, text, documents, association lists, wikis, etc. -- and processing thereof.
And I do envision use of graphics as a common artifact structure, and just as easily leveraged for any explanation as text (though I imagine most such graphics will also have text associated).
Can you explain your concern?
Don't forget that words can be images, vector graphics or 3D graphics. If you have an open system, then people will incorporate names/symbols. I'm not sure you want to avoid symbolic processing, but that's your choice.
I'm reminded of the omgcraft ad for cachefly.
John
_______________________________________________
fonc mailing list
fo...@vpri.org
http://vpri.org/mailman/listinfo/fonc
I don't really have a big concern. If you just support numbers, people will find clever, but potentially incompatible ways of doing strings. I recall in the pre-STL days supporting 6 different string classes. I understand that a name is different than a string, but I come from a perl background. People don't reinvent strings in perl to my knowledge.
David Barbour <dmba...@gmail.com> writes:
> Text is also one of the problems I've been banging my head against since
> Friday. Thing is, I really hate escapes. They have this nasty geometric
> progression when dealing with deeply quoted code:
>
> {} -> {{\}} -> {{{\\\}\}} -> {{{{\\\\\\\}\\\}\}} ->
> {{{{{\\\\\\\\\\\\\\\}\\\\\\\}\\\}\}}
>
> I feel escapes are too easy to handle incorrectly, and too difficult to
> inspect for correctness. I'm currently contemplating a potential solution:
> require all literal text to use balanced `{` and `}` characters, and use
> post-processing in ABC to introduce any imbalance. This could be performed
> in a streaming manner. Inductively, all quoted code would be balanced.
The geometric explosion comes from the unary nature of escaping. It
wouldn't be too difficult to add a 'level', for example:
{} -> {{\0}} -> {{{\1}\0}} -> {{{{\2}\1}\0}} ->
{{{{{\3}\2}\1}\0}}
The main problem with escaping is that it is homomorphic: ie. it is
usually "String -> String". This is basically the source of all code
injection attacks. It wouldn't be too bad if escaping were idempotent,
since we could add extra escapes just in case, but it's not so we end up
keeping track manually, and failing.
There's a good post on this at
http://blog.moertel.com/posts/2006-10-18-a-type-based-solution-to-the-strings-problem.html
It would be tricky to implement a solution to this in a way that's open
and extensible; if we're be passing around first-class functions anyway,
we could do Haskell's dictionary-passing manually.
Cheers,
Chris
I have nothing against name resolution at edit-time. My concern is that giving the user a list of 108 subtly different definitions of 'OOP' and saying "I can't resolve this in context. Which one do you mean here?" every single time would be insufferable, even if the benefit is that everyone 'sees' the same code.
On Sep 24, 2013 7:15 AM, "Matt M" <mclella...@gmail.com> wrote:
> Person.draw(object) <-- What do I mean by this? Am I drawing a picture? a gun? a curtain?
And the way this works in conversation is that your partner stops you and says "wait, what do you mean by 'draw'"? Similarly an IDE can underline the ambiguity and leave it to the user to resolve, either explicitly or implicitly by continuing to write more (often ambiguity is removed with further context).
I completely agree with Sean's quote (of Johnathan Edwards?) that names are for people, and that name resolution should almost never be part of the dynamics of a language. Names should be resolved statically (preferably at edit time).
Matt
--You received this message because you are subscribed to the Google Groups "reactive-demand" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reactive-dema...@googlegroups.com.
One way of escaping is indentation, like Markdown.
This is arbitrary code
This is arbitrary code *in* arbitrary code.
and so on.
No more escape sequences in the quotation. You just have the
inconvenience of prefixing each line with a tab or something.
Loup.
On Mon, Sep 23, 2013 at 10:24:20PM -0700, David Barbour wrote:
> Text is also one of the problems I've been banging my head against since
> Friday. Thing is, I really hate escapes. They have this nasty geometric
> progression when dealing with deeply quoted code:
>
> {} -> {{\}} -> {{{\\\}\}} -> {{{{\\\\\\\}\\\}\}} ->
> {{{{{\\\\\\\\\\\\\\\}\\\\\\\}\\\}\}}
>
> I feel escapes are too easy to handle incorrectly, and too difficult to
> inspect for correctness. I'm currently contemplating a potential solution:
> require all literal text to use balanced `{` and `}` characters, and use
> post-processing in ABC to introduce any imbalance. This could be performed
> in a streaming manner. Inductively, all quoted code would be balanced.
If I were to enter 3 characters a second into a computer for 40 years, assuming a byte per character, I'd have generated ~3.8 GiB of information, which would fit in memory on my laptop. I'd say that user input at least is well worth saving.
Well, since we're talking about a concatenative bytecode, I'll try to speak Forthfully.Normally when we define a word in a stack language we make up an ASCII symbol and say "this symbol refers to all these other symbols, in this definite order". Well and good, with two potential problems: we have to make up a symbol, and that symbol might conflict with someone else's symbol.Name clashes is an obvious problem. The fact that we must make up a symbol is less obviously a problem, except that the vast majority of our referents should be generated by a computer. A computer generated symbol may as well be a hash function, at which point, a user-generated symbol may as well be a hash also, in a special case where the data hashed includes an ASCII handle for user convenience.This is fine for immutable values, but for identities (referents to a series of immutable values, essentially), we need slightly more than this: a master hash, taken from the first value the identity refers to, the time of creation, and perhaps other useful information. This master hash then points to the various values the identity refers to, as they change.There are a few things that are nice about this approach, all of which derive from the fact that identical values have identical names and that relatively complex relationships between identifies and values may be established and modified programmatically.As an example, if I define a "foo" function which is identical to someone else's "bar" function, they should have the same "name" (hash) despite having different handles. With a little work, we should be able to retrieve all the contexts where a value appears, as well as all the handles and other metadata associated with that value in those contexts.
[continued to second e-mail]
What we gain relative to URLs is that a hash is not arbitrary. If two programs are examining the same piece of data, say a sound file, it would be nice if they came to the same, independant conclusion as to what to call it.
Saving total state at all times is not necessary, but there are times when it may be convenient. If I were to enter 3 characters a second into a computer for 40 years, assuming a byte per character, I'd have generated ~3.8 GiB of information, which would fit in memory on my laptop. I'd say that user input at least is well worth saving.
"This is my personal programming environment. There are many like it, but this one is mine."
The notion is to have a consistent way to map between "a" large sound file and "the" large sound file. From one perspective it's just a large number, and it's nice if two copies of that number are never treated as different things.
For identity, I prefer to formally treat uniqueness as a semantic feature, not a syntactic one.
I entirely agree! Hence the proposal of a function hash(foo) that produces a unique value for any given foo, where foo is an integer of arbitrary size (aka data). We may then compare the hashes as though they are the values, while saving time.
Hashing is not associative per se but it may be made to behave associatively through various tweaks: