Re: Unexpected (read "...") behavior
Hi Erik, > It seems that symbols beginning with (or consisting only of) '+' are not > parsed as > a continuous (internal) symbol name. > > But everything works as expected with '*': This is intended. The same happens with '-' BTW. The reason is that these two characters may also denote the sign of a number. The parser cannot decide their meaning, and keeps them always separate. The idea is that the caller decides, depending on language and context. For example, is "3-4" an arithmetic expression (3 "-" 2) or just two numbers (2 -3)? > Is there any way to get '++' to pass through as an internal symbol? Here too the application layer must decide. 'read' is just a simple tokenizer, not a full parser. The latter would require the specification of lots of rules, which are more easily handled if the application operates on the returned lexical tokens. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Unexpected (read "...") behavior
Hi Alex, Ah, yes that makes sense now. Thanks for clarifying! On Thu, Jan 14, 2021 at 2:05 AM Alexander Burger wrote: > Hi Erik, > > > It seems that symbols beginning with (or consisting only of) '+' are not > > parsed as > > a continuous (internal) symbol name. > > > > But everything works as expected with '*': > > This is intended. The same happens with '-' BTW. > > The reason is that these two characters may also denote the sign of a > number. > The parser cannot decide their meaning, and keeps them always separate. > > The idea is that the caller decides, depending on language and context. For > example, is "3-4" an arithmetic expression (3 "-" 2) or just two numbers > (2 -3)? > > > Is there any way to get '++' to pass through as an internal symbol? > > Here too the application layer must decide. > > 'read' is just a simple tokenizer, not a full parser. The latter would > require > the specification of lots of rules, which are more easily handled if the > application operates on the returned lexical tokens. > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > >
subscribe
Hello Christos Gitsis :-) You are now subscribed
Subscribe
Hello Christos Gitsis :-) You are now subscribed
Compile issues
Hi Alex, I'm trying to compile newest PicoLisp but get this: henrik@henrik-tuf:/feting/Downloads/picoLisp-21.1/pil21/src$ make Intrinsic has incorrect argument type! void (i8*, i8*, i64, i1)* @llvm.memcpy.p0i8.p0i8.i64 Intrinsic has incorrect argument type! void (i8*, i8*, i64, i1)* @llvm.memcpy.p0i8.p0i8.i64 Intrinsic has incorrect argument type! void (i8*, i8*, i64, i1)* @llvm.memcpy.p0i8.p0i8.i64 Intrinsic has incorrect argument type! void (i8*, i8*, i64, i1)* @llvm.memcpy.p0i8.p0i8.i64 Intrinsic has incorrect argument type! void (i8*, i8*, i64, i1)* @llvm.memcpy.p0i8.p0i8.i64 Intrinsic has incorrect argument type! void (i8*, i8*, i64, i1)* @llvm.memcpy.p0i8.p0i8.i64 Intrinsic has incorrect argument type! void (i8*, i8, i64, i1)* @llvm.memset.p0i8.p0i8.i64 Intrinsic has incorrect argument type! void (i8*, i8, i64, i1)* @llvm.memset.p0i8.p0i8.i64 Intrinsic has incorrect argument type! void (i8*, i8, i64, i1)* @llvm.memset.p0i8.p0i8.i64 Intrinsic has incorrect argument type! void (i8*, i8, i64, i1)* @llvm.memset.p0i8.p0i8.i64 Intrinsic has incorrect argument type! void (i8*, i8*, i64, i1)* @llvm.memcpy.p0i8.p0i8.i64 Intrinsic has incorrect argument type! void (i8*, i8*, i64, i1)* @llvm.memcpy.p0i8.p0i8.i64 Intrinsic has incorrect argument type! void (i8*, i8*, i64, i1)* @llvm.memcpy.p0i8.p0i8.i64 Intrinsic has incorrect argument type! void (i8*, i8*, i64, i1)* @llvm.memcpy.p0i8.p0i8.i64 Intrinsic has incorrect argument type! void (i8*, i8*, i64, i1)* @llvm.memcpy.p0i8.p0i8.i64 Intrinsic has incorrect argument type! void (i8*, i8*, i64, i1)* @llvm.memcpy.p0i8.p0i8.i64 Intrinsic has incorrect argument type! void (i8*, i8*, i64, i1)* @llvm.memcpy.p0i8.p0i8.i64 opt: base.ll: error: input module is broken! Makefile:35: recipe for target 'base.bc' failed make: *** [base.bc] Error 1 I found this discussion related to this problem: https://stackoverflow.com/questions/51429898/llvm-link-error-when-using-memcpy-in-c-code-and-compiling-with-wasm-target I would try and fiddle myself but I can't for the life of me figure out where to put that extra param / flag in your makefile. I'm on Ubuntu 18.04 but with a newer kernel: 5.4.0-050400-generic if it matters. Regards, Henrik Sarvell
