Chicken Scheme 4.8.0.5
Greetings all,
Here's a snippet of a malformed definition of a list of lists. I say malformed because the
variable name lies outside the leftmost parenthesis and there is no explicit define statement ie.
(define techDisplays ((AG1 fillerIgnore....nil nil))
snippet.il
techDisplays(
;( LayerName Purpose Packet Vis Sel C2C Drg Val )
;( --------- ------- ------ --- --- --- --- --- )
( AG1 fillerIgnore AG1_fillerIgnore t t nil t nil )
( AG2 drawing AG2_drawing t t nil t t )
( AG2 fillerIgnore AG2_fillerIgnore t t nil t nil )
( AG2 frame AG2_frame t t nil t t )
( AG2 frameOnly AG2_frameOnly t t nil t t )
( AG2 frameOnlyHole AG2_frameOnlyHole t t nil t t )
( y0 flight y0_flight t t t t nil )
( y1 flight y1_flight t t t t nil )
( y2 flight y2_flight t t t t nil )
( y3 flight y3_flight t t t t nil )
( y4 flight y4_flight t t t t nil )
( y5 flight y5_flight t t t t nil )
( y6 flight y6_flight t t t t nil )
( y7 flight y7_flight t t t t nil )
( y8 flight y8_flight t t t t nil )
( y9 flight y9_flight t t t t nil )
( border boundary border_boundary t nil t t nil )
( snap grid snap_grid t nil t nil nil )
) ;techDisplays
Problem: I need to get Scheme to recognise this as a valid top-level definition
Further problem: Solution must be scalable as there's 100s more where this one came from that
I must read in as well
Constraint: I would very very much like NOT to have to write some parsing routine as it'd very likely
turn out wrong what with all the parenthesis-counting , matching, and layering.
Any ideas, hints, constructive critisisms are all welcome.
TIA,
Still-learning Steve
Consider this,
; this is structured as your input with just a space after the first name
#;1> (define inp
'(techdisps (foo bar baz)
(foo1 bar1 baz1)
(foo2 bar2 baz2)))
#;2> inp
(techdisps (foo bar baz) (foo1 bar1 baz1) (foo2 bar2 baz2))
#;3> (define techdisps cdr)
;get all the displays from you input
#;4> (techdisps inp)
((foo bar baz) (foo1 bar1 baz1) (foo2 bar2 baz2))
;this should be just a tech display, let's see how it parses.
#;5> (car (techdisps inp))
(foo bar baz)
#;6> (define foo car)
#;7> (define bar cadr)
#;8> (define baz caddr)
;this will give us all the bazes
#;9> (map baz (techdisps inp))
(baz baz1 baz2)
If you think this won't scale (although 100s more won't be something that a modern scheme interpreter in a decent box will have trouble crunching) we can suggest alternatives.
Hope this helps.
Cheers.
Related
I've encountered an error which I can't resolve. I have a file test.org which simply contains a first level headline: * test
(with-temp-buffer
(insert-file-contents "~/test.org")
(goto-char (point-min))
(org-map-entries
(lambda ()
(compare-strings
"* test\n" nil nil
(thing-at-point 'line t) nil nil
t))
"LEVEL=1"))
This returns Wrong type argument: stringp, nil. The org-map-entries function works normally, but there seems to be a problem when it is used with with-temp-buffer.
The temp buffer is in fundamental mode and nothing you do in your code changes that. OTOH, the org- functions assume that the buffer is in Org mode and (sometimes) barf if that is not the case.
Try this:
(with-temp-buffer
(org-mode)
(insert-file-contents "~/test.org")
(goto-char (point-min))
(org-map-entries
(lambda ()
(compare-strings
"* test\n" nil nil
(thing-at-point 'line t) nil nil
t))
"LEVEL=1"))
I am not able to get the answer by checking the generated assemblies:
{
a := []byte{'a'}
s1 := string(a)
a[0] = 'b'
fmt.Println(s1) // a
}
{
a := "a"
b := []byte(a)
b[0] = 'b'
fmt.Println(a) // a
}
Why the observed behavior is happening?
Is there a description of how go interprets these lines of code?
What does go compiler do for type conversion?
This isn't so much a compiler issue as it is a language specification issue. The compiler can and will do strange things sometimes--what matters here is that whatever machine code the compiler ends up spitting out, it follows the rules laid out in the language specification.
As mentioned in the comments, the language specification defines the conversion of byte slices to and from string types like this:
Converting a slice of bytes to a string type yields a string whose successive bytes are the elements of the slice.
Converting a value of a string type to a slice of bytes type yields a slice whose successive elements are the bytes of the string.
In order to understand the behavior of your examples, you have to also read the definition of string types, also in the specification:
Strings are immutable: once created, it is impossible to change the contents of a string.
Because []byte is mutable, behind the scenes go must make a copy of the relevant data when converting to and from a string. This can be verified by printing the addresses of the 0th element of the []byte object and the pointer to the first element of data in the string object. Here is an example (and a Go Playground version):
package main
import (
"fmt"
"reflect"
"unsafe"
)
func main() {
a := "a"
b := []byte(a)
ah := (*reflect.StringHeader)(unsafe.Pointer(&a))
fmt.Printf("a: %4s # %#x\n", a, ah.Data)
fmt.Printf("b: %v # %p\n\n", b, b)
c := []byte{'a'}
d := string(c)
dh := (*reflect.StringHeader)(unsafe.Pointer(&d))
fmt.Printf("c: %v # %p\n", c, c)
fmt.Printf("d: %4s # %#x\n", d, dh.Data)
}
The output looks like this:
a: a # 0x4c1ab2
b: [97] # 0xc00002c008
c: [97] # 0xc00002c060
d: a # 0x554e21
Notice that the pointer locations of the string and []byte are not the same and do not overlap. Therefore there is no expectation that changes to the []byte values will effect the string values in any way.
Okay, technically the result didn't have to be this way because I didn't make any changes in my example to the values of b or c. Technically the compiler could have taken a shortcut and simply called b a length=1 []byte starting at the same memory address as a. But that optimization would not be allowed if I did something like this instead:
package main
import (
"fmt"
"reflect"
"unsafe"
)
func main() {
a := "a"
b := []byte(a)
b[0] = 'b'
ah := (*reflect.StringHeader)(unsafe.Pointer(&a))
fmt.Printf("a: %4s # %#x\n", a, ah.Data)
fmt.Printf("b: %v # %p\n\n", b, b)
}
Output:
a: a # 0x4c1ab2
b: [98] # 0xc00002c008
See this in action at the Go Playground.
I am new to Emacs Lisp and changing some code in mu4e-send-delay. I want to test whether the user set a variable to a value, e.g. in the scratch buffer:
(setq mu4e-sent-messages-behavior 'delete)
delete
These three tests return false:
(eq 'mu4e-sent-messages-behavior 'delete)
nil
(equal 'mu4e-sent-messages-behavior 'delete)
nil
(equal 'mu4e-sent-messages-behavior "delete")
nil
And this one returns true, but with the member function for lists:
(if (member mu4e-sent-messages-behavior '(delete)) t nil)
t
If the user keeps the setting at the default set in the code:
(defcustom mu4e-sent-messages-behavior 'sent
...
)
then member also fails:
(when (member mu4e-sent-messages-behavior '(sent)) t nil)
nil
What is wrong with my tests, and how can I test for the value of a variable set by the user?
Don't quote the variable name when passing it to eq:
(eq mu4e-sent-messages-behavior 'delete)
The problem with this piece of code:
(when (member mu4e-sent-messages-behavior '(sent)) t nil)
is that when will either return nil (if the condition is false) or the last value of the body (if the condition is true), which in this case is nil - so this piece of code will always return nil. Use if instead of when, and you should see it returning t.
I'm trying to understand how to check if two objects are the same when they implement the same interface.
Here is the example code:
package main
import (
"fmt"
)
type shout interface {
echo()
}
type a struct {}
func (*a) echo () {
fmt.Println("a")
}
type b struct {}
func (*b) echo () {
fmt.Println("b")
}
func compare(a, b shout) {
//fmt.Println(&a, &b)
if a == b {
fmt.Println("same")
} else {
fmt.Println("not same")
}
}
func main() {
a1 := &a{}
b1 := &b{}
a2 := &a{}
a1.echo()
b1.echo()
compare(a1, b1)
compare(a1, a2)
compare(a1, a1)
}
https://play.golang.org/p/qo9XnbthMw
The result is:
not same
not same
same
a1 and a2 are not the same
But if uncomment the line#22
fmt.Println(&a, &b)
The result is:
0x1040a120 0x1040a128
not same
0x1040a140 0x1040a148
same
0x1040a158 0x1040a160
same
Does anyone can figure out what happened here?
Does the Golang compiler optimize something?
Thanks
This appears to be a more complicated example of https://github.com/golang/go/issues/8938.
The relevant parts of the Go spec are https://golang.org/ref/spec#Comparison_operators
Pointers to distinct zero-size variables may or may not be equal.
and https://golang.org/ref/spec#Size_and_alignment_guarantees
Two distinct zero-size variables may have the same address in memory.
Based on the title of the issue linked above (cmd/compile: optimisations change the behaviour of *struct{}), the difference is due to compiler optimizations.
This is expected behavior. For background, == is an operator which compares the value of two objects. This is known as object equality. Comparing their pointer value, or their identity, is different. See the top answer on this similar post.
When you ask a1 == b1, you receive false because a1 is an instance of the a struct, whereas b1 is an instance of the b struct. Therefore, even though they implement the same interface, they are not == to each other. Consider your a struct and b struct where they had additional and different methods implemented in both (so a has an additional method foo() and b has an additional method bar()). Although a and b would implement the same interface, they would not be the same, nor would you expect or want them to be.
When you ask if a1 == a2, you receive true because a1 and a2 are just separate instances of the same struct. Referencing the post I linked above, a1 and a2 are equal, but do not share the same identity.
Finally, when you ask if a1 == a1, you are asking if the same instance of the same object is equal to itself, which of course is true. In this case, a1 shares both equality and identity with a1.
You should use reflect.DeepEqual to compare struct, slice and map.
package main
import (
"fmt"
)
type a struct{}
func main() {
a1 := &a{}
a2 := &a{}
fmt.Printf("%p\n", a1)
if a1 == a2 {
fmt.Println("same")
} else {
fmt.Println("not same")
}
}
The result is:
0x196a9c
not same
Using reflect.DeepEqual as below:
package main
import (
"fmt"
"reflect"
)
type a struct{}
func main() {
a1 := &a{}
a2 := &a{}
fmt.Printf("%p\n", a1)
if a1 == a2 {
fmt.Println("same")
} else {
fmt.Println("not same")
}
fmt.Println(reflect.DeepEqual(a1, a2))
}
The Result is:
0x196a9c
same
true
Just golang compiler optimization i guess.
i am reading the golang tutorial: https://tour.golang.org/moretypes/10
And i am confused about how fmt.Println prints the nil value, hope you could help me out.
package main
import "fmt"
func main() {
var z []int
fmt.Println("z: ", z)
if z == nil {
fmt.Println("z is nil!")
}
fmt.Println("nil:", nil)
}
the result is:
z: []
z is nil!
nil: <nil>
Since z is a nil, why is z printed as [] but not <nil>?
thanks!
The fmt package uses reflection to determine what to print. Since the type of z is a slice, fmt uses the [] notation.
Since slices, channels, interfaces and pointers can all be nil, it helpful if fmt prints something different when it can. If you want more context, use the %v format: http://play.golang.org/p/I1SAVzlv9f
var a []int
var b chan int
var c *int
var e error
fmt.Printf("a:%#v\n", a)
fmt.Printf("b:%#v\n", b)
fmt.Printf("c:%#v\n", c)
fmt.Printf("e:%#v\n", e)
Prints:
a:[]int(nil)
b:(chan int)(nil)
c:(*int)(nil)
e:<nil>
The word nil means : not initialized.
In this case you are initializing the slide but no values have bean assigned yet.
Remember PICS (Pointers, Interfaces, CHANNELS , and SLIDES )are all already
initialized.