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

Re: [q-lang-users] Request to add new reserved words "quote" and "QUOTE" to Q

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

John Cowan wrote:
> This is a request to make the identifiers "quote" and "QUOTE" reserved
> and illegal in Q 7.1 and future releases.

Well, I'm all for a Lisp interface, but I don't like the idea to 
introduce some special keywords which aren't even used in the language. 
If the issue is just to disambiguate the s-exp representation, why can't 
this be done with a Lisp macro, say "q-list", which can't possibly occur 
as a Q identifier? Or maybe it would be possible to escape Q function 
symbols? (I'd say that you need an escape mechanism on symbols anyway, 
if only to distinguish "foo" from "FOO" which are the same symbol in 
Lisp, right?)

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] Request to add new reserved words "quote" and "QUOTE" to Q

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

This is a request to make the identifiers "quote" and "QUOTE" reserved
and illegal in Q 7.1 and future releases.

In the interest of getting some interoperability between the Lisp family
of languages and Q, I'm designing an S-expression representation of
Q expressions -- not declarations or definitions, just expressions.
Doing this permits a representation of a Q expression to be easily
manipulated by Scheme or Common Lisp programs.

The basic Q types are integers, floats, booleans, strings, files, symbols,
applications, lists, and tuples.  Of these, files are hopeless (there
is no standardized representation of them).  Integers, floats, strings,
symbols, and tuples have clear S-expression representations (tuples
are Scheme vectors or Common Lisp simple general vectors, in either
case notated "#(a b c)".  Booleans can be represented in S-expressions
by the symbols "true" and "false", just as on the Q side; in Scheme,
the special boolean values #t and #f can be mapped back and forth.

Lists and applications, however, are both represented by lists in both
Scheme and CL, and only context distinguishes them.  By reserving the word
"quote", we can use "(quote (a b c)) to represent a list and "(a b c)"
to represent one or more Q applications (right associative as usual).

Because Lisp is not case-sensitive, the internal representation of the
symbol named "quote" may be either "quote" or "QUOTE", so both must be
reserved in Q.  If these words are not reserved, then the Q application
"quote [a,b]" would have the same S-expression representation as "[a,b]".

This should be a really trivial change to the compiler and interpreter
that can be folded into 7.1, I think.

-- 
John Cowan                              <co...@cc...>
            http://www.ccil.org/~cowan
                .e'osai ko sarji la lojban.
                Please support Lojban!          http://www.lojban.org

Re: [q-lang-users] CVS head failed to build, flex yytext_ptr problems

[Peter M. <pet...@wa...>]

Albert Graef wrote:
> Hi, Peter, thanks a lot for the report. I vaguely remember that I've run 
> into a related issue before, I'll try to fix it asap. Meanwhile, maybe 
> you'd like to try whether the 7.1rc2 tarball builds cleanly on your 
> system? It's available here:
> 
> http://prdownloads.sourceforge.net/q-lang/q-7.1rc2.tar.gz?download

This works. However when I removed the qclex.c file (which was in the 
archive) and ran make again to recreate the file it fails in exactly the 
same way as before (not suprisingly as there is no difference between 
the 7.1rc2 qclex.l file and the one in CVS HEAD).

Greetings,

Peter

Re: [q-lang-users] CVS head failed to build, flex yytext_ptr problems

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

Hi, Peter, thanks a lot for the report. I vaguely remember that I've run 
into a related issue before, I'll try to fix it asap. Meanwhile, maybe 
you'd like to try whether the 7.1rc2 tarball builds cleanly on your 
system? It's available here:

http://prdownloads.sourceforge.net/q-lang/q-7.1rc2.tar.gz?download

Albert

Peter Minten wrote:
> Q CVS HEAD failed to build for me. These are the relevant errors:

-- 
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 head failed to build, flex yytext_ptr problems

[Peter M. <pet...@wa...>]

Hi,

Q CVS HEAD failed to build for me. These are the relevant errors:

"""
make[2]: Entering directory `/home/peter/Desktop/q/src'
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../libltdl       -DYEAR=2006 
-DSYSINFO=i686-pc-linux-gnu 
-DQPATH=.:/usr/local/share/q/lib:/usr/local/lib/q 
-DQEXEC=/usr/local/bin/q -DLIBTOOL=/usr/local/lib/q/libtool -DCC=gcc  -g 
-O2 -c qmlex.c
qmlex.l: In function 'u8ungetc':
qmlex.l:593: error: 'yytext_ptr' undeclared (first use in this function)
qmlex.l:593: error: (Each undeclared identifier is reported only once
qmlex.l:593: error: for each function it appears in.)
qmlex.l: In function 'utf8_qualid':
qmlex.l:661: error: 'yytext_ptr' undeclared (first use in this function)
qmlex.l: In function '__qq__peek':
qmlex.l:747: error: 'yytext_ptr' undeclared (first use in this function)
make[2]: *** [qmlex.o] Error 1
"""

flex --version = "flex 2.5.31" (that's the latest version in the dapper 
repository)
gcc --version = "gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu4)"

Google turned up this:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=191942

If that's correct the current use of unput at least causes part of the 
problem.

Greetings,

Peter

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

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

All right, cvs is up and running again and I comitted the latest 
changes. Anonymous cvs also seems to be in sync again.

However, it seems that the mailing list archives have completely 
disappeared now. Will have to submit another support request tomorrow. 
Arrghh. :(

Albert Graef wrote:
> Good news! I just received mail from sourceforge that the new cvs 
> infrastructure will be deployed this afternoon (May 12). That probably 
> means pacific time, so it'll be after midnight for the Europeans among us.
> 
> Provided that everything works smoothly, I hope that I'll have 
> everything up-to-date again shortly afterwards, i.e., some time 
> tomorrow. Anonymous cvs should then also be in sync again (with the 
> usual lag of 2 hours). Also, with sf's new cvs infrastructure the cvs 
> web interface should always be in sync with developer cvs.
> 
> The bad news is that the cvs server names will change, so those of you 
> who keep track of q-lang cvs will have to check out new working copies.

-- 
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] Matching with special constructors

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

John Cowan wrote:
> I wonder whether it would be useful to have a way of declaring precisely
> which special constructors (or special forms in general?) are affected
> by this.  Maybe not.

I also thought about something similar, but decided against it since it 
would be rather confusing. If some function really needs to ensure that 
one of its args is passed unevaluated then you can always declare it as 
a special form.

-- 
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] Matching with special constructors

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

Albert Graef scripsit:

> Specifically, the pattern matcher, when trying to match 
> a pattern inside a suspended argument, should evaluate that argument 
> recursively before proceeding. AFAICT, that's also the way that this 
> situation would be handled in other languages which provide pattern 
> matching on lazy data structures.

Indeed, in Haskell Core (the output of the front end of the GHC compiler)
pattern matching is the *only* way in which evaluation happens.

> Of course this changes the way that special forms work, so it will not 
> be backward-compatible. I still think that I should do this change. What 
> do you think? Any other solution approaches? Any other opinions on what 
> would be "the right thing" here?

I wonder whether it would be useful to have a way of declaring precisely
which special constructors (or special forms in general?) are affected
by this.  Maybe not.

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

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

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

Tim Haynes wrote:
> a) I think there's some kind of svn support on sf.net

That's right. I've actually considered switching the repository to svn 
for a while. Maybe this summer.

> Not directly. I know another developer at work looked at one such thing
> and found they'd rejected an app for saying `GPLv2 only' (as distinct from
> "or any later version"). That's only anecdotal, but still, keep an eye out
> for licensing policy.

Yes, even if with the occasional service disruptions sf.net still has 
its advantages, not the least of which is its extensive set of mirrors 
all over the world. OTOH that klunky web interface makes me want to bang 
my head against the wall whenever I'm doing file releases. ;-)

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] Matching with special constructors

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

Albert Graef wrote:
> Specifically, the pattern matcher, when trying to match 
> a pattern inside a suspended argument, should evaluate that argument 
> recursively before proceeding.

I should clarify this: "a pattern inside a suspended argument" only 
refers to subexpressions of *non-special toplevel arguments of the lhs 
pattern* here. E.g., if you have something like:

special foo X; special bar X Y;
foo (bar (gnu X) Y) = ...;

then the special argument of foo should _not_ be evaluated by the 
pattern matcher before matching against bar (gnu X) Y. Nor should any of 
the subexpressions (like the first argument of bar) be evaluated by the 
pattern matcher.

OTOH, if you have something like:

private foo X; special bar X Y;
foo (bar (gnu X) Y) = ...;

where bar acts as a special constructor in the _non-special_ argument of 
foo, then the pattern matcher, when it comes to consider the subpattern 
gnu X, will first evaluate the first argument of bar before proceeding 
with the matching process.

Yes, I know that this sounds a bit confusing, but the restriction to 
non-special toplevel args is necessary so that the special forms 
themselves still have full control on where and when their arguments are 
evaluated. Otherwise special forms like lambda would stop working.

There are some other hairy implementation issues related to the proposed 
change of the pattern matcher which I didn't even mention yet. (Yann, 
you opened a can of worms there. ;-) In particular, the pattern matcher 
is also used when building special argument terms, to make an informed 
decision about which parts of a suspension actually need to be evaluated 
later (without this optimization, special forms are so slow that they're 
essentially unusable). This "quick reducibility checker" will have to be 
adapted, too, so that it can handle "irrefutable" matches where 
suspensions protected by special constructors are involved.

Talking about irrefitable matches, another question is whether Q should 
also support Clean/Haskell style lazy patterns, see e.g. Section 4.4 at 
http://www.haskell.org/tutorial/patterns.html. While these look like a 
kind of hack to me, they do allow more succint representations of 
certain algorithms. Do any of the seasoned Haskell programmers on this 
list miss them at all in Q?

Well, I'm still pretty confident that there are no real roadblocks on 
the way to the new pattern matching code, only a bit of "blood, sweat 
and tears". ;-) Hopefully cvs will be back up soon so that I can start 
working on this...

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:

> Tim Haynes wrote:
> > Yes, sf.net cvs has been screwed for a while :/
> 
> And it gets even worse. Today I noticed that the ML archives haven't been
> updated for at least 9 days now.

There are ends in sight:

a) I think there's some kind of svn support on sf.net

b) I received a status-mail from them this morning stating that new CVS
infrastructures will be in place shortly, one consequence of which is that
everyone is going to have to check-out again with the project name in the
CVSROOT. Eg:

cvs -z3 -d:pserver:ano...@cv...:/cvsroot/q-lang co -P
modulename

becomes

cvs -z3 -d:pserver:ano...@q-...:/cvsroot/q-lang co -P
modulename

> Maybe sf is just getting too big. Does anyone here have experiences with
> alternative sites such as savannah or berlios?

Not directly. I know another developer at work looked at one such thing
and found they'd rejected an app for saying `GPLv2 only' (as distinct from
"or any later version"). That's only anecdotal, but still, keep an eye out
for licensing policy.

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

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

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

Good news! I just received mail from sourceforge that the new cvs 
infrastructure will be deployed this afternoon (May 12). That probably 
means pacific time, so it'll be after midnight for the Europeans among us.

Provided that everything works smoothly, I hope that I'll have 
everything up-to-date again shortly afterwards, i.e., some time 
tomorrow. Anonymous cvs should then also be in sync again (with the 
usual lag of 2 hours). Also, with sf's new cvs infrastructure the cvs 
web interface should always be in sync with developer cvs.

The bad news is that the cvs server names will change, so those of you 
who keep track of q-lang cvs will have to check out new working copies.

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:
> Yes, sf.net cvs has been screwed for a while :/ 

And it gets even worse. Today I noticed that the ML archives haven't 
been updated for at least 9 days now.

Maybe sf is just getting too big. Does anyone here have experiences with 
alternative sites such as savannah or berlios?

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] Matching with special constructors

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

Hi all,

there is yet another issue related to streams and other lazy data 
structures in Q that I'd still like to resolve in the 7.1 release. It 
would be nice to discuss this here on the list because it affects 
certain aspects of pattern matching in a non-backward compatible way, 
and maybe there are some other solutions for the issue that I haven't 
stumbled upon yet.

The problem has been brought up by Yann Orlarey who noticed the 
following usability issue with lazy data structures in Q. (I'm taking 
streams here as an example; note that I use the new syntactic sugar for 
streams understood by the 7.1 version of the interpreter.)

For the sake of a concrete example, suppose we want to define a function 
which "deinterleaves" a list by replacing pairs of successive list 
elements with a tuple. For instance:

==> deinterleave [1..10]
[(1,2),(3,4),(5,6),(7,8),(9,10)]

This operation can easily be defined on lists as follows:

deinterleave []		= [];
deinterleave [X,Y|Xs]	= [(X,Y)|deinterleave Xs];

Now let's consider the literal translation of this definition to streams:

deinterleave {}		= {};
deinterleave {X,Y|Xs}	= {(X,Y)|deinterleave Xs};

Let's try this with the infinite stream of all positive integers:

==> {1..}
{1|iterate (+1) ((+1) 1)}

==> deinterleave {1..}
deinterleave {1|iterate (+1) ((+1) 1)}

Well, this doesn't work as expected because of the suspended tail 
iterate (+1) ((+1) 1) of the stream, which doesn't match {Y|Xs} so the 
second equation cannot be applied before the tail is evaluated.

While the above result is consistent with the way that special forms 
currently work in Q, I'd really like Q to do "the right thing" here. 
With the current interpreter, you're forced to write something like the 
following to force evaluation of the stream's tail:

deinterleave {X|Xs}	= {(X,Y)|deinterleave Ys} where {Y|Ys} = Xs;

Which is rather awkward. I agree with Yann that the right thing here is 
that the original definition should "just work" as is. The only 
reasonable way I see to make this work is to interleave pattern matching 
with evaluation. Specifically, the pattern matcher, when trying to match 
a pattern inside a suspended argument, should evaluate that argument 
recursively before proceeding. AFAICT, that's also the way that this 
situation would be handled in other languages which provide pattern 
matching on lazy data structures.

Of course this changes the way that special forms work, so it will not 
be backward-compatible. I still think that I should do this change. What 
do you think? Any other solution approaches? Any other opinions on what 
would be "the right thing" here?

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] Stream constructors

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

Sean Russell wrote:
> Not really, although I do have a question.  Why is the alternate mark-up 
> (braces instead of brackets) necessary?  Is it aesthetic, or is there some 
> parsing issue that I've missed?

Well, there are different ways to get lazy data structures in an eager 
FPL, but the fact of the matter is that in an eager language you will 
*always* need some kind of special markup to distinguish suspensions 
from ordinary expressions. Leaving the syntactic sugar and 
implementation issues aside, you can think of lists and streams being 
defined in Q by:

type List = const list_nil, list_cons X Xs;
type Stream = special const stream_nil, stream_cons X Xs;

So lists and streams are really different data types in Q and need 
different syntaxes because that's the only way that the interpreter can 
know which kind of object to create.

There are other ways to handle lazy evaluation in a strict FPL. E.g., in 
the ML dialect Alice you'd use an explicit suspension created with `lazy 
(<expr>)'. IMHO Q's notion of special forms has its advantages because 
it allows both macro-like functions and lazy data structures to be 
handled in a uniform way. And you don't have to write `lazy' all the 
time, because once you've declared your special forms the interpreter 
knows where and when suspensions need to be created without any further ado.

> Explicitness is nice, but not having the lists and streams share syntax means 
> that you won't be able to re-use library functions that operate on lists.

That's true, and it's why there is a standard library module stream.q 
which extends all the usual list operations to streams. I think that 
this strict separation actually has its advantages, because lists and 
streams are quite different beasts on the algorithmic level. An 
efficient list algorithm might be completely unusable for streams 
because it's too strict, and, vice versa, an algorithm tailored for 
streams (considering non-strictness requirements) might be quite 
inefficient for lists.

OTOH, if your algorithm can be expressed in terms of the standard 
list+stream stuff like fold, map, zip etc. then chances are good that it 
can be used with both lists and streams without ever having to worry 
whether it's a list or stream that you are working with. But that still 
relies on that (some of) the basic list operations are optimized on the 
specific data structure at hand.

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: 7.1rc2 on AMD64 (Re: [q-lang-users] Re: 7.1 candidate)

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

Hi Tim, yes it's the same thing that Andrew already reported quite a 
while ago. I'll have a look at this asap.

Tim Haynes wrote:
> My attempts to build are currently failing on this command (I've inserted
> `-d' myself in an attempt to find out a bit more):

-- 
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: 7.1rc2 on AMD64 (Re: [q-lang-users] Re: 7.1 candidate)

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

Hi, Tim.

First the caveat:  I'm operating purely from memory
here, it was probably around a year ago that I looked
into this last, but what I remember was...

The real failure is before that spot.  You have to
look closely at the make output to see it, since the
error does not get detected, and it continues on to
that point.  Where the real error is, it leaves an
empty file which should include stuff to make those
undef symbols go away.  I worked backward and then
followed it to the point that some scary pointer
arithmetic was clearly broken, but not being able to
figure out what it was trying to do (in the couple of
hours I had on hand), I did not fix it.

-andrew

--- Tim Haynes <q...@st...> wrote:

> Hi,
> 
> My attempts to build are currently failing on this
> command (I've inserted
> `-d' myself in an attempt to find out a bit more):
> 
>
PATH=".:/bin:/usr/bin/:/usr/X11R6/bin:/usr/pkg/bin:/sbin:/usr/sbin::/usr/local/bin/:/usr/bin:/usr/bin:/usr/doc:/usr/games:/usr/include:/usr/lib:/usr/lib32:/usr/lib64:/usr/local:/usr/sbin:/usr/share:/usr/src:/usr/X11R6:/usr/local/sbin:/usr/local/gphoto/bin:/sbin:/usr/sbin:/usr/X11R6/bin:/opt/blackdown-jdk-1.4.1/bin"
> QPATH="../stdlib:../modules/clib:../modules/clib"
> ./q -d ./qcwrap.q
> def: error loading module
> Warning: 268 unresolved external symbols
> ! File def, line 297: Value mismatch in definition
> --  def SIG_IGN = -1
> --  def SIG_DFL = 0
> --  def SIG_TRP = 1
> --  def SCHED_OTHER = 0
> --  def SCHED_RR = 1
> --  def SCHED_FIFO = 2
> --  def AF_UNIX = AF_LOCAL
> --  def AF_FILE = AF_LOCAL
> --  def S_ISUID = 2048
> --  def S_ISGID = 1024
> --  def S_ISVTX = 512
> --  def S_IRWXU = 448
> --  def S_IRUSR = 256
> --  def S_IWUSR = 128
> --  def S_IXUSR = 64
> --  def S_IRWXG = 56
> --  def S_IRGRP = 32
> --  def S_IWGRP = 16
> --  def S_IXGRP = 8
> --  def S_IRWXO = 7
> --  def S_IROTH = 4
> --  def S_IWOTH = 2
> --  def S_IXOTH = 1
> --  def clib::MAIN_THREAD = this_thread
> zsh: exit 2     PATH=
> QPATH="../stdlib:../modules/clib:../modules/clib"
> ./q -d ./qcwrap.q
> zsh, sauce  9:38AM src/ %
> 
> Any ideas? :)
> 
> ~Tim
> -- 
> <http://spodzone.org.uk/>
> 
> 
>
-------------------------------------------------------
> Using Tomcat but need to do more? Need to support
> web services, security?
> Get stuff done quickly with pre-integrated
> technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1
> based on Apache Geronimo
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> q-lang-users mailing list
> q-l...@li...
>
https://lists.sourceforge.net/lists/listinfo/q-lang-users
> 

Re: [q-lang-users] Stream constructors

[Sean R. <q...@se...>]

On Thursday 11 May 2006 02:46, Albert Graef wrote:
> Good idea. That'll be stream_cons and stream_nil. Further comments?
> Anyone upset by this change?

Not really, although I do have a question.  Why is the alternate mark-up 
(braces instead of brackets) necessary?  Is it aesthetic, or is there some 
parsing issue that I've missed?

Explicitness is nice, but not having the lists and streams share syntax means 
that you won't be able to re-use library functions that operate on lists.  I 
may have missed the discussion about this particular issue.

-- 
### SER   
### Deutsch|Esperanto|Francaise|Linux|XML|Java|Ruby|Aikido
### http://www.germane-software.com/~ser  jabber.com:ser  ICQ:83578737 
### GPG: http://www.germane-software.com/~ser/Security/ser_public.gpg

7.1rc2 on AMD64 (Re: [q-lang-users] Re: 7.1 candidate)

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

Hi,

My attempts to build are currently failing on this command (I've inserted
`-d' myself in an attempt to find out a bit more):

PATH=".:/bin:/usr/bin/:/usr/X11R6/bin:/usr/pkg/bin:/sbin:/usr/sbin::/usr/local/bin/:/usr/bin:/usr/bin:/usr/doc:/usr/games:/usr/include:/usr/lib:/usr/lib32:/usr/lib64:/usr/local:/usr/sbin:/usr/share:/usr/src:/usr/X11R6:/usr/local/sbin:/usr/local/gphoto/bin:/sbin:/usr/sbin:/usr/X11R6/bin:/opt/blackdown-jdk-1.4.1/bin" QPATH="../stdlib:../modules/clib:../modules/clib" ./q -d ./qcwrap.q
def: error loading module
Warning: 268 unresolved external symbols
! File def, line 297: Value mismatch in definition
--  def SIG_IGN = -1
--  def SIG_DFL = 0
--  def SIG_TRP = 1
--  def SCHED_OTHER = 0
--  def SCHED_RR = 1
--  def SCHED_FIFO = 2
--  def AF_UNIX = AF_LOCAL
--  def AF_FILE = AF_LOCAL
--  def S_ISUID = 2048
--  def S_ISGID = 1024
--  def S_ISVTX = 512
--  def S_IRWXU = 448
--  def S_IRUSR = 256
--  def S_IWUSR = 128
--  def S_IXUSR = 64
--  def S_IRWXG = 56
--  def S_IRGRP = 32
--  def S_IWGRP = 16
--  def S_IXGRP = 8
--  def S_IRWXO = 7
--  def S_IROTH = 4
--  def S_IWOTH = 2
--  def S_IXOTH = 1
--  def clib::MAIN_THREAD = this_thread
zsh: exit 2     PATH= QPATH="../stdlib:../modules/clib:../modules/clib" ./q -d ./qcwrap.q
zsh, sauce  9:38AM src/ %

Any ideas? :)

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

Re: [q-lang-users] Stream constructors

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

John Cowan wrote:
Since no one is going to actually use them, I suggest going for something verbose like stream-cons and stream-empty. That minimizes conflict with plausible user constructors.

Albert Graef wrote:
Good idea. That'll be stream_cons and stream_nil. Further comments? Anyone upset by this change?
 
The proposed verbose names are fine by me!

Cheers,
Keith 
 

Re: [q-lang-users] Re: 7.1 candidate

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

John Cowan wrote:
> This release works fine on Cygwin.

Great, thanks for testing.

-- 
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] Stream constructors

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

John Cowan wrote:
> Since no one is going to actually use them, I suggest going for something
> verbose like stream-cons and stream-empty.  That minimizes conflict with
> plausible user constructors.

Good idea. That'll be stream_cons and stream_nil. Further comments? 
Anyone upset by this change?

-- 
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] Stream constructors

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

Albert Graef scripsit:
> As the new syntactic sugar for streams is now in place (streams now look 
> just like lists, only using curly braces instead of brackets), to clean 
> up the namespace I'd like to rename the stream constructor symbols to 
> `scons' and `snil'.

Since no one is going to actually use them, I suggest going for something
verbose like stream-cons and stream-empty.  That minimizes conflict with
plausible user constructors.

-- 
Income tax, if I may be pardoned for saying so,         John Cowan
is a tax on income.  --Lord Macnaghten (1901)           co...@cc...

Re: [q-lang-users] Re: 7.1 candidate

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

Albert Graef wrote:
> 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 

Source and SuSE 10.0 RPMs are now available there, too.

-- 
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] Stream constructors

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

As the new syntactic sugar for streams is now in place (streams now look 
just like lists, only using curly braces instead of brackets), to clean 
up the namespace I'd like to rename the stream constructor symbols to 
`scons' and `snil'.

Using `bin' and `nil' for these was really a bad choice, as these are 
what almost everyone who has read the Bird/Wadler book would use for 
binary tree constructors, so having these symbols already defined as 
something else in the global namespace is not a good idea. Also, as Yann 
pointed out in private conversation, naming the binary stream 
constructor `bin' really is a little weird. ;-)

The question is, would this affect anybody's scripts? Does anyone here 
use streams at all? And, if so, would it be too much work to convert 
them to the new {X|Xs} notation?

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