I want to look at using Qi as a scripting language.
A. Does anybody have experience using Lisp as a scripting language;
CLisp esp.
B Has anybody got a copy of Red Hat Linux? You should have a copy of
CLisp on it.
> I want to look at using Qi as a scripting language. > A. Does anybody have experience using Lisp as a scripting language; > CLisp esp.
I use Lisp as a scripting language both common Lisp using Clisp and Elisp using emacs.
> B Has anybody got a copy of Red Hat Linux? You should have a copy of > CLisp on it.
I use CLisp on SuSE and Ubuntu Linux but not on Red Hat.
> Just a thought; anybody used Qi to do scripts?
I have thought about it as a fun and useful way to learn how to program in Qi but most scripts I write use regular expressions and/or escaped characters and at the moment these can only be supported in Qi by hacking the core language. My feeling is the issue of the comment character being the usual escape character and Qi not providing an alternative escape character limits its usefulness and this needs to be resolved particularly if Qi is to be used for scripting.
> My feeling is the issue of the comment character being the usual escape
> character and Qi not providing an alternative escape character limits its
> usefulness and this needs to be resolved particularly if Qi is to be used for
> scripting.
You can change this to what you want in 10 minutes.
>> My feeling is the issue of the comment character being the usual escape >> character and Qi not providing an alternative escape character limits its >> usefulness and this needs to be resolved particularly if Qi is to be used for >> scripting. > You can change this to what you want in 10 minutes.
Sure; Stefan posted the change to Qi to introduce \ as the escape character but this clashes with the use of \ as the block-comment delimiter so I posted a suggested change to Qi to introduce CL and Scheme style comments. For all this to hang together properly all the Qi source code needs to have comment style changed so support for \ as the block-comment delimiter can be removed. I am prepared to do this once but at the moment I would need to redo everything for every bug-fix, patch, addition and release of Qi unless you accept these changes or equivalent in the definition of the language.
Do you have a plan to support an escape character in the definition of the language at same point? If so would you choose \ ? If so what would you change the comment delimiter to be? And if not what would you choose as the escape character? What ever you decide I would be happy to attempt the implementation, changes to the current Qi sources and testing the result.
just to make things clear writing regular expressions means that you
probably need all
characters in the string and #\" is not possible to include in a
string in a vanilla Qi session.
witout some really clunky work (see my html coloring code). It is
really good to be able to escape it into strings.
I vote for having this feature in future vanilla Qi.
/Stefan
On 4 July, 13:25, Henry Weller <hwell...@googlemail.com> wrote:
> >> My feeling is the issue of the comment character being the usual escape
> >> character and Qi not providing an alternative escape character limits its
> >> usefulness and this needs to be resolved particularly if Qi is to be used for
> >> scripting.
> > You can change this to what you want in 10 minutes.
> Sure; Stefan posted the change to Qi to introduce \ as the escape character but
> this clashes with the use of \ as the block-comment delimiter so I posted a
> suggested change to Qi to introduce CL and Scheme style comments. For all this
> to hang together properly all the Qi source code needs to have comment style
> changed so support for \ as the block-comment delimiter can be removed. I am
> prepared to do this once but at the moment I would need to redo everything for
> every bug-fix, patch, addition and release of Qi unless you accept these changes
> or equivalent in the definition of the language.
> Do you have a plan to support an escape character in the definition of the
> language at same point? If so would you choose \ ? If so what would you change
> the comment delimiter to be? And if not what would you choose as the escape
> character? What ever you decide I would be happy to attempt the implementation,
> changes to the current Qi sources and testing the result.
There are so many options for programming in your own comment
delimiters into Qi using simple source hacking (about 10 lines of the
reader) or you can use strings like Norvig does in PAIP if you want.
Its a matter of personal taste and not a big issue at all. I leave
it to people to do as they wish because the sources are there if they
want to change them. I certainly wouldn't spend time worrying over
this one.
On 4 July, 12:25, Henry Weller <hwell...@googlemail.com> wrote:
> >> My feeling is the issue of the comment character being the usual escape
> >> character and Qi not providing an alternative escape character limits its
> >> usefulness and this needs to be resolved particularly if Qi is to be used for
> >> scripting.
> > You can change this to what you want in 10 minutes.
> Sure; Stefan posted the change to Qi to introduce \ as the escape character but
> this clashes with the use of \ as the block-comment delimiter so I posted a
> suggested change to Qi to introduce CL and Scheme style comments. For all this
> to hang together properly all the Qi source code needs to have comment style
> changed so support for \ as the block-comment delimiter can be removed. I am
> prepared to do this once but at the moment I would need to redo everything for
> every bug-fix, patch, addition and release of Qi unless you accept these changes
> or equivalent in the definition of the language.
> Do you have a plan to support an escape character in the definition of the
> language at same point? If so would you choose \ ? If so what would you change
> the comment delimiter to be? And if not what would you choose as the escape
> character? What ever you decide I would be happy to attempt the implementation,
> changes to the current Qi sources and testing the result.
> There are so many options for programming in your own comment
> delimiters into Qi using simple source hacking (about 10 lines of the
> reader) or you can use strings like Norvig does in PAIP if you want.
> Its a matter of personal taste and not a big issue at all. I leave
> it to people to do as they wish because the sources are there if they
> want to change them. I certainly wouldn't spend time worrying over
> this one.
> On 4 July, 12:25, Henry Weller <hwell...@googlemail.com> wrote:
> > Mark,
> > >> My feeling is the issue of the comment character being the usual escape
> > >> character and Qi not providing an alternative escape character limits its
> > >> usefulness and this needs to be resolved particularly if Qi is to be used for
> > >> scripting.
> > > You can change this to what you want in 10 minutes.
> > Sure; Stefan posted the change to Qi to introduce \ as the escape character but
> > this clashes with the use of \ as the block-comment delimiter so I posted a
> > suggested change to Qi to introduce CL and Scheme style comments. For all this
> > to hang together properly all the Qi source code needs to have comment style
> > changed so support for \ as the block-comment delimiter can be removed. I am
> > prepared to do this once but at the moment I would need to redo everything for
> > every bug-fix, patch, addition and release of Qi unless you accept these changes
> > or equivalent in the definition of the language.
> > Do you have a plan to support an escape character in the definition of the
> > language at same point? If so would you choose \ ? If so what would you change
> > the comment delimiter to be? And if not what would you choose as the escape
> > character? What ever you decide I would be happy to attempt the implementation,
> > changes to the current Qi sources and testing the result.
> just to make things clear writing regular expressions means that you
> probably need all
> characters in the string and #\" is not possible to include in a
> string in a vanilla Qi session.
> witout some really clunky work (see my html coloring code). It is
> really good to be able to escape it into strings.
> I vote for having this feature in future vanilla Qi.
> /Stefan
> On 4 July, 13:25, Henry Weller <hwell...@googlemail.com> wrote:
> > Mark,
> > >> My feeling is the issue of the comment character being the usual escape
> > >> character and Qi not providing an alternative escape character limits its
> > >> usefulness and this needs to be resolved particularly if Qi is to be used for
> > >> scripting.
> > > You can change this to what you want in 10 minutes.
> > Sure; Stefan posted the change to Qi to introduce \ as the escape character but
> > this clashes with the use of \ as the block-comment delimiter so I posted a
> > suggested change to Qi to introduce CL and Scheme style comments. For all this
> > to hang together properly all the Qi source code needs to have comment style
> > changed so support for \ as the block-comment delimiter can be removed. I am
> > prepared to do this once but at the moment I would need to redo everything for
> > every bug-fix, patch, addition and release of Qi unless you accept these changes
> > or equivalent in the definition of the language.
> > Do you have a plan to support an escape character in the definition of the
> > language at same point? If so would you choose \ ? If so what would you change
> > the comment delimiter to be? And if not what would you choose as the escape
> > character? What ever you decide I would be happy to attempt the implementation,
> > changes to the current Qi sources and testing the result.
>> (make-string "here is a string in a string: ~S" "howdy")
Yep that eases my pain a little, but still writing regular expressions
means that you
need just one " sometimes. Maybe there is a trick to do this as well.
Stefan
On 5 July, 00:00, Mark Tarver <dr.mtar...@ukonline.co.uk> wrote:
> (make-string "here is a string in a string: ~S" "howdy")
> gives
> "here is a string in a string: \"howdy\"" : string
> If you want to search the string using Qi you have to use 'explode' to
> coerce it to a list of characters.
> Mark
> On 4 July, 22:18, snorgers <stefan.ta...@spray.se> wrote:
> > just to make things clear writing regular expressions means that you
> > probably need all
> > characters in the string and #\" is not possible to include in a
> > string in a vanilla Qi session.
> > witout some really clunky work (see my html coloring code). It is
> > really good to be able to escape it into strings.
> > I vote for having this feature in future vanilla Qi.
> > /Stefan
> > On 4 July, 13:25, Henry Weller <hwell...@googlemail.com> wrote:
> > > Mark,
> > > >> My feeling is the issue of the comment character being the usual escape
> > > >> character and Qi not providing an alternative escape character limits its
> > > >> usefulness and this needs to be resolved particularly if Qi is to be used for
> > > >> scripting.
> > > > You can change this to what you want in 10 minutes.
> > > Sure; Stefan posted the change to Qi to introduce \ as the escape character but
> > > this clashes with the use of \ as the block-comment delimiter so I posted a
> > > suggested change to Qi to introduce CL and Scheme style comments. For all this
> > > to hang together properly all the Qi source code needs to have comment style
> > > changed so support for \ as the block-comment delimiter can be removed. I am
> > > prepared to do this once but at the moment I would need to redo everything for
> > > every bug-fix, patch, addition and release of Qi unless you accept these changes
> > > or equivalent in the definition of the language.
> > > Do you have a plan to support an escape character in the definition of the
> > > language at same point? If so would you choose \ ? If so what would you change
> > > the comment delimiter to be? And if not what would you choose as the escape
> > > character? What ever you decide I would be happy to attempt the implementation,
> > > changes to the current Qi sources and testing the result.
> Probably the easiest solution is to have a programmable comment > delimiter set by default to \.
But if \ is the default comment delimiter what should be the default escape character or do you think that character escaping is not needed is Qi as indicated in your previous Emails?
I have no problem adding CL style comments to Qi and I have already done so and posted the patch (I could even extend the approach to support a programmable comment delimiter as you propose); my problem is if I make \ the escape character it cannot also be the comment delimiter and all the Qi sources would have to be edited to change the comment delimiters. I can also do this as mentioned in my previous Email but then it becomes a significant maintenance problem and if I then post any Qi code I write people can only use it they use my patched and edited version of Qi.
When reading in a file with load we have the problem that that whole
file goes through
the reader before it is interpreted. Now we might want to be able to
inject some code
in the beginning of a file to describe the usage of some syntactic
constructs. You could
solve this by using multiple files but it is a mess and a pain or?
But anyway one idea to solve this issue would be to set the syntactic
preferences in the
beginning of the file.
/Stefan
On 5 July, 00:34, Henry Weller <hwell...@googlemail.com> wrote:
> > Probably the easiest solution is to have a programmable comment
> > delimiter set by default to \.
> But if \ is the default comment delimiter what should be the default escape
> character or do you think that character escaping is not needed is Qi as
> indicated in your previous Emails?
> I have no problem adding CL style comments to Qi and I have already done so and
> posted the patch (I could even extend the approach to support a programmable
> comment delimiter as you propose); my problem is if I make \ the escape
> character it cannot also be the comment delimiter and all the Qi sources would
> have to be edited to change the comment delimiters. I can also do this as
> mentioned in my previous Email but then it becomes a significant maintenance
> problem and if I then post any Qi code I write people can only use it they use
> my patched and edited version of Qi.
If you want to parse a file then use read-file-as-charlist (very fast) and tokenise to a list of strings using your tokeniser. Then proceed as normal. This is the way to process HTML.
Mark
----- Original Message ----- From: "snorgers" <stefan.ta...@spray.se>
To: "Qilang" <Qilang@googlegroups.com>
Sent: Saturday, July 04, 2009 11:23 PM
Subject: Re: Using Qi as a scripting language: queries
>> (make-string "here is a string in a string: ~S" "howdy")
Yep that eases my pain a little, but still writing regular expressions
means that you
need just one " sometimes. Maybe there is a trick to do this as well.
Stefan
On 5 July, 00:00, Mark Tarver <dr.mtar...@ukonline.co.uk> wrote:
> (make-string "here is a string in a string: ~S" "howdy")
> gives
> "here is a string in a string: \"howdy\"" : string
> If you want to search the string using Qi you have to use 'explode' to
> coerce it to a list of characters.
> Mark
> On 4 July, 22:18, snorgers <stefan.ta...@spray.se> wrote:
> > just to make things clear writing regular expressions means that you
> > probably need all
> > characters in the string and #\" is not possible to include in a
> > string in a vanilla Qi session.
> > witout some really clunky work (see my html coloring code). It is
> > really good to be able to escape it into strings.
> > I vote for having this feature in future vanilla Qi.
> > /Stefan
> > On 4 July, 13:25, Henry Weller <hwell...@googlemail.com> wrote:
> > > Mark,
> > > >> My feeling is the issue of the comment character being the usual > > > >> escape
> > > >> character and Qi not providing an alternative escape character > > > >> limits its
> > > >> usefulness and this needs to be resolved particularly if Qi is to > > > >> be used for
> > > >> scripting.
> > > > You can change this to what you want in 10 minutes.
> > > Sure; Stefan posted the change to Qi to introduce \ as the escape > > > character but
> > > this clashes with the use of \ as the block-comment delimiter so I > > > posted a
> > > suggested change to Qi to introduce CL and Scheme style comments. For > > > all this
> > > to hang together properly all the Qi source code needs to have comment > > > style
> > > changed so support for \ as the block-comment delimiter can be > > > removed. I am
> > > prepared to do this once but at the moment I would need to redo > > > everything for
> > > every bug-fix, patch, addition and release of Qi unless you accept > > > these changes
> > > or equivalent in the definition of the language.
> > > Do you have a plan to support an escape character in the definition of > > > the
> > > language at same point? If so would you choose \ ? If so what would > > > you change
> > > the comment delimiter to be? And if not what would you choose as the > > > escape
> > > character? What ever you decide I would be happy to attempt the > > > implementation,
> > > changes to the current Qi sources and testing the result.
My plan is to write Qi wrappers for the cl-ppcre library and then I can use all the perl-style regular expressions I already have which currently include \s. I can't see an easy way to do this without adding support for \ in Qi strings (i.e. reinstate string functionality present in the underlying CL language), or at least another escape character which \ can easily be translated to \ when transferring regular-expressions from elsewhere. Can you suggest how this might be done without introducing an escape character into Qi?
> My plan is to write Qi wrappers for the cl-ppcre library and then I can use all
> the perl-style regular expressions I already have which currently include \s. I
> can't see an easy way to do this without adding support for \ in Qi strings
> (i.e. reinstate string functionality present in the underlying CL language), or
> at least another escape character which \ can easily be translated to \ when
> transferring regular-expressions from elsewhere. Can you suggest how this might
> be done without introducing an escape character into Qi?
----- Original Message ----- From: "Henry Weller" <hwell...@googlemail.com>
To: <Qilang@googlegroups.com>
Sent: Saturday, July 04, 2009 11:34 PM
Subject: Re: Using Qi as a scripting language: queries
> Mark,
>> Probably the easiest solution is to have a programmable comment
>> delimiter set by default to \.
> But if \ is the default comment delimiter what should be the default > escape
> character or do you think that character escaping is not needed is Qi as
> indicated in your previous Emails?
> I have no problem adding CL style comments to Qi and I have already done > so and
> posted the patch (I could even extend the approach to support a > programmable
> comment delimiter as you propose); my problem is if I make \ the escape
> character it cannot also be the comment delimiter and all the Qi sources > would
> have to be edited to change the comment delimiters. I can also do this as
> mentioned in my previous Email but then it becomes a significant > maintenance
> problem and if I then post any Qi code I write people can only use it they > use
> my patched and edited version of Qi.
> I'm kind of stuck seeing what it is you are having difficulty with. Can you
> post a concrete example?
> Mark
> ----- Original Message -----
> From: "Henry Weller" <hwell...@googlemail.com>
> To: <Qilang@googlegroups.com>
> Sent: Saturday, July 04, 2009 11:34 PM
> Subject: Re: Using Qi as a scripting language: queries
> > Mark,
> >> Probably the easiest solution is to have a programmable comment
> >> delimiter set by default to \.
> > But if \ is the default comment delimiter what should be the default
> > escape
> > character or do you think that character escaping is not needed is Qi as
> > indicated in your previous Emails?
> > I have no problem adding CL style comments to Qi and I have already done
> > so and
> > posted the patch (I could even extend the approach to support a
> > programmable
> > comment delimiter as you propose); my problem is if I make \ the escape
> > character it cannot also be the comment delimiter and all the Qi sources
> > would
> > have to be edited to change the comment delimiters. I can also do this as
> > mentioned in my previous Email but then it becomes a significant
> > maintenance
> > problem and if I then post any Qi code I write people can only use it they
> > use
> > my patched and edited version of Qi.
I have not used Qi or lisp as a scripting environment, I like the idea
of using it though
and love to help making a smooth qi environment for scripting. Clisp
should not be a problem.
Cheers
Stefan
On 5 July, 14:58, snorgers <stefan.ta...@spray.se> wrote:
> which can be used to do an alternative Qi vanilla string parsing. It
> containes one "
> and I can only make that regex by building it from characters.
> On 5 July, 13:29, "Mark Tarver" <dr.mtar...@ukonline.co.uk> wrote:
> > I'm kind of stuck seeing what it is you are having difficulty with. Can you
> > post a concrete example?
> > Mark
> > ----- Original Message -----
> > From: "Henry Weller" <hwell...@googlemail.com>
> > To: <Qilang@googlegroups.com>
> > Sent: Saturday, July 04, 2009 11:34 PM
> > Subject: Re: Using Qi as a scripting language: queries
> > > Mark,
> > >> Probably the easiest solution is to have a programmable comment
> > >> delimiter set by default to \.
> > > But if \ is the default comment delimiter what should be the default
> > > escape
> > > character or do you think that character escaping is not needed is Qi as
> > > indicated in your previous Emails?
> > > I have no problem adding CL style comments to Qi and I have already done
> > > so and
> > > posted the patch (I could even extend the approach to support a
> > > programmable
> > > comment delimiter as you propose); my problem is if I make \ the escape
> > > character it cannot also be the comment delimiter and all the Qi sources
> > > would
> > > have to be edited to change the comment delimiters. I can also do this as
> > > mentioned in my previous Email but then it becomes a significant
> > > maintenance
> > > problem and if I then post any Qi code I write people can only use it they
> > > use
> > > my patched and edited version of Qi.
> I'm kind of stuck seeing what it is you are having difficulty with. Can you > post a concrete example?
My initial problem came form embedding strings in documentation strings:
"This is some documentation for the string \"a string\" and more stuff"
Stefan posted a patch to add support for the \ escape character which solved this problem but introduces a parsing problem due to the ambiguous use of \ as the escape character and the comment delimiter, for example how could you have escaped characters in comment strings?. Another problem this ambiguity introduces is adding support for font-locking and other nice features to editors such as Emacs which already have built-in rules for escape characters and comment delimiters but which do not allow both to be the same. This issue can in part be resolved using context analysis but this is rather complicated to editors and makes Qi a less attractive language to work with. There is more detail about my fight with Qi over escaping characters in previous threads which I can dig up if you would like to review the problems and possible solutions.
My feeling is that either an alternative escape character to \ should be chosen or the comment delimiter cannot remain \ or character escaping is not supported as is currently the case. I cannot achieve my aims without adding support for an escape character and would rather \ was chosen so my vote is for changing the comment delimiter but I really do not mind to what it is changed. I only suggested the CL-style (with a test implementation) because it is consistent with the underlying language but the Haskell, C++, Java etc. styles are all fine as well as is anything else which does not clash with other character sequences used the definition of the language.
And you want to comment it out or you want to discuss it in a comment.
and you get into these issues, not so smooth. I can live with this but
it is not
a selling point for Qi.
/Stefan
On 5 July, 20:49, Henry Weller <HWell...@googlemail.com> wrote:
> > I'm kind of stuck seeing what it is you are having difficulty with. Can you
> > post a concrete example?
> My initial problem came form embedding strings in documentation strings:
> "This is some documentation for the string \"a string\" and more stuff"
> Stefan posted a patch to add support for the \ escape character which solved
> this problem but introduces a parsing problem due to the ambiguous use of \ as
> the escape character and the comment delimiter, for example how could you have
> escaped characters in comment strings?. Another problem this ambiguity
> introduces is adding support for font-locking and other nice features to editors
> such as Emacs which already have built-in rules for escape characters and
> comment delimiters but which do not allow both to be the same. This issue can
> in part be resolved using context analysis but this is rather complicated to
> editors and makes Qi a less attractive language to work with. There is more
> detail about my fight with Qi over escaping characters in previous threads which
> I can dig up if you would like to review the problems and possible solutions.
> My feeling is that either an alternative escape character to \ should be chosen
> or the comment delimiter cannot remain \ or character escaping is not supported
> as is currently the case. I cannot achieve my aims without adding support for
> an escape character and would rather \ was chosen so my vote is for changing the
> comment delimiter but I really do not mind to what it is changed. I only
> suggested the CL-style (with a test implementation) because it is consistent
> with the underlying language but the Haskell, C++, Java etc. styles are all fine
> as well as is anything else which does not clash with other character sequences
> used the definition of the language.
> My initial problem came form embedding strings in documentation strings:
> "This is some documentation for the string \"a string\" and more stuff"
> Stefan posted a patch to add support for the \ escape character which > solved
> this problem but introduces a parsing problem due to the ambiguous use of > \ as
> the escape character and the comment delimiter, for example how could you > have
> escaped characters in comment strings?.
As I pointed out this is not a problem. You *can* construct these strings in Qi, you just
cannot read them back in to the Qi top level. But not everything you can construct can be read
back in - the evaluated form of (/. X X) etc - which holds for CL too btw. Likewise there is
a class of unreadable strings in Qi which cannot be read in verbatim but they can always be
constructed. Including the dreaded ^ which is is the nuke key. And there are unprintable
characters in CL too.
> Another problem this ambiguity
> introduces is adding support for font-locking and other nice features to > editors
> such as Emacs which already have built-in rules for escape characters and
> comment delimiters but which do not allow both to be the same.
OK; so it suits Emacs less because this possibility was not envisaged by the designers.
On the other hand following your approach would mean rewriting every commented Qi
program ever written just to make font locking in Emacs easy. And some people would
not like that either. (Me actually, I don't use Emacs).
I think what you need is a programmable delimiter which you can set
(think of SET-SYNTAX-FROM-CHAR). It will allow your Qi programs to be portable
and you can choose whatever delimiter style you like.
> in part be resolved using context analysis but this is rather complicated > to
> editors and makes Qi a less attractive language to work with. There is > more
> detail about my fight with Qi over escaping characters in previous threads > which
> I can dig up if you would like to review the problems and possible > solutions.
> My feeling is that either an alternative escape character to \ should be > chosen
> or the comment delimiter cannot remain \ or character escaping is not > supported
> as is currently the case. I cannot achieve my aims without adding support > for
> an escape character and would rather \ was chosen so my vote is for > changing the
> comment delimiter but I really do not mind to what it is changed. I only
> suggested the CL-style (with a test implementation) because it is > consistent
> with the underlying language but the Haskell, C++, Java etc. styles are > all fine
> as well as is anything else which does not clash with other character > sequences
> used the definition of the language.
OK; then we will have programmable delimiters and a programmable
escape character and maybe a programmable abort ^ character too.
The question is how the defaults are set and for now it seems best to
set them to FPQi. Likely future candidates are C++ delimiters and \
for the escape.
I would suggest that you fix the delimiters to C++ syntax in your
programs if you wish and in the next release I'll include a
programmable feature for setting your delimiters etc. You will need
2-3 lines of boilerplate in all your Qi files.
We can have a plebiscite on the defaults at a later date.
Mark
On 5 July, 21:18, snorgers <stefan.ta...@spray.se> wrote:
> And you want to comment it out or you want to discuss it in a comment.
> and you get into these issues, not so smooth. I can live with this but
> it is not
> a selling point for Qi.
> /Stefan
> On 5 July, 20:49, Henry Weller <HWell...@googlemail.com> wrote:
> > Mark,
> > > I'm kind of stuck seeing what it is you are having difficulty with. Can you
> > > post a concrete example?
> > My initial problem came form embedding strings in documentation strings:
> > "This is some documentation for the string \"a string\" and more stuff"
> > Stefan posted a patch to add support for the \ escape character which solved
> > this problem but introduces a parsing problem due to the ambiguous use of \ as
> > the escape character and the comment delimiter, for example how could you have
> > escaped characters in comment strings?. Another problem this ambiguity
> > introduces is adding support for font-locking and other nice features to editors
> > such as Emacs which already have built-in rules for escape characters and
> > comment delimiters but which do not allow both to be the same. This issue can
> > in part be resolved using context analysis but this is rather complicated to
> > editors and makes Qi a less attractive language to work with. There is more
> > detail about my fight with Qi over escaping characters in previous threads which
> > I can dig up if you would like to review the problems and possible solutions.
> > My feeling is that either an alternative escape character to \ should be chosen
> > or the comment delimiter cannot remain \ or character escaping is not supported
> > as is currently the case. I cannot achieve my aims without adding support for
> > an escape character and would rather \ was chosen so my vote is for changing the
> > comment delimiter but I really do not mind to what it is changed. I only
> > suggested the CL-style (with a test implementation) because it is consistent
> > with the underlying language but the Haskell, C++, Java etc. styles are all fine
> > as well as is anything else which does not clash with other character sequences
> > used the definition of the language.
> OK; then we will have programmable delimiters and a programmable > escape character and maybe a programmable abort ^ character too. > The question is how the defaults are set and for now it seems best to > set them to FPQi. Likely future candidates are C++ delimiters and \ > for the escape.
I have coded CL and Scheme style comments but can easily change this code to support C++ style comments if you prefer and post it if you or others would like it. Given that the underlying language is CL why would you prefer to see the C++ style used? I don't mind either way as they offer equivalent functionality. I do however like the #; expression comment in Scheme which I have coded for Qi but which does not have an equivalent in C++.
> I would suggest that you fix the delimiters to C++ syntax in your > programs if you wish and in the next release I'll include a > programmable feature for setting your delimiters etc. You will need > 2-3 lines of boilerplate in all your Qi files.
> As I pointed out this is not a problem. You *can* construct these strings in > Qi, you just cannot read them back in to the Qi top level.
Yep, and this is a problem.
> But not everything you can construct can be read back in - the evaluated form > of (/. X X) etc - which holds for CL too btw.
Sure
> Likewise there is a class of unreadable strings in Qi which cannot be read in > verbatim but they can always be constructed. Including the dreaded ^ which is > is the nuke key. And there are unprintable characters in CL too.
Sure, but I think it is important to be able to handle the escape character in a simple way as it is so commonly used.
>> Another problem this ambiguity >> introduces is adding support for font-locking and other nice features to >> editors >> such as Emacs which already have built-in rules for escape characters and >> comment delimiters but which do not allow both to be the same. > OK; so it suits Emacs less because this possibility was not envisaged by the > designers.
Not just Emacs but all editors that I know of that have this kind of functionality. They generally use simple, efficient passing methods for font-locking etc. which do not handle ambiguities very well. Of course a complete Qi parser could be written in Elisp, or the scripting language for vim, or eclipse etc. but this would be a significant effort and one which is not needed for other languages.
> On the other hand following your approach would mean rewriting > every commented Qi program ever written just to make font locking in Emacs > easy.
The problem is not limited to Emacs; having \ as the escape character and the comment delimiter is a problem for all simple parsing strategies for Qi which are used in editors and possible other code analysing tools. My feeling is that Qi would benefit from this ambiguity being removed and a two-character comment delimiter introduced preferably with the option for having single line comments and even better the option for expression comments.
> I think what you need is a programmable delimiter which you can set > (think of SET-SYNTAX-FROM-CHAR). It will allow your Qi programs to be > portable > and you can choose whatever delimiter style you like.
OK. For now I will change my patch to use C++ style comments as you suggest. Shall I drop support for commenting expressions or are you interested in supporting this in a future Qi release. If you are interested in this functionality what delimiter would you use for it? At the moment I have
> As I pointed out this is not a problem. You *can* construct these strings in > Qi, you just cannot read them back in to the Qi top level. But not everything > you can construct can be read back in - the evaluated form of (/. X X) etc - > which holds for CL too btw. Likewise there is a class of unreadable strings > in Qi which cannot be read in verbatim but they can always be constructed. > Including the dreaded ^ which is is the nuke key.
I have just been playing with regular expression strings and it is indeed difficult to handle ^, e.g. in "[^abc]" which Qi cannot read in; can ^ be escaped as \^ in Qi-1.07?. What is the easiest way to read regular expressions in Qi? Do we need to write some regular expression creation functions to get around the problem of Qi using some of the regular expression characters for other purposes?
|
