Hello, I've been watching some people learn lisp, and the sexp
notation seems like a big obstacle for some. I'm wondering what
people think about the pedagogy of introducing lisp from the sexp
perspective, talking about how sexps could be host to all sorts of
languages, from asm to C to lisp. Then the intro could proceed to
lisp, explaining that people somehow "felt" it was what they wanted to
program in. Then lisp could be introduced in terms of how it sensibly
evolved on a sexp substrate. Lisp arbitrarily evaluates stuff in the
sexps, and macros are there for people to reconfigure a sexp before
evaluation.
Let me handle here any errors I might have made in that last
paragraph. I think the difficulty of lisp is that there's fear that
certain decisions were deep, when they really were "arbitrary"; in
other words, it looked good to make lists so simple, and if you're
going to make a programming language on top of this data language,
lisp isn't at all half-bad. It's kind of make-believe, that meaning
can be built upon these atoms and lists.
Also, a source of confusion might be that "characters vs. program
object" concept. It could be explained that there's i/o and printed
representations, which we perceive, and the world of abstract objects.
Bird and Wadler's _Introduction to Functional Programming_ has a
poetic way of describing this, that maybe somewhere in outer space
these abstract objects just float around, but we deal with printed
reps in the interface between our minds and the machines.
BTW, peoples' learning of xml may be leveraged here. Maybe I will ask
about technical advantages of xml over sexps in another thread, to
clear away any misconceptions I have; all I can think of is a
standardized way to deal with charset issues; otherwise it's worse and
unhealthy for general needs. And even then, there may exist sexp
standards which do standardize charset issues, even if lisp-style
sexps happen not to.
Any thoughts? If I made any errors here, it's certainly better than
if I passed them off to others.
Tayssir John Gabbour wrote:
> Hello, I've been watching some people learn lisp, and the sexp
> notation seems like a big obstacle for some.
Do you mean that literally? Here on c.l.l? Because I do not recall
sexprs being a problem for those who have undertaken learning Lisp.
On the other hand, many anti-Lispniks like to point to parens and say
they are a problem, but those folks are more xenophobes than anything
else, and I guarantee you they have never programmed in Lisp.
So to me it is a non-issue. The folks who talk about parens would never
try Lisp anyway. And anyone who gets curious about Lisp just shrugs and
puts up with them until they fall in love with them.
I'm wondering what
> people think about the pedagogy of introducing lisp from the sexp
> perspective, talking about how sexps could be host to all sorts of
> languages, from asm to C to lisp. Then the intro could proceed to
> lisp, explaining that people somehow "felt" it was what they wanted to
> program in.
Right. McCarthy's plan was to switch to some other syntax (m-exprs?) but
everyone like sexprs so they stuck.
Then lisp could be introduced in terms of how it sensibly
> evolved on a sexp substrate. Lisp arbitrarily evaluates stuff in the
> sexps, and macros are there for people to reconfigure a sexp before
> evaluation.
>
> Let me handle here any errors I might have made in that last
> paragraph. I think the difficulty of lisp is that there's fear that
> certain decisions were deep, when they really were "arbitrary"; in
> other words, it looked good to make lists so simple, and if you're
> going to make a programming language on top of this data language,
> lisp isn't at all half-bad. It's kind of make-believe, that meaning
> can be built upon these atoms and lists.
>
> Also, a source of confusion might be that "characters vs. program
> object" concept. It could be explained that there's i/o and printed
> representations, which we perceive, and the world of abstract objects.
> Bird and Wadler's _Introduction to Functional Programming_ has a
> poetic way of describing this, that maybe somewhere in outer space
> these abstract objects just float around, but we deal with printed
> reps in the interface between our minds and the machines.
>
> BTW, peoples' learning of xml may be leveraged here.
Yep.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
On Sat, 13 Dec 2003 13:32:01 +0000, Kenny Tilton wrote:
> Do you mean that literally? Here on c.l.l? Because I do not recall
> sexprs being a problem for those who have undertaken learning Lisp.
Well, I'm not expressing my dislike of sexprs loudly here, because it's
too easy to yield a counterproductive flamewar.
Anyway, sexprs are not necessary to have powerful macros. What is needed
is the possibility to parse code using unknown macros into some tree,
a notation for code quasiquotation, a dual notation for code patterns for
destructuring, and a handful of functions like checking whether a code
object is an identifier or producing an identifier from a string.
Yes, a syntax which is parseable into a tree without the knowledge of
the semantics of most of its constructs tends to require more parens than
average syntaxes. But it's still possible to do that with less parens than
in Lisp.
If a syntax uses a bit more punctuation and less parentheses, in particular
if local definitions don't require putting the body they scope over in an
additional set of parens, then the indentation style which puts a closing
bracket on a separate line, indented as much as the line which introduced
the matching opening bracket (rather than at the end of the previous line),
becomes attractive.
This style doesn't work for Lisp because there are too many closing
parens, and the bottom 1/3 of a function definition would consist of
stair-shaped closing parens only. With fewer parens this style works,
and it's easy enough to match them with naked eyes, without having
to highlight them using a bracket-aware editor. This style is used by
virtually all languages except Lisp dialects.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> Anyway, sexprs are not necessary to have powerful macros.
They are necessary if you want to have a simple mapping between how the
macro manipulates the code and how the code looks. That's why people
like sexrs. You traverse the code exactly how it looks and so does the
evaluator.
1+2+3
is '+ the second and fourth symbol in that expression? Or is it the
operator of the whole expression and the operator of the second
parameter?
(+ 1 2 3)
I know intuituvely where the '+ sits in that expression. It's the first
element of it. No thinking about arbitrary conventions necessary.
> If a syntax uses a bit more punctuation and less parentheses, in particular
> if local definitions don't require putting the body they scope over in an
> additional set of parens
I've never seen a macro that does this, or maybe I misunderstand you. Or
maybe you mistake an "end of statement" marker as a non-syntactic
character.
> This style doesn't work for Lisp because there are too many closing
> parens, and the bottom 1/3 of a function definition would consist of
> stair-shaped closing parens only.
In Lisp, you just tuck away all the closing parens in a corner of the
code and let the editor and lisp reader look at them.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
On Sat, 13 Dec 2003 12:11:41 -0500, Rahul Jain wrote:
> 1+2+3
>
> is '+ the second and fourth symbol in that expression? Or is it the
> operator of the whole expression and the operator of the second
> parameter?
The latter of course. And you don't need to remember how it's represented
because you can write `(,x + ,y), and you should be able to similarly
match expressions to patterns. A bunch of caddr's and the like used for
destructuring is hard to read.
> In Lisp, you just tuck away all the closing parens in a corner of the
> code and let the editor and lisp reader look at them.
I know it's easy for the *computer* to parse Lisp.
A language should be readable for humans.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> On Sat, 13 Dec 2003 12:11:41 -0500, Rahul Jain wrote:
>
>> 1+2+3
>>
>> is '+ the second and fourth symbol in that expression? Or is it the
>> operator of the whole expression and the operator of the second
>> parameter?
>
> The latter of course.
How do you know this? It's just a stream of tokens, 1, +, 2, +, 3, to me.
> And you don't need to remember how it's represented
> because you can write `(,x + ,y), and you should be able to similarly
> match expressions to patterns.
where do the parens come from? I didn't type my code with parens, so why
am I using them to build that code? I don't see why you need the
confusion of two different syntaxes depending on what "level" of the
language you're using. Code as a data structure should simply be the
code as a literal constant. Otherwise, metaprogramming becomes a
separate realm of the language, protected by private syntaxes. When
programming and metaprogramming are on the same footing, then the
programmer can trivially become the metaprogrammer when the need arises.
> A bunch of caddr's and the like used for destructuring is hard to
> read.
No really. That's why no one does that. It's clear to me that you're yet
another person who has never learned how to use Lisp and yet "knows"
what's wrong with it. Most of my macros are written with mapcar, remove,
and destructuring-bind.
As some examples of the simplest macros, the kind that the average
programmer could really benefit from, I give these definitions from
<http://common-lisp.net/cgi-bin/viewcvs.cgi/DefDoc/src/layout/html-engine.lisp>
,---
| (defmacro with-html-block ((tag &rest attributes) &body body)
| (let ((tag-sym (gensym "TAG-")))
| `(progn
| (pprint-newline :linear *html-stream*)
| (pprint-logical-block (*html-stream* nil)
| (let ((,tag-sym ,tag))
| (open-html-tag ,tag-sym ,@attributes)
| (pprint-indent :block 2 *html-stream*)
| (pprint-newline :linear *html-stream*)
| (unwind-protect
| (progn ,@body)
| (pprint-indent :block 0 *html-stream*)
| (pprint-newline :linear *html-stream*)
| (close-html-tag ,tag-sym)))))))
|
| (defmacro with-html-inline ((tag &rest attributes) &body body)
| (let ((tag-sym (gensym "TAG-")))
| `(let ((,tag-sym ,tag))
| (open-html-tag ,tag-sym ,@attributes)
| (unwind-protect
| (progn ,@body)
| (close-html-tag ,tag-sym)))))
|
| (defmacro write-html-tag (tag-name &rest attributes)
| "Writes a bodiless html tag. Uses the XHTML <.../> syntax."
| `(unless *suppress-html-tags*
| (pprint-logical-block (*html-stream* nil :prefix "<" :suffix "/>")
| (write-string ,(string tag-name) *html-stream*)
| (write-html-attributes ,@attributes))))
`---
Look at the macro bodies and see how they are simply the result of
taking the code I wrote for a special case of the macro, quasiquoting
it, making the variable parts of it parameters (no cadr nonsense), and
unquoting to insert those parameters where they belong.
If you want to see something really complex, look at the beginning of
that file for the WRITE-HTML-ATTRIBUTES compiler macro. The cddr being
used there has nothing to do with the fact that I'm using a macro,
btw. Technically, the loop in that shold be written using do-plist
instead, which I'll fix soon. :)
>> In Lisp, you just tuck away all the closing parens in a corner of the
>> code and let the editor and lisp reader look at them.
>
> I know it's easy for the *computer* to parse Lisp.
> A language should be readable for humans.
Lisp is readable for humans if the human uses the information in the
code that matches what he can process best. I find it very difficult to
read C-syntax code beacuse all the lines taken up by the dangling parens
make it extremely difficult to quickly see what context they are
closing.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
On Sat, 13 Dec 2003 13:05:28 -0500, Rahul Jain wrote:
>> The latter of course.
>
> How do you know this?
Because it's parsed into an abstract syntax tree before macroexpansion.
How do you know that a Lisp macro receives (foo bar) as a list of two
elements and not as four tokens?
>> And you don't need to remember how it's represented
>> because you can write `(,x + ,y), and you should be able to similarly
>> match expressions to patterns.
>
> where do the parens come from?
The programmer has written them to delimit the expression to which ` applies.
I don't say that the syntax would look exactly like this, for example
it could be <<$x + $y>>, but I do say that a non-Lispy syntax would use
parens for grouping and something else for lists (square brackets probably).
And be suitable for macros. The only quotation needed is for quoting code.
List expressions have their elements evaluated and symbols are obtained by
symbol literals instead of quoting. You need to quote symbol literals but
not numeric literals or strings - it's inconsistent.
> I don't see why you need the confusion of two different syntaxes
> depending on what "level" of the language you're using.
There are no two different syntaxes. You use exactly the same syntax in
code quotations and in the main program.
Do you mean, why to use a different syntax for code and for lists of
symbols? Because code is not a list of symbols. Hygiene alone requires
that.
How do you disambiguate lists from applications? You need quoting for
lists, I don't. Why to introduce a different quotation level just because
we are making a list? Just write elements in brackets.
> Code as a data structure should simply be the code as a literal constant.
And it is. You can think of <<...>> as of making code literals, except you
need to disambiguate unquotes to specify to which nesting level they apply
(the issue is analogous to writing \ in string literals, and Lisp must
disambiguate commas in quasiquotations too, but it does it differently
than I would do that).
> Look at the macro bodies and see how they are simply the result of
> taking the code I wrote for a special case of the macro, quasiquoting
> it, making the variable parts of it parameters (no cadr nonsense), and
> unquoting to insert those parameters where they belong.
The same can be done in a syntax not based on sexprs. It doesn't matter
whether an application is represented by a list or some other datum;
it matters that you can construct it by quoting code which looks like
a real application.
Actually I would write these macros as functions, assuming my language has
a more friendly syntax for anonymous functions than #'(lambda () ...).
Please don't tell me that I can let {...} make functions in Lisp. I know
that. Somehow most Lispers prefer to make macros than higher-order
functions, and readtable extensions are unmodular anyway.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
On Sat, 13 Dec 2003 21:35:57 +0100, Marcin 'Qrczak' Kowalczyk wrote:
> The same can be done in a syntax not based on sexprs. It doesn't matter
> whether an application is represented by a list or some other datum;
> it matters that you can construct it by quoting code which looks like
> a real application.
You can but, having actually done this in other languages, I'd be less
than honest if I said it was fun. Places where problems arise are
building declarations before use, having to generate different code for
insertion in different syntactic contexts, and other seemingly miniscule
issues that turn into great big issues because of irregularity in the
language grammar and semantics. If you can design a language that
minimizes local constraints on allowed code with a fairly clean syntactic
and lexical structure, you'll probably be OK. Most languages today have
not been designed this way. If you're trying to graft a macro language
onto an existing language not designed with these issues in mind, writing
macros will probably suck.
Lisp's minimal contextualization of and regularization of syntactic and
semantic constructs makes writing macros in Lisp much easier. It makes a
big difference.
faa
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> On Sat, 13 Dec 2003 13:05:28 -0500, Rahul Jain wrote:
>
>>> The latter of course.
>>
>> How do you know this?
>
> Because it's parsed into an abstract syntax tree before macroexpansion.
And that tree looks nothing like the code.
> How do you know that a Lisp macro receives (foo bar) as a list of two
> elements and not as four tokens?
Because that's what it looks like. I know that the code is a tree of
expressions and the parens delimit the nesting of the tree.
>>> And you don't need to remember how it's represented
>>> because you can write `(,x + ,y), and you should be able to similarly
>>> match expressions to patterns.
>>
>> where do the parens come from?
>
> The programmer has written them to delimit the expression to which ` applies.
>
> I don't say that the syntax would look exactly like this, for example
> it could be <<$x + $y>>, but I do say that a non-Lispy syntax would use
> parens for grouping and something else for lists (square brackets probably).
Whatever you do, it'll look nothing like the code you're trying to
generate, as far as I can see.
> And be suitable for macros. The only quotation needed is for quoting code.
> List expressions have their elements evaluated and symbols are obtained by
> symbol literals instead of quoting. You need to quote symbol literals but
> not numeric literals or strings - it's inconsistent.
No, it's just a result of the rule that some objects are self-evaluating.
If that's the case, then not having to quote keywords, NIL, and T when
passing them as args to a "normal" function would be
inconsistent. However, we know that they are self-evaluating, so we can
quote them or not, but that's an indicator to a human reader about some
aspect of the parameter's "meaning".
>> I don't see why you need the confusion of two different syntaxes
>> depending on what "level" of the language you're using.
>
> There are no two different syntaxes. You use exactly the same syntax in
> code quotations and in the main program.
The "same" syntax which has 1+2+3 look like a stream of 5 tokens or a
3-element list with the 3rd element as another 3-element list?
> Do you mean, why to use a different syntax for code and for lists of
> symbols? Because code is not a list of symbols. Hygiene alone requires
> that.
So lisp code is somehow "unhygenic"? Does it give you a disease when you
touch it? Or just a speech impediment? :)
> How do you disambiguate lists from applications? You need quoting for
> lists, I don't. Why to introduce a different quotation level just because
> we are making a list? Just write elements in brackets.
So instead of quoting using a quote, you're quoting using a different
delimiter. I hope you realize that this is something the user can easily
do in Lisp.
>> Code as a data structure should simply be the code as a literal constant.
>
> And it is. You can think of <<...>> as of making code literals, except you
> need to disambiguate unquotes to specify to which nesting level they apply
> (the issue is analogous to writing \ in string literals, and Lisp must
> disambiguate commas in quasiquotations too, but it does it differently
> than I would do that).
Why... would you like to put commas in your symbols? (In fact, you can
do that, you just need to use \ as you would in strings.)
>> Look at the macro bodies and see how they are simply the result of
>> taking the code I wrote for a special case of the macro, quasiquoting
>> it, making the variable parts of it parameters (no cadr nonsense), and
>> unquoting to insert those parameters where they belong.
>
> The same can be done in a syntax not based on sexprs. It doesn't matter
> whether an application is represented by a list or some other datum;
> it matters that you can construct it by quoting code which looks like
> a real application.
And the point remains that no one has come up with a syntax where you
really can do that other than sexprs. And I mean 'looks like' from the
data structure point of view as well, for when you want to build more
complex macros. Being able to change to a different language while still
retaining all the relevant bits of all other languages is very
freeing. :)
> Actually I would write these macros as functions, assuming my language has
> a more friendly syntax for anonymous functions than #'(lambda () ...).
Like Smalltalk? The results are nastily slow from what I've heard, even
from ostensibly modern smalltalkers.
How would you write compiler-macros?
> Please don't tell me that I can let {...} make functions in Lisp. I know
> that. Somehow most Lispers prefer to make macros than higher-order
> functions,
Because that's the whole point. We like to extend the language. We like
to create control structures that make sense in the domain we are
programming in.
> and readtable extensions are unmodular anyway.
agreed, but they're only for a specific programmer.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
On Sun, 14 Dec 2003 21:18:20 -0500, Rahul Jain wrote:
>> Because it's parsed into an abstract syntax tree before macroexpansion.
>
> And that tree looks nothing like the code.
A tree doesn't look. It exists in memory, it's derived from the stream of
tokens or characters but it's not *the* stream. The same is true in Lisp.
There are lexical rules and grammar rules which transform the stream to
the tree.
>> I don't say that the syntax would look exactly like this, for example
>> it could be <<$x + $y>>, but I do say that a non-Lispy syntax would use
>> parens for grouping and something else for lists (square brackets probably).
>
> Whatever you do, it'll look nothing like the code you're trying to
> generate, as far as I can see.
How does the tree node for addition look like then, if not "something +
something"? In the similar way to parentheses used to build a list node
which means application (or grouping of macro arguments, or a list
constant when quoted), here + is used to build an addition node which
means addition (or building an addition expression when quoted).
The only significant difference is that there is a dozen of kinds of nodes
rather than a few, and that data which represents code is used only for
code (and not also for lists and symbols).
>> There are no two different syntaxes. You use exactly the same syntax in
>> code quotations and in the main program.
>
> The "same" syntax which has 1+2+3 look like a stream of 5 tokens or a
> 3-element list with the 3rd element as another 3-element list?
If it's just a stream of 5 tokens, then (foo bar) is just a stream of 4
tokens.
When it's parsed, it's a tree. If unquoted, it means addition; if quoted,
it means to construct a syntax object which means addition.
In Lisp when it's parsed, it's a list (or tree of lists in general).
If unquoted, it means application; if quoted, it means to construct
a list which can mean application (or other things if used in other
contexts).
>> Do you mean, why to use a different syntax for code and for lists of
>> symbols? Because code is not a list of symbols. Hygiene alone requires
>> that.
>
> So lisp code is somehow "unhygenic"? Does it give you a disease when you
> touch it? Or just a speech impediment? :)
I meant hygienic macros.
> Why... would you like to put commas in your symbols?
I meant expanding to quasiquotations and splicing expressions into it.
In Lisp I must disambiguate using ,', versus , so it's not always just
"replace the parts which change with ,expression", one must be careful
to nesting of quasiquotations. The same is true in my syntax, I would
only let $foo expand to the value of foo and let $$foo expand to $foo.
> And the point remains that no one has come up with a syntax where you
> really can do that other than sexprs.
I did, but it's not finished yet. Wait a couple of weeks / months.
> And I mean 'looks like' from the data structure point of view as well,
> for when you want to build more complex macros.
You must know functions for manipulating lists, and you can often use
quasiquotations to build lists.
In my syntax you must know functions for manipulating syntax objects,
but you generally use code quotations to build and decompose syntax
objects.
>> Actually I would write these macros as functions, assuming my language has
>> a more friendly syntax for anonymous functions than #'(lambda () ...).
>
> Like Smalltalk? The results are nastily slow from what I've heard, even
> from ostensibly modern smalltalkers.
In Smalltalk they can't be inlined because of dynamic dispatch, but in a
language similar to Lisp a global higher-order function can be inlined.
> How would you write compiler-macros?
Sorry, I don't know what they are.
> Because that's the whole point. We like to extend the language. We like
> to create control structures that make sense in the domain we are
> programming in.
I like to have a language which I don't need to constantly extend for such
simple things as passing a piece of code to a function. Macros are fine
for more complex cases.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
How do you know this? It's just a stream of tokens, 1, +, 2, +, 3, to
me.
>>>>>>>>>>>>>>>>>>
Oh come on! I've grown to like the prefix syntax myself, but nobody
who made it past grade-school mathematics would interpret "1 + 2 + 3"
as "just a stream of tokens." Algebraic notation is just too deeply
ingrained into our educational system.
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote in message news:<······························@knm.org.pl>...
> I know it's easy for the *computer* to parse Lisp.
> A language should be readable for humans.
That statement needs a context, though. Under what context is a
language readable? If you're a programmer, you're going to want the
most powerful symbolism, not one that's intended to appear like
highschool algebra.
It's like those DVD playing guis that have a knob you're supposed to
rotate with the mouse pointer to raise the volume. The metaphor works
well in the normal world, but definitely not on the computer.
Now, I do think you can target a language to people, like musical
notation or VB. But I think programmers need pride enough to say we
need our own notations made for working with computers. If we're
loyal to one that's not designed for us, we might end up like those
mathematicians loyal to Newton's calculus notation, whose asses were
handed to them by Leibnizians. (So the urban legend goes...)
BTW, Michael Scott had an interesting argument that a language that's
hard to scan also presents difficulties to humans. He used examples
from Fortran and one from Pascal (the dot-dot syntax) in _Programming
Pragmatics_. I'm not sure he's right, but it's an attractive theory.
It's really a bold statement of psychology to know what's "readable"
to humans.
Anyway, I think you have an interesting point and don't intend a
flame.
Marcin 'Qrczak' Kowalczyk wrote:
> I know it's easy for the *computer* to parse Lisp.
> A language should be readable for humans.
>
You are projecting, confusing your preferences with general rules.
I am, as far as I can tell, a human, and I find lisp almost uniquely EASY to
read and write because it has nearly no complicated syntax nor precedence
ambiguities to be resolved by my poor little brain. Once you learn the
basics, that's pretty all there is. I get really annoyed by the baroque
intricacies of most other syntaxes that try to be "clever".
> I am, as far as I can tell, a human, and I find lisp almost uniquely EASY to
> read and write because it has nearly no complicated syntax nor precedence
> ambiguities to be resolved by my poor little brain.
This makes little sense. Human beings are particularly well-adapted to
mentally parsing complicated syntax full of ambiguities. Reading
natural languages basically requires it.
Rayiner Hashem wrote:
>
> > I am, as far as I can tell, a human, and I find lisp almost uniquely EASY to
> > read and write because it has nearly no complicated syntax nor precedence
> > ambiguities to be resolved by my poor little brain.
> This makes little sense. Human beings are particularly well-adapted to
> mentally parsing complicated syntax full of ambiguities. Reading
> natural languages basically requires it.
That is because in natural language the *MEANINGS* of what we're saying
are naturally ambiguous and complicated. Computer code, ideally, is
only supposed to mean one thing. Our brains, which are adapted for
simultaneously extracting dozens or hundreds of shades of meaning and
ambiguity, read complicated syntaxes looking for possible "hooks" to
attach additional meanings and shadings to. We can't help it; it's
just the kind of animals we are. But with computer code, which naturally
has only one meaning, this is disastrous.
It is easiest for us to get the single, unambiguous meaning of
code if there are as few extra "hooks" of syntax as possible to
distract us.
Bear
> It is easiest for us to get the single, unambiguous meaning of
> code if there are as few extra "hooks" of syntax as possible to
> distract us.
I dunno about that. Humans are used to a lot of syntax being used to
*disambiguiate* meanings. For example:
The dog bit roy.
The syntax in this sentence (or is it the grammar?) disambiguates who
bits who. Now, consider something like this:
(bite the-dog roy)
Who is biting who? You only know either from convention or from the
API docs. Now, consider something like this:
the-dog bite: roy
Now, from just knowing the Smalltalk syntax, its obvious who is biting
who.
·······@mindspring.com (Rayiner Hashem) writes:
>> It is easiest for us to get the single, unambiguous meaning of
>> code if there are as few extra "hooks" of syntax as possible to
>> distract us.
> I dunno about that. Humans are used to a lot of syntax being used to
> *disambiguiate* meanings. For example:
>
> The dog bit roy.
Only in some languages.
Puer canem mordet.
Puerum canis mordet.
·······@mindspring.com (Rayiner Hashem) wrote in message news:<····························@posting.google.com>...
> > It is easiest for us to get the single, unambiguous meaning of
> > code if there are as few extra "hooks" of syntax as possible to
> > distract us.
> I dunno about that. Humans are used to a lot of syntax being used to
> *disambiguiate* meanings. For example:
>
> The dog bit roy.
>
> The syntax in this sentence (or is it the grammar?) disambiguates who
> bits who. Now, consider something like this:
>
> (bite the-dog roy)
>
> Who is biting who? You only know either from convention or from the
> API docs. Now, consider something like this:
>
> the-dog bite: roy
>
> Now, from just knowing the Smalltalk syntax, its obvious who is biting
> who.
I'd say that is an English perspective on obviousness. Here, you're
using word order and a : to disambiguate the sentence. Natural
languages additionally add extra words and word alteration to
disambiguate, avoiding strict word order.
How about (-- the-dog bite -> roy), if you really like English? An
advantage of sexprs is you can provide additional info:
(-- roy bites the-dog (:tense :past
:adverb ironically))
Presumably, you can define rules for verbs which look up "bite" in a
dictionary and add the plural form "bites" as a synonym. Maybe "bit"
could also be understood as the past tense form, allowing another way
to express the above sentence.
Can extra modifiers (tense, adjectives..) be passed with Smalltalk
syntax? I don't know this language very much and it's interesting.
Of course, IANAL (I'm not a lingust). And thanks btw, I find
criticisms of sexprs valuable.
> Of course, IANAL (I'm not a lingust). And thanks btw, I find
> criticisms of sexprs valuable.
I wasn't criticizing sexprs. Somebody earlier said:
"It is easiest for us to get the single, unambiguous meaning of
code if there are as few extra "hooks" of syntax as possible to
distract us."
If I got the gist of it, he was saying that syntax *adds* ambiguity,
which I think is a bogus statement.
·······@mindspring.com (Rayiner Hashem) writes:
> If I got the gist of it, he was saying that syntax *adds* ambiguity,
> which I think is a bogus statement.
Compare this situation to the failure probabilities of a RAID-0 array.
The more words there are, the more you have to figure out in order to
figure out the meaning, and the more places there are where you can get
confused.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain <·····@nyct.net> wrote:
> ·······@mindspring.com (Rayiner Hashem) writes:
>
>> If I got the gist of it, he was saying that syntax *adds* ambiguity,
>> which I think is a bogus statement.
>
> Compare this situation to the failure probabilities of a RAID-0 array.
>
> The more words there are, the more you have to figure out in order to
> figure out the meaning, and the more places there are where you can get
> confused.
Sure, but language ook so reliable ook can ook some words and still ook
the meaning out. Human language is ook redundant, because it's ook to
be understood even over ook or noisy ook. We don't like ook languages
like Lisp ook be so ook, ook it would ook a lot of ook typing.
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
·······@mindspring.com (Rayiner Hashem) writes:
> > It is easiest for us to get the single, unambiguous meaning of
> > code if there are as few extra "hooks" of syntax as possible to
> > distract us.
>
> I dunno about that. Humans are used to a lot of syntax being used to
> *disambiguiate* meanings.
Yes, but then humans don't write a lot of macros.
In fact, if you watch sitcoms on TV, they are rich in confusions and
misunderstandings that are directly traceable to the need for better
disambiguation.
> For example:
>
> The dog bit roy.
>
> The syntax in this sentence (or is it the grammar?) disambiguates who
> bits who.
A grammar dictates syntax. It's the same.
(Though sometimes people use these terms to disambiguate the two kinds
of syntax, like Lisp at the character level being formed into
structure and Lisp at the structure level being formed into
programs... There are multiple levels at which syntaxing is
occurring. To reiterate your point, we're used to allowing context to
help us disambiguate the meaning of an overloaded word.)
> Now, consider something like this:
>
> (bite the-dog roy)
>
> Who is biting who? You only know either from convention or from the
> API docs.
Yes. The same as for "The dog bit roy." Information passing in any
notation generally presupposes knowledge of the situation. Even when
it looks right.
For example, the expression:
No carro.
in Spanish, this means "no car" or "non car" or something like that.
In Portuguese, it means "in the car". (This one trips me up all the
time when I'm reading and I forget my language context, but continually
reminds me that language does not, by itself, mean anything. It means
things only by convention.)
> Now, consider something like this:
>
> the-dog bite: roy
>
> Now, from just knowing the Smalltalk syntax, its obvious who is biting
> who.
No, it still tells you nothing without convention.
"bite: roy" might be a way of expressing that roy is capable of biting
things, and like an HP calculator, the way you give roy something to bite
is perhaps to put it on the stack before the operation. so roy might be
biting a dog.
"the-dog bite:" might be a way of expressing that the dog is going to bite
something. so the dog might be biting roy.
"the-" might be a way of expressing the noun action of that which follows
and dog bite: might be a way of introducing the name of something, so
"dog bite: roy" might mean
"a roy (whatever that is) whose name was 'dog bite'"
and "the-dog bite: roy" might mean "the concept of having a roy whose
name is 'dog bite'."
So I believe your initial claim, that syntax can be a help, though you
omitted that it can also add complexity or confuse.
I also note you didn't compare the smalltalk notation to either the
lispy (bite :biter the-dog :bitee roy) or
(do-action bite :subject the-dog :object roy)
nor even the dylan do-action(bite,subject:the-dog,object:roy). Not that
either of these is in any way definitive, since there are surely ways
(absent documentation) to confuse them, but at least it's worth pointing
out that the Lispy way fits without Lisp's largely unsyntaxed model and
the parallel way of doing things fits within Dylan's largely heavily
syntaxed model.
PERSONALLY, I think the value of the Lisp model is in its arbitrariness,
same as English. Each was well-published and heavily used for a long time
before people came along to "study" it and critique it. There cannot be
disagreement about what it means for an editor of an (English) newspaper
to say "write me a story" (English text is expected in relatively normal
format). There cannot be disagreement about what it means for a programmer
to say "I'll give you code." For a great many other languages, the
problem is that there is not first class representation that makes it easy
to "trade programs" other than trivially as text. In those languages,
the more complex the syntax, the more distanced the tools are from the
datatype the user offers up when tasked to offer up a program. It's that
distance between data type and operator, not the particular choice of data
type nor of operator, that makes it tough to manipulate in some languages
(e.g., languages with complex parsing that provide macro technologies not
themselves 'aware' of that parsing) and not in others (like Lisp, which
provides operators directly on the data that Lisp itself uses for parsing).
> I also note you didn't compare the smalltalk notation to either the
> lispy (bite :biter the-dog :bitee roy) or
> (do-action bite :subject the-dog :object roy)
> nor even the dylan do-action(bite,subject:the-dog,object:roy). Not that
> either of these is in any way definitive, since there are surely ways
> (absent documentation) to confuse them, but at least it's worth pointing
> out that the Lispy way fits without Lisp's largely unsyntaxed model and
> the parallel way of doing things fits within Dylan's largely heavily
> syntaxed model.
Good point. My avoidance of keyword arguments in generic methods is
just years of C++ experience making me uncomfortable with anything
that imposes a runtime cost :) It'll get better over time, I'm sure.
Although, keyword arguments don't strike me as very prefix-y. "key:
value" definately seems like infix syntax to me.
Rahul Jain <·····@nyct.net> wrote in message news:<··············@nyct.net>...
> ·······@mindspring.com (Rayiner Hashem) writes:
>
> > Although, keyword arguments don't strike me as very prefix-y. "key:
> > value" definately seems like infix syntax to me.
>
> It's :key value, tho.
You are, of course, correct. But the significance ":" still strikes me
as adding syntax. Kinda like &rest and #.
·······@mindspring.com (Rayiner Hashem) writes:
>
> Rahul Jain <·····@nyct.net> wrote in message news:<··············@nyct.net>...
> > ·······@mindspring.com (Rayiner Hashem) writes:
> >
> > > Although, keyword arguments don't strike me as very prefix-y. "key:
> > > value" definately seems like infix syntax to me.
> >
> > It's :key value, tho.
> You are, of course, correct. But the significance ":" still strikes me
> as adding syntax. Kinda like &rest and #.
Not anymore than is already present for reading symbols. Nowhere does
Common Lisp require that keyword argument markers be keyword SYMBOLS.
You are allowed to use any symbols at all for the keywords.
Now, most programmers tend to use keywords as the markers for keyword
arguments, and that is the default, but it isn't mandated. There are,
in fact, some advocates of NOT using keywords.
--
Thomas A. Russ, USC/Information Sciences Institute
···@sevak.isi.edu (Thomas A. Russ) writes:
> ·······@mindspring.com (Rayiner Hashem) writes:
>
>>
>> Rahul Jain <·····@nyct.net> wrote in message news:<··············@nyct.net>...
>> > ·······@mindspring.com (Rayiner Hashem) writes:
>> >
>> > > Although, keyword arguments don't strike me as very prefix-y. "key:
>> > > value" definately seems like infix syntax to me.
>> >
>> > It's :key value, tho.
>> You are, of course, correct. But the significance ":" still strikes me
>> as adding syntax. Kinda like &rest and #.
":" isn't any additional syntax, as Thomas points out. It has no meaning
in the context of the data structure that is being built for the
arglist. In fact, it is prefix syntax because the description comes
before the value. It's not "value (key)", which would be a reasonable
syntax with an appropriate usage (or lack thereof) of parens elsewhere.
The truth is that this has nothing to do with prefix or infix at the
level of the language; it has to do with namespacing. &rest is there
because you need to do SOMETHING to indicate that the next variable will
be bound to the remainder of the arglist. Why not have a uniform look to
the symbols that are used as markers in the lambda-lists so that it's
easier for humans to spot them? # is there because there are all kinds
of funky data types you might want to enter as a literal using special
formatting conventions.
The character-level syntax is really a different thing than what we're
talking about here, and this is what the OP doesn't get. You don't need
to change the low-level parser in order to add a new operator to the
language, because precedence and associativity aren't an issue.
> Not anymore than is already present for reading symbols. Nowhere does
> Common Lisp require that keyword argument markers be keyword SYMBOLS.
> You are allowed to use any symbols at all for the keywords.
>
> Now, most programmers tend to use keywords as the markers for keyword
> arguments, and that is the default, but it isn't mandated. There are,
> in fact, some advocates of NOT using keywords.
I think this is mostly in the case of initargs, as you could have
multiple superclasses with the same symbol-name for their slots, but
different packages. If the initargs are the same symbol, then you get a
strange partial namespace conflict.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain <·····@nyct.net> writes:
> ·······@mindspring.com (Rayiner Hashem) writes:
>
>> Although, keyword arguments don't strike me as very prefix-y. "key:
>> value" definately seems like infix syntax to me.
>
> It's :key value, tho.
IIRC, DSSSL (which is related to Scheme) uses "key:". I can't
recall whether those are anything like CL keywords though.
Rayiner Hashem wrote:
>>It is easiest for us to get the single, unambiguous meaning of
>>code if there are as few extra "hooks" of syntax as possible to
>>distract us.
>
> I dunno about that. Humans are used to a lot of syntax being used to
> *disambiguiate* meanings. For example:
>
> The dog bit roy.
>
> The syntax in this sentence (or is it the grammar?) disambiguates who
> bits who.
That's just a convention.
> Now, consider something like this:
>
> (bite the-dog roy)
>
> Who is biting who? You only know either from convention or from the
> API docs.
Why did you pass "the-dog" as the first parameter then to illustrate
your point?
> Now, consider something like this:
>
> the-dog bite: roy
>
> Now, from just knowing the Smalltalk syntax, its obvious who is biting
> who.
No, it's obvious because of the notion of message passing and dynamic
dispatch, i.e. because of a convention who is responsible for what.
The language Lagoona has a different syntax for that:
bite(roy)->theDog;
Do you understand this because of the syntax?
What about this?
(send the-dog (bite roy))
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
> That's just a convention.
Not in English. In English, its part of the grammer.
> Why did you pass "the-dog" as the first parameter then to illustrate
> your point?
Just the convention that objects are the first parameter to methods.
But its just that, a convention --- having the above statement mean
"Roy should bite the dog" is perfectly legal. In contrast, in English,
it *always* means that the dog should bite Roy, as it does in
Smalltalk.
·······@mindspring.com (Rayiner Hashem) writes:
>> That's just a convention.
> Not in English. In English, its part of the grammer.
Which is a set of conventions.
> In contrast, in English, it *always* means that the dog should bite
> Roy, as it does in Smalltalk.
What makes the smalltalk syntax have some sort of status that's above an
arbitrary choice that some people agreed upon? What is always the
meaning of the second arg to a smalltalk method?
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain <·····@nyct.net> writes:
> ·······@mindspring.com (Rayiner Hashem) writes:
>
> >> That's just a convention.
> > Not in English. In English, its part of the grammer.
>
> Which is a set of conventions.
>
> > In contrast, in English, it *always* means that the dog should bite
> > Roy, as it does in Smalltalk.
[roy bittenBy: theDog].
[theDog bits: roy].
> What makes the smalltalk syntax have some sort of status that's above an
> arbitrary choice that some people agreed upon? What is always the
> meaning of the second arg to a smalltalk method?
In a good proportion of human languages the main gramatical production
is: phrase ::= <subject> <verb> <complement> '.' .
which can me mapped directly in Smalltalk:
[subject verb: complement].
(Of course, in Lisp, would be:
(verb subject complement)
)
--
__Pascal_Bourguignon__ . * * . * .* .
http://www.informatimago.com/ . * . .*
There is no worse tyranny than to force * . . /\ () . *
a man to pay for what he does not . . / .\ . * .
want merely because you think it .*. / * \ . .
would be good for him. -- Robert Heinlein . /* o \ .
http://www.theadvocates.org/ * '''||''' .
SCO Spam-magnet: ··········@sco.com ******************
Pascal Bourguignon wrote:
> Rahul Jain <·····@nyct.net> writes:
>
> > What makes the smalltalk syntax have some sort of status that's above an
> > arbitrary choice that some people agreed upon? What is always the
> > meaning of the second arg to a smalltalk method?
>
> In a good proportion of human languages the main gramatical production
> is: phrase ::= <subject> <verb> <complement> '.' .
> which can me mapped directly in Smalltalk:
>
> [subject verb: complement].
Except where there is no subject, e.g. English imperatives:
imperative ::= <verb> <complement>
e.g.
Add one and one!
which maps directly to Lisp:
(+ 1 1)
Pascal Bourguignon wrote:
> In a good proportion of human languages the main gramatical production
> is: phrase ::= <subject> <verb> <complement> '.' .
> which can me mapped directly in Smalltalk:
>
> [subject verb: complement].
Look, the dog bit Roy!
Did the dog bite Roy?
Wow, the dog bit Roy!
The dog surely bit Roy.
One of the dogs bit Roy.
One or more dogs bit Roy.
The dog bit Roy, and then some.
The dog bit Roy and vice versa.
The dog and Roy bit each other.
Either the dog bit Roy, or Roy bit the dog.
At first, the dog bit Roy, and then they both bit each other.
Can you translate them all into Smalltalk in a straightforward way?
;)
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
On 2003-12-16, Pascal Bourguignon <····@thalassa.informatimago.com> wrote:
|
| In a good proportion of human languages the main gramatical production
| is: phrase ::= <subject> <verb> <complement> '.' .
About 40-45% of human languages are like this; another 40-45% uses the
order <subject> <complement> <verb> instead (examples are Japanese and
Hindi). Only about 10% of languages have the verb coming first in the
sentence. So I guess that's "proof" that Postscript and Forth are much
more intuitive than Lisp ;)
| which can me mapped directly in Smalltalk:
|
| [subject verb: complement].
|
| (Of course, in Lisp, would be:
|
| (verb subject complement)
| )
|
|
--
Cliff Crawford *** ·····@cornell.edu
"Platypus? I thought it was pronounced platymapus. Has it always been
pronounced platypus?" -- Jessica Simpson
Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> In a good proportion of human languages the main gramatical production
> is: phrase ::= <subject> <verb> <complement> '.' .
"Bagles, Mary likes!"
(from a linguistic article I read a few years ago, can't remember
which right now)
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> Pascal Bourguignon <····@thalassa.informatimago.com> writes:
>
> > In a good proportion of human languages the MAIN gramatical production
> > is: phrase ::= <subject> <verb> <complement> '.' .
>
> "Bagles, Mary likes!"
>
> (from a linguistic article I read a few years ago, can't remember
> which right now)
Key word was "main".
--
__Pascal_Bourguignon__ . * * . * .* .
http://www.informatimago.com/ . * . .*
There is no worse tyranny than to force * . . /\ ( . *
a man to pay for what he does not . . / .\ . * .
want merely because you think it .*. / * \ . .
would be good for him. -- Robert Heinlein . /* o \ .
http://www.theadvocates.org/ * '''||''' .
SCO Spam-magnet: ··········@sco.com ******************
Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> Key word was "main".
And? It's completely irrelevant anyway.
...especially if you consider the fact that imperatives and
yes/no-questions (which are in fact more like computer programs)
indeed do have "lisp syntax" in e.g. english!
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> Pascal Bourguignon <····@thalassa.informatimago.com> writes:
>
> > Key word was "main".
>
> And? It's completely irrelevant anyway.
>
> ...especially if you consider the fact that imperatives and
> yes/no-questions (which are in fact more like computer programs)
> indeed do have "lisp syntax" in e.g. english!
What's really tiring with newgroups is that when we obviously speak
about a limited or even an extremely limited part of a domain, there
are always people who intend to push you to emit formal expressions
covering the whole universe. Tautologies are not that interesting.
Well, in the whole universe, it may well be that 99.99999% of the
sentient beings have the exact same syntax than lisp, for all I know.
--
__Pascal_Bourguignon__ . * * . * .* .
http://www.informatimago.com/ . * . .*
There is no worse tyranny than to force * . . /\ ( . *
a man to pay for what he does not . . / .\ . * .
want merely because you think it .*. / * \ . .
would be good for him. -- Robert Heinlein . /* o \ .
http://www.theadvocates.org/ * '''||''' .
SCO Spam-magnet: ··········@sco.com ******************
Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> Well, in the whole universe, it may well be that 99.99999% of the
> sentient beings have the exact same syntax than lisp, for all I know.
How could you possibly assert that?! Do you personally know 99.99999%
of the sentient beings? And even if they do use lisp it might be a
learned response rather than natural....
Oops, sorry, usenet rush. Never mind.
Rayiner Hashem wrote:
>>That's just a convention.
>
> Not in English. In English, its part of the grammer.
And the English grammar fell from the sky?
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
> Rayiner Hashem wrote:
>
>>>That's just a convention.
>> Not in English. In English, its part of the grammer.
>
> And the English grammar fell from the sky?
Not at all. It could have been carried.
Joe Marshall <···@ccs.neu.edu> writes:
> Pascal Costanza <········@web.de> writes:
>
>> Rayiner Hashem wrote:
>>
>>>>That's just a convention.
>>> Not in English. In English, its part of the grammer.
>>
>> And the English grammar fell from the sky?
>
> Not at all. It could have been carried.
Do you mean curried?
Andreas
--
Wherever I lay my .emacs, there's my $HOME.
> And the English grammar fell from the sky?
Argh! I'm not saying that using grammer or syntax makes things less
ambiguous. I'm saying I don't get how it makes things *more*
ambiguous. Please follow the thread :)
* Rayiner Hashem wrote:
> Not in English. In English, its part of the grammer.
Roy, the dog bit. Sad was Roy, he whom the dog bit. Bitten by the dog
was Roy. (The latter possibly Welsh dialect, at least sounds like
that, the second clearly archaic).
English is fairly fixed word-order (since it has hardly any case
endings it has to be), but this obsessing about order just makes
people who do it look even more stupid than they do already. Even
English is much freer than you naively suppose, and there are just
plenty of languages with wildly differing orders, or completely free
order.
--tim
Tim Bradshaw wrote:
>
> * Rayiner Hashem wrote:
> > Not in English. In English, its part of the grammer.
>
> Roy, the dog bit. Sad was Roy, he whom the dog bit. Bitten by the dog
> was Roy. (The latter possibly Welsh dialect, at least sounds like
> that, the second clearly archaic).
>
> English is fairly fixed word-order (since it has hardly any case
> endings it has to be), but this obsessing about order just makes
> people who do it look even more stupid than they do already. Even
> English is much freer than you naively suppose, and there are just
> plenty of languages with wildly differing orders, or completely free
> order.
>
Indeed, latin used to give the part of speech by suffix and
just fling them into the sentence in virtually any order (or
in orders chosen for prosodic reasons).
I suppose that maps onto keyword arguments in some sense. It
would be nice, I think, to have some kind of sentence-constructing
function that took basic symbols as keyword args and then built a
sentence in whatever the *LANG* variable dictated using them.
But that is probably a pipedream...
(Nlanguage :verb bite :subject dog :object Roy :tense past :number singular)
;; if *LANG* = "en"
==> "The dog bit Roy"
;; if *LANG* = "fr"
==> "Roy mordu par le chien"
or something like that. (My French may be wrong. If so, sorry...)
Bear
Ray Dillinger wrote:
> Indeed, latin used to give the part of speech by suffix and
> just fling them into the sentence in virtually any order (or
> in orders chosen for prosodic reasons).
>
Ever seen the Lingua::Perligata::Romana package for Perl?
Sometimes Perl can make you laugh and cry at the same time.
inserto stringum tum unum tum duo excerpementum da.
# $insert = substr($string,1,2);
http://www.csse.monash.edu.au/~damian/papers/HTML/Perligata.html
David Golden <············@oceanfree.net> writes:
> Ray Dillinger wrote:
>
>
> > Indeed, latin used to give the part of speech by suffix and
> > just fling them into the sentence in virtually any order (or
> > in orders chosen for prosodic reasons).
> >
>
> Ever seen the Lingua::Perligata::Romana package for Perl?
> Sometimes Perl can make you laugh and cry at the same time.
Wow, that's ... amazing. Perl's always felt like nails on a
chalkboard to me ... but this ... it's wonderful! I think I had the
same reaction to it that I did to INTERCAL: I'd never use it for
anything serious, but I can't stop writing little things in it!
--
use Lingua::Romana::Perligata;
tfb nomo meo da.
ocf tum berkeley tum edu adrecis meis da.
da adreco meo XLVI indementum tum adreca coniungementum.
LXIV indementum huic da.
egresso nomum tum hoc tum adrecum tum novumversum scribe.
·······@mindspring.com (Rayiner Hashem) wrote in message
>
> The dog bit roy.
>
> The syntax in this sentence (or is it the grammar?) disambiguates who
> bits who. Now, consider something like this:
It really depends on which langauge you speak. It only disambiguates
who bites who in English. In other languages its meaningless. English
is a Subject-Verb-Object language (one of a few) there are also many
langauges that are VSO and even a few that are OSV. So from a human
standpoint its all about the langauge and culture you were raised in,
not something inherent in all humans.
Even the above sentance doens't completly disambiguate whats going
on. There are several questions unanswered.
Why did the dog bite roy.
When did the dog bite roy.
How much damage occured when the dog bit roy.
In a natural langauge these questions can ignored or interpolated
throw context, etc. However, in a computer langauge much, much more
detail is required to make it work. For example, on every machine I
have ever worked on or heard of you can't right something like
print hello world in half an hour
You need much more detail, on the order of
sleep(60 * 30);
print("hello world");
exit(0);
Like the parent's parent poster said, the less possibility of
ambiguity the better for the coder and maintainer.
>
> (bite the-dog roy)
>
> Who is biting who? You only know either from convention or from the
> API docs. Now, consider something like this:
This is perfect sentence structure in a VSO language.
The general percentage of langauges seem to run at the following
percentage
SOV 45%
SVO 43%
VSO 9%
VOS 3%
OVS < 1%
OSV < 1%
So the verb first langauges make up about 12% of the total langauges.
Its not huge, but not insignificant either. This argues strongly
against humans having some type of instinctual preference towards SOV
or SVO langauges.
Eric Merritt wrote:
> The general percentage of langauges seem to run at the following
> percentage
>
> SOV 45%
> SVO 43%
> VSO 9%
> VOS 3%
> OVS < 1%
> OSV < 1%
>
> So the verb first langauges make up about 12% of the total langauges.
> Its not huge, but not insignificant either. This argues strongly
> against humans having some type of instinctual preference towards SOV
> or SVO langauges.
These are very interesting numbers. Can you give any references?
Thanks in advance.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> wrote in message
>
> These are very interesting numbers. Can you give any references?
>
>
> Thanks in advance.
>
>
> Pascal
I got these specific numbers from a paper by Andr�e Gruning. You can
get it at
http://personal-homepages.mis.mpg.de/gruening/bg_short.pdf
Its worth looking at. There are a few other papers that I have found
that back him up.
www.ling.lu.se/education/homepages/ALS052/handouts/TL4.pdf
http://crl.ucsd.edu/pdpnlp/abstract/20020528.html
Rahul Jain <·····@nyct.net> writes:
> Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
>
> > Anyway, sexprs are not necessary to have powerful macros.
>
> They are necessary if you want to have a simple mapping between how the
> macro manipulates the code and how the code looks. That's why people
> like sexrs. You traverse the code exactly how it looks and so does the
> evaluator.
>
> 1+2+3
>
> is '+ the second and fourth symbol in that expression? Or is it the
> operator of the whole expression and the operator of the second
> parameter?
>
> (+ 1 2 3)
In most languages, 1+2+3 is (+ (+ 1 2) 3)
Not quite the same expression as (+ 1 2 3)
That's what you gain with parenthesis: a variable number of arguments
for any operator.
--
__Pascal_Bourguignon__ . * * . * .* .
http://www.informatimago.com/ . * . .*
There is no worse tyranny than to force * . . /\ () . *
a man to pay for what he does not . . / .\ . * .
want merely because you think it .*. / * \ . .
would be good for him. -- Robert Heinlein . /* o \ .
http://www.theadvocates.org/ * '''||''' .
SCO Spam-magnet: ··········@sco.com ******************
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> Anyway, sexprs are not necessary to have powerful macros. What is needed
> is the possibility to parse code using unknown macros into some tree,
> a notation for code quasiquotation, a dual notation for code patterns for
> destructuring, and a handful of functions like checking whether a code
> object is an identifier or producing an identifier from a string.
Right, but doing these things in a traditional C or Pascal syntax is
amazingly difficult.
To use C as an example: first, you cannot parse C with a
straighforward LALR(1) parser because of the typedefs. So you have to
use a hacked parser that has access to the symbol table. Adding a
macro to the language is extending the syntax, so you would have to
regenerate the parser as you added macros. Of course, adding a macro
may introduce ambiguities into the grammar, so you would have to
specify carefully where in the grammar the macro `fits' to avoid
ambiguities. The expansion of the macro may change the parse where
the macro was introduced, so you would have to be careful there as
well.
The macro systems for Java (for example) restrict macros to be used
only where function call syntax, method syntax, or class syntax is
allowed, and you must be careful about what the macro expands into so
that it does not (or does) `eat' things like `else' or `finally'
clauses.
On Mon, 15 Dec 2003 10:12:20 -0500, Joe Marshall wrote:
> Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
>
>> Anyway, sexprs are not necessary to have powerful macros. What is needed
>> is the possibility to parse code using unknown macros into some tree,
>> a notation for code quasiquotation, a dual notation for code patterns for
>> destructuring, and a handful of functions like checking whether a code
>> object is an identifier or producing an identifier from a string.
>
> Right, but doing these things in a traditional C or Pascal syntax is
> amazingly difficult.
That's why I said that it must be parseable into a tree without knowing
macros which are used - such that macros transform trees to trees, not
text to text. Of course taking C or Pascal syntax as is would not fly
(and I dislike C syntax probably more than sexprs). There needs to be
a middle ground.
My goal is to reduce the number of parentheses such that putting closing
brackets on separate lines looks fine, and thus a human can balance them
visually, without having to use an editor.
I also want to reduce the levels of nesting required. Paying attention to
nesting in order to match subexpressions, as advised by sexpr evangelists,
doesn't help when there are a dozen of levels of nesting, 2 spaces each,
and you must see where an indented piece of code goes.
The third goal is to make programs shorter.
My ways to archieve these goals:
- semicolons instead of wrapping whole definitions/statements in parens,
- one kind of let, which corresponds to the hypothetical letrec* in Scheme
but introduces no parens (definitions and the final expression are
separated by semicolons),
- using parens/brackets/braces avoids the need of grouping condition/rhs
or pattern/rhs pairs, because alternating parens and braces are clear
enough; Arc does the same but with parens only,
- infix operators,
- syntactic sugar for cascaded applications and for passing the rest
of a body as a functional argument.
Actually I don't come from Lisp; I'm coming to Lisp. But I can't stand
sexprs, so I'm making my own not-very-unlike-Lisp-but-no-sexprs.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> On Mon, 15 Dec 2003 10:12:20 -0500, Joe Marshall wrote:
>
>> Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
>>
>>> Anyway, sexprs are not necessary to have powerful macros. What is needed
>>> is the possibility to parse code using unknown macros into some tree,
>>> a notation for code quasiquotation, a dual notation for code patterns for
>>> destructuring, and a handful of functions like checking whether a code
>>> object is an identifier or producing an identifier from a string.
>>
>> Right, but doing these things in a traditional C or Pascal syntax is
>> amazingly difficult.
>
> That's why I said that it must be parseable into a tree without knowing
> macros which are used - such that macros transform trees to trees, not
> text to text. Of course taking C or Pascal syntax as is would not fly
> (and I dislike C syntax probably more than sexprs). There needs to be
> a middle ground.
Tree -> tree `macros' aren't really macros, though. They are more of
a semantic transform. When someone says `macro' they generally think
in terms of `I wish the language had this syntactic feature'. If you
insert your macros *after* the syntax has been parsed, it's not really
a macro.
>
> Actually I don't come from Lisp; I'm coming to Lisp. But I can't stand
> sexprs, so I'm making my own not-very-unlike-Lisp-but-no-sexprs.
Have fun.
I will, of course, gleefully say `I told you so' at the point when you
change your mind.
Joe Marshall <···@ccs.neu.edu> schrieb:
> Tree -> tree `macros' aren't really macros, though. They are more of
> a semantic transform. When someone says `macro' they generally think
> in terms of `I wish the language had this syntactic feature'. If you
> insert your macros *after* the syntax has been parsed, it's not really
> a macro.
My definition of macro is basically
macro:function::compiler:interpreter. Certainly it seems like the
essential parts of macros are the semantic transformations they allow,
not the syntax used to apply them.
Adrian Kubala <······@sixfingeredman.net> writes:
> My definition of macro is basically
> macro:function::compiler:interpreter. Certainly it seems like the
> essential parts of macros are the semantic transformations they allow,
> not the syntax used to apply them.
The problem is that with macros in algol-like syntaxes, you need to deal
with the syntax first, but that will depend on the precedence and
associativity semantics...
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Adrian Kubala <······@sixfingeredman.net> writes:
> Joe Marshall <···@ccs.neu.edu> schrieb:
>> Tree -> tree `macros' aren't really macros, though. They are more of
>> a semantic transform. When someone says `macro' they generally think
>> in terms of `I wish the language had this syntactic feature'. If you
>> insert your macros *after* the syntax has been parsed, it's not really
>> a macro.
>
> My definition of macro is basically
> macro:function::compiler:interpreter. Certainly it seems like the
> essential parts of macros are the semantic transformations they allow,
> not the syntax used to apply them.
Not at all! The whole point of a macro is syntactic abstraction.
Joe Marshall <···@ccs.neu.edu> schrieb:
> Adrian Kubala <······@sixfingeredman.net> writes:
>> Joe Marshall <···@ccs.neu.edu> schrieb:
>>> Tree -> tree `macros' aren't really macros, though. They are more of
>>> a semantic transform. When someone says `macro' they generally think
>>> in terms of `I wish the language had this syntactic feature'. If you
>>> insert your macros *after* the syntax has been parsed, it's not really
>>> a macro.
>>
>> My definition of macro is basically
>> macro:function::compiler:interpreter. Certainly it seems like the
>> essential parts of macros are the semantic transformations they allow,
>> not the syntax used to apply them.
>
> Not at all! The whole point of a macro is syntactic abstraction.
Probably I'm not using "syntactic" versus "semantic" correctly. If I say
"I want C-like syntax for scheme" (not really), and call this a
"syntactic feature", this is clearly not what macros are for. You would
not use a macro to map from
if (this) { that } else { foo }
to
(if this that foo)
but you would use one to map from
(and one two three)
to
(if one (if two three #f) #f)
And the thing that strikes me about the second example as opposed to the
first, is that it really is a tree->tree transformation and is basically
syntax-independent.
Adrian Kubala <······@sixfingeredman.net> writes:
> (and one two three)
> to
> (if one (if two three #f) #f)
>
> And the thing that strikes me about the second example as opposed to the
> first, is that it really is a tree->tree transformation and is basically
> syntax-independent.
That's because these transformations *create* syntax.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
On Mon, 15 Dec 2003 16:01:27 -0500, Joe Marshall wrote:
> Tree -> tree `macros' aren't really macros, though. They are more of
> a semantic transform. When someone says `macro' they generally think
> in terms of `I wish the language had this syntactic feature'. If you
> insert your macros *after* the syntax has been parsed, it's not really
> a macro.
So you count readtable changes as macros, but not defmacro or Scheme macros?
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> On Mon, 15 Dec 2003 16:01:27 -0500, Joe Marshall wrote:
>
>> Tree -> tree `macros' aren't really macros, though. They are more of
>> a semantic transform. When someone says `macro' they generally think
>> in terms of `I wish the language had this syntactic feature'. If you
>> insert your macros *after* the syntax has been parsed, it's not really
>> a macro.
>
> So you count readtable changes as macros, but not defmacro or Scheme macros?
Tricky!
Suppose I want to write a macro that is an infix macro with precedence
higher than +, but lower than *, and is right-associative. This has
to be done in the parser in C. It cannot be done at the AST level
because it is then too late.
"Joe Marshall" <···@ccs.neu.edu> wrote in message
·················@ccs.neu.edu...
> Suppose I want to write a macro that is an infix macro with precedence
> higher than +, but lower than *, and is right-associative. This has
> to be done in the parser in C. It cannot be done at the AST level
> because it is then too late.
Well, technically, if your macro system has the ability to morph the AST in
place, then the macro can do anything it wants.
That's the beauty of the Lisp system in that it can pretty much do anything
it wants, including mucking with precedance (not that it really has any).
Compare to the syntax-rule pattern matching macro systems, which basically
can't "do anything they want". But it can be argued that for simpler macros,
syntax-rules is more than sufficient, but I don't think you can write
something like LOOP using them.
Regards,
Will Hartung
(·····@msoft.com)
"Will Hartung" <·····@msoft.com> writes:
> "Joe Marshall" <···@ccs.neu.edu> wrote in message
> ·················@ccs.neu.edu...
>> Suppose I want to write a macro that is an infix macro with precedence
>> higher than +, but lower than *, and is right-associative. This has
>> to be done in the parser in C. It cannot be done at the AST level
>> because it is then too late.
>
> Well, technically, if your macro system has the ability to morph the AST in
> place, then the macro can do anything it wants.
It *could*, but what if I want a macro that syntactically appears,
say, between and ELSE and its associated IF? It is unlikely that the
parser will be happy about this.
Marcin 'Qrczak' Kowalczyk wrote:
> My ways to archieve these goals:
Some of those things already exist:
> - semicolons instead of wrapping whole definitions/statements in parens,
> - one kind of let, which corresponds to the hypothetical letrec* in Scheme
> but introduces no parens (definitions and the final expression are
> separated by semicolons),
see http://www.cliki.net/WITH%20macro
...and I am not convinced that this is a good idea. The various let
forms have their uses.
> - using parens/brackets/braces avoids the need of grouping condition/rhs
> or pattern/rhs pairs, because alternating parens and braces are clear
> enough; Arc does the same but with parens only,
Yes, cond has this problem. But it's trivial to implement your own cond
version that does this right.
> - infix operators,
http://www-2.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/cgol/0.html
> - syntactic sugar for cascaded applications and for passing the rest
> of a body as a functional argument.
>
> Actually I don't come from Lisp; I'm coming to Lisp.
One can tell. ;)
> But I can't stand
> sexprs, so I'm making my own not-very-unlike-Lisp-but-no-sexprs.
Here is what Guy Steele and Richard Gabriel say about this topic:
"We conjecture that Algol-style syntax has not really caught on in the
Lisp community as a whole for two reasons. First, there are not enough
special symbols to go around. When your domain of discourse is limited
to numbers or characters, there are only so many operations of interest,
and it is not difficult to assign one special character to each and be
done with it. But Lisp has a much richer domain of discourse, and a Lisp
programmer often approaches an application as yet another exercise in
language design; the style typically involves designing new data
structures and new functions to operate on them -- perhaps dozens or
hundreds -- and it's just too hard to invent that many distinct symbols
(though the APL community certainly has tried). Ultimately one must
always fall back on a general function-call notation; it's just that
Lisp programmers don't wait until they fail.
Second, and perhaps more important, Algol-style syntax makes programs
look less like the data structures used to represent them. In a culture
where the ability to manipulate representations of programs is a central
paradigm, a notation that distances the appearance of a program from the
appearance of its representation as data is not likely to be warmly
received (and this was, and is, one of the principal objections to the
inclusion of loop in Common Lisp).
On the other hand, precisely because Lisp makes it easy to play with
program representations, it is always easy for the novice to experiment
with alternative notations. Therefore we expect future generations of
Lisp programmers to continue to reinvent Algol-style syntax for Lisp,
over and over and over again, and we are equally confident that they
will continue, after an initial period of infatuation, to reject it.
(Perhaps this process should be regarded as a rite of passage for Lisp
hackers.)"
("The Evolution of Lisp", see http://www.dreamsongs.com/Essays.html )
BTW, you can get very far implementing your syntax extensions by making
use of macros and readtables in Common Lisp. In that process, you will
get to know Common Lisp better, so it wouldn't be such a big waste of
time. ;)
(That's actually one of the really weird things in the Lisp community:
people who rave about the flexibility of dynamic languages, but use C to
implement their new Lisp dialect that is supposed to take over the world
by storm. Not very convincing...)
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
> (That's actually one of the really weird things in the Lisp community:
> people who rave about the flexibility of dynamic languages, but use C
> to implement their new Lisp dialect that is supposed to take over the
> world by storm. Not very convincing...)
Agreed! Next lisp system I write will be lisp down to the metal.
Joe Marshall <···@ccs.neu.edu> writes:
> Pascal Costanza <········@web.de> writes:
>
>> (That's actually one of the really weird things in the Lisp community:
>> people who rave about the flexibility of dynamic languages, but use C
>> to implement their new Lisp dialect that is supposed to take over the
>> world by storm. Not very convincing...)
>
> Agreed! Next lisp system I write will be lisp down to the metal.
I wouldn't bother; I'd offer support to Movitz instead. Written in
Lisp, of course.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes <·····@cam.ac.uk> writes:
> Joe Marshall <···@ccs.neu.edu> writes:
>
> > Pascal Costanza <········@web.de> writes:
> >
> >> (That's actually one of the really weird things in the Lisp community:
> >> people who rave about the flexibility of dynamic languages, but use C
> >> to implement their new Lisp dialect that is supposed to take over the
> >> world by storm. Not very convincing...)
> >
> > Agreed! Next lisp system I write will be lisp down to the metal.
>
> I wouldn't bother; I'd offer support to Movitz instead. Written in
> Lisp, of course.
Hrm, I wonder if that project is named after the guy one of the CM2
FEPs at KTH is named after or after the FEP itself?
//Ingvar
--
((lambda (x y l) (format nil "~{~a~}" (loop for a in x for b in y with c = t
if a collect (funcall (if c #'char-upcase #'char-downcase) (elt (elt l a) b))
else collect #\space if c do (setq c ())))) '(76 1 0 0 nil 0 nil 0 3 0 5 nil 0
0 12 0 0 0) '(2 2 16 8 nil 1 nil 2 4 16 2 nil 9 1 1 13 10 11) (sort (loop for
foo being the external-symbols in :cl collect (string-upcase foo)) #'string<))
Marcin 'Qrczak' Kowalczyk wrote:
> On Sat, 13 Dec 2003 13:32:01 +0000, Kenny Tilton wrote:
>
>
>>Do you mean that literally? Here on c.l.l? Because I do not recall
>>sexprs being a problem for those who have undertaken learning Lisp.
>
>
> Well, I'm not expressing my dislike of sexprs loudly here, because it's
> too easy to yield a counterproductive flamewar.
>
> Anyway, sexprs are not necessary to have powerful macros. What is needed
> is the possibility to parse code using unknown macros into some tree,
> a notation for code quasiquotation, a dual notation for code patterns for
> destructuring, and a handful of functions like checking whether a code
> object is an identifier or producing an identifier from a string.
>
> Yes, a syntax which is parseable into a tree without the knowledge of
> the semantics of most of its constructs tends to require more parens than
> average syntaxes. But it's still possible to do that with less parens than
> in Lisp.
>
> If a syntax uses a bit more punctuation and less parentheses, in particular
> if local definitions don't require putting the body they scope over in an
> additional set of parens, then the indentation style which puts a closing
> bracket on a separate line, indented as much as the line which introduced
> the matching opening bracket (rather than at the end of the previous line),
> becomes attractive.
>
> This style doesn't work for Lisp because there are too many closing
> parens, and the bottom 1/3 of a function definition would consist of
> stair-shaped closing parens only. With fewer parens this style works,
> and it's easy enough to match them with naked eyes, without having
> to highlight them using a bracket-aware editor. This style is used by
> virtually all languages except Lisp dialects.
This style doesn't work for Python. Why should it work for anything else?
Cheers
--
Marco
>
Do people find the syntax of xml (which is arguably more complex or at
least more verbose than sexps) an obstacle to learning xml?
I don't think so. I think they just shut up and put up with the syntax
because people tell them that xml is cool, it's hot, it's the latest
thing.
The same goes for html. HTML syntax is grody, yet kids in grade school
and their grandparents learn HTML without one complaint about it's
horrible syntax.
The thing to do is to harp on the fact that lisp is cool, it's hot,
it's the latest up and coming thing. That will stop people from
whining about parenthesis.
···········@yahoo.com (Tayssir John Gabbour) wrote in message news:<····························@posting.google.com>...
> Hello, I've been watching some people learn lisp, and the sexp
> notation seems like a big obstacle for some. I'm wondering what
> people think about the pedagogy of introducing lisp from the sexp
> perspective, talking about how sexps could be host to all sorts of
> languages, from asm to C to lisp. Then the intro could proceed to
> lisp, explaining that people somehow "felt" it was what they wanted to
> program in. Then lisp could be introduced in terms of how it sensibly
> evolved on a sexp substrate. Lisp arbitrarily evaluates stuff in the
> sexps, and macros are there for people to reconfigure a sexp before
> evaluation.
>
> Let me handle here any errors I might have made in that last
> paragraph. I think the difficulty of lisp is that there's fear that
> certain decisions were deep, when they really were "arbitrary"; in
> other words, it looked good to make lists so simple, and if you're
> going to make a programming language on top of this data language,
> lisp isn't at all half-bad. It's kind of make-believe, that meaning
> can be built upon these atoms and lists.
>
> Also, a source of confusion might be that "characters vs. program
> object" concept. It could be explained that there's i/o and printed
> representations, which we perceive, and the world of abstract objects.
> Bird and Wadler's _Introduction to Functional Programming_ has a
> poetic way of describing this, that maybe somewhere in outer space
> these abstract objects just float around, but we deal with printed
> reps in the interface between our minds and the machines.
>
> BTW, peoples' learning of xml may be leveraged here. Maybe I will ask
> about technical advantages of xml over sexps in another thread, to
> clear away any misconceptions I have; all I can think of is a
> standardized way to deal with charset issues; otherwise it's worse and
> unhealthy for general needs. And even then, there may exist sexp
> standards which do standardize charset issues, even if lisp-style
> sexps happen not to.
>
> Any thoughts? If I made any errors here, it's certainly better than
> if I passed them off to others.
··········@hotmail.com (larry) writes:
> Do people find the syntax of xml (which is arguably more complex or at
> least more verbose than sexps) an obstacle to learning xml?
> I don't think so. I think they just shut up and put up with the syntax
> because people tell them that xml is cool, it's hot, it's the latest
> thing.
> The same goes for html. HTML syntax is grody, yet kids in grade school
> and their grandparents learn HTML without one complaint about it's
> horrible syntax.
> The thing to do is to harp on the fact that lisp is cool, it's hot,
> it's the latest up and coming thing. That will stop people from
> whining about parenthesis.
I think the reason html is so readily learned is the instant
gratification of putting up your own webpage. Since learning sexps
won't let you do the same so quickly, it doesn't seem so "cool". The
user isn't interested in correctness, doctrinal or otherwise, only
setting up some sort of interesting document without getting bogged
down. Efficiency probably isn't of particular concern either because
anything complex will have been generated elsewhere and exported into
html/xml. If html were based on sexps, we would probably be sitting
here decrying horrid coding styles rather than horrid syntaxes.
Gregm
Greg Menke <··········@toadmail.com> wrote:
+---------------
| ··········@hotmail.com (larry) writes:
| > The thing to do is to harp on the fact that lisp is cool, it's hot,
| > it's the latest up and coming thing. That will stop people from
| > whining about parenthesis.
|
| I think the reason html is so readily learned is the instant
| gratification of putting up your own webpage. Since learning sexps
| won't let you do the same so quickly, it doesn't seem so "cool".
+---------------
Uh... Excuse me? Look at any of the many fine sexpr-to-HTML packages
mentioned on <URL:http://www.cliki.net/Web> [such as Tim Bradshaw's
HTOUT or Edi Weitz's CL-WHO, to name just two]. IMHO, you can put up
simple pages *much* easier with sexprs than with raw HTML, e.g.,
<URL:http://rpw3.org/hacks/lisp/minimal.lhp>:
;;; Simplified [but still working] version of the above.
(lhp-basic-page ()
(:html ()
(:head ()
(:title () "Simple Test Page"))
(:body ()
(:h1 () "Simple Test Page")
"This is a simple test page with not much on it.")))
The advantage only gets greater when the pages are interactive and/or
more complex, e.g., <URL:http://rpw3.org/hacks/lisp/appsrv-demo.lhp>
(which still isn't very complex, but...)
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> Greg Menke <··········@toadmail.com> wrote:
> +---------------
> | ··········@hotmail.com (larry) writes:
> | > The thing to do is to harp on the fact that lisp is cool, it's hot,
> | > it's the latest up and coming thing. That will stop people from
> | > whining about parenthesis.
> |
> | I think the reason html is so readily learned is the instant
> | gratification of putting up your own webpage. Since learning sexps
> | won't let you do the same so quickly, it doesn't seem so "cool".
> +---------------
>
> Uh... Excuse me? Look at any of the many fine sexpr-to-HTML packages
> mentioned on <URL:http://www.cliki.net/Web> [such as Tim Bradshaw's
> HTOUT or Edi Weitz's CL-WHO, to name just two]. IMHO, you can put up
> simple pages *much* easier with sexprs than with raw HTML, e.g.,
> <URL:http://rpw3.org/hacks/lisp/minimal.lhp>:
>
> ;;; Simplified [but still working] version of the above.
> (lhp-basic-page ()
> (:html ()
> (:head ()
> (:title () "Simple Test Page"))
> (:body ()
> (:h1 () "Simple Test Page")
> "This is a simple test page with not much on it.")))
>
> The advantage only gets greater when the pages are interactive and/or
> more complex, e.g., <URL:http://rpw3.org/hacks/lisp/appsrv-demo.lhp>
> (which still isn't very complex, but...)
>
No doubt- which is great for people using Lisp who want to generate
html, Ive used HTOUT myself- its very handy- but what I meant was
people sitting down and actually <learning> html. You know the deal,
open up Notepad with some 3" thick Learn HTML in 21 days book
alongside, start typing- save and open the file with IE- instant
gratification. Now having "learned" html, when the page gets too
complex, the user then switches to Word or some crap where they can
type their document and Save As HTML. Since they "know" html and with
all the angle syntax business a fond memory, they are able to pass
judgement on all other languages that use punctuation.
Gregm
On Sat, 13 Dec 2003 15:29:29 -0800, larry wrote:
> Do people find the syntax of xml (which is arguably more complex or at
> least more verbose than sexps) an obstacle to learning xml?
> I don't think so. I think they just shut up and put up with the syntax
> because people tell them that xml is cool, it's hot, it's the latest
> thing.
It doesn't imply that XML is suitable for representing *programs*. I've
seen about two XML-lased languages; one was just extremely verbose, and
another cheated by mixing XML elements with textual syntax in text data
and in attribute values, still being very verbose.
Sexprs might be convenient for representing configuration files. They are
a bit too verbose for my taste for writing programs, and require too much
nesting.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk writes:
> Sexprs might be convenient for representing configuration files. They are
> a bit too verbose for my taste for writing programs, and require too much
> nesting.
What's the problem? Just don't use Lisp.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
In article <····························@posting.google.com>, larry
<··········@hotmail.com> wrote:
> Do people find the syntax of xml (which is arguably more complex or at
> least more verbose than sexps) an obstacle to learning xml?
> I don't think so. I think they just shut up and put up with the syntax
> because people tell them that xml is cool, it's hot, it's the latest
> thing.
> The same goes for html. HTML syntax is grody, yet kids in grade school
> and their grandparents learn HTML without one complaint about it's
> horrible syntax.
> The thing to do is to harp on the fact that lisp is cool, it's hot,
> it's the latest up and coming thing. That will stop people from
> whining about parenthesis.
Yes, I do find the syntax of XML an obstacle to using it it using to
obstacle an XML of syntax the find do I, yes.
This style of repetition may work for hand-editing simple HTML, where
one always wants to pick out what is closing what portion of text, but
it becomes increasingly difficult to manage for non-markup applications
applications non-markup for manage to difficult increasingly becomes it
but, text of portion what closing is what out pick to wants always one
where, HTML simple hand-editing for work may repetition of style this.
Fortunately, since I started using English-XML, I have become much more
accustomed to it it to accustomed more much become have I, English-XML
using started I since, fortunately.
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
Brian Mastenbrook wrote:
> Yes, I do find the syntax of XML an obstacle to using it it using to
> obstacle an XML of syntax the find do I, yes.
>
> This style of repetition may work for hand-editing simple HTML, where
> one always wants to pick out what is closing what portion of text,
The solution to this problem should be quite familiar to cll readers:
Just use an editor that works.<C-c RET>
If you insist on using Notepad, every syntax will suck.<C-c />
> but it becomes increasingly difficult to manage for non-markup applications
Not using markup languages for non-markup applications would also be a
good idea, but I guess it's a little late for that.
··········@hotmail.com (larry) writes:
> Do people find the syntax of xml (which is arguably more complex or at
> least more verbose than sexps) an obstacle to learning xml?
There is something to learn?
Tayssir John Gabbour wrote:
> BTW, peoples' learning of xml may be leveraged here. Maybe I will ask
> about technical advantages of xml over sexps in another thread, to
> clear away any misconceptions I have; all I can think of is a
> standardized way to deal with charset issues; otherwise it's worse and
> unhealthy for general needs. And even then, there may exist sexp
> standards which do standardize charset issues, even if lisp-style
> sexps happen not to.
Note that Microsoft is intending (see sample code released at the recent PDC)
to integrate XML with its .NET languages, so that you can use it to declare or
initialise variables. (At the same time they've announced anonymous
functions -- Greenspun's tenth validated again?)
--
Regards,
Mark Hurd, B.Sc.(Ma.) (Hons.)
"Mark Hurd" <········@ozemail.com.au> wrote in message news:<············@news.iprimus.com.au>...
> Note that Microsoft is intending (see sample code released at the recent PDC)
> to integrate XML with its .NET languages, so that you can use it to declare or
> initialise variables. (At the same time they've announced anonymous
> functions -- Greenspun's tenth validated again?)
Are you talking about XAML? FYI, influenced by Erik Naggum's claim
that "there are no attributes," I asked Joe Beda kind of ignorantly
whether XAML could have a syntax that didn't require attributes. His
answer: Already done! Greenspunning in action.
If you have something like:
<window height="50">...</window>
You could trivially replace it with:
<window>
<window.height>50</window.height>
</window>
This was asked on his blog, so details are there, but he has one of
those excruciating calendar navigation thingies, so I can't find it
easily now...
Erik's claim:
http://groups.google.com/groups?q=g:thl40872739d&dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&selm=3207661527508051%40naggum.net
"Tayssir John Gabbour" <···········@yahoo.com> wrote in message
·································@posting.google.com...
> Hello, I've been watching some people learn lisp, and the sexp
> notation seems like a big obstacle for some.
Here are my "issues" regarding Sexprs/Lisp. None of them important.
I think for new users, prefix math is more of an issue than sexprs in
general. It's pretty easy to whip out 1 + 2 * 3 - 4 / 5, but it's takes a
distinct pause in the train of though to write this in Lisp. Of course a lot
of this is sourced from the fact that most people type these kinds of
equations in from a book or notes, rather than scheming them up in their
heads. Work in the domain enough, and you can think in terms of prefix or
RPN, but if you're typing the equation in from a book, it's a bit more of a
page-fault in your head to reparse the math.
This can be aggravating for new users.
As far as editing, I can also appreciate the frustration with Sexprs:
proc myProc(String arg1, Int arg2)
{
Int aLocal = 0;
aLocal = random(10);
if(arg2 > 1) {
if (aLocal > 3) {
print "You miss" arg1;
}
} else {
if (aLocal < 2) {
print "You hit" arg1;
}
}
}
vs
(defun myProc (arg1 arg2)
(let ((aLocal 0))
(setf aLocal (random 10))
(if (> arg2 1)
(if (> aLocal 3)
(print "You miss" arg1))
(if (< aLocal 2)
(print "You hit" arg1)))))
The problem here is the 3rd if clause.
In the first example, it's "easy" to delete that clause, and the else, in a
typical GUI editor. Simply click in front of the else, drag to the
"obviously" matching closing bracket, and hit DEL. You can do the same with
the 2nd if clause in either example, as it is "obvious" where this code
begins and ends, though with the first example you'd end up with empty {},
which is messy, but safe. In the Lisp example you'd change the actual code
behavior, which is tidy, but not safe.
But with the 3rd if in the Lisp function, it is certainly not "obvious"
where the if ends in the multitude of )'s ending the defun.
It's obvious to the computer, but not to the eye. Do it by hand, and you
risk a simple error (unmatched ')') if you didn't get enough parens, to
absorbing the "rest of the program" and getting an umatched "(" someplace
else. At which point you need to eye the entire function to make sure you
didn't muck anything up.
To wit it will be argued that in an SSE (Sufficiently Smart Editor), you
would simply go to the start of the 3rd If, and delete the sexpr wholesale.
But part of being a new user is not knowing the extensions and wonders of an
SSE. Hell, half the Unix population get through their entire lives knowing
less than a dozen VI commands.
With all of my Lisp dabbling, I have almost never used the sxpr commands of
Emacs. I simply obliterate the ))))'s and add them back watching how they
match. Works fine with VI as well.
But it brings up a point. I have always been under the impression that Lisp
is best taught as part of its environment, and the editor is a part of that
environment.
For example, Smalltalk can be edited using VI, but pretty much nobody does
that. Pretty much no book or tutorial does that. They all show the basics of
the browsers et al because they are so ingrained into the Smalltalk
experience.
In a similar way, Emacs is so ingrained into the Lisp psyche, it pretty much
goes unsaid. Yet, in most of the books, emacs goes unmentioned. Unix folks
use Emacs and Lisp, Harelquin uses Emacs-esque commands, MCL uses "FRED". I
don't know what Franz's default editor does, nor Corman. But both can be
made to work with emacs, and I imagine most Lispers do do that, especially
if they work between different Lisps (with emacs being their common
denominator).
So, in some ways, I think that sexprs can be a bit of a hurdle. Particularly
those used to algol languages and dumb editors. (Or even smart editors used
in dumb ways.)
If Lisp were taught with its editor, this would be less of a problem, as the
editor can manage the structure more easily. It would also highlight some of
the power that folks really like about Lisp (auto complete, packages, etc).
While experienced Lisper watch the ()'s simply vanish from their eye and use
their editor to manage higher level operations, with new folks, every
keystroke is a conscious thought experiment for them, and at this stage, the
()'s can be quite bewildering and overwhelming. And when folks are
struggling to pick up something, they'll harp on anything out of the
ordinary until they "get it" and feel that sexprs are worth learning and
navigating to get the benefits of the Lisp environment.
Regards,
Will Hartung
(·····@msoft.com)
Will Hartung <·····@msoft.com> schrieb:
> But part of being a new user is not knowing the extensions and wonders of an
> SSE. Hell, half the Unix population get through their entire lives knowing
> less than a dozen VI commands.
But surely "%" is one of those dozen?
> So, in some ways, I think that sexprs can be a bit of a hurdle. Particularly
> those used to algol languages and dumb editors. (Or even smart editors used
> in dumb ways.)
IMO the only editor support you *really* need for lisp is
find-matching-bracket.
Anyways, if every Lisp book taught you how to use Emacs it would give
the impression that Lisp *requires* more editor support than most other
languages. Which I think is not true (though it can take advantage of
more editor support).
Adrian Kubala <······@sixfingeredman.net> writes:
> Will Hartung <·····@msoft.com> schrieb:
> > But part of being a new user is not knowing the extensions and wonders of an
> > SSE. Hell, half the Unix population get through their entire lives knowing
> > less than a dozen VI commands.
>
> But surely "%" is one of those dozen?
Perhaps not. I switched to emacs before knowing it it seems...
--
__Pascal_Bourguignon__ . * * . * .* .
http://www.informatimago.com/ . * . .*
There is no worse tyranny than to force * . . /\ () . *
a man to pay for what he does not . . / .\ . * .
want merely because you think it .*. / * \ . .
would be good for him. -- Robert Heinlein . /* o \ .
http://www.theadvocates.org/ * '''||''' .
SCO Spam-magnet: ··········@sco.com ******************
Will Hartung wrote:
> "Tayssir John Gabbour" <···········@yahoo.com> wrote in message
> ·································@posting.google.com...
>
>>Hello, I've been watching some people learn lisp, and the sexp
>>notation seems like a big obstacle for some.
>
>
> Here are my "issues" regarding Sexprs/Lisp. None of them important.
>
> I think for new users, prefix math is more of an issue than sexprs in
> general. It's pretty easy to whip out 1 + 2 * 3 - 4 / 5, but it's takes a
> distinct pause in the train of though to write this in Lisp.
Do you remember the days at school where you had a really hard time
explaining your classmates why pocket calculators suck that don't obey
operator precedence rules?
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
> Do you remember the days at school where you had a really hard time
> explaining your classmates why pocket calculators suck that don't obey
> operator precedence rules?
Actually, I had a really hard time explaining to my classmates why
infix (TI) calculators suck, as opposed to postfix (HP).
No, scratch that. Most of them agreed. :)
--
Chris Jeris ······@oinvzer.net Apply (1 6 2 4)(3 7) to domain to reply.
On Mon, 15 Dec 2003 17:56:24 -0800, "Will Hartung" <·····@msoft.com> wrote:
>I think for new users, prefix math is more of an issue than sexprs in
>general. It's pretty easy to whip out 1 + 2 * 3 - 4 / 5, but it's takes a
>distinct pause in the train of though to write this in Lisp. Of course a lot
Yes, but its also pretty easy to get wrong, because of operator precedence
rules, compounded by operator overloading (C++/C#) issues and undefined order of
evaluation. I rarely if ever see expressions like that in commercial code. It
nearly always will have parentheses clarifying the evaluation order intended,
often with defined variables holding subexpressions. The reason is that operator
precedence rules are so poorly remembered by many programmers, that anyone
enhancing or maintaining the program (or reviewing it) is immediately suspicious
of an expression with several variables and no explicit evaluation ordering. A
C++ programmer will clarify the intended evaluation order with parens.
So you write:
1 + (2 * 3) - (4/5)
and often wrap parens around the whole thing so it fits nicely in the outer
statement/macro:
(1 + (2 * 3) - (4 / 5))
Compare to Lisp:
(+ 1 (* 2 3) (/ -4 5))
Note the same number of parentheses. Not only that, Lisp, unlike
C++/Java/C#/etc., gives the correct result. :-)
Roger
Roger Corman
Corman Technologies
www.cormanlisp.com
Will Hartung wrote:
> ...
>
> Here are my "issues" regarding Sexprs/Lisp. None of them important.
>
> ...
>
> As far as editing, I can also appreciate the frustration with Sexprs:
>
> ...
>
> vs
>
> (defun myProc (arg1 arg2)
> (let ((aLocal 0))
> (setf aLocal (random 10))
> (if (> arg2 1)
> (if (> aLocal 3)
> (print "You miss" arg1))
> (if (< aLocal 2)
> (print "You hit" arg1)))))
>
> The problem here is the 3rd if clause.
>
> ...
it's not that hard. on lispm.dyndns.org r.joswig has a short about using mcl.
>
> In a similar way, Emacs is so ingrained into the Lisp psyche, it pretty much
> goes unsaid. Yet, in most of the books, emacs goes unmentioned. Unix folks
> use Emacs and Lisp, Harelquin uses Emacs-esque commands, MCL uses "FRED". I
> don't know what Franz's default editor does, nor Corman. But both can be
> made to work with emacs, and I imagine most Lispers do do that, especially
> if they work between different Lisps (with emacs being their common
> denominator).
not all. i've found it to be more effective to keep using mcl's editor when i
work with those lisps which have no ide. even, in some cases, when the lisp is
running on another machine.
...