Many thanks for most informative replies ! OK, I agree, leave 'struct and 'native as they are - maybe / perhaps with ONLY the addition of:
o Interpretation of a 'struct descriptor value of '( NIL . sz )' or '( F . sz ) ( Fill / Fix ( since 'P and 'I are taken)) ? meaning PAD of size sz , this value must be ignored and not returned as a result, and will NOT be present in value list ? I am implementing a 'C_struct' and "C_native" that do what I want, especially for "C" - they will support o DWARF lookup by symbol name: Use of transient symbols in place of 'struct descriptor, that will end up being defined as proper (generated) struct descriptors and will use my C++ ELF+DWARF parser library to generate LISP descriptions to handle register return types, register parameters, structure alignment, etc, that struct descriptor value ending up being the value of the transient symbol: '(C_struct "my_debug_info_file : struct s" ...)' or '(C_struct " struct s" ...)' # ^- or enum, and 's' can contain bit-fields, which # will be encoded as '(B X \: Y ) struct descriptor car # value (bit-field) , or '(E 'EnumName \: EnumValue ) o IFF given a 'struct descriptor' first argument: Will expect a value list last parameter that is of a form identical to that returned by 'struct with the same struct descriptor, and will apply the size and possibly alignment of the currently effective struct descriptor to each member , or '(throw ...) an error if the next member cannot match or be coerced to the expected C type. If 'struct (and native) supports just a new ( ( 'F . sz ) or '(NIL . sz ) result specification, then specifying ignored PAD bytes would be alot easier and the above alot simpler to develop, since internally it could append the '( And, as other commentators suggested, please do ammend the documentation to expand a bit on the sentence: "Creates or extracts data structures, suitable to be passed to or returned from native C functions. " by appending "IFF they specify C native aligned structures or parameters with expected pad bytes . " or something like that. I see that in PicoLisp 'struct does NOT just mean 'C' struct, and IFF the programmer means 'C' struct, they should take care to specify so . I'd also like: o a way of loading 'pil21.so' as a shared library, which has a much stripped down 'main' routine renamed 'pil_main', as a function called from a load module '__attribute__((constructor))' function, and which provides a 'pil' "C" function dynamic symbol that can be called by C which implements something like: (de pil ptr ( eval (c_list (any (pack (list 'struct (car ptr) (cons 'S (length (cdr ptr) ) ) (cdr ptr) ) ) ) ) ) ) so when called from C, a C-parsable list, whose 'next' pointer is the first member of the returned struct value, with the second being a Number / Pointer / String or Symbol atom , or another List pointer : PIL::List *p = pil ( 1, { "(+ 2 2)", NULL } ) ; PIL::for_each (p, [] (PIL::List::Node *p) -> bool { printf( "%d", *((int*)(p->data_pointer()))) > 0; } ); or something like that . I did have a first working prototype of something like this working for pil 20.6, involving modification to handle PIC compilation, and it did work, I'd like to port this to pil21, and will submit with the above DWARF + expressly "C" version of 'struct, called 'C_struct, that specifies PAD bytes correctly , and the extra bit-wise ops I mentioned, shortly. I load this 'pil.so' into the bash shell as a bash-builtin to provide a 'λ' bash shell built-in function - I was going to extend this to provide a '$$' function that interpolated '$' prefixed bash shell expressions by passing back to bash to expand, for Array variable and environment variable access in PicoLisp - maybe it could also handle '${x}=~...' for Regular Expression match and '${x}=*...' for GLOB match. This might take some time to complete! But is where I'm heading ... All the best, Jason maybe I'll try to join the PilCon tomorrow. On 08/12/2021, Alexander Burger <a...@software-lab.de> wrote: > Hi Beneroth, > >> Just a question/idea, maybe nonsense: >> Is (struct) really limited to use with (native)? > > Not explicitly, but on the Lisp level such formatted buffers are not really > useful. They don't need to be passed to 'native' though, calls to libraries > in > the form (lib:foo 'arg) are also possible. > > For debugging PicoLisp itself, 'struct' can be useful to inspect memory in > combination with the 'T' (Direct Lisp value) type and the 'adr' function. > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe