Re: Strange eval behaviour

[Stefan Huchler]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Stefan Huchler <stefan.huchler@mail.de> writes:
>
>> Or did you refer here to something different you saw? bytecompiling
>> only throw warnings about this params variables. And thats only
>> warnings...
>
> But the warnings are there for a reason, and the reason is that the code
> can potentially error when being run.  In general, the warnings mean
> that you do something you definitely should not do.  Let's fix these
> warnings, and then I can have a look at the code again if you want.

Yes but when I know (or belive strongly) that I have nothing that causes
problems I fix warnings as last thing, not as first (at least normaly)
and I am pretty shure that this setq does not create problems, only if
somethnig else also uses global variables with the name params :). So
basicly if I AND somebody else messed up, then it creates problems.

And yes I work best practises in my lisp workflow coding style in one by one.

> Also try to follow the essence of functional programming: reduce side
> effects of functions to a minimum.  When a function has side effects,
> make it clear (e.g. in the doc or the name of the function).

I dont write a doc for a code I will replace before I release it anyway :)

> If you
> really need to set any global variable, declare that variable with
> `defvar' and prefix its name with the prefix of your library.  In
> general, the way functions transfer information in Lisp is by the return
> value, not by setting variables.  For avoiding some bad habits it's very
> helpful to use lexical-binding - you can enable it with a specification
> in the file's first line.

Yeah I know that this is no good idea especialy if you upload it, cause
the main problem is not if you do it in one local package but if
everybody would do that, you have many times incompatible packages
basicly.

I know about that, I just used it because I concentrated primary on the
json code and to get something working, and at the time it was just
easier and faster to do it that way.

Also I dont want to refactor stuff while stuff is not working, I wanted
to get to a working state first. And I was not aware of the
bytecompiling and that macros dont get "live" evaluated basicly I am
used to code that when its wrong gives me some sort of error.

> Maybe consider reading a good book about lisp (since learning by doing
> is not a good approach in Lisp).  Maybe "Land of Lisp" (haven't read it,
> but it has a good title song) or "On Lisp" by Graham (a classical, but
> harder to read; reading some of the first chapters might be a good idea
> anyway).

I am not so good at reading books, I need a reason to do things other
than learn somethnig abstract :) I do that for fun, startet with a
send-youtube-to-kody thing and got then bigger and bigger.

Of course if I run more often into such things, I consider reading a few
pages of a book. I just learned no language by book, not Java, not c++,
not python, not php...

But I think you CAN learn everything online or with the offline
documentiation, books tend just to focus a bit narrower on the juice
stuff, but therefor you have to go through some stupid example code I
dont care and cant relate to.

Whatever still I might consider it in the future.

The main problem was that I did not even have the idea to try to
bytecompile it, so I did not even see that warnings ever.