Re: Re: Release 6.17

Re: Re: Release 6.17

[Carsten Dominik]

On Jan 4, 2009, at 3:33 PM, Steven E. Harris wrote:

> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> Code references use special labels embedded directly into the source
>> code.  Such labels look like "((name))" and must be unique within a
>> document.
>
> How does the parser know that, say, "((def))" is not a valid  
> expression
> in the surrounding Lisp forms? Is it important that it be separated by
> space, or be the last token on the line?
>
> Trying to concoct a motivating example, consider a structure  
> represented
> as nested lists:
>
> ,----
> | '(a
> |   ((b c) d)
> |   (((e) f))    ((def))
> |   g)
> `----
>
> Without knowing what the enclosing `quote' form means, how do know  
> that
> "((def))" is not part of it?

Hi Steven,

good question, and the answer is that is does not know,
cannot know, because this is a feature that is supposed
to work for any kind of example, an the parser cannot
know all possible syntaxes :-)

This idea is to make this work in a heuristic way, by using something
that is unlikely enough to occur in real code.

You are right that what I am using might be too
dangerous for emacs lisp or other lisp dialects, and
it could also show up in other languages like C.

What would be safer?

  <<name>>    like the other Org-mode targets?  That would make sense.
              Does anyone know a language where this would be used
              in real life?  It would make it harder to write about
              Org-mode, though.

Or do we need another option, so that, if needed, we could switch do
a different syntax?

Comments are very welcome.

- Carsten

Re: Re: Release 6.17

[Eddward DeVilla]

On Sun, Jan 4, 2009 at 10:01 AM, Carsten Dominik <dominik@science.uva.nl> wrote:
>
> On Jan 4, 2009, at 3:33 PM, Steven E. Harris wrote:
>
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>
>>> Code references use special labels embedded directly into the source
>>> code.  Such labels look like "((name))" and must be unique within a
>>> document.
>>
>> How does the parser know that, say, "((def))" is not a valid expression
>> in the surrounding Lisp forms? Is it important that it be separated by
>> space, or be the last token on the line?
>>
>> Trying to concoct a motivating example, consider a structure represented
>> as nested lists:
>>
>> ,----
>> | '(a
>> |   ((b c) d)
>> |   (((e) f))    ((def))
>> |   g)
>> `----
>>
>> Without knowing what the enclosing `quote' form means, how do know that
>> "((def))" is not part of it?
>
> Hi Steven,
>
> good question, and the answer is that is does not know,
> cannot know, because this is a feature that is supposed
> to work for any kind of example, an the parser cannot
> know all possible syntaxes :-)
>
> This idea is to make this work in a heuristic way, by using something
> that is unlikely enough to occur in real code.
>
> You are right that what I am using might be too
> dangerous for emacs lisp or other lisp dialects, and
> it could also show up in other languages like C.
>
> What would be safer?
>
>  <<name>>    like the other Org-mode targets?  That would make sense.
>             Does anyone know a language where this would be used
>             in real life?  It would make it harder to write about
>             Org-mode, though.
>
> Or do we need another option, so that, if needed, we could switch do
> a different syntax?
>
> Comments are very welcome.
>
> - Carsten

I think that is quote words in perl 6.

@list = <<$this is a 'list' of 7 strings>>  # in perl 6 is
@list = qw/$this is a 'list' of 7 strings/  # in perl 5.

It's looking like perl 6 will be a reality and that syntax is
recommend in several places like hash dereferences.

%hash<<bareword>>  # look up bareword in %hash

I can't remember enough off the top of my head, but I think <<name>>
will play merry heck with common(?) perl 6 code.  I can look up more
examples if needed.

Edd

Re: Re: Release 6.17

[Tom Breton (Tehom)]

>
> On Jan 4, 2009, at 3:33 PM, Steven E. Harris wrote:
> [...]
>> Without knowing what the enclosing `quote' form means, how do know
>> that
>> "((def))" is not part of it?
>
> Hi Steven,
>
> good question, and the answer is that is does not know,
> cannot know, because this is a feature that is supposed
> to work for any kind of example, an the parser cannot
> know all possible syntaxes :-)
>
> This idea is to make this work in a heuristic way, by using something
> that is unlikely enough to occur in real code.
>
> You are right that what I am using might be too
> dangerous for emacs lisp or other lisp dialects, and
> it could also show up in other languages like C.
>
> What would be safer? [...]


Perhaps it would make sense to let the syntax vary by source language. 
Like, elisp could have something like ;;((def))\n and C something like
/*((def))*/.

Tom Breton

Re: Re: Release 6.17

[Samuel Wales]

I have a reply under the subject, "extensible syntax".

One possibility is this: if the syntax exists in a given language
(fairly unlikely), then you simply escape like this: \c = c for all c
(including \ itself).

-- 
For personal gain, myalgic encephalomyelitis denialists are knowingly
causing further suffering and death by grossly corrupting science.  Do
you care about the world?
http://www.meactionuk.org.uk/What_Is_ME_What_Is_CFS.htm

Re: Re: Release 6.17

[David Lord]

[-- Attachment #1.1: Type: text/plain, Size: 427 bytes --]

Carsten,

2009/1/4 Carsten Dominik <dominik@science.uva.nl>:
>
>  <<name>>    like the other Org-mode targets?  That would make sense.
>             Does anyone know a language where this would be used
>             in real life?  It would make it harder to write about
>             Org-mode, though.

Yes, Oracle pl/sql uses that for loop labels.  You might also want to check
ADA since pl/sql is based on it.

-- David Lord

[-- Attachment #1.2: Type: text/html, Size: 1105 bytes --]

[-- Attachment #2: Type: text/plain, Size: 204 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Re: Release 6.17

[Rick Moynihan]

Carsten Dominik wrote:
> On Jan 4, 2009, at 3:33 PM, Steven E. Harris wrote:
> 
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>
>>> Code references use special labels embedded directly into the source
>>> code.  Such labels look like "((name))" and must be unique within a
>>> document.
>> How does the parser know that, say, "((def))" is not a valid  
>> expression
>> in the surrounding Lisp forms? Is it important that it be separated by
>> space, or be the last token on the line?
>>
>> Trying to concoct a motivating example, consider a structure  
>> represented
>> as nested lists:
>>
>> ,----
>> | '(a
>> |   ((b c) d)
>> |   (((e) f))    ((def))
>> |   g)
>> `----
>>
>> Without knowing what the enclosing `quote' form means, how do know  
>> that
>> "((def))" is not part of it?
> 
> Hi Steven,
> 
> good question, and the answer is that is does not know,
> cannot know, because this is a feature that is supposed
> to work for any kind of example, an the parser cannot
> know all possible syntaxes :-)
> 
> This idea is to make this work in a heuristic way, by using something
> that is unlikely enough to occur in real code.
> 
> You are right that what I am using might be too
> dangerous for emacs lisp or other lisp dialects, and
> it could also show up in other languages like C.
> 
> What would be safer?
> 
>   <<name>>    like the other Org-mode targets?  That would make sense.
>               Does anyone know a language where this would be used
>               in real life?  It would make it harder to write about
>               Org-mode, though.
> 
> Or do we need another option, so that, if needed, we could switch do
> a different syntax?

Is a good work around not to simply supply the marker inside an inline 
comment, e.g.

,----
| '(a
|   ((b c) d)
|   (((e) f))   ;; ((def))
|   g)
`----

The advantage to this approach is that you can keep your code 
executable, which is really nice if you're writing documentation and 
want to be able to make sure the code always runs and is never broken. 
This solution seems to be more sensible than supporting different link 
markers etc... though the <<def>> does seem more consistent.

It might even be possible to link the ((def)) to the comment that 
describes it, so the links between code and comments are bidirectional.

Just some food for thought! :-)

R.

Re: Re: Release 6.17

[Carsten Dominik]

Hi Steven,

thank you for your thoughtful post and everyone else for chiming in with
useful suggestions.

I have just uploaded 6.17a which revamps the codeline references stuff,
in the following way:

1. The default label now looks like      (ref:name)

2. The default format is defined in org-coderef-label-format,
    with the default value "(ref:%s)".

3. You can change the format for each individual snippet with the -l  
switch:

       #+BEGIN_SRC pascal -n -r -l "((%s))"

4. Links to the labels have also changed, they are now

        [[(name)]]  or [[(name)][in line (name)]]

    instead of

        [[((name))]]  or [[((name))][in line ((name))]]

    i.e. only single parenthesis around the label name.

5. For technical reasons, there are currently some restrictions
    to what you can use as label format:

    - Do not use the character special in HTML:  `<', `>', and `&'.

    - Use something that will not be split up into sections
      with different fonts by font-lock/htmlize.  For example,
      in pascal-mode, "{{%s}}" will not work (I know nothing of
      Pascal, was just something I tried).

    The reason for both restrictions is that the current
    implementation looks for the labels only *after* htmlize has
    done its work on the example.  Clearly it would be good to
    change this, but it is non-trivial and I won't do it until
    I see that it is really necessary.

Let's see how ar we get with this.

- Carsten

On Jan 4, 2009, at 9:24 PM, Steven E. Harris wrote:

> Carsten Dominik <dominik@science.uva.nl> writes:
>
>> This idea is to make this work in a heuristic way, by using something
>> that is unlikely enough to occur in real code.
>
> And that is a tough problem, as code is usually defined as stuff that
> contains all kinds of weird (and often paired) delimiters.
>
> [...]
>
>> What would be safer?
>>
>> <<name>>    like the other Org-mode targets?  That would make sense.
>>             Does anyone know a language where this would be used
>>             in real life?  It would make it harder to write about
>>             Org-mode, though.
>>
>> Or do we need another option, so that, if needed, we could switch  
>> do a
>> different syntax?
>
> This reminds me of the "leaning toothpick" problem with regular
> expression syntax; Perl and some other languages adopted the  
> flexibility
> to accept any "matching" delimiters (either the same character used
> twice or a balancing pair) in lieu of the default '/' delimiter
> character. There was the need to have the delimiters be able to "get  
> out
> of the way" of the dominant syntax within that particular regular
> expression. Here, too, I expect that we'd either need to define
> language-specific escape hatches, or stop guessing and force the  
> user to
> define the active delimiters.
>
> What if the user could specify before each code block some "dispatch
> character" that then had to be followed by a more telling string, such
> as "#line:def". In that example, the octothorpe is the dispatch
> character, the "line:" is the belt-and-suspenders clarifying tag, and
> the "def" is the named label for that line. Force it to be at the  
> end of
> the line (perhaps modulo trailing space), as there should only be one
> definition per line.
>
> A regular expression match would look for
>
>  #line:([^)]+)\s*$
>  ^
>  |
>  + (not fixed)
>
> except that the dispatch character would need to be composed in and
> regex-quoted appropriately. Also, that one would tolerate anything  
> but a
> closing parenthesis in a label; it could be more restrictive to  
> tolerate
> something more commonly expected of an identifier such as  
> alphanumerics,
> dashes, and underscores.
>
> You could punt even further and just demand that the user provide a
> suitable regex for finding the line labels unambiguously. I'm just  
> leery
> of trying to pick a default that's expected to work not just within
> natural language, but within program source code.
>
> -- 
> Steven E. Harris
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode