Hi Folks,
Want to announce availability of a stable version of TwinLisp:
http://twinlisp.nongnu.org/
TwinLisp is a way of programming Common Lisp in a Java/Python like
syntax without sacrificing any of Lisps strenths and features. TwinLisp
is implemented as a layer, which reads TL code and translates it into
CL code, which is run by a lisp mashine. It is not implemented as
reader macro, since these are limited for our purpose.
Download TwinLisp at http://twinlisp.nongnu.org/download.html
Check documentation at http://twinlisp.nongnu.org/documentation.html
Mikalai wrote:
> Check documentation at http://twinlisp.nongnu.org/documentation.html
I haven't loaded this up yet, but just from your documentation, it
looks like a good job.
At first glance, I think like how the design handles backquote for
macro programming. You use the TwinLisp syntax within the templates,
and it translates to a CL backquote. It seems like a no-nonsense
approach.
Too bad that the comma isn't available for unquotes, huh? (Since it
separates arguments in argument lists, ugh).
I don't like how the backtick and dollar sign aren't "visually
opposite" glyphs, the way ( ) are opposite or ` , are opposite.
Backslash and forward slash wouldn't be bad:
\(foo(/a,/b)+/c) -> `(_+_ (FOO ,A ,B) ,C)
They are kind of like an enlarged, cheesy backtick and comma. To go
with your enlarged and cheesy syntax. Bahahaha.
Cheers ...
Kaz Kylheku wrote:
> Mikalai wrote:
> > Check documentation at http://twinlisp.nongnu.org/documentation.html
>
> I haven't loaded this up yet, but just from your documentation, it
> looks like a good job.
Thanks :) .
>
> At first glance, I think like how the design handles backquote for
> macro programming. You use the TwinLisp syntax within the templates,
> and it translates to a CL backquote. It seems like a no-nonsense
> approach.
>
> Too bad that the comma isn't available for unquotes, huh? (Since it
> separates arguments in argument lists, ugh).
>
> I don't like how the backtick and dollar sign aren't "visually
> opposite" glyphs, the way ( ) are opposite or ` , are opposite.
>
> Backslash and forward slash wouldn't be bad:
>
> \(foo(/a,/b)+/c) -> `(_+_ (FOO ,A ,B) ,C)
>
> They are kind of like an enlarged, cheesy backtick and comma. To go
> with your enlarged and cheesy syntax. Bahahaha.
I looked at a keyboard on my toshiba, and there so many non-alphabetic
symbols. Add usual operators to it. Not enough choice.
But, when in BASH, $ stands exactly for "value-of" thingy. So, I
thought, $ can work as a comma replacement.
Mikalai, I'm truly amased at your talent as a programmer and a lisper.
In order to create TwinLisp you have to be not only very good
programmer, but also understand lisp very vell.
I'm in programming for more than 17 years, all algol-family languages
(c, delphi, java, csharp, python etc) And only recently had chance to
use lisp for work (lispworks).
So i'm a lisp dilettante.
But i must tell you that i love lisp synthax. It is the best thing I
have ever seen in programming, despite my many years of "conventional"
synthax experience.
So unfortunately for me, your wounderfull work will be no use for me.
What a pitty.
Regarding bringing other people to lisp hiding lisp synthax from them,
I think you are mistaken.
It is all-or-nothing deal.
Those who do not like lisp synthax will never use TwinLisp, even if you
give them synthax they prefer. And those who want to use lisp, will
never use TwinLisp, exactly because it is hiding lisp from them.
But i want to see the putcome of this very strange experiment.
Good luck to you.
Vagif Verdi wrote:
> Mikalai, I'm truly amased at your talent as a programmer and a lisper.
> In order to create TwinLisp you have to be not only very good
> programmer, but also understand lisp very vell.
> I'm in programming for more than 17 years, all algol-family languages
> (c, delphi, java, csharp, python etc) And only recently had chance to
> use lisp for work (lispworks).
> So i'm a lisp dilettante.
>
> But i must tell you that i love lisp synthax. It is the best thing I
> have ever seen in programming, despite my many years of "conventional"
> synthax experience.
>
> So unfortunately for me, your wounderfull work will be no use for me.
> What a pitty.
>
> Regarding bringing other people to lisp hiding lisp synthax from them,
> I think you are mistaken.
> It is all-or-nothing deal.
When I thought of a lisp as all-or-nothing deal. You guessed it :) --
I was on the nothing side, deprived of pluses that lisp gives, which
are now available through TL. Missing out some stuff, I was probably
inventing round wheels time-and-time again.
Hey, may be other people shouldn't be thrown onto the same thing. So,
TL is for them.
> Those who do not like lisp synthax will never use TwinLisp, even if you
> give them synthax they prefer. And those who want to use lisp, will
> never use TwinLisp, exactly because it is hiding lisp from them.
I now one person that likes TL - myself. That's a start, don't you
think so?
>
> But i want to see the putcome of this very strange experiment.
> Good luck to you.
Thank you for a good wish.
Well, since I am playing a sales-person role here, I should ask you to
let other people now about TL when you hear them dismissing Lisp. I
have a feeling, that having a career like yours (a lot of non-lisp),
you may know personally many people that do dismiss lisp because of
syntax. Tell 'em about TL.
"Mikalai" <········@yahoo.com> writes:
> Thank you for a good wish.
> Well, since I am playing a sales-person role here, I should ask you to
> let other people now about TL when you hear them dismissing Lisp. I
> have a feeling, that having a career like yours (a lot of non-lisp),
> you may know personally many people that do dismiss lisp because of
> syntax. Tell 'em about TL.
Did you try TL on Python people? How do they receive it? Do they like it?
As I said, non-lisp programmers will probably be your main "customers".
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
Pascal Bourguignon wrote:
> "Mikalai" <········@yahoo.com> writes:
> > Thank you for a good wish.
> > Well, since I am playing a sales-person role here, I should ask you to
> > let other people now about TL when you hear them dismissing Lisp. I
> > have a feeling, that having a career like yours (a lot of non-lisp),
> > you may know personally many people that do dismiss lisp because of
> > syntax. Tell 'em about TL.
>
> Did you try TL on Python people? How do they receive it? Do they like it?
> As I said, non-lisp programmers will probably be your main "customers".
Haven't yet. This list is a prime time for TL PR. But you guessed it
right -- python, ruby, java, C people are the main target. Let's drag
'em to LISP!!!
On Fri, 10 Mar 2006 12:35:38 -0800, Mikalai wrote:
> TwinLisp is a way of programming Common Lisp in a Java/Python like
> syntax without sacrificing any of Lisps strenths and features.
Lisp's syntax, and how it differs from the syntax of Java or Python, is
one of its strongest features. So I would consider this statement to be
false by definition.
Just my opinion.
Cheers,
Bill.
William Bland wrote:
> On Fri, 10 Mar 2006 12:35:38 -0800, Mikalai wrote:
>
> > TwinLisp is a way of programming Common Lisp in a Java/Python like
> > syntax without sacrificing any of Lisps strenths and features.
>
> Lisp's syntax, and how it differs from the syntax of Java or Python, is
> one of its strongest features. So I would consider this statement to be
> false by definition.
>
Experience of TwinLisp shows, that lisps powers can be used with Java's
like syntax.
With documentation, I have compiled a small file (
http://www.nongnu.org/twinlisp/docs/CL-TwLisp%20comparison.txt ), which
compares CL and TL. I have used macros and functions from "On Lisp" and
"Practical CL". Initially, I thought that I will find something which
can be really simple in CL, but difficult in TL. Well, I haven't found
such examples. I would be glad if you provide one.
I claim that on a *technical* merit, CL and TL are the same. Help me to
prove otherwise.
If you are talking that you *personally* feel that lisp syntax is more
convenient, then it is a different matter. TL is not for those who are
happy. TL is for those who are not exactly comfortable with pure lisp
syntax, but would like to use its powers, flexibility of vendors
(unlike Python, Ruby). And if you hear someone saying they do not like
lisps syntax, please, send them to TwinLisp. They will be pleased with
what they'll find.
From: Peter Seibel
Subject: Re: ANN: TwinLisp - a new way of programming in Common Lisp
Date:
Message-ID: <m2k6b2ot5t.fsf@gigamonkeys.com>
"Mikalai" <········@yahoo.com> writes:
> William Bland wrote:
>> On Fri, 10 Mar 2006 12:35:38 -0800, Mikalai wrote:
>>
>> > TwinLisp is a way of programming Common Lisp in a Java/Python like
>> > syntax without sacrificing any of Lisps strenths and features.
>>
>> Lisp's syntax, and how it differs from the syntax of Java or Python, is
>> one of its strongest features. So I would consider this statement to be
>> false by definition.
>>
>
> Experience of TwinLisp shows, that lisps powers can be used with Java's
> like syntax.
> With documentation, I have compiled a small file (
> http://www.nongnu.org/twinlisp/docs/CL-TwLisp%20comparison.txt ), which
> compares CL and TL. I have used macros and functions from "On Lisp" and
> "Practical CL". Initially, I thought that I will find something which
> can be really simple in CL, but difficult in TL. Well, I haven't found
> such examples. I would be glad if you provide one.
Can you show how you'd tackle some of the more complex macros from
PCL? Perhaps the binary data macros from Chapter 24?
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
> Can you show how you'd tackle some of the more complex macros from
> PCL? Perhaps the binary data macros from Chapter 24?
>
> -Peter
Can you copy-and-paste a particular example. I'll work on it.
From: Peter Seibel
Subject: Re: ANN: TwinLisp - a new way of programming in Common Lisp
Date:
Message-ID: <m2fylqos8v.fsf@gigamonkeys.com>
"Mikalai" <········@yahoo.com> writes:
>> Can you show how you'd tackle some of the more complex macros from
>> PCL? Perhaps the binary data macros from Chapter 24?
>>
>> -Peter
>
> Can you copy-and-paste a particular example. I'll work on it.
Here you go.
-Peter
(in-package :cl-user)
(defpackage :com.gigamonkeys.binary-data
(:use :common-lisp :com.gigamonkeys.macro-utilities)
(:export :define-binary-class
:define-tagged-binary-class
:define-binary-type
:read-value
:write-value
:*in-progress-objects*
:parent-of-type
:current-binary-object
:+null+))
(in-package :com.gigamonkeys.binary-data)
(defvar *in-progress-objects* nil)
(defconstant +null+ (code-char 0))
(defgeneric read-value (type stream &key)
(:documentation "Read a value of the given type from the stream."))
(defgeneric write-value (type stream value &key)
(:documentation "Write a value as the given type to the stream."))
(defgeneric read-object (object stream)
(:method-combination progn :most-specific-last)
(:documentation "Fill in the slots of object from stream."))
(defgeneric write-object (object stream)
(:method-combination progn :most-specific-last)
(:documentation "Write out the slots of object to the stream."))
(defmethod read-value ((type symbol) stream &key)
(let ((object (make-instance type)))
(read-object object stream)
object))
(defmethod write-value ((type symbol) stream value &key)
(assert (typep value type))
(write-object value stream))
;;; Binary types
(defmacro define-binary-type (name (&rest args) &body spec)
(with-gensyms (type stream value)
`(progn
(defmethod read-value ((,type (eql ',name)) ,stream &key ,@args)
(declare (ignorable ,@args))
,(type-reader-body spec stream))
(defmethod write-value ((,type (eql ',name)) ,stream ,value &key ,@args)
(declare (ignorable ,@args))
,(type-writer-body spec stream value)))))
(defun type-reader-body (spec stream)
(ecase (length spec)
(1 (destructuring-bind (type &rest args) (mklist (first spec))
`(read-value ',type ,stream ,@args)))
(2 (destructuring-bind ((in) &body body) (cdr (assoc :reader spec))
`(let ((,in ,stream)) ,@body)))))
(defun type-writer-body (spec stream value)
(ecase (length spec)
(1 (destructuring-bind (type &rest args) (mklist (first spec))
`(write-value ',type ,stream ,value ,@args)))
(2 (destructuring-bind ((out v) &body body) (cdr (assoc :writer spec))
`(let ((,out ,stream) (,v ,value)) ,@body)))))
;;; Binary classes
(defmacro define-generic-binary-class (name (&rest superclasses) slots read-method)
(with-gensyms (objectvar streamvar)
`(progn
(eval-when (:compile-toplevel :load-toplevel :execute)
(setf (get ',name 'slots) ',(mapcar #'first slots))
(setf (get ',name 'superclasses) ',superclasses))
(defclass ,name ,superclasses
,(mapcar #'slot->defclass-slot slots))
,read-method
(defmethod write-object progn ((,objectvar ,name) ,streamvar)
(declare (ignorable ,streamvar))
(with-slots ,(new-class-all-slots slots superclasses) ,objectvar
,@(mapcar #'(lambda (x) (slot->write-value x streamvar)) slots))))))
(defmacro define-binary-class (name (&rest superclasses) slots)
(with-gensyms (objectvar streamvar)
`(define-generic-binary-class ,name ,superclasses ,slots
(defmethod read-object progn ((,objectvar ,name) ,streamvar)
(declare (ignorable ,streamvar))
(with-slots ,(new-class-all-slots slots superclasses) ,objectvar
,@(mapcar #'(lambda (x) (slot->read-value x streamvar)) slots))))))
(defmacro define-tagged-binary-class (name (&rest superclasses) slots &rest options)
(with-gensyms (typevar objectvar streamvar)
`(define-generic-binary-class ,name ,superclasses ,slots
(defmethod read-value ((,typevar (eql ',name)) ,streamvar &key)
(let* ,(mapcar #'(lambda (x) (slot->binding x streamvar)) slots)
(let ((,objectvar
(make-instance
,@(or (cdr (assoc :dispatch options))
(error "Must supply :disptach form."))
,@(mapcan #'slot->keyword-arg slots))))
(read-object ,objectvar ,streamvar)
,objectvar))))))
(defun as-keyword (sym) (intern (string sym) :keyword))
(defun normalize-slot-spec (spec)
(list (first spec) (mklist (second spec))))
(defun mklist (x) (if (listp x) x (list x)))
(defun slot->defclass-slot (spec)
(let ((name (first spec)))
`(,name :initarg ,(as-keyword name) :accessor ,name)))
(defun slot->read-value (spec stream)
(destructuring-bind (name (type &rest args)) (normalize-slot-spec spec)
`(setf ,name (read-value ',type ,stream ,@args))))
(defun slot->write-value (spec stream)
(destructuring-bind (name (type &rest args)) (normalize-slot-spec spec)
`(write-value ',type ,stream ,name ,@args)))
(defun slot->binding (spec stream)
(destructuring-bind (name (type &rest args)) (normalize-slot-spec spec)
`(,name (read-value ',type ,stream ,@args))))
(defun slot->keyword-arg (spec)
(let ((name (first spec)))
`(,(as-keyword name) ,name)))
;;; Keeping track of inherited slots
(defun direct-slots (name)
(copy-list (get name 'slots)))
(defun inherited-slots (name)
(loop for super in (get name 'superclasses)
nconc (direct-slots super)
nconc (inherited-slots super)))
(defun all-slots (name)
(nconc (direct-slots name) (inherited-slots name)))
(defun new-class-all-slots (slots superclasses)
"Like all slots but works while compiling a new class before slots
and superclasses have been saved."
(nconc (mapcan #'all-slots superclasses) (mapcar #'first slots)))
;;; In progress Object stack
(defun current-binary-object ()
(first *in-progress-objects*))
(defun parent-of-type (type)
(find-if #'(lambda (x) (typep x type)) *in-progress-objects*))
(defmethod read-object :around (object stream)
(declare (ignore stream))
(let ((*in-progress-objects* (cons object *in-progress-objects*)))
(call-next-method)))
(defmethod write-object :around (object stream)
(declare (ignore stream))
(let ((*in-progress-objects* (cons object *in-progress-objects*)))
(call-next-method)))
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel wrote:
> "Mikalai" <········@yahoo.com> writes:
>
> >> Can you show how you'd tackle some of the more complex macros from
> >> PCL? Perhaps the binary data macros from Chapter 24?
> >>
> >> -Peter
> >
> > Can you copy-and-paste a particular example. I'll work on it.
>
> Here you go.
>
> -Peter
OK. Here we go, word by word.
>
> (in-package :cl-user)
inside :&cl-user
>
> (defpackage :com.gigamonkeys.binary-data
> (:use :common-lisp :com.gigamonkeys.macro-utilities)
> (:export :define-binary-class
> :define-tagged-binary-class
> :define-binary-type
> :read-value
> :write-value
> :*in-progress-objects*
> :parent-of-type
> :current-binary-object
> :+null+))
package :&com.gigamonkey.binary-data {
:&use { :&comm-lisp, :&com.gigamonkeys.macro-utilities }
:export { :&define-binary-class
:&define-tagged-binary-class
:&define-binary-type
:&read-value
:&write-value
:&*in-progress-objects*
:&parent-of-type
:¤t-binary-object
:&+null+ }}
>
> (in-package :com.gigamonkeys.binary-data)
inside :&com.gigamonkeys.binary-data
>
> (defvar *in-progress-objects* nil)
var(&*in-progress-objects* = nil)
>
> (defconstant +null+ (code-char 0))
const(&+null+ = &code-char(0))
>
> (defgeneric read-value (type stream &key)
> (:documentation "Read a value of the given type from the stream."))
defgeneric(&read-value, .(type,stream,&&key)
.(:documentation="Read a value of the given type from
the stream."))
Note: TL has a special syntax for defmethod (meth), but not yet for
defgeneric. Simply because I have been using meth, and never felt a
need to introduce defgeneric. But, I think, I should :) .
>
> (defgeneric write-value (type stream value &key)
> (:documentation "Write a value as the given type to the stream."))
defgeneric(&write-value, .(type,stream,value,&&key)
.(:documentation="Write a value as the given type to
the stream."))
>
> (defgeneric read-object (object stream)
> (:method-combination progn :most-specific-last)
> (:documentation "Fill in the slots of object from stream."))
defgeneric(&read-object, .(object,stream)
.(:&method-combination,progn,:&most-specific-last)
.(:documentation="Write a value as the given type to
the stream."))
>
> (defgeneric write-object (object stream)
> (:method-combination progn :most-specific-last)
> (:documentation "Write out the slots of object to the stream."))
defgeneric(&write-object, .(object,stream)
.(:&method-combination,progn,:&most-specific-last)
.(:documentation="Write out the slots of object to the
stream."))
>
> (defmethod read-value ((type symbol) stream &key)
> (let ((object (make-instance type)))
> (read-object object stream)
> object))
meth &read-value (.(type,symbol),stream,&&key) {
object = type.new()
&read-object(object,stream)
object}
Notice: a convenient new, used for objects, structures and conditions.
It is not a macro, some implicit let will be inserted.
>
> (defmethod write-value ((type symbol) stream value &key)
> (assert (typep value type))
> (write-object value stream))
meth &write-value (.(type,symbol),stream,value,&&key) {
assert(value.typep(type))
&write-object(value,stream) }
Notice the way I call typep, I find it nicer to use this way for typep
(check TL docs for other ways of function calling).
>
This is a first part. I am afraid of loosing a thing, so sending you
this and starting the rest...
"Mikalai" <········@yahoo.com> writes:
>> (defpackage :com.gigamonkeys.binary-data
>> (:use :common-lisp :com.gigamonkeys.macro-utilities)
>> (:export :define-binary-class
>> :define-tagged-binary-class
>> :define-binary-type
>> :read-value
>> :write-value
>> :*in-progress-objects*
>> :parent-of-type
>> :current-binary-object
>> :+null+))
> package :&com.gigamonkey.binary-data {
> :&use { :&comm-lisp, :&com.gigamonkeys.macro-utilities }
> :export { :&define-binary-class
> :&define-tagged-binary-class
> :&define-binary-type
> :&read-value
> :&write-value
> :&*in-progress-objects*
> :&parent-of-type
> :¤t-binary-object
> :&+null+ }}
Frankly, I do not see the point. In the code chunks above the Lisp
version has 6 parens, while the TwinLisp version has instead 6 braces
and on top of it a lot of ampersands.
Same thing is true for the examples on your site: lots of braces, dots,
dollar signs etc. Looks ugly.
The S-expression syntax gives Lisp a special feel of elegance, harmony
and natural flow. In comparison to it the Java/C/Perl etc. languages
look like broken, chaotic splashes of random characters.
--
vedm
vedm wrote:
> "Mikalai" <········@yahoo.com> writes:
>
> Frankly, I do not see the point. In the code chunks above the Lisp
> version has 6 parens, while the TwinLisp version has instead 6 braces
> and on top of it a lot of ampersands.
And Java will have close to the same number. *Some* people like to
write foo() instead (foo). That's all. That is people's concern, not
the number of brackets.
>
> Same thing is true for the examples on your site: lots of braces, dots,
> dollar signs etc. Looks ugly.
You see dollar signs only in macro definitions. CL macros ain't simple
either. The rule of a thumb is that there is no Santa Claus. And if you
want to pack a lot (as in macros) and not to type a lot, `',@ and all
other guys come in quite handy. This complexity in macros has to be
typied in. And the shortest way I know is like CL. That is why TL
mimics CL in this.
>
> The S-expression syntax gives Lisp a special feel of elegance, harmony
> and natural flow. In comparison to it the Java/C/Perl etc. languages
> look like broken, chaotic splashes of random characters.
Does the word "feel" subjective here?
TL is about choice. A choice of a different syntax for the same old
CL. Some like old syntax, some like new. And if one is not fond of one
syntax he (she) may choose another, without necessarily switching from
CLisp to Python.
vedm wrote:
> Frankly, I do not see the point. In the code chunks above the Lisp
> version has 6 parens, while the TwinLisp version has instead 6 braces
> and on top of it a lot of ampersands.
I do see the point, but I find the ampersands to be a huge turnoff.
A better design would be to just collect identifier tokens in
something like the normal Lisp way, allowing dashes and other
characters. Or at least allow the most commonly used non-alphabetic
glyphs to be symbol constituents without escaping, so that integrating
with Lisp code would be seamless.
If you have to escape identifiers just because they contain -, + or *,
that's terrible. I'd almost call it a "non-starter".
I'd much rather live with the "restriction" that z = x - y must not
be written
z = x-y.
>If you have to escape identifiers just because they contain -, + or *,
>that's terrible. I'd almost call it a "non-starter".
>
>I'd much rather live with the "restriction" that z = x - y must not
>be written
>z = x-y.
Take a look at code of TL (check CVS as well). TL is written in itself
(it was bootstrapped from Python). Well, there aren't many &'s in the
code. Why? Because what you see here is a demonstration of one-to-one
correspondence. So, I kept name-like-this, which needs &. The real
production TL code does not suffer from this, because you do not
introduce too many names with dashes on the first place.
Mikalai wrote:
> >If you have to escape identifiers just because they contain -, + or *,
> >that's terrible. I'd almost call it a "non-starter".
> >
> >I'd much rather live with the "restriction" that z = x - y must not
> >be written
> >z = x-y.
>
> Take a look at code of TL (check CVS as well). TL is written in itself
> (it was bootstrapped from Python).
Why would you bootstrap a CL syntax using Python?
> Well, there aren't many &'s in the
> code. Why? Because what you see here is a demonstration of one-to-one
> correspondence. So, I kept name-like-this, which needs &. The real
> production TL code does not suffer from this, because you do not
> introduce too many names with dashes on the first place.
So the goal is not CL interoperability then, since the standard CL
library and third-party ones liberally use identifiers with dashes and
stars in them.
TL is hostile toward these identifiers by requiring an ugly escape
symbol.
Why?
Kaz Kylheku wrote:
> Mikalai wrote:
> > >If you have to escape identifiers just because they contain -, + or *,
> > >that's terrible. I'd almost call it a "non-starter".
> > >
> > >I'd much rather live with the "restriction" that z = x - y must not
> > >be written
> > >z = x-y.
> >
> > Take a look at code of TL (check CVS as well). TL is written in itself
> > (it was bootstrapped from Python).
>
> Why would you bootstrap a CL syntax using Python?
I first wrote it in Python. That's all. In fact, I haven't written *a
line* of CL code to make TL happen (except playing at CL's repl).
Now Python is not needed at all to use TL. And CVS contains python
code only as a hystorical curiousity.
>
> > Well, there aren't many &'s in the
> > code. Why? Because what you see here is a demonstration of one-to-one
> > correspondence. So, I kept name-like-this, which needs &. The real
> > production TL code does not suffer from this, because you do not
> > introduce too many names with dashes on the first place.
>
> So the goal is not CL interoperability then, since the standard CL
> library and third-party ones liberally use identifiers with dashes and
> stars in them.
No-no. &-ed names are included to provide *full* interoperability with
CL.
>
> TL is hostile toward these identifiers by requiring an ugly escape
> symbol.
>
> Why?
Do you recall a mythical figure of a half-man, half-horse?
Just think. In the syntax with use of almost all non-alphanumeric
characters for some non-trivial purposes, what would you escape:
operators that occur almost on every line, or few names, for which one
can even use his own synonyms?
>Now, in general, writting all of this, I haven't found any issues, that
>I haven't had in writting examples in the file in TL's documentation
>(modulus absence in TL of some special structures, which can be added
>if needed), i.e. there are now *foundamental* problem with having
>macros in non-lisp syntax.
this reades, no *foundamental* problem with having macros in non-lisp
syntax.
From: Peter Seibel
Subject: Re: ANN: TwinLisp - a new way of programming in Common Lisp
Date:
Message-ID: <m2mzfxfvo8.fsf@gigamonkeys.com>
"Mikalai" <········@yahoo.com> writes:
>>Now, in general, writting all of this, I haven't found any issues, that
>>I haven't had in writting examples in the file in TL's documentation
>>(modulus absence in TL of some special structures, which can be added
>>if needed), i.e. there are now *foundamental* problem with having
>>macros in non-lisp syntax.
>
> this reades, no *foundamental* problem with having macros in non-lisp
> syntax.
So what do "calls" to DEFINE-BINARY-TYPE and DEFINE-BINARY-CLASS look like?
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
> So what do "calls" to DEFINE-BINARY-TYPE and DEFINE-BINARY-CLASS look like?
Recall definition:
mac &define-binary-class(name,.(*superclasses),slots) { .... }
.() in lambda stands for inner lambda list (check TL docs), so we do a
call with it:
&define-binary-class(name, .(superclass1,superclass2, ...), slots)
Thats it. The DEFINE-BINARY-TYPE will be of the same form, if it needs
inner lambda lists.
From: Peter Seibel
Subject: Re: ANN: TwinLisp - a new way of programming in Common Lisp
Date:
Message-ID: <m2irqleyr1.fsf@gigamonkeys.com>
"Mikalai" <········@yahoo.com> writes:
>> So what do "calls" to DEFINE-BINARY-TYPE and DEFINE-BINARY-CLASS look like?
> Recall definition:
> mac &define-binary-class(name,.(*superclasses),slots) { .... }
>
> .() in lambda stands for inner lambda list (check TL docs), so we do a
> call with it:
>
> &define-binary-class(name, .(superclass1,superclass2, ...), slots)
Okay. So can you translate this one:
(define-binary-class id3-tag ()
((identifier (iso-8859-1-string :length 3))
(major-version u1)
(revision u1)
(flags u1)
(size id3-tag-size)))
(I don't doubt you can, I just wonder what it looks like.)
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
>Okay. So can you translate this one:
>
> (define-binary-class id3-tag ()
> ((identifier (iso-8859-1-string :length 3))
> (major-version u1)
> (revision u1)
> (flags u1)
> (size id3-tag-size)))
>
>(I don't doubt you can, I just wonder what it looks like.)
&define-binary-class(&id3-tag,~[]
.(.(identifier,~(&iso-8859-1-string,:length,3))
.(&major-version,u1)
.(revision,u1)
.(flags,u1)
.(size,&id3-tag-size)))
It was a blind translation. Now, introduce a little hint in notation:
&define-binary-class(&id3-tag,~[]
.(.(identifier,~(&iso-8859-1-string,:length,3))
.(&major-version=u1)
.(revision=u1)
.(flags=u1)
.(size=&id3-tag-size)))
If that is what was intended. You wrote this macro for consumption in
CL. In TL, you would've probably skipped lambda lists around flags,
size, again, if my guess with = is correct.
On 2006-03-11 11:51:12 -0500, "Mikalai" <········@yahoo.com> said:
>> Okay. So can you translate this one:
>>
>> (define-binary-class id3-tag ()
>> ((identifier (iso-8859-1-string :length 3))
>> (major-version u1)
>> (revision u1)
>> (flags u1)
>> (size id3-tag-size)))
>>
>> (I don't doubt you can, I just wonder what it looks like.)
[snip]
> &define-binary-class(&id3-tag,~[]
>
> .(.(identifier,~(&iso-8859-1-string,:length,3))
> .(&major-version=u1)
> .(revision=u1)
> .(flags=u1)
> .(size=&id3-tag-size)))
I honestly fail to see how this is a win in any way (aprart from the
purely political one of "all expressions do not need to begin with an
open paren")
The lisp call has 9 pairs of parens and 1 colon; the twinlisp call has
8 pairs of parens plus 1 pair of square brackets, plus 6 periods, plus
5 ampersands, plus 2 tildes, plus 4 equal signs, plus 4 commas, plus 1
colon.
So, given that fewer is better we have:
lisp: 19
twinlisp: 40
which is to say, twinlisp requires more than twice as much punctuation.
How is this an improvement?
Raffael Cavallaro wrote:
> On 2006-03-11 11:51:12 -0500, "Mikalai" <········@yahoo.com> said:
>
> >> Okay. So can you translate this one:
> >>
> >> (define-binary-class id3-tag ()
> >> ((identifier (iso-8859-1-string :length 3))
> >> (major-version u1)
> >> (revision u1)
> >> (flags u1)
> >> (size id3-tag-size)))
> >>
> >> (I don't doubt you can, I just wonder what it looks like.)
>
> [snip]
>
> > &define-binary-class(&id3-tag,~[]
> >
> > .(.(identifier,~(&iso-8859-1-string,:length,3))
> > .(&major-version=u1)
> > .(revision=u1)
> > .(flags=u1)
> > .(size=&id3-tag-size)))
>
>
> I honestly fail to see how this is a win in any way (aprart from the
> purely political one of "all expressions do not need to begin with an
> open paren")
>
> The lisp call has 9 pairs of parens and 1 colon; the twinlisp call has
> 8 pairs of parens plus 1 pair of square brackets, plus 6 periods, plus
> 5 ampersands, plus 2 tildes, plus 4 equal signs, plus 4 commas, plus 1
> colon.
I think, I have already mentioned it in this thread.
a) some people want to write foo() not (foo). The number of characters
doesn't matter.
b) when you design an API to consume in *heavy* s-expression, then the
best way is to *use* s-expression, provided as ~()'s or as inner lambda
lists via .()'s. Take a look at TL production code - TL itself. It'll
look nicer, because API was not designed "exclusively" for s-exps.
c) look for &s in production code, again. What you see hear is a very
heavy (thanks, Peter) lisp stuff from a lisp textbook.
d) Doesn't CL has a colon? Didn't you see that TL uses it for the same
purpose as CL?
e) Check docs about []'s. You'll see how they *do save* you typing.
f) = can be placed for readability and hint a reader. But I have shown
two alternatives in the original post, in case = where not exactly by
writter's wish.
g) Check the docs. Comma acts as a separator. So in CL you need periods
instead.
>
> So, given that fewer is better we have:
>
> lisp: 19
> twinlisp: 40
Now, take this number *together* with point (a-g).
>
> which is to say, twinlisp requires more than twice as much punctuation.
>
> How is this an improvement?
Improvement as in ability to have an *alternative* syntax.
I have *never* said, you'll type less characters.
And again, check points (a-g) above.
On 2006-03-13 11:51:58 -0500, "Mikalai" <········@yahoo.com> said:
> I think, I have already mentioned it in this thread.
> a) some people want to write foo() not (foo).
This is an arbitrary preference. It should be indulged only if the
resulting syntax doesn't entail huge cognitive costs.
> The number of characters
> doesn't matter.
The number of characters matters when indulging this silly preference
entails typing *twice as much*!
Just as importantly, the number of punctuation marks used is 4 times as
great. This introduces a much larger cognitive load on the programmer
who must remember the proper placement and type from among 8 different
punctuation marks. All this just to have foo() instead of (foo). How
foolish() - (pun intended)
Raffael Cavallaro wrote:
> On 2006-03-13 11:51:58 -0500, "Mikalai" <········@yahoo.com> said:
>
> > I think, I have already mentioned it in this thread.
> > a) some people want to write foo() not (foo).
>
> This is an arbitrary preference. It should be indulged only if the
> resulting syntax doesn't entail huge cognitive costs.
If it is not *your* preference, it is not arbitrary.
>
> > The number of characters
> > doesn't matter.
>
> The number of characters matters when indulging this silly preference
> entails typing *twice as much*!
You have ignored points, that will change your statistics.
You have ignored points showing how this is not a common example.
If you insist on extrapolating your statement on entire TL, please
reconsile your statement with the following example:
TL:
a=3
CL:
(setf a 3)
CL -- 10 characters, TL -- 3 characters, so CL should have *three times
as much* characters to type :) .
>
> Just as importantly, the number of punctuation marks used is 4 times as
> great. This introduces a much larger cognitive load on the programmer
I assume that my fellow programmers are not dumb monkeys, and they
will be OK
·········@gmail.com wrote:
>
> How does TL handle setf-expansions/patterns?
>
If you want to define a (setf foo) function or method, you use word
setter:
def setter foo ...
meth setter foo ...
On 2006-03-15 09:39:09 -0500, "Mikalai" <········@yahoo.com> said:
> You have ignored points, that will change your statistics.
> You have ignored points showing how this is not a common example.
> If you insist on extrapolating your statement on entire TL, please
> reconsile your statement with the following example:
> TL:
> a=3
> CL:
> (setf a 3)
> CL -- 10 characters, TL -- 3 characters, so CL should have *three times
> as much* characters to type :) .
This is a one line example. Longer examples are more representative.
Longer examples suggest that using twinlisp entails remembering the
correct use of a half dozen or more special syntactic markers where
common lisp most often uses just parentheses and the odd colon.
>>
>> Just as importantly, the number of punctuation marks used is 4 times as
>> great. This introduces a much larger cognitive load on the programmer
> I assume that my fellow programmers are not dumb monkeys, and they
> will be OK
No, they are human beings who are known to have distinct limits to
working memory. The evolution of programming languages is in the
direction of freeing the programmer to focus his mental assets on the
problem by relieving him of the burden of pointless bookkeeping ("which
do I want here, a period, a comma, an ampersand, a tilde ...") The
simplicity of common lisp's syntax is one of its strengths. Sacrificing
this simply to attract those used to a different, more complex syntax,
or to stop yourself from accidentally typing foo() at a repl is a
monumental exercise in futility. You won't lure these others to lisp
with algol syntax. Dylan proved that pretty definitively - and yes I'm
aware that Dylan wasn't originally developed with algol syntax, but
Apple did ultimately try to push the language that way as a mainstream
replacement for C/C++ as used by application developers (I was one of
the seed sites).
As for typing foo() at the repl, when you use lisp and scheme long
enough you'll find yourself making the opposite error - trying to get a
java or c compiler to accept (foo x).
I remember seeing a panel discussion in which, iirc, David Moon said
something along the lines of "any monkey can just hack code - the point
is, is what you're coding worth doing? To answer this you have to think
long and hard about the problem first." Twinlisp impresses me as a
great deal of coding effort undertaken without first determining if it
was actually worthwhile to do it.
Raffael Cavallaro wrote:
> On 2006-03-15 09:39:09 -0500, "Mikalai" <········@yahoo.com> said:
>
> > You have ignored points, that will change your statistics.
> > You have ignored points showing how this is not a common example.
> > If you insist on extrapolating your statement on entire TL, please
> > reconsile your statement with the following example:
> > TL:
> > a=3
> > CL:
> > (setf a 3)
> > CL -- 10 characters, TL -- 3 characters, so CL should have *three times
> > as much* characters to type :) .
>
> This is a one line example. Longer examples are more representative.
> Longer examples suggest that using twinlisp entails remembering the
> correct use of a half dozen or more special syntactic markers where
> common lisp most often uses just parentheses and the odd colon.
>
> >>
> >> Just as importantly, the number of punctuation marks used is 4 times as
> >> great. This introduces a much larger cognitive load on the programmer
> > I assume that my fellow programmers are not dumb monkeys, and they
> > will be OK
>
> No, they are human beings who are known to have distinct limits to
> working memory. The evolution of programming languages is in the
> direction of freeing the programmer to focus his mental assets on the
> problem by relieving him of the burden of pointless bookkeeping ("which
> do I want here, a period, a comma, an ampersand, a tilde ...") The
> simplicity of common lisp's syntax is one of its strengths. Sacrificing
> this simply to attract those used to a different, more complex syntax,
> or to stop yourself from accidentally typing foo() at a repl is a
> monumental exercise in futility. You won't lure these others to lisp
> with algol syntax. Dylan proved that pretty definitively - and yes I'm
> aware that Dylan wasn't originally developed with algol syntax, but
> Apple did ultimately try to push the language that way as a mainstream
> replacement for C/C++ as used by application developers (I was one of
> the seed sites).
>
> As for typing foo() at the repl, when you use lisp and scheme long
> enough you'll find yourself making the opposite error - trying to get a
> java or c compiler to accept (foo x).
>
> I remember seeing a panel discussion in which, iirc, David Moon said
> something along the lines of "any monkey can just hack code - the point
> is, is what you're coding worth doing? To answer this you have to think
> long and hard about the problem first." Twinlisp impresses me as a
> great deal of coding effort undertaken without first determining if it
> was actually worthwhile to do it.
I totally agree that *you* do not need TL. That is *why* it's not you
who wrote it.
Raffael Cavallaro wrote:
> On 2006-03-15 09:39:09 -0500, "Mikalai" <········@yahoo.com> said:
>
> > You have ignored points, that will change your statistics.
> > You have ignored points showing how this is not a common example.
> > If you insist on extrapolating your statement on entire TL, please
> > reconsile your statement with the following example:
> > TL:
> > a=3
> > CL:
> > (setf a 3)
> > CL -- 10 characters, TL -- 3 characters, so CL should have *three times
> > as much* characters to type :) .
>
> This is a one line example. Longer examples are more representative.
> Longer examples suggest that using twinlisp entails remembering the
> correct use of a half dozen or more special syntactic markers where
> common lisp most often uses just parentheses and the odd colon.
>
> >>
> >> Just as importantly, the number of punctuation marks used is 4 times as
> >> great. This introduces a much larger cognitive load on the programmer
> > I assume that my fellow programmers are not dumb monkeys, and they
> > will be OK
>
> No, they are human beings who are known to have distinct limits to
> working memory. The evolution of programming languages is in the
> direction of freeing the programmer to focus his mental assets on the
> problem by relieving him of the burden of pointless bookkeeping ("which
> do I want here, a period, a comma, an ampersand, a tilde ...") The
> simplicity of common lisp's syntax is one of its strengths. Sacrificing
> this simply to attract those used to a different, more complex syntax,
> or to stop yourself from accidentally typing foo() at a repl is a
> monumental exercise in futility. You won't lure these others to lisp
> with algol syntax. Dylan proved that pretty definitively - and yes I'm
> aware that Dylan wasn't originally developed with algol syntax, but
> Apple did ultimately try to push the language that way as a mainstream
> replacement for C/C++ as used by application developers (I was one of
> the seed sites).
>
> As for typing foo() at the repl, when you use lisp and scheme long
> enough you'll find yourself making the opposite error - trying to get a
> java or c compiler to accept (foo x).
>
> I remember seeing a panel discussion in which, iirc, David Moon said
> something along the lines of "any monkey can just hack code - the point
> is, is what you're coding worth doing? To answer this you have to think
> long and hard about the problem first." Twinlisp impresses me as a
> great deal of coding effort undertaken without first determining if it
> was actually worthwhile to do it.
Since you have mentioned D.Moon, look at his opinion about s-expr:
http://lispmeister.com/blog/lisp-news/moon-on-s-expressions.html
On 2006-03-16 12:00:17 -0500, "Mikalai" <········@yahoo.com> said:
> Since you have mentioned D.Moon, look at his opinion about s-expr:
Yes, I'm aware of Dave Moon's objections to s-expressions though I
don't necessarily agree with them all [1]; he was talking about using
s-expressions as an *internal* compiler representation as a separate
issue from using them as a surface syntax. Note that his response to
this situation was to contribute to the creation of a new language,
Dylan, which does not use s-expressions either for syntax or internal
representation. I was a Dylan user before I was a lisp programmer - I
actually came to MCL as a result of the failure of the Apple Dylan
project. So I have no objection at all to m-expressions or algol syntax
per se. I do object to bolting an alien syntax on to an existing
language that was implicitly designed to work with a very different
syntax.
As a result, note that Dylan programs don't begin to approach the level
of dire ugliness of some of the twinlisp examples you provided. This is
largely because the algol syntax of Dylan was carefully thought out as
an integral part of a new and different language compiler, not a
bolt-on hack to an existing language whose whole design assumes
s-expression syntax.
Finally, the current status of Dylan (I once quipped that Dylan was an
acronym for "Dying Language"), a much more mature algol syntax language
in the lisp family than twinlisp, clearly shows that algol syntax is
not going to bring users of other algol syntax languages to the lisp
family. So we are left with your accidentally typing foo() at the repl
as the sole reason for the existence of the very impressive, very
large, but ultimately, very ugly hack that is twinlisp.
In other words, your time would have been much better spent
contributing to the gwydion dylan project, or, alternatively, just
getting used to common lisp's s-expression syntax.
[1] In particular, his three objections:
A. "The (function . arguments) notation is not extensible. In other
words, there isn't any place to attach additional annotations if some
should be required."
B. "Representing code as linked lists of conses and symbols does not
lead to the fastest compilation speed. More generally, why should the
language specification dictate the internal representation to be used
by the compiler? That's just crazy!"
C. "Symbols are not the right representation of identifiers. This
becomes obvious as soon as you try to design a good hygienic macro
system."
are valid criticisms, and good reasons to either:
a) design a whole new language that doesn't do these things
b) use syntax objects for a hygienic macro system instead of
s-expressions and symbols (see Andre van Tonder's SRFI 72 for example)
but not good reasons to bolt algol syntax onto a language whose
standard *does* assume s-expression syntax.
Finally, note that Moon's objections are those of a language
implementor, and don't really speak to the ease of use of s-expression
surface syntax. I think that Andre van Tonder has shown with his
hygienic macros that you can have your cake (s-expression syntax,
procedural macros) and eat it too (hygiene, referential transparency,
optional capture).
"Mikalai" <········@yahoo.com> writes:
> If you are talking that you *personally* feel that lisp syntax is more
> convenient, then it is a different matter. TL is not for those who are
> happy. TL is for those who are not exactly comfortable with pure lisp
> syntax, but would like to use its powers, flexibility of vendors
> (unlike Python, Ruby). And if you hear someone saying they do not like
> lisps syntax, please, send them to TwinLisp. They will be pleased with
> what they'll find.
This is clear. That's why it's useless to advocate TwinLisp on c.l.l.
Here we like the parentheses.
I'd advise to rename it to avoid frightening the others with that
"Lisp" substring, and to advocate it on comp.lang.python,
comp.lang.ruby, comp.lang.java, etc. Sell the macros!
I see one "little" problem though:
; (Assuming I get the syntax straight)
mac p(form) {
`progn(·@mapcan(lambda(subform){list(`print('$subform) subform)},rest(form)))}
; Explain the difference in macro expansions between:
p(progn{1+2 print("Hello")})
p(progn{a=1+2 print(a)})
Since it seems that progn{...} produces
either (progn ...)
or (progn (let ...)),
it's a little hairy.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Grace personified,
I leap into the window.
I meant to do that.
Pascal Bourguignon wrote:
> "Mikalai" <········@yahoo.com> writes:
> > If you are talking that you *personally* feel that lisp syntax is more
> > convenient, then it is a different matter. TL is not for those who are
> > happy. TL is for those who are not exactly comfortable with pure lisp
> > syntax, but would like to use its powers, flexibility of vendors
> > (unlike Python, Ruby). And if you hear someone saying they do not like
> > lisps syntax, please, send them to TwinLisp. They will be pleased with
> > what they'll find.
>
> This is clear. That's why it's useless to advocate TwinLisp on c.l.l.
> Here we like the parentheses.
There are new-comers here. Do all new-comers to lisp like them? Myself,
I felt relieved to typing something like python, adding a dose of
functional language (loops return results, etc.), using lexical and
dynamic variables, and writting macros, where needed. Something tells
me, that I am not alone.
I have seen that many old-timers are annoyed by people complaining
about ()'s. From now on, please send them to TL's site, so that they do
not waste you time.
>
> I'd advise to rename it to avoid frightening the others with that
> "Lisp" substring, and to advocate it on comp.lang.python,
> comp.lang.ruby, comp.lang.java, etc. Sell the macros!
>
It will be unfare. Syntax is a thin layer. The rest is proved in years
CL implementation on a base.
Initially, I thought about putting more python-like runtime things. But
then I realized one truth: "Let Lisp be Lisp". The rest is on the
surface. The result is better this way.
>
> I see one "little" problem though:
>
> ; (Assuming I get the syntax straight)
> mac p(form) {
> `progn(·@mapcan(lambda(subform){list(`print('$subform) subform)},rest(form)))}
>
> ; Explain the difference in macro expansions between:
>
> p(progn{1+2 print("Hello")})
> p(progn{a=1+2 print(a)})
>
>
> Since it seems that progn{...} produces
> either (progn ...)
> or (progn (let ...)),
> it's a little hairy.
>
Take a look at
http://www.nongnu.org/twinlisp/docs/TwinLisp%20for%20lisp%20users.html#ScopeOfVars
If translator does not recognizes a variable as existing one, it will
"let" new lexical variable for you. Unless you turn this behaviour off.
Talking about implicit introduction of variables, one may recall
"Lessons of Arc". In macro definitions, new variables are not created -
they have to be explicitly "let". Implicit vars do not work nicely with
defining macros. In all other places - this is a convenience. TL does
not take a black-and-white approach to this matter, but rather allows
implicit vars in "OK" places.
Also take a look at
http://www.nongnu.org/twinlisp/docs/TwinLisp%20for%20lisp%20users.html#CallFuncMacs
to see the difference between calling something foo(a,b), foo{a,b} or
foo(a){b}
Mikalai wrote:
> Pascal Bourguignon wrote:
> > "Mikalai" <········@yahoo.com> writes:
> > I'd advise to rename it to avoid frightening the others with that
> > "Lisp" substring, and to advocate it on comp.lang.python,
> > comp.lang.ruby, comp.lang.java, etc. Sell the macros!
> >
> It will be unfare. Syntax is a thin layer. The rest is proved in years
> CL implementation on a base.
I thnk Pascal's idea deserves some consideration here and shouldn't be
dismissed so casually. What if you just called it Twin?
You can sucker more people into looking at it if the L word doesn't
appear anywhere. And there are pointy-haired-bosses in the world whose
only contact with computer science was failing some undergraduate
course that used some kind of Lisp. :)
The point is that people will make assumptions about your project
without even looking at it if you use the word Lisp in its name.
On Fri, 10 Mar 2006 15:53:57 -0800, Kaz Kylheku wrote:
>
> I thnk Pascal's idea deserves some consideration here and shouldn't be
> dismissed so casually. What if you just called it Twin?
>
> You can sucker more people into looking at it if the L word doesn't
> appear anywhere. And there are pointy-haired-bosses in the world whose
> only contact with computer science was failing some undergraduate
> course that used some kind of Lisp. :)
>
> The point is that people will make assumptions about your project
> without even looking at it if you use the word Lisp in its name.
That didn't seem to help Dylan.
Matt
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
>> The point is that people will make assumptions about your project
>> without even looking at it if you use the word Lisp in its name.
>
>That didn't seem to help Dylan.
>
>Matt
If one adds macros to Python, may will call it lisp (ala P.Graham)
anyway.
On another hand, programming in TL I lookup standard functions in
HyperSpec. I cannot hide TL's lisp nature.
From: Pascal Costanza
Subject: Re: ANN: TwinLisp - a new way of programming in Common Lisp
Date:
Message-ID: <47fbueFer117U1@individual.net>
Matthew D Swank wrote:
> On Fri, 10 Mar 2006 15:53:57 -0800, Kaz Kylheku wrote:
>
>>I thnk Pascal's idea deserves some consideration here and shouldn't be
>>dismissed so casually. What if you just called it Twin?
>>
>>You can sucker more people into looking at it if the L word doesn't
>>appear anywhere. And there are pointy-haired-bosses in the world whose
>>only contact with computer science was failing some undergraduate
>>course that used some kind of Lisp. :)
>>
>>The point is that people will make assumptions about your project
>>without even looking at it if you use the word Lisp in its name.
>
> That didn't seem to help Dylan.
Arguments along the lines of "xyz failed in the past" don't make a lot
of sense. To some people, Lisp also failed in the past, and this doesn't
mean anything either.
Personally, I don't like the idea of TwinLisp. As Peter tries to make
clear, there will also be cases where the translation of CL constructs
to TL won't work, for example, when symbols in CL include what looks
like TL constructs.
Nevertheless, it might work for some people, at least as a first step
towards the Real Thing (tm).
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza wrote:
> Personally, I don't like the idea of TwinLisp. As Peter tries to make
> clear, there will also be cases where the translation of CL constructs
> to TL won't work, for example, when symbols in CL include what looks
> like TL constructs.
What I don't like is the implementation, as it makes many decisions
about what should be done in that way, e.g. what varnames are illegal
and which character is user for what.
On the other hand, I do like its basic idea, that is transforming the
S-exps into "something else" to make it more readable for java-hackers
or other groups. You took clumsy M-exps here, but it doesn't have to be.
I guess most people, even being advanced lisp hackers, still prefer
reading "6 - a*b" over "(- 6 (* a b))" - I would even like to remove the
'*'. Of course, they gladly take this drawback in order to have all the
cool stuff.
Actually, I'm already thinking about this for quite a long time, and my
ideas are as follows:
-get rid of ascii...
-represent the code as lists internally, as usual. Don't compile
completely entered code into it afterwards, but (if it's entered in
another way - I'm not sure about input yet...), do this "live" while the
programmer is typing.
-each part of the program, that is function calls, symbols and so on may
have its own "presentation function" that draws it on the screen. For
example, in a math package, the code "(integral #'my-func :start 'x :end
pi)" could be defined to be printed exactly like latex-output as
mathematicians expect.
-have a default way to present things - if you like, this can be parens,
whitespace indentation, tree view or whatever.
-give everyone the ability to create new viewing schemes. For example,
if you're a clever designer and want to draw in people from the dark
side, you might be able to have it look **exactly** like java (I'm
getting a headache thinking of that, though). Parts of ruby's way might
be more interesting...
I guess the cracking point is about how to type programs with this.
Maybe you need a view showing the syntax tree for better navigation.
What do you think of that?
Regards,
Benjamin
Incidentally, the Lisp dialect that first introduced me to Lisp is a
language called Skill, developed by Cadence Design Systems, which
normally creates electronic design tools (design of integrated
circuits, simulation of circuits, etc.). In our office we use Skill as
a scripting language (for example, to automatically perform a series of
simulations with different temperatures/voltages/processes), while I've
hacked bits of the CDS development system with Skill (for example, to
automate changing of device parameters).
Skill is a real Lisp: it uses lists to represent code. In particular,
the following is valid Skill code:
procedure( foo(x)
let( (y)
y=x+3
y
);let
);procedure foo
Skill even prints all lists in a manner similar to the above. In fact,
the above code is equivalent to:
(procedure (foo x)
(let (y)
(setq y (plus x 3))
y))
While most of the other engineers in my line of work find the former
more comfortable, I'm actually more comfortable with the latter. The
sheer POWER of them parantheses makes me type x+a*b as (plus x (times a
b)) even if it's so much longer... {gollum mode}my paranthesesss...
@Benjamin Teuber
regarding your last few sentences... hmm. If Paul Graham's conjecture
that newer and newer languages approach Lisp, then wouldn't that mean
that someday all languages would be *gasp* syntactic sugar on Lisp??
Maybe we should write a "any-language"-to-lisp compiler!
Benjamin Teuber wrote:
> Pascal Costanza wrote:
> > Personally, I don't like the idea of TwinLisp. As Peter tries to make
> > clear, there will also be cases where the translation of CL constructs
> > to TL won't work, for example, when symbols in CL include what looks
> > like TL constructs.
>
> What I don't like is the implementation, as it makes many decisions
> about what should be done in that way, e.g. what varnames are illegal
> and which character is user for what.
Take a look at
http://twinlisp.nongnu.org/docs/TwinLisp%20for%20lisp%20users.html#IdentAndOpers
You can use *any* names for variables, by putting & infront of it. And
you can use names, that are used as names for special structure, by
placing &. Again, take look at docs, and try the stuff at trepl.
>
> On the other hand, I do like its basic idea, that is transforming the
> S-exps into "something else" to make it more readable for java-hackers
> or other groups. You took clumsy M-exps here, but it doesn't have to be.
> I guess most people, even being advanced lisp hackers, still prefer
> reading "6 - a*b" over "(- 6 (* a b))" - I would even like to remove the
> '*'. Of course, they gladly take this drawback in order to have all the
> cool stuff.
>
> Actually, I'm already thinking about this for quite a long time, and my
> ideas are as follows:
>
> -get rid of ascii...
TL is not in the way here. The CL under it should work with UTF? TL is
no constraint here.
>
> -represent the code as lists internally, as usual. Don't compile
> completely entered code into it afterwards, but (if it's entered in
> another way - I'm not sure about input yet...), do this "live" while the
> programmer is typing.
>
> -each part of the program, that is function calls, symbols and so on may
> have its own "presentation function" that draws it on the screen. For
> example, in a math package, the code "(integral #'my-func :start 'x :end
> pi)" could be defined to be printed exactly like latex-output as
> mathematicians expect.
>
> -have a default way to present things - if you like, this can be parens,
> whitespace indentation, tree view or whatever.
>
> -give everyone the ability to create new viewing schemes. For example,
> if you're a clever designer and want to draw in people from the dark
> side, you might be able to have it look **exactly** like java (I'm
> getting a headache thinking of that, though). Parts of ruby's way might
> be more interesting...
>
> I guess the cracking point is about how to type programs with this.
> Maybe you need a view showing the syntax tree for better navigation.
>
> What do you think of that?
I should digest the rest
Stefan Ram wrote:
> Benjamin Teuber <······@web.de> writes:
>> What do you think of that?
>
> See also pages 19 - 21 in
>
> http://research.sun.com/projects/plrg/1.02_steele.pdf
Yeah, I already had a look at fortress. That gave me some confidence not
to be completely wrong if Mr. Steele looks in the same direction... :)
But I think their project doesn't aim to be a lisp but rather a
science-specific thing. Also, I don't think they want to give others the
ability to define their own graphical syntax, but maybe I'm wrong...
Pascal Costanza <··@p-cos.net> writes:
> Personally, I don't like the idea of TwinLisp. As Peter tries to make
> clear, there will also be cases where the translation of CL constructs
> to TL won't work, for example, when symbols in CL include what looks
> like TL constructs.
I think that's the wrong approach. People possibly using Twinlisp are
likely not long lispers. These can just continue to write CL code.
People who are used to writing C++/Java/Python style code are the
presumed users of Twinlisp, and these people will likely not use the
&escape to access CL functions, because they ignore CL. Instead,
they'll write code that looks like Python/Java/C++, as usual, using
the built-ins of Twinlisp (all without &escape).
I doubt however, that remaining in a C++/Python-style syntax will help
newcomers to discover the true nature of Lisp. I fear they'll later
write C++/Python style code in Lisp syntax and not learn much (same
idea as in another current thread in c.l.l).
> Nevertheless, it might work for some people, at least as a first step
> towards the Real Thing (tm).
To me, Twinlisp seems much more mature than any other "newlisp" we've
heard here in the past. Why that much bashing?
Regards,
Jorg Hohle
Come to the European CL Meeting -- http://weitz.de/eclm2006/
Joerg Hoehle wrote:
> Pascal Costanza <··@p-cos.net> writes:
> > Personally, I don't like the idea of TwinLisp. As Peter tries to make
> > clear, there will also be cases where the translation of CL constructs
> > to TL won't work, for example, when symbols in CL include what looks
> > like TL constructs.
>
> I think that's the wrong approach. People possibly using Twinlisp are
> likely not long lispers. These can just continue to write CL code.
Or they can fall back into old habits, due to TL. It's *their* choice.
But TL does not require them to switch back to whatever other lang
they've used before, but instead stick to CL, and get it slower, by
smaller bits.
>
> People who are used to writing C++/Java/Python style code are the
> presumed users of Twinlisp, and these people will likely not use the
> &escape to access CL functions, because they ignore CL. Instead,
> they'll write code that looks like Python/Java/C++, as usual, using
> the built-ins of Twinlisp (all without &escape).
Not really. TL is CL in a sense of what functions you use. If CL func
has to be be escaped to be used in TL, it will. Say, I wanted to open
files, I've used &with-open-file macro. I need regexp, I've used it.
I think that in pair TL-CL, CL is an elephant, and TL is a mouse. If
some want and can ignore an elephant? I think, mouse should ride an
elephant :) , rather then ignoring it.
>
> I doubt however, that remaining in a C++/Python-style syntax will help
> newcomers to discover the true nature of Lisp. I fear they'll later
> write C++/Python style code in Lisp syntax and not learn much (same
> idea as in another current thread in c.l.l).
>
> > Nevertheless, it might work for some people, at least as a first step
> > towards the Real Thing (tm).
>
> To me, Twinlisp seems much more mature than any other "newlisp" we've
> heard here in the past.
I appreciate such comment.
From: Ken Tilton
Subject: Re: ANN: TwinLisp - a new way of programming in Common Lisp
Date:
Message-ID: <5InQf.878$Tu1.18@fe12.lga>
Mikalai wrote:
> Pascal Bourguignon wrote:
>
>>"Mikalai" <········@yahoo.com> writes:
>>
>>>If you are talking that you *personally* feel that lisp syntax is more
>>>convenient, then it is a different matter. TL is not for those who are
>>>happy. TL is for those who are not exactly comfortable with pure lisp
>>>syntax, but would like to use its powers, flexibility of vendors
>>>(unlike Python, Ruby). And if you hear someone saying they do not like
>>>lisps syntax, please, send them to TwinLisp. They will be pleased with
>>>what they'll find.
>>
>>This is clear. That's why it's useless to advocate TwinLisp on c.l.l.
>>Here we like the parentheses.
>
>
> There are new-comers here. Do all new-comers to lisp like them? Myself,
> I felt relieved to typing something like python...
So you prefer manually re-indenting in order to express program flow
instead of expressing it yourself and letting the editor re-indent?
I am big on indentation no matter what language I use, and I refactor no
matter what language I use. I once wondered aloud to the team, while
programming Basic Plus 2, what percent of my time went into reindenting
refactored code. It would have been a non-negligible number, methinks.
I also wonder if you ever mastered Emacs (or the Emacs-like editors
available with most Lisp IDEs). Those allow one to edit not lines or
words or characters or selected ranges thereof, but arbitrary functional
chunks of code. Which is exactly what I want to do when editing.
The sad thing about TwinLisp is that in its well-meant attempt to
sugarcoat Lisp it denies users big advantages of Lisp notation that
could be had with just a few weeks of steady Lisp programming. Reminds
me of the great c.l.l thread "Lisp is hard! Let's go shopping!!"
Anyway, if you are looking for a macro to demonstrate TL, how about the
very typical one Sacha just worked out (sorry about the line breaks):
(defmacro defcontainer (name (&rest super-classes) (&rest slots) &body body)
(loop for slot-def in slots
for contained = (getf (rest slot-def) :containing)
for slot-name = (first slot-def)
collect (if contained `(,slot-name
:accessor ,slot-name
:initform (make-hash-table :test #'equal))
slot-def)
into slot-forms
when contained collect (cons slot-name contained) into init-forms
finally return
`(defclass ,name
,(if (member 'name-container super-classes)
super-classes
(append super-classes (list 'name-container)))
( ,@slot-forms
(container-slots :accessor container-slots :initform
',init-forms))
,@body)))
Applied (from a separate article, but I think the syntax went unchanged):
(defcontainer items (name-container)
((groups :containing itemgroup)
(items :containing item)
(some-slot :initarg :some-slot :initform 12))
(:default-initargs . (:some-slot 12))
(:documentation "let's test this thing"))))
ken
> Anyway, if you are looking for a macro to demonstrate TL, how about the
> very typical one Sacha just worked out (sorry about the line breaks):
My work already being refered to...this sacha is learning pretty fast ! (in
his own err hedonistic ways)
What !? collective effort ? Nonsense !
Seriously isn't this TwinLisp syntax very much like m-expressions ?
Sacha
> Seriously isn't this TwinLisp syntax very much like m-expressions ?
m-expressions were supposed to do foo() instead (foo), aren't they?
Then Java and Python are about m-expressions.
What else is in TL?
- Well, the operators are mostly generic functions, so one can overload
them for own use.
- == acts like Pythons ==. This will not be in the way of newbees. At
the same time eq(), eql() are available, well since it is all on top of
CL.
- indexing with []'s, like in Python's list
- some shorter notations: [] for vectors, ~[] for lists, {} for
hash-tables
- shorter way for writting vars from other packages without interning
symbols, or even use synonyms (pythons: from ... import ... as ...).
All of this without *any* change package system.
- macros, *true* CL macros
- to get a slot of an object, type obj.slot . Similar with methods, but
read docs on this one.
- do you remember, how site-specific and distributed modules come with
python? Same for TL. There is a folder, where you place file.twl, and
then use it by require('file) or require("file"). Or, file can be a
folder, inside which there is _load_.twl
From: Peter Seibel
Subject: Re: ANN: TwinLisp - a new way of programming in Common Lisp
Date:
Message-ID: <m2bqwdpzp6.fsf@gigamonkeys.com>
"Mikalai" <········@yahoo.com> writes:
> - to get a slot of an object, type obj.slot . Similar with methods,
> but read docs on this one.
What do you do with:
(defclass foo () (my.slot another.slot))
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
> > - to get a slot of an object, type obj.slot . Similar with methods,
> > but read docs on this one.
>
> What do you do with:
>
> (defclass foo () (my.slot another.slot))
I am sorry, I didn't get this one. In CL my.slot will be a name, right?
In TL, you do not need to use slot-value(), it is inserted for you. So,
if I have a class with slots a and b:
class foo { a, b }
Then,
a=foo.new()
a.a=5 --- will make slot a in instance of foo a, be 5.
This is what I meant in the first place.
From: Peter Seibel
Subject: Re: ANN: TwinLisp - a new way of programming in Common Lisp
Date:
Message-ID: <m2r759fvud.fsf@gigamonkeys.com>
"Mikalai" <········@yahoo.com> writes:
>> > - to get a slot of an object, type obj.slot . Similar with methods,
>> > but read docs on this one.
>>
>> What do you do with:
>>
> > (defclass foo () (my.slot another.slot))
>
> I am sorry, I didn't get this one. In CL my.slot will be a name, right?
Yes.
> In TL, you do not need to use slot-value(), it is inserted for you. So,
> if I have a class with slots a and b:
> class foo { a, b }
> Then,
> a=foo.new()
> a.a=5 --- will make slot a in instance of foo a, be 5.
> This is what I meant in the first place.
Right. But what does
class foo { a a.x }
class bar { x }
f=foo.new()
f.a = bar.new()
f.a.x
give you? Or is a.x an illegal slot name in TwinLisp?
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Peter Seibel wrote:
---snip---
> Right. But what does
>
> class foo { a a.x }
> class bar { x }
>
> f=foo.new()
> f.a = bar.new()
> f.a.x
>
> give you? Or is a.x an illegal slot name in TwinLisp?
If you want a name "A.X", then &a.x will create a name as a slot's
name.
Otherwise a.x, which is equivalent to slot-value(...) is illegal in
class definition structure. Should it be not?
The f.a.x , will work if f has slot a, and a is bound to an object with
slot x. Just like in Python or Java.
Ken Tilton <·········@gmail.com> writes:
> Mikalai wrote:
[...]
>> I felt relieved to typing something like python...
>
> So you prefer manually re-indenting in order to express program flow
> instead of expressing it yourself and letting the editor re-indent?
I'm not a big python fan, but I need to edit it occasionally, and I
find that emacs does a good job at indenting things correctly with
surprisingly little minimal intervention. Not as good as if it used
parentheses (or braces), but not as annoying as one might anticipate.
(IMHO, obviously.)
[...]
>>> I felt relieved to typing something like python...
>
>> So you prefer manually re-indenting in order to express program flow
>> instead of expressing it yourself and letting the editor re-indent?
>
>I'm not a big python fan, but I need to edit it occasionally, and I
>find that emacs does a good job at indenting things correctly with
>surprisingly little minimal intervention. Not as good as if it used
>parentheses (or braces), but not as annoying as one might anticipate.
>(IMHO, obviously.)
I am not yet in a business of text editors. And I cannot comment on
that. But ain't there something about identation in Kate (from KDE)
editor in the menu? Working on syntax xml file for KWrite (Kate), there
was some mentioning about identation, but I have skipped it.
Hi,
Mikalai wrote:
> There are new-comers here. Do all new-comers to lisp like them?
Actually - as a "newcomer" - I like them very much. Its the cleanest
syntax I ever programmed in.
Sascha
>Mikalai wrote:
>> There are new-comers here. Do all new-comers to lisp like them?
>
>Actually - as a "newcomer" - I like them very much. Its the cleanest
>syntax I ever programmed in.
And I, as a "newcomer" was typing foo() to clisp all the time. So,
again, it is all *personal*. And TL simply gives a choice.
Mikalai
Mikalai wrote:
> And I, as a "newcomer" was typing foo() to clisp all the time. So,
> again, it is all *personal*. And TL simply gives a choice.
Hello: I congratulate your effort and you appear to be a truly talented
programmer. However, I have never seen such a tremendous effort made by
others in order to get over syntax. Hey brother, wouldn't it have been
better to suck up a lot of Dylan. If you had contributed your time and
intelligence to the Dylan project they would have been very happy.
That said: why on earth do people want to get rid of parentheses in
Common Lisp? I could understand if there are some individuals who want
to trade in Lisp for Scheme but not for the case of that "(((())))".
And oh no I am not a Emacs guy even. All what I know from Emacs are
that 2 or 3 keyboard-commands and my mouse is the sheet-anchor. I have
never red any Emacs manual at all (I assume it will have a lot to
offer). But parentheses have never been a problem for me in Bigloo
under its development environment Bee/Emacs.
Schneewittchen
On Sat, 11 Mar 2006 09:24:18 -0800, Förster vom Silberwald wrote:
>
>
> Hello: I congratulate your effort and you appear to be a truly talented
> programmer. However, I have never seen such a tremendous effort made by
> others in order to get over syntax. Hey brother, wouldn't it have been
> better to suck up a lot of Dylan. If you had contributed your time and
> intelligence to the Dylan project they would have been very happy.
>
It's doing a disservice to both Dylan and Common Lisp to imply that there
is some kind of interchangeability between the two for someone who wants:
"Common Lisp with syntax".
Matt
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
Matthew D Swank wrote:
> It's doing a disservice to both Dylan and Common Lisp to imply that there
> is some kind of interchangeability between the two for someone who wants:
> "Common Lisp with syntax".
In the meantime I often fall into the gap and write (foo) instead of
foo() in other programming languages as well. However, that wouldn't
be a reason for me to change a language its syntax. Btw: I wouldn't
have the ability to do so.
I for one was particularily impressed by the TwinLisp inventor since he
was able to quickly react to most of the macros shed on him by the
contributors in this thread. It is a pity that such a potential is lost
since he understands Lisp very well. I mean it is often better to help
a language by developing new libraries or making bindings (that is the
success of Python, though, Python is useless in the real world at least
for me). The worst what can happen to any language: a severe syntax
change.
Schneewittchen
Förster vom Silberwald wrote:
> Matthew D Swank wrote:
>
> > It's doing a disservice to both Dylan and Common Lisp to imply that there
> > is some kind of interchangeability between the two for someone who wants:
> > "Common Lisp with syntax".
>
> In the meantime I often fall into the gap and write (foo) instead of
> foo() in other programming languages as well. However, that wouldn't
> be a reason for me to change a language its syntax. Btw: I wouldn't
> have the ability to do so.
>
> I for one was particularily impressed by the TwinLisp inventor since he
> was able to quickly react to most of the macros shed on him by the
> contributors in this thread. It is a pity that such a potential is lost
> since he understands Lisp very well. I mean it is often better to help
> a language by developing new libraries or making bindings (that is the
> success of Python, though, Python is useless in the real world at least
> for me). The worst what can happen to any language: a severe syntax
> change.
>
I'd like to suggest a different point of view on this matter:
a) On the surface, it seems, many prefer Python way (syntax) of coding.
And these people create libraries for Python.
b) Such person will be more willing to write another lib in TwinLisp,
rather then in CL.
c) When the thing is written in TL, the files (.twl) are translated
into lisp (.lisp) files. That's it. After that point TwinLisp has
nothing to do with the running code, except that it itself provides
some libraries. This means that *any* library written for TL is a
library written for CL.
Summing it up, TwinLisp may bring people to write code *for* lisp that
will otherwise not do it. In this light CL will only benefit from TL.
On Sun, 12 Mar 2006 09:14:45 -0800, Mikalai wrote:
> Summing it up, TwinLisp may bring people to write code *for* lisp that
> will otherwise not do it. In this light CL will only benefit from TL.
The benefits are debatable. Culturally, if TwinLisp were to become
popular, you would effectively have two communities separated by a
common language.
The restrictions on syntax in TwinLisp (or the burden of supporting all
valid CL identifiers through sigils), will encourage different naming
conventions (your own examples use camel casing). Posters to c.l.l using
TwinLisp syntax as an expository tool will most likely be irksome to the
existing community.
Instead of bringing people to (Common) Lisp, a popular TwinLisp more is
likely to become its own language.* That's fine, but selling TwinLisp as
win win has the odor of snake oil about it.
Matt
*There are plenty of languages that started out as augmentations of
existing languages: C->C++, C->Objective C, Common-Lisp -> Dylan, etc.
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
Matthew D Swank wrote:
> On Sun, 12 Mar 2006 09:14:45 -0800, Mikalai wrote:
>
> > Summing it up, TwinLisp may bring people to write code *for* lisp that
> > will otherwise not do it. In this light CL will only benefit from TL.
>
> The benefits are debatable. Culturally, if TwinLisp were to become
> popular, you would effectively have two communities separated by a
> common language.
>
> The restrictions on syntax in TwinLisp (or the burden of supporting all
> valid CL identifiers through sigils), will encourage different naming
> conventions (your own examples use camel casing). Posters to c.l.l using
> TwinLisp syntax as an expository tool will most likely be irksome to the
> existing community.
>
> Instead of bringing people to (Common) Lisp, a popular TwinLisp more is
> likely to become its own language.* That's fine, but selling TwinLisp as
> win win has the odor of snake oil about it.
>
> Matt
>
> *There are plenty of languages that started out as augmentations of
> existing languages: C->C++, C->Objective C, Common-Lisp -> Dylan, etc.
C++ brings objects to C.
Objective C brings objects to C.
Dylan? If they wanted *just* a new syntax, why they have there own
internals? What did they try to add to Common-Lisp?
The way TwinLisp is done, it is none of the above. It has a different
goal - altenative syntax *on top* of CL. In this way TL can be used on
all platforms, where CL exists.
On Sun, 12 Mar 2006 10:25:18 -0800, Mikalai wrote:
> C++ brings objects to C.
> Objective C brings objects to C.
> Dylan? If they wanted *just* a new syntax, why they have there own
> internals? What did they try to add to Common-Lisp?
That's not quite my point. C++ and ObjC were originally implemented as
preprocessors to C. Dylan (with sexp syntax) was originally implemented
in Common Lisp, effectively compiling to Common Lisp.
Technically TwinLisp is just a preprocessor, but culturally, to a
community of language users, there is no such thing as "*just* syntax".
Just look at the contortions the Python community goes through in order to
enforce the uniformity of their syntax. C++ brings objects to C, and
TwinLisp brings syntax to Common Lisp. The impact of that (both positive
and negative) on the community of Lisp users is not to be underestimated.
Matt
--
"You do not really understand something unless you
can explain it to your grandmother." — Albert Einstein.
Matthew D Swank wrote:
> Just look at the contortions the Python community goes through in order to
> enforce the uniformity of their syntax. C++ brings objects to C, and
> TwinLisp brings syntax to Common Lisp. The impact of that (both positive
> and negative) on the community of Lisp users is not to be underestimated.
Hi Matt,
I tried the Python Path before I convinced myself to do the Lisp Leap.
I liked it, but found it too verbose at times. What do you mean by
'contortions to enforce uniformity of syntax'?
On Tue, 14 Mar 2006 16:10:14 -0800, Jonathon McKitrick wrote:
>
> I tried the Python Path before I convinced myself to do the Lisp Leap.
> I liked it, but found it too verbose at times. What do you mean by
> 'contortions to enforce uniformity of syntax'?
Uniformity isn't the right word. Mostly I was trying to express how
important syntax is to a community of language users. This is certainly
true of Python*. Reading Python doc one gets the impression the syntax is
handed down from God, and many Pythonistas expend (or at least have
expended in the past) a lot of energy impugning dissenters, casting them
as a bunch losers that haven't seen the Light.
However, I don't think Python is exceptional in this regard.**
Matt
*but not the community here in c.l.l; here we don't care what syntax Lisp
uses. :)
**though some people do:
http://www.cabochon.com/~stevey/blog-rants/anti-anti-hype.html.
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
From: Pascal Costanza
Subject: Re: ANN: TwinLisp - a new way of programming in Common Lisp
Date:
Message-ID: <47jf1iFg1ouvU1@individual.net>
Mikalai wrote:
> Dylan? If they wanted *just* a new syntax, why they have there own
> internals? What did they try to add to Common-Lisp?
The primary goal of Dylan was not to change the syntax. The primary goal
was to make the language smaller and more "orthogonal". The change of
syntax was decided later, the original versions of Dylan had
s-expression-based syntax, if I understand correctly.
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
Pascal Costanza wrote:
> Mikalai wrote:
>
> > Dylan? If they wanted *just* a new syntax, why they have there own
> > internals? What did they try to add to Common-Lisp?
>
> The primary goal of Dylan was not to change the syntax. The primary goal
> was to make the language smaller and more "orthogonal". The change of
> syntax was decided later, the original versions of Dylan had
> s-expression-based syntax, if I understand correctly.
Thank you for info.
This means that it was correct not to follow Dylan, since it has a
different agenda.
From: Ken Tilton
Subject: Re: ANN: TwinLisp - a new way of programming in Common Lisp
Date:
Message-ID: <eTjRf.92$v27.39@fe08.lga>
Mikalai wrote:
> Matthew D Swank wrote:
>
>
>>On Sun, 12 Mar 2006 09:14:45 -0800, Mikalai wrote:
>>
>>
>>> Summing it up, TwinLisp may bring people to write code *for* lisp that
>>>will otherwise not do it. In this light CL will only benefit from TL.
>>
>>The benefits are debatable. Culturally, if TwinLisp were to become
>>popular, you would effectively have two communities separated by a
>>common language.
>>
>>The restrictions on syntax in TwinLisp (or the burden of supporting all
>>valid CL identifiers through sigils), will encourage different naming
>>conventions (your own examples use camel casing). Posters to c.l.l using
>>TwinLisp syntax as an expository tool will most likely be irksome to the
>>existing community.
>>
>>Instead of bringing people to (Common) Lisp, a popular TwinLisp more is
>>likely to become its own language.* That's fine, but selling TwinLisp as
>>win win has the odor of snake oil about it.
>>
>>Matt
>>
>>*There are plenty of languages that started out as augmentations of
>>existing languages: C->C++, C->Objective C, Common-Lisp -> Dylan, etc.
>
>
> C++ brings objects to C.
> Objective C brings objects to C.
> Dylan? If they wanted *just* a new syntax,...
No.
>... why they have there own
> internals?
Keep reading....
> What did they try to add to Common-Lisp?
Google be your friend:
http://en.wikipedia.org/wiki/Dylan_programming_language
In brief, the goal was to have a Lisp with a smaller footprint, and
mebbe faster, by optionally supplying more type info to the compiler and
(I guess) reducing dynamism a little so a linker could do some serious
tree-shaking (from the above link):
'Dylan attempts to address the performance problem by introducing
"natural" limits to the full flexibility of Lisp systems, allowing the
compiler to clearly understand compilable units (i.e., libraries).'
This because the original deployment target was the Apple Newton (RIP).
So what about the syntax? from the same link:
"Syntax
"At first, Dylan used Lisp syntax, which is based on s-expressions:
(bind ((radius 5)
(circumference (* 2 $pi radius)))
(if (> circumference 42)
(format-out "Hello big circle! c is %=" circumference)
(format-out "Hello circle! c is %=" circumference)))
"The language was then changed to use an Algol-style syntax, which would
be more familiar to C programmers:
begin
let radius = 5;
let circumference = 2 * $pi * radius;
if (circumference > 42)
format-out("Hello, big circle! c = %=", circumference);
else
format-out("Hello, circle! c is %=", circumference);
end if
end"
>
> The way TwinLisp is done, it is none of the above. It has a different
> goal - altenative syntax *on top* of CL. In this way TL can be used on
> all platforms, where CL exists.
>
Dylan was developed atop Digitool Common Lisp.
At the time Apple cancelled the Dylan project and gave it away, Java had
just been released too much hoopla, rejoicing, and adoption.
Coincidence? Maybe, but I doubt it helped.
ken
--
Cells: http://common-lisp.net/project/cells/
"And I will know my song well before I start singing." - Bob Dylan
Mikalai wrote:
> I'd like to suggest a different point of view on this matter:
> a) On the surface, it seems, many prefer Python way (syntax) of coding.
> And these people create libraries for Python.
> b) Such person will be more willing to write another lib in TwinLisp,
> rather then in CL.
Sorry, but this doesn't make much sense to me. If I wanted Python I
would just use Python. Why would anyone liking Python now start to
program in TwinLisp?
> Summing it up, TwinLisp may bring people to write code *for* lisp that
> will otherwise not do it. In this light CL will only benefit from TL.
Let's hope so, by goodness.
Btw: Do you have any statistics of the TwinLisp downloads right now?
Are there any feedbacks from the Pythoners out there regarding your
effort?
Schneewittchen
Förster vom Silberwald wrote:
> Mikalai wrote:
>
> > I'd like to suggest a different point of view on this matter:
> > a) On the surface, it seems, many prefer Python way (syntax) of coding.
> > And these people create libraries for Python.
> > b) Such person will be more willing to write another lib in TwinLisp,
> > rather then in CL.
>
> Sorry, but this doesn't make much sense to me. If I wanted Python I
> would just use Python. Why would anyone liking Python now start to
> program in TwinLisp?
Well, I'll tell you a story.
Imagine, you program a nice thing. These days you use threads, to take
advantage of hardware, smooth the logic, etc. You realize that you have
one piece that will be almost like a global lock in your appllication.
You rework it, spending several months, etc.
Then you learn that
a) Python has GIL (global interpreter lock)
b) NOONE is going to rework Python to get rid of it (even now, even in
future, even when Intel(!) went multicore)
c) If you read posts, BDFL and Co suggest to write an app, so that you
use different processes, i.e. turn several python instances in the OS.
The last point needs a comment. You are doing RAID. You do a simple
thing first, and you hope never to rewrite logic of an app. Now, these
guys suggest you to think, so that, you separate stuff into processes
(not mere threads). When an app is split into processes, I can put
every process on a different machine and use RPC in between. In other
words, they suggest to *first* build, from ground zero, a
clustter-ready app!!!
Do you see a general disconnect here with so called pythonic way and
philosophy.
Why Python people may like TL. Well, even python docs say that you use
python for RAID, and you may later rewrite it in C++, Java. There is no
guaranty, that python version will be OK for production.
Well, lisp is even better RAID. With new syntax (TL) Python people
will be coding in lisp in minutes. They may need a longer time to get
macros -- some thing need learning. But! There are dozens of lisps, and
you can write your RAID code, while a lisp vendor will GUARANTY it
running as fast as possible (may be after you do a few declarations ---
nothing like rewritting a thing).
If you write a simple "hello world", then it doesn't matter *at all*
which language you choose. But if your app takes mu-uch longer to
develop in the most developer-friendly language, rewritting it will
cost you a fortune.
Today, most will have to rewrite, due to new hardware and GIL.
I hear you saying Jython and PyOn.Net:
a) Jython's objects are not exactly java's objects, in a sense that
there is an extra pythonic level on top of java. This does not help
performance.
b) .net -- two vendors, java -- a little more. But who of them *really*
cares about python, so that it flies?
c) What about stability, production ready? Ever looked at python's new
site. Well, CPython is, probably, used by NASA.
d) Isn't lisp in general better then python, anyway?
>
>
> > Summing it up, TwinLisp may bring people to write code *for* lisp that
> > will otherwise not do it. In this light CL will only benefit from TL.
>
> Let's hope so, by goodness.
I do hope so. Let's help it by telling world about TL!
From: Aurélien (nospam, please) Campéas
Subject: Re: ANN: TwinLisp - a new way of programming in Common Lisp [OT]
Date:
Message-ID: <4415a8bf$0$26140$626a54ce@news.free.fr>
Mikalai a �crit :
> F�rster vom Silberwald wrote:
>
>>Mikalai wrote:
>>
>>
>>>I'd like to suggest a different point of view on this matter:
>>>a) On the surface, it seems, many prefer Python way (syntax) of coding.
>>>And these people create libraries for Python.
>>>b) Such person will be more willing to write another lib in TwinLisp,
>>>rather then in CL.
>>
>>Sorry, but this doesn't make much sense to me. If I wanted Python I
>>would just use Python. Why would anyone liking Python now start to
>>program in TwinLisp?
>
> Well, I'll tell you a story.
> Imagine, you program a nice thing. These days you use threads, to take
> advantage of hardware, smooth the logic, etc. You realize that you have
> one piece that will be almost like a global lock in your appllication.
> You rework it, spending several months, etc.
> Then you learn that
> a) Python has GIL (global interpreter lock)
you learn that several months after the beginning of your project ?
sucker ! :)
> b) NOONE is going to rework Python to get rid of it (even now, even in
> future, even when Intel(!) went multicore)
there *might* be, in a not-too distant future, a new implementation of
Python (called PyPy) whose developpers are for sure more open-minded
than GVR.
note that PyPy already has coroutines (various flavors of them in fact)
and will allow dataflow synchronisation between them
> c) If you read posts, BDFL and Co suggest to write an app, so that you
> use different processes, i.e. turn several python instances in the OS.
> The last point needs a comment. You are doing RAID. You do a simple
you mean, RAD ?
> thing first, and you hope never to rewrite logic of an app. Now, these
> guys suggest you to think, so that, you separate stuff into processes
> (not mere threads). When an app is split into processes, I can put
> every process on a different machine and use RPC in between. In other
> words, they suggest to *first* build, from ground zero, a
> clustter-ready app!!!
> Do you see a general disconnect here with so called pythonic way and
> philosophy.
it is well known that Python sucks balls at concurrent programming
the later is not even defined in the Lisp standard but of course you
might find (free) Lisp compilers with decent thread support
>
> Why Python people may like TL. Well, even python docs say that you use
> python for RAID, and you may later rewrite it in C++, Java. There is no
> guaranty, that python version will be OK for production.
> Well, lisp is even better RAID. With new syntax (TL) Python people
> will be coding in lisp in minutes. They may need a longer time to get
> macros -- some thing need learning. But! There are dozens of lisps, and
> you can write your RAID code, while a lisp vendor will GUARANTY it
> running as fast as possible (may be after you do a few declarations ---
> nothing like rewritting a thing).
> If you write a simple "hello world", then it doesn't matter *at all*
> which language you choose. But if your app takes mu-uch longer to
> develop in the most developer-friendly language, rewritting it will
> cost you a fortune.
> Today, most will have to rewrite, due to new hardware and GIL.
>
> I hear you saying Jython and PyOn.Net:
> a) Jython's objects are not exactly java's objects, in a sense that
> there is an extra pythonic level on top of java. This does not help
> performance.
> b) .net -- two vendors, java -- a little more. But who of them *really*
> cares about python, so that it flies?
> c) What about stability, production ready? Ever looked at python's new
> site. Well, CPython is, probably, used by NASA.
> d) Isn't lisp in general better then python, anyway?
Lisp is just mind-bogglingy good but when you write a python generator
for the tenth time you can feel that even Lisp lacks something (don't
tell me about closures, I know them)
To take things a little further, I don't see how even Lisp would help
write the kind of highly concurrent app. with constraint programming
mixed in you can do in Oz for instance.
To switch another time the discussion : you think you brought Lisp to
Python users (let's forget for one moment the syntactic issues), and
that might be true, but didn't you lose in the process one of the great
strength of Python : a huge hassle-free standard lib ?
Python is just that in the end : not-too-ugly looking syntax for a
slightly crappy language on top of a huge set of utilities. Python
programmers will immediately discover the true nature of your plot when
they discover that 80% of their pet tools miss.
Last note : I nevertheless support the idea to slap a close-to-python
syntax on top of CL. Would this be already in existence I would be
tempted to play with it and maybe improve it ...
(sorry for the plugs about PyPy and somewhat changing topics)
>
>>
>>> Summing it up, TwinLisp may bring people to write code *for* lisp that
>>>will otherwise not do it. In this light CL will only benefit from TL.
>>
>>Let's hope so, by goodness.
>
> I do hope so. Let's help it by telling world about TL!
>
Aurélien (nospam, please) Campéas wrote:
---snip---
> > b) NOONE is going to rework Python to get rid of it (even now, even in
> > future, even when Intel(!) went multicore)
>
> there *might* be, in a not-too distant future, a new implementation of
> Python (called PyPy) whose developpers are for sure more open-minded
> than GVR.
You see, there is a difference between "in a not-too distant future"
(when did they start, since GIL isn't just yesterday discovered
problem) and "use it now for production" TL.
>
> Lisp is just mind-bogglingy good but when you write a python generator
> for the tenth time you can feel that even Lisp lacks something (don't
> tell me about closures, I know them)
I like generators myself. We should imagine something like it.
>
> To take things a little further, I don't see how even Lisp would help
> write the kind of highly concurrent app. with constraint programming
> mixed in you can do in Oz for instance.
Concurrent programming, I fear, will not have a silver bullet solution
(it is my personal opinion). So, we will always have to write at length
custom solutions in every app. This will be definitely benefitted from
*real* macros.
>
> To switch another time the discussion : you think you brought Lisp to
> Python users (let's forget for one moment the syntactic issues), and
> that might be true, but didn't you lose in the process one of the great
> strength of Python : a huge hassle-free standard lib ?
I remember that GIL defenders were saying that it is a gazilion of libs
that have to rewritten in order to get rid of GIL. So, for the future
concurrent world many of these libs are lost anyway.
>
> Last note : I nevertheless support the idea to slap a close-to-python
> syntax on top of CL. Would this be already in existence I would be
> tempted to play with it and maybe improve it ...
Try TL, play with it. Use it. The emphasis I have now is on
documentation, so, stay tuned for it. Log support requests in savannah
(currently their mail system is at mess, so maillist isn't working, for
now).
From: Aurélien (nospam, please) Campéas
Subject: Re: ANN: TwinLisp - a new way of programming in Common Lisp [OT]
Date:
Message-ID: <4415c3e6$0$26144$626a54ce@news.free.fr>
Mikalai a �crit :
> Aur�lien (nospam, please) Camp�as wrote:
> ---snip---
>
>>>b) NOONE is going to rework Python to get rid of it (even now, even in
>>>future, even when Intel(!) went multicore)
>>
>>there *might* be, in a not-too distant future, a new implementation of
>>Python (called PyPy) whose developpers are for sure more open-minded
>>than GVR.
>
> You see, there is a difference between "in a not-too distant future"
> (when did they start, since GIL isn't just yesterday discovered
> problem) and "use it now for production" TL.
None knows even *if* it will be usable up to 'production' if that means
being a drop-in replacement for CPython. But there is some manpower at
work there and some funding, even by the EU. Something usable could
emerge from it. They still have some ... performance problems to solve
for instance.
>
>>Lisp is just mind-bogglingy good but when you write a python generator
>>for the tenth time you can feel that even Lisp lacks something (don't
>>tell me about closures, I know them)
>
> I like generators myself. We should imagine something like it.
There was a discussion in c.l.l about implementing generators in CL, and
the outcome was quite unclear about the feasibility of the thing -- I
mean without leaving many corner cases and doing something complicated.
>
>>To take things a little further, I don't see how even Lisp would help
>>write the kind of highly concurrent app. with constraint programming
>>mixed in you can do in Oz for instance.
>
> Concurrent programming, I fear, will not have a silver bullet solution
> (it is my personal opinion). So, we will always have to write at length
> custom solutions in every app. This will be definitely benefitted from
> *real* macros.
I think not. Concurrent programming is currently best addressed by three
kinds of devices :
* message-passing processes (forget about sharing state) as in Erlang or Oz
* dataflow variables (with a logic semantic as a bonus) or just futures
(as in respectively OZ or Alice and Multilisp)
* full-blown transactions
The two first kinds help you design cooperative concurrent stuff. They
are quite underrated right now, especially the dataflow stuff (I'm sure
Kenny Tilton could sell you the dataflow idea if he wanted to ...).
Transactional stuff is generally costly but remember that it drives an
incredible lot of "real-life" or "production" stuff. I've yet to see it
really integrated into some programming language.
But again, here macro can't help you with something that your kernel
language misses : leightweight concurrency. It is a fundamental addition
that would necessitate the ability to really encapsulate the
side-effecting stuff. I am not sure arbitrary Common Lisp code can be
safely encapsulated inside something less big than full-blown OS-level
threads or processes. Note that I would love to be proven wrong.
One thing that could be done would be writting a completely separate
language on top of CL. In fact I just regret the designers of Oz didn't
go with s-exprs as core syntax.
>
>>To switch another time the discussion : you think you brought Lisp to
>>Python users (let's forget for one moment the syntactic issues), and
>>that might be true, but didn't you lose in the process one of the great
>>strength of Python : a huge hassle-free standard lib ?
>
> I remember that GIL defenders were saying that it is a gazilion of libs
> that have to rewritten in order to get rid of GIL. So, for the future
> concurrent world many of these libs are lost anyway.
Would adding microthreads cause the same problems ? I doubt it.
>
>>Last note : I nevertheless support the idea to slap a close-to-python
>>syntax on top of CL. Would this be already in existence I would be
>>tempted to play with it and maybe improve it ...
>
> Try TL, play with it. Use it. The emphasis I have now is on
> documentation, so, stay tuned for it. Log support requests in savannah
> (currently their mail system is at mess, so maillist isn't working, for
> now).
I'll try. But as I've already said, the mere use of {} for blocks isn't
an encouragement. Eventualy, if the internals of TL are workable, I'll
try to see if it is possible to get rid of it.
Don't try to sell a mix of Java and Python syntax for python folks... (I
means, regular users of the language). Well if you do that I'll be
curious to see the reactions on comp.lang.python
cheers,
aur�lien
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: ANN: TwinLisp - a new way of programming in Common Lisp
Date:
Message-ID: <87k6ayfeps.fsf@qrnik.zagroda>
"Mikalai" <········@yahoo.com> writes:
> a) Python has GIL (global interpreter lock)
This is true for most Lisp implementations as well.
But at least I hope they have a saner implementation of timed wait
on a condition variable than this:
def wait(self, timeout=None):
assert self._is_owned(), "wait() of un-acquire()d lock"
waiter = _allocate_lock()
waiter.acquire()
self.__waiters.append(waiter)
saved_state = self._release_save()
try: # restore state no matter what (e.g., KeyboardInterrupt)
if timeout is None:
waiter.acquire()
if __debug__:
self._note("%s.wait(): got it", self)
else:
# Balancing act: We can't afford a pure busy loop, so we
# have to sleep; but if we sleep the whole timeout time,
# we'll be unresponsive. The scheme here sleeps very
# little at first, longer as time goes on, but never longer
# than 20 times per second (or the timeout time remaining).
endtime = _time() + timeout
delay = 0.0005 # 500 us -> initial delay of 1 ms
while True:
gotit = waiter.acquire(0)
if gotit:
break
remaining = endtime - _time()
if remaining <= 0:
break
delay = min(delay * 2, remaining, .05)
_sleep(delay)
if not gotit:
if __debug__:
self._note("%s.wait(%s): timed out", self, timeout)
try:
self.__waiters.remove(waiter)
except ValueError:
pass
else:
if __debug__:
self._note("%s.wait(%s): got it", self, timeout)
finally:
self._acquire_restore(saved_state)
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> "Mikalai" <········@yahoo.com> writes:
>
> > a) Python has GIL (global interpreter lock)
>
> This is true for most Lisp implementations as well.
But some are what you need. And "some"!=0. That's the point of choice
in lisp-land
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: ANN: TwinLisp - a new way of programming in Common Lisp
Date:
Message-ID: <87y7zehzaq.fsf@qrnik.zagroda>
"Mikalai" <········@yahoo.com> writes:
>> > a) Python has GIL (global interpreter lock)
>>
>> This is true for most Lisp implementations as well.
>
> But some are what you need. And "some"!=0.
Is there anything besides experimental SBCL on Linux 2.6 on x86|x86_64
among free implementations?
> That's the point of choice in lisp-land
I believe Jython and IronPython support OS threads, via Java and .NET
respectively.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> > That's the point of choice in lisp-land
>
> I believe Jython and IronPython support OS threads, via Java and .NET
> respectively.
I have mentioned them exactly because they have proper threads. I am
just not too sure how these two compare in production stability as
lisps. Thats all.
From: Edi Weitz
Subject: Re: ANN: TwinLisp - a new way of programming in Common Lisp
Date:
Message-ID: <u8xre6q90.fsf@agharta.de>
On Mon, 13 Mar 2006 21:20:29 +0100, Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
> "Mikalai" <········@yahoo.com> writes:
>
>>> > a) Python has GIL (global interpreter lock)
>>>
>>> This is true for most Lisp implementations as well.
>>
>> But some are what you need. And "some"!=0.
>
> Is there anything besides experimental SBCL on Linux 2.6 on
> x86|x86_64 among free implementations?
Yes, at least OpenMCL and ABCL.
--
European Common Lisp Meeting 2006: <http://weitz.de/eclm2006/>
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
"Mikalai" <········@yahoo.com> writes:
> c) When the thing is written in TL, the files (.twl) are translated
> into lisp (.lisp) files. That's it. After that point TwinLisp has
> nothing to do with the running code, except that it itself provides
> some libraries.
I believe this is short-sighted. There are error messages. There's
debugging. Should TL-writing people (unaware of Lisp) see messages
referring to sexp notation?
With highly imperative code, it's easy to relate an error to a source
line. Python's backtrace outputare good enough at that. However,
when you change style, use parameterization, closures, data-driven
programming or whatever, Python's error messages become less clear.
Here's an example:
rsp = mymod.fetchloop((commandSpeak,expectHello,"hi there"),
(commandGreet,expectXYZ,otherParameters),
(commandSend,expectOk,message,encoding))
)
fetchloop(*args) takes a list of commands, expect... are methods. If
one of these fails, there's no more error message which points me to
the precise location in the source code. Instead, I have to guess (or
use other means) to find out which of the 3 commands caused the error.
BTW, why don't you provide/require RETURN to yield a value in TL?
That's the biggest difference I identified with C/C++/JAva/Python style.
Regards,
Jorg Hohle
Come to the European CL Meeting -- http://weitz.de/eclm2006/
Joerg Hoehle wrote:
> "Mikalai" <········@yahoo.com> writes:
> > c) When the thing is written in TL, the files (.twl) are translated
> > into lisp (.lisp) files. That's it. After that point TwinLisp has
> > nothing to do with the running code, except that it itself provides
> > some libraries.
>
> I believe this is short-sighted. There are error messages. There's
> debugging. Should TL-writing people (unaware of Lisp) see messages
> referring to sexp notation?
If TL sees syntax errors, it does not let it by, period. As for Lisp
machine complaint's, then it will be in regular form, whatever
implementation is under TL.
I wouldn't call it a shortsight, since I knew about this thing before.
I'll call it, "do the simle thing first". I cannot afford to do "the
best thing" right from the ground, since I do not have hundred years
for the task (ala P.Graham).
>
> With highly imperative code, it's easy to relate an error to a source
> line. Python's backtrace outputare good enough at that. However,
> when you change style, use parameterization, closures, data-driven
> programming or whatever, Python's error messages become less clear.
>
> Here's an example:
> rsp = mymod.fetchloop((commandSpeak,expectHello,"hi there"),
> (commandGreet,expectXYZ,otherParameters),
> (commandSend,expectOk,message,encoding))
> )
>
> fetchloop(*args) takes a list of commands, expect... are methods. If
> one of these fails, there's no more error message which points me to
> the precise location in the source code. Instead, I have to guess (or
> use other means) to find out which of the 3 commands caused the error.
I myself stand on the opinion, that professional code should have
fine-grain tests. From my experience, it is tests that provide
(implicitly) valuable info to decode and understand error messages.
>
> BTW, why don't you provide/require RETURN to yield a value in TL?
> That's the biggest difference I identified with C/C++/JAva/Python style.
Everything returns a value in TL -- thats the big difference with
C&Co.
def foo { 3 } returns three. One needs return (it is provided by TL),
when it is an exit from the middle. Why always type return at an end,
if it always returns. Althogh you can type return anywhere you like
inside the func's body.
This will be uniform with
if (t) { 3 }, which returns three.
Another issue is that in the with function 3 is already returned, so,
adding return, will make one more function call, for no reason. Sooner
or later it will produce a huge waste.
In TL you can do return from ... result, if a func was flet inside
another func. return will &return-from outer-most func body (or a
block).
break and return are used in TL for lexical exists. break from ... and
return from ... are the same, but return should be used when it is an
exit from a func, break should be used in other places. break and
return differe when from ... is not given, break returns from block
nil, return from a proper func.
Förster vom Silberwald wrote:
> All what I know from Emacs are
> that 2 or 3 keyboard-commands and my mouse is the sheet-anchor. I have
> never red any Emacs manual at all (I assume it will have a lot to
> offer).
You may find so-called "keyboard macros" very very useful. I suspect if
there's one thing that takes a little time but has a big payoff in
terms of happiness, it's that.
Tayssir
"Mikalai" <········@yahoo.com> writes:
> And I, as a "newcomer" was typing foo() to clisp all the time. So,
> again, it is all *personal*. And TL simply gives a choice.
If you approach a new language with such an attitude, and try to
change it to match your expectations, you don't have much to learn
from it.
"A language that doesn't affect the way you think about programming,
is not worth knowing" -- Alan Perlis
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
Paolo Amoroso wrote:
> "Mikalai" <········@yahoo.com> writes:
>
> > And I, as a "newcomer" was typing foo() to clisp all the time. So,
> > again, it is all *personal*. And TL simply gives a choice.
>
> If you approach a new language with such an attitude, and try to
> change it to match your expectations, you don't have much to learn
> from it.
>
It seems, that you are missled into thinking that TL is a wholy new
language. It is a new syntax, but the rest is the same: generalized
vars, generic funcs, macros, etc., because it is CL under the *thin*
syntax layer, designed for those who will like it more, than
S-expressions. *Nothing* has been changed, apart from a syntax.
I have matched syntax to my expectation, because I claim this
territory to fit *developer's* desires and wants. Everything else - a
huge part - should be the best possible runtime(s).
"Mikalai" <········@yahoo.com> writes:
> Paolo Amoroso wrote:
>> "Mikalai" <········@yahoo.com> writes:
>>
>> > And I, as a "newcomer" was typing foo() to clisp all the time. So,
>> > again, it is all *personal*. And TL simply gives a choice.
>>
>> If you approach a new language with such an attitude, and try to
>> change it to match your expectations, you don't have much to learn
>> from it.
>>
>
> It seems, that you are missled into thinking that TL is a wholy new
> language. It is a new syntax, but the rest is the same: generalized
I wasn't directly addressing TwinLisp, but your approach to learning.
If as a newcomer you dismiss decades of Lisp experience and throw
sexps away at the first difficulty, then you also throw away much of
what Lisp can teach you.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
Paolo Amoroso wrote:
>
> I wasn't directly addressing TwinLisp, but your approach to learning.
> If as a newcomer you dismiss decades of Lisp experience and throw
> sexps away at the first difficulty, then you also throw away much of
> what Lisp can teach you.
>
What may happen is that new people will learn CL functional way of
programming, by using TL, they will see CL's lexical vs. dynamical
variables, by using TL, they'll learn to appreciate CL's CLOS, they'll
get CL's macros, by using TL. They will get *decades* of Lisp
experience, which they will otherwise never touch because of a *common
opinion* about lisp syntax.
I do not see, how all of these CL treasures are thrown away, when TL
*uses* them.
I urge you to investigate *in details* what TL looses from CL valuable
experience. Tell me exactly, so I can put it into documentation, for
other people to see. I would very much appreciate your effort.
"Mikalai" <········@yahoo.com> writes:
> What may happen is that new people will learn CL functional way of
> programming, by using TL, they will see CL's lexical vs. dynamical
Common Lisp is a multiparadigm programming language.
> I urge you to investigate *in details* what TL looses from CL valuable
> experience. Tell me exactly, so I can put it into documentation, for
> other people to see. I would very much appreciate your effort.
A sexp-based syntax.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
Paolo Amoroso wrote:
> > What may happen is that new people will learn CL functional way of
> > programming, by using TL, they will see CL's lexical vs. dynamical
>
> Common Lisp is a multiparadigm programming language.
And how is it lost in TL, if TL can use *anything* available in CL
under it?
>
>
> > I urge you to investigate *in details* what TL looses from CL valuable
> > experience. Tell me exactly, so I can put it into documentation, for
> > other people to see. I would very much appreciate your effort.
>
> A sexp-based syntax.
Which is also available in TL via
http://twinlisp.nongnu.org/docs/TwinLisp%20for%20lisp%20users.html#CLForms
?
"Mikalai" <········@yahoo.com> writes:
> Paolo Amoroso wrote:
>> > What may happen is that new people will learn CL functional way of
>> > programming, by using TL, they will see CL's lexical vs. dynamical
>>
>> Common Lisp is a multiparadigm programming language.
> And how is it lost in TL, if TL can use *anything* available in CL
> under it?
I didn't say that the multiparadigm aspects of Common Lisp are lost in
TwinLisp. Since you mentioned the functional aspects of Common Lisp,
I merely pointed out that it is not just a functional language, but a
multiparadigm one.
>> > I urge you to investigate *in details* what TL looses from CL valuable
>> > experience. Tell me exactly, so I can put it into documentation, for
>> > other people to see. I would very much appreciate your effort.
>>
>> A sexp-based syntax.
> Which is also available in TL via
> http://twinlisp.nongnu.org/docs/TwinLisp%20for%20lisp%20users.html#CLForms
I wasn't clear. I meant that TwinLisp misses the traditional
sexp-based Common Lisp syntax.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
Paolo Amoroso wrote:
---snip---
> >> A sexp-based syntax.
> > Which is also available in TL via
> > http://twinlisp.nongnu.org/docs/TwinLisp%20for%20lisp%20users.html#CLForms
>
> I wasn't clear. I meant that TwinLisp misses the traditional
> sexp-based Common Lisp syntax.
I am lost now. You see, whatever you write in lisp (except reader
macros, with which translator may interfere), is something like (a b c
...), where a,b,c,... can also be forms (a1 b1 ...), not only atoms.
Now, substitute an opening bracket with ~( and use commas (end of
lines) as separators between a,b,c,... , and it is a legitimate TL,
with an added luxury that a,b,c,... can be other TL expressions, not
only ~()'s.
CL uses these bracket forms. TL has them. What is missing in technical
terms?
TwinLisp does not take a "black-and-white" approach towards
s-expressions. These are not taken from TL.
"Mikalai" <········@yahoo.com> writes:
> CL uses these bracket forms. TL has them. What is missing in technical
> terms?
My first message in this thread was about your learning approach, not
TwinLisp itself. But, for the record, my opinion about TwinLisp is
the same expressed by Matthew Swank elsewhere in this thread.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
Pascal Bourguignon wrote:
> "Mikalai" <········@yahoo.com> writes:
> > If you are talking that you *personally* feel that lisp syntax is more
> > convenient, then it is a different matter. TL is not for those who are
> > happy. TL is for those who are not exactly comfortable with pure lisp
> > syntax, but would like to use its powers, flexibility of vendors
> > (unlike Python, Ruby). And if you hear someone saying they do not like
> > lisps syntax, please, send them to TwinLisp. They will be pleased with
> > what they'll find.
>
> This is clear. That's why it's useless to advocate TwinLisp on c.l.l.
> Here we like the parentheses.
>
> I'd advise to rename it to avoid frightening the others with that
> "Lisp" substring, and to advocate it on comp.lang.python,
> comp.lang.ruby, comp.lang.java, etc. Sell the macros!
I'm interested in telling others about efforts like TwinLisp, even if I
don't personally need to use it. It shows that the Lisp tradition is
cosmopolitan, and a number of people have expressed an interest.
As for obscuring the "Lisp" aspect, I suspect that tactically speaking,
fragmentation has a heavier burden of proof than solidarity.
Tayssir
"Mikalai" <········@yahoo.com> writes:
> Hi Folks,
>
> Want to announce availability of a stable version of TwinLisp:
> http://twinlisp.nongnu.org/
>
> TwinLisp is a way of programming Common Lisp in a Java/Python like
> syntax without sacrificing any of Lisps strenths and features. TwinLisp
> is implemented as a layer, which reads TL code and translates it into
> CL code, which is run by a lisp mashine.
Surely, you mean "machine" :-)
A "mashine" would beat it to pulp...
> It is not implemented as
> reader macro, since these are limited for our purpose.
>
> Download TwinLisp at http://twinlisp.nongnu.org/download.html
>
> Check documentation at http://twinlisp.nongnu.org/documentation.html
>
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Logiciels libres : nourris au code source sans farine animale."
From: Ken Tilton
Subject: Re: ANN: TwinLisp - a new way of programming in Common Lisp
Date:
Message-ID: <%bmQf.32$rd6.5@fe08.lga>
Pascal Bourguignon wrote:
> "Mikalai" <········@yahoo.com> writes:
>
>
>>Hi Folks,
>>
>>Want to announce availability of a stable version of TwinLisp:
>>http://twinlisp.nongnu.org/
"Why TwinLisp?
1) TwinLisp should be an alternative for those who want to use lisp's
power, but are not exactly comfortable with lisp's syntax (use of brackets).
2) I hope, more mainstream syntax may bring more people to lisp. "
Oh, my.
(a) You have heard of Dylan, haven't you? If not, that is my point.
(b) The "bracket" syntax is one of the best things about Lisp.
Anyway, good luck with your project.
kt
>Oh, my.
>
>(a) You have heard of Dylan, haven't you? If not, that is my point.
>
>(b) The "bracket" syntax is one of the best things about Lisp.
>
a) I've heard about Dylan, and I wanted something better. On another
hand, I am not changing or creating new lisp runtime. So, I can use TL
*now* for real programming project.
b) This how I thought initially. And there is even a way to mix pure CL
with TL. But I have never needed it. Thus, I have changed my opinion.
From: Pascal Costanza
Subject: Re: ANN: TwinLisp - a new way of programming in Common Lisp
Date:
Message-ID: <47ea3fFeijm9U1@individual.net>
Mikalai wrote:
>>Oh, my.
>>
>>(a) You have heard of Dylan, haven't you? If not, that is my point.
>>
>>(b) The "bracket" syntax is one of the best things about Lisp.
>
> a) I've heard about Dylan, and I wanted something better. On another
> hand, I am not changing or creating new lisp runtime. So, I can use TL
> *now* for real programming project.
>
> b) This how I thought initially. And there is even a way to mix pure CL
> with TL. But I have never needed it. Thus, I have changed my opinion.
If this finds a few new converts, why not...
Pascal
--
3rd European Lisp Workshop
July 3-4 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
> If this finds a few new converts, why not...
That's what I think. With TL on the surface and CL as base I can tell
Python people why they should look into Lisp. Main objection - syntax -
is non-existent now.
From: Aurélien (nospam, please) Campéas
Subject: Re: ANN: TwinLisp - a new way of programming in Common Lisp
Date:
Message-ID: <44159977$0$14270$626a54ce@news.free.fr>
Mikalai a �crit :
>>If this finds a few new converts, why not...
>
>
> That's what I think. With TL on the surface and CL as base I can tell
> Python people why they should look into Lisp. Main objection - syntax -
> is non-existent now.
>
You won't get a lot of python folks jumping in by mixing python and java
syntax.
Note that I'd be interested in the ability to parse python-like code and
make it run on top of a CL implementation (I work in a python-heavy
place where, alas, Lisp is quite sneered at).
Aurélien (nospam, please) Campéas wrote:
> Mikalai a écrit :
> >>If this finds a few new converts, why not...
> >
> >
> > That's what I think. With TL on the surface and CL as base I can tell
> > Python people why they should look into Lisp. Main objection - syntax -
> > is non-existent now.
> >
>
> You won't get a lot of python folks jumping in by mixing python and java
> syntax.
>
> Note that I'd be interested in the ability to parse python-like code and
> make it run on top of a CL implementation (I work in a python-heavy
> place where, alas, Lisp is quite sneered at).
Initially I wanted to have a white-space based syntax like in Python.
But, if you want to keep functional aspect of lisp, i.e. loops, ifs --
everybody return values, then either you switch to something else, or
one should design some syntax trick. I've chosen the first way. But it
doesn't mean that the second cann't be used.
I mentioned this issue in
http://www.nongnu.org/twinlisp/docs/TwinLisp%20for%20lisp%20users.html#ExprAndCodeBlocks
closer to the end of the section.
From: Aurélien (nospam, please) Campéas
Subject: Re: ANN: TwinLisp - a new way of programming in Common Lisp
Date:
Message-ID: <4415a22f$0$13219$626a54ce@news.free.fr>
Mikalai a �crit :
> Aur�lien (nospam, please) Camp�as wrote:
>
>>Mikalai a �crit :
>>
>>>>If this finds a few new converts, why not...
>>>
>>>
>>>That's what I think. With TL on the surface and CL as base I can tell
>>>Python people why they should look into Lisp. Main objection - syntax -
>>>is non-existent now.
>>>
>>
>>You won't get a lot of python folks jumping in by mixing python and java
>>syntax.
>>
>>Note that I'd be interested in the ability to parse python-like code and
>>make it run on top of a CL implementation (I work in a python-heavy
>>place where, alas, Lisp is quite sneered at).
>
>
> Initially I wanted to have a white-space based syntax like in Python.
> But, if you want to keep functional aspect of lisp, i.e. loops, ifs --
> everybody return values, then either you switch to something else, or
> one should design some syntax trick. I've chosen the first way. But it
> doesn't mean that the second cann't be used.
> I mentioned this issue in
> http://www.nongnu.org/twinlisp/docs/TwinLisp%20for%20lisp%20users.html#ExprAndCodeBlocks
> closer to the end of the section.
>
I see. I'd have prefered the syntactic trick. If I remember well, logix
(http://logix.livelogix.com/index.html, unfortunately the site seems
down right now) went that road and the result is ok. Also for
intoxicated pythoneers I wouldn't mind slightly restricting the set of
allowed forms for the sake of readability. After all, they won't mind if
something present in CL but not in Python is not in TwinLisp. But they
will just flee when they see basic python stuff not working, especially
at the immediate syntactic level. Oh well, it's all a matter of compromise.
But allow me to insist : {} for blocks is a no-go for 100% of the
pythoneers I know. I'm sure () would be better for instance.
Don't forget to announce on comp.lang.python if you change your mind
about this :)
Aurélien (nospam, please) Campéas wrote:
> Mikalai a écrit :
> > Aurélien (nospam, please) Campéas wrote:
> >
> >>Mikalai a écrit :
> >>
> >>>>If this finds a few new converts, why not...
> >>>
> >>>
> >>>That's what I think. With TL on the surface and CL as base I can tell
> >>>Python people why they should look into Lisp. Main objection - syntax -
> >>>is non-existent now.
> >>>
> >>
> >>You won't get a lot of python folks jumping in by mixing python and java
> >>syntax.
> >>
> >>Note that I'd be interested in the ability to parse python-like code and
> >>make it run on top of a CL implementation (I work in a python-heavy
> >>place where, alas, Lisp is quite sneered at).
> >
> >
> > Initially I wanted to have a white-space based syntax like in Python.
> > But, if you want to keep functional aspect of lisp, i.e. loops, ifs --
> > everybody return values, then either you switch to something else, or
> > one should design some syntax trick. I've chosen the first way. But it
> > doesn't mean that the second cann't be used.
> > I mentioned this issue in
> > http://www.nongnu.org/twinlisp/docs/TwinLisp%20for%20lisp%20users.html#ExprAndCodeBlocks
> > closer to the end of the section.
> >
>
> I see. I'd have prefered the syntactic trick. If I remember well, logix
> (http://logix.livelogix.com/index.html, unfortunately the site seems
> down right now) went that road and the result is ok. Also for
> intoxicated pythoneers I wouldn't mind slightly restricting the set of
> allowed forms for the sake of readability. After all, they won't mind if
> something present in CL but not in Python is not in TwinLisp. But they
> will just flee when they see basic python stuff not working, especially
> at the immediate syntactic level. Oh well, it's all a matter of compromise.
>
> But allow me to insist : {} for blocks is a no-go for 100% of the
> pythoneers I know. I'm sure () would be better for instance.
100% - at least one person (myself) < 100%
If you talk about 100% die-hards, then you are right. I am not a
die-hard pythoneest. I worry more about what I develop and how I
develop, and general cost overall, rather than purity of a language.
>
> Don't forget to announce on comp.lang.python if you change your mind
> about this :)
Sure, I will. I just want to write another doc called "TwinLisp for
Python Users" :) .
From: Aurélien (nospam, please) Campéas
Subject: Re: ANN: TwinLisp - a new way of programming in Common Lisp
Date:
Message-ID: <4417283f$0$29612$636a55ce@news.free.fr>
Mikalai a �crit :
> Aur�lien (nospam, please) Camp�as wrote:
>
>>Mikalai a �crit :
>>
>>>Aur�lien (nospam, please) Camp�as wrote:
>>>
>>>
>>>>Mikalai a �crit :
>>>>
>>>>
>>>>>>If this finds a few new converts, why not...
>>>>>
>>>>>
>>>>>That's what I think. With TL on the surface and CL as base I can tell
>>>>>Python people why they should look into Lisp. Main objection - syntax -
>>>>>is non-existent now.
>>>>>
>>>>
>>>>You won't get a lot of python folks jumping in by mixing python and java
>>>>syntax.
>>>>
>>>>Note that I'd be interested in the ability to parse python-like code and
>>>>make it run on top of a CL implementation (I work in a python-heavy
>>>>place where, alas, Lisp is quite sneered at).
>>>
>>>
>>> Initially I wanted to have a white-space based syntax like in Python.
>>>But, if you want to keep functional aspect of lisp, i.e. loops, ifs --
>>>everybody return values, then either you switch to something else, or
>>>one should design some syntax trick. I've chosen the first way. But it
>>>doesn't mean that the second cann't be used.
>>> I mentioned this issue in
>>>http://www.nongnu.org/twinlisp/docs/TwinLisp%20for%20lisp%20users.html#ExprAndCodeBlocks
>>>closer to the end of the section.
>>>
>>
>>I see. I'd have prefered the syntactic trick. If I remember well, logix
>>(http://logix.livelogix.com/index.html, unfortunately the site seems
>>down right now) went that road and the result is ok. Also for
>>intoxicated pythoneers I wouldn't mind slightly restricting the set of
>>allowed forms for the sake of readability. After all, they won't mind if
>>something present in CL but not in Python is not in TwinLisp. But they
>>will just flee when they see basic python stuff not working, especially
>>at the immediate syntactic level. Oh well, it's all a matter of compromise.
>>
>>But allow me to insist : {} for blocks is a no-go for 100% of the
>>pythoneers I know. I'm sure () would be better for instance.
>
> 100% - at least one person (myself) < 100%
> If you talk about 100% die-hards, then you are right. I am not a
> die-hard pythoneest. I worry more about what I develop and how I
> develop, and general cost overall, rather than purity of a language.
Ok, my point was not about purity. The fact is I'm currently sitting on
some bits of pure-python code (read : code does not depend on std lib)
that I'd like having translated automatically to CL without fuss (it's a
constraint solver).
>
>>Don't forget to announce on comp.lang.python if you change your mind
>>about this :)
>
> Sure, I will. I just want to write another doc called "TwinLisp for
> Python Users" :) .
>
Aur�lien (nospam, please) Camp�as wrote:
> (http://logix.livelogix.com/index.html, unfortunately the site seems
> down right now)
http://livelogix.net/
From: Ken Tilton
Subject: Re: ANN: TwinLisp - a new way of programming in Common Lisp
Date:
Message-ID: <BghRf.294$7o7.8@fe09.lga>
Aur�lien (nospam, please) Camp�as wrote:
> Mikalai a �crit :
>
>>> If this finds a few new converts, why not...
>>
>>
>>
>> That's what I think. With TL on the surface and CL as base I can tell
>> Python people why they should look into Lisp. Main objection - syntax -
>> is non-existent now.
>>
>
> You won't get a lot of python folks jumping in by mixing python and java
> syntax.
>
> Note that I'd be interested in the ability to parse python-like code and
> make it run on top of a CL implementation (I work in a python-heavy
> place where, alas, Lisp is quite sneered at).
"Stone that the builder refuse
Will always be the head cornerstone"
Psalm 118:22, by Bob Marley
Not sure on that citation. :)
--
Cells: http://common-lisp.net/project/cells/
"And I will know my song well before I start singing." - Bob Dylan