Yes,  the FAQ should definitely elaborate on that, since people are used to 
that interpreted languages can not induce segfaults on their own. Also explain 
perhaps that the interpreter could check all C calls against a white list, but 
it would take a lot of time 

Alexander Burger <a...@software-lab.de> skrev:

>Hi Oskar,
>
>> bitte melde mich fuer die email liste an.
>
>Sure! It happened automatically already :)
>
>
>> : (setq foo 1)
>> -> 1
>> : (foo)
>> Segmentation fault (core dumped)
>
>I understand your worries, but this is actually a "feature".
>
>In general, PicoLisp doesn't catch such errors, as this would induce
>relatively high runtime overhead, in contrast to their extremely rare
>occurrence in production programs.
>
>And, after all, "Segmentation fault" *is* an error message, generated by
>the hardware, isn't it? And you test your program at least once, don't
>you?
>
>
>Setting a symbol to a number (like '1' above) is perfectly legal. And
>"calling" a symbol with a numeric value means to call an internal
>function (i.e. a function pointer). However, at memory location '1'
>there is probably no function, but the interpreter cannot know this.
>
>To avoid potential dangers like the one above, where a variable is
>called as a function, PicoLisp recommends strongly to adhere to certain
>naming conventions:
>
>   http://software-lab.de/doc/ref.html#conv
>
>You would use 'Foo' for locally bound symbols, and 'foo' for a global
>symbol (what a function typically is), and have no problem.
>
>
>Perhaps the FAQ
>
>   http://software-lab.de/doc/faq.html#segfault
>
>should elaborate more on that?
>
>♪♫ Alex
>-- 
>UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
PԔ � &j)m����X�����zV�u�.n7�

Reply via email to