Stefan Ram wrote:
> The parentheses are intended to mark the parts of
> the Lisp-like language.
How then would you mark (for example this), which isn't intended to be
evaluated as a Lisp expression?
On 18 Sep, 16:01, ····@zedat.fu-berlin.de (Stefan Ram) wrote:
> Matthias Buelow <····@incubus.de> writes:
> >>The parentheses are intended to mark the parts of
> >>the Lisp-like language.
> >How then would you mark (for example this), which isn't
> >intended to be evaluated as a Lisp expression?
>
> The example was simplified.
>
> The actual representation would be:
>
> < [The sum is ]( + 2 3 )[.] >
>
> versus
>
> < [How would you mark (for example this)?] >
>
> String literals are marked by brackets and lists by angle brackets.
It would be much easier to just steal methods from literate
programming.
You don't need brackets to describe an evaluated region, as you only
evaluate one object at a time.
Instead you could have everything as plain text by default, and use a
> to indicate that the next object should be evaluated and its result
put inserted into the text in it's place.
Set > so that it evaluates to itself and you're done.
Then you could write:
">> (+ 2 2) = >(+ 2 2) and n is of value >n."
And it would return.
"> (+ 2 2) = 4 and n is of value *n*."
Always try and keep things nice and simple.
On 18 Sep, 22:47, ····@zedat.fu-berlin.de (Stefan Ram) wrote:
> Chris Russell <·····················@gmail.com> writes:
> >Always try and keep things nice and simple.
>
> OK. (Sometimes there are just different ways to measure or
> define kindness and simplicity.)
>
> Then, just for curiosity: defining values, such as »4«, in a
> hypothetical Lisp variant to be functions of 0 arguments that
> evaluate to themselve, would allow to evaluate
>
> (4)
>
> with the result
>
> 4
>
> . Would this have any drawbacks? Are there reasons not to
> allow this?
I think its fine for numbers. I don't believe that you can break a
language by assigning a meaning to what was previously a meaningless
phrase, so ("stuff")="stuff" is fine. (123)=123 is fine. (#1A(1 2
3) )=#1A(1 2 3) is fine.
The problem is going to be where you have expressions where expr and
(expr) have predefined and different meanings. So (f) and f will cause
problems as Mattias says, as will (lambda()nil) and ((lambda()nil))
If you are going to add extra brackets to the outside of your lisp
syntax(as I've said I think they're redundant and a single symbol
would do instead), treat them as meaningless syntactic cruft. Strip
them out, throw them away and then pass the expression like it is
normal lisp.
Stefan Ram wrote:
> Then, just for curiosity: defining values, such as �4�, in a
> hypothetical Lisp variant to be functions of 0 arguments that
> evaluate to themselve, would allow to evaluate
>
> (4)
>
> with the result
>
> 4
>
> . Would this have any drawbacks? Are there reasons not to
> allow this?
What about symbols?
(f) would probably have to be evaluated like
(if (fboundp 'f)
(funcall (symbol-function 'f))
(symbol-value 'f))
which is rather hairy (and breaks if f is bound as a variable) and then
what about
(f x)
when f is bound as a variable?
Matthias Buelow wrote:
> Stefan Ram wrote:
>
>> The parentheses are intended to mark the parts of
>> the Lisp-like language.
>
> How then would you mark (for example this), which isn't intended to be
> evaluated as a Lisp expression?
Of what importance is that which escape
character OP wants to use ? :>
Btw, there was (is ?) smthing named ELDER for emacs.
One can mix emacs lisp code with other languages
(and plain text).
Stefan Ram wrote:
> The actual representation would be:
> < [The sum is ]( + 2 3 )[.] >
...
As I see it, you could use an escape character (for example, $) to mark
the next expression for evaluation, or use extra brackets (like {}) for
wrapping expressions. Uglier still but you won't run into lexical problems.
Or change your interpretation rules to evaluate everything outside of []
as Lisp expressions (instead of as literal text).