Even Lisp isn't parentheses balanced by definition, because you can do this:
'(")")
In that same sense my bytecode is block balanced, except in text.
[ [ [] [] ] [] ]
{ ] }
The idea of using number of chars is possible, something like:
{42|forty two characters here.................
But that would also be very difficult to use in a streaming bytecode. It's
also difficult to read. I've always felt that bytecode should at least be
slightly legible, so I can easily get a sense of what's happening just by
looking at the raw streams, even though I don't expect people to program in
bytecode directly (nor read it that way often).
On Tue, Sep 24, 2013 at 12:49 AM, Pavel Bažant <[email protected]> wrote:
> 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
>
>
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
