From: Mark Tarver
Subject: Qi II preview
Date: 
Message-ID: <c1294d10-833d-4168-8ff3-0fbfab0790f9@c23g2000hsa.googlegroups.com>
The home site for Qi now contains the first preview of Qi II to be
released in August 2008 (http://www.lambdassociates.org/QiII.htm).
This should answer several questions that people have been posting to
me about license etc. No doubt it will raise a crop of new questions.

This page gives you the opportunity of making a real difference to the
development of Qi without in any way hitting your pocket.  I hope
you'll help in lending your support.

best

Mark

From: ······@gmail.com
Subject: Re: Qi II preview
Date: 
Message-ID: <185df91f-c52f-4a35-b0b1-fa17ab8adfab@d21g2000prf.googlegroups.com>
On Feb 10, 1:43 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
> The home site for Qi now contains the first preview of Qi II to be
> released in August 2008 (http://www.lambdassociates.org/QiII.htm).
> This should answer several questions that people have been posting to
> me about license etc. No doubt it will raise a crop of new questions.
>
> This page gives you the opportunity of making a real difference to the
> development of Qi without in any way hitting your pocket.  I hope
> you'll help in lending your support.

Mark, use my logo!!!

http://xahlee.org/emacs/qi_logo.html

If you like the logo, just use it. Just replace all places you have
that colorful disk image by this logo.

Trust me, as far as web impression goes, it'll advertise your lang to
visitors far better than not.

-------------
Sorry i don't have comments on other aspects of Qi. Hope others will
do that.

... though i do wish, that Qi could incorporate much of the list
manipulation functions into it... since i don't really know common
lisp nor Qi, so i'm not sure how exactly this is pertinent... but
since for example Qi adds pattern matching, it could, for example, add
a Select or “grep/filter” function that filter list using a patttern
(perhaps this is already there...)

  Xah
  ···@xahlee.org
∑ http://xahlee.org/

☄
From: Mark Tarver
Subject: Re: Qi II preview
Date: 
Message-ID: <179e62c7-b7a9-472f-a4cb-4b65107928b7@l16g2000hsh.googlegroups.com>
On 11 Feb, 00:40, ·······@gmail.com" <······@gmail.com> wrote:
> On Feb 10, 1:43 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > The home site for Qi now contains the first preview of Qi II to be
> > released in August 2008 (http://www.lambdassociates.org/QiII.htm).
> > This should answer several questions that people have been posting to
> > me about license etc. No doubt it will raise a crop of new questions.
>
> > This page gives you the opportunity of making a real difference to the
> > development of Qi without in any way hitting your pocket.  I hope
> > you'll help in lending your support.
>
> Mark, use my logo!!!
>
> http://xahlee.org/emacs/qi_logo.html
>
> If you like the logo, just use it. Just replace all places you have
> that colorful disk image by this logo.
>
> Trust me, as far as web impression goes, it'll advertise your lang to
> visitors far better than not.
>
> -------------
> Sorry i don't have comments on other aspects of Qi. Hope others will
> do that.
>
> ... though i do wish, that Qi could incorporate much of the list
> manipulation functions into it... since i don't really know common
> lisp nor Qi, so i'm not sure how exactly this is pertinent... but
> since for example Qi adds pattern matching, it could, for example, add
> a Select or “grep/filter” function that filter list using a patttern
> (perhaps this is already there...)
>
>   Xah
>   ····@xahlee.org
> ∑http://xahlee.org/
>
> ☄

I will use your logo - certainly on Qi files as an icon and quite
possibly elsewhere too.  I'll think about grep.

with thanks

Mark
From: Leslie P. Polzer
Subject: Re: Qi II preview
Date: 
Message-ID: <06f63bc2-9189-4309-893c-7bb026008e6b@s13g2000prd.googlegroups.com>
On Feb 11, 1:40 am, ·······@gmail.com" <······@gmail.com> wrote:

> ... though i do wish, that Qi could incorporate much of the list
> manipulation functions into it... since i don't really know common
> lisp nor Qi, so i'm not sure how exactly this is pertinent... but
> since for example Qi adds pattern matching, it could, for example, add
> a Select or "grep/filter" function that filter list using a patttern
> (perhaps this is already there...)

I don't understand what you want here.
You do know about using higher-order functions to map over lists,
right?

  Leslie
From: Xah Lee
Subject: Re: Qi II preview
Date: 
Message-ID: <06ee28b0-d504-4d1b-9a63-dfb4cfe994c3@v67g2000hse.googlegroups.com>
Dear Leslie,

You wrote:
«I don't understand what you want here. You do know about using higher-
order functions to map over lists, right?»

I assume you are not familiar with Mathematica, right?

Although it may seem that i'm chiding you, but in discussions, one
should be clear about what one knows and what one doesn't know,  as
opposed to stalwartly acts like young college boys do.

If you have a question, _ask_ it earnestly, as opposed to throwing a
tangential exclamation or challenge.

Sure, we are all cocks — congenitally belligerent. But still,
especially in intellectual discourses, braven your way does not
advance you in the eyes of other men.

Now, to answer your question. In this thread, i spoke of list
manipulating functions in Mathematica. I have given out links to their
docs. If you want to know what are these and how easy or difficult it
is to emulate them by mapping functions to list, you can study the
links i gave. I don't think they are too hard to read even if you've
never seen Mathematica code.

Btw, speaking of mapping functions to lists... Mathematica has a whole
set of such functions. Map, MapThread, MapAt, Nest, NestList, Fold,
FoldList, FixedPoint, FixedPointList, Outer... all buildin. These are
really far more advanced in terms of their flexibility at mapping to
lists or recursion, far beyond any of CL, Scheme, or Haskell. (i'm
confident in this claim even i don't really know CL and Haskell)

So, if you have a question, ask. Ask means earnest. You can also ask
even specific questions. You need not necessarily be polite with me. I
judge messages by their content's quality and sincerity.

PS in case you think i'm being silly, yes i am. Y'know? tech geekers
behave asinine in newsgroups, so can i.

  Xah
  ···@xahlee.org
∑ http://xahlee.org/

☄
From: Xah Lee
Subject: Re: Qi II preview
Date: 
Message-ID: <8e291b24-5607-4654-9dd8-e42d63154cba@b2g2000hsg.googlegroups.com>
PS sorry Leslie, actually it is another thread i gave lots links to
Mathematica docs.
The subject of that thread is “Mathematica list function in NewLisp,
Qi” posted about the same day. here's the google link:

http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/6ed66f0a9e7d52d4


On Feb 11, 4:43 am, Xah Lee <····@xahlee.org> wrote:
> Dear Leslie,
>
> You wrote:
>
> «I don't understand what you want here. You do know about using higher-
> order functions to map over lists, right?»
>
> I assume you are not familiar with Mathematica, right?
>
> Although it may seem that i'm chiding you, but in discussions, one
> should be clear about what one knows and what one doesn't know,  as
> opposed to stalwartly acts like young college boys do.
>
> If you have a question, _ask_ it earnestly, as opposed to throwing a
> tangential exclamation or challenge.
>
> Sure, we are all cocks — congenitally belligerent. But still,
> especially in intellectual discourses, braven your way does not
> advance you in the eyes of other men.
>
> Now, to answer your question. In this thread, i spoke of list
> manipulating functions in Mathematica. I have given out links to their
> docs. If you want to know what are these and how easy or difficult it
> is to emulate them by mapping functions to list, you can study the
> links i gave. I don't think they are too hard to read even if you've
> never seen Mathematica code.
>
> Btw, speaking of mapping functions to lists... Mathematica has a whole
> set of such functions. Map, MapThread, MapAt, Nest, NestList, Fold,
> FoldList, FixedPoint, FixedPointList, Outer... all buildin. These are
> really far more advanced in terms of their flexibility at mapping to
> lists or recursion, far beyond any of CL, Scheme, or Haskell. (i'm
> confident in this claim even i don't really know CL and Haskell)
>
> So, if you have a question, ask. Ask means earnest. You can also ask
> even specific questions. You need not necessarily be polite with me. I
> judge messages by their content's quality and sincerity.
>
> PS in case you think i'm being silly, yes i am. Y'know? tech geekers
> behave asinine in newsgroups, so can i.
>
>   Xah
>   ····@xahlee.org
> ∑http://xahlee.org/
>
> ☄
From: Leslie P. Polzer
Subject: Re: Qi II preview
Date: 
Message-ID: <b1d1f503-20a0-44b7-94cf-de70d6a438d3@e6g2000prf.googlegroups.com>
On Feb 11, 1:53 pm, Xah Lee <····@xahlee.org> wrote:
> PS sorry Leslie, actually it is another thread i gave lots links to
> Mathematica docs.
> The subject of that thread is "Mathematica list function in NewLisp,
> Qi" posted about the same day. here's the google link:
>
> http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/6ed66...

Well, it makes a bit more sense now.
I haven't got that much time, but I took a look at the SELECT function
of Mathematica (which you requested to have added to Qi) and still
don't understand how this would be different from, say

  (REMOVE-IF-NOT #'evenp '(1 2 3 4))

I didn't mean to insult you in my previous post, I'm honestly curious
about this.
And yes, I don't have any experience with Mathematica and can't afford
to go through its docs at this time, so please be patient with me.

  Leslie
From: Xah Lee
Subject: Re: Qi II preview
Date: 
Message-ID: <54f2badc-cad0-43a4-add6-6eb61509f240@u10g2000prn.googlegroups.com>
oops, i meant to say Cases instead Select... anyway... here's the
deal.

Select[list, predicateFunct]

like the example you have, it apply a function to a list, and return
elements that is true.

What i meant originally should be Cases. Cases[list,pattern], is like
select, except that the second argument is a pattern. It return
elements where the pattern matches. However, Cases takes optional 3rd
argument that specifies a level(s), this is where things gets
interesting and is not trivial to implement.

http://reference.wolfram.com/mathematica/ref/Cases.html

I was suggesting to Mark about Cases since Qi adds pattern matching to
CL, so this seems a good candidate for addition.

----------

As to Select, lisper might wonder why add such a function while one
can just map a predicate to a list. The answer is that, this is good
in my opinion because it shorterns the code and adds clarity. Little
conveniences here and there really adds up. Common lispers think the
same way when criticizing Scheme.

  Xah
  ···@xahlee.org
∑ http://xahlee.org/

☄
From: Victor Kryukov
Subject: Re: Qi II preview
Date: 
Message-ID: <871w7ill99.fsf@esculap.gateway.2wire.net>
Xah Lee <···@xahlee.org> writes:

> As to Select, lisper might wonder why add such a function while one
> can just map a predicate to a list. The answer is that, this is good
> in my opinion because it shorterns the code and adds clarity. Little
> conveniences here and there really adds up. Common lispers think the
> same way when criticizing Scheme.

Indeed, lisper might wonder why to add such a function while
REMOVE-IF-NOT already exists and serves exactly this purpose:

CL-USER> (remove-if-not #'oddp '(1 2 3 4 5 6 7))
(1 3 5 7)

Renaming REMOVE-IF-NOT to SELECT is not a big deal.

Regards,
Victor.
From: Maciej Katafiasz
Subject: Re: Qi II preview
Date: 
Message-ID: <forocq$g3d$4@news.net.uni-c.dk>
Den Mon, 11 Feb 2008 21:47:29 -0800 skrev Xah Lee:

> oops, i meant to say Cases instead Select... anyway... here's the deal.
> 
> Select[list, predicateFunct]
> 
> like the example you have, it apply a function to a list, and return
> elements that is true.
> 
> What i meant originally should be Cases. Cases[list,pattern], is like
> select, except that the second argument is a pattern. It return elements
> where the pattern matches. However, Cases takes optional 3rd argument
> that specifies a level(s), this is where things gets interesting and is
> not trivial to implement.
> 
> http://reference.wolfram.com/mathematica/ref/Cases.html

Looking at that reference, it seems to me that the most interesting 
things happen not when you add levels, which I understand should be 
fairly trivial, but when you employ patterns. Since Mathematica is really 
a rule rewriter, which Lisp and Qi aren't, I don't see the possibility to 
implement this for example:

-- Return the x from inside each f[x_] matched:
In[1]:=	Cases[{1, 1, f[a], 2, 3, y, f[8], 9, f[10]}, f[x_] -> x]
Out[1]=	{a, 8, 10}

And it seems to me that every other pattern match you can already express 
in Qi you could trivially MAPCAR with a lambda over the list. So Cases is 
reduced to just MAPCAR for structures other than flat lists, which, 
whilst possibly still handy, depending on your usage patterns, is 
considerably less earth-shaking.

Cheers,
Maciej
From: Xah Lee
Subject: Re: Qi II preview
Date: 
Message-ID: <49728ca7-2683-46e4-9b75-296d8846eea1@p69g2000hsa.googlegroups.com>
Maciej Katafiasz <········@gmail.com> wrote:

> >http://reference.wolfram.com/mathematica/ref/Cases.html
>
> Looking at that reference, it seems to me that the most interesting
> things happen not when you add levels, which I understand should be
> fairly trivial, but when you employ patterns.

The power of Mathematica's pattern matching facilities is quite beyond
any lang out there, as far as i know. So, let's ignore Mathematica's
patterns for the moment because otherwise we'd be talking about
implementing Mathematica.

(note here: my main interest in this thread, as well as many others
recently, is just about adding Mathematica's list manipulating
functions to lisp, which is doable and practical. Adding Mathematica's
pattern matching to lisp would be too big a topic.)

The level spec in Mathematica is actually quite interesting.

When reading the doc site:
 http://reference.wolfram.com/mathematica/ref/Cases.html

click on the “More Infomation” yellow box. It gives you details.
Here's few excerpt:

• Cases uses standard level specifications:

   n               levels 1 through n
   Infinity        levels 1 through Infinity
   {n}             level n only
   {n1,n2}         levels n1 through n2

• The default value for levelspec in Cases is {1}.

• A positive level n consists of all parts of expr specified by n
indices.

• A negative level -n consists of all parts of expr with depth n.

• Level -1 consists of numbers, symbols and other objects that do not
have subparts.

• Level 0 corresponds to the whole expression.

-----------------------

Note that, this levelspec is basically either a interger/Infinity, or
a list of 1 or 2 integers/Infinity. (Examples: {1} means just level 1.
{3,5} means levels 3, 4, 5. {2,-2} means level 2, 3,... up to any
branch/node that has a depth of 2)

 This levelspec is a optional argument throughout any functions that
manipulates list or maps to list. Now, for the moment let's assume
that mapping to levels or manipulating lists with specified levels is
useful. But adding this to ALL list related functions, as to achieve a
consistent and uniform way to deal with trees, is quite another level
of power.

This levelspec, in its full generality as specified above, is not easy
to implement. You can try implement it for lisp's map. I bet it's more
than a hundred lines.

So, if you gonna add such a option to all lisp's functions that deals
with lists, you dont implement for each one. Instead, you write a
general code that deals with levels, and have all your list functions
call it.

(i've studied and implement this in some depth, in ~1998, at a time
i'm a naive, total blank about computer science. I think basically you
need some internal data structure for trees. The way i did it was
basically use a flat list to represent tree. Each element has 2 parts,
one being the node's index, and the other being the node's item. So,
in essence, i decompose a tree into this flat structure, then
manipulate any levelspec or other tree-transformation by manipulating
the indexes, then use the result to reconstructe a new tree. I think
this method is the mathematical essence of any implementation of
dealing with manipulating trees in the general way.
see the Mathematica notebook here: http://xahlee.org/tree/tree.html
)

Now, when this levelspec is used, let's say {2,5}, meaning level 2 to
5 inclusive, and when this is used in a context of pattern matching as
in Mathematica's Cases[], it gets rather quite complex. Because,
there's the question of which level is gonna be pattern matched first,
because Mathematica patterns can match just about any shape of nested
list. So this why the last sentence in the spec says “Cases traverses
the parts of expr in a depth-first order, with leaves visited before
roots.”.

In practice, using patterns with levelspec that's more than one level,
is rather complex. To give a picture of this...: unless you have
programed in Mathematica daily for few years, you generally don't use
it and don't need to use it. (it becomes very powerful when you are
throughly familiar with tree structure and Mathematica's pattern spec)
(in analogy, this is somewhat similar to regex. Some of the regex
features you generally never use, but are critical when you need it)

--------------------

Imagine someone accustomized to the above highlevel flexibility of
dealing with trees, then is exposed to lisp's cons business with car,
cdr, cddar! That is the shock i got when i was learning purportedly
the most elegant lang the Scheme lisp back in 1998.

See My Lisp experience:
 http://xahlee.org/PageTwo_dir/Personal_dir/xah_comp_exp.html

As i have expressed before, due to the cons surfacing to the language
level masquirading as a list syntax, a programer cannot practically
write programs and pretending it doesn't exist. I could, in my own
emacs lisp program, avoid cons and always construct only proper lists
and use higher level list functions on them. But as soon as i read
other's lisp code, i'll see cons. This is not just a syntactical,
perpectual inconvenience. Because, i could not use the high-level list
function on arbitrary lists in other people's code, because there's
the proper list and improper list distinction due to the fact that
lists longer than 2 elements are made of cons in some specific way. In
essence, the power of the concept of trees, is reduced to binary
trees, in lisp.

This is why, in lisps, there are never much advancement to
manipulating lists in a more general and powerful way. The cons stops
it.

As far as i know, the reason lisp has cons is really due to a
particular hardware. (see for example, http://en.wikipedia.org/wiki/CAR_and_CDR
) This is a instance of damage of not clearly understanding or
seperating issues related to hardware/speed/compilation with issues
related to the mathematical specification of computation. Similar
damage includes the so-called “types” of int/long/float/double/, the
concept of “point/reference” in many langs, lisp's concept of
“objects”, and in general the concept of a language's data types, ...
See:

• Jargons And High Level Languages
 http://xahlee.org/emacs/jargons_high_level_lang.html

(cross posted to comp.lang.functional)

  Xah
  ···@xahlee.org
∑ http://xahlee.org/

☄

On Feb 12, 1:20 am, Maciej Katafiasz <········@gmail.com> wrote:
> Den Mon, 11 Feb 2008 21:47:29 -0800 skrevXahLee:
>
> > oops, i meant to say Cases instead Select... anyway... here's the deal.
>
> > Select[list, predicateFunct]
>
> > like the example you have, it apply a function to a list, and return
> > elements that is true.
>
> > What i meant originally should be Cases. Cases[list,pattern], is like
> > select, except that the second argument is a pattern. It return elements
> > where the pattern matches. However, Cases takes optional 3rd argument
> > that specifies a level(s), this is where things gets interesting and is
> > not trivial to implement.
>
> >http://reference.wolfram.com/mathematica/ref/Cases.html
>
> Looking at that reference, it seems to me that the most interesting
> things happen not when you add levels, which I understand should be
> fairly trivial, but when you employ patterns. Since Mathematica is really
> a rule rewriter, which Lisp and Qi aren't, I don't see the possibility to
> implement this for example:
>
> -- Return the x from inside each f[x_] matched:
> In[1]:= Cases[{1, 1, f[a], 2, 3, y, f[8], 9, f[10]}, f[x_] -> x]
> Out[1]= {a, 8, 10}
>
> And it seems to me that every other pattern match you can already express
> in Qi you could trivially MAPCAR with a lambda over the list. So Cases is
> reduced to just MAPCAR for structures other than flat lists, which,
> whilst possibly still handy, depending on your usage patterns, is
> considerably less earth-shaking.
>
> Cheers,
> Maciej
From: Rainer Joswig
Subject: Re: Qi II preview
Date: 
Message-ID: <joswig-219455.13425212022008@news-europe.giganews.com>
In article 
<····································@p69g2000hsa.googlegroups.com>,
 Xah Lee <···@xahlee.org> wrote:

> This levelspec, in its full generality as specified above, is not easy
> to implement. You can try implement it for lisp's map. I bet it's more
> than a hundred lines.

Is it? In Common Lisp it's only a few lines:

(defun mapc-level (list fn &key (start-level 0) (end-level start-level))
  (labels ((mapc-level-aux (list level)
             (unless (and (numberp end-level) (> level end-level))
               (when (or (eq end-level :infinity) (< level end-level))
                 (loop for item in list unless (atom item) do (mapc-level-aux item (1+ level))))
               (when (or (and (numberp end-level)
                              (<= start-level level end-level))
                         (and (eq end-level :infinity)
                              (<= start-level level)))
                 (loop for item in list
                   when (atom item) do (funcall fn item))))))
    (mapc-level-aux list 0))
  list)

(defun cases (list predicate &key (start-level 0) (end-level start-level))
  (let ((result nil))
    (mapc-level list (lambda (item)
                       (when (funcall predicate item)
                         (push item result)))
                :start-level start-level
                :end-level end-level)
    result))


Plus it is nicer to call:

(CASES '(1 2 3 (537 322 (10 (11))) 43 22 388 (12 (33 (22 12 44))))
       #'EVENP
       :START-LEVEL 1
       :END-LEVEL 2)

Other examples

(CASES '(1 2 3 (537 322 (10 (11))) 43 22 388 (12 (33 (22 12 44))))
       #'EVENP)

(CASES '(1 2 3 (537 322 (10 (11))) 43 22 388 (12 (33 (22 12 44))))
       #'EVENP
       :end-level :infinity)

(CASES '(1 2 3 (537 322 (10 (11))) 43 22 388 (12 (33 (22 12 44))))
       #'EVENP
       :start-level 2
       :end-level :infinity)
From: ···········@gmail.com
Subject: Re: Qi II preview
Date: 
Message-ID: <13a46b8d-cfdc-4286-a505-85a57d075962@e25g2000prg.googlegroups.com>
Mark, are you planning on doing anything about the datatype syntax. I
mean, all those underscores and equal signes are pretty hideous and
could probably be cut out somehow.

(1+) (datatype binary

if (element? X [0 1])
_____________
X : zero-or-one;

X : zero-or-one;
__________________
[X] : binary;

X : zero-or-one; Y : binary;
____________________________
[X | Y] : binary;

X : zero-or-one, [Y | Z] : binary >> P;
___________________________________________
[X Y | Z] : binary >> P;)
binary
From: Mark Tarver
Subject: Re: Qi II preview
Date: 
Message-ID: <eede44e0-3e83-4a0c-b71b-5c654366a5ee@e4g2000hsg.googlegroups.com>
On 11 Feb, 17:27, ···········@gmail.com wrote:
> Mark, are you planning on doing anything about the datatype syntax. I
> mean, all those underscores and equal signes are pretty hideous and
> could probably be cut out somehow.
>
> (1+) (datatype binary
>
> if (element? X [0 1])
> _____________
> X : zero-or-one;
>
> X : zero-or-one;
> __________________
> [X] : binary;
>
> X : zero-or-one; Y : binary;
> ____________________________
> [X | Y] : binary;
>
> X : zero-or-one, [Y | Z] : binary >> P;
> ___________________________________________
> [X Y | Z] : binary >> P;)
> binary

Well actually its the orthodox notation for sequent calculus as handed
down in virtually all books.  ==== is just the ASCII substitute for
double underline.  Its neater not to make these underlines stretch
beyond the text.  But if it offends you and you don't like spacing
stuff out then you can always write it like this.

(datatype binary

 if (element? X [0 1]) ___ X : zero-or-one;
 X : zero-or-one; ___ [X] : binary;
 X : zero-or-one; Y : binary; _____  [X | Y] : binary;
 X : zero-or-one, [Y | Z] : binary >> P; _____ [X Y | Z] : binary >>
P;)

And if you're *still* not happy you can program the Qi reader to
invent your own version.

Mark
From: Ron Garret
Subject: Re: Qi II preview
Date: 
Message-ID: <rNOSPAMon-C3B71E.12010811022008@news.gha.chartermi.net>
In article 
<····································@e4g2000hsg.googlegroups.com>,
 Mark Tarver <··········@ukonline.co.uk> wrote:

> On 11 Feb, 17:27, ···········@gmail.com wrote:
> > Mark, are you planning on doing anything about the datatype syntax. I
> > mean, all those underscores and equal signes are pretty hideous and
> > could probably be cut out somehow.
> >
> > (1+) (datatype binary
> >
> > if (element? X [0 1])
> > _____________
> > X : zero-or-one;
> >
> > X : zero-or-one;
> > __________________
> > [X] : binary;
> >
> > X : zero-or-one; Y : binary;
> > ____________________________
> > [X | Y] : binary;
> >
> > X : zero-or-one, [Y | Z] : binary >> P;
> > ___________________________________________
> > [X Y | Z] : binary >> P;)
> > binary
> 
> Well actually its the orthodox notation for sequent calculus as handed
> down in virtually all books.

But it's a bad notation for programming.  Really really bad.

The reason it's bad is because it's an inherently two-dimensional 
notation designed to be rendered by sophisticated typesetting apparatus 
and to be "parsed" by the human visual system.  But programs are, at 
least traditionally, one-dimensional.  So unless you specify very 
carefully how the two-dimensional representation maps onto the 
one-dimensional structure you end up with ambiguities.  For example, 
does the length of the line have any semantic meaning?  Is

foo baz bar
___________
biff boff bratz

the same as

foo baz bar
_______________
biff boff bratz

or

foo baz bar
___
biff boff bratz

or even

foo baz bar _________ biff boff bratz

or

foo baz bar
______________________________________________
biff boff bratz

or

foo baz bar
_ _ _ _ _ _ _ _
biff boff bratz

or

foo baz bar
_
_
_
_
_
biff boff bratz

Worse, once you open the door to this kind of silliness you have to 
allow for other potential uses of two-dimensional notation.  (Why should 
*your* pet project get special treatment?)  So I might want to revert to 
my schoolboy days and write X/Y as:

X
_
Y

Or maybe, if the vertical offset of the underscore offends my 
typographical sensibilities:

X
-
Y

which is intended to be distinct from, say, x-y (which might in turn be 
distinct from x - y, which is distinct from x - -y, which is distinct 
from x - - y, is distinct from

x
- -
y

which may or may not be meaningful (but c.f. the dashed-line example 
above) but which is nonetheless distinct from

x
-
-y

which may or may not be the right way to render (/ x (- y)) depending on 
which way your typographical rendering rules run.

Trying to import a two-dimensional mathematical notation into 
character-based programming is a Pandora's box which is better left 
unopened.

IMHO of course.

rg
From: Pascal Bourguignon
Subject: Re: Qi II preview
Date: 
Message-ID: <878x1rjlds.fsf@thalassa.informatimago.com>
Ron Garret <·········@flownet.com> writes:
> [...]
> x
> -
> -y
>
> which may or may not be the right way to render (/ x (- y)) depending on 
> which way your typographical rendering rules run.
>
> Trying to import a two-dimensional mathematical notation into 
> character-based programming is a Pandora's box which is better left 
> unopened.

I agree with you, it's silly, but smart guys at NASA thought it would
be nice do write programs in 2D, in HAL/S:

http://www.aclevercookie.com/nasa-spaceshuttle-programming-language-exposed/


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
        Un chat errant
se soulage
        dans le jardin d'hiver
                                        Shiki
From: Ron Garret
Subject: Re: Qi II preview
Date: 
Message-ID: <rNOSPAMon-29F3FB.12543911022008@news.gha.chartermi.net>
In article <··············@thalassa.informatimago.com>,
 Pascal Bourguignon <···@informatimago.com> wrote:

> Ron Garret <·········@flownet.com> writes:
> > [...]
> > x
> > -
> > -y
> >
> > which may or may not be the right way to render (/ x (- y)) depending on 
> > which way your typographical rendering rules run.
> >
> > Trying to import a two-dimensional mathematical notation into 
> > character-based programming is a Pandora's box which is better left 
> > unopened.
> 
> I agree with you, it's silly, but smart guys at NASA thought it would
> be nice do write programs in 2D, in HAL/S:
> 
> http://www.aclevercookie.com/nasa-spaceshuttle-programming-language-exposed/

Even smart people make mistakes.

rg
From: JohnW
Subject: Re: Qi II preview
Date: 
Message-ID: <b270e2a3-1b0b-4d2d-84b8-ea8c779c585d@s8g2000prg.googlegroups.com>
On Feb 11, 9:41 am, Mark Tarver <··········@ukonline.co.uk> wrote:
> > Mark, are you planning on doing anything about the datatype syntax. I
> > mean, all those underscores and equal signes are pretty hideous and
> > could probably be cut out somehow.
>
> Well actually its the orthodox notation for sequent calculus as handed
> down in virtually all books.  ==== is just the ASCII substitute for
> double underline.  Its neater not to make these underlines stretch
> beyond the text.  But if it offends you and you don't like spacing
> stuff out then you can always write it like this.

I have to agree that incorporating what is essentially ASCII graphics
into a programming language feels rather awkward.  I would also
prefer /. to be "fn", since as a Lisper I'm using to see words at the
beginning of a list, not odd characters.  At least that one is rather
easy to fix.

While reading the book 'The Art of Readable Writing', one of the
things it recommended was to "murder your darlings"; that is,
eliminate phrasing we find cute and adorable, since they more reflect
our personal preferences than help to create clarity.  I think this
could apply equally well to syntax design.

John
From: Mark Tarver
Subject: Re: Qi II preview
Date: 
Message-ID: <05d2d935-4961-43df-84d7-da28fc0998ce@s13g2000prd.googlegroups.com>
On 11 Feb, 20:37, JohnW <········@gmail.com> wrote:
> On Feb 11, 9:41 am, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > Mark, are you planning on doing anything about the datatype syntax. I
> > > mean, all those underscores and equal signes are pretty hideous and
> > > could probably be cut out somehow.
>
> > Well actually its the orthodox notation for sequent calculus as handed
> > down in virtually all books.  ==== is just the ASCII substitute for
> > double underline.  Its neater not to make these underlines stretch
> > beyond the text.  But if it offends you and you don't like spacing
> > stuff out then you can always write it like this.
>
> I have to agree that incorporating what is essentially ASCII graphics
> into a programming language feels rather awkward.  I would also
> prefer /. to be "fn", since as a Lisper I'm using to see words at the
> beginning of a list, not odd characters.  At least that one is rather
> easy to fix.
>
> While reading the book 'The Art of Readable Writing', one of the
> things it recommended was to "murder your darlings"; that is,
> eliminate phrasing we find cute and adorable, since they more reflect
> our personal preferences than help to create clarity.  I think this
> could apply equally well to syntax design.
>
> John

I think if you come from a logical background and you're used to
seeing the standard notation then Qi/Qi II looks easy to grasp.  This
notation has been around for 60 years.  Its older than Lisp.  Its not
my darling.  Have a look at http://en.wikipedia.org/wiki/Sequent_calculus

The presentation is 2-D but the formatting is at the discretion of the
programmer.  Its not essential to lay it out in the way I do.  Its no
more essentially 2-D than Lisp is 2-D because you pretty-print Lisp in
2-D.

(define &-right {problem --> problem} Pr -> ((#. P;Q; ___ [P & Q])
Pr))

or

(define &-right
   {problem --> problem}
   Pr -> ((#. P;Q; ___ [P & Q]) Pr))

or

(define &-right
   {problem --> problem}
   Pr -> ((#. P;Q;
                 ______
                 [P & Q]) Pr))

are all the same.

Still you can suggest alternatives.

Mark
From: Mark Tarver
Subject: Qi II syntax for sequents
Date: 
Message-ID: <7baa02e4-96db-49e7-ba57-9356d5e42e71@e6g2000prf.googlegroups.com>
On 11 Feb, 21:54, Mark Tarver <··········@ukonline.co.uk> wrote:
> On 11 Feb, 20:37, JohnW <········@gmail.com> wrote:
>
>
>
>
>
> > On Feb 11, 9:41 am, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > > Mark, are you planning on doing anything about the datatype syntax. I
> > > > mean, all those underscores and equal signes are pretty hideous and
> > > > could probably be cut out somehow.
>
> > > Well actually its the orthodox notation for sequent calculus as handed
> > > down in virtually all books.  ==== is just the ASCII substitute for
> > > double underline.  Its neater not to make these underlines stretch
> > > beyond the text.  But if it offends you and you don't like spacing
> > > stuff out then you can always write it like this.
>
> > I have to agree that incorporating what is essentially ASCII graphics
> > into a programming language feels rather awkward.  I would also
> > prefer /. to be "fn", since as a Lisper I'm using to see words at the
> > beginning of a list, not odd characters.  At least that one is rather
> > easy to fix.
>
> > While reading the book 'The Art of Readable Writing', one of the
> > things it recommended was to "murder your darlings"; that is,
> > eliminate phrasing we find cute and adorable, since they more reflect
> > our personal preferences than help to create clarity.  I think this
> > could apply equally well to syntax design.
>
> > John
>
> I think if you come from a logical background and you're used to
> seeing the standard notation then Qi/Qi II looks easy to grasp.  This
> notation has been around for 60 years.  Its older than Lisp.  Its not
> my darling.  Have a look athttp://en.wikipedia.org/wiki/Sequent_calculus
>
> The presentation is 2-D but the formatting is at the discretion of the
> programmer.  Its not essential to lay it out in the way I do.  Its no
> more essentially 2-D than Lisp is 2-D because you pretty-print Lisp in
> 2-D.
>
> (define &-right {problem --> problem} Pr -> ((#. P;Q; ___ [P & Q])
> Pr))
>
> or
>
> (define &-right
>    {problem --> problem}
>    Pr -> ((#. P;Q; ___ [P & Q]) Pr))
>
> or
>
> (define &-right
>    {problem --> problem}
>    Pr -> ((#. P;Q;
>                  ______
>                  [P & Q]) Pr))
>
> are all the same.
>
> Still you can suggest alternatives.
>
> Mark- Hide quoted text -
>
> - Show quoted text -

OK; - what about this?

(define &-right
   {problem --> problem}
   Pr -> ((#. P;Q; ==>  [P & Q]) Pr))

and <==> for double underline.

You can use the star rating on Google to vote this one - 5* love it 1*
hate it etc.
I think this looks good and keeps the logical intuition.

Mark
From: Ron Garret
Subject: Re: Qi II syntax for sequents
Date: 
Message-ID: <rNOSPAMon-A573B4.15043211022008@news.gha.chartermi.net>
In article 
<····································@e6g2000prf.googlegroups.com>,
 Mark Tarver <··········@ukonline.co.uk> wrote:

> On 11 Feb, 21:54, Mark Tarver <··········@ukonline.co.uk> wrote:
> > On 11 Feb, 20:37, JohnW <········@gmail.com> wrote:
> >
> >
> >
> >
> >
> > > On Feb 11, 9:41�am, Mark Tarver <··········@ukonline.co.uk> wrote:
> >
> > > > > Mark, are you planning on doing anything about the datatype syntax. I
> > > > > mean, all those underscores and equal signes are pretty hideous and
> > > > > could probably be cut out somehow.
> >
> > > > Well actually its the orthodox notation for sequent calculus as handed
> > > > down in virtually all books. �==== is just the ASCII substitute for
> > > > double underline. �Its neater not to make these underlines stretch
> > > > beyond the text. �But if it offends you and you don't like spacing
> > > > stuff out then you can always write it like this.
> >
> > > I have to agree that incorporating what is essentially ASCII graphics
> > > into a programming language feels rather awkward. �I would also
> > > prefer /. to be "fn", since as a Lisper I'm using to see words at the
> > > beginning of a list, not odd characters. �At least that one is rather
> > > easy to fix.
> >
> > > While reading the book 'The Art of Readable Writing', one of the
> > > things it recommended was to "murder your darlings"; that is,
> > > eliminate phrasing we find cute and adorable, since they more reflect
> > > our personal preferences than help to create clarity. �I think this
> > > could apply equally well to syntax design.
> >
> > > John
> >
> > I think if you come from a logical background and you're used to
> > seeing the standard notation then Qi/Qi II looks easy to grasp. �This
> > notation has been around for 60 years. �Its older than Lisp. �Its not
> > my darling. �Have a look athttp://en.wikipedia.org/wiki/Sequent_calculus
> >
> > The presentation is 2-D but the formatting is at the discretion of the
> > programmer. �Its not essential to lay it out in the way I do. �Its no
> > more essentially 2-D than Lisp is 2-D because you pretty-print Lisp in
> > 2-D.
> >
> > (define &-right {problem --> problem} Pr -> ((#. P;Q; ___ [P & Q])
> > Pr))
> >
> > or
> >
> > (define &-right
> > � �{problem --> problem}
> > � �Pr -> ((#. P;Q; ___ [P & Q]) Pr))
> >
> > or
> >
> > (define &-right
> > � �{problem --> problem}
> > � �Pr -> ((#. P;Q;
> > � � � � � � � � �______
> > � � � � � � � � �[P & Q]) Pr))
> >
> > are all the same.
> >
> > Still you can suggest alternatives.
> >
> > Mark- Hide quoted text -
> >
> > - Show quoted text -
> 
> OK; - what about this?
> 
> (define &-right
>    {problem --> problem}
>    Pr -> ((#. P;Q; ==>  [P & Q]) Pr))
> 
> and <==> for double underline.
> 
> You can use the star rating on Google to vote this one - 5* love it 1*
> hate it etc.
> I think this looks good and keeps the logical intuition.
> 
> Mark

Five stars.  :-)

rg
From: Michael Weber
Subject: Re: Qi II syntax for sequents
Date: 
Message-ID: <a4e3f864-715d-4872-9f3c-d700b5b7c624@l32g2000hse.googlegroups.com>
On Feb 11, 11:12 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
> On 11 Feb, 21:54, Mark Tarver <··········@ukonline.co.uk> wrote:
>
>
>
> > On 11 Feb, 20:37, JohnW <········@gmail.com> wrote:
>
> > > On Feb 11, 9:41 am, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > > > Mark, are you planning on doing anything about the datatype syntax. I
> > > > > mean, all those underscores and equal signes are pretty hideous and
> > > > > could probably be cut out somehow.
>
> > > > Well actually its the orthodox notation for sequent calculus as handed
> > > > down in virtually all books.  ==== is just the ASCII substitute for
> > > > double underline.  Its neater not to make these underlines stretch
> > > > beyond the text.  But if it offends you and you don't like spacing
> > > > stuff out then you can always write it like this.
>
> > > I have to agree that incorporating what is essentially ASCII graphics
> > > into a programming language feels rather awkward.  I would also
> > > prefer /. to be "fn", since as a Lisper I'm using to see words at the
> > > beginning of a list, not odd characters.  At least that one is rather
> > > easy to fix.
>
> > > While reading the book 'The Art of Readable Writing', one of the
> > > things it recommended was to "murder your darlings"; that is,
> > > eliminate phrasing we find cute and adorable, since they more reflect
> > > our personal preferences than help to create clarity.  I think this
> > > could apply equally well to syntax design.
>
> > > John
>
> > I think if you come from a logical background and you're used to
> > seeing the standard notation then Qi/Qi II looks easy to grasp.  This
> > notation has been around for 60 years.  Its older than Lisp.  Its not
> > my darling.  Have a look athttp://en.wikipedia.org/wiki/Sequent_calculus
>
> > The presentation is 2-D but the formatting is at the discretion of the
> > programmer.  Its not essential to lay it out in the way I do.  Its no
> > more essentially 2-D than Lisp is 2-D because you pretty-print Lisp in
> > 2-D.
>
> > (define &-right {problem --> problem} Pr -> ((#. P;Q; ___ [P & Q])
> > Pr))
>
> > or
>
> > (define &-right
> >    {problem --> problem}
> >    Pr -> ((#. P;Q; ___ [P & Q]) Pr))
>
> > or
>
> > (define &-right
> >    {problem --> problem}
> >    Pr -> ((#. P;Q;
> >                  ______
> >                  [P & Q]) Pr))
>
> > are all the same.
>
> > Still you can suggest alternatives.
>
> > Mark- Hide quoted text -
>
> > - Show quoted text -
>
> OK; - what about this?
>
> (define &-right
>    {problem --> problem}
>    Pr -> ((#. P;Q; ==>  [P & Q]) Pr))
>
> and <==> for double underline.
>
> You can use the star rating on Google to vote this one - 5* love it 1*
> hate it etc.
> I think this looks good and keeps the logical intuition.

It's slightly better than the 2D notation, but it still looks out of
place in a lispy language.

If you go to infix notation you reintroduce the can of worms that is
operator precedence, extra terminal symbols, the need to invent your
own macro system with another set of rules when and in which order
macros apply, syntax-directed tools (editors, pretty printers, etc.),
etc.. All for the little gain of having a "familiar" notation.
I am used to sequent notation even if it's /not/ in the pretty-printed
2D form (cf. LaTeX's semantic package), and parsing it is the least of
my worries if I just know where are the antecedents and where are the
consequents.


Michael
From: JohnW
Subject: Re: Qi II preview
Date: 
Message-ID: <21a81c42-829f-4147-8ee3-d0a98fa80dd6@c4g2000hsg.googlegroups.com>
On Feb 11, 1:54 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
> I think if you come from a logical background and you're used to
> seeing the standard notation then Qi/Qi II looks easy to grasp.  This
> notation has been around for 60 years.  Its older than Lisp.  Its not
> my darling.  Have a look athttp://en.wikipedia.org/wiki/Sequent_calculus

But is your intended audience those with a logical background?
Perhaps what Qi really wants is to introduce the concept of logical
typing to the generality of programmers.  I certainly found your
sequent typing idea to be like a revelation; I've fallen in love with
the concept.  But my non-logical background has caused the 2D notation
to feel a bit strange.

I don't yet have the depth of experience needed to suggest alternates
to you; I can only say how it strikes me.  But I guess what I would
recommend is that instead of using a syntax that's oriented from logic
to Lisp, you find something equally brilliant that aims from Lisp to
logic.

John
From: Mark Tarver
Subject: Re: Qi II preview
Date: 
Message-ID: <5a3c7aa2-f1fd-4c4a-8c23-4805324c0a5d@z17g2000hsg.googlegroups.com>
On 11 Feb, 22:18, JohnW <········@gmail.com> wrote:
> On Feb 11, 1:54 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > I think if you come from a logical background and you're used to
> > seeing the standard notation then Qi/Qi II looks easy to grasp.  This
> > notation has been around for 60 years.  Its older than Lisp.  Its not
> > my darling.  Have a look athttp://en.wikipedia.org/wiki/Sequent_calculus
>
> But is your intended audience those with a logical background?
> Perhaps what Qi really wants is to introduce the concept of logical
> typing to the generality of programmers.  I certainly found your
> sequent typing idea to be like a revelation; I've fallen in love with
> the concept.  But my non-logical background has caused the 2D notation
> to feel a bit strange.
>
> I don't yet have the depth of experience needed to suggest alternates
> to you; I can only say how it strikes me.  But I guess what I would
> recommend is that instead of using a syntax that's oriented from logic
> to Lisp, you find something equally brilliant that aims from Lisp to
> logic.
>
> John

I think that the new notation I suggest works quite well.  Take a
look.

Mark
From: Mark Tarver
Subject: Re: Qi II preview
Date: 
Message-ID: <37f1599a-9f4f-40dc-9b00-b25a9d5460d1@i7g2000prf.googlegroups.com>
On 11 Feb, 22:34, Mark Tarver <··········@ukonline.co.uk> wrote:
> On 11 Feb, 22:18, JohnW <········@gmail.com> wrote:
>
>
>
>
>
> > On Feb 11, 1:54 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
>
> > > I think if you come from a logical background and you're used to
> > > seeing the standard notation then Qi/Qi II looks easy to grasp.  This
> > > notation has been around for 60 years.  Its older than Lisp.  Its not
> > > my darling.  Have a look athttp://en.wikipedia.org/wiki/Sequent_calculus
>
> > But is your intended audience those with a logical background?
> > Perhaps what Qi really wants is to introduce the concept of logical
> > typing to the generality of programmers.  I certainly found your
> > sequent typing idea to be like a revelation; I've fallen in love with
> > the concept.  But my non-logical background has caused the 2D notation
> > to feel a bit strange.
>
> > I don't yet have the depth of experience needed to suggest alternates
> > to you; I can only say how it strikes me.  But I guess what I would
> > recommend is that instead of using a syntax that's oriented from logic
> > to Lisp, you find something equally brilliant that aims from Lisp to
> > logic.
>
> > John
>
> I think that the new notation I suggest works quite well.  Take a
> look.
>
> Mark- Hide quoted text -
>
> - Show quoted text -

I tell you one reason why __________ might be bad for
rule closures - and that is because _ can be used by Qi
to indicate 'don't care'

[P & [~ P]]
__________
_;

is perhaps confusing.

Mark
From: danb
Subject: Re: Qi II preview
Date: 
Message-ID: <91f6310c-43ab-4ab9-aebc-8271d9967268@e23g2000prf.googlegroups.com>
On Feb 11, 11:27 am, ···········@gmail.com wrote:
> Mark, are you planning on doing anything about the datatype
> syntax. I mean, all those underscores and equal signes
> are pretty hideous and could probably be cut out somehow.

Seconded on the underscores.  Please don't make people add
LOCs.  I also agree with Ron about /., although that's not
as big a deal.

--Dan
www.prairienet.org/~dsb/
From: Mark Tarver
Subject: Re: Qi II preview - sugar and spice
Date: 
Message-ID: <0600c5f3-35d1-4fbd-8c06-21611a0636df@c23g2000hsa.googlegroups.com>
On 11 Feb, 18:02, danb <·········@gmail.com> wrote:
> On Feb 11, 11:27 am, ···········@gmail.com wrote:
>
> > Mark, are you planning on doing anything about the datatype
> > syntax. I mean, all those underscores and equal signes
> > are pretty hideous and could probably be cut out somehow.
>
> Seconded on the underscores.  Please don't make people add
> LOCs.  I also agree with Ron about /., although that's not
> as big a deal.
>
> --Danwww.prairienet.org/~dsb/

Syntax is partly a matter of taste - like how you like your coffee. In
Qi II you can change syntax by use of *sugar functions*.

OK, you don't like === and ______ and want 'iff' and 'thus' instead.
This is how you like your coffee - fair enough.  In Qi II you write

(define dans-datatype-syntax
  [datatype | Rest] -> [datatype | (subst ___ thus (subst === iff
Rest))]
  X -> X)

thats your sugar function.  OK, now you tell Qi II to use this as
sugar for what you read in placing your function at 0th (top) place.

(sugar in dans-datatype-syntax 0)

and you can write

(datatype binary

 if (element? X [0 1]) thus X : zero-or-one;

 X : zero-or-one; thus [X] : binary;

 X : zero-or-one; Y : binary; thus  [X | Y] : binary;

 X : zero-or-one, [Y | Z] : binary >> P; thus [X Y | Z] : binary >>
P;)

More seriously you can invent more useful idioms.  How about a case
statement?
You want to dispense with nested ifs and have a nice case statement
except (boo hiss) Mark Tarver forgot to build it in.  Should we
organise a march and break his window? No; stay cool.

(define cases
  [cases] -> [error "case failure~%"]
  [cases true B | _] -> B
  [cases A B | Cases] -> [if A B (cases [cases | Cases])]
  X -> X)

(sugar in cases 0)

then off you go

((/. X (cases (= X 1) X
                   (= X 2) X
                   true  0)) 3)
0 : number

See this is useful because although you *could* organise a macro in CL
to do this it would have the disadvantage that it would not
typecheck.  So you'd have to write a piece of sequent calculus to give
the type theory of 'cases'.  Here you don't have to do this because Qi
II treats 'cases' as a *syntactic fiction* - that is to say, a figure
of speech for a nested conditional.  Qi is programmable at a very deep
level.  Qi doesn't try to make a cup of coffee to everybody's taste -
thats impossible.  Instead it gives everybody a coffee machine.

Mark
From: Aatu Koskensilta
Subject: Re: Qi II preview
Date: 
Message-ID: <0jcsj.295726$jB1.259452@reader1.news.saunalahti.fi>
On 2008-02-11, in comp.lang.lisp, ···········@gmail.com wrote:
> Mark, are you planning on doing anything about the datatype syntax. I
> mean, all those underscores and equal signes are pretty hideous and
> could probably be cut out somehow.

They could, but the syntax is obvious and readable for anyone with a
type theory or proof theory background, where sequent calculus
notation is ubiquitous. Having such a background I find QI quite
interesting and am perfectly happy with its syntax. Should someone
have different preferences -- shudder! -- they can modify the syntax
to cater for their brand of perversity.

-- 
Aatu Koskensilta (················@xortec.fi)

"Wovon man nicht sprechen kann, daruber muss man schweigen"
 - Ludwig Wittgenstein, Tractatus Logico-Philosophicus
From: Marco Antoniotti
Subject: Re: Qi II preview
Date: 
Message-ID: <830dd05f-bf22-46ae-8126-55425488cd17@e23g2000prf.googlegroups.com>
On Feb 12, 8:56 am, Aatu Koskensilta <················@xortec.fi>
wrote:

>
> --
> Aatu Koskensilta (················@xortec.fi)
>
> "Wovon man nicht sprechen kann, daruber muss man schweigen"
>  - Ludwig Wittgenstein, Tractatus Logico-Philosophicus

Do we speak in 2D? (Sorry, couldn't resist :) )

Cheers
--
Marco
From: Aatu Koskensilta
Subject: Re: Qi II preview
Date: 
Message-ID: <qpesj.295775$Re2.11016@reader1.news.saunalahti.fi>
On 2008-02-12, in comp.lang.lisp, Marco Antoniotti wrote:
> Do we speak in 2D? (Sorry, couldn't resist :) )

Some people speak in 3D, e.g. those using this or that sign language.

-- 
Aatu Koskensilta (················@xortec.fi)

"Wovon man nicht sprechen kann, daruber muss man schweigen"
 - Ludwig Wittgenstein, Tractatus Logico-Philosophicus
From: Ron Garret
Subject: Re: Qi II preview
Date: 
Message-ID: <rNOSPAMon-141FB7.10072612022008@news.gha.chartermi.net>
In article <······················@reader1.news.saunalahti.fi>,
 Aatu Koskensilta <················@xortec.fi> wrote:

> On 2008-02-12, in comp.lang.lisp, Marco Antoniotti wrote:
> > Do we speak in 2D? (Sorry, couldn't resist :) )
> 
> Some people speak in 3D, e.g. those using this or that sign language.

Just for the record, this is a false analogy.  The symbols of sign 
language may be constructed in three dimensions (though they can also be 
rendered in two) but the logical structure of sign language is 
one-dimensional, just like any other natural language.

rg
From: Aatu Koskensilta
Subject: Re: Qi II preview
Date: 
Message-ID: <iklsj.295975$tG4.159027@reader1.news.saunalahti.fi>
On 2008-02-12, in comp.lang.lisp, Ron Garret wrote:
> Just for the record, this is a false analogy.  The symbols of sign 
> language may be constructed in three dimensions (though they can also be 
> rendered in two) but the logical structure of sign language is 
> one-dimensional, just like any other natural language.

I didn't know we were supposed to be serious. Of course, sign
languages are three dimensional to the same extent that sequent
calculus notation is two dimensional -- that is, on the face of it the
notation, or mode of expression, makes use of extra dimensions. But of
course there's nothing necessary to this; we could just as well
express sequent calculus rules by writing A1, A2, ..., An |- B instead
of 

 A1, A2, ..., An
 ---------------
        B

The notion of the logical structure of this or that mode of expression
being one-dimensional, two-dimensional, etc does not, on the face of
it, mean much anything. Just what is that you have in mind?

-- 
Aatu Koskensilta (················@xortec.fi)

"Wovon man nicht sprechen kann, daruber muss man schweigen"
 - Ludwig Wittgenstein, Tractatus Logico-Philosophicus
From: Ron Garret
Subject: Re: Qi II preview
Date: 
Message-ID: <rNOSPAMon-F7CB73.15271712022008@news.gha.chartermi.net>
In article <·······················@reader1.news.saunalahti.fi>,
 Aatu Koskensilta <················@xortec.fi> wrote:

> On 2008-02-12, in comp.lang.lisp, Ron Garret wrote:
> > Just for the record, this is a false analogy.  The symbols of sign 
> > language may be constructed in three dimensions (though they can also be 
> > rendered in two) but the logical structure of sign language is 
> > one-dimensional, just like any other natural language.
> 
> I didn't know we were supposed to be serious. Of course, sign
> languages are three dimensional to the same extent that sequent
> calculus notation is two dimensional -- that is, on the face of it the
> notation, or mode of expression, makes use of extra dimensions. But of
> course there's nothing necessary to this; we could just as well
> express sequent calculus rules by writing A1, A2, ..., An |- B instead
> of 
> 
>  A1, A2, ..., An
>  ---------------
>         B
> 
> The notion of the logical structure of this or that mode of expression
> being one-dimensional, two-dimensional, etc does not, on the face of
> it, mean much anything. Just what is that you have in mind?

Something like this:


A1, A2, ... An            B1, B2, ... Bn
______________            ______________
      A                         B

I'd cite Python as a language with a truly two-dimensional structure as 
well.

rg
From: Mark Tarver
Subject: Re: Qi II preview
Date: 
Message-ID: <63764dce-dae3-4099-a73e-bd3f35060b31@m34g2000hsf.googlegroups.com>
On 12 Feb, 23:27, Ron Garret <·········@flownet.com> wrote:
> In article <·······················@reader1.news.saunalahti.fi>,
>  Aatu Koskensilta <················@xortec.fi> wrote:
>
>
>
>
>
> > On 2008-02-12, in comp.lang.lisp, Ron Garret wrote:
> > > Just for the record, this is a false analogy.  The symbols of sign
> > > language may be constructed in three dimensions (though they can also be
> > > rendered in two) but the logical structure of sign language is
> > > one-dimensional, just like any other natural language.
>
> > I didn't know we were supposed to be serious. Of course, sign
> > languages are three dimensional to the same extent that sequent
> > calculus notation is two dimensional -- that is, on the face of it the
> > notation, or mode of expression, makes use of extra dimensions. But of
> > course there's nothing necessary to this; we could just as well
> > express sequent calculus rules by writing A1, A2, ..., An |- B instead
> > of
>
> >  A1, A2, ..., An
> >  ---------------
> >         B
>
> > The notion of the logical structure of this or that mode of expression
> > being one-dimensional, two-dimensional, etc does not, on the face of
> > it, mean much anything. Just what is that you have in mind?
>
> Something like this:
>
> A1, A2, ... An            B1, B2, ... Bn
> ______________            ______________
>       A                         B
>
> I'd cite Python as a language with a truly two-dimensional structure as
> well.
>
> rg- Hide quoted text -
>
> - Show quoted text -

There are two points here; but I'm not sure that I agree with either
of them.

1.  Qi is 2-D

*No*. Qi would be truly 2-D only if the Newline/Return character was
essential to writing the language.  It is not. It is purely a matter
of formatting or pretty printing.  It's no more 2-D than Lisp.

Its really a matter of style how you lay it out.  For example; here is
a rule from Qi II's native (i.e. precompiled, built in type theory)
for the type of error messages. It is laid down in 'sequent pretty
print'

commit!
if (cons? Error)
if (= (length Error) 2)
let F (head FX)
if (= F error)
let S (head (tail Error))
S : string;
________
Error : A;

You can write it as

commit! if (cons? Error) if (= (length Error) 2) let F (head FX) if (=
F error) let S (head (tail Error)) S : string; ________ Error : A;

and get it down to 1 LOC.  But its not very readable and looks like
O'Caml (well maybe not that bad ;)).  The LOC obsession can lead to
unreadable code if allowed to get out of hand.

2. The underscore notation is bad.

I think there are two reasons for arguing this; the first is that you
have to type in more characters (= more work) to make a line.  But
actually that's a bit bogus because you just keep your finger pressed
for autorepeat.

The second is that Qi is ambigous about what counts as an underline.
From recall I think Qi requires 2 or more characters to an underline.
So the language allows you to make lines of varying length.  This is
valid.

X : A >> Y : B;
__
(/. X Y) : (A --> B);

but generally the good form is to make the underline stretch as far as
the longest formula and no further.

X : A >> Y : B;
_______________
(/. X Y) : (A --> B);

Some of the 'ugly' counterexamples cited are really the result of
abandoning the  principles of good formatting.  You can make Lisp look
terrible that way too (and just about any language). The advantage of
the underline notation is that it allows you to sculpt your own
formatting and offset the line to the formulae you are using.

I windering if the problem here is just that programmers are not used
to the notation and have not learnt how to format it.

Mark
From: Ron Garret
Subject: Re: Qi II preview
Date: 
Message-ID: <rNOSPAMon-BC1F54.23200212022008@news.gha.chartermi.net>
In article 
<····································@m34g2000hsf.googlegroups.com>,
 Mark Tarver <··········@ukonline.co.uk> wrote:

> On 12 Feb, 23:27, Ron Garret <·········@flownet.com> wrote:
> > In article <·······················@reader1.news.saunalahti.fi>,
> > �Aatu Koskensilta <················@xortec.fi> wrote:
> >
> >
> >
> >
> >
> > > On 2008-02-12, in comp.lang.lisp, Ron Garret wrote:
> > > > Just for the record, this is a false analogy. �The symbols of sign
> > > > language may be constructed in three dimensions (though they can also be
> > > > rendered in two) but the logical structure of sign language is
> > > > one-dimensional, just like any other natural language.
> >
> > > I didn't know we were supposed to be serious. Of course, sign
> > > languages are three dimensional to the same extent that sequent
> > > calculus notation is two dimensional -- that is, on the face of it the
> > > notation, or mode of expression, makes use of extra dimensions. But of
> > > course there's nothing necessary to this; we could just as well
> > > express sequent calculus rules by writing A1, A2, ..., An |- B instead
> > > of
> >
> > > �A1, A2, ..., An
> > > �---------------
> > > � � � � B
> >
> > > The notion of the logical structure of this or that mode of expression
> > > being one-dimensional, two-dimensional, etc does not, on the face of
> > > it, mean much anything. Just what is that you have in mind?
> >
> > Something like this:
> >
> > A1, A2, ... An � � � � � �B1, B2, ... Bn
> > ______________ � � � � � �______________
> > � � � A � � � � � � � � � � � � B
> >
> > I'd cite Python as a language with a truly two-dimensional structure as
> > well.
> >
> > rg- Hide quoted text -
> >
> > - Show quoted text -
> 
> There are two points here; but I'm not sure that I agree with either
> of them.
> 
> 1.  Qi is 2-D
> 
> *No*.

Just to clarify, I recognize the Qi is not 2-D, I was just trying to 
point out what it might look like if it were.

> I windering if the problem here is just that programmers are not used
> to the notation and have not learnt how to format it.

That is almost certainly a factor.  Familiarity plays a role in any 
notational preference.

rg
From: Xah Lee
Subject: Re: Qi II preview
Date: 
Message-ID: <463c4608-53f0-405d-95b2-7ecd12f06244@1g2000hsl.googlegroups.com>
Dear Mark,

On your Qi II page:
 http://www.lambdassociates.org/QiII.htm

you mentioned that: « Qi now runs under four implementations of Common
Lisp and has acquired a personalised EMACS version tailored to Qi
syntax.»

does this mean there's a emacs lisp implementation?

I'd be very much interested! I went to the download page but don't see
it.

  Xah
  ···@xahlee.org
∑ http://xahlee.org/

☄
From: Mark Tarver
Subject: Re: Qi II preview
Date: 
Message-ID: <f9f46125-30d9-4160-bac3-72547f498715@b2g2000hsg.googlegroups.com>
On 13 Feb, 12:28, Xah Lee <····@xahlee.org> wrote:
> Dear Mark,
>
> On your Qi II page:
>  http://www.lambdassociates.org/QiII.htm
>
> you mentioned that: « Qi now runs under four implementations of Common
> Lisp and has acquired a personalised EMACS version tailored to Qi
> syntax.»
>
> does this mean there's a emacs lisp implementation?
>
> I'd be very much interested! I went to the download page but don't see
> it.
>
>   Xah
>   ····@xahlee.org
> ∑http://xahlee.org/
>
> ☄

Hi Xah,

Qi has been personalised to emacs but its not on my site.  I'm not an
Emacs user so I can't tell you much about it. It lives at

http://code.google.com/p/qilang/downloads/list

Mark
From: Xah Lee
Subject: Re: Qi II preview
Date: 
Message-ID: <49fe1349-8b3f-4118-a272-c0b16a24c430@v67g2000hse.googlegroups.com>
Mark Tarver <··········@ukonline.co.uk> wrote:
> Qi has been personalised to emacs but its not on my site.  I'm not an
> Emacs user so I can't tell you much about it. It lives at
>
> http://code.google.com/p/qilang/downloads/list

O no! it's just a emacs mode, not Qi in elisp.

what's with the phraseology "personalised"?

<<Qi has been personalised to emacs but its not on my site>>.

I don't recognize that this usage is UK's idiom... but i guess it is a
proper use of the term "personalization". In American English, we'd
prob just say "There is now a qi-mode for emacs".

(And you don't use emacs!? Words cannot express my incredulity! How
infidelical!)

Xah
From: Mark Tarver
Subject: Re: Qi II preview
Date: 
Message-ID: <7ca94965-f782-4ee7-80ba-fe747d197b1c@i72g2000hsd.googlegroups.com>
On 13 Feb, 15:34, Xah Lee <····@xahlee.org> wrote:
> Mark Tarver <··········@ukonline.co.uk> wrote:
> > Qi has been personalised to emacs but its not on my site.  I'm not an
> > Emacs user so I can't tell you much about it. It lives at
>
> >http://code.google.com/p/qilang/downloads/list
>
> O no! it's just a emacs mode, not Qi in elisp.
>
> what's with the phraseology "personalised"?
>
> <<Qi has been personalised to emacs but its not on my site>>.
>
> I don't recognize that this usage is UK's idiom... but i guess it is a
> proper use of the term "personalization". In American English, we'd
> prob just say "There is now a qi-mode for emacs".
>
> (And you don't use emacs!? Words cannot express my incredulity! How
> infidelical!)
>
> Xah

I should have said Emacs has been personalised to Qi.  No I don't
bother much with editors; all I expect is paren matching, pasting,
search and replace. Notepad 2 gives me all that I want.

Mark
From: Mark Tarver
Subject: your logo
Date: 
Message-ID: <eeb4a37e-fff1-46a0-898c-889ee9525ebb@c23g2000hsa.googlegroups.com>
Hi Xah,

Actually I like your logo;  could you try two small changes?

1. Join the arm of your red Chinese style lambda so that it forms one
figure.

2.  Change it to Qi II - written Qi ][.

Just to see.

;)

Mark
From: Xah Lee
Subject: Re: your logo
Date: 
Message-ID: <a94d5f26-15b1-469a-ba31-d8c33e618bee@z17g2000hsg.googlegroups.com>
Mark Tarver wrote:

> Actually I like your logo;  could you try two small changes?

Am very happy to.

> 1. Join the arm of your red Chinese style lambda so that it forms one
> figure.
>
> 2.  Change it to Qi II - written Qi ][.

See: http://xahlee.org/emacs/qi_logo.html

See if you like it.

I didn't like the idea of the name Qi II that much. Because, Qi itself
is a new lang. Strickly speaking, it is basically unknown to the
programing populace. Even among lispers, it is little known. (lispers
here means any programer who makes a living programing in any lisp
family of langs (here, we count university teachers. Lisp family here
includes CL, scheme, emacs lisp, autolisp, newlisp, arc). (as opposed
to, the people who post in comp.lang.lisp, which is i think maybe less
than 1% of professional lispers))

So, the “II” in “Qi II”, doesn't do much for the wider audience, and
possibly distractive. Of course, the name Qi II signify changes to
existing users. I'd think just consider this version as a internal
upgrade among the close-knit group of current Qi users, and keep the
officially name just Qi or Qi Lang. (i do love the name Qi Lang, it's
somewhat rhythmic, and more alludes to its oriental exotic
association)

Ok, for the Qi II logo i did... i added the II in the shape of ][ as
you asked. The II part could be tweaked a bit more. But i think it
gives some idea now. Let me know what you think.

I do think the II in the logo distract the overall beauty.

The version also has the lambda connected. On the connected lamba, i'm
not sure which i prefer. I think i slightly prefer the separate
version, because it makes Q more recognizable and the sepration of
lambda strokes seems to have some cuteness factor.

  Xah
  ···@xahlee.org
∑ http://xahlee.org/

☄
From: Mark Tarver
Subject: why Qi II?
Date: 
Message-ID: <5fc0948c-c446-4c81-b7b3-14e8f96f056a@s8g2000prg.googlegroups.com>
On 14 Feb, 04:31, Xah Lee <····@xahlee.org> wrote:
> Mark Tarver wrote:
> > Actually I like your logo;  could you try two small changes?
>
> Am very happy to.
>
> > 1. Join the arm of your red Chinese style lambda so that it forms one
> > figure.
>
> > 2.  Change it to Qi II - written Qi ][.
>
> See:http://xahlee.org/emacs/qi_logo.html
>
> See if you like it.
>
> I didn't like the idea of the name Qi II that much. Because, Qi itself
> is a new lang. Strickly speaking, it is basically unknown to the
> programing populace. Even among lispers, it is little known. (lispers
> here means any programer who makes a living programing in any lisp
> family of langs (here, we count university teachers. Lisp family here
> includes CL, scheme, emacs lisp, autolisp, newlisp, arc). (as opposed
> to, the people who post in comp.lang.lisp, which is i think maybe less
> than 1% of professional lispers))
>
> So, the “II” in “Qi II”, doesn't do much for the wider audience, and
> possibly distractive. Of course, the name Qi II signify changes to
> existing users. I'd think just consider this version as a internal
> upgrade among the close-knit group of current Qi users, and keep the
> officially name just Qi or Qi Lang. (i do love the name Qi Lang, it's
> somewhat rhythmic, and more alludes to its oriental exotic
> association)
>
> Ok, for the Qi II logo i did... i added the II in the shape of ][ as
> you asked. The II part could be tweaked a bit more. But i think it
> gives some idea now. Let me know what you think.
>
> I do think the II in the logo distract the overall beauty.
>
> The version also has the lambda connected. On the connected lamba, i'm
> not sure which i prefer. I think i slightly prefer the separate
> version, because it makes Q more recognizable and the sepration of
> lambda strokes seems to have some cuteness factor.
>
>   Xah
>   ····@xahlee.org
> ∑http://xahlee.org/
>
> ☄

The 'II' is not a gimmick.  For the last 2 1/2 years all releases of
Qi have followed a pattern.  Major changes to version N have produced
version N+1.  Minor changes to version N.M have produced N.M+1.

But *all prior versions have kept to the same text*.  That has changed
because the text has itself been changed and much improved with the
addition of rule closures. It simplies so much of what I was trying to
do that Qi II is actually shorter code wise than Qi I but more
powerful. That plus the other changes merits a new series. So its Qi
II, which I much prefer to Qi++.

Now I need to get on with it.

nuff said

Mark