Oh, I see. As I mentioned in the first message, I plan on UTF-8 text being
one of the three basic types in ABC. There is text, rational numbers, and
blocks. Even if I'm not using names, I think text is very useful for tagged
values and such.
{Hello, World!}
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.
Best,
Dave
On Mon, Sep 23, 2013 at 9:28 PM, John Carlson <[email protected]> wrote:
> 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.
> On Sep 23, 2013 11:15 PM, "David Barbour" <[email protected]> wrote:
>
>> 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?
>> On Sep 23, 2013 8:16 PM, "John Carlson" <[email protected]> wrote:
>>
>>> 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
>>> On Sep 23, 2013 8:11 PM, "David Barbour" <[email protected]> wrote:
>>>
>>>> Okay, so if I understand correctly you want everyone to see the same
>>>> thing, and just deal with the collisions when they occur.
>>>>
>>>> You also plan to mitigate this by using some visual indicators when
>>>> "that word doesn't mean what you think it means". This would require
>>>> search before rendering, but perhaps it could be a search of the user's
>>>> personal dictionary - i.e. ambiguity only within a learned set. I wonder if
>>>> we could use colors or icons to help disambiguate.
>>>>
>>>> A concern I have about this design is when words have meanings that are
>>>> subtly but significantly different. Selecting among these distinctions
>>>> takes extra labor compared to using different words or parameterizing the
>>>> distinctions. But perhaps this also could be mitigated, through automatic
>>>> refactoring of the personal dictionary (such that future exposure to a
>>>> given word will automatically translate it).
>>>>
>>>> I titled this "Personal Programming Environment as Extension of Self"
>>>> because I think it should reflect our own metaphors, our own thoughts,
>>>> while still being formally precise when we share values. Allowing me to use
>>>> your words, your meanings, your macros is one thing - a learning
>>>> experience. Asking me to stick with it, when I have different subtle
>>>> distinctions I favor, is something else.
>>>>
>>>> Personally, I think making the community "see" the same things is less
>>>> important so long as they can share and discover by *meaning* of content
>>>> rather than by the words used to describe it. Translator packages could be
>>>> partially automated and further maintained implicitly with permission from
>>>> the people who explore different projects and small communities.
>>>>
>>>> Can we create systems that enable people to use the same words and
>>>> metaphors with subtly different meanings, but still interact efficiently,
>>>> precisely, and unambiguously?
>>>>
>>>> Best,
>>>>
>>>> Dave
>>>>
>>>>
>>>> On Mon, Sep 23, 2013 at 5:26 PM, Sean McDirmid
>>>> <[email protected]>wrote:
>>>>
>>>>> 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:* [email protected] [mailto:
>>>>> [email protected]] *On Behalf Of *David Barbour
>>>>> *Sent:* Tuesday, September 24, 2013 5:10 AM
>>>>> *To:* [email protected]
>>>>>
>>>>> *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.****
>>>>>
>>>>> ** **
>>>>>
>>>>> http://www.skyhunter.com/marcs/petnames/IntroPetNames.html****
>>>>>
>>>>> ** **
>>>>>
>>>>> 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 <[email protected]>
>>>>> 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" <[email protected]> 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 <[email protected]>
>>>>> 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 [email protected].
>>>>> To post to this group, send email to
>>>>> [email protected].
>>>>> Visit this group at
>>>>> http://groups.google.com/group/augmented-programming.
>>>>> For more options, visit https://groups.google.com/groups/opt_out.****
>>>>>
>>>>> --
>>>>> 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 [email protected].
>>>>> To post to this group, send email to
>>>>> [email protected].
>>>>> Visit this group at
>>>>> http://groups.google.com/group/augmented-programming.
>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> fonc mailing list
>>>> [email protected]
>>>> http://vpri.org/mailman/listinfo/fonc
>>>>
>>>>
>>> _______________________________________________
>>> fonc mailing list
>>> [email protected]
>>> http://vpri.org/mailman/listinfo/fonc
>>>
>>>
>> _______________________________________________
>> fonc mailing list
>> [email protected]
>> http://vpri.org/mailman/listinfo/fonc
>>
>>
> _______________________________________________
> fonc mailing list
> [email protected]
> http://vpri.org/mailman/listinfo/fonc
>
>
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
