I don't know the details of your language, but I see two possibilities: 1) If the textual representation of your language is parenthesis-balanced by definition, just do what Lisp does. 2) If not, format quoted text like quote number_of_chars char char char .... Yes I know 2) is fragile, but so is escaping.
On Tue, Sep 24, 2013 at 7:24 AM, David Barbour <[email protected]> wrote: > 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 > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
