q-lang-users — general discussion, questions, suggestions, etc.

[q-lang-users] Re: 7.1 candidate

[Albert G. <Dr....@t-...>]

John Cowan wrote:
> Can you send me the 7.1 candidate tarball, or make it available for
> download?  I'll test it on Cygwin.

Ok, it's available now in the new "rcs" section of the download area:
http://sourceforge.net/project/showfiles.php?group_id=96881&package_id=188958&release_id=416034

(Never mind that it's actually called RC2, I've already tagged an 
earlier version as 7_1RC1 in cvs, that's why.)

> I don't know if I mentioned that I successfully built 7.0 final.

Great, thanks for testing.

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] CVS issues/Q 7.1

[Albert G. <Dr....@t-...>]

Hi Yann!

Orlarey Yann wrote:
> If you need some bandwidth for an additional repository we would be
> happy to offer it...

Well, it looks like at least the file downloads still work on 
sourceforge ;-), so that shouldn't be a problem. But thanks for the offer.

Or did you mean to open up a secondary cvs repository at Grame? But is 
it possible to sync with different repositories from a single working 
copy? I've never done that kind of thing before.

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] CVS issues/Q 7.1

[Albert G. <Dr....@t-...>]

Tim Haynes wrote:
>>There also seem to be some issues with libtool on OSX, 
> 
> There are. I gather from talking with development at work that the mac's
> libtool does silly things.

I was talking about GNU automake+libtool here. For some reason I 
couldn't yet determine, the usual automakish way to build and link 
against dynamic libraries just doesn't work as it should on OSX. It's 
probably a GNU libtool bug, and I'll have to figure out a way to work 
around that. Or switch to a different build system altogether. Has 
anyone here already used scons, that seems to be pretty hot these days?

> It might be comparatively cool to aim for a Universal Binary build, with
> support for ppc32/64 and i386 all in the one set of executables. We use
> variations on:
> 
> CFLAGS="-O -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch ppc64 \
>         -arch i386"

Yeah, that sounds really cool, but I think I'll have to leave that to 
you Mac experts here. ;-) Once Q again builds cleanly on OSX, hopefully 
someone will step up and provide OSX packages for the others.

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [qlist] [q-lang-users] CVS issues/Q 7.1

[Albert G. <Dr....@t-...>]

Andrew Berg wrote:
> I tried a while ago to port Q to 64 bit, using a little bit of spare  
> time at work, where I have an AMD 64 bit machine running Ubuntu  Linux.  
> Since then I have become busy enough that I cannot devote  enough time 
> to do porting/development, but I could still do some  testing.

Hi Andrew, thanks for the offer! I think that as soon as I have a beta 
of 7.2 working on my G4 and Intel 64 bit systems I'll upload a release 
candidate and give you and Tim a notice so that you can start testing it 
on your machines and we can work out any remaining quirks.

> How much OS X support do you foresee?

Well, I really want to get the entire Q environment working again, 
including all the add-on modules. Actually I had that working at some 
point in time (during the 4.x releases I regularly ported to OSX and 
even provided binary packages), so that shouldn't be too difficult. One 
major stumbling stone, however, was that I couldn't figure out a way to 
make GNU automake+libtool link against a framework, so the only way I 
could get the Tcl/Tk module to work was with the X11-based Tcl/Tk which 
I compiled myself. But of course it would be preferable to link against 
the native (Aqua) version of Tcl/Tk which is provided as a framework. 
I'll also have to solve that problem in order to link against MidiShare 
which, if I'm not mistaken, is distributed as a framework rather than a 
simple dylib these days. So any advice on this will be greatly 
appreciated! :)

Interfacing to Objective C is an entirely different matter, however. 
Right now the only foreign language interface Q has is to C/C++, and the 
SWIG interface is built on top of that. But AFAIK SWIG doesn't support 
Objective C, and so I have no idea how to do a bridge to that language 
(which I've never used myself). If anyone would be willing to work on 
this, I'll be glad to provide as much help as I can, but I probably 
won't be able to do it myself. Especially since I want to do a complete 
overhaul of the interpreter core and start work on the bytecode -> 
native code compiler later this year. ;-)

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] CVS issues/Q 7.1

[Orlarey Y. <or...@gr...>]

Dear Albert,


> If anyone is interested in trying out the new release before I do the
> final touches, I can upload an up-to-date tarball as a release candidate.
If you need some bandwidth for an additional repository we would be
happy to offer it...

Yann

Re: [qlist] [q-lang-users] CVS issues/Q 7.1

[Tim H. <q...@st...>]

Andrew Berg <and...@ya...> writes:

> Hi, Albert.
> 
> I tried a while ago to port Q to 64 bit, using a little bit of spare time
> at work, where I have an AMD 64 bit machine running Ubuntu Linux. Since
> then I have become busy enough that I cannot devote enough time to do
> porting/development, but I could still do some testing.
> 
> 
> Also, at home I use a Macintosh with OS X. It is an Intel iMac. I know
> that the Core Duo chip supports 64 bits, but I don't know if OS X
> supports 64 bits on it.

I believe it does not.

> I also recall reading that the app framework is all 32 bits still, so OS
> X 64 bit processes cannot do much more than write to standard out. If I
> recall, Apple decided that 64 bitness is mostly advantageous for
> scientific or server workloads, which do not need a shiny UI.

Yes; Apple have not ported Carbon to 64-bit environments. 

~Tim
-- 
<http://spodzone.org.uk/>

Re: [q-lang-users] CVS issues/Q 7.1

[Tim H. <q...@st...>]

Albert Graef <Dr....@t-...> writes:

[snip]
> There also seem to be some issues with libtool on OSX, 

There are. I gather from talking with development at work that the mac's
libtool does silly things.

It might be comparatively cool to aim for a Universal Binary build, with
support for ppc32/64 and i386 all in the one set of executables. We use
variations on:

CFLAGS="-O -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch ppc64 \
        -arch i386"

> but I first have to set up an OSX system with gcc and Fink before I can
> look into this. BTW, what do the OSX hackers recommend these days to get
> the necessary dependencies working? Fink or Darwin ports?

I have been simultaneously most_happy and most_frustrated with darwinports
(nice interface, keeps itself to itself in whatever --prefix you specify,
but can be very flaky to keep uptodate) and am currently enduring a phase
of having both gentoo's portage system and Fink installed simultaneously.

> > Hmm. I could spare a little time to help, perhaps?
> 
> That's great, thanks for the offer. I'll get back to you on that... :)

OK :)

~Tim
-- 
<http://spodzone.org.uk/>

Re: [qlist] [q-lang-users] CVS issues/Q 7.1

[Andrew B. <and...@ya...>]

Hi, Albert.

I tried a while ago to port Q to 64 bit, using a little bit of spare  
time at work, where I have an AMD 64 bit machine running Ubuntu  
Linux.  Since then I have become busy enough that I cannot devote  
enough time to do porting/development, but I could still do some  
testing.

Also, at home I use a Macintosh with OS X.  It is an Intel iMac.  I  
know that the Core Duo chip supports 64 bits, but I don't know if OS  
X supports 64 bits on it.  I also recall reading that the app  
framework is all 32 bits still, so OS X 64 bit processes cannot do  
much more than write to standard out.  If I recall, Apple decided  
that 64 bitness is mostly advantageous for scientific or server  
workloads, which do not need a shiny UI.

How much OS X support do you foresee?  On the low end of the effort  
scale would be just a basic command line, probably a few hours worth  
of effort.  At the other would be an Objective-C bridge with access  
to Cocoa, but I have not done that kind of port before, so I could  
only guess at the time required.  Lots of other projects do that kind  
of bridge, though, so I would imagine it to be in the range of a week  
or three of development time.

-andrew

On May 9, 2006, at 3:39 PM, Albert Graef wrote:

> Hi,
>
> not much traffic here for a while, so I thought a quick update was  
> in order. ;-)
>
> As some of you may have noticed already, anonymous cvs is currently  
> lagging behind developer cvs quite a lot (8 weeks!), apparently  
> because sf.net is currently deploying new cvs servers. There seem  
> to be some serious issues with the new servers, though (in fact,  
> currently even developer cvs doesn't work any more for me and lots  
> of other sf-hosted projects). That's unfortunate because Q 7.1 is  
> almost ready in cvs. :(
>
> I filed support requests on these issues but didn't receive a reply  
> yet (and if I see the number of cvs support requests piling up, I  
> doubt that I get a reply very soon), so I don't know when this mess  
> will be fixed.
>
> FYI, a quick summary of the new features in Q 7.1 is attached to  
> this post. The most important changes are in the warning messages  
> of the compiler and the handling of enumerations, streams and list  
> comprehensions, and there is still one more experimental new  
> feature on my TODO list for this release, which should further  
> improve the handling of lazy data structures.
>
> If anyone is interested in trying out the new release before I do  
> the final touches, I can upload an up-to-date tarball as a release  
> candidate.
>
> The road ahead: For Q 7.2, I'd like to work on the 64 bit support  
> and renew the support for OS X. Please let me know if you're  
> willing to help with that. (Currently I only have access to Intel  
> 64 bit machines, so any beta testers with other setups like AMD64,  
> G5 etc. are welcome...)
>
> Cheers,
> Albert
>
> -- 
> Dr. Albert Gr"af
> Dept. of Music-Informatics, University of Mainz, Germany
> Email:  Dr....@t-..., ag...@mu...
> WWW:    http://www.musikinformatik.uni-mainz.de/ag
> * 7.1	(Unreleased, work in progress.)
>
> This release sports the following experimental new features:
>
> - Sentinel expressions: Clib now provides these as a special kind of
>   references to expressions whose evaluation is deferred until the  
> sentinel is
>   garbage-collected. Sentinels are a means to implement ordinary Q  
> data
>   structures which perform automatic cleanup in the same fashion as  
> some
>   built-in and external data types.
>
> - Improved warning messages: Undeclared variable symbols are not  
> reported with
>   -w anymore (these messages are often a nuisance if you use lambda  
> a lot),
>   and function symbols will only be reported as undeclared at the  
> end of a
>   source file, if they are neither imported nor declared _anywhere_  
> in the
>   file (where appearances of a function symbol on the left-hand  
> side of
>   equations and variable definitions count as implicit  
> declarations). If you
>   want to play it *really* safe, there is a new warning level -w2  
> a.k.a.
>   --pedantic which warns about *all* function and variable symbols  
> which are
>   used without a prior *explicit* declaration (i.e., when using  
> that option
>   you really have to declare each and every symbol explicitly, to  
> make the
>   compiler happy).
>
> - New builtins and standard library functions: The `+' and `-'  
> operators can
>   now be used to perform simple arithmetics on enumeration types.  
> If X is an
>   enumeration type member then X+N and X-N yields the Nth successor  
> and
>   predecessor of X, respectively, and if X and Y are members of the  
> same
>   enumeration type then X-Y yields the integer N s.t. X=Y+N.  
> Moreover, typec.q
>   offers a new typechecking predicate for enumeration type members  
> (isenum),
>   stream.q has a few new stream generation functions (repeat,  
> repeatn, cycle),
>   and `cat' and `tuple' now work with streams, too.
>
> - Syntactic sugar for streams and comprehensions: Streams can now  
> be written
>   in the same kind of notation as lists, but using curly braces  
> instead of
>   brackets, as in `{1,2,3}' or `{X|Xs}'. The new notation is  
> translated to an
>   appropriate application involving the stream constructors `bin'  
> and `nil'
>   (which are now predefined as builtins) by the parser, and is also  
> used when
>   an expression is printed. Moreover, the parser recognizes the  
> notations
>   `{1..10}' and `{1..}' for finite and infinite stream  
> enumerations, and
>   there's also new syntactic sugar for list and stream  
> comprehensions. E.g.,
>   you can now write `[2*X^2 : X in Xs, even X]' as a shorthand for  
> `listof
>   (2*X^2) (X in Xs, even X)'. Stream comprehensions (streamof) work  
> the same,
>   using curly braces instead of the brackets.
>
> - Other language extensions: There's an alternative syntax `type X  
> == Y' to
>   declare type aliases and the `var' keyword can now be used in  
> front of a
>   variable symbol on the right-hand side of an equation or variable  
> definition
>   to escape free variable symbols and declare them on the fly.
>
> Besides this, a rather annoying bug in the pattern matcher has been  
> fixed. As
> usual, you should check out the ChangeLog file and the language  
> manual for all
> the gory details.

Re: [q-lang-users] CVS issues/Q 7.1

[Albert G. <Dr....@t-...>]

Tim Haynes wrote:
> Yes, sf.net cvs has been screwed for a while :/ 

Today at least they updated the site status page... after cvs has been 
completely disfunctional for two days. Hopefully devel cvs should be 
back up and running by the end of the week, but there's no word yet when 
they will finally sync anon cvs again.

> I would be..

Ok, I'll upload a tarball and RPMs later tonight.

> This would explain why I had problems building on my AMD64 and G5 boxen.

Yes, I've had reports that the interpreter is broken on 64 bit. Probably 
some bad pointer arithmetic in the symbol table code, that should be 
easy enough to fix once I find the time.

There also seem to be some issues with libtool on OSX, but I first have 
to set up an OSX system with gcc and Fink before I can look into this. 
BTW, what do the OSX hackers recommend these days to get the necessary 
dependencies working? Fink or Darwin ports?

> Hmm. I could spare a little time to help, perhaps?

That's great, thanks for the offer. I'll get back to you on that... :)

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] CVS issues/Q 7.1

[Tim H. <q...@st...>]

Albert Graef <Dr....@t-...> writes:

> not much traffic here for a while, so I thought a quick update was in
> order. ;-)
> 
> 
> As some of you may have noticed already, anonymous cvs is currently
> lagging behind developer cvs quite a lot (8 weeks!), apparently because
> sf.net is currently deploying new cvs servers. There seem to be some
> serious issues with the new servers, though (in fact, currently even
> developer cvs doesn't work any more for me and lots of other sf-hosted
> projects). That's unfortunate because Q 7.1 is almost ready in cvs. :(

Yes, sf.net cvs has been screwed for a while :/ 

> If anyone is interested in trying out the new release before I do the
> final touches, I can upload an up-to-date tarball as a release candidate.

I would be..

> The road ahead: For Q 7.2, I'd like to work on the 64 bit support and
> renew the support for OS X. Please let me know if you're willing to help
> with that. (Currently I only have access to Intel 64 bit machines, so any
> beta testers with other setups like AMD64, G5 etc. are welcome...)

This would explain why I had problems building on my AMD64 and G5 boxen.
Hmm. I could spare a little time to help, perhaps?

~Tim
-- 
<http://pig.sty.nu/>

Re: [q-lang-users] Is this the Q we all know and love?

[Albert G. <Dr....@t-...>]

Hi Walter, sorry, it looks like my mail client ate your post...

On 2006-02-06 WW wrote:
 > http://www.tiobe.com/tpci.htm - at number 49.

Yes, looks like this indeed refers to "the Q we all know and love".

Unfortunately, it has since fallen down to position >=50 again. :( But 
it has some good company there: Clean, Erlang, Haskell, ... AFAICT, the 
only modern FPL under the first 50 is ML. Kinda depressing, isn't it?

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

[q-lang-users] CVS issues/Q 7.1

[Albert G. <Dr....@t-...>]

Hi,

not much traffic here for a while, so I thought a quick update was in 
order. ;-)

As some of you may have noticed already, anonymous cvs is currently 
lagging behind developer cvs quite a lot (8 weeks!), apparently because 
sf.net is currently deploying new cvs servers. There seem to be some 
serious issues with the new servers, though (in fact, currently even 
developer cvs doesn't work any more for me and lots of other sf-hosted 
projects). That's unfortunate because Q 7.1 is almost ready in cvs. :(

I filed support requests on these issues but didn't receive a reply yet 
(and if I see the number of cvs support requests piling up, I doubt that 
I get a reply very soon), so I don't know when this mess will be fixed.

FYI, a quick summary of the new features in Q 7.1 is attached to this 
post. The most important changes are in the warning messages of the 
compiler and the handling of enumerations, streams and list 
comprehensions, and there is still one more experimental new feature on 
my TODO list for this release, which should further improve the handling 
of lazy data structures.

If anyone is interested in trying out the new release before I do the 
final touches, I can upload an up-to-date tarball as a release candidate.

The road ahead: For Q 7.2, I'd like to work on the 64 bit support and 
renew the support for OS X. Please let me know if you're willing to help 
with that. (Currently I only have access to Intel 64 bit machines, so 
any beta testers with other setups like AMD64, G5 etc. are welcome...)

Cheers,
Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

[q-lang-users] ANN: Q 7.0 released

[Albert G. <Dr....@t-...>]

Hi,

as some of you probably noticed already, Q 7.0 has finally been 
released, along with a bunch of updated add-on modules. Today I also had 
some time to update the website. So all the new goodies can now be found 
on http://q-lang.sourceforge.net/download.html

Please note that starting with this release, all binaries are in a 
single package (RPM and MSI), which now also includes all the add-on 
modules. (The multimedia examples are still in a separate package, 
though.) This should make it easier to get everything up and running 
quickly on Linux and Windows systems. You should remove old packages 
when upgrading from a previous binary release. The source packages are 
still divided into the core package and separate tarballs for each 
add-on module.

Enjoy! :)

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] ANN: Q 7.0 release candidate

[Albert G. <Dr....@t-...>]

RC2 is now available for download at:

http://sourceforge.net/project/showfiles.php?group_id=96881&package_id=103965

There have been various bugfixes and the Windows ports (both 
native/Mingw and Cygwin) now work. Besides the source tarball, RPMs for 
Linux and a Windows MSI package are available, too.

Thanks are due to John Cowan for helping make the Cygwin port work. 
Please continue to report bugs (especially in the Unicode support) so 
that they can be fixed before the final release (which is due in the 
next 3-4 weeks, when I have updated the add-on modules).

Cheers,
Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [q-lang-users] Re: [qlang] Q 7.0 character escape syntax

[Albert G. <Dr....@t-...>]

Keith Trenton wrote:
> John, I forgot about your point wrt the possibility of \z acquiring a future meaning, if we should "reserve" \z by making it an error (today). I like your idea; accordingly, I have "decamped" from the "sloppy" faction. ;-)

Desertion! ;-) All right then, syntax-checking of escapes is in cvs now. 
I'm currently building the RC2 packages and will upload them later tonight.

Cheers,
Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

[q-lang-users] Re: [qlang] Q 7.0 character escape syntax

[Keith T. <kaz...@ea...>]

 
John Cowan writes: 
Then why prefer the warning? Nobody's actually disputed my point: that by making \z an error, it's possible to add \z to mean something later (\0xFFFF, say) with no possibility that it already appears somewhere in existing code.

John, I forgot about your point wrt the possibility of \z acquiring a future meaning, if we should "reserve" \z by making it an error (today). I like your idea; accordingly, I have "decamped" from the "sloppy" faction. ;-)

So, I guess I am not indifferent after all... Thanks for the reminder!

Cheers,
Keith 
 

Re: [q-lang-users] Re: [qlang] Q 7.0 character escape syntax

[John C. <co...@cc...>]

Keith Trenton scripsit:

> I prefer a warning over an error; however, in the programming that I
> do, I am unlikely to be affected either way. So, I am happy to defer
> to those with stronger opinions.

Then why prefer the warning?  Nobody's actually disputed my point:
that by making \z an error, it's possible to add \z to mean
something later (\0xFFFF, say) with no possibility that it already
appears somewhere in existing code.

-- 
John Cowan                              co...@cc...
http://www.ccil.org/~cowan              http://www.ap.org
Thor Heyerdahl recounts his attempt to prove Rudyard Kipling's theory
that the mongoose first came to India on a raft from Polynesia.
        --blurb for Rikki-Kon-Tiki-Tavi

[q-lang-users] Re: [qlang] Q 7.0 character escape syntax

[Keith T. <kaz...@ea...>]

Albert Graef wrote: 
So we have two votes in favour of making unrecognized escapes an error now. Am I the only one in the "don't care if it's sloppy" faction? ;-)

I prefer a warning over an error; however, in the programming that I do, I am unlikely to be affected either way. So, I am happy to defer to those with stronger opinions.

Count me in the "indifferent and sloppy" faction. ;-)

BTW, I cast an emphatic vote to retain the current syntax, and adding the () delimiters.
 
Cheers,
Keith 
 

[q-lang-users] Re: [qlang] Q 7.0 character escape syntax

[Albert G. <Dr....@t-...>]

Andrew Berg wrote:
> Is there a good reason to not make the "0" in \0xff just be optional?

Yes, there is. The current notation is based on the idea that what 
follows the backslash is just an ordinary integer literal. That's easy 
to remember, and no special syntax for "character numbers" is required.

> I'd vote for making it an actuall error.  Speaking as one who often has  
> trouble remembering if the "bell" is '\b' or '\g'

Neither. ;-) In C it's \a. Q doesn't have a notation for BEL at all, so 
you'd have to write something like \7.

So we have two votes in favour of making unrecognized escapes an error 
now. Am I the only one in the "don't care if it's sloppy" faction? ;-)

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

[q-lang-users] Re: Q 7.0 character escape syntax

[Albert G. <Dr....@t-...>]

> I'm happy to retain the existing syntax, adding the () delimiters.

Ok, as nobody seems to oppose this, it's done (already in cvs now).

> If anything,
> consistency between character numbers and number numbers is a Good Thing.

Yes, that was the idea behind it.

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Re: [qlang] Q 7.0 character escape syntax (was: Re: [q-lang-users] ANN: Q 7.0 release candidate)

[Andrew B. <an...@vo...>]

On Wed, 15 Feb 2006 17:26:31 -0800, Albert Graef <Dr....@t-...>  
wrote:

As an only-occasional user of Q, I'll weigh in with my $.02 here.

>
> I'm not sure what The Right Thing is in this case. So what should we do:  
> Keep the existing \ddd, \0ooo, \0xhhh notation and extend that with the  
> \(<int>) notation? Or rather jump on the C/Python/... bandwagon and  
> employ the widely used \ooo, \xhh, \uhhhh, \Uhhhhhhhh notation? (Note  
> that then I'd also have to slash the decimal escape syntax of pre-7.0  
> releases, potentially breaking existing scripts in places where it might  
> not be easily noticed.) Any other proposals? Opinions?

Is there a good reason to not make the "0" in \0xff just be optional?   
That gets a format that is consistent with the number literals, and a  
shorter--yet still clear--format for people like me who really hate  
senseless redundancy in a syntax.

>
> This convention was adopted from C (I think that the standard doesn't  
> actually specify this, but IIRC all C compilers I've used did it that  
> way). At least the newer versions of gcc generate a warning message in  
> the case of an unrecognized escape, though. I could easily do this in  
> the Q compiler as well, but unless you run the interpreter with the -w  
> option you won't notice the difference. ;-) OTOH, spitting out a syntax  
> error in this case seems a bit too harsh for my taste. What do others  
> think?

I'd vote for making it an actuall error.  Speaking as one who often has  
trouble remembering if the "bell" is '\b' or '\g' (somehow I _can_  
remember that the bell character is ^g), I would like a  
quicker-than-running-it way to find out that one of them is an  
unrecognized escape.  I can't think of any scenario where the fact that  
some characters can have an ignored '\' prepended to them can be used  
advantageously.  And in the event that I think of one, I hope that someone  
around me cares enough to take my keyboard away and slap some sense into  
me.

-andrew

-- 
an...@vo...

Re: Q 7.0 character escape syntax (was: Re: [q-lang-users] ANN: Q 7.0 release candidate)

[John C. <co...@cc...>]

Albert Graef scripsit:

> Keep the existing \ddd, \0ooo, \0xhhh notation and extend that with the 
> \(<int>) notation? Or rather jump on the C/Python/... bandwagon and 
> employ the widely used \ooo, \xhh, \uhhhh, \Uhhhhhhhh notation? (Note 
> that then I'd also have to slash the decimal escape syntax of pre-7.0 
> releases, potentially breaking existing scripts in places where it might 
> not be easily noticed.) Any other proposals? Opinions?

I'm happy to retain the existing syntax, adding the () delimiters.  What
matters is that characters can be encoded in hex (which is already true,
I just didn't know how) and that delimiters be provided.  If anything,
consistency between character numbers and number numbers is a Good Thing.

-- 
What has four pairs of pants, lives             John Cowan
in Philadelphia, and it never rains             http://www.ap.org
but it pours?                                   co...@cc...
        --Rufus T. Firefly                      http://www.ccil.org/~cowan

Q 7.0 character escape syntax (was: Re: [q-lang-users] ANN: Q 7.0 release candidate)

[Albert G. <Dr....@t-...>]

Hi John,

I'm taking this discussion back to the the mailing list, as I feel that 
this issue should be discussed by everybody on the list who is 
interested in the upcoming Q 7.0 release.

(Just a quick update for everybody: Q 7.0 RC2 is almost done and I also 
have the native Windows port working. Moreover, thanks to John Cowan's 
tireless testing and bug reporting, Cygwin is now supported, too. 
However, there is still an issue related to numeric character escapes, 
as detailed below. Note that we now need an escape syntax which is able 
to support the entire Unicode range, not just ASCII.)

John Cowan wrote:
> I found a problem:  when you type
> 
> 	"\300" ++ "4"
> 
> to the interpreter, it replies
> 
> 	"\3004"

> There doesn't seem to be any way to defeat
> the greediness of the \N construct, and there needs to be.  It seems
> to me that the most Q-ish approach is to allow parentheses around N,
> and output "\(300)4".

Thanks for reporting this. I certainly want to fix this before releasing 
RC2. Your proposal makes sense to me, and would be fairly easy to 
implement, too.

(NB: The problem here is that an escape like "\1234" will always denote 
character #1234, and there's currently no way to escape, say, character 
#123, followed by a literal "4" character (other than escaping "4", too, 
which is silly). In fact, I think that this misfeature is present in 
*all* recent Q versions.)

> In addition, Unicode folks really really really detest decimal numbers
> for Unicode characters.  While you're fixing the above, please allow a
> leading x (as in "\x0100") for hexadecimal character escapes.

Recent Q versions already allow either decimal, octal or hexadecimal 
notation in an escape, using the same syntax as in integer literals. 
Thus, e.g., \27, \033 and \0x1b all denote the ASCII escape character. 
With Q 7.0 I still use the same notation, only the range of character 
codes is bigger, allowing for all 0x110000 Unicode characters. I think 
that this notation is cleaner and simpler than having to remember all 
kinds of funny escape notations, like the \ooo, \xhh, \uhhhh and 
\Uhhhhhhhh escapes of C, Python et al. But the advantage of the latter 
is that apparently many other languages already use them, so they are a 
kind of de facto standard.

I'm not sure what The Right Thing is in this case. So what should we do: 
Keep the existing \ddd, \0ooo, \0xhhh notation and extend that with the 
\(<int>) notation? Or rather jump on the C/Python/... bandwagon and 
employ the widely used \ooo, \xhh, \uhhhh, \Uhhhhhhhh notation? (Note 
that then I'd also have to slash the decimal escape syntax of pre-7.0 
releases, potentially breaking existing scripts in places where it might 
not be easily noticed.) Any other proposals? Opinions?

> Another minor point:  currently stray \ characters are basically ignored:
> "\z" is equivalent to "z".  IMHO this should be changed, making them
> syntax errors; that allows you to add a meaning for \z at some future
> date without worries that existing poorly-written scripts will break.

This convention was adopted from C (I think that the standard doesn't 
actually specify this, but IIRC all C compilers I've used did it that 
way). At least the newer versions of gcc generate a warning message in 
the case of an unrecognized escape, though. I could easily do this in 
the Q compiler as well, but unless you run the interpreter with the -w 
option you won't notice the difference. ;-) OTOH, spitting out a syntax 
error in this case seems a bit too harsh for my taste. What do others think?

Cheers,
Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag

[q-lang-users] =?iso-2022-jp?B?IBskQkJ0MGYkRyQ5GyhC?=

[<ne...@ci...>]

DQobJEJGTUEzJE4lYSE8JWskRz89JDdMdSQ0JDYkJCReJDskcyEjO2QkTyU7JWwlVjZmM1pJdCRI
JCQkJkE0OXFFODMrJE4jMyMwQmUwSj5lJE40ezonPFQkLD04JF4kayEiJTMlXyVlJUslRiUjJHJF
fTNnJDckRiQkJGtCdDBmOSVIfiRIPz0kNyReJDkhIzRKQzEkS0BiTEAkJCQ/JDckXiQ5JEghIj9N
OkokTj13QC0kLDAmP00kckM1JDklMyVfJWUlSyVGJSMkRyQ5ISMkPSROJGgkJiRKNFg3OCRLNj1M
IyROJCIka0NLQC0kTyUzJUElaSReJEclIiUvJTslOSQ3JEYyPCQ1JCQbKEIgGyRCJTMlQSVpISEb
KEJodHRwOi8vYXdnLndlYmNodS5jb20vY2FzYW5vdmEvPzE5MzQbJEIhISRHJTslbBsoQiANChsk
QiVWNmYzWkl0JEg4ITp3JDckRiRiJGkkKCRsJFA9d0AtJE40aTxMPz9JVSQtJE4lVyVtJVUlIyE8
JWskSE8iTW1AaCRyOCskazt2JCwkRyQtJF4kOSEjJCpCVCRBJDckRiQqJGokXiQ5ISMbKEINCg0K
DQoNCg0KLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vDQobJEIlYSE8JWtJVE1XJE5K
fSRPJDMkQSRpJEslYSE8JWskciItGyhCDQpjb25jZXB0M19uZXRAeWFob28uY2ENCg0KDQo=

Re: [q-lang-users] ANN: Q 7.0 release candidate

[Albert G. <Dr....@t-...>]

Hi John,

I just committed the necessary changes to the Makefile.am's to cvs. 
Can't test whether this works better than before, though (my Winblows 
development box is currently under repair ;-), so it would be nice if 
you could take a look. I can send you an overhauled tarball in personal 
mail, if you like (2.8 MB), so that you don't have to run automake. Just 
let me know.

Albert

John Cowan wrote:
> 
>>Yes, clearly the proper link option for libiconv is missing. So I'll 
>>have to add a corresponding LIBADD line in libq/Makefile.am and also 
>>modify the LIBADD lines in the other Makefile.am's I mentioned. If you 
>>can wait a little more, I'll  try to figure out what the right @XYZ@ 
>>variables are which have to be included for libiconv and libgettext, and 
>>then prepare a new tarball.
> 
> 
> This is a new box and my first attempt to install 7.0, so there's no hurry.

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr....@t-..., ag...@mu...
WWW:    http://www.musikinformatik.uni-mainz.de/ag