Hi Alex and Henrik,
> Is Kriangkrai acceptable, too?
Sure. Kriangkrai is my first name. KS is from K for Kriangkrai (my
first name) and S for Soatthiyanont (my surname).
> Kriangkrai Soatthiyanont sounds Thai
Yes, I'm Thai. Sawadee Krub :-)
Best regards,
KS
--
UNSUBSCRIBE: mailto:picol...@softw
>>Is Kriangkrai acceptable, too?<<
Kriangkrai Soatthiyanont sounds Thai, but maybe I was mistaken, if I
wasn't there is a short, usually 3 letter name that is easier to use
:-).
/Henrik
On Fri, May 8, 2009 at 4:43 PM, Alexander Burger wrote:
> Hi Kriangkrai,
>
>> You may call me KS.
>
> Really
Hi Henrik,
> Alright, up to Alex but if it makes the interpreter slower then I'm against=
> it.
No reason to worry. I'm sure the impact is minimal.
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Hi Kriangkrai,
> You may call me KS.
Really? I was also not sure how to call you ;-)
Is Kriangkrai acceptable, too?
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Hi Henrik,
You may call me KS.
It's NOT my intention to fork Pico Lisp! I just need some features. If
I can do them myself, I implement and share them back. If I do not
know how, I request them or ask for an alternative solution. It's OK
for my contribution to not be included in standard Pico Lis
Hi Kriangkrai,
> Thanks for making it nestable. I like your code. ;-)
Thanks :-) However, after thinking about it and Henrik's comment, I
thought I better leave it non-nesting. This is simpler, cleaner, and
less risky (due to the mentioned dangers of breaking it). I think it is
an optimal comprom
Hi Kriangkrai,
> One problem with 'fill' is that the expressions to fill cannot be
> anonymous (it must be the result of a variable), e.g. to fill the
That's true.
> That's true if such functions (e.g. , , ...) already exist.
Yes, they do, e.g. in "lib/xhtml.l". They are a little bit described
Alright, up to Alex but if it makes the interpreter slower then I'm against=
it.
The reason I'm using Pico Lisp is because it's faster than the
alternatives (Ruby, Python).
Maybe it's time then to start with a Maxi Pico Lisp? You could put the
Maxi version under Mercurial control, whenever Alex
Hi Kriangkrai (what is your short name?).
This is a matter of taste, I actually like the way because that
makes it easy for me to differentiate them from system functions.
Check out the xhtml.l file for both those functions and the tag function.
/Henrik
On Fri, May 8, 2009 at 3:24 PM, Kriangkr
Hi Henrik,
My purpose of block comment is not to comment out multiple lines, for
that I would use single line comments too.
I would use block comment to comment out small part in a line, e.g.
(list 1 2 #{3 4}# 5)
or to comment within context, e.g.
(de f (A #{...}# B #{...}#)
Hi Alex,
Thanks for making it nestable. I like your code. ;-)
Best regards,
KS
On 5/8/09, Alexander Burger wrote:
> On Fri, May 08, 2009 at 09:48:05AM +0200, Alexander Burger wrote:
>> Because: If the commented text contains the pattern "#{" or "}#" in a
>> context where it is not relevant as a
Hi Alex,
> (let (Clr "#EEE" Cls "xxx")
>(fill
> '(html
> (body (style "background-color:" Clr)
> (div (class Cls)) ) )
> '(Clr Cls) ) )
One problem with 'fill' is that the expressions to fill cannot be
anonymous (it must be the result of a variable), e.g. to f
Hi Henrik,
> Let's not make the interpreter more complicated for nothing.
This is something I wholeheartedly agree :-)
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
I've implemented simply selecting a slew of lines in my editor,
hitting ctrl-t and they're all single line commented. I'm sure this
can be done in VIM too with some work (if it isn't there already).
Anyway, after doing that I never wished for multi line comments again.
Let's not make the interpre
On Fri, May 08, 2009 at 09:48:05AM +0200, Alexander Burger wrote:
> Because: If the commented text contains the pattern "#{" or "}#" in a
> context where it is not relevant as a comment (e.g. in a symbol name or
> a string), the nesting will break.
Sorry, I'm stupid!
Nesting or not, these block c
On Fri, May 08, 2009 at 09:21:54AM +0200, Alexander Burger wrote:
> True. I'll better make it nesting, using a simple level counter.
Hm, thinking about it, I'm not so sure ...
A working solution would be
static int skip(int c) {
for (;;) {
if (Chr < 0)
return Chr;
Hi Kriangkrai & Tomas,
> it is not great that #{ }# does not nest:-(
True. I'll better make it nesting, using a simple level counter.
> >~(as
> > ...
> What about some more concise syntax, e.g.
>
> ~~ , e.g. ~~NIL(body ...) or something like that?
Well, the nice thing with 'as' is that i
Hi Kriangkrai & Alex,
> In fact, my #{...}# syntax is inspired by the #|...|# syntax in PLT
> Scheme (but in PLT, it can be nested, unlike my implementation ;-)
it is not great that #{ }# does not nest:-(
>...
>~(as
> body
> ... )
>...
>
> The list with 'body' will not b
Hi Kriangkrai,
> It would be great if PicoLisp have "quasi-quotation", so the code
> could be something like:
>
> (out "t.html"
>(sxml
> (let (Clr "#EEE" Cls "xxx")
> `(html
> (body (@ style "background-color:" ,Clr)
>(div (@ class ,Cls)) )
Ther
Hi Kriangkrai,
> Yes, it's ok to include only block comment :-)
Great! Thanks for the contribution!
I released it now in "picoLisp.tgz" and also "miniPicoLisp.tgz".
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
Hi Tomas,
> well, #+NIL(...) seems a bit long, but it is actually a conditional
> comment where the condition is NIL in this case.
Ah, I see! Well, in PicoLisp there is also a kind of "conditional
compilation" which I use quite frequently. It is the read macro operator
'~' (tilde) in combination
Hi Tomas,
Thanks for the code. But my intension for unescaped string is for
"casual" template (most of text are static strings) and embedding
files (without creating separate files).
It would be great if PicoLisp have "quasi-quotation", so the code
could be something like:
(out "t.html"
(sxml
Just to correct my mistake. It is "#;", not "#'", for
single-expression comment in PLT Scheme.
On Fri, May 8, 2009 at 1:53 AM, Kriangkrai Soatthiyanont
wrote:
> Hi Alex and Tomas,
>
> In PLT Scheme, you can comment out a single expression with "#'" (e.g.
> ... #'(+ 1 2) ...). It would be great t
Hi Kriangkrai,
>> But what if we want to mix it with expressions?
>>
>>(let (Clr "#EEE" Cls "xxx")
>> (pack {$
>>
>>
>> $} ))
I would suggest:
(de style Lst
(let S NIL
(while Lst
(let (K (pop 'Lst) V (eval (pop 'Lst) 1))
(whe
Hi Alex,
>> something which would not make me edit both ends of the commented out
>> expression, e.g. Common Lisp #+NIL(...) is better in that sense as you
>> can stay at the beginning all the time when commenting or
>
> I personally find the token '#+NIL' a bit too long (a typical Common
> Lisp s
Hi Alex and Tomas,
In PLT Scheme, you can comment out a single expression with "#'" (e.g.
.. #'(+ 1 2) ...). It would be great to have such kind of comment
too, but I don't know how to do it easily. :-(
In fact, my #{...}# syntax is inspired by the #|...|# syntax in PLT
Scheme (but in PLT, it can
Hi Alex,
Yes, it's ok to include only block comment :-)
Best regards,
KS
On Fri, May 8, 2009 at 1:20 AM, Alexander Burger wrot=
e:
> Hi Kriangkrai,
>
>> But what if we want to mix it with expressions?
>>
>> =A0 =A0(let (Clr "#EEE" =A0Cls "xxx")
>> =A0 =A0 =A0 (pack {$
>> =A0 =A0 =A0 =A0 =A0
>>
Hi Tomas,
> something which would not make me edit both ends of the commented out
> expression, e.g. Common Lisp #+NIL(...) is better in that sense as you
> can stay at the beginning all the time when commenting or
I personally find the token '#+NIL' a bit too long (a typical Common
Lisp style).
Hi Kriangkrai,
> But what if we want to mix it with expressions?
>
>(let (Clr "#EEE" Cls "xxx")
> (pack {$
>
>
> $} ))
Then it gets indeed a bit clumsy, but you can use multiple 'here's and
suitable delimiters:
(let (Clr "#EEE" Cls "xxx")
(here "<1>")
Hi Kriangkrai,
> I have a patch to add block comment (#{}#)
it would be nice to have block comments. I would actually prefer
something which would not make me edit both ends of the commented out
expression, e.g. Common Lisp #+NIL(...) is better in that sense as you
can stay at the beginning
Hi Kriangkrai,
> that, we can generate files easily, e.g.
>
> (out "t.html" (prin {$ style="background-color:#EEE">... class="xxx">..$}))
you can try @lib/html.l or @lib/xml.l to achieve that better:
(out "t.html"
( NIL
( html
( body style "background-color:#EEE"
Hi Alex,
> BTW, I think using 'here' you can achieve something similar, but without
> any danger of conflict:
>
> =A0 (out "t.html" (here))
> =A0
> =A0
> =A0
> =A0
But what if we want to mix it with expressions?
(let (Clr "#EEE" Cls "xxx")
(pack {$
$} )
Hi Kriangkrai,
> "\^"), well except ensuring that there is no "$}" in the string. With
> that, we can generate files easily, e.g.
>
> (out "t.html" (prin {$ style="background-color:#EEE">... class="xxx">..$}))
I see your point, but it seems a little overkill to me for such cases.
BTW, I thi
u, May 7, 2009 at 7:45 PM, Alexander Burger wrote:
> Hi Kriangkrai,
>
>> I have a patch to add block comment (#{}#) and unescape string
>> ({$.$}) syntax.
>
> I think the block comments are a great idea. Such a feature was missing,
> and I like the above syntax.
Hi Kriangkrai,
> I have a patch to add block comment (#{}#) and unescape string
> ({$.$}) syntax.
I think the block comments are a great idea. Such a feature was missing,
and I like the above syntax. But I'm a bit reluctant about the unescaped
strings. Why do you think th
Hi Alex,
I have a patch to add block comment (#{}#) and unescape string
({$.$}) syntax.
Do you think that the syntax will affect old code? Should it be added
to the standard distribution?
Best regards,
KS
io.c.patch
Description: Binary data
36 matches
Mail list logo
