An Acceptable Lisp

On 1 Sep, 03:07, Ali <emailalicl...@gmail.com> wrote:
> > > > (3-) (define factorial
> > > > * (-> (0) 1)
> > > > * (-> (X) (* X (factorial (- X 1)))))
> > > > factorial
>
> Cool, you added extra parenthesis around the input parts, 0 and X.
> Why? I'm struggling to see why not just use (-> 0 1)
>
> This is all actually what I meant by the post at:http://groups.google.co.uk/group/Qil...hread/f1fabe52...
>
> Thanks for the macro code, maybe I'll look into using the language
> again.
>
> > > > I think the moral here is - be careful of what you wish for.
>
> In this case, if I did that I'd instead have to rip out my guts from
> the feeling their giving me.
> By formatting the data with prefix, you pave the way for
> a) Greater ability to re-use the code as data and in macro's.
> b) Possibility of writing your code more concisely as a result.
>
> The (-> 0 1) above might become (0 1) as similar to a let form. Dare I
> say it, but if ever an indentation syntax reader were introduced, I
> would use it, and I would type this:
>
> mydef factorial
> * 0 1
> * X (* X (factorial (- X 1))
>
> I would imagine you used the current Qi syntax (partly) to make the
> code easier for people to type. Personally, I find the above to be
> even easier, regardless of whether an arrow is necessary to focus the
> eyes.
>
> For those of you spinning with rage at my insolence, here's the above
> code without my hypothetical indent-reader:
>
> (mydef factorial
> * (0 1)
> * (X (* X (factorial (- X 1))))
>
> Of course, if you like, those wrapping parens can be removed anyway in
> the same way that Qi does,
> but I would see that as a bad idea.
>
> Ali

As in

C:\Documents and Settings\User\Desktop\Qi II\Qi 9.2>lisp.exe -M
lispinit.mem sta
rtup.txt

Qi 2007, Copyright (C) 2001-2007 Mark Tarver
www.lambdassociates.org
version 9.2 (Turbo-E)

(0-) (define myrule
Rule -> (let Patterns (all-but-last Rule)
Result (last Rule)
(append Patterns [-> Result])))
myrule

(1-) (define all-but-last
[_] -> []
[X | Y] -> [X | (all-but-last Y)])
all-but-last

(2-) (define mapcan
_ [] -> []
F [X | Y] -> (append (F X) (mapcan F Y)))
mapcan

(3-) (define last
[X] -> X
[_ | Y] -> (last Y))
last

(4-) (define macroexpand
[mydef F | Rules] -> [define F | (mapcan myrule Rules)]
X -> X)

WARNING:
DEFUN/DEFMACRO: redefining function macroexpand in C:\Documents and
Settings\User\Desktop\Qi II\Qi 9.2\startup.txt, was defined in C:
\Documents and Settings\User\Desktop\Qi II\Qi 9.2\Qi
9.2.txtmacroexpand

(5-) (mydef factorial
(0 1)
(X (* X (factorial (- X 1)))))
factorial

(6-) (factorial 4)
24

-> does carry some information though in Qi - its not just noise - <-
is an alternative. See http://www.lambdassociates.org/studies/study05.htm
for an example.

Qi II improves on Qi I by removing 'macroexpand' and allowing you to
declare any function as akin to macroexpand. So the above would be in
Qi II identical except instead of

(define macroexpand
[mydef F | Rules] -> [define F | (mapcan myrule Rules)]
X -> X)

We might have

(define mylanguage
[mydef F | Rules] -> [define F | (mapcan myrule Rules)]
X -> X)

and to declare that mylanguage is used as a sugar function (i.e. to
change the syntax of the reader) we write

(sugar in mylanguage 0)

meaning that the function mylanguage is to be used to change the input
and that the function is to be applied in 0th position (ie. before any
other sugar function). This allows you to import syntactic changes
without overwriting previous syntax changes because there is no longer
a single 'macroexpand' function. Analogously by swapping 'out' for
'in' you can program the printer.

The ability to create sugar functions in Qi II really displaces not
all but quite a lot of what is done in Lisp by DEFMACRO. It
effectively allows you to create your own language on top of Qi with
your own shorthands and conventions.

Mark

On Aug 27, 11:07*pm, Kaz Kylheku <kkylh...@gmail.com> wrote:
> On 2008-08-26, Jon Harrop <j...@ffconsultancy.com> wrote:
>
> > Matthew D Swank wrote:
> >> He also said:
> >> "There should be a simple, easily implementable kernel to the Lisp. That
> >> kernel should be both more than Scheme -- modules and macros -- and less
> >> than Scheme -- continuations remain an ugly stain on the otherwise clean
> >> manuscript of Scheme.
>
> > What's wrong with continuations?
>
> Continuations are one of those features that, as a user, you will probably pay
> for even if you don't use them.
And pay with gold, making implementation of lisp is a piece of cake,
making one that supports (proper) continuations is a hard work.
>
> Of course, I mean real, first-class, re-invocable, dynamic continuations:the
> kind which capture the entire call stack, so that you can re-enter a previously
> saved context, and then return through its entire call chain, which may
> traverse separate compilation units.
I hope you don't mean copying the stack by capturing the continuation
because that's not implementation of call/cc that's an ugly hack.
Anyone thinks about copying few MBs of stack.
>
> This type of object is the only thing that is worthy of being called
> ``continuation'', but the distinction needs to be made because of lesser hacks
> which are called continuations.
>
> If you implement real continuations so that there is no cost to programs which
> don't use continuations, the implementation will suck donkey dung for programs
> that do use continuations.
There is always some cost in implementing continuations, complexity of
the implementation, memory use, getti ng rid of the call stack, source
to source transformations, nothing comes for free in the life, will it
show in your code depends mostly on what kind of code you're making.
>
> The problem is that a separately-compiled module of code which calls other
> modules will have to support being traversed by continuations even if it
> doesn't actually use them. If it is compiled to use a regular stack for its
> local variables (i.e. user doesn't pay for the continuation feature that isn't
> being used), the creation of a continuation will become expensive; it will have
> to go back and clone the entire stack.
>
> Lexical closures don't have this problem. If you don't use them, you don't pay.
> A function that doesn't close over anything can be compiled in a way thatis
> oblivious to lexical closures. If a parent function calls some external child
> function that makes closures, that activity has no interaction with the parent
> function.

On Aug 27, 11:42*am, Pascal Costanza <p...@p-cos.net> wrote:
> Jon Harrop wrote:
> > Matthew D Swank wrote:
> >> He also said:
> >> "There should be a simple, easily implementable kernel to the Lisp. That
> >> kernel should be both more than Scheme -- modules and macros -- and less
> >> than Scheme -- continuations remain an ugly stain on the otherwise clean
> >> manuscript of Scheme.
>
> > What's wrong with continuations?
>
> They interact badly with side effects.
Lisp is the language that gives you control not shields you from your
own stupidity. If continuations have problem in some program with side
effects that don't use them in that particular place. Don't blame a
powerful tools because you have problem using it.

>
> Pascal
>
> --
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/

Slobodan Blazeski wrote:
> On Aug 27, 11:42 am, Pascal Costanza <p...@p-cos.net> wrote:
>> Jon Harrop wrote:
>>> Matthew D Swank wrote:
>>>> He also said:
>>>> "There should be a simple, easily implementable kernel to the Lisp. That
>>>> kernel should be both more than Scheme -- modules and macros -- and less
>>>> than Scheme -- continuations remain an ugly stain on the otherwise clean
>>>> manuscript of Scheme.
>>> What's wrong with continuations?
>> They interact badly with side effects.
> Lisp is the language that gives you control not shields you from your
> own stupidity. If continuations have problem in some program with side
> effects that don't use them in that particular place. Don't blame a
> powerful tools because you have problem using it.

The problem is that two completely unrelated parts of a program may
interact badly because of continuations, and it's hard to protect your
code from that.

(I agree that when in doubt you should give more power, not less. But
the problem is there anyway.)

Pascal

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/

On Sep 1, 6:04*am, namekuseijin <namekusei...@gmail.com> wrote:
> What if the defined functions takes more than 1 argument? *The
> parenthesis mean a list of arguments, in this particular case, just
> one.

Sorry, I assumed there would be only one output. The extra parens are
okay if you want the structure though.

Thanks again for the extra code Mark, I wasn't arguing that it can't
be implemented in Qi,
I was arguing the case for why I will code in that way rather than the
default.

On Sep 1, 10:33 am, Mark Tarver <dr.mtar...@ukonline.co.uk> wrote:
> The ability to create sugar functions in Qi II really displaces not
> all but quite a lot of what is done in Lisp by DEFMACRO. It
> effectively allows you to create your own language on top of Qi with
> your own shorthands and conventions.

As far as I understand, you are talking about a list of functions,
which define rules of code transformation and which are applied in a
specified order. But that's more the analogue of Lisp's *reader*
macros, not the (compiler) macros, isn't it? It's not something, that
you can apply in one place and leave aside in the other.

So, returning to my previous question: if I define this new
macroexpand in such way and try to load the code, written in infix
manner, it won't compile, right?

Vsevolod

On 1 sep, 10:19, Slobodan Blazeski <slobodan.blaze...@gmail.com>
wrote:
> On Aug 27, 11:42 am, Pascal Costanza <p...@p-cos.net> wrote:> Jon Harrop wrote:
> > > Matthew D Swank wrote:
> > >> He also said:
> > >> "There should be a simple, easily implementable kernel to the Lisp. That
> > >> kernel should be both more than Scheme -- modules and macros -- and less
> > >> than Scheme -- continuations remain an ugly stain on the otherwise clean
> > >> manuscript of Scheme.
>
> > > What's wrong with continuations?
>
> > They interact badly with side effects.
>
> Lisp is the language that gives you control not shields you from your
> own stupidity. If continuations have problem in some program with side
> effects that don't use them in that particular place. Don't blame a
> powerful tools because you have problem using it.

Lisp does in fact shield me from my own stupidity (eg, (aref nil 1)
does not segfault), but more importantly it should shield me from
*your* stupidity (and you from mine). Your statement above tells me
that you're not actually familiar with the sorts of problems that
continuations systematically introduce.

One very easy to understand example is mapcar. Imagine you're mapping
across a 10 element list:

(mapcar (lambda (x) ...)
'(0 1 2 3 4 5 6 7 8 9))

I see 10 continuations that can be captured here returning from calls
to the anonymous function. Every one of them is a bad idea. What do
you think will happen if my function is:

(lambda (x)
(call/cc
(lambda (cont)
(when (zerop x) (setq *cont* cont))
x)))

Now when I reinvoke that continuation in *cont*

(funcall *cont* "zero")

what happens? Do I have a mapcar that returns

(0 1 2 3 4 5 6 7 8 9 "zero")

or

("zero" 1 2 3 4 5 6 7 8 9)

? Depends on how mapcar is implemented. In other words, *you* as a
library author have to be aware of all possible continuations that I
as your user might throw through your library, exposing all sorts of
grotty implementation details that cannot be seen in a language
without multiply-invokable continuations.

After playing around with them for a while, I think continuations have
no place in an impure functional language, which is one of the hats
that Lisp wears. They force your functional abstractions to be leaky.

On Sep 1, 3:48*pm, "Thomas F. Burdick" <tburd...@gmail.com> wrote:
> On 1 sep, 10:19, Slobodan Blazeski <slobodan.blaze...@gmail.com>
> wrote:
>
>
>
>
>
> > On Aug 27, 11:42 am, Pascal Costanza <p...@p-cos.net> wrote:> Jon Harrop wrote:
> > > > Matthew D Swank wrote:
> > > >> He also said:
> > > >> "There should be a simple, easily implementable kernel to the Lisp.. That
> > > >> kernel should be both more than Scheme -- modules and macros -- and less
> > > >> than Scheme -- continuations remain an ugly stain on the otherwiseclean
> > > >> manuscript of Scheme.
>
> > > > What's wrong with continuations?
>
> > > They interact badly with side effects.
>
> > Lisp is the language that gives you control not shields you from your
> > own stupidity. If continuations have problem in some program with side
> > effects that don't use them in that particular place. Don't blame a
> > powerful *tools because you have problem using it.
>
> Lisp does in fact shield me from my own stupidity (eg, (aref nil 1)
> does not segfault), but more importantly it should shield me from
> *your* stupidity (and you from mine). Your statement above tells me
> that you're not actually familiar with the sorts of problems that
> continuations systematically introduce.
Not very much. But considering the benefits I'm willing to pay the
price. Things I like to do are very easy with continuations and very
hard without them.
>
> One very easy to understand example is mapcar. Imagine you're mapping
> across a 10 element list:
>
> *(mapcar (lambda (x) ...)
> * * * * *'(0 1 2 3 4 5 6 7 8 9))
>
> I see 10 continuations that can be captured here returning from calls
> to the anonymous function. Every one of them is a bad idea. What do
> you think will happen if my function is:
>
> *(lambda (x)
> * *(call/cc
> * * *(lambda (cont)
> * * * *(when (zerop x) (setq *cont* cont))
> * * * *x)))
>
> Now when I reinvoke that continuation in *cont*
>
> *(funcall *cont* "zero")
>
> what happens? Do I have a mapcar that returns
>
> *(0 1 2 3 4 5 6 7 8 9 "zero")
>
> or
>
> *("zero" 1 2 3 4 5 6 7 8 9)
This one. I understand the implementation leaked. But so what? In the
language I'm working almost everything is transparent anyway so
exposing the control flow is no big deal. Actually I'm thinking about
exposing the enviroment too. I believe that opaqueness just gets in
the way. Take c++/c# protected fields and compare it with cl with-
slots. Which system is better in your eyes?
>
> ? Depends on how mapcar is implemented. In other words, *you* as a
> library author have to be aware of all possible continuations that I
> as your user might throw through your library, exposing all sorts of
> grotty implementation details that cannot be seen in a language
> without multiply-invokable continuations.
That's expecting to much from a library authors, if you fallow that
scrutiny will there be any library that could pass your rigorous tests
to be usable. I've seen so many buggy libraries or ones that could be
broken with certain inputs coming from multibillione companies and
pedigreed open source projects but people still use them and build
their software with them.Continuation might make easier to blow your
head but if they make problems don't use them in your project, it's
as simple as that. It's much easier than not having them when you need
them. Every powerful feature has an oponents for introduction in
*lesser* languages because it would make the code unsafe, how about cl
macros and anonymous functions, or forth direct stack manipulation.
It's like a nuclear weapon, it could surely make a lot of trouble if
left uncared but it will makes enemies think twice invading you.



>
> After playing around with them for a while, I think continuations have
> no place in an impure functional language,
There is no pure functional languages, only those posing as such.
> which is one of the hats that Lisp wears.
> They force your functional abstractions to be leaky.- Hide quoted text -
>
> - Show quoted text -

Thomas F. Burdick wrote:
> On 1 sep, 10:19, Slobodan Blazeski <slobodan.blaze...@gmail.com>
> wrote:
>
>>On Aug 27, 11:42 am, Pascal Costanza <p...@p-cos.net> wrote:> Jon Harrop wrote:
>>
>>>>Matthew D Swank wrote:
>>>>
>>>>>He also said:
>>>>>"There should be a simple, easily implementable kernel to the Lisp. That
>>>>>kernel should be both more than Scheme -- modules and macros -- and less
>>>>>than Scheme -- continuations remain an ugly stain on the otherwise clean
>>>>>manuscript of Scheme.
>>
>>>>What's wrong with continuations?
>>
>>>They interact badly with side effects.
>>
>>Lisp is the language that gives you control not shields you from your
>>own stupidity. If continuations have problem in some program with side
>>effects that don't use them in that particular place. Don't blame a
>>powerful tools because you have problem using it.
>
>
> Lisp does in fact shield me from my own stupidity (eg, (aref nil 1)
> does not segfault), but more importantly it should shield me from
> *your* stupidity (and you from mine). Your statement above tells me
> that you're not actually familiar with the sorts of problems that
> continuations systematically introduce.
>
> One very easy to understand example is mapcar. Imagine you're mapping
> across a 10 element list:
>
> (mapcar (lambda (x) ...)
> '(0 1 2 3 4 5 6 7 8 9))
>
> I see 10 continuations that can be captured here returning from calls
> to the anonymous function. Every one of them is a bad idea. What do
> you think will happen if my function is:
>
> (lambda (x)
> (call/cc
> (lambda (cont)
> (when (zerop x) (setq *cont* cont))
> x)))
>
> Now when I reinvoke that continuation in *cont*
>
> (funcall *cont* "zero")
>
> what happens? Do I have a mapcar that returns
>
> (0 1 2 3 4 5 6 7 8 9 "zero")
>
> or
>
> ("zero" 1 2 3 4 5 6 7 8 9)
>
> ? Depends on how mapcar is implemented. In other words, *you* as a
> library author have to be aware of all possible continuations that I
> as your user might throw through your library, exposing all sorts of
> grotty implementation details that cannot be seen in a language
> without multiply-invokable continuations.
>
> After playing around with them for a while, I think continuations have
> no place in an impure functional language, which is one of the hats
> that Lisp wears. They force your functional abstractions to be leaky.

Some brilliant wag once summarized the case against continuations by
falling back on Spinal Tap's fine line between stupid and clever.
Continuations start out as brilliant and then the wheels came off, as
per the above. I always assumed that would happen to Cells because they
were so...clever. I digress. Now I am Mr. Web 2.0 thanks to Franz's nice
session management and how am I managing state? With a frickin data
structure one uses to manage state.

Too easy?

Meanwhile Patrick Collison dumped Lisp to do his Lispy Web language in C
why? Because he needed control over the stack. Why did he need control
over the stack? Because he needed continuations. Fortunately he still
made his fortune. Using Ruby.

Moral somewhere.

kxo

Kenny <kentilton@gmail.com> writes:
> Now I am Mr. Web 2.0 thanks to Franz's nice session management and how
> am I managing state? With a frickin data structure one uses to manage
> state.
>
> Too easy?

Yes, there are some words about the "stateless purity of HTTP" and
"making sure things are just as hard as they are with CGI", but I have
delightfully misplaced them.

--
I write stuff at http://failex.blogspot.com/ now. But the post
formatter and themes are terrible for sharing code, the primary
content, so it might go away sooner or later.