freenode/lisp - IRC Chatlog
Search
18:53:28
phoe
UIOP:LAUNCH-PROGRAM on SBCL under Wine creates a process that would then normally spawn a window
19:22:35
borei
r can be vector object with 3 components, but it can be just x, y, z so method will be like
19:24:25
borei
i can introduce several generic functions to cover possible use-cases, but that solution is not lisp way
19:25:08
borei
i can introuduce (defgeneric move-to (atom &rest r) ... - but that solution is too open for potential problem
19:26:31
gigamonkey
Or are you hoping to distinguish between a vector r and your three loose arguments?
19:26:33
borei
attila_lendvai: that is good point and it leads to another question - when should i use generic functions or just functions
19:26:56
gigamonkey
Use GFs when you want convenient dispatching on the type(s) of one or more arguments.
19:28:12
borei
im comming up to that conclusion, but want to make sure if i missunderstood something, or don't see full functionality
19:28:12
attila_lendvai
borei: if it'll be an essential part of your code, i.e. used a lot, then you can even introduce a small macro based DSL
19:28:43
gigamonkey
SBCL hackers: that weird warning I mentioned earlier this morning seems to be contaminating things worse than I thought. If I build the system I get the warning and then if I run the code it complains about the wrong number of arguments being passed.
19:29:03
gigamonkey
But if I then go and recompile the file containing the DEFTERM form, the warning goes away and the code runs fine.
19:31:40
gigamonkey
borei: really what you're doing is "punning" on the name. Since you're going to pass either one or three (extra) arguments you might as well just write two functions with two different names.
19:33:01
gigamonkey
Or you could do something gross like (defun move-to (atom a &option b c) (if (and b c) (move-to atom (vector a b c)) (actually-move atom a)))
19:36:21
gigamonkey
But that's what you're asking to do: dispatch on the number of arguments you get.
19:40:06
borei
is it good idea to wrap arguments into &rest list and control it within method, don't want to introduce one more "move-to" function because of the arguments, because it does absolutely the same thing, but a bit differently.
19:47:45
phoe
I need a Windows ECL 16.1.3 and I do not have a Windows box with the infrastructure to compile it on - what do you suggest?
20:32:42
jurov
but i had some disappointments trying to compile stuff there, maybe it's improved since
23:11:01
pillton
borei: The CLIM specification solves this problem by providing move-to and move-to*.
5:21:02
jackdaniel
McCLIM progress report: https://common-lisp.net/project/mcclim/posts/Progress-report-7.html :-)
6:32:39
beach
I had some insight about Earley-style parsing, and about parsing in general. This insight is relevant to Cleavir, because I want to use Earley-style parsing for lambda lists, so as to make it possible for client code to customize what specific lambda-list keywords are allowed, and how to treat them.
6:32:41
beach
The insight is that the tokenizer is context free, so it must be possible to determine the nature of a token without knowing how it will be used. For lambda lists, a `token' can in fact be a pattern, requiring a recursive parsing task to be started. But whether a list is a pattern or (say) an optional parameter definitely depends on the context.
6:35:11
beach
In terms of Earley parsing, the consequences are that the Earley `scanner' is just a special case of the `completer' in that it uses some equality predicate to check the next token. What I should do is generalize the completer to use a custom test and eliminate the special case represented by the scanner.
6:36:29
beach
If I have a generic function to do that, then, based on the context, I can trigger a subordinate parsing task when a pattern is required and I see a list as the next `token'.
6:37:32
beach
But when an optional parameter is required and I see a list, then the list is considered to be an optional parameter with a default value.
6:42:18
pjb
beach: what about *read-base*; what about reader macros implementing context-dependent tokenizers? Almost all programming languages have context-dependent lexers (hence the states in lex/flex).
6:44:18
beach
But for lambda lists, the concept of a token gets generalized a bit, since lambda lists are nested.
6:45:43
beach
But yeah, you are right, most tokenizers need some kind of kludge to determine context, but it is usually not the same mechanism as is used by the parser. Though I am aware that there are parsing techniques that don't require a tokenizer.