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

Re: [q-lang-users] Q 7.1 RC3 available

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

Q 7.1 final is now in cvs, ready to be released. Did anyone notice any 
bugs in RC3, or can I proceed with the release?

There have been a number of smaller cosmetic changes and bugfixes 
compared to RC3, and the manual has finally been updated. I hope that 
all new features are properly documented now.

John, I think you said you have some more corrections for the manual, 
could you please send them to me? Thanks.

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] rational.q: "Q+Q": a rational number module for Q

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

Rob Hubbard wrote:
> My rational number module "Q+Q" rational_136.tar.gz is now available from
>     <http://q-lang.sourceforge.net/examples.html>
>     <http://q-lang.sourceforge.net/rational_136.tar.gz>

Hi Rob, thanks a lot for the new module.

I might add that those of you running 7.1RC3 already have latest Rob's 
rational.q included, so you can try it right away.

-- 
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] rational.q: "Q+Q": a rational number module for Q

[Rob H. <hub...@gm...>]

Dear all,

My rational number module "Q+Q" rational_136.tar.gz is now available from
    <http://q-lang.sourceforge.net/examples.html>
    <http://q-lang.sourceforge.net/rational_136.tar.gz>

The module includes:
    constructors (and decomposition functions)
    rational arithmetic (+), (-), (*), (/), ... and relations (=3D),
(<), (<=3D), ..., cmp, ...
        (mixed arithmetic with Ints and Floats is also supported;
        there is one "gotcha" regarding division of ints -- see =A74.1)
    'complexity' comparison functions
    some simple maths functions: abs, sgn, min, max, gcd, lcm, ...
    conversion, approximation and rounding routines
    various string formatting routines
    calculating and evaluating continued fractions (and convergents)

Here are some examples:

    // Arithmetic
    =3D=3D> 5 over 7 + 2 over 3 ; str_mixed _
    rat 29 21
    "1+8/21"
    =3D=3D> (3 over 8) < (1 over 3)
    false
    =3D=3D> cmp (3 over 8) (1 over 3)
    1
    =3D=3D> max (3 over 8) (1 over 3)
    rat 3 8

    // Finding a rational approximations to a real number (or rather, Float=
)
    =3D=3D> def phi =3D (1 + sqrt 5) / 2
    =3D=3D> rational_approx_epsilon .001 phi // Least complex to within
some 'epsilon'
    rat 55 34
    =3D=3D> rational_approx_max_den 1000 phi // Best given a bound on the
denominator
    rat 1597 987

    // Formatting mixed fraction strings
    =3D=3D> def L =3D while (<=3D 3 over 2) (+(1 over 2)) (-3 over 2); L
    [rat (-3) 2,rat (-1) 1,rat (-1) 2,rat 0 1,rat 1 2,rat 1 1,rat 3 2]
    =3D=3D> map str_mixed L
    ["-(1+1/2)","-1","-1/2","0","1/2","1","1+1/2"]

    // Formatting recurring decimal expansion string (exact)
    =3D=3D> str_real_recur format_uk 10 3 (-1 over 700)
    "-0.00[142857...]"

    // Formatting engineering notation (approximation)
    =3D=3D> str_real_approx_eng format_uk 3 10 3 3 round 7 (rational 999950=
)
    "999.950,0*10^3"
    =3D=3D> str_real_approx_eng format_uk 3 10 3 3 round 4 (rational 999950=
)
    "1.000*10^6(-)"
    // The "(-)" should be read as "but a bit less".
    // Different formatting structures are supported (UK used here)
    // Different rounding modes are supported
    // Different radices are supported

    // Calculating and evaluating continued fractions
    =3D=3D> continued_fraction (1234 over 1001)
    [1,4,3,2,1,1,1,8]
    =3D=3D> evaluate_continued_fraction _
    rat 1234 1001

The tarball contains the module source itself, plus a PDF document.

[Some notes for Windoze users (like me): The tarball is easily
unpacked with the 7-Zip program, available from
<http://www.7-zip.org/>; I'd recommend that anyway. The contained
module source rational.q has Linux-style line endings that might upset
some Windoze editors. If that's a problem for you there are various
solutions: if you have Cygwin installed, use unix2dos; write a
conversion script (in Q or Python, say); use an editor such as
Programmers' Notepad <http://www.pnotepad.org/>, Notepad++
<http://notepad-plus.sourceforge.net/uk/about.php> or SciTE
<http://www.scintilla.org/SciTE.html>. All the tools I mention here
are free and/or open source.]

I consider that the module is only an "alpha" version at the moment,
as I may make some minor adjustments to the API over the coming weeks.
The code has had some testing but I plan to do more extensive testing
in the no too distant future. In order to ensure that the examples in
the documentation are correct, these are generated by automatically
evaluating the commands using rational.q.

Please let me know of any bugs that you find. There is currently at
least one minor bug: the string evaluation routines do not detect
out-of-range digits.

Constructive criticism of my implementations is also welcome. I am
relatively new to 'Q' and to the functional style of programming
generally.

Please also let me know of any omissions from (or mistakes or
ambiguities or otherwise unclear material in) the documentation.

I hope to produce a further update soon.

Rob.

Re: [q-lang-users] Q 7.1 RC3 available

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

A Windows MSI is now available from the same location.

> http://sourceforge.net/project/showfiles.php?group_id=96881&package_id=188958&release_id=416034

-- 
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] Q 7.1 RC3 available

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

All right, FRS seems to work again, and meanwhile I cleaned up the mess 
that was left behind after my earlier attempts. Happy downloading! :)

John Cowan wrote:
> I built what I believe to be the second rc2 (size = 3012490 bytes)
> successfully on Cygwin.

The file size seems to be ok. Here's the md5sum of the latest 
q-3.1rc3.tar.gz if you want to verify that, too:
0d9b6c300ef830e301dc3025a6e73671

> A thought:  Currently the compiler will cheerfully accept rules like
> "f (x Y) = something;" even if there exists a rule "x Y" = something;",
> though the first rule will never be executed due to Q's eager evaluation.
> This is documented in the manual.  It seems to me worthwhile to warn,
> at least, about a rule like "f (x Y)" if there are any rules defining x.

But this case naturally arises, e.g., if you have "constructor 
equations". So it's difficult to determine exactly when those warnings 
really make sense. Of course I could let the compiler spit out such a 
warning anytime it sees two rules like this, but that would be more 
annoying than useful most of the time.

So IMHO these warnings only make sense if we can decide statically 
whether the equation(s) for "x Y" always succeed, i.e., whether x is 
"completely defined" in some sense. But what does "completely defined" 
exactly mean here, given that Q has dynamic typing and allows as much ad 
hoc polymorphism as you want? And even if we leave that question aside, 
and there's only a single equation defining x, we still cannot decide 
statically whether that equation will always succeed, since an equation 
may fail at runtime even if the lhs matches and there are no qualifying 
conditions at all, due to a computed (and deferred) "catch fail" on the 
rhs of the equation (which leaves us with the halting problem; d'oh!).

> I'll send you some notes privately on English-language fixes.

Great, keep 'em rolling. :) I still have to process the previous batch, 
but I'll probably get to that later tonight, after the Windows build of 
RC3 is out...

Thanks,
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] Q 7.1 RC3 available

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

Albert Graef scripsit:

> I've uploaded RC3 last night. (Needed to get some sleep first before I 
> could do the announcement. ;-) There is a tarball as well as source and 
> SuSE 10.0 rpms (I see whether I can make a Windows build later today). 
> It's available here:
> http://sourceforge.net/project/showfiles.php?group_id=96881&package_id=188958&release_id=416034

I built what I believe to be the second rc2 (size = 3012490 bytes)
successfully on Cygwin.

A thought:  Currently the compiler will cheerfully accept rules like
"f (x Y) = something;" even if there exists a rule "x Y" = something;",
though the first rule will never be executed due to Q's eager evaluation.
This is documented in the manual.  It seems to me worthwhile to warn,
at least, about a rule like "f (x Y)" if there are any rules defining x.

> RC3 should be 99% feature-complete now, but the documentation still 
> needs updating. 

I'll send you some notes privately on English-language fixes.

-- 
John Cowan   http://ccil.org/~cowan    co...@cc...
In might the Feanorians / that swore the unforgotten oath
brought war into Arvernien / with burning and with broken troth.
and Elwing from her fastness dim / then cast her in the waters wide,
but like a mew was swiftly borne, / uplifted o'er the roaring tide.
        --the Earendillinwe

Re: [q-lang-users] Q 7.1 RC3 available

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

Albert Graef wrote:
> I'm 
> currently building new packages and will upload them during the next hour.

Well, the file release system seems to be severely broken right now, 
I'll try again later...

-- 
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] Q 7.1 RC3 available

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

Albert Graef wrote:
> I've uploaded RC3 last night.

Please hold on for a little while, I discovered that I needed to do some 
last-minute fixes in the standard library, and I'd like this to be in 
the release candidate so that you can all test the "real thing". I'm 
currently building new packages and will upload them during the next hour.

Sorry for the inconvenience,
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] Q 7.1 RC3 available

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

Hi all,

I've uploaded RC3 last night. (Needed to get some sleep first before I 
could do the announcement. ;-) There is a tarball as well as source and 
SuSE 10.0 rpms (I see whether I can make a Windows build later today). 
It's available here:
http://sourceforge.net/project/showfiles.php?group_id=96881&package_id=188958&release_id=416034

RC3 should be 99% feature-complete now, but the documentation still 
needs updating. There's lots of new stuff since the last RC; please 
check the release notes or the NEWS file for details. Most notable 
perhaps is the new builtin lambda and dramatic improvements in the 
performance of special forms in general and stream comprehensions in 
particular. The latter also benefit from the builtin lambda 
implementation. E.g., I found that the stream-based implementation of 
the 8 queens algorithm in queens.q, which used to be much slower than 
the imperative backtracking algorithm in queens2.q, is now just about as 
fast!

Here are some new and revised examples you might wish to take a look at 
if you're interested in lambda (I even got the normal order fixed point 
combinator to work) and streams:

http://q-lang.cvs.sourceforge.net/q-lang/q/examples/fixpt.q?revision=1.6
http://q-lang.cvs.sourceforge.net/q-lang/q/examples/streams.q?revision=1.2

I've also included Tim Haynes' latest cgi.q and Rob Hubbard's new 
rational.q (we'll probably see a separate announcement for the latter on 
the ML later today).

Tim, btw, it seems that your primetest.q example, which has been in cvs 
since 2004, never made it into the distribution tarball since I forgot 
to also include it in the Makefile.am's DISTFILES; that should be fixed now.

Peter, I wasn't able to fix the flex compatibility issue yet; I have it 
on my TODO list for 7.2 now.

Thanks to all for the helpful discussions and contributions!

Enjoy. :)

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] Libqint and the stability of qexps

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

John Cowan wrote:
> Is it necessary to call qnewref() on each newly constructed qexp, or only
> on the top-level qexp?

Normally the toplevels should be enough, since the subexprs will per 
definition be referred to by other exprs and hence have a nonzero 
refcount anyway. But if you keep a pointer to, say, both Y = F X and X, 
then you should count a ref to both X and Y unless you can be sure that 
X and Y will always be thrown away at the same time. Otherwise just make 
it a habit to do a qnewref whenever you assign an expr pointer to a C 
variable, and make sure that you have a qfreeref after the last 
reference to the C variable (e.g., at the end of the block for an 
automatic variable).

-- 
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] Libqint and the stability of qexps

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

Albert Graef scripsit:

> Yes, they are. Expressions are never copied, always shared. And the 
> garbage collector will never move expressions around, it only adds them 
> to the freelist when they become inaccessible. 

Excellent.

> Note that if you keep pointers to temporary Q expressions (i.e., with a 
> reference count of 0) in your Scheme data structures then those 
> expressions may well be garbage-collected at any time during an 
> evaluation. 

Good point.  This by itself wouldn't be a problem, since the associations
between Scheme objects and Q objects are only used when recursively
decomposing the qexp and constructing the corresponding qsxp (Q-language
S-expression).  In this process, I never attempt to do anything with a
saved qexp except compare it with a returned qexp, so if the saved qexp
is garbage, no harm is done.

The real danger is that a qexp formerly referred to may be discarded
by Q and a newly created qexp may wind up at exactly the same C-level
address, causing false positive matches.  Because of this, I will be
sure to qnewref() my qexps.

> Therefore, to avoid nasty surprises, you should always count a reference
> (qnewref) to Q expressions which are stored somewhere.

Is it necessary to call qnewref() on each newly constructed qexp, or only
on the top-level qexp?

-- 
John Cowan    co...@cc...    http://ccil.org/~cowan
        Sound change operates regularly to produce irregularities;
        analogy operates irregularly to produce regularities.
                --E.H. Sturtevant, ca. 1945, probably at Yale

Re: [q-lang-users] Libqint and the stability of qexps

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

John Cowan wrote:
> I'm wondering whether the Q garbage collector sometimes moves temporary
> values about.  Given the rule "double X = [X, X];" in the current script,
> if you pass the qexp corresponding to "double [1,2,3]" to qevalx(),
> are the components of the list that is returned guaranteed to be
> C-pointer-equal to the list that is passed in?  This would seem to be
> true a priori, but I'd like to have it confirmed.

Yes, they are. Expressions are never copied, always shared. And the 
garbage collector will never move expressions around, it only adds them 
to the freelist when they become inaccessible. (You should however count 
a reference to all Q expressions you want to keep in Scheme data 
structures, see below).

NB: There is a (rather obscure) secondary gc in the Q interpreter which 
is only enabled with the --gc option. This is the usual kind of 
stop-and-copy gc which serves the purpose of defragmenting the heap and 
returning inaccessible expression memory to the system between different 
evaluations, and is a relict from the ancient times when Q needed to run 
on systems with <=640K of main memory. ;-) However, this isn't enabled 
by default, not needed on modern systems, and you can't enable that 
feature via libqint anyway. (I will probably also remove that --gc 
option in the near future.)

> This is important for my Scheme-to-Q connector, since I'd like to memoize
> the expression (and all its parts) being evaluated so that the elements
> of the Scheme-level list are EQ? to the Scheme-level argument to "double",
> rather than being newly constructed on the Scheme side.  However, if this
> is not reliable, I'll have to provide newly constructed lists instead.
> 
> (I'm assuming that the argument is being passed in is a temporary value.)

Note that if you keep pointers to temporary Q expressions (i.e., with a 
reference count of 0) in your Scheme data structures then those 
expressions may well be garbage-collected at any time during an 
evaluation. E.g., suppose you have constructed a temporary expression X, 
use it to construct the application Y = cst () X, and then you evaluate 
Y. The refcount of X goes up to 1 when Y is constructed but then becomes 
zero again when cst () X is reduced to () and Y is gc'ed by qeval(), at 
which point X is gc'ed, too.

Therefore, to avoid nasty surprises, you should always count a reference 
(qnewref) to Q expressions which are stored somewhere. When the 
expression is to be destroyed (because, say, the hosting Scheme object 
is destroyed) then you just call qfreeref() and the Q interpreter will 
do the right thing with it.

(Of course, you can also keep such expressions in the Q interpreter's 
global environment, using qdef(). This will automatically count a new 
reference and free the reference when the variable is undefined again.)

HTH,
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] Libqint and the stability of qexps

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

I'm wondering whether the Q garbage collector sometimes moves temporary
values about.  Given the rule "double X = [X, X];" in the current script,
if you pass the qexp corresponding to "double [1,2,3]" to qevalx(),
are the components of the list that is returned guaranteed to be
C-pointer-equal to the list that is passed in?  This would seem to be
true a priori, but I'd like to have it confirmed.

This is important for my Scheme-to-Q connector, since I'd like to memoize
the expression (and all its parts) being evaluated so that the elements
of the Scheme-level list are EQ? to the Scheme-level argument to "double",
rather than being newly constructed on the Scheme side.  However, if this
is not reliable, I'll have to provide newly constructed lists instead.

(I'm assuming that the argument is being passed in is a temporary value.)

-- 
Híggledy-pìggledy / XML programmers            John Cowan
Try to escape those / I-eighteen-N woes;        http://www.ccil.org/~cowan
Incontrovertibly / What we need more of is      co...@cc...
Unicode weenies and / François Yergeaus.

Re: [q-lang-users] RFC: Conditional syntax

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

All right, the revised lambda.q is in cvs now, under examples.

Realizing that Q has namespaces :), I didn't even bother to change the 
name of the lambda operation. In fact you can even replace the builtin 
lambda with the one from lambda.q by uncommenting a single line near the 
beginning of lambda.q.

John Cowan wrote:
> Albert Graef scripsit:
> 
>>- The lambda function used to return combinator terms which weren't nice 
>>to look at, but could be unparsed, written to a file and read back. With 
>>the new built-in lambda function, you'll get an external <<Function>> 
>>object instead.
> 
> For this reason, and also for the sheer coolness of it, I'd like to
> see the old lambda stay in the standard library, but renamed "Lambda".
> It's a nice executable demonstration of exactly how lambdas can be
> expressed as combinators.

-- 
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] RFC: Conditional syntax

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

Tim Haynes wrote:
> AFAIK I make very limited use of threading only in my wittering/index.q:

Ok, since noone really complained, it's all done and in cvs now. I've 
renamed the "cond" and "sem" stuff in clib, and the multiway conditional 
in prelude.q is properly named "cond" now. :)

Note that the new cond and case conditionals will now raise an exception 
when they "fall off" the list of clauses. I thought that was more 
appropriate than just returning (), as was the case with the old 
switch/match stuff.

-- 
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] RFC: Conditional syntax

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

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

> John Cowan wrote:
> > Umm, is it out of the question to change "cond" in clib to "condition"?
> 
> Well, if I change that, I'll have to change sem to semaphore, too, for
> consistency, and maybe some other pthread ops. Actually that's not a bad
> idea. But it will break most of the multimedia examples and maybe other
> stuff in the multimedia library, so all of this would have to be fixed.
> :(
> 
> 
> I'm willing to take the plunge, though. So does anyone else use those
> thread operations?

AFAIK I make very limited use of threading only in my wittering/index.q:

 | //How to kill a thread
 | terminate T = cancel T if active T;
 |             = result T otherwise;
 | 
 | main = TP || insertarticle || sleep 3 || terminate TP || writes output 
 |         if    [snip]
 |         where TP=thread ping;

This code is mostly inactive & bugged atm anyway and doesn't mention `sem'
or anything either, so don't worry about me! :)

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

Re: [q-lang-users] RFC: Conditional syntax

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

John Cowan wrote:
> Umm, is it out of the question to change "cond" in clib to "condition"?

Well, if I change that, I'll have to change sem to semaphore, too, for 
consistency, and maybe some other pthread ops. Actually that's not a bad 
idea. But it will break most of the multimedia examples and maybe other 
stuff in the multimedia library, so all of this would have to be fixed. :(

I'm willing to take the plunge, though. So does anyone else use those 
thread operations?

-- 
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] RFC: Conditional syntax

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

Albert Graef scripsit:

> Arrgh, I just noticed that cond is already used in clib for pthread 
> conditions. Too bad. :( Can anyone think of another nice name for the 
> conditional operation?

Umm, is it out of the question to change "cond" in clib to "condition"?

-- 
My confusion is rapidly waxing          John Cowan
For XML Schema's too taxing:            co...@cc...
    I'd use DTDs                        http://www.ccil.org/~cowan
    If they had local trees --
I think I best switch to RELAX NG.

Re: [q-lang-users] RFC: Conditional syntax

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

Albert Graef wrote:
> I like those. "choose" seems to be a bit too generic, though, and thus 
> it might collide with user definitions (I actually have a few programs 
> where I use that for nondeterministic choice). That also rules out 
> "test", I guess. But "branch" seems to be ok.

Hmmm...decisions, decisions. Eureka! How about "decide":

***    abs X    = decide (X<0, -X; true, X);

OTOH, I like "branch". I also liked "select", but it is already spoken for. If you like "pick", then I also suggest that you have a look at "take":

***    abs X    = take (X<0, -X; true, X);

Nevermind...I consulted the Q language reference; "take" has been taken. Hmmm...

I formally renounce all of my previous (silly) suggestions, e.g., "co_op". The nominee "mbr" was not mine, but after the dread "cancer of the semicolon", there comes the dark spectre of the "vowel-less bowel". ;-)

As for your latest nominee, "ifcond":

***    abs X    = ifcond (X<0, -X; true, X);

This one looks a little clunky, but it does possess _symmetry_ with "cond" and "ifelse". I do admire symmetry.

So, to sum up my (sticking with the colon jokes, "distended" ;-) two-cents:

1. ifcond    *** my favorite (fickle man that I am) ***
2. branch
3. decide

Cheers,
Keith 
 

Re: [q-lang-users] RFC: Conditional syntax

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

Patrick Albuquerque wrote:
>     abs X    = choose (X<0, -X; true, X);

Keith Trenton wrote:
 >      abs X    = branch (X<0, -X; true, X);

I like those. "choose" seems to be a bit too generic, though, and thus 
it might collide with user definitions (I actually have a few programs 
where I use that for nondeterministic choice). That also rules out 
"test", I guess. But "branch" seems to be ok.

Keith and Brian, thanks for your other suggestions, too. But those 
abbreviations sound an awful lot like assembler opcodes... ;-)

Ok, here is what we got so far:

1. cop, coop, co_op
2. mbr
3. choose
4. branch

Here are some more I "invented" myself:

5. pick
6. check
7. test
8. query
9. guard

BTW, in the library of the Icon language, Dijkstra-style guarded 
statements are named if_fi, but this also looks a bit clumsy.

Or how about:

10. ifcond

This is sufficiently similar to cond, not likely to collide with user 
definitions, and we already have ifelse for the two-way conditional.

Of course, the question is whether we actually need this construct at 
all, since one could always use an if-then-else if-... chain like in 
other programming languages:

sign X = if X<0 then -X
          else if X>0 then X
          else X;

Hmm ... actually, that looks quite messy when compared to:

sign X = ifcond (X<0, -X; X>0, X; true, 0);

I can understand now why Lisp programmers love their cond. ;-)

Comments? Other suggestions?

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] RFC: Conditional syntax

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

Patrick Albuquerque wrote:

>> Albert Graef wrote:
>> >(Ex. 3)
>> >
>> >abs X    = cond (X<0, -X; true, X);
>> 
>> Arrgh, I just noticed that cond is already used in clib
>> for pthread conditions. Too bad. :( Can anyone think
>> of another nice name for the conditional operation?
> 
> Perhaps?
> 
>    abs X    = choose (X<0, -X; true, X);

Wrt today's nominees, I like "choose" best.

Here is one for tomorrow?

     abs X    = branch (X<0, -X; true, X);

Cheers,
Keith 
 

Re: [q-lang-users] RFC: Conditional syntax

[Patrick A. <rp...@al...>]

On Thu, Jun 01, 2006 at 12:59:19AM +0200, Albert Graef wrote:
> Albert Graef wrote:
> >(Ex. 3)
> >
> >abs X    = cond (X<0, -X; true, X);
> 
> Arrgh, I just noticed that cond is already used in clib for pthread 
> conditions. Too bad. :( Can anyone think of another nice name for the 
> conditional operation?
> 

Perhaps?

    abs X    = choose (X<0, -X; true, X);

Patrick.
-- 

Re: [q-lang-users] RFC: Conditional syntax

[<bri...@co...>]

"mccarthy"?  :)

how about "mbr" for m-way branch?

--
BBeckman http://weblogs.asp.net/brianbec http://data/tesla 
------------------------------------------------------------------------------------ 
| Type inference | Object initializers | Anonymous types | XML CRUD | 
| Extension members | LINQ | Relationships | Nested functions | 
| Nullable of T | Relaxed delegates | Dynamic identifiers | Duck typing | 
| Pattern matching | Contracts | AJAX | Iterators | 
| Continuations | REPL | Join Patterns | Transactions | 
| XML Streams | Code Literals | Morphisms | Embedded DSLs | 
------------------------------------------------------------------------------------

-------------- Original message -------------- 
From: Albert Graef <Dr....@t-...> 

> Albert Graef wrote: 
> > (Ex. 3) 
> > 
> > abs X = cond (X<0, -X; true, X); 
> 
> Arrgh, I just noticed that cond is already used in clib for pthread 
> conditions. Too bad. :( Can anyone think of another nice name for the 
> conditional operation? 
> 
> -- 
> 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 
> 
> 
> ------------------------------------------------------- 
> All the advantages of Linux Managed Hosting--Without the Cost and Risk! 
> Fully trained technicians. The highest number of Red Hat certifications in 
> the hosting industry. Fanatical Support. Click to learn more 
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 
> _______________________________________________ 
> q-lang-users mailing list 
> q-l...@li... 
> https://lists.sourceforge.net/lists/listinfo/q-lang-users 

Re: [q-lang-users] RFC: Conditional syntax

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

Albert Graef wrote:
>Hey, that's nice. :) Did you turn 44 already?

Yes! I share my birthday with the ever-so "cool" and "funky-fresh" Benjamin Franklin. ;-)

>At least you didn't have to program in COBOL. 8->

I had to work with people who did. Which was almost as bad.

Cheers,
Keith 
 

Re: [q-lang-users] RFC: Conditional syntax

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

Albert Graef wrote:
>Arrgh, I just noticed that cond is already used in clib for pthread conditions. Too bad. :( Can anyone think of another nice name for the conditional operation?

How about "co_op" or "coop", as in "co-op", as in "conditional operation"?
Or perhaps "cop"? "cops"? "caml"? "ocaml"? (ducks... ;-)

Silly me,
Keith 
 
PS: How about "pop" or "pops", as in "pending operation(s)"? Reminds me of BASIC... ;-)