Hi!
I hope this is not too off-topic..
Well, here I go. I have a casual interest in all languages of the lisp
family because the syntax is so "agnostic" and customizable. I've
learnt of some lisp-like systems of knowledge representation, such as
CycL and SUO-KIF. The underlying logical theory seems quite solid, but
I haven't seen much effort to reduce the number of parens up to the
point where one could dream of a "speakable" version of those
languages. I was wondering whether there has been any attempt to
produce a speakable logical language based on S-expressions, with the
right kind of macros so that everyday sentences can be expressed with
very few nested parens (or they spoken equivalents). Something like a
lispy version of Lojban, powered by Common Logic .
NOTE:
I hope you don't mind if I tend to use Scheme syntax in the examples.
I'm a bit more familiar with it than with the one of Common Lisp
(though I'm a clueless newbie in both, mind you!). From reading some
post I got the feeling that it's OK to discuss any kind of lisp (or
"member of the lisp family") here, not just Common Lisp. Is that
correct?
For instance, let's take the lambda function (in Scheme syntax):
(define (adder n) (lambda (x) (+ x n)))
Is it possible to have something shorter, like a macro called
"lambda-?xi" ...?
(define (adder n) (lambda-?xi + ?x1 n))
And even something like:
(define-?yi adder lambda-?xi + ?x1 ?y1)
How about hierarchical parens? Are they evil? I even thought up a
possible notation for them, bottom-up incremental.There are three kinds
of markers: "(n]", "|n]" and ")n]", where "n" is a number, and "|n]" is
a fusion of two adjacent, close-open markers. The "order of an S-exp"
is marked by the index of its outest markers. When two or more disjoint
S-exps are fused, all the "|n]" markers between them (replacing the
close-open markers) adopt the order of the highest-order S-exp, and the
order of the resulting fused S-exp is one unit above that of the
top-level "|n]" markers.
The point is that you never have to write two consecutive markers, and
at the same time, the inner marking of a S-exp is unaltered when you
nest it inside a bigger S-exp; only its outest markers are changed.
Here are some examples:
Traditional notation: a
Proposed notation: "a" OR (0] a )0]
Traditional notation: (a b)
Proposed notation: (] a b )] OR (1] a b )1]
Traditional notation: ( a ( b c ) d )
Proposed notation: (2] a (] b c )] d )2]
Traditional notation: ( a ( b c ) )
Proposed notation: (2] a (] b c )2]
Traditional notation: ( a ( b c ) (d e) )
Proposed notation: (2] a (] b c |] d e )2]
Traditional notation: ( a ( b c ) d e )
Proposed notation: (2] a (] b c )] d e )2]
Traditional notation: ( ( a ( b c ) d e ) (f g) )
Proposed notation: (3] a (] b c )] d e |2] f g )3]
Traditional notation: ( ( a ( b c ) d e ) f g )
Proposed notation: (3] a (] b c )] d e )2] f g )3]
As for namespaces, the Eulisp approach sounds interesting: a single
namespace but modules to declare local namespaces. That would be great
for declaring jargons.
For the event model, I'd like a variant of Event-token reification, but
extremely tersified by macros (something in the lines of Scheme's
"map", maybe).
Another idea would be the use of "implicit macros" that are inserted by
default in a given environment, unless stated otherwise. This would be
very useful during conversations.
So...am I trying to reinvent the wheel? Is my wheel square? :)
Regards,
-Martin
martinobal wrote:
>
> Traditional notation: ( ( a ( b c ) d e ) (f g) )
> Proposed notation: (3] a (] b c )] d e |2] f g )3]
>
> Traditional notation: ( ( a ( b c ) d e ) f g )
> Proposed notation: (3] a (] b c )] d e )2] f g )3]
Suppose that when you are editing the code that you discover that you
didn't mean c, but
rather a single element list containing c. That is, you want to change
this:
((a (b c) d e) f g)
to this:
((a (b (c)) d e) f g)
Great, a flameless reply! :)
Joe Marshall wrote:
> martinobal wrote:
> >
> > Traditional notation: ( ( a ( b c ) d e ) (f g) )
> > Proposed notation: (3] a (] b c )] d e |2] f g )3]
> >
> > Traditional notation: ( ( a ( b c ) d e ) f g )
> > Proposed notation: (3] a (] b c )] d e )2] f g )3]
>
> Suppose that when you are editing the code that you discover that you
> didn't mean c, but
> rather a single element list containing c. That is, you want to change
> this:
>
> ((a (b c) d e) f g)
>
> to this:
>
> ((a (b (c)) d e) f g)
First, please let me make it clear again TO EVERYONE: I'm NOT proposing
this as a new notation for lisp, or scheme or whatever. I LIKE the
parens, and there are lots of tricks to make them look good and not
confusing, such as good indentation, colorboxes... What I worry about
is spoken, or at least "real-time", linear communication, where you can
rarely or never edit what you said. You just restate it as you like it.
Terseness in paramount in this context, and you have no indentation or
colors to help you. I'm NOT trying to teach you what lisp or scheme
should be like or look like! I'm asking about something RELATED to
Lisp-scheme but never tried, AFAIK: a *speakable* logical language
based on a lisp-like syntax and macro system, with principles of Common
Logic under the hood. Using lots of nested parens for this is not an
option, just think of how it would sound and how cumbersome to use it
would be in real-time conversation. Fortunately, these languages have a
powerful macro system that I think can solve the problem.
In other words, I'm humblly asking for help and guidance from a bunch
of lisp-scheme gurus to get some hints on whether this is possible at
all.
Now let's adress your question. The corrected version would be either
the quick-and-dirty but unambiguous and minimally disruptive:
(3] a (] b (]c)] )] d e )2] f g )3]
Or the "more correct" (canonical), but more disruptive:
(4] a (2] b (]c )2] d e )3] f g )4]
If you were doing this in an IDE, the logical thing to do is try the
quick and dirty sollution and then let the IDE turn it into the more
elegant one.
kind regards,
-Martin
martinobal wrote:
> Great, a flameless reply! :)
Sorry, I did not actually read what you had suggested and so did not
realize it was purely for speaking. I went off half-cocked and for that
I apologize.
>
>
> Joe Marshall wrote:
>
>>martinobal wrote:
>>
>>>Traditional notation: ( ( a ( b c ) d e ) (f g) )
>>>Proposed notation: (3] a (] b c )] d e |2] f g )3]
>>>
>>>Traditional notation: ( ( a ( b c ) d e ) f g )
>>>Proposed notation: (3] a (] b c )] d e )2] f g )3]
OK, but this is speakable? Would this last one be spoken: "Left parens
three right bracket ay left parens right bracket bee cee right parens
right bracket dee eee right parens two right bracket eff gee right
parens three right bracket"? Other? Plz transcribe.
>>
>>Suppose that when you are editing the code that you discover that you
>>didn't mean c, but
>>rather a single element list containing c. That is, you want to change
>>this:
>>
>>((a (b c) d e) f g)
>>
>>to this:
>>
>>((a (b (c)) d e) f g)
>
>
> First, please let me make it clear again TO EVERYONE: I'm NOT proposing
> this as a new notation for lisp, or scheme or whatever. I LIKE the
> parens, and there are lots of tricks to make them look good and not
> confusing, such as good indentation, colorboxes... What I worry about
> is spoken, or at least "real-time", linear communication, where you can
> rarely or never edit what you said. You just restate it as you like it.
> Terseness in paramount in this context, and you have no indentation or
> colors to help you. I'm NOT trying to teach you what lisp or scheme
> should be like or look like! I'm asking about something RELATED to
> Lisp-scheme but never tried, AFAIK: a *speakable* logical language
> based on a lisp-like syntax and macro system, with principles of Common
> Logic under the hood. Using lots of nested parens for this is not an
> option, just think of how it would sound and how cumbersome to use it
> would be in real-time conversation. Fortunately, these languages have a
> powerful macro system that I think can solve the problem.
>
> In other words, I'm humblly asking for help and guidance from a bunch
> of lisp-scheme gurus to get some hints on whether this is possible at
> all.
>
> Now let's adress your question. The corrected version would be either
> the quick-and-dirty but unambiguous and minimally disruptive:
>
> (3] a (] b (]c)] )] d e )2] f g )3]
>
> Or the "more correct" (canonical), but more disruptive:
>
> (4] a (2] b (]c )2] d e )3] f g )4]
>
> If you were doing this in an IDE, the logical thing to do is try the
> quick and dirty sollution and then let the IDE turn it into the more
> elegant one.
This would be a listening/talking IDE? Lord knows my carpal tunnels
could use a rest.
kt
--
The Dalai Lama gets the same crap all the time.
-- Kenny Tilton on c.l.l when accused of immodesty
Ken Tilton wrote:
> martinobal wrote:
> > Great, a flameless reply! :)
>
> Sorry, I did not actually read what you had suggested and so did not
> realize it was purely for speaking. I went off half-cocked and for that
> I apologize.
No offence.. I should also aplogize for not explaining my intentions
more clearly. I was afraid my post would become too off-topic. Let's
start anew: I'm a student of Industrial Engineering in Spain. I should
have finished a while ago, but I'm a lazy pig and also tend to have
some geeky hobbies that take up valuable time an mental resources. I've
had to learn some programming languages for university, such as a
little Java, but so far lisp-scheme is not in that list. I've briefly
tried some implementations of lisp (clisp) and scheme (DrScheme) and
I'd like to learn more. Of course, that's something I must do, I'm not
asking for help on that (though any advice is welcome). But what
brought me here is something very different. I'm also a conlang
aficionado (of the "engelang" kind, not the "artlang" kind). I started
with Esperanto, then went on to Ido.. and finally discovered Loglan,
Lojban and other speakable logical languages. I was somewhat
disappointed, because the syntax seemed overly complicated and
idiomatic, inflexible and mnemonic-unfriendly, and it was very
difficult to see through it the logical theory behind the scenes. Then
I discovered CycL and it was a much better learning experience. IIRC,
I got interested in lisp because CycL was said to have a lisp-like
syntax. Then came SUO-KIF, Common Logic, SUMO..Well, I believe that
with a minimal vocabulary and a good word-composition method (I've been
working on the latter), a lisp-like syntax with the right macros, and
the Common Logic theory behind, one heck of a good speakable logical
language could be built. So I didn't mean speakable in controlled
English, but speakable as a constucted language with its own set of
words, phonotactics and morphological rules. Now THIS is offtopic, but
I was trying to achieve a common ground of "speakable in controlled
English" that other people here might find useful. There are advantages
to building a new language from the ground up around a new concept
(such as ease of parsing, and terseness, especially for compounds), but
I'm OK if others prefer to imagine some form of controlled natural
language.
> > Joe Marshall wrote:
> >
> >>martinobal wrote:
> >>
> >>>Traditional notation: ( ( a ( b c ) d e ) (f g) )
> >>>Proposed notation: (3] a (] b c )] d e |2] f g )3]
> >>>
> >>>Traditional notation: ( ( a ( b c ) d e ) f g )
> >>>Proposed notation: (3] a (] b c )] d e )2] f g )3]
>
> OK, but this is speakable? Would this last one be spoken: "Left parens
> three right bracket ay left parens right bracket bee cee right parens
> right bracket dee eee right parens two right bracket eff gee right
> parens three right bracket"? Other? Plz transcribe.
As I said, a controlled English is not exactly what I have in mind, but
anyway, I'd suggest something like:
"left par three ay left par one bee cee right par one dee ee right par
two eff gee right par three"
There many other possible forms. You should only care that the
indicator number of the parens is not confused with an argument that
happens to be a number.
> > If you were doing this in an IDE, the logical thing to do is try the
> > quick and dirty sollution and then let the IDE turn it into the more
> > elegant one.
>
> This would be a listening/talking IDE? Lord knows my carpal tunnels
> could use a rest.
>
Well, I hadn't thought of it that way but... why not! It would be much
easier with parser-friendly language. Actually it would be easier to
tell the IDE where you want the cursor with labelled parens, so maybe
there's a real-life use for this pipe dream of mine :D
-Martin
Joe Marshall wrote:
> martinobal wrote:
>
>>Traditional notation: ( ( a ( b c ) d e ) (f g) )
>>Proposed notation: (3] a (] b c )] d e |2] f g )3]
>>
>>Traditional notation: ( ( a ( b c ) d e ) f g )
>>Proposed notation: (3] a (] b c )] d e )2] f g )3]
>
>
> Suppose that when you are editing the code that you discover that you
> didn't mean c, but
> rather a single element list containing c. That is, you want to change
> this:
>
> ((a (b c) d e) f g)
>
> to this:
>
> ((a (b (c)) d e) f g)
>
I missed it, too. It's speakable, so unless there is a speakable splice
it would be:
"Sorry, I that should be.." then say it again correctly.
This is starting to make sense.
kt
--
The Dalai Lama gets the same crap all the time.
-- Kenny Tilton on c.l.l when accused of immodesty
martinobal wrote:
> Hi!
>
> I hope this is not too off-topic..
> Well, here I go. I have a casual interest in all languages of the lisp
> family because the syntax is so "agnostic" and customizable. I've
> learnt of some lisp-like systems of knowledge representation, such as
> CycL and SUO-KIF. The underlying logical theory seems quite solid, but
> I haven't seen much effort to reduce the number of parens up to the
> point where one could dream of a "speakable" version of those
> languages. I was wondering whether there has been any attempt to
> produce a speakable logical language based on S-expressions, with the
> right kind of macros so that everyday sentences can be expressed with
> very few nested parens (or they spoken equivalents). Something like a
> lispy version of Lojban, powered by Common Logic .
>
>
> NOTE:
> I hope you don't mind if I tend to use Scheme syntax in the examples.
> I'm a bit more familiar with it than with the one of Common Lisp
> (though I'm a clueless newbie in both, mind you!). From reading some
> post I got the feeling that it's OK to discuss any kind of lisp (or
> "member of the lisp family") here, not just Common Lisp. Is that
> correct?
>
>
> For instance, let's take the lambda function (in Scheme syntax):
> (define (adder n) (lambda (x) (+ x n)))
>
>
> Is it possible to have something shorter, like a macro called
> "lambda-?xi" ...?
>
> (define (adder n) (lambda-?xi + ?x1 n))
>
> And even something like:
>
> (define-?yi adder lambda-?xi + ?x1 ?y1)
>
> How about hierarchical parens? Are they evil? I even thought up a
> possible notation for them, bottom-up incremental.There are three kinds
> of markers: "(n]", "|n]" and ")n]", where "n" is a number, and "|n]" is
> a fusion of two adjacent, close-open markers. The "order of an S-exp"
> is marked by the index of its outest markers. When two or more disjoint
> S-exps are fused, all the "|n]" markers between them (replacing the
> close-open markers) adopt the order of the highest-order S-exp, and the
> order of the resulting fused S-exp is one unit above that of the
> top-level "|n]" markers.
>
> The point is that you never have to write two consecutive markers, and
> at the same time, the inner marking of a S-exp is unaltered when you
> nest it inside a bigger S-exp; only its outest markers are changed.
> Here are some examples:
>
> Traditional notation: a
> Proposed notation: "a" OR (0] a )0]
>
> Traditional notation: (a b)
> Proposed notation: (] a b )] OR (1] a b )1]
>
> Traditional notation: ( a ( b c ) d )
> Proposed notation: (2] a (] b c )] d )2]
>
> Traditional notation: ( a ( b c ) )
> Proposed notation: (2] a (] b c )2]
>
> Traditional notation: ( a ( b c ) (d e) )
> Proposed notation: (2] a (] b c |] d e )2]
>
> Traditional notation: ( a ( b c ) d e )
> Proposed notation: (2] a (] b c )] d e )2]
>
> Traditional notation: ( ( a ( b c ) d e ) (f g) )
> Proposed notation: (3] a (] b c )] d e |2] f g )3]
>
> Traditional notation: ( ( a ( b c ) d e ) f g )
> Proposed notation: (3] a (] b c )] d e )2] f g )3]
>
>
> As for namespaces, the Eulisp approach sounds interesting: a single
> namespace but modules to declare local namespaces. That would be great
> for declaring jargons.
>
> For the event model, I'd like a variant of Event-token reification, but
> extremely tersified by macros (something in the lines of Scheme's
> "map", maybe).
>
> Another idea would be the use of "implicit macros" that are inserted by
> default in a given environment, unless stated otherwise. This would be
> very useful during conversations.
>
> So...am I trying to reinvent the wheel? Is my wheel square? :)
I was going to say your wheel was due last week, but then I realized it
must be because of the holidays. You can put your wheel in that big pile
over there with the others we get...
...... ALL THE F*CKING TIME!!!!!*
Sorry. Meanwhile, full marks for being the first to worry about a
language being speakable. Most of you dorks** worry about it being
readable. But I think Mother Goose will be good for all of you.
hth,ken
* 2006 Q4 was a banner quarter, Google groups be your friend.
** dork n. individual who offers to fix X on their first day using X
--
The Dalai Lama gets the same crap all the time.
-- Kenny Tilton on c.l.l when accused of immodesty
Thanks for the warm welcome! :)
Ken Tilton wrote:
.
> I was going to say your wheel was due last week, but then I realized it
> must be because of the holidays. You can put your wheel in that big pile
> over there with the others we get...
>
> ...... ALL THE F*CKING TIME!!!!!*
Great, mr. car dealer! Show me the wheels and I'll show you the $
>
> Sorry. Meanwhile, full marks for being the first to worry about a
> language being speakable. Most of you dorks** worry about it being
> readable.
Thanks, but I don't think I'm the fist one who thought a true language
should be spoken, and I'm not sure that's such a good idea. Some
experts believe human language began as face gimmicks and hand signs.
Maybe we would be better off like that, no more having to bear
strangers' gleeking and foul breath when asking directions.
>
> ** dork n. individual who offers to fix X on their first day using X
>
Well, there's a difference between trying to "fix" something and trying
to adapt it to a different use. There's nothing wrong with parens, as
long as you don't have to pronounce them all.
Thanks for the early reply,
-Martin
martinobal wrote:
> Thanks for the warm welcome! :)
Actually, this welcome has been somewhat on the cool side, as compared to
some incidents of fond memory...
You wrote:
> Thanks, but I don't think I'm the fist one who thought a true language
> should be spoken, [snip!]
Taken with the rest of your statements regarding our parentheses, I think
you are labouring under a misapprehension. The only time a parenthesis is
likely to be mentioned, is in cases where either one is missing, or
there is one
more than needed. (Technically, of course, you could have the situation
where
a programmer dictates what to write, to a secretary typing code without
understanding what he was typing; but that kind of scenario sounds so
unlikely that I would describe the notion as "ludicrous".)
As for namespaces: What's wrong with having separate namespaces for
functions
and variables ?
To repeat myself in slightly more polite language: It would behoove our
critics/reformers
to actually _know_ our tools, _before_ deciding that "X is a
clumsy/misleading/confusing
construct, and should be done away with!"...
-akr
(PS: You are welcome to use our group while learning - all newcomers who
actually want to
learn, are very welcome!)
Arne Knut Roev <······@runbox.com> writes:
> martinobal wrote:
>> Thanks for the warm welcome! :)
>
> Actually, this welcome has been somewhat on the cool side, as compared to
> some incidents of fond memory...
>
> You wrote:
>> Thanks, but I don't think I'm the fist one who thought a true language
>> should be spoken, [snip!]
>
> Taken with the rest of your statements regarding our parentheses, I think
> you are labouring under a misapprehension. The only time a parenthesis is
> likely to be mentioned, is in cases where either one is missing, or
> there is one
> more than needed. (Technically, of course, you could have the
> situation where
> a programmer dictates what to write, to a secretary typing code without
> understanding what he was typing; but that kind of scenario sounds so
> unlikely that I would describe the notion as "ludicrous".)
Indeed. I've got a prototype where you type in emacs
defun fact n) if zerop n 1 * n fact 1- n)
and it inserts:
(defun fact (n)
(if (zerop n)
1
(* n (fact (1- n)))))
Now some parentheses must be typed, because we have variable arity
operators, AND because this prototype doesn't know the number of
arguments needed by non CL operators. The later can be solved hooking
the editor with a CL implementation, like slime does, and querying the
lisp implementation for the needed meta data.
The number of problematic variable arity in CL is actually limited
(mostly &optional and &rest arguments). &key arguments can be handled
automatically in the case where the key is a literal keyword (but not
in general).
Anyways, in general we only need to close a small number of lists to
indicate explicitely the number of arguments we want, for variable
arity operators, and that's all the parentheses we need to "dictate"
when we read out a lisp program to a lisp programmer.
defun fact n close if zerop n 1 * n fact 1- n close-all
or:
defun fact n close if = 0 n close 1 * n fact 1- n close-all
if we use a variable arity operator such as = instead of zerop.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You can tell the Lisp programmers. They have pockets full of punch
cards with close parentheses on them." --> http://tinyurl.com/8ubpf
Hi, Pascal
Pascal Bourguignon wrote:
> Indeed. I've got a prototype where you type in emacs
>
> defun fact n) if zerop n 1 * n fact 1- n)
>
> and it inserts:
>
> (defun fact (n)
> (if (zerop n)
> 1
> (* n (fact (1- n)))))
[snip]
>
> Anyways, in general we only need to close a small number of lists to
> indicate explicitely the number of arguments we want, for variable
> arity operators, and that's all the parentheses we need to "dictate"
> when we read out a lisp program to a lisp programmer.
>
> defun fact n close if zerop n 1 * n fact 1- n close-all
>
> or:
>
> defun fact n close if = 0 n close 1 * n fact 1- n close-all
>
> if we use a variable arity operator such as = instead of zerop.
>
How about a macro to imitate (and extend) this behavior by using a
macro , but without fiddling with the parens? Something like:
open myMacro defun fact n end if = 0 n close 1 * n fact 1 - n end-
defun close
where "myMacro" finds the keywords "end" and "end-" (followed by the
function one wants to end) and generates the proper output.
Another possible keyword would be "endsc-" , meaning "end scope
containing-" (..the following string).
open myMacro defun fact n end if = 0 n close 1 * n fact 1 - n endsc-
quote fact n end close
An "end-all" keyword would also be useful, but I'm worried it would be
tricky when you try to nest an expression ending in "end-all" inside
another expression. You would have to remove the "end-all" first, if
it's not what you want.
How difficult would it be to implement such kind of macro?
Another step to improve terseness would be to have a "myMacro mode" ,
where you don't have to retype "myMacro" every time, since it is
applied automatically to the input S-exp.
regards,
-Martin
"martinobal" <··········@gmail.com> writes:
> open myMacro defun fact n end if = 0 n close 1 * n fact 1 - n endsc-
> quote fact n end close
You could use a reader macro:
#: defun fact n : if = 0 n : 1 * n fact 1 - n :
> How difficult would it be to implement such kind of macro?
It would be hard.
One problem is that you cannot know the arity of the operators before
you define them. You would have to introduce forward declarations.
Another problem is that the only implementation dependant operators
that would allow you to get the argument list of the operators
(function-lambda-list) is allowed to return NIL. So there is really
no implementation independant way to do it.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"A TRUE Klingon warrior does not comment his code!"
Pascal Bourguignon <···@informatimago.com> writes:
> "martinobal" <··········@gmail.com> writes:
>
>> open myMacro defun fact n end if = 0 n close 1 * n fact 1 - n endsc-
>> quote fact n end close
>
> You could use a reader macro:
>
> #: defun fact n : if = 0 n : 1 * n fact 1 - n :
>
>
>> How difficult would it be to implement such kind of macro?
>
> It would be hard.
>
> One problem is that you cannot know the arity of the operators before
> you define them. You would have to introduce forward declarations.
And even, forward declarations wouldn't be enough:
(flet ((f (x y z) (+ x y z)))
(flet ((f (x y) (f x y 1)))
(flet ((f (x) (f x 2)))
(+ (f 3) 4 5))))
If you remove the parentheses, how can you know, at read time, that
the call to the function f takes only one argument?
See also this discussion:
http://www.nhplace.com/kent/PS/Ambitious.html
but here, we're not considering run-time, but read-time.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot. don't bother saving your artefacts.
Pascal Bourguignon wrote:
> > "martinobal" <··········@gmail.com> writes:
> >
> >> open myMacro defun fact n end if = 0 n close 1 * n fact 1 - n endsc-
> >> quote fact n end close
OOps, I mistankenly wrote "close" instead of "end" after "n". I wanted
to reserve "close" for the parens:
open myMacro defun fact n end if = 0 n end 1 * n fact 1 - n endsc-
quote fact n end close
> >
> > You could use a reader macro:
> >
> > #: defun fact n : if = 0 n : 1 * n fact 1 - n :
Sounds good. So, in the extreme case, can you implement a parser for a
totally different syntax in lisp as a reader macro? Just asking. What I
need, I guess, is a thin layer macro for evaluation (with "end" "end-",
"endsc-" and little else). a reader macro to define which macros are
applied by default (without explicitly calling them), another macro to
handle anaphoric reference, and yet another for rubout. The "rubout"
feature is what looks most specific of "real time" conversation.
I would like to have a chat client that does't let you delete anything
you type, but instead it lets you refer to those things you want to
change, and replace them, as you would do in speech.
> >> How difficult would it be to implement such kind of macro?
> >
> > It would be hard.
> >
> > One problem is that you cannot know the arity of the operators before
> > you define them. You would have to introduce forward declarations.
Sorry, what does this mean? Don't you have to define a function before
you can use it anyway? Or do you mean it's more work for the reader
macro?
I've googled for forward declaration in Lisp, and found this:
http://tiny-tools.sourceforge.net/emacs-code-body.html
But I can't see the relation : /
"define foo arg-1 arg-2 ... arg-n end function-body ...end" is
unambiguous, isn't it?
>
> And even, forward declarations wouldn't be enough:
>
> (flet ((f (x y z) (+ x y z)))
> (flet ((f (x y) (f x y 1)))
> (flet ((f (x) (f x 2)))
> (+ (f 3) 4 5))))
>
> If you remove the parentheses, how can you know, at read time, that
> the call to the function f takes only one argument?
I would write:
For 1 argument:
open mymacro f x end ... close
For 2 args:
open mymacro f x y end ...close
For 3 args (no more args left):
open mymacro f x y ... close
> See also this discussion:
> http://www.nhplace.com/kent/PS/Ambitious.html
>
> but here, we're not considering run-time, but read-time.
I skimmed through that page and it seems like a way to evaluate the
code as you type it, instead of waiting until you hit enter. Is that
correct? I don't think I would need that kind of capability.
>Another problem is that the only implementation dependant operators
>that would allow you to get the argument list of the operators
>(function-lambda-list) is allowed to return NIL. So there is really
>no implementation independant way to do it.
Did you mean "the only implementation INdependant operators"? Otherwise
I don't understand this paragraph. Anyway, I don't see a big problem
here, since I would ultimately have to pick an implementation (and even
a lisp dialect, for that matter).
--Martin
"martinobal" <··········@gmail.com> writes:
> Pascal Bourguignon wrote:
>
>> > "martinobal" <··········@gmail.com> writes:
>> >
>> >> open myMacro defun fact n end if = 0 n close 1 * n fact 1 - n endsc-
>> >> quote fact n end close
>
> OOps, I mistankenly wrote "close" instead of "end" after "n". I wanted
> to reserve "close" for the parens:
>
> open myMacro defun fact n end if = 0 n end 1 * n fact 1 - n endsc-
> quote fact n end close
>
>> >
>> > You could use a reader macro:
>> >
>> > #: defun fact n : if = 0 n : 1 * n fact 1 - n :
>
> Sounds good. So, in the extreme case, can you implement a parser for a
> totally different syntax in lisp as a reader macro?
Indeed. The reader macro function has the stream, and can do whatever
it wants with it, and return 0 or 1 forms. (eg the reader macro for ;
reads till the end of line and returns 0 forms, so we skip the
comment).
> [...]
> I would like to have a chat client that does't let you delete anything
> you type, but instead it lets you refer to those things you want to
> change, and replace them, as you would do in speech.
Using readline?
>> >> How difficult would it be to implement such kind of macro?
>> >
>> > It would be hard.
>> >
>> > One problem is that you cannot know the arity of the operators before
>> > you define them. You would have to introduce forward declarations.
>
> Sorry, what does this mean? Don't you have to define a function before
> you can use it anyway? Or do you mean it's more work for the reader
> macro?
No, in lisp, you don't have to define a function before "using it".
You just need to have defined it before you actually call it. For
example, when you read the source of fact, the function fact is not
defined yet, so we cannot know that it takes only 1 argument, so the
code reading it, or even the DEFUN macro couldn't know how many
arguments to pass to the recursive call to fact itself.
The normal lisp processing goes like that:
(read)
this returns the s-exp: (DEFUN FACT (X) (IF (ZEROP X) 1 (* X (FACT (1- X)))))
Then eval is called:
(eval '(defun fact (x) (if (zerop x) 1 (* x (fact (1- x))))))
eval finds that this form is a macro call, so it calls macroexpand.
This returns a s-exp like:
(SETF (SYMBOL-VALUE 'FACT)
(FUNCTION (LAMBDA (X) (IF (ZEROP X) 1 (* X (FACT (1- X)))))))
;; (actually it might be more complex (eg keeping the source, the
;; lambda list, the documentation around, etc, but that's essentially
;; what DEFUN does.)
then eval works on it. When evaluating the lambda function, the
function FACT is still not defined, so how could we know that fact
takes only one argument, (1- x), if there wasn't the parenthesis to
tell us?
> I've googled for forward declaration in Lisp, and found this:
> http://tiny-tools.sourceforge.net/emacs-code-body.html
> But I can't see the relation : /
> "define foo arg-1 arg-2 ... arg-n end function-body ...end" is
> unambiguous, isn't it?
(defun f (x) (if (evenp x) (f (truncate x 2)) (g (1- x))))
;; Here, g is not defined, but it's used by f. How can we know how
;; many arguments g takes?
(defun g (x) (f (* 3 x)))
;; Pfff! It tooks only one. We're lucky.
;; But what if we've defined:
(defun g (a b) (+ a b))
;; Then we'd have a runtime error when we call (f 3)
>> And even, forward declarations wouldn't be enough:
>>
>> (flet ((f (x y z) (+ x y z)))
>> (flet ((f (x y) (f x y 1)))
>> (flet ((f (x) (f x 2)))
>> (+ (f 3) 4 5))))
>>
>> If you remove the parentheses, how can you know, at read time, that
>> the call to the function f takes only one argument?
>
> I would write:
> For 1 argument:
> open mymacro f x end ... close
> For 2 args:
> open mymacro f x y end ...close
> For 3 args (no more args left):
> open mymacro f x y ... close
The question is when you read: f 3 4 5
how do you know where to close the argument list of f? What is the
number of arguments f takes in that scope? How can you know that at
read-time?
>> See also this discussion:
>> http://www.nhplace.com/kent/PS/Ambitious.html
>>
>> but here, we're not considering run-time, but read-time.
>
> I skimmed through that page and it seems like a way to evaluate the
> code as you type it, instead of waiting until you hit enter. Is that
> correct? I don't think I would need that kind of capability.
Yes. You'd need it even worse. But it's simply not possible: you
just cannot execute the code you are reading, before compiling it and
before deploying it in its run-time environment.
>>Another problem is that the only implementation dependant operators
>>that would allow you to get the argument list of the operators
>>(function-lambda-list) is allowed to return NIL. So there is really
>>no implementation independant way to do it.
>
> Did you mean "the only implementation INdependant operators"?
Yes, sorry.
> Otherwise I don't understand this paragraph. Anyway, I don't see a
> big problem here, since I would ultimately have to pick an
> implementation (and even a lisp dialect, for that matter).
YM.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
Pascal Bourguignon wrote:
> Indeed. The reader macro function has the stream, and can do whatever
> it wants with it, and return 0 or 1 forms. (eg the reader macro for ;
> reads till the end of line and returns 0 forms, so we skip the
> comment).
Cool :)
>
> > [...]
> > I would like to have a chat client that does't let you delete anything
> > you type, but instead it lets you refer to those things you want to
> > change, and replace them, as you would do in speech.
>
> Using readline?
I don't know... it would have no backspace deletion or special keys, it
would just wait for an "enter" keystroke, maybe not even that, but an
"enter" keyword, and then read the input. It may let you see a preview
of the line you typed, with the corrections applied, before it actually
sends it, so that you can abort the operation, but that's about it. The
point is not to be visually comfortable, but to imitate speech as
closely as possible. Is "readline" fit for this task?
>
> No, in lisp, you don't have to define a function before "using it".
> You just need to have defined it before you actually call it. For
> example, when you read the source of fact, the function fact is not
> defined yet, so we cannot know that it takes only 1 argument, so the
> code reading it, or even the DEFUN macro couldn't know how many
> arguments to pass to the recursive call to fact itself.
Now I'm confused. You seem to say that you need to define the function
first, but then you can't define it because the DEFUN macro can't do
it. But you gave me the following piece of code:
#: defun fact n : if = 0 n : 1 * n fact 1 - n :
Which is basically what I have in mind, except that I wrote "end"
instead of ":". Wouldn't this work?
> This returns a s-exp like:
>
> (SETF (SYMBOL-VALUE 'FACT)
> (FUNCTION (LAMBDA (X) (IF (ZEROP X) 1 (* X (FACT (1- X)))))))
>
> ;; (actually it might be more complex (eg keeping the source, the
> ;; lambda list, the documentation around, etc, but that's essentially
> ;; what DEFUN does.)
>
> then eval works on it. When evaluating the lambda function, the
> function FACT is still not defined, so how could we know that fact
> takes only one argument, (1- x), if there wasn't the parenthesis to
> tell us?
Well, I guess the reader macro takes "defun fact n:" and so it knows
that fact is unary. I was temped to say that "end"/":" act as the
parens, but this is a simple example (tail recursion, right?). If FACT
weren't at the end of the definition, but in the middle, it would be
harder to parse, so I guess what I said above is necessary. Another
possibilty is to "declare" FACT (its name and number of arguments) in a
previous sentence. I'm ok with that. Yet another possibility would be
to actually insert the parens when you need to (if you want to use a
function before declaring or defining it). I mean the parens should
still be available and work as usual, that's why I chose another
keyword, such as "end" instead of ")", as a delimiter for the macro.
>
> (defun f (x) (if (evenp x) (f (truncate x 2)) (g (1- x))))
>
> ;; Here, g is not defined, but it's used by f. How can we know how
> ;; many arguments g takes?
Same here. Just define g or at least declare it before using it for
defining f. That pretty much what we do in speech. Before using a new
concept, we usually give, at least, a sketch of what it means. Or just
use the parens("open" and "close" keywords).
> > I would write:
> > For 1 argument:
> > open mymacro f x end ... close
> > For 2 args:
> > open mymacro f x y end ...close
> > For 3 args (no more args left):
> > open mymacro f x y ... close
>
> The question is when you read: f 3 4 5
> how do you know where to close the argument list of f? What is the
> number of arguments f takes in that scope? How can you know that at
> read-time?
I'm assuming that f is already defined, so the reader macro knows it
has (at most) three arguments, so it accepts whatever arguments come
after it until it finds an "end" or until the 3 args are completed.
Notice I say whatever arguments, not whatever atoms. The parsing,it
seems, has to begin with the unary functions followed by atoms, to
create conses possibly used as arguments for other unary functions .
Then, binary functions followed by atoms and/or these first-level
conses, an so on... In short, (bracket-free) Polish notation whenever
possible, the "end" delimiter for variadic functions when the number of
args they are taking is lower than their maximum, and parens as an
option (for postponed declaration or just to add some redundancy).
> > I skimmed through that page and it seems like a way to evaluate the
> > code as you type it, instead of waiting until you hit enter. Is that
> > correct? I don't think I would need that kind of capability.
>
> Yes. You'd need it even worse. But it's simply not possible: you
> just cannot execute the code you are reading, before compiling it and
> before deploying it in its run-time environment.
I don't want to do that. As I said, what I want is *less* interactive
than the usual IDE, not more. In fact I don't want and IDE, just a way
to "talk" (by keyword) to an inference engine in real time, as a first
step towards actually *speaking* to it. If I have to input a
definition/declaration in the previous sentence (so it gets compiled
and all) before I use it, that's ok.
> > Otherwise I don't understand this paragraph. Anyway, I don't see a
> > big problem here, since I would ultimately have to pick an
> > implementation (and even a lisp dialect, for that matter).
Here I said something silly. I want a *language*, not just an
implementation. It should be usable for human communication, even in
the absence of computers. But again, I think you are referring to
features I wouldn't need.
Regards,
-Martin
"martinobal" <··········@gmail.com> writes:
>> > I would like to have a chat client that does't let you delete anything
>> > you type, but instead it lets you refer to those things you want to
>> > change, and replace them, as you would do in speech.
>>
>> Using readline?
>
> I don't know... it would have no backspace deletion or special keys, it
> would just wait for an "enter" keystroke, maybe not even that, but an
> "enter" keyword, and then read the input. It may let you see a preview
> of the line you typed, with the corrections applied, before it actually
> sends it, so that you can abort the operation, but that's about it. The
> point is not to be visually comfortable, but to imitate speech as
> closely as possible. Is "readline" fit for this task?
Well, this is actually how emacs works. So indeed, readline.
Emacs just reads your input keys, and you see a preview of the line
you type, with the corrections applied. You can send it (C-x s) to
the file system. You can abort the editing (C-x k). Indeed, emacs is
not visually comfortable (compared to the glossness of MS-Word), but
it's input imitate speech closely.
For example, when I typed: compared to the glithness (I thought oops,
that's not a word, and I said:
"oops, I mean" (M-DEL) glossness of MS-Word
Ok, so we already have the speak part. What about the chat client?
Do you know erc? Seems to me there is already all you want, with
emacs+erc ;-)
Otherwise, serriously, it looks like what you want is more like an
"editor" than a reader. An editor here being any application that
takes some atomic input and run a command depending on each atomic
input, modifying and displaying "buffer". When you have commands to
go back and correct what's been put/edited in the buffer, you have
your speak like input, I mean, "speach", not speak ;-)
(And you can also add emacsspeak it have it read out what you have in
the buffers (and what you type I assume), and one could hook a speach
recognition hardware or software to emacs and bind some utterance to
emacs commands, like "oops, erase that word" bound to M-DEL, etc. )
>> No, in lisp, you don't have to define a function before "using it".
>> You just need to have defined it before you actually call it. For
>> example, when you read the source of fact, the function fact is not
>> defined yet, so we cannot know that it takes only 1 argument, so the
>> code reading it, or even the DEFUN macro couldn't know how many
>> arguments to pass to the recursive call to fact itself.
>
> Now I'm confused. You seem to say that you need to define the function
> first, but then you can't define it because the DEFUN macro can't do
> it.
In Lisp, you don't have to define the function first.
But if you want to read a form where you don't write the parentheses,
to build the correct parse tree, you need to know the number of
arguments to each operator. And here is the problem: You cannot know,
at read time, when you need it, the number of arguments of most
operators, because either they aren't defined yet, or because the
number of arguments to an operator can change at anytime, including at
run-time. To keep the good dynamic and meta programming properties of
lisp, the programmer must write the parentheses (must tell how many
arguments it gives to each operator).
> But you gave me the following piece of code:
>
> #: defun fact n : if = 0 n : 1 * n fact 1- n :
>
> Which is basically what I have in mind, except that I wrote "end"
> instead of ":". Wouldn't this work?
It wouldn't work, because when you have read:
#: defun fact n : if = 0 n : 1 * n fact
you'll have found here an operator named fact that is not defined yet,
so you don't know how many arguments it expects.
Another more glaring example:
#: list 1 2 f 3 4 5 6 7 8 9 0
assuming for now that you can distinguish the variable f from the
function f, and that you can guess that we want the function f here.
How many arguments do you give to f? Remember, f is not defined _yet_.
In lisp, we can write (inside another function definition):
(list 1 2 (f) 3 4 5 6 7 8 0)
(list 1 2 (f 3) 4 5 6 7 8 0)
(list 1 2 (f 3 4) 5 6 7 8 0)
(list 1 2 (f 3 4 5) 6 7 8 0)
(list 1 2 (f 3 4 5 6) 7 8 0)
(list 1 2 (f 3 4 5 6 7) 8 0)
(list 1 2 (f 3 4 5 6 7 8) 0)
(list 1 2 (f 3 4 5 6 7 8 0))
followed by:
(defun f () ...)
or:
(defun f (x) ...)
or:
(defun f (x y) ...)
or:
...
or:
(defun f (&rest any-number-of-args) ...)
So, in general, you will have to keep all the closing parenthesis, and
write either:
#: list 1 2 f : 3 4 5 6 7 8 9 0 :
#: list 1 2 f 3 : 4 5 6 7 8 9 0 :
#: list 1 2 f 3 4 : 5 6 7 8 9 0 :
...
#: list 1 2 f 3 4 5 6 7 8 9 0 : :
Remains the problem of macros (and special operators) that can expect
a tree of any depth, and quote:
#: let x y : ...
Is this (let (x y) ...)
or (let ((x y) ...) ...) ?
How do you translate:
(quote (a (b c d (f)))) ?
#: quote a b c d f : : : :
Where do you put the open parentheses?
So, most of the time you'll still need to write both parentheses...
>> This returns a s-exp like:
>>
>> (SETF (SYMBOL-VALUE 'FACT)
>> (FUNCTION (LAMBDA (X) (IF (ZEROP X) 1 (* X (FACT (1- X)))))))
>>
>> ;; (actually it might be more complex (eg keeping the source, the
>> ;; lambda list, the documentation around, etc, but that's essentially
>> ;; what DEFUN does.)
>>
>> then eval works on it. When evaluating the lambda function, the
>> function FACT is still not defined, so how could we know that fact
>> takes only one argument, (1- x), if there wasn't the parenthesis to
>> tell us?
>
> Well, I guess the reader macro takes "defun fact n:" and so it knows
> that fact is unary.
Yes, it becomes suddenly much more complex than a simple read: it must
parse and analyse what it reads. In lisp, the reader doesn't do any
syntactic analysis, because the _data_ read can be feed to macros that
can expand it to code of a form completely different.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay
Pascal Bourguignon wrote:
>
> Ok, so we already have the speak part. What about the chat client?
> Do you know erc? Seems to me there is already all you want, with
> emacs+erc ;-)
I suspected something like that must exist :). Well, it's not *exactly*
what I need, but pretty close, and a good starting point, I guess.
Thanks for the tip!
>
> Otherwise, serriously, it looks like what you want is more like an
> "editor" than a reader. An editor here being any application that
> takes some atomic input and run a command depending on each atomic
> input, modifying and displaying "buffer". When you have commands to
> go back and correct what's been put/edited in the buffer, you have
> your speak like input, I mean, "speach", not speak ;-)
I see. I guess it would be a very simplified, dumbed-down version of
Emacs. One of my concerns is that the macros that parse the atomic
input into s-expressions are fully documented and defined in the same
language you use to define ordinary functions and macros, so that they
are part of the language "dictionary", not a feature of a particular
editor. In other words, the "preview" and "apply-corrections" commands
are convenient luxuries, but even if I hit "send" without appying
corrections, the person at the other side, who gets the message
verbatim, should be able to *mentally* apply the corrections and the
parsing macros. If instead of a person it is an inference engine which
understands the language, it should be able to do likewise, regardless
of which editor or irc client was used to send the message.
So, a simple run-of-the mill irc client should be enough for
communication, except that it doesn't provide the "apply-corrections"
feature. You take this ordinary irc client, remove all the
error-correcting tricks (backspace deletion, arrow keys to move
cursor...) and then give it the error-correcting smarts that any
competent speaker of the language has, and you get pretty much what I
want. Not a super-cool editor, but a good testbed for an intended
real-time conversation language. Additional features could be
on-the-fly (approximate) translation of every word to the local
language of each participant, so it could be both a learning tool for
the spoken logical language and an interlingua for irc.
>
> (And you can also add emacsspeak it have it read out what you have in
> the buffers (and what you type I assume), and one could hook a speach
> recognition hardware or software to emacs and bind some utterance to
> emacs commands, like "oops, erase that word" bound to M-DEL, etc. )
If the speech recognition software can be configured for any language,
that'd be great :)
>
> In Lisp, you don't have to define the function first.
>
> But if you want to read a form where you don't write the parentheses,
> to build the correct parse tree, you need to know the number of
> arguments to each operator. And here is the problem: You cannot know,
> at read time, when you need it, the number of arguments of most
> operators, because either they aren't defined yet, or because the
> number of arguments to an operator can change at anytime, including at
> run-time. To keep the good dynamic and meta programming properties of
> lisp, the programmer must write the parentheses (must tell how many
> arguments it gives to each operator).
But the reader macros first parse the input to s-expressions, and only
then are the macros and functions applied.
Doesn't it work like this? the parser should know that "defun" is a
macro, that the first argument is the defined function name, and then
come the formal arguments, until it finds ":". Then it knows the number
of arguments of the defined function, and that's all it needs in order
to insert the parens where they should be each time it finds "fact".
"defun" is not read as a macro at this stage.
> Another more glaring example:
>
> #: list 1 2 f 3 4 5 6 7 8 9 0
>
> assuming for now that you can distinguish the variable f from the
> function f, and that you can guess that we want the function f here.
> How many arguments do you give to f? Remember, f is not defined _yet_.
Which is much to assume indeed. I see a little problem here. I have to
distinguish (f) (which returns NIL) from f (which returns de function
object). "f:" means "(f)", so maybe what I need is a unary function
that takes "(f)" and returns "f". I guess in Common lisp you do it with
(function f) or, abbreviated #'f. But in Scheme, maybe I would need a
keyword/symblol to indicate "zero brackets"
>
>
>
> So, in general, you will have to keep all the closing parenthesis, and
> write either:
>
> #: list 1 2 f : 3 4 5 6 7 8 9 0 :
> #: list 1 2 f 3 : 4 5 6 7 8 9 0 :
> #: list 1 2 f 3 4 : 5 6 7 8 9 0 :
> ...
> #: list 1 2 f 3 4 5 6 7 8 9 0 : :
>
That's if you didn't define f before, or if you want to give it less
than its maximum number of arguments. No problem here.
>
> Remains the problem of macros (and special operators) that can expect
> a tree of any depth, and quote:
>
>
> #: let x y : ...
>
> Is this (let (x y) ...)
> or (let ((x y) ...) ...) ?
Sorry, what is this "nested let" used for? Maybe there's a way to
define an alternative let, more amenable to bracketless Polish
notation.
After reading this:
http://www.sunsite.ualberta.ca/Documentation/Gnu/emacs-lisp-intro/html_node/emacs-lisp-intro_50.html
I think it would be:
(let (x y z) ...)--> let x y z: ...
(let ( (init x xo) z ...)--> let init x xo z : ...
Maybe I should apply this strategy in all similar situations.
Can I use a trick like this?:
let x y : ... --> (let (x y) ..)
let list x y: ... : ... : --> (let ((x y) ...) ...)
>
>
> How do you translate:
> (quote (a (b c d (f)))) ?
>
> #: quote a b c d f : : : :
>
> Where do you put the open parentheses?
How about...:
#: quote list a list b c d list f end- quote
Hmm, I suspect this may not work, but I'd like to know what the result
would be. Anyway, "quote" is rather tricky, depending on how literal
you need to be, which depends on what the quoting if for. If you want
to say *exactly* what is quoted, then I guess you have to pronounce all
the open-close parens. OTOH, if it's part of a macro difinition, and
you know the respective arities of a, b, c.., then I guess you can use
Polish notation inside the quote.
BTW, my three hierarchically marked brackets could be a last resort
when nothing else will do. At least you don't have to repeat long
streams of brackets.
>
> So, most of the time you'll still need to write both parentheses...
Well, besides the strategies I mentioned, that may be true for
programming, but in human conversation you are not defining new
concepts all the time. Most of the time you just tell people about
facts, using words they already know. I guess that the same can be
applied to an inference engine (I haven't worked with them, it's just
an impression ) ; after you have a big dictionary of words, you spend a
lot of time telling it axioms and facts.
>
> Yes, it becomes suddenly much more complex than a simple read: it must
> parse and analyse what it reads. In lisp, the reader doesn't do any
> syntactic analysis, because the _data_ read can be feed to macros that
> can expand it to code of a form completely different.
What's the name for those macros, then?
regards,
Martin
"martinobal" <··········@gmail.com> writes:
> Pascal Bourguignon wrote:
>
>>
>> Ok, so we already have the speak part. What about the chat client?
>> Do you know erc? Seems to me there is already all you want, with
>> emacs+erc ;-)
>
> I suspected something like that must exist :). Well, it's not *exactly*
> what I need, but pretty close, and a good starting point, I guess.
> Thanks for the tip!
>
>
>>
>> Otherwise, serriously, it looks like what you want is more like an
>> "editor" than a reader. An editor here being any application that
>> takes some atomic input and run a command depending on each atomic
>> input, modifying and displaying "buffer". When you have commands to
>> go back and correct what's been put/edited in the buffer, you have
>> your speak like input, I mean, "speach", not speak ;-)
>
> I see. I guess it would be a very simplified, dumbed-down version of
> Emacs. One of my concerns is that the macros that parse the atomic
> input into s-expressions are fully documented and defined in the same
> language you use to define ordinary functions and macros, so that they
> are part of the language "dictionary", not a feature of a particular
> editor. In other words, the "preview" and "apply-corrections" commands
> are convenient luxuries, but even if I hit "send" without appying
> corrections, the person at the other side, who gets the message
> verbatim, should be able to *mentally* apply the corrections and the
> parsing macros. If instead of a person it is an inference engine which
> understands the language, it should be able to do likewise, regardless
> of which editor or irc client was used to send the message.
Really, this is what you get with emacsen. (If you write in Common
Lisp, consider Hemlock or better, Climacs).
In CL, we have reader macros, normal macros, compiler macros. If you
write an emacs in CL, you can define _editor macros_. They'd be what
we call commands in GNU emacs. You press a key, and an editor macro
is executed to do whatever it wants with the key. For normal
character keys, the editor macro called is one that just inserts the
character into the buffer. But most of the other keys are bound to
editor macros (commands) that do other things.
Don't let you simple modes, such as text-mode blind you. This is a
degenerate application of emacs power. Rather try paren-mode.
Have a look at my cl-magic emacs code:
http://darcs.informatimago.com/darcs/public/emacs/pjb-cl-magic.el
The first part builds a database about CL operators (use
(compile-lambda-lists) C-x C-e to generate the
pjb-cl-magic-lambda-lists.el file).
The second part, starting with "(defstruct (ossn" is the code that
check the code typed so far, in relation to the partially typed s-exp,
to display some help string and insert the needed parentheses.
Actually, all this code hides behind a single editor macro, the
pjb-cl-magic-space command, which is invoked everytime you type a
space (in the buffer where you bind it).
So you type: car SPC
and it inserts: (CAR
and displays: "I want a LIST."
you type: mylist SPC
and it inserts: (CAR mylist)
since it knows that CAR takes only one argument.
> So, a simple run-of-the mill irc client should be enough for
> communication, except that it doesn't provide the "apply-corrections"
> feature. You take this ordinary irc client, remove all the
> error-correcting tricks (backspace deletion, arrow keys to move
> cursor...) and then give it the error-correcting smarts that any
> competent speaker of the language has, and you get pretty much what I
> want. Not a super-cool editor, but a good testbed for an intended
> real-time conversation language. Additional features could be
> on-the-fly (approximate) translation of every word to the local
> language of each participant, so it could be both a learning tool for
> the spoken logical language and an interlingua for irc.
Whether the "interpreter" of the editor commands is in the same image
(the same unix process) as the code that gets the key presses and
displays the characters, or if they're in distinct images
communicating thru a socket is rather irrelevant.
> But the reader macros first parse the input to s-expressions, and only
> then are the macros and functions applied.
> Doesn't it work like this? the parser should know that "defun" is a
> macro, that the first argument is the defined function name, and then
> come the formal arguments, until it finds ":". Then it knows the number
> of arguments of the defined function, and that's all it needs in order
> to insert the parens where they should be each time it finds "fact".
> "defun" is not read as a macro at this stage.
Yes. That's why you should consider this notion of editor macros
(emacs commands), since this program can consider all the levels of
the data. It can handle the characters stored in the buffer data
structure, and it can do partial syntactic parses, and even partial
semantic analysis, either on its own (eg reading all the source files
in the project), or communicating with another process (an "inferior
lisp", which knows about the program being edited, like slime does).
What I'm saying is that the architecture of an emacs matches well what
you want to do, so you can do it directly and rather effortlessly in
an existing emacs (GNU emacs, climacs, etc), instead of implementing a
new one from scratch.
>> Another more glaring example:
>>
>> #: list 1 2 f 3 4 5 6 7 8 9 0
>>
>> assuming for now that you can distinguish the variable f from the
>> function f, and that you can guess that we want the function f here.
>> How many arguments do you give to f? Remember, f is not defined _yet_.
>
> Which is much to assume indeed. I see a little problem here. I have to
> distinguish (f) (which returns NIL) from f (which returns de function
> object). "f:" means "(f)", so maybe what I need is a unary function
> that takes "(f)" and returns "f". I guess in Common lisp you do it with
> (function f) or, abbreviated #'f. But in Scheme, maybe I would need a
> keyword/symblol to indicate "zero brackets"
In Common Lisp, you'd have to distinguish between a variable named f
and a function named f:
(let ((f 2))
(flet ((f () 3))
(list f (f))))
#: let f 2 : : flet f nil 3 : : list f f : : : :
>> #: let x y : ...
>>
>> Is this (let (x y) ...)
>> or (let ((x y) ...) ...) ?
>
> Sorry, what is this "nested let" used for? Maybe there's a way to
> define an alternative let, more amenable to bracketless Polish
> notation.
In CL and emacs lisp, (let (x y) ...)
means create two lexical variables named x and y and bind them each to NIL.
In CL, emacs lisp and scheme, (let ((x y)) ...)
means create one lexical variable named x, and bind it to the value of
the variable named y (which should be bound in the scope of this LET
form.
> Can I use a trick like this?:
>
> let x y : ... --> (let (x y) ..)
> let list x y: ... : ... : --> (let ((x y) ...) ...)
An objection would be that this list recalls everybody of the run-time
operator LIST. You should better write it (, and use closing
parenthesis instead of : so we're back to the normal syntax.
>> How do you translate:
>> (quote (a (b c d (f)))) ?
>>
>> #: quote a b c d f : : : :
>>
>> Where do you put the open parentheses?
>
> How about...:
>
> #: quote list a list b c d list f end- quote
How about: (quote (a (b c d (f)))) ?
Isn't it simplier and more readable?
The point here is that you can do without all the parentheses of lisp,
when you remove some other feature(s) of lisp. But when you want all
the features of lisp, the best notation is the sexps using parentheses.
Other programming languages can do without parentheses, or with some
optional parentheses, because they don't have all the features of
lisp.
>> So, most of the time you'll still need to write both parentheses...
>
> Well, besides the strategies I mentioned, that may be true for
> programming, but in human conversation you are not defining new
> concepts all the time. Most of the time you just tell people about
> facts, using words they already know. I guess that the same can be
> applied to an inference engine (I haven't worked with them, it's just
> an impression ) ; after you have a big dictionary of words, you spend a
> lot of time telling it axioms and facts.
With human processors at the other end, you can skip dictating some
parentheses and even, you can read out code with bug, it doesn't
matter because there's an intelligent process that can reconstruct the
precise code.
That's probably what you're wanting to do actually: implement an
intelligent process that can rebuild an original logical notation,
from a few dictated hints.
>> Yes, it becomes suddenly much more complex than a simple read: it must
>> parse and analyse what it reads. In lisp, the reader doesn't do any
>> syntactic analysis, because the _data_ read can be feed to macros that
>> can expand it to code of a form completely different.
>
> What's the name for those macros, then?
Well, I proposed above the name "editor macros" ;-) In emacs, they're
just called "commands", that is, functions that can be bound to keys.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
Pascal Bourguignon wrote:
>
> Really, this is what you get with emacsen. (If you write in Common
> Lisp, consider Hemlock or better, Climacs).
Emacs reimplemented in Common Lisp, that's interesting :) There's a
link to CLIM-desktop, which also sounds good.
> Have a look at my cl-magic emacs code:
> http://darcs.informatimago.com/darcs/public/emacs/pjb-cl-magic.el
Impressive! BTW, what's a synthesizer editor?
> since it knows that CAR takes only one argument.
I'm getting more and more convinced that what I need, for a spoken
prefix logical language, is a lisp-1 (because it fits better with KIF
and IKL) dialect where functions of finite arity have a fixed arity, so
that I can use Polish Notation for most things.
Here's something that I thought up: There would be a function, let's
call it "function" that takes a function as argument and returns the
function object (the lambda form). There would be a "v-arity" function
with arity 2, whose arguments are a number "n" and a function name, and
it returns another function with the same name but fewer ("n")
arguments. Two functions with the same name but different arity would
be different functions, but the shorter forms would be curryfied
versions of the full function. The V-arity may be inconvenient to use,
so there is a "begin" and "end" keywords, and the editor macro builds
the V-arity function from them.
For instance let's say f has arity 3: (f x y z)
f x y z === (f x y z)
begin f x y end === ( (v-arity 2 f ) x y) === (f x y)
function f: === (function f) === (lambda (x y z)(f x y z))
function begin f x1 end === (function ((v-arity 1 f) x1 )) ===
(function (f x1)) === (lambda (y z)(f x1 y z))
> > Additional features could be
> > on-the-fly (approximate) translation of every word to the local
> > language of each participant, so it could be both a learning tool for
> > the spoken logical language and an interlingua for irc.
>
> Whether the "interpreter" of the editor commands is in the same image
> (the same unix process) as the code that gets the key presses and
> displays the characters, or if they're in distinct images
> communicating thru a socket is rather irrelevant.
I don't understand what you are getting at in this paragraph... I meant
an interlingua for human communication, so that words in each language
are translate to and from this intermadiate language. I don't mean
computers need a communication protocol beyond those they have.
> What I'm saying is that the architecture of an emacs matches well what
> you want to do, so you can do it directly and rather effortlessly in
> an existing emacs (GNU emacs, climacs, etc), instead of implementing a
> new one from scratch.
OK, thanks, I'll take note. Not that I intended to reimplement Emacs,
but it's good to know. ;)
>
> In Common Lisp, you'd have to distinguish between a variable named f
> and a function named f:
>
> (let ((f 2))
> (flet ((f () 3))
> (list f (f))))
>
> #: let f 2 : : flet f nil 3 : : list f f : : : :
>
>
> In CL and emacs lisp, (let (x y) ...)
> means create two lexical variables named x and y and bind them each to NIL.
>
> In CL, emacs lisp and scheme, (let ((x y)) ...)
> means create one lexical variable named x, and bind it to the value of
> the variable named y (which should be bound in the scope of this LET
> form.
>
>
> > Can I use a trick like this?:
> >
> > let x y : ... --> (let (x y) ..)
> > let list x y: ... : ... : --> (let ((x y) ...) ...)
>
> An objection would be that this list recalls everybody of the run-time
> operator LIST. You should better write it (, and use closing
> parenthesis instead of : so we're back to the normal syntax.
Another way could be to define LET as a macro that recognises the
keywords "end" and "bind":
let x y end sum x y end ---> (let(x y)(sum x y))
let x bind y 1 z end sum x y z end (let (x (y 1) z) (sum x y z) )
There are two "end"s, because (in this system) both "let" and "sum" are
potentially infinitary functions, so they don't need the "begin"
keyword or the v-arity function.
> >
> > How about...:
> >
> > #: quote list a list b c d list f end- quote
>
> How about: (quote (a (b c d (f)))) ?
>
> Isn't it simplier and more readable?
It sure is more readable, but I wouldn't say it's more *speakable*. In
spoken language, having to repeat the same syntactic word several times
is a No-No. As I said, my primary concern is speech, and the irc client
is just an intermediate step.
>
> The point here is that you can do without all the parentheses of lisp,
> when you remove some other feature(s) of lisp. But when you want all
> the features of lisp, the best notation is the sexps using parentheses.
>
> Other programming languages can do without parentheses, or with some
> optional parentheses, because they don't have all the features of
> lisp.
But you can use lisp in Emacs, and thanks to the editor macros you
don't have to actually type all the parens, and you don't lose the
power of lisp. I like this concept, and I'm thinking of ways to
maximize it in a lisp dialect (by restricting arity and the like).
>
> With human processors at the other end, you can skip dictating some
> parentheses and even, you can read out code with bug, it doesn't
> matter because there's an intelligent process that can reconstruct the
> precise code.
>
> That's probably what you're wanting to do actually: implement an
> intelligent process that can rebuild an original logical notation,
> from a few dictated hints.
Well, in fact what I'd like to do (or to see done, anyway), as I said,
is to create a competitor of Lojban, with editor macros instead of a
YACC grammar (among many other differences, of course). So, the point
is not to have a program understand quasi-natural, buggy language, but
to make a formal, clean language as expressive and user-friendly as a
natural language (no easy task, either!)
> >
> > What's the name for those macros, then?
>
> Well, I proposed above the name "editor macros" ;-) In emacs, they're
> just called "commands", that is, functions that can be bound to keys.
So, Emacs stands for "Editor Macros", but they are not called "editor
macros" in Emacs, right? (??) :)
Regards,
-Martin
"martinobal" <··········@gmail.com> writes:
> Pascal Bourguignon wrote:
>> Have a look at my cl-magic emacs code:
>> http://darcs.informatimago.com/darcs/public/emacs/pjb-cl-magic.el
>
> Impressive! BTW, what's a synthesizer editor?
It's a structure editor, that allows you to build the syntactic tree
node by node, instead of character by character.
One can generate this kind of specific editor from the grammar, with a
Synthesize Generator.
The Synthesizer Generator Reference Manual
Thomas W. Reps & Tim Teitelbaum
Springer Verlag
ISBN 0-387-96910-1
In emacs, we just add some ad-hoc structural editing layer above the
character editor, but with could write in an emacs a routine to
generate an emacs mode from the grammar of the language to edit. This
would generate a structural editing emacs mode with commands and
keybindings, where you could insert/modify/delete only a well formed
structure, along with the corresponding displayable and parseable
text buffer.
>> since it knows that CAR takes only one argument.
>
> I'm getting more and more convinced that what I need, for a spoken
> prefix logical language, is a lisp-1 (because it fits better with KIF
> and IKL) dialect where functions of finite arity have a fixed arity, so
> that I can use Polish Notation for most things.
>
> Here's something that I thought up: There would be a function, let's
> call it "function" that takes a function as argument and returns the
> function object (the lambda form). There would be a "v-arity" function
> with arity 2, whose arguments are a number "n" and a function name, and
> it returns another function with the same name but fewer ("n")
> arguments. Two functions with the same name but different arity would
> be different functions, but the shorter forms would be curryfied
> versions of the full function. The V-arity may be inconvenient to use,
> so there is a "begin" and "end" keywords, and the editor macro builds
> the V-arity function from them.
>
> For instance let's say f has arity 3: (f x y z)
>
>
> f x y z === (f x y z)
>
> begin f x y end === ( (v-arity 2 f ) x y) === (f x y)
>
> function f: === (function f) === (lambda (x y z)(f x y z))
>
> function begin f x1 end === (function ((v-arity 1 f) x1 )) ===
> (function (f x1)) === (lambda (y z)(f x1 y z))
Indeed, in spoken language it's a trick that can be used to avoid
ambiguities. You say: "call the function f with two arguments x and
y." for (f x y).
> Another way could be to define LET as a macro that recognises the
> keywords "end" and "bind":
>
> let x y end sum x y end ---> (let(x y)(sum x y))
>
> let x bind y 1 z end sum x y z end (let (x (y 1) z) (sum x y z) )
>
> There are two "end"s, because (in this system) both "let" and "sum" are
> potentially infinitary functions, so they don't need the "begin"
> keyword or the v-arity function.
That's not too bad a solution.
Just try to translate:
(let (x bind y z)
(setf x 0 y 1 z 2 bind (+ x y z)))
;-)
When speaking code, we often have to use three levels. code and data
(s-exp and quoted s-exp), and meta code:
The next form a LET which define the variables x y and z and binds y
to 1, whose body is a call to setf with two assignments, to x the
expression 42, to z the call to the function f with two arguments, y
and x.
(let (x (y 1) z) (setf x 42 z (f y x)))
Now, in the spoken sentence, there are two tricks to distinguish the
meta code from the code. One is that most variable or operator names
are not usual nouns, so they stand out by themselves. LET is a
verb. So when we say "a LET", we hear the two levels. X and Y aren't
usual names either, it's implicit they're variable names. The other
trick, is that we prefix the name with the "function": variable x,
operator setf, function f.
What I'm coming at here is that we add a lot of redundancy when we
want to speak out code fluently. We actually give a description of
the code that only a programmer knowing the details of the syntax of
the programming language can use to rewrite the original source code.
To anybody that is not a programmer in the same language, you'd have
to spell out each character...
If you try to remove this redundancy you get when you speak the meta
program, you get difficulties such as above.
let x bind y z end ...
is it: (let (x bind y z) ...) or (let (x (y z) ...) ?
You can only know after having parsed the whole sentence, and I'm not
sure you can remove all ambiguity even with a whole parse. Human
brains are not so good at that.
>> > How about...:
>> >
>> > #: quote list a list b c d list f end- quote
>>
>> How about: (quote (a (b c d (f)))) ?
>>
>> Isn't it simplier and more readable?
>
> It sure is more readable, but I wouldn't say it's more *speakable*. In
> spoken language, having to repeat the same syntactic word several times
> is a No-No. As I said, my primary concern is speech, and the irc client
> is just an intermediate step.
Yes, but the less ambiguous way to speak out avoiding repeatitions is
to tell a meta program: give a description of the code, not the code
itself.
"I've got a quote operator with one argument which is a list of two
elements, first is the symbol a, then a list of four elements: three
symbols, b, list, and d, and one list of one element, the symbol f."
I've said:
(list 'quote (list 'a (list 'b 'list 'd (list 'f))))
the listener must execute it to get:
(QUOTE (A (B LIST D (F))))
Fundamentally, there is no difference between speach and code (or
data), that's why when you want to speak code, you have these
difficulties.
There is a difference between (apples and tables), and (speach and
code). When you speak about apples and tables, there's no problem,
because the model is external. "The apple is no the table."
But when you speak about code, the model is potentially (and often)
self referential.
> Well, in fact what I'd like to do (or to see done, anyway), as I said,
> is to create a competitor of Lojban, with editor macros instead of a
> YACC grammar (among many other differences, of course). So, the point
> is not to have a program understand quasi-natural, buggy language, but
> to make a formal, clean language as expressive and user-friendly as a
> natural language (no easy task, either!)
You could try to use different prefixes for the different level of speach.
e-variable A speach word.
o-variable A code word.
a-variable A data word.
"e-I e-have e-got o-quote e-with e-one e-argument e-which e-is e-a
e-list e-of e-two e-elements, e-first e-is o-a, e-then e-a e-list
e-of e-four e-elements: o-b, o-list, e-and o-d, e-and e-one e-list
e-of e-one e-element, o-f."
"a-the a-apple a-is a-on a-the a-table."
(setf apple 'apple)
"e-a o-setf e-form e-with e-one e-assignment o-apple e-becomes a-apple"
That could be a starting point...
>> > What's the name for those macros, then?
>>
>> Well, I proposed above the name "editor macros" ;-) In emacs, they're
>> just called "commands", that is, functions that can be bound to keys.
>
> So, Emacs stands for "Editor Macros", but they are not called "editor
> macros" in Emacs, right? (??) :)
Funny! emacs was a set of macros for the TECO editor. But now that
it's an independant program, you'd write editor macros in editor
macros :-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
CAUTION: The mass of this product contains the energy equivalent of
85 million tons of TNT per net ounce of weight.
Pascal Bourguignon wrote:
> > Impressive! BTW, what's a synthesizer editor?
>
> It's a structure editor, that allows you to build the syntactic tree
> node by node, instead of character by character.
Hmm, I see. Looks great for an IDE. If this concept were translated to
a language it would mean that you can never say something syntactically
wrong in this language, by definition. The meaning of the sentence
would be what it was before the failed attempts to edit it. He, He,
that sounds nice, but.. I'm thinking that all these editor and
synthesizer macros can only be a good starting point for a spoken
language if they are strictly non-interactive. That's not usually the
case, you have lots of previews of what the sentence will be like. The
problem with this is that when you have lots of feedback, repetitive
actions are much more user-friendly. For instance, you delete one char,
see it deleted, repeat until you delete everything you want. This works
for a text editor, but in speech you don't have this kind of feedback,
so it's not a good deletion method for speech. As I said, one preview
before sending is ok; more than that would be useless as a model for
spoken interchange.
> > Another way could be to define LET as a macro that recognises the
> > keywords "end" and "bind":
> >
> > let x y end sum x y end ---> (let(x y)(sum x y))
> >
> > let x bind y 1 z end sum x y z end (let (x (y 1) z) (sum x y z) )
> >
> > There are two "end"s, because (in this system) both "let" and "sum" are
> > potentially infinitary functions, so they don't need the "begin"
> > keyword or the v-arity function.
>
> That's not too bad a solution.
> Just try to translate:
>
> (let (x bind y z)
> (setf x 0 y 1 z 2 bind (+ x y z)))
>
> ;-)
You are an evil man ;)
So, I would have to quote the "bind" variable.
let x quote bind end y z end setf x 0 y 1 z 2 quote bind end plus x y z
end- let
If you intend to bring about cases such as a variable called "quote" or
a variable called "end" I'll just use here-strings, like in scsh :P
>
> Fundamentally, there is no difference between speach and code (or
> data), that's why when you want to speak code, you have these
> difficulties.
As I see it, it's just a particular case of name clashes when you are
speaking in jargon. A Physicist or an Engineer have the same problem
when they talk about "work" and other technical concepts that borrow
words from everyday speech. I was not exactly focused on lisp as a
jargon, but on lisp as a model for the syntax of a general purpose
logical language. But indeed, jargons, including lisp, should be easy
to use in this language. See below.
>
> You could try to use different prefixes for the different level of speach.
>
> e-variable A speach word.
> o-variable A code word.
> a-variable A data word.
>
> "e-I e-have e-got o-quote e-with e-one e-argument e-which e-is e-a
> e-list e-of e-two e-elements, e-first e-is o-a, e-then e-a e-list
> e-of e-four e-elements: o-b, o-list, e-and o-d, e-and e-one e-list
> e-of e-one e-element, o-f."
>
> "a-the a-apple a-is a-on a-the a-table."
>
> (setf apple 'apple)
> "e-a o-setf e-form e-with e-one e-assignment o-apple e-becomes a-apple"
>
> That could be a starting point...
"When in doubt, use brute force" ;)
Yes, it's a good starting point. Let's make it less verbous. Following
with the jargon analogy, let's say I only mark the jargon words.
"I have got o-quote with one argument which is a
> list of two elements, first is j-a, then a list
> of four elements: j-b, j-list, and j-d, and one list
> of one element, j-f."
>"ja-the ja-apple ja-is ja-on ja-the ja-table."
> (setf apple 'apple)
> "a j-setf form with one assignment j-apple becomes ja-apple"
> Funny! emacs was a set of macros for the TECO editor. But now that
> it's an independant program, you'd write editor macros in editor
> macros :-)
:D
-Martin
"martinobal" <··········@gmail.com> writes:
>> Just try to translate:
>>
>> (let (x bind y z)
>> (setf x 0 y 1 z 2 bind (+ x y z)))
>>
>> ;-)
>
> You are an evil man ;)
> So, I would have to quote the "bind" variable.
>
> let x quote bind end y z end setf x 0 y 1 z 2 quote bind end plus x y z
> end- let
Yes, you need to move up one meta level. You don't speak the program,
you speak the program that generates the program.
For sake of generality, you'd quote everything in the program, but the
operators of your program description language.
> If you intend to bring about cases such as a variable called "quote" or
> a variable called "end" I'll just use here-strings, like in scsh :P
No, it's ok. Just say: quote quote.
>> You could try to use different prefixes for the different level of speach.
>>
>> e-variable A speach word.
>> o-variable A code word.
>> a-variable A data word.
>>
>> "e-I e-have e-got o-quote e-with e-one e-argument e-which e-is e-a
>> e-list e-of e-two e-elements, e-first e-is o-a, e-then e-a e-list
>> e-of e-four e-elements: o-b, o-list, e-and o-d, e-and e-one e-list
>> e-of e-one e-element, o-f."
>>
>> "a-the a-apple a-is a-on a-the a-table."
>>
>> (setf apple 'apple)
>> "e-a o-setf e-form e-with e-one e-assignment o-apple e-becomes a-apple"
>>
>> That could be a starting point...
>
> "When in doubt, use brute force" ;)
> Yes, it's a good starting point. Let's make it less verbous. Following
> with the jargon analogy, let's say I only mark the jargon words.
>
> "I have got o-quote with one argument which is a
> list of two elements, first is j-a, then a list
> of four elements: j-b, j-list, and j-d, and one list
> of one element, j-f."
>"ja-the ja-apple ja-is ja-on ja-the ja-table."
>
> (setf apple 'apple)
> "a j-setf form with one assignment j-apple becomes ja-apple"
Good.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Our users will know fear and cower before our software! Ship it!
Ship it and let them flee like the dogs they are!"
martinobal wrote:
> I was wondering whether there has been any attempt to
> produce a speakable logical language based on S-expressions,
What you need is something speakable to represent the parentheses, so
that people don't just say "open paren" ... "close paren". Very little
phonetic space should be dedicated to this opening and closing so that
it is unobtrusive.
Suppose, for instance, that the sound "ee" means open list, and "oo"
means close list.
If we borrow English words to create an example, we get:
((ideas colorless green) (sleep furiously))
which renders as:
ee ee ideas colorless green oo ee sleep furiously oo oo.
In the morphology of the language, these sounds can be dedicated to
their role, such that words cannot start with them, and so the sounds
can be glued to the words to which they are adjacent without creating
an ambiguity.
A glottal stop comes between successive ee's and oo's so you can count
them. It doesn't take a big mouthful to pronounce ((((( as ee-ee-ee-ee.
There are going to be limitations as to the level of nesting that
speakers and listeners can handle without difficulty. This is just the
classic competence/performance distinction which limits the sentences
whch actually occur in human speech.
Kaz Kylheku wrote:
> martinobal wrote:
>
>>I was wondering whether there has been any attempt to
>>produce a speakable logical language based on S-expressions,
>
>
> What you need is something speakable to represent the parentheses, so
> that people don't just say "open paren" ... "close paren". Very little
> phonetic space should be dedicated to this opening and closing so that
> it is unobtrusive.
>
> Suppose, for instance, that the sound "ee" means open list, and "oo"
> means close list.
>
> If we borrow English words to create an example, we get:
>
> ((ideas colorless green) (sleep furiously))
>
> which renders as:
>
> ee ee ideas colorless green oo ee sleep furiously oo oo.
...bing bang walla walla ting tang?
http://www.lyricsdownload.com/sha-na-na-witch-doctor-lyrics.html
I was thinking Shrager might have something to offer here. Spoken
Chinese use tones to distinguish syllables otherwise proounced the same.
I myself use an octave drop and acceleration to denote parenthesis.
kt
--
The Dalai Lama gets the same crap all the time.
-- Kenny Tilton on c.l.l when accused of immodesty
> I was thinking Shrager might have something to offer here.
Me? Why me? I don't understand what the fuss is about; I just speak it
like it is: "The list of the list a b c, the list e f, and the list x y
z." or whatever. "Defun the function fact with arg n. The body is a
single cond where the first clause has test zerop n. If zerop n, return
1. The second and last clause is an else, that is, t, condition, whose
result is n times the recursive call to fact of one-minus n." Seems
perfectly speakable to me.
martinobal wrote:
> Traditional notation: ( ( a ( b c ) d e ) f g )
> Proposed notation: (3] a (] b c )] d e )2] f g )3]
I wonder why these apparent geniuses never give examples of their wisdom in
something resembling _real_ code, with symbol-names that actually make
some sense...
> I hope you don't mind if I tend to use Scheme syntax in the examples.
> I'm a bit more familiar with it than with the one of Common Lisp
> (though I'm a clueless newbie in both, mind you!).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
_First_ grok, _then_ criticize!
(Yes, I _could_ have commented on the other suggestions you had; but the
comment immediately above applies equally to them all...)
-akr
(message (Hello 'martinobal)
(you :wrote :on '(8 Jan 2007 13:16:59 -0800))
(
m> very few nested parens (or they spoken equivalents). Something like a
m> lispy version of Lojban, powered by Common Logic .
i'm afraid s-exp notation is not really speach-friendly -- all those nested
paren levels are not only hard to speak, but also hard to think of -- humans
simply will not be able to track that much context. computers understand
s-exprs well, so maybe that would be good for ..aliens?
forth postfix notation might be better for this -- it doesn't need parens at
least.
and, if you know each function's arity, you won't need parens. i think
that's what they do in Lojban. some modifiers can be used for some variable
arity.
so, i think lojban style might be optimal for spoken formal language.
although, BOA functions might be hard to understand (i never used lojban so
i don't know, but it looks not that easy), so some keyword-argument style
can be used instead
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Hi, Alex!
Alex Mizrahi wrote:
> (message (Hello 'martinobal)
> (you :wrote :on '(8 Jan 2007 13:16:59 -0800))
> (
>
> m> very few nested parens (or they spoken equivalents). Something like a
> m> lispy version of Lojban, powered by Common Logic .
>
> i'm afraid s-exp notation is not really speach-friendly -- all those nested
> paren levels are not only hard to speak, but also hard to think of -- humans
> simply will not be able to track that much context. computers understand
> s-exprs well, so maybe that would be good for ..aliens?
I'm aware of this fact, it's just that I don't think a baroque,
idiomatic syntax is the way to go for a logical language. I'd say
labelled brackets are much easier to manage, especially in written text
and careful speech, but my main hope is in the alleged power of the
lisp macros. With macros, I hope, one could adapt the syntax to the
speech context (pure logic, mathematics, natural science, everyday
events) explicitly, without complicating the basic syntax. I've never
heard of a spoken logical language with macros.. would'nt that be cool?
:) But lisp macros seem to be a hard topic, and that's the main reason
why I'm asking about them here, instead of doing it in conlanging
newsgroups.
>
> forth postfix notation might be better for this -- it doesn't need parens at
> least.
> and, if you know each function's arity, you won't need parens. i think
> that's what they do in Lojban. some modifiers can be used for some variable
> arity.
Lojban syntax, IIRC, is quite complex and poorly documented if you go
beyond the most basic constructs:
http://www.digitalkingdom.org/~rlpowell/hobbies/lojban/grammar/
http://www.digitalkingdom.org/~rlpowell/hobbies/lojban/grammar/lojban.peg.txt
The idea of Polish or Reverse-Polish notation looks more interesting,
and have been proposed to me before, but I see a few problems with it.
There are lots of useful, variable-arity functions, such as AND, OR,
XOR (or a more intuitive "PickOne") . Is it possible to write a macro
to imitate RP when desired? I can't find much information on Forth-like
languages used for knowledge representation, while lisp-like syntax is
widely used for that. I guess there must be some reson for this.
My general feeling is that RPN is great for logical languages that make
heavy use of long BOA functions, but not so good for languages which
rely on hash tables, macros, "mapping" functions and the like for
conciseness, because the latter tend to have lots of variable-arity
functions.
>
> so, i think lojban style might be optimal for spoken formal language.
> although, BOA functions might be hard to understand (i never used lojban so
> i don't know, but it looks not that easy), so some keyword-argument style
> can be used instead
What I most dislike of BOA functions is how inflexible (unextendable)
they are. Lojban vocabulary is full of different roots for slightly
different concepts, because of its treatment of thematic roles
(subject, object, instrument..) as argument slots. I prefer a different
approach, such as event-token reification, where thematic roles can be
declared as first-class constants (constants in the SUO-KIF sense).
Here's a post I did in yahoo groups about this topic, in case you are
interested. It probably contains some mistakes, but at least it gives
you a sense of what I want:
http://tech.groups.yahoo.com/group/engelang/message/158
In short, the sentence "John gave a flower to Mary yesterday"
in a Lojbanic style would be something like: "give( John, Mary, a
flower) yesterday"
While in a version of ETR I'm considering, it may be something like:
(E (?x ?y) (and ((and (acType give) (subj John) (obj Mary)
(happens-during yesterday) (theme ?y) ) ?x)
(E (?z) ( (and acType beAFlower (subj ?y) (holds-when ?x)) ?z)) ) )
Notice:
_ Variable names begin with a "?" in SUO-KIF. "E" stands for "there
exists"
_ I'm making (and (r1 a1) (r2 a2) e1) equivalent to (and (r1 a1 e1) (r2
a2 e1)) , where "r1" and "r2" are (role) relations, "a1" and "a2" are
objects, and "e1" is an event (which is also an object). I need this
kind of mapping very often, but I'm not sure of how to implement it.
Should that be in the definition of each and every logical connective?
should I add a mapping function, a macro..? Can I set the desired
behavior in an environment, so that a function or a macro is
automatically added at the head of each sentence?
Now that I think of it, programmers often customise Emacs so that the
have to type fewer parens (as described by Pascal Bourguignon on Tues,
Jan 9 2007 12:41 pm). The effect seems to be the same as having Polish
notation, without leaving lisp. Emacs is customised through elisp
macros, right? Now here's an idea for a "chatting", written but
real-time logical language, as a first step towards a spoken lispy
logical language: a mixture of a irc client (or instant messenger), a
lisp (CL, Scheme, whatever) implementation and an Emacs-like
programmable text editor, written in the same lisp dialect as the rest
(instead of Elisp) with different modes. Instead of writing a lisp
program, you write messages in the chat textbox (which would also act
as the "input side" of the REPL). Some of those messages are
customization macro definitions. Other messages are mode change
announcements (or maybe proposals, which your interlocutor may accept
or refuse). In the fundamental mode, all macros must be used
explicitly. In other modes, some macros are assumed to apply to each
message.
Now back to the syntax examples. In everyday speach, a much more
concise form is needed. Something closer to what I have in mind is the
following:
E-var and (3]pred acType give subj John obj Mary theme ?y
happens-during (1]t-int-past 1 day )2] ?x |3]beAFlower ?y
Where:
_ "pred" is a mapping function
_ E-var autocompletes declaration of all variables inside the
corresponding scope. It also eliminates the variable declaration
brackets by requiring all variables to begin with "?"
_ I'm using my version of hierarchical brackets.
_It is assumed that the "beAFlower" state holds during all the "give"
event. The longer form wold be:
---
(E (?x ?y) (and ((pred acType give subj John obj Mary happens-during
yesterday theme ?y ) ?x)
(E (?z) ( (pred acType beAFlower subj ?y holds-when ?x) ?z)) ) )
---
Another example:
"John gave a flower to the red-haired girl yesterday"
E-var pred give John obj (2]the-var and beAGirl (1]haveA_which hair
beRed )2] theme ?-e beAFlower happens-during (1]t-int-past 1 day
Notice:
_ The usual form of the "the" function should be (the (?x)(f ?x)) which
has arity two. I Could define a "the-v" macro of the form "(the-v (f
?x))" that recognises the "?" before "x" and autocompletes the rest. I
assume a regular function can't do that, right?
Instead, I defined a "the-var" macro which does the same, but without
the internal parens: "(the-var f ?x)" The problem is that this macro
has variable (unbounded) arity. Can this be done?
And then, I came up with this "pred2" macro:
pred2 give John obj beAGirl haveA_which hair beRed theme ?-e
beAFlower happens-during t-int-past 1 day
which is supposed to do the following:
_ Recognises "?-e" as the equivalent of the English "a/an", and builds
the corresponding existentially quantified sentence from the given
sentence.
_Detects "give" at the beginning, checks it is an action type and adds
"acType" before it.
_Detecs "John" in the second place, without a tematic role, and
defaults to "subj"
_Detects the "role relations": "obj" "theme", "happens-during" and uses
them to parse the rest of the sentence.
_Detects "beAGirl" after "obj". Since it's a type of action, it
defaults to "the-var and"
_Detects "haveAWhich", a relation with three arguments, of which two
must be present. Those are "hair" and "beRed"
Apologies for the long post ;)
-Martin