q-lang-users

[q-lang-users] where

[Eddie R. <ed...@bm...>]

Given the following script

// strip character C from the left and right sides of a string
strip C "" = "";
strip C S = strip C $ sub S 0 (N-1) if (S!N = C) where N = #S-1;
	  = strip C $ sub S 1 N     if (S!0 = C) where N = #S-1;
	  = S                       otherwise;

Is it possible to have another type of local variable defined at the end
of a list of equations that would apply to all of them? For example, the
"where N = #S-1" is on both lines. This is not a good example, but what
if I have a list five or more equations, the same where clause on each
line seems a waste of typing. I understand that "where" should apply to
the equation that it corresponds to instead of all of them because you
might not want the local variable apply to the other equations in the
list.

I know a where clause could be applied to cond, case, and if then else.

Eddie

[q-lang-users] where

[Eddie R. <ed...@bm...>]

Thanks Dr. Greaf for giving the reason. I will use case, cond, if then
else constructs for these situations.

I understand that language decisions can be difficult. Would using a
"letting" statement as in the following example be bad or ugly? I'm
starting to be a bit curious about language design but I don't want to
waste much of your time on this.

example:

strip C "" = "";
strip C S letting N = #S-1
           = strip C $ sub S 0 (N-1) if (S!N = C);
           = strip C $ sub S 1 N     if (S!0 = C);
           = S                       otherwise;

Eddie

Eddie Rucker wrote:
> Given the following script
>
> // strip character C from the left and right sides of a string
> strip C "" = "";
> strip C S = strip C $ sub S 0 (N-1) if (S!N = C) where N = #S-1;
>           = strip C $ sub S 1 N     if (S!0 = C) where N = #S-1;
>           = S                       otherwise;
>
> Is it possible to have another type of local variable defined
at the end
> of a list of equations that would apply to all of them?

No. I actually thought about this problem before. As local
variables are
maintained on the expression stack, it probably wouldn't be that
difficult to modify the VM to handle such shared qualifiers (as
long as
they share the same left-hand side). But I haven't been able to
come up
with a good syntax to support that in the language.

So the solution is indeed to use case or if-then-else in such
situations
instead.

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] where

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

Perhaps the "where" (and even "if" for a common conditional) keywords
could be used for the "letting" clauses (assuming the grammar doesn't
then become ambiguous, and assuming the language can be extended
consistently in this way).

Rob.

On 09/10/06, Eddie Rucker <ed...@bm...> wrote:
> Thanks Dr. Greaf for giving the reason. I will use case, cond, if then
> else constructs for these situations.
>
> I understand that language decisions can be difficult. Would using a
> "letting" statement as in the following example be bad or ugly? I'm
> starting to be a bit curious about language design but I don't want to
> waste much of your time on this.
>
> example:
>
> strip C "" = "";
> strip C S letting N = #S-1
>            = strip C $ sub S 0 (N-1) if (S!N = C);
>            = strip C $ sub S 1 N     if (S!0 = C);
>            = S                       otherwise;
>
> Eddie
>
> Eddie Rucker wrote:
> > Given the following script
> >
> > // strip character C from the left and right sides of a string
> > strip C "" = "";
> > strip C S = strip C $ sub S 0 (N-1) if (S!N = C) where N = #S-1;
> >           = strip C $ sub S 1 N     if (S!0 = C) where N = #S-1;
> >           = S                       otherwise;
> >
> > Is it possible to have another type of local variable defined
> at the end
> > of a list of equations that would apply to all of them?
>
> No. I actually thought about this problem before. As local
> variables are
> maintained on the expression stack, it probably wouldn't be that
> difficult to modify the VM to handle such shared qualifiers (as
> long as
> they share the same left-hand side). But I haven't been able to
> come up
> with a good syntax to support that in the language.
>
> So the solution is indeed to use case or if-then-else in such
> situations
> instead.
>
> 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
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> q-lang-users mailing list
> q-l...@li...
> https://lists.sourceforge.net/lists/listinfo/q-lang-users
>

Re: [q-lang-users] where

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

Rob Hubbard wrote:
> Perhaps the "where" (and even "if" for a common conditional) keywords
> could be used for the "letting" clauses (assuming the grammar doesn't
> then become ambiguous, and assuming the language can be extended
> consistently in this way).

Yes, this could be done. Looks a bit weird, though:

strip C S where N = #S-1
           = strip C $ sub S 0 (N-1) if (S!N = C);
           = strip C $ sub S 1 N     if (S!0 = C);
           = S                       otherwise;

Maybe we can invent a syntax that better mimics the way that
mathematicians actually write these things?

Also, you might then want to nest those shared definitions. E.g., have
another shared variable which is only defined for the second and third
equation. I don't see how this can be done in a free-format language
without introducing some form of bulky begin ... end brackets.

Of course there's an existing solution to this, namely Haskell's guarded
equation syntax, but that also looks fairly messy IMHO. Oh well, I guess
I'll have to take another look at Miranda to see if Turner already
solved that problem.

-- 
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] where

[Eddie R. <ed...@bm...>]

Dr. Graef and (Mr? Dr?) Hubbard,

Of all of the functions in mathematics that I've ever seen, if a "where
clause" is given at the end of a piecewise function, the variables and/or
functions denoted by "where" are global to all of the "pieces." In Q's
case it is very similar to

f x = cond (Condition1, Expression1 with A;
            Condition2, Expression2 with A;
            Condition3, Expression3 with A;
            ...
            ConditionN, ExpressionN)
      where A = ...;

However, a local "where clause" for each equation is a handy feature of
Q.  In math books and papers, symbols are usually defined with "Assume
..." or "Let ..." and then go on to define a function based on the those
symbols. That is why I put a "letting" statement where I did (Although
Mr. Hubbard's use of where looks better).  Perhaps maybe:

let N = #S - 1;
strip C S = strip C $ sub S 0 (N-1) if (S!N = C);
          = ...

or

This might mess things up since "let N" looks like any other equation.
Making "let" a keyword might be a solution, but, then again, since "let
N" looks like any other equation, it doesn't stand out and might get lost
in larger definitions.

Another idea, so that wheres are nested:

f X Y Z
  where A = ... ; // global to all equations belonging to f
     = ...;
     = ...;
  where B = ... ; // global to all equations below this and belonging to f
     = ...;
     = ...;
  where C = ... where D = ...;
     = ...;



Eddie

> Rob Hubbard wrote:
>> Perhaps the "where" (and even "if" for a common conditional) keywords
>> could be used for the "letting" clauses (assuming the grammar doesn't
>> then become ambiguous, and assuming the language can be extended
>> consistently in this way).
>
> Yes, this could be done. Looks a bit weird, though:
>
> strip C S where N = #S-1
>            = strip C $ sub S 0 (N-1) if (S!N = C);
>            = strip C $ sub S 1 N     if (S!0 = C);
>            = S                       otherwise;
>
> Maybe we can invent a syntax that better mimics the way that
> mathematicians actually write these things?
>
> Also, you might then want to nest those shared definitions. E.g., have
> another shared variable which is only defined for the second and third
> equation. I don't see how this can be done in a free-format language
> without introducing some form of bulky begin ... end brackets.
>
> Of course there's an existing solution to this, namely Haskell's guarded
> equation syntax, but that also looks fairly messy IMHO. Oh well, I guess
> I'll have to take another look at Miranda to see if Turner already
> solved that problem.
>
> --
> 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
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> q-lang-users mailing list
> q-l...@li...
> https://lists.sourceforge.net/lists/listinfo/q-lang-users
>

Re: [q-lang-users] where

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

Eddie Rucker wrote:
> Dr. Graef and (Mr? Dr?) Hubbard,

No need to throw around titles here, we're all friendly people. ;-)

That reminds me of a "Hägar the Horrible" strip in which Hägar asks his
medical doctor, Dr. Zook, whether he is allowed to call him by his first
name. "Yes sure," Dr. Zook replies. "So what's your first name?" asks
Hägar. The reply: "Doctor." :)

Ok, back on topic...

> Of all of the functions in mathematics that I've ever seen, if a "where
> clause" is given at the end of a piecewise function, the variables and/or
> functions denoted by "where" are global to all of the "pieces."

That's true, although some mathematicians (me included) occasionally use
local "where" clauses in branches, too. A syntax which closely mimics
this style could maybe look like this:

foo X = ... Y ... where ... if ...,
      = ... Y ...,
where Y = ...;

But that's awkward to parse, since the entire collection of equations
must be in memory before you can start generating code.

> let N = #S - 1;
> strip C S = strip C $ sub S 0 (N-1) if (S!N = C);

This looks like the "let" and the following equation(s) are totally
unrelated. Not a good syntax IMHO.

> Another idea, so that wheres are nested:
> 
> f X Y Z
>   where A = ... ; // global to all equations belonging to f
>      = ...;
>      = ...;
>   where B = ... ; // global to all equations below this and belonging to f
>      = ...;
>      = ...;
>   where C = ... where D = ...;
>      = ...;

That's a neat idea, but still not fully general. What if you want A to
be defined only in eqns #1 and #2 and B only in eqns #3 and #4? You need
some kind of block structure to do that. And IMHO block structure looks
messy in equational programs, at least in a free-format language like Q
where you need explicit brackets to indicate the block structure.

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] where

[Eddie R. <ed...@bm...>]

Albert Graef,

My thinking was about the use of if then else, cond, and case statements
and infinite recursion causing a segment fault on Linux. I was thinking
that the global "where" would cut down on some typing. However, the real
solution to my problem happens to be assert.q. Somehow I overlooked this.
Shame on me! Bug hunting just got a lot easier.

Thanks!

Eddie

> Albert Graef wrote:
>> Of course there's an existing solution to this, namely Haskell's
>> guarded
>> equation syntax, but that also looks fairly messy IMHO. Oh well, I
>> guess
>> I'll have to take another look at Miranda to see if Turner already
>> solved that problem.
>
> I just checked that, and AFAICT in Miranda there are no local
> definitions shared by different equations either. Given that most of
> these usage cases can be handled quite conveniently with if-then-else
> and case, I'm not really convinced that we need the proposed extension.
> Other opinions?
>
> 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
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> q-lang-users mailing list
> q-l...@li...
> https://lists.sourceforge.net/lists/listinfo/q-lang-users
>

Re: [q-lang-users] where

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

"Rob Hubbard" <hub...@gm...> writes:

> If you wish to use "let" syntax, then the "let" clause could end in
> "in" rather than a semi-colon:

Absolutely! It's one of the few ML-isms I still bother remembering - I
always read `let' as `let blah... in' in scheme and haskell.

>     let N = #S - 1 in
>       strip C S = strip C $ sub S 0 (N-1) if (S!N = C);
> 
> that would prevent it looking like a separate definition.
> 
> Further definitions sharing the let clause could be separated by
> something like "and also" (as opposed to "and" or "and then"). I can't
> see a way to provide elegant, "Q-ish" nesting without a terminating
> delimiter for a let clause though. This:
> 
>     let T2 = 2*T in
>       let S = T2+1 in
>         f T = sin S
>       //"end let"
>     and also
>       let P = T2-1 in
>         g T = cos P;
>       //"end let"
>     //"end let"
> 
> would still be ambiguous: which "let" does the "and also" match? An
> "end let" would just produce blocks, which Albert has already
> indicated would not be in keeping with Q. It's a problem.

OK, I've only half been following this, but is there some potential for
using tuples/braces to delimit such a list of local-scope assignments? 
If need be, how about some kind of (= , , , ...)  form for constructing a
scope? 
It's a bit Scheme of me, but hey :)

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

Re: [q-lang-users] where

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

Tim Haynes wrote:
> "Rob Hubbard" <hub...@gm...> writes:
> 
>> If you wish to use "let" syntax, then the "let" clause could end in
>> "in" rather than a semi-colon:
> 
> Absolutely! It's one of the few ML-isms I still bother remembering - I
> always read `let' as `let blah... in' in scheme and haskell.
> 
>>     let N = #S - 1 in
>>       strip C S = strip C $ sub S 0 (N-1) if (S!N = C);

Note that the analogy here is purely syntactical. With an ML-style let x
= y in z, y may only depend on variables bound in the context of the let
expression, not on any variable bound inside z.

The more I think about this, the less I like the idea. In lambda
calculus based languages like ML, the scope of a local definition never
extends across multiple function definitions either. Now in term
rewriting the basic unit of definition is not a function definition, but
the equation. (Indeed the term rewriting machinery doesn't even have an
idea what a "function" is. It just rewrites expressions according to the
equations, and function application is just an expression like any other.)

So, while I see the utility of this, it's at least questionable whether
it fits the basic design of the language. And it doesn't seem to be such
a big deal since we already have other means (if-then-else etc.) to
accomplish the same.

You could even define your own let and letrec special forms in terms of
lambda if you really need them. Let would be fairly straightforward,
letrec might be a little challenge, though, because it involves fixed
points. So where are the lambda hackers who want to take up the
challenge? ;-) I think you'll even find some code for "let" in older
versions of the former lambda.q module. And a version of the Y
combinator which works in Q can be found in the fixpt.q example.

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] where

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

Albert Graef wrote:
> Of course there's an existing solution to this, namely Haskell's guarded
> equation syntax, but that also looks fairly messy IMHO. Oh well, I guess
> I'll have to take another look at Miranda to see if Turner already
> solved that problem.

I just checked that, and AFAICT in Miranda there are no local
definitions shared by different equations either. Given that most of
these usage cases can be handled quite conveniently with if-then-else
and case, I'm not really convinced that we need the proposed extension.
Other opinions?

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] where

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

Eddie Rucker wrote:
> My thinking was about the use of if then else, cond, and case statements
> and infinite recursion causing a segment fault on Linux.

Understood. But that's a bug that will eventually be fixed. We don't
change the language just to work around bugs in the interpreter. ;-)

> However, the real
> solution to my problem happens to be assert.q. Somehow I overlooked this.
> Shame on me! Bug hunting just got a lot easier.

BTW, the interpreter also has a full-blown symbolic debugger. It needs
some time to get used to it, but it's quite useful. See
http://q-lang.sourceforge.net/qdoc/qdoc_16.html#SEC161

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] where

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

If you wish to use "let" syntax, then the "let" clause could end in
"in" rather than a semi-colon:

    let N = #S - 1 in
      strip C S = strip C $ sub S 0 (N-1) if (S!N = C);

that would prevent it looking like a separate definition.

Further definitions sharing the let clause could be separated by
something like "and also" (as opposed to "and" or "and then"). I can't
see a way to provide elegant, "Q-ish" nesting without a terminating
delimiter for a let clause though. This:

    let T2 = 2*T in
      let S = T2+1 in
        f T = sin S
      //"end let"
    and also
      let P = T2-1 in
        g T = cos P;
      //"end let"
    //"end let"

would still be ambiguous: which "let" does the "and also" match? An
"end let" would just produce blocks, which Albert has already
indicated would not be in keeping with Q. It's a problem.

Rob.

PS. It's just "Mr."  :-(  but I'm perfectly happy being referred to as
just "Rob".

Re: [q-lang-users] where

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

Eddie Rucker wrote:
> Given the following script
> 
> // strip character C from the left and right sides of a string
> strip C "" = "";
> strip C S = strip C $ sub S 0 (N-1) if (S!N = C) where N = #S-1;
> 	  = strip C $ sub S 1 N     if (S!0 = C) where N = #S-1;
> 	  = S                       otherwise;
> 
> Is it possible to have another type of local variable defined at the end
> of a list of equations that would apply to all of them?

No. I actually thought about this problem before. As local variables are
maintained on the expression stack, it probably wouldn't be that
difficult to modify the VM to handle such shared qualifiers (as long as
they share the same left-hand side). But I haven't been able to come up
with a good syntax to support that in the language.

So the solution is indeed to use case or if-then-else in such situations
instead.

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