Hi,
I have read "Structure and interpretation..." several years ago and
even that I havn't written anything in Lisp, the book had great
influence on my programming experience.
As a C++ programmer I wondered if it was possible to have both C-like
syntax and Lisp-like programs as data. I have made an attempt to put
it into effect and created a data language, which allows expressions
that look nearly as C++ statements. The language includes lists, as
Lisp, but it also has records and tuples (I think this makes it more
clear what the expressions mean). And my language has syntactic sugar
operators to mimic common programming notations.
I'd be interested in hearing what Lisp experts have to say about it:
http://harpoon.sourceforge.net
--
Michal Czardybon
······@poczta.onet.pl wrote:
> Hi,
>
> I have read "Structure and interpretation..." several years ago and
> even that I havn't written anything in Lisp, the book had great
> influence on my programming experience.
Really?
>
> As a C++ programmer I wondered if it was possible to have both C-like
> syntax and Lisp-like programs as data. I have made an attempt to put
> it into effect and created a data language, which allows expressions
> that look nearly as C++ statements. The language includes lists, as
> Lisp, but it also has records and tuples (I think this makes it more
> clear what the expressions mean). And my language has syntactic sugar
> operators to mimic common programming notations.
>
> I'd be interested in hearing what Lisp experts have to say about it:
>
> http://harpoon.sourceforge.net
>
From http://harpoon.sourceforge.net/rationale.html
> Why the C-family syntax?
>
> There are generally 3 syntax families:
>
> 1.
>
> C - braces for grouping
> 2.
>
> Pascal - begin-end for grouping
> 3.
>
> Python - indentations for grouping
I don't think so. We like:
4. Lisp - (none)
Good luck with your language anyway!
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Tue, 18 Mar 2008 12:39:00 -0700, mczard wrote:
> I'd be interested in hearing what Lisp experts have to say about it:
>
> http://harpoon.sourceforge.net
Not an expert but languages with irregular syntax now make my eyes bleed.
Damn you Lisp.
--
Sohail Somani
http://uint32t.blogspot.com
On Mar 18, 8:39 pm, ······@poczta.onet.pl wrote:
> Hi,
>
> I have read "Structure and interpretation..." several years ago and
> even that I havn't written anything in Lisp, the book had great
> influence on my programming experience.
>
> As a C++ programmer I wondered if it was possible to have both C-like
> syntax and Lisp-like programs as data. I have made an attempt to put
> it into effect and created a data language, which allows expressions
> that look nearly as C++ statements. The language includes lists, as
> Lisp, but it also has records and tuples (I think this makes it more
> clear what the expressions mean). And my language has syntactic sugar
> operators to mimic common programming notations.
>
> I'd be interested in hearing what Lisp experts have to say about it:
>
> http://harpoon.sourceforge.net
>
> --
> Michal Czardybon
One of the cooloest feature of lisp is that it isn't a language but a
building material.
Unique feature of lisp is macro programming. If you didn't like
something in the language you could change it.
For very simple example take a look how easy is to implement Arc if
http://tourdelisp.blogspot.com/2008/03/gif.html
it took me 2 minutes to write it. Just imagine how hard would it be to
change the behaviour and syntax of some of operators in your language.
And the best examples are here On Lisp http://www.paulgraham.com/onlisptext.html
Look at the macros implemented in the book and think how much effort
you need to do such thing in your langauge.
My personal opinion is that without regular syntax like s-expressions
coding macros will be something out of reach for the mortals.
Slobodan
http://tourdelisp.blogspot.com
On 19 Mar, 10:08, Slobodan Blazeski <·················@gmail.com>
wrote:
> One of the cooloest feature of lisp is that it isn't a language but a
> building material.
> Unique feature of lisp is macro programming. If you didn't like
> something in the language you could change it.
This is exactly what I wanted to have in Harpoon.
Harpoon is not a programming language however, it
is rather extension of the S-expressions.
> [...] Just imagine how hard would it be to
> change the behaviour and syntax of some of operators in your language.
No problem at all. Operators are only syntactic
sugar. "a + b" is equivalent to "+( a, b)". In
normal Lisp it would be "(+ a b)".
> My personal opinion is that without regular syntax like s-expressions
> coding macros will be something out of reach for the mortals.
Harpoon syntax IS REGULAR. It only has 3 constructs
(lists, records, tuples) instead of 1 (lists).
My goals were to:
- distinguish collections (lists) from objects (records, tuples)
- mimic the C-family syntax, still having the idea of programs as data
I hope in this way I will create *a bridge* between
worlds of Lisp and C/C++/C#/Java.
Do you think these goals (at least) are ok?
--
Michal Czardybon
From: Pixel // pinterface
Subject: Re: C++ program as a Lisp expression
Date:
Message-ID: <frs08d$f0s$1@aioe.org>
<······@poczta.onet.pl> wrote in message
·········································@d4g2000prg.googlegroups.com...
> My goals were to:
> - distinguish collections (lists) from objects (records, tuples)
> - mimic the C-family syntax, still having the idea of programs as data
>
> I hope in this way I will create *a bridge* between
> worlds of Lisp and C/C++/C#/Java.
>
> Do you think these goals (at least) are ok?
People have been trying to give Lisp a more ALGOL-inspired syntax since the
day McCarthy discovered Lisp. It originally started with M-Expressions[1];
at one point there was Dylan[2]. Many other attempts were made. But in
spite of years of attempts by various people to shirk the parenthesi,
Lispers still use S-expressions.
Maybe--just maybe--you'll manage to pull people from the C++ side closer to
lisp, but if history is any indication you aren't likely to attract many
lispers. They've tried other syntaxes and found them wanting.
I know the ()s are scary at first, but you get used to them, and eventually
take them for granted.
[1] http://en.wikipedia.org/wiki/M-expression
[2] http://en.wikipedia.org/wiki/Dylan_%28programming_language%29
And yes, this is just a more verbose version of what His Kennyness already
stated.
Pixel // pinterface wrote:
> <······@poczta.onet.pl> wrote in message
> ·········································@d4g2000prg.googlegroups.com...
>
>>My goals were to:
>>- distinguish collections (lists) from objects (records, tuples)
>>- mimic the C-family syntax, still having the idea of programs as data
>>
>>I hope in this way I will create *a bridge* between
>>worlds of Lisp and C/C++/C#/Java.
>>
>>Do you think these goals (at least) are ok?
>
>
> People have been trying to give Lisp a more ALGOL-inspired syntax since the
> day McCarthy discovered Lisp. It originally started with M-Expressions[1];
> at one point there was Dylan[2]. Many other attempts were made. But in
> spite of years of attempts by various people to shirk the parenthesi,
> Lispers still use S-expressions.
>
> Maybe--just maybe--you'll manage to pull people from the C++ side closer to
> lisp, but if history is any indication you aren't likely to attract many
> lispers. They've tried other syntaxes and found them wanting.
>
> I know the ()s are scary at first, but you get used to them, and eventually
> take them for granted.
>
> [1] http://en.wikipedia.org/wiki/M-expression
> [2] http://en.wikipedia.org/wiki/Dylan_%28programming_language%29
>
> And yes, this is just a more verbose version of what His Kennyness already
> stated.
But the OP may benefit from those two examples, which I would have
offered had I seen the explicit goal of providing a bridge from C et al
to Lisp.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Wed, 19 Mar 2008 21:24:00 +0000, Pixel // pinterface wrote:
> People have been trying to give Lisp a more ALGOL-inspired syntax since the
> day McCarthy discovered Lisp.
People have been using s-expressions, while waiting for something better to
come along.
Still waiting...
Tim
On 19 Mar, 23:10, tim <····@internet.com> wrote:
> People have been using s-expressions, while waiting for something better to
> come along.
>
> Still waiting...
Could you explain more precisely what you expect, please?
--
Michal Czardybon
On Wed, 19 Mar 2008 22:37:49 -0700, mczard wrote:
> On 19 Mar, 23:10, tim <····@internet.com> wrote:
>
>
>> People have been using s-expressions, while waiting for something better to
>> come along.
>>
>> Still waiting...
>
> Could you explain more precisely what you expect, please?
>
I don't actually *expect* anything better. My point was that after nearly
50 years if something radically better is out there, it would have been
found. The combination of sexps plus a few hacks for special cases
(format, loop), seems to be as good as it gets.
By the way, Lisp is 50 this year! What is its exact birthday? Sometime in
the northern fall/autumn I believe.
Tim
On Wed, 19 Mar 2008 21:24:00 +0000, Pixel // pinterface wrote:
> People have been trying to give Lisp a more ALGOL-inspired syntax since
> the day McCarthy discovered Lisp. It originally started with
> M-Expressions[1]; at one point there was Dylan[2]. Many other attempts
> were made. But in spite of years of attempts by various people to shirk
> the parenthesi, Lispers still use S-expressions.
>
> Maybe--just maybe--you'll manage to pull people from the C++ side closer
> to lisp, but if history is any indication you aren't likely to attract
> many lispers. They've tried other syntaxes and found them wanting.
>
> I know the ()s are scary at first, but you get used to them, and
> eventually take them for granted.
>
> [1] http://en.wikipedia.org/wiki/M-expression [2]
> http://en.wikipedia.org/wiki/Dylan_%28programming_language%29
>
> And yes, this is just a more verbose version of what His Kennyness
> already stated.
Oooh me like Dylan. Shouldn't that be Kenniness?
I think Bolero's language, typo, will have () [] {} and ||, but no <>, %
%, ::.
In fact I just might choose to use underscores. hmm _symbol_... yeah I
think that would be great.
--
http://dihymo.blogspot.com
http;//ntltrmllgnc.stumbleupon.com
Dihydrogen Monoxide wrote:
> On Wed, 19 Mar 2008 21:24:00 +0000, Pixel // pinterface wrote:
>
>
>>People have been trying to give Lisp a more ALGOL-inspired syntax since
>>the day McCarthy discovered Lisp. It originally started with
>>M-Expressions[1]; at one point there was Dylan[2]. Many other attempts
>>were made. But in spite of years of attempts by various people to shirk
>>the parenthesi, Lispers still use S-expressions.
>>
>>Maybe--just maybe--you'll manage to pull people from the C++ side closer
>>to lisp, but if history is any indication you aren't likely to attract
>>many lispers. They've tried other syntaxes and found them wanting.
>>
>>I know the ()s are scary at first, but you get used to them, and
>>eventually take them for granted.
>>
>>[1] http://en.wikipedia.org/wiki/M-expression [2]
>>http://en.wikipedia.org/wiki/Dylan_%28programming_language%29
>>
>>And yes, this is just a more verbose version of what His Kennyness
>>already stated.
>
>
> Oooh me like Dylan. Shouldn't that be Kenniness?
The first link on M-expressions says it all. While McCarthy was still
doing the Chief Science Officer thing and "knew" from first principles
or something that no one should be programming explicitly with the
internal structure, the other people on the team were Actually
Programming(tm) with Lisp and knew otherwise.
Now enjoy this because it may be the only time it ever happens:
What do you and McCarthy have in common?
Cure that and you can have the keys to c.l.l. I am being eased out to
Poster Emeritus and you seem to be able to write without putting me to
sleep.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
On Thu, 29 May 2008 22:10:33 -0400, Ken Tilton wrote:
> Dihydrogen Monoxide wrote:
>> On Wed, 19 Mar 2008 21:24:00 +0000, Pixel // pinterface wrote:
>>
>>
>>>People have been trying to give Lisp a more ALGOL-inspired syntax since
>>>the day McCarthy discovered Lisp. It originally started with
>>>M-Expressions[1]; at one point there was Dylan[2]. Many other attempts
>>>were made. But in spite of years of attempts by various people to
>>>shirk the parenthesi, Lispers still use S-expressions.
>>>
>>>Maybe--just maybe--you'll manage to pull people from the C++ side
>>>closer to lisp, but if history is any indication you aren't likely to
>>>attract many lispers. They've tried other syntaxes and found them
>>>wanting.
>>>
>>>I know the ()s are scary at first, but you get used to them, and
>>>eventually take them for granted.
>>>
>>>[1] http://en.wikipedia.org/wiki/M-expression [2]
>>>http://en.wikipedia.org/wiki/Dylan_%28programming_language%29
>>>
>>>And yes, this is just a more verbose version of what His Kennyness
>>>already stated.
>>
>>
>> Oooh me like Dylan. Shouldn't that be Kenniness?
>
> The first link on M-expressions says it all. While McCarthy was still
> doing the Chief Science Officer thing and "knew" from first principles
> or something that no one should be programming explicitly with the
> internal structure, the other people on the team were Actually
> Programming(tm) with Lisp and knew otherwise.
>
> Now enjoy this because it may be the only time it ever happens:
>
> What do you and McCarthy have in common?
>
> Cure that and you can have the keys to c.l.l. I am being eased out to
> Poster Emeritus and you seem to be able to write without putting me to
> sleep.
>
> kt
well, let me take that the way it was meant
loud n clear capn - expect something at the blogspot like tomorrow
afternoon
i'll be using " _" and "_ " as my eyes take priority
there's a kind of beauty to " " + "_" + char, it makes even the delimiter
a program!
--
http://dihymo.blogspot.com
http;//ntltrmllgnc.stumbleupon.com
Dihydrogen Monoxide wrote:
> On Thu, 29 May 2008 22:10:33 -0400, Ken Tilton wrote:
>
>
>>Dihydrogen Monoxide wrote:
>>
>>>On Wed, 19 Mar 2008 21:24:00 +0000, Pixel // pinterface wrote:
>>>
>>>
>>>
>>>>People have been trying to give Lisp a more ALGOL-inspired syntax since
>>>>the day McCarthy discovered Lisp. It originally started with
>>>>M-Expressions[1]; at one point there was Dylan[2]. Many other attempts
>>>>were made. But in spite of years of attempts by various people to
>>>>shirk the parenthesi, Lispers still use S-expressions.
>>>>
>>>>Maybe--just maybe--you'll manage to pull people from the C++ side
>>>>closer to lisp, but if history is any indication you aren't likely to
>>>>attract many lispers. They've tried other syntaxes and found them
>>>>wanting.
>>>>
>>>>I know the ()s are scary at first, but you get used to them, and
>>>>eventually take them for granted.
>>>>
>>>>[1] http://en.wikipedia.org/wiki/M-expression [2]
>>>>http://en.wikipedia.org/wiki/Dylan_%28programming_language%29
>>>>
>>>>And yes, this is just a more verbose version of what His Kennyness
>>>>already stated.
>>>
>>>
>>>Oooh me like Dylan. Shouldn't that be Kenniness?
>>
>>The first link on M-expressions says it all. While McCarthy was still
>>doing the Chief Science Officer thing and "knew" from first principles
>>or something that no one should be programming explicitly with the
>>internal structure, the other people on the team were Actually
>>Programming(tm) with Lisp and knew otherwise.
>>
>>Now enjoy this because it may be the only time it ever happens:
>>
>> What do you and McCarthy have in common?
>>
>>Cure that and you can have the keys to c.l.l. I am being eased out to
>>Poster Emeritus and you seem to be able to write without putting me to
>>sleep.
>>
>>kt
>
>
> well, let me take that the way it was meant
>
> loud n clear capn - expect something at the blogspot like tomorrow
> afternoon
>
> i'll be using " _" and "_ " as my eyes take priority
>
> there's a kind of beauty to " " + "_" + char, it makes even the delimiter
> a program!
Lessee, I have been cleaning up the code just hoping and praying that
someday Pascal the Magnificent Costanza would deign to look at it, maybe
you can help. I started with this:
(defmethod ensure-value-is-current (c debug-id ensurer)
;
; ensurer can be used cell propagating to callers, or an existing
caller who wants to make sure
; dependencies are up-to-date before deciding if it itself is up-to-date
;
(declare (ignorable debug-id ensurer))
(count-it :ensure-value-is-current)
;; (trc c "ensure-value-is-current > entry" c (c-state c) :now-pulse
*data-pulse-id* debug-id ensurer)
(when *not-to-be*
(when (c-unboundp c)
(error 'unbound-cell :cell c :instance (c-model c) :name
(c-slot-name c)))
(return-from ensure-value-is-current
(when (c-validp c) ;; probably accomplishes nothing
(c-value c))))
(when (and (not (symbolp (c-model c))) ;; damn, just here because of
playing around with global vars and cells
(eq :eternal-rest (md-state (c-model c))))
(break "model ~a of cell ~a is dead" (c-model c) c))
(cond
((c-currentp c)
(trc nil "EVIC yep: c-currentp" c)) ;; used to follow c-inputp, but
I am toying with letting ephemerals (inputs) fall obsolete
;; and then get reset here (ie, ((c-input-p c) (ephemeral-reset
c))). ie, do not assume inputs are never obsolete
;;
((and (c-inputp c)
(c-validp c) ;; a c?n (ruled-then-input) cell will not be valid
at first
(not (and (typep c 'c-dependent)
(eq (cd-optimize c) :when-value-t)
(null (c-value c))))))
((or (not (c-validp c))
;;
;; new for 2006-09-21: a cell ended up checking slots of a dead
instance, which would have been
;; refreshed when checked, but was going to be checked last
because it was the first used, useds
;; being simply pushed onto a list as they come up. We may need
fancier handling of dead instance/cells
;; still being encountered by consulting the prior useds list,
but checking now in same order as
;; accessed seems Deeply Correct (and fixed the immediate problem
nicely, always a Good Sign).
;;
(labels ((check-reversed (useds)
(when useds
(or (check-reversed (cdr useds))
(let ((used (car useds)))
(ensure-value-is-current used :nested c)
#+slow (trc c "comparing pulses (ensurer, used,
used-changed): " c debug-id used (c-pulse-last-changed used))
(when (> (c-pulse-last-changed used)(c-pulse c))
#+slow (trc c "used changed and newer !!!!!!"
c :oldpulse (c-pulse used) debug-id used :lastchg (c-pulse-last-changed
used))
#+shhh (when (trcp c)
(describe used))
t))))))
(assert (typep c 'c-dependent))
(check-reversed (cd-useds c))))
#+shhh (trc c "kicking off calc-set of" (c-state c) (c-validp c)
(c-slot-name c) :vstate (c-value-state c)
:stamped (c-pulse c) :current-pulse *data-pulse-id*)
(calculate-and-set c))
((mdead (c-value c))
(trc nil "ensure-value-is-current> trying recalc of ~a with current
but dead value ~a" c (c-value c))
(let ((new-v (calculate-and-set c)))
(trc nil "ensure-value-is-current> GOT new value ~a to replace
dead!!" new-v)
new-v))
(t (trc nil "ensuring current decided current, updating pulse"
(c-slot-name c) debug-id)
(c-pulse-update c :valid-uninfluenced)))
(when (c-unboundp c)
(error 'unbound-cell :cell c :instance (c-model c) :name
(c-slot-name c)))
(bwhen (v (c-value c))
(if (mdead v)
(progn
#+shhh (format t "~&on pulse ~a ensure-value still got and
still not returning ~a dead value ~a" *data-pulse-id* c v)
nil)
v)))
His Costanzaness does not play such. So I cleaned it up:
(defmethod ensure-value-is-current (c debug-id ensurer)
(cond
((c-currentp c)
(c-value c))
((and (c-inputp c)
(c-validp c)
(not (and (typep c 'c-dependent)
(eq (cd-optimize c) :when-value-t)
(null (c-value c))))))
((or (not (c-validp c))
(labels ((check-reversed (useds)
(when useds
(or (check-reversed (cdr useds))
(let ((used (car useds)))
(ensure-value-is-current used :nested c)
(> (c-pulse-last-changed used)(c-pulse c)))))))
(check-reversed (cd-useds c)))
(mdead (c-value c)))
(calculate-and-set c))
(t (c-pulse-update c :valid-uninfluenced))))
But I still do not see Pascal the Latter tolerating such. Turning to
what I take to be your scheme:
_defmethod ensure-value-is-current _c debug-id ensurer_
_cond
_ _c-currentp c_ _
_ _and _c-inputp c_
_c-validp c_
_not _and _typep c 'c-dependent_
_eq _cd-optimize c_ :when-value-t_
_null _c-value c_ _ _ _ _ _
_ _or _not _c-validp c_ _
_labels _ _check-reversed _useds_
_when useds
_or _check-reversed _cdr useds_ _
_let _ _used _car useds_ _ _
_ensure-value-is-current used :nested c_
_> _c-pulse-last-changed used_ _c-pulse c_ _
_ _ _ _ _
_check-reversed _cd-useds c_ _ _
_mdead _c-value c_ _ _
_calculate-and-set c_ _
_t _c-pulse-update c :valid-uninfluenced_ _ _ _
I think all it needs is camelCase! Where were you fifty years ago!!?
kzo
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton wrote:
> But I still do not see Pascal the Latter tolerating such.
Stop guessing. Idiot.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Ken Tilton wrote:
>
>> But I still do not see Pascal the Latter tolerating such.
>
>
> Stop guessing. Idiot.
Cherish this moment: I agree. I just realized I cocked up the whole
Algebra application by blowing a key design decision, where that key
design decision was itself meant to cure a fundamental design flaw in
the original C application. I do not mind when one of the monkeys tosses
off an off-key note in the heat of coding, but when I look right at a
problem... well, maybe it is like tennis, the more time I have to think
about hitting the ball the more likely the guys on the basketball court
will have to retrieve my shot.
btw, I looked at some of your work. How funny is it that we both applied
our SPTs to calculating Fibonacci numbers? I hope you were joking, too.
And ContextL -- haven't the yobbos savaged you yet on the camelCase?
Please change that to context-l.
Otherwise, nice real-world orientation in there! I will have to consider
that for the Internationalization step if I ever get the thing done for
one nation. Unfortunately I now have to start over...
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
On Mar 19, 8:36 pm, ······@poczta.onet.pl wrote:
> On 19 Mar, 10:08, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
> > One of the cooloest feature of lisp is that it isn't a language but a
> > building material.
> > Unique feature of lisp is macro programming. If you didn't like
> > something in the language you could change it.
>
> This is exactly what I wanted to have in Harpoon.
> Harpoon is not a programming language however, it
> is rather extension of the S-expressions.
>
> > [...] Just imagine how hard would it be to
> > change the behaviour and syntax of some of operators in your language.
>
> No problem at all. Operators are only syntactic
> sugar. "a + b" is equivalent to "+( a, b)". In
> normal Lisp it would be "(+ a b)".
>
> > My personal opinion is that without regular syntax like s-expressions
> > coding macros will be something out of reach for the mortals.
>
> Harpoon syntax IS REGULAR. It only has 3 constructs
> (lists, records, tuples) instead of 1 (lists).
Ok do you mind to give simpel demonstration.
I assume that harpoon if is like c++
if (a ==b)
{
++a;
--b
}
else if (a > b)
{
--a;
++b;
}
else
{
--a;
--b;
}
now create a if* operator that will allow me to code like this:
if* (a ==b)
{
++a;
--b
}
(a > b)
{
--a;
++b;
}
{
--a;
--b;
}
>
> My goals were to:
> - distinguish collections (lists) from objects (records, tuples)
> - mimic the C-family syntax, still having the idea of programs as data
>
> I hope in this way I will create *a bridge* between
> worlds of Lisp and C/C++/C#/Java.
>
> Do you think these goals (at least) are ok?
>
> --
> Michal Czardybon
Goals are Ok but your project seems more or less like deja vu.
good luck anyway
Slobodan
······@poczta.onet.pl writes:
> On 19 Mar, 10:08, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
>> One of the cooloest feature of lisp is that it isn't a language but a
>> building material.
>> Unique feature of lisp is macro programming. If you didn't like
>> something in the language you could change it.
>
> This is exactly what I wanted to have in Harpoon.
> Harpoon is not a programming language however, it
> is rather extension of the S-expressions.
>
>> [...] Just imagine how hard would it be to
>> change the behaviour and syntax of some of operators in your language.
>
> No problem at all. Operators are only syntactic
> sugar. "a + b" is equivalent to "+( a, b)". In
> normal Lisp it would be "(+ a b)".
>
>
>> My personal opinion is that without regular syntax like s-expressions
>> coding macros will be something out of reach for the mortals.
>
> Harpoon syntax IS REGULAR. It only has 3 constructs
> (lists, records, tuples) instead of 1 (lists).
(defmacro what-is-it? (&rest args)
(dolist (arg args)
(format t "At macroexpansion time, ~S is a ~S~%" arg (type-of arg)))
`(progn
(princ "Got ") (princ ',(length args)) (princ " elements.")
(terpri)))
(what-is-it? 123 abc "abc" (1 2 3) #(a b c) #.(make-hash-table) #.*readtable*)
At macroexpansion time, 123 is a (INTEGER 0 281474976710655)
At macroexpansion time, ABC is a SYMBOL
At macroexpansion time, "abc" is a (SIMPLE-BASE-STRING 3)
At macroexpansion time, (1 2 3) is a CONS
At macroexpansion time, #(A B C) is a (SIMPLE-VECTOR 3)
At macroexpansion time, #S(HASH-TABLE :TEST EXT:FASTHASH-EQL) is a HASH-TABLE
At macroexpansion time, #<READTABLE #x000333AC1B58> is a READTABLE
Got 7 elements.
NIL
There are of course much more other types in lisp, all can be written
in a way or the other in your sources (just use #. or add a reader
macro for specific types).
Note that the only thing the lisp reader can read natively are reals
(including rationals, and integers), and symbols. All the rest, like
lists and strings, is read with reader macros.
> My goals were to:
> - distinguish collections (lists) from objects (records, tuples)
> - mimic the C-family syntax, still having the idea of programs as data
>
> I hope in this way I will create *a bridge* between
> worlds of Lisp and C/C++/C#/Java.
>
> Do you think these goals (at least) are ok?
"We were not out to win over the Lisp programmers; we were after the
C++ programmers. We managed to drag a lot of them about halfway to
Lisp." said Guy Steele, Java spec co-author, about Java.
You're competing with Java.
Perhaps it would be more worthwhile to overcome it?
--
__Pascal Bourguignon__
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: C++ program as a Lisp expression
Date:
Message-ID: <rem-2008mar19-001@yahoo.com>
> From: ······@poczta.onet.pl
> I wondered if it was possible to have both C-like syntax and
> Lisp-like programs as data.
IMO it's a dumb idea, because there's nothing particularily good
about C-like syntax. IMO a better idea would be to use the idea
that SAIL (Stanford's version of Algol) had, namely that you can
optionally name the start and end of blocks if you want (not like
XML where every itty bitty level of nested structure *must* have
matching start-and-end tags), and support compact FORTRAN-style
mathematics-like expressions in local places where those are easier
to visualize, but otherwise keep the streamlined
parenthesis-matching syntax of s-expressions. And for literally
stating anonymous functions, nothing beats lambda expressions in
most cases, so keep those for sure!
If you really want to fix something about Lisp syntax, try fixing
the syntax for literal strings. It's a pain that certain characters
are "reserved" in the sense that they can't appear within strings
without needing to be specially quoted. One of my ideas for
resolving this issue is to have more than one kind of
string-delimiting character, so you use whatever kind doesn't
appear in the string itself, so you never have to specially quote
anything within the string, and immediately-adjacent string
notations are automatically appended so you can put together pieces
that use different string-delimiting characters. For example, if "
and ! are string-delimiting characters, here's how to express a
string that has both of them:
!if " and!" ! are string-delimiting characters" shows the proposed notation
!!!!!!!! """"""""""""""""""""""""""""""""""" shows the two segments
For characters that don't work well literally within string expressions,
such as newline and tab, maybe also allow single-character representations
to be included as segments:
"Hello! World!"#\newline shows the proposed notation
""""""""""""" ccccccc shows the two segments
Of course single-character notation would include UniCode hexadecimal
expressions perhaps #uHHHH and #UHHHHHH for 16-bit and 24-bit
UniCodes respectively? This is not a firm proposal I'm making, just
a place to start thinking about better ways to express literal strings
within source code (and also as output from PRIN1 which can then be
read back in by READ).
Combining the two ideas, maybe whenever you need a math expression
you use #m followed by a string expression, whereupon at read time
the contents of the string are parsed as a FORTRAN-style
mathematics expression. So there are two levels of parsing going
on, first the recursive call to READ to parse the string expression
to get the actual contents of the string, then math-parsing that
string to get the parse tree of the mathematical structure.
For example: #M"D = 2*"#\pi"*R"
Equivalent to: #M"D = 2*"#u03C0"*R"
Which might produce: (= D (* 2 |#u03C0| R))
Or maybe allow establishment of a context where certain keywords
that look like variables within the expression are automatically
replaced by the appropriate UniCode character, for example the
symbol pi might be replaced by the character #u03C0. For printing
out, you could select whether to map back to the symbol pi or
actually include the UniCode character #u03C0 in the output.
> I'd be interested in hearing what Lisp experts have to say about it:
I have only about 15+ years experience using Lisp to write
software, starting with Stanford Lisp 1.6, then UCI lisp, then
MacLisp, then SL, then PSL, then pre-ANSI Common Lisp (MACL 1.2.2),
then post-ANSI Common Lisp (CMUCL), so you might not consider me to
be as much of a Lisp expert as people who actually implemented
fully working versions of Lisp.
On 19 Mar, 23:38, ·······@yahoo.com (Robert Maas, see http://tinyurl.com/uh3t)
wrote:
> > From: ······@poczta.onet.pl
> > I wondered if it was possible to have both C-like syntax and
> > Lisp-like programs as data.
>
> IMO it's a dumb idea, because there's nothing particularily good
> about C-like syntax. [...]
Generally I can see that Lisp users fill comfortably
with S-expressions. Nevertheless most of the world
prefers the C-family syntax.
My opinion is that people are different and so are
languages they are creating. And I think that
homoiconicity (programs as data) is not reserved
for Lisp. What I am trying to do is to bring this
interesting feature to the C/C++/C#/Java world.
thus spoke ······@poczta.onet.pl:
>>> I wondered if it was possible to have both C-like syntax and
>>> Lisp-like programs as data.
>> IMO it's a dumb idea, because there's nothing particularily good
>> about C-like syntax. [...]
> Generally I can see that Lisp users fill comfortably with
> S-expressions. Nevertheless most of the world prefers the C-family
> syntax.
It's not like there's much to gain from switchin to Lisp if you take
away homoiconicity.
--
Nawet świnka wejdzie na drzewo kiedy ją chwalą.
On Fri, 21 Mar 2008 13:25:43 +0000, Stanisław Halik wrote:
> It's not like there's much to gain from switchin to Lisp if you take
> away homoiconicity.
I thought homoiconicity (is that a word?) was to do with code being data.
Apparently Harpoon does this as well and then warps it into the C sin-tax.
--
Sohail Somani
http://uint32t.blogspot.com
thus spoke ······@poczta.onet.pl:
>> It's not like there's much to gain from switchin to Lisp if you take
>> away homoiconicity.
> Exactly. And I want to take this single feature
> and add it to the C language family.
Then the expressions are going to look like:
defun(foo, n(m), print("foo"), +(n 42 m))
Unless you start special-casing macros and special forms, it's going to
look like crap. Note the argument list. But if anything's special-cased,
it's not homoiconic anymore. I doubt M-exp-ish syntax would appeal to
either Algol-syntax-derived-languages' programmers or to Lispers.
--
Nawet świnka wejdzie na drzewo kiedy ją chwalą.
On 22 Mar, 11:19, Stanis³aw Halik <··············@tehran.lain.pl>
wrote:
>
> >> It's not like there's much to gain from switchin to Lisp if you take
> >> away homoiconicity.
> > Exactly. And I want to take this single feature
> > and add it to the C language family.
>
> Then the expressions are going to look like:
>
> defun(foo, n(m), print("foo"), +(n 42 m))
> [...]
Thank you for that post - now I know what I have to clarify.
What I think and what you have just given an example for
is that s-expressions can be not convenient for everything.
I would like to have something like s-expression, but I would
also like to be able to express loops and other imperative
statements as in C++. Your example shows that it can be
difficult. A solution I am proposing is Harpoon - you can
write code as this:
define foo:
function ( n : Int, m : Int ) -> Int :
{
printf!("foo");
n := (m + 42);
return n;
}
After removing syntactic sugar, this expression contains
only (tagged) tuples and lists. I am not sure that this
is the best way to describe a function, but I think this
shows my general idea - with lists and tuples (often
expressed with colons or binary operators) you can
obtain expressions very similar to ones from the
"mainstream" programming languages.
It can potentially be attempted to add similar syntactic
sugar operators to the pure lisp. For example:
a + b expands to (+, a, b)
a : b expands to (a, b)
I think this is some way to remove the for-begginers-
inconvenient parentheses. You can say that it is possible
to get accustomed to the parentheses, but the fact is that
I am an example of person that haven't gone deeper into
learing Lisp because of that (besides of the inability
to write high-performance, low-level-optimized routines).
Harpoon is not a lisp with syntactic sugar - it also
expands the set of language constructs to lists, tuples
and records, but the two things (set of constructs and
syntactic sugar) can be used in a language independily.
······@poczta.onet.pl writes:
> On 22 Mar, 11:19, Stanisław Halik <··············@tehran.lain.pl>
> wrote:
>>
>> >> It's not like there's much to gain from switchin to Lisp if you take
>> >> away homoiconicity.
>> > Exactly. And I want to take this single feature
>> > and add it to the C language family.
>>
>> Then the expressions are going to look like:
>>
>> defun(foo, n(m), print("foo"), +(n 42 m))
>> [...]
>
> Thank you for that post - now I know what I have to clarify.
> What I think and what you have just given an example for
> is that s-expressions can be not convenient for everything.
> I would like to have something like s-expression, but I would
> also like to be able to express loops and other imperative
> statements as in C++. Your example shows that it can be
> difficult. A solution I am proposing is Harpoon - you can
> write code as this:
>
> define foo:
> function ( n : Int, m : Int ) -> Int :
> {
> printf!("foo");
> n := (m + 42);
> return n;
> }
I don't see how he's given an example of that.
(defun foo (n m)
(print "foo")
(+ n 42 m)) ; Feel free to add an explicit return statement.
seems pretty convenient to me. More convenient than the Harpoon version
too. But that's why I'm a Lisper. Different strokes for different folks.
> After removing syntactic sugar, this expression contains
> only (tagged) tuples and lists. I am not sure that this
> is the best way to describe a function, but I think this
> shows my general idea - with lists and tuples (often
> expressed with colons or binary operators) you can
> obtain expressions very similar to ones from the
> "mainstream" programming languages.
That's pretty clever. I suppose the parens delimit a tuple and the curly
braces a list? It does sound like it could work.
> I think this is some way to remove the for-begginers- inconvenient
> parentheses.
I (and probably everyone else) have toyed with the idea of cutting away
some parens. Sometimes "))))))))" still looks a little ludicrous. But
what I've come up with is that the "excessive" parens are half a
consequence of the programming style Lisp makes possible, and half a
consequence of formatting. If you took my example above an reformatted
it with some hypothetical "C-style" notation:
defun foo (n, m)
(
print("foo"),
add(n, 42, m)
)
which I think is what Stanisław was trying to show, you'd get the same
number of braces. In fact, it's the same number of braces in your
Harpoon example as well. If you wrote all your Lisp programs in an
imperative style and used this formatting, I suspect the total braces
would come out very much like in Harpoon. On the other hand, if you
start writing functional expressions like "foo(bar(baz(quux)))", the
parens are going to pile up in any language, even C.
> You can say that it is possible to get accustomed to the parentheses,
I'll do you one better and say that it's impossible not to get
accustomed to them if you just ignore them for now, buckle down, and
write code.
> but the fact is that I am an example of person that haven't gone
> deeper into learing Lisp because of that (besides of the inability to
> write high-performance, low-level-optimized routines).
You're so caught up in your misconceptions that you're designing a new
language rather than learn Lisp. To me it looks like your whole effort
is based on hearsay about Lisp's looks, its performance, and even its
benefits. I can understand not learning Lisp because of your beliefs
about the former two, but if you don't even know Lisp, how do you expect
to successfully import the good parts into your language?
Good luck, I guess. I've got no problem with a new language. But from
this group I don't think you're going to get anything better than "There
goes another one." Attempts to make Lisp "palatable" are literally as
old as Lisp itself, and have not historically been successful or even
interesting to Lispers.
On Mar 21, 11:17 pm, "Dimiter \"malkia\" Stanev" <······@gmail.com>
wrote:
> ······@poczta.onet.pl wrote:
> > On 19 Mar, 23:38, ·······@yahoo.com (Robert Maas, seehttp://tinyurl.com/uh3t)
> > wrote:
> >>> From: ······@poczta.onet.pl
> >>> I wondered if it was possible to have both C-like syntax and
> >>> Lisp-like programs as data.
> >> IMO it's a dumb idea, because there's nothing particularily good
> >> about C-like syntax. [...]
>
> > Generally I can see that Lisp users fill comfortably
> > with S-expressions. Nevertheless most of the world
> > prefers the C-family syntax.
>
> Most of the world likes soccer, yet american football, or just football
> is popular more in US, than the rest of the world.
>
> Most of the world likes pop music, yet in Texas, they have CMT.
>
> Most of the world thinks that guns needs to be banned, yet we have the
> second amendment.
>
> Most of the world is neither white, neither black, yet .....
>
> I mean whatever....
>
> Most of the world does not matter!
>
> I'm from Bulgaria :) I do know a little bit about minorities.
>
>
>
> > My opinion is that people are different and so are
> > languages they are creating. And I think that
> > homoiconicity (programs as data) is not reserved
> > for Lisp. What I am trying to do is to bring this
> > interesting feature to the C/C++/C#/Java world.
>
> What happened to "most of the world", now they are all different? How come?
>
> Nothing is reserved for Lisp. I've started learning it year or so ago,
> and I'm finding that most of the stuff in other languages has some form
> in Lisp too, even inline assembly (take Corman Lisp or SBCL for example).
>
> Lisp is like Mother Theresa - caring (GC), loving (REPL), all forgiving
> (DYNAMIC, not STATIC) yet not willing to change (BRACKETS!), or
> modernize (MACROS).... Okay Lisp is not like Mother Theresa, or I can't
> picture Kenny with this analogy, but most definitely it's something like
> Mother Theresa, but it's Kenny again....
>
> Point is... It's not only about programs are code, and code is data, and
> data are programs, and such and such... Where's my GC in C? Where is
> my REPL in C (Haha - root.cern.ch), where is my DYNAMIC C (Pike? Ch?),
> where are my macros (Ugh)?
>
> BTW - what about the READER?
Beautiful rant.
Slobodan
tourdelisp.blogspot.com