The Guile Reference Manual ************************** This manual documents Guile version 3.0.10. Copyright (C) 1996-1997, 2000-2005, 2009-2023 Free Software Foundation, Inc. Copyright (C) 2021 Maxime Devos Copyright (C) 2024 Tomas Volf Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License." The Guile Reference Manual Preface Contributors to this Manual The Guile License 1 Introduction 1.1 Guile and Scheme 1.2 Combining with C Code 1.3 Guile and the GNU Project 1.4 Interactive Programming 1.5 Supporting Multiple Languages 1.6 Obtaining and Installing Guile 1.7 Organisation of this Manual 1.8 Typographical Conventions 2 Hello Guile! 2.1 Running Guile Interactively 2.2 Running Guile Scripts 2.3 Linking Guile into Programs 2.4 Writing Guile Extensions 2.5 Using the Guile Module System 2.5.1 Using Modules 2.5.2 Writing new Modules 2.5.3 Putting Extensions into Modules 2.6 Reporting Bugs 3 Hello Scheme! 3.1 Data Types, Values and Variables 3.1.1 Latent Typing 3.1.2 Values and Variables 3.1.3 Defining and Setting Variables 3.2 The Representation and Use of Procedures 3.2.1 Procedures as Values 3.2.2 Simple Procedure Invocation 3.2.3 Creating and Using a New Procedure 3.2.4 Lambda Alternatives 3.3 Expressions and Evaluation 3.3.1 Evaluating Expressions and Executing Programs 3.3.1.1 Evaluating Literal Data 3.3.1.2 Evaluating a Variable Reference 3.3.1.3 Evaluating a Procedure Invocation Expression 3.3.1.4 Evaluating Special Syntactic Expressions 3.3.2 Tail calls 3.3.3 Using the Guile REPL 3.3.4 Summary of Common Syntax 3.4 The Concept of Closure 3.4.1 Names, Locations, Values and Environments 3.4.2 Local Variables and Environments 3.4.3 Environment Chaining 3.4.4 Lexical Scope 3.4.4.1 An Example of Non-Lexical Scoping 3.4.5 Closure 3.4.6 Example 1: A Serial Number Generator 3.4.7 Example 2: A Shared Persistent Variable 3.4.8 Example 3: The Callback Closure Problem 3.4.9 Example 4: Object Orientation 3.5 Further Reading 4 Programming in Scheme 4.1 Guile's Implementation of Scheme 4.2 Invoking Guile 4.2.1 Command-line Options 4.2.2 Environment Variables 4.3 Guile Scripting 4.3.1 The Top of a Script File 4.3.2 The Meta Switch 4.3.3 Command Line Handling 4.3.4 Scripting Examples 4.4 Using Guile Interactively 4.4.1 The Init File, ‘~/.guile’ 4.4.2 Readline 4.4.3 Value History 4.4.4 REPL Commands 4.4.4.1 Help Commands 4.4.4.2 Module Commands 4.4.4.3 Language Commands 4.4.4.4 Compile Commands 4.4.4.5 Profile Commands 4.4.4.6 Debug Commands 4.4.4.7 Inspect Commands 4.4.4.8 System Commands 4.4.5 Error Handling 4.4.6 Interactive Debugging 4.5 Using Guile in Emacs 4.6 Using Guile Tools 4.7 Installing Site Packages 4.8 Distributing Guile Code 5 Programming in C 5.1 Parallel Installations 5.2 Linking Programs With Guile 5.2.1 Guile Initialization Functions 5.2.2 A Sample Guile Main Program 5.2.3 Building the Example with Make 5.2.4 Building the Example with Autoconf 5.3 Linking Guile with Libraries 5.3.1 A Sample Guile Extension 5.4 General concepts for using libguile 5.4.1 Dynamic Types 5.4.2 Garbage Collection 5.4.3 Control Flow 5.4.4 Asynchronous Signals 5.4.5 Multi-Threading 5.5 Defining New Foreign Object Types 5.5.1 Defining Foreign Object Types 5.5.2 Creating Foreign Objects 5.5.3 Type Checking of Foreign Objects 5.5.4 Foreign Object Memory Management 5.5.5 Foreign Objects and Scheme 5.6 Function Snarfing 5.7 An Overview of Guile Programming 5.7.1 How One Might Extend Dia Using Guile 5.7.1.1 Deciding Why You Want to Add Guile 5.7.1.2 Four Steps Required to Add Guile 5.7.1.3 How to Represent Dia Data in Scheme 5.7.1.4 Writing Guile Primitives for Dia 5.7.1.5 Providing a Hook for the Evaluation of Scheme Code 5.7.1.6 Top-level Structure of Guile-enabled Dia 5.7.1.7 Going Further with Dia and Guile 5.7.2 Why Scheme is More Hackable Than C 5.7.3 Example: Using Guile for an Application Testbed 5.7.4 A Choice of Programming Options 5.7.4.1 What Functionality is Already Available? 5.7.4.2 Functional and Performance Constraints 5.7.4.3 Your Preferred Programming Style 5.7.4.4 What Controls Program Execution? 5.7.5 How About Application Users? 5.8 Autoconf Support 5.8.1 Autoconf Background 5.8.2 Autoconf Macros 5.8.3 Using Autoconf Macros 6 API Reference 6.1 Overview of the Guile API 6.2 Deprecation 6.3 The SCM Type 6.4 Initializing Guile 6.5 Snarfing Macros 6.6 Data Types 6.6.1 Booleans 6.6.2 Numerical data types 6.6.2.1 Scheme's Numerical "Tower" 6.6.2.2 Integers 6.6.2.3 Real and Rational Numbers 6.6.2.4 Complex Numbers 6.6.2.5 Exact and Inexact Numbers 6.6.2.6 Read Syntax for Numerical Data 6.6.2.7 Operations on Integer Values 6.6.2.8 Comparison Predicates 6.6.2.9 Converting Numbers To and From Strings 6.6.2.10 Complex Number Operations 6.6.2.11 Arithmetic Functions 6.6.2.12 Scientific Functions 6.6.2.13 Bitwise Operations 6.6.2.14 Random Number Generation 6.6.3 Characters 6.6.4 Character Sets 6.6.4.1 Character Set Predicates/Comparison 6.6.4.2 Iterating Over Character Sets 6.6.4.3 Creating Character Sets 6.6.4.4 Querying Character Sets 6.6.4.5 Character-Set Algebra 6.6.4.6 Standard Character Sets 6.6.5 Strings 6.6.5.1 String Read Syntax 6.6.5.2 String Predicates 6.6.5.3 String Constructors 6.6.5.4 List/String conversion 6.6.5.5 String Selection 6.6.5.6 String Modification 6.6.5.7 String Comparison 6.6.5.8 String Searching 6.6.5.9 Alphabetic Case Mapping 6.6.5.10 Reversing and Appending Strings 6.6.5.11 Mapping, Folding, and Unfolding 6.6.5.12 Miscellaneous String Operations 6.6.5.13 Representing Strings as Bytes 6.6.5.14 Conversion to/from C 6.6.5.15 String Internals 6.6.6 Symbols 6.6.6.1 Symbols as Discrete Data 6.6.6.2 Symbols as Lookup Keys 6.6.6.3 Symbols as Denoting Variables 6.6.6.4 Operations Related to Symbols 6.6.6.5 Extended Read Syntax for Symbols 6.6.6.6 Uninterned Symbols 6.6.7 Keywords 6.6.7.1 Why Use Keywords? 6.6.7.2 Coding With Keywords 6.6.7.3 Keyword Read Syntax 6.6.7.4 Keyword Procedures 6.6.8 Pairs 6.6.9 Lists 6.6.9.1 List Read Syntax 6.6.9.2 List Predicates 6.6.9.3 List Constructors 6.6.9.4 List Selection 6.6.9.5 Append and Reverse 6.6.9.6 List Modification 6.6.9.7 List Searching 6.6.9.8 List Mapping 6.6.10 Vectors 6.6.10.1 Read Syntax for Vectors 6.6.10.2 Dynamic Vector Creation and Validation 6.6.10.3 Accessing and Modifying Vector Contents 6.6.10.4 Vector Accessing from C 6.6.10.5 Uniform Numeric Vectors 6.6.11 Bit Vectors 6.6.12 Bytevectors 6.6.12.1 Endianness 6.6.12.2 Manipulating Bytevectors 6.6.12.3 Interpreting Bytevector Contents as Integers 6.6.12.4 Converting Bytevectors to/from Integer Lists 6.6.12.5 Interpreting Bytevector Contents as Floating Point Numbers 6.6.12.6 Interpreting Bytevector Contents as Unicode Strings 6.6.12.7 Accessing Bytevectors with the Array API 6.6.12.8 Accessing Bytevectors with the SRFI-4 API 6.6.12.9 Bytevector Procedures in R7RS 6.6.12.10 Bytevector Slices 6.6.13 Arrays 6.6.13.1 Array Syntax 6.6.13.2 Array Procedures 6.6.13.3 Shared Arrays 6.6.13.4 Arrays as arrays of arrays 6.6.13.5 Accessing Arrays from C 6.6.14 VLists 6.6.15 Record Overview 6.6.16 SRFI-9 Records Non-toplevel Record Definitions Custom Printers Functional "Setters" 6.6.17 Records 6.6.18 Structures 6.6.18.1 Vtables 6.6.18.2 Structure Basics 6.6.18.3 Vtable Contents 6.6.18.4 Meta-Vtables 6.6.18.5 Vtable Example 6.6.19 Dictionary Types 6.6.20 Association Lists 6.6.20.1 Alist Key Equality 6.6.20.2 Adding or Setting Alist Entries 6.6.20.3 Retrieving Alist Entries 6.6.20.4 Removing Alist Entries 6.6.20.5 Sloppy Alist Functions 6.6.20.6 Alist Example 6.6.21 VList-Based Hash Lists or "VHashes" 6.6.22 Hash Tables 6.6.22.1 Hash Table Examples 6.6.22.2 Hash Table Reference 6.6.23 Other Types 6.7 Procedures 6.7.1 Lambda: Basic Procedure Creation 6.7.2 Primitive Procedures 6.7.3 Compiled Procedures 6.7.4 Optional Arguments 6.7.4.1 lambda* and define*. 6.7.4.2 (ice-9 optargs) 6.7.5 Case-lambda 6.7.6 Higher-Order Functions 6.7.7 Procedure Properties and Meta-information 6.7.8 Procedures with Setters 6.7.9 Inlinable Procedures 6.8 Macros 6.8.1 Defining Macros 6.8.2 Syntax-rules Macros 6.8.2.1 Patterns 6.8.2.2 Hygiene 6.8.2.3 Shorthands 6.8.2.4 Reporting Syntax Errors in Macros 6.8.2.5 Specifying a Custom Ellipsis Identifier 6.8.2.6 Further Information 6.8.3 Support for the ‘syntax-case’ System 6.8.3.1 Why ‘syntax-case’? 6.8.3.2 Custom Ellipsis Identifiers for syntax-case Macros 6.8.3.3 Syntax objects can be data too 6.8.4 Syntax Transformer Helpers 6.8.5 Lisp-style Macro Definitions 6.8.6 Identifier Macros 6.8.7 Syntax Parameters 6.8.8 Eval-when 6.8.9 Macro Expansion 6.8.10 Hygiene and the Top-Level 6.8.11 Internal Macros 6.9 General Utility Functions 6.9.1 Equality 6.9.2 Object Properties 6.9.3 Sorting 6.9.4 Copying Deep Structures 6.9.5 General String Conversion 6.9.6 Hooks 6.9.6.1 Hook Usage by Example 6.9.6.2 Hook Reference 6.9.6.3 Hooks For C Code. 6.9.6.4 Hooks for Garbage Collection 6.9.6.5 Hooks into the Guile REPL 6.10 Definitions and Variable Bindings 6.10.1 Top Level Variable Definitions 6.10.2 Local Variable Bindings 6.10.3 Internal definitions 6.10.4 Querying variable bindings 6.10.5 Binding multiple return values 6.11 Controlling the Flow of Program Execution 6.11.1 Sequencing and Splicing 6.11.2 Simple Conditional Evaluation 6.11.3 Conditional Evaluation of a Sequence of Expressions 6.11.4 Iteration mechanisms 6.11.5 Prompts 6.11.5.1 Prompt Primitives 6.11.5.2 Shift, Reset, and All That 6.11.6 Continuations 6.11.7 Returning and Accepting Multiple Values 6.11.8 Exceptions 6.11.8.1 Exception Objects 6.11.8.2 Raising and Handling Exceptions 6.11.8.3 Throw and Catch 6.11.8.4 Exceptions and C 6.11.9 Procedures for Signaling Errors 6.11.10 Dynamic Wind 6.11.11 Fluids and Dynamic States 6.11.12 Parameters 6.11.13 How to Handle Errors 6.11.13.1 C Support 6.11.13.2 Signaling Type Errors 6.11.14 Continuation Barriers 6.12 Input and Output 6.12.1 Ports 6.12.2 Binary I/O 6.12.3 Encoding 6.12.4 Textual I/O 6.12.5 Simple Textual Output 6.12.6 Buffering 6.12.7 Random Access 6.12.8 Line Oriented and Delimited Text 6.12.9 Default Ports for Input, Output and Errors 6.12.10 Types of Port 6.12.10.1 File Ports 6.12.10.2 Bytevector Ports 6.12.10.3 String Ports 6.12.10.4 Custom Ports 6.12.10.5 Soft Ports 6.12.10.6 Void Ports 6.12.10.7 Low-Level Custom Ports 6.12.10.8 Low-Level Custom Ports in C 6.12.11 Venerable Port Interfaces 6.12.12 Using Ports from C 6.12.13 Non-Blocking I/O 6.12.14 Handling of Unicode Byte Order Marks 6.13 Regular Expressions 6.13.1 Regexp Functions 6.13.2 Match Structures 6.13.3 Backslash Escapes 6.14 LALR(1) Parsing 6.15 PEG Parsing 6.15.1 PEG Syntax Reference 6.15.2 PEG API Reference 6.15.3 PEG Tutorial 6.15.4 PEG Internals 6.16 Reading and Evaluating Scheme Code 6.16.1 Scheme Syntax: Standard and Guile Extensions 6.16.1.1 Expression Syntax 6.16.1.2 Comments 6.16.1.3 Block Comments 6.16.1.4 Case Sensitivity 6.16.1.5 Keyword Syntax 6.16.1.6 Reader Extensions 6.16.2 Reading Scheme Code 6.16.3 Reading Scheme Code, For the Compiler 6.16.4 Writing Scheme Values 6.16.5 Procedures for On the Fly Evaluation 6.16.6 Compiling Scheme Code 6.16.7 Loading Scheme Code from File 6.16.8 Load Paths 6.16.9 Character Encoding of Source Files 6.16.10 Delayed Evaluation 6.16.11 Local Evaluation 6.16.12 Local Inclusion 6.16.13 Sandboxed Evaluation 6.16.14 REPL Servers 6.16.15 Cooperative REPL Servers 6.17 Memory Management and Garbage Collection 6.17.1 Function related to Garbage Collection 6.17.2 Memory Blocks 6.17.3 Weak References 6.17.3.1 Weak hash tables 6.17.3.2 Weak vectors 6.17.4 Guardians 6.18 Modules 6.18.1 General Information about Modules 6.18.2 Using Guile Modules 6.18.3 Creating Guile Modules 6.18.4 Modules and the File System 6.18.5 R6RS Version References 6.18.6 R6RS Libraries 6.18.7 Variables 6.18.8 Module System Reflection 6.18.9 Declarative Modules 6.18.10 Accessing Modules from C 6.18.11 provide and require 6.18.12 Environments 6.19 Foreign Function Interface 6.19.1 Foreign Libraries 6.19.2 Foreign Extensions 6.19.3 Foreign Pointers 6.19.4 Foreign Types 6.19.5 Foreign Functions 6.19.6 Void Pointers and Byte Access 6.19.7 Foreign Structs 6.19.8 More Foreign Functions 6.20 Foreign Objects 6.21 Smobs 6.22 Threads, Mutexes, Asyncs and Dynamic Roots 6.22.1 Threads 6.22.2 Thread-Local Variables 6.22.3 Asynchronous Interrupts 6.22.4 Atomics 6.22.5 Mutexes and Condition Variables 6.22.6 Blocking in Guile Mode 6.22.7 Futures 6.22.8 Parallel forms 6.23 Configuration, Features and Runtime Options 6.23.1 Configuration, Build and Installation 6.23.2 Feature Tracking 6.23.2.1 Feature Manipulation 6.23.2.2 Common Feature Symbols 6.23.3 Runtime Options 6.23.3.1 Examples of option use 6.24 Support for Other Languages 6.24.1 Using Other Languages 6.24.2 Emacs Lisp 6.24.2.1 Nil 6.24.2.2 Dynamic Binding 6.24.2.3 Other Elisp Features 6.24.3 ECMAScript 6.25 Support for Internationalization 6.25.1 Internationalization with Guile 6.25.2 Text Collation 6.25.3 Character Case Mapping 6.25.4 Number Input and Output 6.25.5 Accessing Locale Information 6.25.6 Gettext Support 6.26 Debugging Infrastructure 6.26.1 Evaluation and the Scheme Stack 6.26.1.1 Stack Capture 6.26.1.2 Stacks 6.26.1.3 Frames 6.26.2 Source Properties 6.26.3 Programmatic Error Handling 6.26.3.1 Catching Exceptions 6.26.3.2 Pre-Unwind Debugging 6.26.3.3 call-with-error-handling 6.26.3.4 Stack Overflow 6.26.3.5 Debug options 6.26.4 Traps 6.26.4.1 VM Hooks 6.26.4.2 Trap Interface 6.26.4.3 Low-Level Traps 6.26.4.4 Tracing Traps 6.26.4.5 Trap States 6.26.4.6 High-Level Traps 6.26.5 GDB Support 6.27 Code Coverage Reports 7 Guile Modules 7.1 SLIB 7.1.1 SLIB installation 7.1.2 JACAL 7.2 POSIX System Calls and Networking 7.2.1 POSIX Interface Conventions 7.2.2 Ports and File Descriptors 7.2.3 File System 7.2.4 User Information 7.2.5 Time 7.2.6 Runtime Environment 7.2.7 Processes 7.2.8 Signals 7.2.9 Terminals and Ptys 7.2.10 Pipes 7.2.11 Networking 7.2.11.1 Network Address Conversion 7.2.11.2 Network Databases 7.2.11.3 Network Socket Address 7.2.11.4 Network Sockets and Communication 7.2.11.5 Network Socket Examples 7.2.12 System Identification 7.2.13 Locales 7.2.14 Encryption 7.3 HTTP, the Web, and All That 7.3.1 Types and the Web 7.3.2 Universal Resource Identifiers 7.3.3 The Hyper-Text Transfer Protocol 7.3.4 HTTP Headers 7.3.4.1 HTTP Header Types 7.3.4.2 General Headers 7.3.4.3 Entity Headers 7.3.4.4 Request Headers 7.3.4.5 Response Headers 7.3.5 Transfer Codings 7.3.6 HTTP Requests 7.3.6.1 An Important Note on Character Sets 7.3.6.2 Request API 7.3.7 HTTP Responses 7.3.8 Web Client 7.3.9 Web Server 7.3.10 Web Examples 7.3.10.1 Hello, World! 7.3.10.2 Inspecting the Request 7.3.10.3 Higher-Level Interfaces 7.3.10.4 Conclusion 7.4 The (ice-9 getopt-long) Module 7.4.1 A Short getopt-long Example 7.4.2 How to Write an Option Specification 7.4.3 Expected Command Line Format 7.4.4 Reference Documentation for ‘getopt-long’ 7.4.5 Reference Documentation for ‘option-ref’ 7.5 SRFI Support Modules 7.5.1 About SRFI Usage 7.5.2 SRFI-0 - cond-expand 7.5.3 SRFI-1 - List library 7.5.3.1 Constructors 7.5.3.2 Predicates 7.5.3.3 Selectors 7.5.3.4 Length, Append, Concatenate, etc. 7.5.3.5 Fold, Unfold & Map 7.5.3.6 Filtering and Partitioning 7.5.3.7 Searching 7.5.3.8 Deleting 7.5.3.9 Association Lists 7.5.3.10 Set Operations on Lists 7.5.4 SRFI-2 - and-let* 7.5.5 SRFI-4 - Homogeneous numeric vector datatypes 7.5.5.1 SRFI-4 - Overview 7.5.5.2 SRFI-4 - API 7.5.5.3 SRFI-4 - Relation to bytevectors 7.5.5.4 SRFI-4 - Guile extensions 7.5.6 SRFI-6 - Basic String Ports 7.5.7 SRFI-8 - receive 7.5.8 SRFI-9 - define-record-type 7.5.9 SRFI-10 - Hash-Comma Reader Extension 7.5.10 SRFI-11 - let-values 7.5.11 SRFI-13 - String Library 7.5.12 SRFI-14 - Character-set Library 7.5.13 SRFI-16 - case-lambda 7.5.14 SRFI-17 - Generalized set! 7.5.15 SRFI-18 - Multithreading support 7.5.15.1 SRFI-18 Threads 7.5.15.2 SRFI-18 Mutexes 7.5.15.3 SRFI-18 Condition variables 7.5.15.4 SRFI-18 Time 7.5.15.5 SRFI-18 Exceptions 7.5.16 SRFI-19 - Time/Date Library 7.5.16.1 SRFI-19 Introduction 7.5.16.2 SRFI-19 Time 7.5.16.3 SRFI-19 Date 7.5.16.4 SRFI-19 Time/Date conversions 7.5.16.5 SRFI-19 Date to string 7.5.16.6 SRFI-19 String to date 7.5.17 SRFI-23 - Error Reporting 7.5.18 SRFI-26 - specializing parameters 7.5.19 SRFI-27 - Sources of Random Bits 7.5.19.1 The Default Random Source 7.5.19.2 Random Sources 7.5.19.3 Obtaining random number generator procedures 7.5.20 SRFI-28 - Basic Format Strings 7.5.21 SRFI-30 - Nested Multi-line Comments 7.5.22 SRFI-31 - A special form 'rec' for recursive evaluation 7.5.23 SRFI-34 - Exception handling for programs 7.5.24 SRFI-35 - Conditions 7.5.25 SRFI-37 - args-fold 7.5.26 SRFI-38 - External Representation for Data With Shared Structure 7.5.27 SRFI-39 - Parameters 7.5.28 SRFI-41 - Streams 7.5.28.1 SRFI-41 Stream Fundamentals 7.5.28.2 SRFI-41 Stream Primitives 7.5.28.3 SRFI-41 Stream Library 7.5.29 SRFI-42 - Eager Comprehensions 7.5.30 SRFI-43 - Vector Library 7.5.30.1 SRFI-43 Constructors 7.5.30.2 SRFI-43 Predicates 7.5.30.3 SRFI-43 Selectors 7.5.30.4 SRFI-43 Iteration 7.5.30.5 SRFI-43 Searching 7.5.30.6 SRFI-43 Mutators 7.5.30.7 SRFI-43 Conversion 7.5.31 SRFI-45 - Primitives for Expressing Iterative Lazy Algorithms 7.5.32 SRFI-46 Basic syntax-rules Extensions 7.5.33 SRFI-55 - Requiring Features 7.5.34 SRFI-60 - Integers as Bits 7.5.35 SRFI-61 - A more general ‘cond’ clause 7.5.36 SRFI-62 - S-expression comments. 7.5.37 SRFI-64 - A Scheme API for test suites. 7.5.38 SRFI-67 - Compare procedures 7.5.39 SRFI-69 - Basic hash tables 7.5.39.1 Creating hash tables 7.5.39.2 Accessing table items 7.5.39.3 Table properties 7.5.39.4 Hash table algorithms 7.5.40 SRFI-71 - Extended let-syntax for multiple values 7.5.41 SRFI-87 => in case clauses 7.5.42 SRFI-88 Keyword Objects 7.5.43 SRFI-98 Accessing environment variables. 7.5.44 SRFI-105 Curly-infix expressions. 7.5.45 SRFI-111 Boxes. 7.5.46 SRFI-119 Wisp: simpler indentation-sensitive Scheme. 7.5.47 Transducers 7.5.47.1 SRFI-171 General Discussion 7.5.47.2 Applying Transducers 7.5.47.3 Reducers 7.5.47.4 Transducers 7.5.47.5 Helper functions for writing transducers 7.6 R6RS Support 7.6.1 Incompatibilities with the R6RS 7.6.2 R6RS Standard Libraries 7.6.2.1 Library Usage 7.6.2.2 rnrs base 7.6.2.3 rnrs unicode 7.6.2.4 rnrs bytevectors 7.6.2.5 rnrs lists 7.6.2.6 rnrs sorting 7.6.2.7 rnrs control 7.6.2.8 R6RS Records 7.6.2.9 rnrs records syntactic 7.6.2.10 rnrs records procedural 7.6.2.11 rnrs records inspection 7.6.2.12 rnrs exceptions 7.6.2.13 rnrs conditions 7.6.2.14 I/O Conditions 7.6.2.15 Transcoders 7.6.2.16 rnrs io ports 7.6.2.17 R6RS File Ports 7.6.2.18 rnrs io simple 7.6.2.19 rnrs files 7.6.2.20 rnrs programs 7.6.2.21 rnrs arithmetic fixnums 7.6.2.22 rnrs arithmetic flonums 7.6.2.23 rnrs arithmetic bitwise 7.6.2.24 rnrs syntax-case 7.6.2.25 rnrs hashtables 7.6.2.26 rnrs enums 7.6.2.27 rnrs 7.6.2.28 rnrs eval 7.6.2.29 rnrs mutable-pairs 7.6.2.30 rnrs mutable-strings 7.6.2.31 rnrs r5rs 7.7 R7RS Support 7.7.1 Incompatibilities with the R7RS 7.7.2 R7RS Standard Libraries 7.8 Pattern Matching 7.9 Readline Support 7.9.1 Loading Readline Support 7.9.2 Readline Options 7.9.3 Readline Functions 7.9.3.1 Readline Port 7.9.3.2 Completion 7.10 Pretty Printing 7.11 Formatted Output 7.12 File Tree Walk 7.13 Queues 7.14 Streams 7.15 Buffered Input 7.16 Expect 7.17 ‘sxml-match’: Pattern Matching of SXML Syntax Matching XML Elements Ellipses in Patterns Ellipses in Quasiquote'd Output Matching Nodesets Matching the "Rest" of a Nodeset Matching the Unmatched Attributes Default Values in Attribute Patterns Guards in Patterns Catamorphisms Named-Catamorphisms ‘sxml-match-let’ and ‘sxml-match-let*’ 7.18 The Scheme shell (scsh) 7.19 Curried Definitions 7.20 Statprof 7.21 SXML 7.21.1 SXML Overview 7.21.2 Reading and Writing XML 7.21.3 SSAX: A Functional XML Parsing Toolkit 7.21.3.1 History 7.21.3.2 Implementation 7.21.3.3 Usage 7.21.4 Transforming SXML 7.21.4.1 Overview 7.21.4.2 Usage 7.21.5 SXML Tree Fold 7.21.5.1 Overview 7.21.5.2 Usage 7.21.6 SXPath 7.21.6.1 Overview 7.21.6.2 Basic Converters and Applicators 7.21.6.3 Converter Combinators 7.21.7 (sxml ssax input-parse) 7.21.7.1 Overview 7.21.7.2 Usage 7.21.8 (sxml apply-templates) 7.21.8.1 Overview 7.21.8.2 Usage 7.22 Texinfo Processing 7.22.1 (texinfo) 7.22.1.1 Overview 7.22.1.2 Usage 7.22.2 (texinfo docbook) 7.22.2.1 Overview 7.22.2.2 Usage 7.22.3 (texinfo html) 7.22.3.1 Overview 7.22.3.2 Usage 7.22.4 (texinfo indexing) 7.22.4.1 Overview 7.22.4.2 Usage 7.22.5 (texinfo string-utils) 7.22.5.1 Overview 7.22.5.2 Usage 7.22.6 (texinfo plain-text) 7.22.6.1 Overview 7.22.6.2 Usage 7.22.7 (texinfo serialize) 7.22.7.1 Overview 7.22.7.2 Usage 7.22.8 (texinfo reflection) 7.22.8.1 Overview 7.22.8.2 Usage 8 GOOPS 8.1 Copyright Notice 8.2 Class Definition 8.3 Instance Creation and Slot Access 8.4 Slot Options 8.5 Illustrating Slot Description 8.6 Methods and Generic Functions 8.6.1 Accessors 8.6.2 Extending Primitives 8.6.3 Merging Generics 8.6.4 Next-method 8.6.5 Generic Function and Method Examples 8.6.6 Handling Invocation Errors 8.7 Inheritance 8.7.1 Class Precedence List 8.7.2 Sorting Methods 8.8 Introspection 8.8.1 Classes 8.8.2 Instances 8.8.3 Slots 8.8.4 Generic Functions 8.8.5 Accessing Slots 8.9 Error Handling 8.10 GOOPS Object Miscellany 8.11 The Metaobject Protocol 8.11.1 Metaobjects and the Metaobject Protocol 8.11.2 Metaclasses 8.11.3 MOP Specification 8.11.4 Instance Creation Protocol 8.11.5 Class Definition Protocol 8.11.6 Customizing Class Definition 8.11.7 Method Definition 8.11.8 Method Definition Internals 8.11.9 Generic Function Internals 8.11.10 Generic Function Invocation 8.12 Redefining a Class 8.12.1 Redefinable Classes 8.12.2 Default Class Redefinition Behavior 8.12.3 Customizing Class Redefinition 8.13 Changing the Class of an Instance 9 Guile Implementation 9.1 A Brief History of Guile 9.1.1 The Emacs Thesis 9.1.2 Early Days 9.1.3 A Scheme of Many Maintainers 9.1.4 A Timeline of Selected Guile Releases 9.1.5 Status, or: Your Help Needed 9.2 Data Representation 9.2.1 A Simple Representation 9.2.2 Faster Integers 9.2.3 Cheaper Pairs 9.2.4 Conservative Garbage Collection 9.2.5 The SCM Type in Guile 9.2.5.1 Relationship Between ‘SCM’ and ‘scm_t_bits’ 9.2.5.2 Immediate Objects 9.2.5.3 Non-Immediate Objects 9.2.5.4 Allocating Heap Objects 9.2.5.5 Heap Object Type Information 9.2.5.6 Accessing Heap Object Fields 9.3 A Virtual Machine for Guile 9.3.1 Why a VM? 9.3.2 VM Concepts 9.3.3 Stack Layout 9.3.4 Variables and the VM 9.3.5 Compiled Procedures are VM Programs 9.3.6 Object File Format 9.3.7 Instruction Set 9.3.7.1 Call and Return Instructions 9.3.7.2 Function Prologue Instructions 9.3.7.3 Shuffling Instructions 9.3.7.4 Trampoline Instructions 9.3.7.5 Non-Local Control Flow Instructions 9.3.7.6 Instrumentation Instructions 9.3.7.7 Intrinsic Call Instructions 9.3.7.8 Constant Instructions 9.3.7.9 Memory Access Instructions 9.3.7.10 Atomic Memory Access Instructions 9.3.7.11 Tagging and Untagging Instructions 9.3.7.12 Integer Arithmetic Instructions 9.3.7.13 Floating-Point Arithmetic Instructions 9.3.7.14 Comparison Instructions 9.3.7.15 Branch Instructions 9.3.7.16 Raw Memory Access Instructions 9.3.8 Just-In-Time Native Code 9.4 Compiling to the Virtual Machine 9.4.1 Compiler Tower 9.4.2 The Scheme Compiler 9.4.3 Tree-IL 9.4.4 Continuation-Passing Style 9.4.4.1 An Introduction to CPS 9.4.4.2 CPS in Guile 9.4.4.3 Building CPS 9.4.4.4 CPS Soup 9.4.4.5 Compiling CPS 9.4.5 Bytecode 9.4.6 Writing New High-Level Languages 9.4.7 Extending the Compiler Appendix A GNU Free Documentation License Concept Index Procedure Index Variable Index Type Index R5RS Index Preface ******* This manual describes how to use Guile, GNU's Ubiquitous Intelligent Language for Extensions. It relates particularly to Guile version 3.0.10. Contributors to this Manual =========================== Like Guile itself, the Guile reference manual is a living entity, cared for by many people over a long period of time. As such, it is hard to identify individuals of whom to say "yes, this single person wrote the manual." Still, among the many contributions, some caretakers stand out. First among them is Neil Jerram, who has worked on this document for over ten years. Neil's attention both to detail and to the big picture have made a real difference in the understanding of a generation of Guile hackers. Next we should note Marius Vollmer's effect on this document. Marius maintained Guile during a period in which Guile's API was clarified--put to the fire, so to speak--and he had the good sense to effect the same change on the manual. Martin Grabmueller made substantial contributions throughout the manual in preparation for the Guile 1.6 release, including filling out a lot of the documentation of Scheme data types, control mechanisms and procedures. In addition, he wrote the documentation for Guile's SRFI modules and modules associated with the Guile REPL. Ludovic Courtès and Andy Wingo, who co-maintain Guile since 2010, along with Mark Weaver, have also made their dent in the manual, writing documentation for new modules and subsystems that arrived with Guile 2.0. Ludovic, Andy, and Mark are also responsible for ensuring that the existing text retains its relevance as Guile evolves. *Note Reporting Bugs::, for more information on reporting problems in this manual. The content for the first versions of this manual incorporated and was inspired by documents from Aubrey Jaffer, author of the SCM system on which Guile was based, and from Tom Lord, Guile's first maintainer. Although most of this text has been rewritten, all of it was important, and some of the structure remains. The manual for the first versions of Guile were largely written, edited, and compiled by Mark Galassi and Jim Blandy. In particular, Jim wrote the original tutorial on Guile's data representation and the C API for accessing Guile objects. Significant portions were also contributed by Thien-Thi Nguyen, Kevin Ryde, Mikael Djurfeldt, Christian Lynbech, Julian Graham, Gary Houston, Tim Pierce, and a few dozen more. You, reader, are most welcome to join their esteemed ranks. Visit Guile's web site at to find out how to get involved. The Guile License ================= Guile is Free Software. Guile is copyrighted, not public domain, and there are restrictions on its distribution or redistribution, but these restrictions are designed to permit everything a cooperating person would want to do. • The Guile library (libguile) and supporting files are published under the terms of the GNU Lesser General Public License version 3 or later. See the files ‘COPYING.LESSER’ and ‘COPYING’. • The Guile readline module is published under the terms of the GNU General Public License version 3 or later. See the file ‘COPYING’. • The manual you're now reading is published under the terms of the GNU Free Documentation License (*note GNU Free Documentation License::). C code linking to the Guile library is subject to terms of that library. Basically such code may be published on any terms, provided users can re-link against a new or modified version of Guile. C code linking to the Guile readline module is subject to the terms of that module. Basically such code must be published on Free terms. Scheme level code written to be run by Guile (but not derived from Guile itself) is not restricted in any way, and may be published on any terms. We encourage authors to publish on Free terms. You must be aware there is no warranty whatsoever for Guile. This is described in full in the licenses. 1 Introduction ************** Guile is an implementation of the Scheme programming language. Scheme () is an elegant and conceptually simple dialect of Lisp, originated by Guy Steele and Gerald Sussman, and since evolved by the series of reports known as RnRS (the Revised^n Reports on Scheme). There are many Scheme implementations, with different characteristics and with communities and academic activities around them, and the language develops as a result of the interplay between these. Guile's particular characteristics are that • it is easy to combine with other code written in C • it has a historical and continuing connection with the GNU Project • it emphasizes interactive and incremental programming • it actually supports several languages, not just Scheme. The next few sections explain what we mean by these points. The sections after that cover how you can obtain and install Guile, and the typographical conventions that we use in this manual. 1.1 Guile and Scheme ==================== Guile implements Scheme as described in the Revised^5 Report on the Algorithmic Language Scheme (usually known as R5RS), providing clean and general data and control structures. Guile goes beyond the rather austere language presented in R5RS, extending it with a module system, full access to POSIX system calls, networking support, multiple threads, dynamic linking, a foreign function call interface, powerful string processing, and many other features needed for programming in the real world. In 2007, the Scheme community agreed upon and published R6RS, a significant installment in the RnRS series. R6RS expands the core Scheme language, and standardises many non-core functions that implementations--including Guile--have previously done in different ways. Over time, Guile has been updated to incorporate almost all of the features of R6RS, and to adjust some existing features to conform to the R6RS specification. *Note R6RS Support::, for full details. In parallel to official standardization efforts, the SRFI process () standardises interfaces for many practical needs, such as multithreaded programming and multidimensional arrays. Guile supports many SRFIs, as documented in detail in *note SRFI Support::. The process that led to the R6RS standard brought a split in the Scheme community to the surface. The implementors that wrote R6RS considered that it was impossible to write useful, portable programs in R5RS, and that only an ambitious standard could solve this problem. However, part of the Scheme world saw the R6RS effort as too broad, and as having included some components that would never be adopted by more minimalistic Scheme implementations. This second group succeeded in taking control of the official Scheme standardization track and in 2013 released a more limited R7RS, essentially consisting of R5RS, plus a module system. Guile supports R7RS also. *Note R7RS Support::. With R6RS and R7RS, the unified Scheme standardization process appears to have more or less run its course. There will continue to be more code written in terms of both systems, and modules defined using the SRFI process, and Guile will support both. However for future directions, Guile takes inspiration from other related language communities: Racket, Clojure, Concurrent ML, and so on. In summary, Guile supports writing and running code written to the R5RS, R6RS, and R7RS Scheme standards, and also supports a number of SRFI modules. However for most users, until a need for cross-implementation portability has been identified, we recommend using the parts of Guile that are useful in solving the problem at hand, regardless of whether they proceed from a standard or whether they are Guile-specific. 1.2 Combining with C Code ========================= Like a shell, Guile can run interactively--reading expressions from the user, evaluating them, and displaying the results--or as a script interpreter, reading and executing Scheme code from a file. Guile also provides an object library, “libguile”, that allows other applications to easily incorporate a complete Scheme interpreter. An application can then use Guile as an extension language, a clean and powerful configuration language, or as multi-purpose "glue", connecting primitives provided by the application. It is easy to call Scheme code from C code and vice versa, giving the application designer full control of how and when to invoke the interpreter. Applications can add new functions, data types, control structures, and even syntax to Guile, creating a domain-specific language tailored to the task at hand, but based on a robust language design. This kind of combination is helped by four aspects of Guile's design and history. First is that Guile has always been targeted as an extension language. Hence its C API has always been of great importance, and has been developed accordingly. Second and third are rather technical points--that Guile uses conservative garbage collection, and that it implements the Scheme concept of continuations by copying and reinstating the C stack--but whose practical consequence is that most existing C code can be glued into Guile as is, without needing modifications to cope with strange Scheme execution flows. Last is the module system, which helps extensions to coexist without stepping on each others' toes. Guile's module system allows one to break up a large program into manageable sections with well-defined interfaces between them. Modules may contain a mixture of interpreted and compiled code; Guile can use either static or dynamic linking to incorporate compiled code. Modules also encourage developers to package up useful collections of routines for general distribution; as of this writing, one can find Emacs interfaces, database access routines, compilers, GUI toolkit interfaces, and HTTP client functions, among others. 1.3 Guile and the GNU Project ============================= Guile was conceived by the GNU Project following the fantastic success of Emacs Lisp as an extension language within Emacs. Just as Emacs Lisp allowed complete and unanticipated applications to be written within the Emacs environment, the idea was that Guile should do the same for other GNU Project applications. This remains true today. The idea of extensibility is closely related to the GNU project's primary goal, that of promoting software freedom. Software freedom means that people receiving a software package can modify or enhance it to their own desires, including in ways that may not have occurred at all to the software's original developers. For programs written in a compiled language like C, this freedom covers modifying and rebuilding the C code; but if the program also provides an extension language, that is usually a much friendlier and lower-barrier-of-entry way for the user to start making their own changes. Guile is now used by GNU project applications such as AutoGen, Lilypond, Denemo, Mailutils, TeXmacs and Gnucash, and we hope that there will be many more in future. 1.4 Interactive Programming =========================== Non-free software has no interest in its users being able to see how it works. They are supposed to just accept it, or to report problems and hope that the source code owners will choose to work on them. Free software aims to work reliably just as much as non-free software does, but it should also empower its users by making its workings available. This is useful for many reasons, including education, auditing and enhancements, as well as for debugging problems. The ideal free software system achieves this by making it easy for interested users to see the source code for a feature that they are using, and to follow through that source code step-by-step, as it runs. In Emacs, good examples of this are the source code hyperlinks in the help system, and ‘edebug’. Then, for bonus points and maximising the ability for the user to experiment quickly with code changes, the system should allow parts of the source code to be modified and reloaded into the running program, to take immediate effect. Guile is designed for this kind of interactive programming, and this distinguishes it from many Scheme implementations that instead prioritise running a fixed Scheme program as fast as possible--because there are tradeoffs between performance and the ability to modify parts of an already running program. There are faster Schemes than Guile, but Guile is a GNU project and so prioritises the GNU vision of programming freedom and experimentation. 1.5 Supporting Multiple Languages ================================= Since the 2.0 release, Guile's architecture supports compiling any language to its core virtual machine bytecode, and Scheme is just one of the supported languages. Other supported languages are Emacs Lisp, ECMAScript (commonly known as Javascript) and Brainfuck, and work is under discussion for Lua, Ruby and Python. This means that users can program applications which use Guile in the language of their choice, rather than having the tastes of the application's author imposed on them. 1.6 Obtaining and Installing Guile ================================== Guile can be obtained from the main GNU archive site or any of its mirrors. The file will be named guile-VERSION.tar.gz. The current version is 3.0.10, so the file you should grab is: To unbundle Guile use the instruction zcat guile-3.0.10.tar.gz | tar xvf - which will create a directory called ‘guile-3.0.10’ with all the sources. You can look at the file ‘INSTALL’ for detailed instructions on how to build and install Guile, but you should be able to just do cd guile-3.0.10 ./configure make make install This will install the Guile executable ‘guile’, the Guile library ‘libguile’ and various associated header files and support libraries. It will also install the Guile reference manual. Since this manual frequently refers to the Scheme "standard", also known as R5RS, or the "Revised^5 Report on the Algorithmic Language Scheme", we have included the report in the Guile distribution; see *note Introduction: (r5rs)Top. This will also be installed in your info directory. 1.7 Organisation of this Manual =============================== The rest of this manual is organised into the following chapters. *Chapter 2: Hello Guile!* A whirlwind tour shows how Guile can be used interactively and as a script interpreter, how to link Guile into your own applications, and how to write modules of interpreted and compiled code for use with Guile. Everything introduced here is documented again and in full by the later parts of the manual. *Chapter 3: Hello Scheme!* For readers new to Scheme, this chapter provides an introduction to the basic ideas of the Scheme language. This material would apply to any Scheme implementation and so does not make reference to anything Guile-specific. *Chapter 4: Programming in Scheme* Provides an overview of programming in Scheme with Guile. It covers how to invoke the ‘guile’ program from the command-line and how to write scripts in Scheme. It also introduces the extensions that Guile offers beyond standard Scheme. *Chapter 5: Programming in C* Provides an overview of how to use Guile in a C program. It discusses the fundamental concepts that you need to understand to access the features of Guile, such as dynamic types and the garbage collector. It explains in a tutorial like manner how to define new data types and functions for the use by Scheme programs. *Chapter 6: Guile API Reference* This part of the manual documents the Guile API in functionality-based groups with the Scheme and C interfaces presented side by side. *Chapter 7: Guile Modules* Describes some important modules, distributed as part of the Guile distribution, that extend the functionality provided by the Guile Scheme core. *Chapter 8: GOOPS* Describes GOOPS, an object oriented extension to Guile that provides classes, multiple inheritance and generic functions. 1.8 Typographical Conventions ============================= In examples and procedure descriptions and all other places where the evaluation of Scheme expression is shown, we use some notation for denoting the output and evaluation results of expressions. The symbol ‘⇒’ is used to tell which value is returned by an evaluation: (+ 1 2) ⇒ 3 Some procedures produce some output besides returning a value. This is denoted by the symbol ‘⊣’. (begin (display 1) (newline) 'hooray) ⊣ 1 ⇒ hooray As you can see, this code prints ‘1’ (denoted by ‘⊣’), and returns ‘hooray’ (denoted by ‘⇒’). 2 Hello Guile! ************** This chapter presents a quick tour of all the ways that Guile can be used. There are additional examples in the ‘examples/’ directory in the Guile source distribution. It also explains how best to report any problems that you find. The following examples assume that Guile has been installed in ‘/usr/local/’. 2.1 Running Guile Interactively =============================== In its simplest form, Guile acts as an interactive interpreter for the Scheme programming language, reading and evaluating Scheme expressions the user enters from the terminal. Here is a sample interaction between Guile and a user; the user's input appears after the ‘$’ and ‘scheme@(guile-user)>’ prompts: $ guile scheme@(guile-user)> (+ 1 2 3) ; add some numbers $1 = 6 scheme@(guile-user)> (define (factorial n) ; define a function (if (zero? n) 1 (* n (factorial (- n 1))))) scheme@(guile-user)> (factorial 20) $2 = 2432902008176640000 scheme@(guile-user)> (getpwnam "root") ; look in /etc/passwd $3 = #("root" "x" 0 0 "root" "/root" "/bin/bash") scheme@(guile-user)> C-d $ 2.2 Running Guile Scripts ========================= Like AWK, Perl, or any shell, Guile can interpret script files. A Guile script is simply a file of Scheme code with some extra information at the beginning which tells the operating system how to invoke Guile, and then tells Guile how to handle the Scheme code. Here is a trivial Guile script. *Note Guile Scripting::, for more details. #!/usr/local/bin/guile -s !# (display "Hello, world!") (newline) 2.3 Linking Guile into Programs =============================== The Guile interpreter is available as an object library, to be linked into applications using Scheme as a configuration or extension language. Here is ‘simple-guile.c’, source code for a program that will produce a complete Guile interpreter. In addition to all usual functions provided by Guile, it will also offer the function ‘my-hostname’. #include #include static SCM my_hostname (void) { char *s = getenv ("HOSTNAME"); if (s == NULL) return SCM_BOOL_F; else return scm_from_locale_string (s); } static void inner_main (void *data, int argc, char **argv) { scm_c_define_gsubr ("my-hostname", 0, 0, 0, my_hostname); scm_shell (argc, argv); } int main (int argc, char **argv) { scm_boot_guile (argc, argv, inner_main, 0); return 0; /* never reached */ } When Guile is correctly installed on your system, the above program can be compiled and linked like this: $ gcc -o simple-guile simple-guile.c \ `pkg-config --cflags --libs guile-3.0` When it is run, it behaves just like the ‘guile’ program except that you can also call the new ‘my-hostname’ function. $ ./simple-guile scheme@(guile-user)> (+ 1 2 3) $1 = 6 scheme@(guile-user)> (my-hostname) "burns" 2.4 Writing Guile Extensions ============================ You can link Guile into your program and make Scheme available to the users of your program. You can also link your library into Guile and make its functionality available to all users of Guile. A library that is linked into Guile is called an “extension”, but it really just is an ordinary object library. The following example shows how to write a simple extension for Guile that makes the ‘j0’ function available to Scheme code. #include #include SCM j0_wrapper (SCM x) { return scm_from_double (j0 (scm_to_double (x))); } void init_bessel () { scm_c_define_gsubr ("j0", 1, 0, 0, j0_wrapper); } This C source file needs to be compiled into a shared library. Here is how to do it on GNU/Linux: gcc `pkg-config --cflags guile-3.0` \ -shared -o libguile-bessel.so -fPIC bessel.c For creating shared libraries portably, we recommend the use of GNU Libtool (*note Introduction: (libtool)Top.). A shared library can be loaded into a running Guile process with the function ‘load-extension’. The ‘j0’ is then immediately available: $ guile scheme@(guile-user)> (load-extension "./libguile-bessel" "init_bessel") scheme@(guile-user)> (j0 2) $1 = 0.223890779141236 For more on how to install your extension, *note Installing Site Packages::. 2.5 Using the Guile Module System ================================= Guile has support for dividing a program into “modules”. By using modules, you can group related code together and manage the composition of complete programs from largely independent parts. For more details on the module system beyond this introductory material, *Note Modules::. 2.5.1 Using Modules ------------------- Guile comes with a lot of useful modules, for example for string processing or command line parsing. Additionally, there exist many Guile modules written by other Guile hackers, but which have to be installed manually. Here is a sample interactive session that shows how to use the ‘(ice-9 popen)’ module which provides the means for communicating with other processes over pipes together with the ‘(ice-9 rdelim)’ module that provides the function ‘read-line’. $ guile scheme@(guile-user)> (use-modules (ice-9 popen)) scheme@(guile-user)> (use-modules (ice-9 rdelim)) scheme@(guile-user)> (define p (open-input-pipe "ls -l")) scheme@(guile-user)> (read-line p) $1 = "total 30" scheme@(guile-user)> (read-line p) $2 = "drwxr-sr-x 2 mgrabmue mgrabmue 1024 Mar 29 19:57 CVS" 2.5.2 Writing new Modules ------------------------- You can create new modules using the syntactic form ‘define-module’. All definitions following this form until the next ‘define-module’ are placed into the new module. One module is usually placed into one file, and that file is installed in a location where Guile can automatically find it. The following session shows a simple example. $ cat /usr/local/share/guile/site/foo/bar.scm (define-module (foo bar) #:export (frob)) (define (frob x) (* 2 x)) $ guile scheme@(guile-user)> (use-modules (foo bar)) scheme@(guile-user)> (frob 12) $1 = 24 For more on how to install your module, *note Installing Site Packages::. 2.5.3 Putting Extensions into Modules ------------------------------------- In addition to Scheme code you can also put things that are defined in C into a module. You do this by writing a small Scheme file that defines the module and call ‘load-extension’ directly in the body of the module. $ cat /usr/local/share/guile/site/math/bessel.scm (define-module (math bessel) #:export (j0)) (load-extension "libguile-bessel" "init_bessel") $ file /usr/local/lib/guile/3.0/extensions/libguile-bessel.so ... ELF 32-bit LSB shared object ... $ guile scheme@(guile-user)> (use-modules (math bessel)) scheme@(guile-user)> (j0 2) $1 = 0.223890779141236 *Note Foreign Extensions::, for more information. 2.6 Reporting Bugs ================== Any problems with the installation should be reported to . If you find a bug in Guile, please report it to the Guile developers, so they can fix it. They may also be able to suggest workarounds when it is not possible for you to apply the bug-fix or install a new version of Guile yourself. Before sending in bug reports, please check with the following list that you really have found a bug. • Whenever documentation and actual behavior differ, you have certainly found a bug, either in the documentation or in the program. • When Guile crashes, it is a bug. • When Guile hangs or takes forever to complete a task, it is a bug. • When calculations produce wrong results, it is a bug. • When Guile signals an error for valid Scheme programs, it is a bug. • When Guile does not signal an error for invalid Scheme programs, it may be a bug, unless this is explicitly documented. • When some part of the documentation is not clear and does not make sense to you even after re-reading the section, it is a bug. Before reporting the bug, check whether any programs you have loaded into Guile, including your ‘.guile’ file, set any variables that may affect the functioning of Guile. Also, see whether the problem happens in a freshly started Guile without loading your ‘.guile’ file (start Guile with the ‘-q’ switch to prevent loading the init file). If the problem does _not_ occur then, you must report the precise contents of any programs that you must load into Guile in order to cause the problem to occur. When you write a bug report, please make sure to include as much of the information described below in the report. If you can't figure out some of the items, it is not a problem, but the more information we get, the more likely we can diagnose and fix the bug. • The version number of Guile. You can get this information from invoking ‘guile --version’ at your shell, or calling ‘(version)’ from within Guile. • Your machine type, as determined by the ‘config.guess’ shell script. If you have a Guile checkout, this file is located in ‘build-aux’; otherwise you can fetch the latest version from . $ build-aux/config.guess x86_64-unknown-linux-gnu • If you installed Guile from a binary package, the version of that package. On systems that use RPM, use ‘rpm -qa | grep guile’. On systems that use DPKG, ‘dpkg -l | grep guile’. • If you built Guile yourself, the build configuration that you used: $ ./config.status --config '--enable-error-on-warning' '--disable-deprecated'... • A complete description of how to reproduce the bug. If you have a Scheme program that produces the bug, please include it in the bug report. If your program is too big to include, please try to reduce your code to a minimal test case. If you can reproduce your problem at the REPL, that is best. Give a transcript of the expressions you typed at the REPL. • A description of the incorrect behavior. For example, "The Guile process gets a fatal signal," or, "The resulting output is as follows, which I think is wrong." If the manifestation of the bug is a Guile error message, it is important to report the precise text of the error message, and a backtrace showing how the Scheme program arrived at the error. This can be done using the ‘,backtrace’ command in Guile's debugger. If your bug causes Guile to crash, additional information from a low-level debugger such as GDB might be helpful. If you have built Guile yourself, you can run Guile under GDB via the ‘meta/gdb-uninstalled-guile’ script. Instead of invoking Guile as usual, invoke the wrapper script, type ‘run’ to start the process, then ‘backtrace’ when the crash comes. Include that backtrace in your report. 3 Hello Scheme! *************** In this chapter, we introduce the basic concepts that underpin the elegance and power of the Scheme language. Readers who already possess a background knowledge of Scheme may happily skip this chapter. For the reader who is new to the language, however, the following discussions on data, procedures, expressions and closure are designed to provide a minimum level of Scheme understanding that is more or less assumed by the chapters that follow. The style of this introductory material aims about halfway between the terse precision of R5RS and the discursiveness of existing Scheme tutorials. For pointers to useful Scheme resources on the web, please see *note Further Reading::. 3.1 Data Types, Values and Variables ==================================== This section discusses the representation of data types and values, what it means for Scheme to be a “latently typed” language, and the role of variables. We conclude by introducing the Scheme syntaxes for defining a new variable, and for changing the value of an existing variable. 3.1.1 Latent Typing ------------------- The term “latent typing” is used to describe a computer language, such as Scheme, for which you cannot, _in general_, simply look at a program's source code and determine what type of data will be associated with a particular variable, or with the result of a particular expression. Sometimes, of course, you _can_ tell from the code what the type of an expression will be. If you have a line in your program that sets the variable ‘x’ to the numeric value 1, you can be certain that, immediately after that line has executed (and in the absence of multiple threads), ‘x’ has the numeric value 1. Or if you write a procedure that is designed to concatenate two strings, it is likely that the rest of your application will always invoke this procedure with two string parameters, and quite probable that the procedure would go wrong in some way if it was ever invoked with parameters that were not both strings. Nevertheless, the point is that there is nothing in Scheme which requires the procedure parameters always to be strings, or ‘x’ always to hold a numeric value, and there is no way of declaring in your program that such constraints should always be obeyed. In the same vein, there is no way to declare the expected type of a procedure's return value. Instead, the types of variables and expressions are only known - in general - at run time. If you _need_ to check at some point that a value has the expected type, Scheme provides run time procedures that you can invoke to do so. But equally, it can be perfectly valid for two separate invocations of the same procedure to specify arguments with different types, and to return values with different types. The next subsection explains what this means in practice, for the ways that Scheme programs use data types, values and variables. 3.1.2 Values and Variables -------------------------- Scheme provides many data types that you can use to represent your data. Primitive types include characters, strings, numbers and procedures. Compound types, which allow a group of primitive and compound values to be stored together, include lists, pairs, vectors and multi-dimensional arrays. In addition, Guile allows applications to define their own data types, with the same status as the built-in standard Scheme types. As a Scheme program runs, values of all types pop in and out of existence. Sometimes values are stored in variables, but more commonly they pass seamlessly from being the result of one computation to being one of the parameters for the next. Consider an example. A string value is created because the interpreter reads in a literal string from your program's source code. Then a numeric value is created as the result of calculating the length of the string. A second numeric value is created by doubling the calculated length. Finally the program creates a list with two elements - the doubled length and the original string itself - and stores this list in a program variable. All of the values involved here - in fact, all values in Scheme - carry their type with them. In other words, every value "knows," at runtime, what kind of value it is. A number, a string, a list, whatever. A variable, on the other hand, has no fixed type. A variable - ‘x’, say - is simply the name of a location - a box - in which you can store any kind of Scheme value. So the same variable in a program may hold a number at one moment, a list of procedures the next, and later a pair of strings. The "type" of a variable - insofar as the idea is meaningful at all - is simply the type of whatever value the variable happens to be storing at a particular moment. 3.1.3 Defining and Setting Variables ------------------------------------ To define a new variable, you use Scheme's ‘define’ syntax like this: (define VARIABLE-NAME VALUE) This makes a new variable called VARIABLE-NAME and stores VALUE in it as the variable's initial value. For example: ;; Make a variable `x' with initial numeric value 1. (define x 1) ;; Make a variable `organization' with an initial string value. (define organization "Free Software Foundation") (In Scheme, a semicolon marks the beginning of a comment that continues until the end of the line. So the lines beginning ‘;;’ are comments.) Changing the value of an already existing variable is very similar, except that ‘define’ is replaced by the Scheme syntax ‘set!’, like this: (set! VARIABLE-NAME NEW-VALUE) Remember that variables do not have fixed types, so NEW-VALUE may have a completely different type from whatever was previously stored in the location named by VARIABLE-NAME. Both of the following examples are therefore correct. ;; Change the value of `x' to 5. (set! x 5) ;; Change the value of `organization' to the FSF's street number. (set! organization 545) In these examples, VALUE and NEW-VALUE are literal numeric or string values. In general, however, VALUE and NEW-VALUE can be any Scheme expression. Even though we have not yet covered the forms that Scheme expressions can take (*note About Expressions::), you can probably guess what the following ‘set!’ example does... (set! x (+ x 1)) (Note: this is not a complete description of ‘define’ and ‘set!’, because we need to introduce some other aspects of Scheme before the missing pieces can be filled in. If, however, you are already familiar with the structure of Scheme, you may like to read about those missing pieces immediately by jumping ahead to the following references. • *note Lambda Alternatives::, to read about an alternative form of the ‘define’ syntax that can be used when defining new procedures. • *note Procedures with Setters::, to read about an alternative form of the ‘set!’ syntax that helps with changing a single value in the depths of a compound data structure.) • *Note Internal Definitions::, to read about using ‘define’ other than at top level in a Scheme program, including a discussion of when it works to use ‘define’ rather than ‘set!’ to change the value of an existing variable. 3.2 The Representation and Use of Procedures ============================================ This section introduces the basics of using and creating Scheme procedures. It discusses the representation of procedures as just another kind of Scheme value, and shows how procedure invocation expressions are constructed. We then explain how ‘lambda’ is used to create new procedures, and conclude by presenting the various shorthand forms of ‘define’ that can be used instead of writing an explicit ‘lambda’ expression. 3.2.1 Procedures as Values -------------------------- One of the great simplifications of Scheme is that a procedure is just another type of value, and that procedure values can be passed around and stored in variables in exactly the same way as, for example, strings and lists. When we talk about a built-in standard Scheme procedure such as ‘open-input-file’, what we actually mean is that there is a pre-defined top level variable called ‘open-input-file’, whose value is a procedure that implements what R5RS says that ‘open-input-file’ should do. Note that this is quite different from many dialects of Lisp -- including Emacs Lisp -- in which a program can use the same name with two quite separate meanings: one meaning identifies a Lisp function, while the other meaning identifies a Lisp variable, whose value need have nothing to do with the function that is associated with the first meaning. In these dialects, functions and variables are said to live in different “namespaces”. In Scheme, on the other hand, all names belong to a single unified namespace, and the variables that these names identify can hold any kind of Scheme value, including procedure values. One consequence of the "procedures as values" idea is that, if you don't happen to like the standard name for a Scheme procedure, you can change it. For example, ‘call-with-current-continuation’ is a very important standard Scheme procedure, but it also has a very long name! So, many programmers use the following definition to assign the same procedure value to the more convenient name ‘call/cc’. (define call/cc call-with-current-continuation) Let's understand exactly how this works. The definition creates a new variable ‘call/cc’, and then sets its value to the value of the variable ‘call-with-current-continuation’; the latter value is a procedure that implements the behavior that R5RS specifies under the name "call-with-current-continuation". So ‘call/cc’ ends up holding this value as well. Now that ‘call/cc’ holds the required procedure value, you could choose to use ‘call-with-current-continuation’ for a completely different purpose, or just change its value so that you will get an error if you accidentally use ‘call-with-current-continuation’ as a procedure in your program rather than ‘call/cc’. For example: (set! call-with-current-continuation "Not a procedure any more!") Or you could just leave ‘call-with-current-continuation’ as it was. It's perfectly fine for more than one variable to hold the same procedure value. 3.2.2 Simple Procedure Invocation --------------------------------- A procedure invocation in Scheme is written like this: (PROCEDURE [ARG1 [ARG2 ...]]) In this expression, PROCEDURE can be any Scheme expression whose value is a procedure. Most commonly, however, PROCEDURE is simply the name of a variable whose value is a procedure. For example, ‘string-append’ is a standard Scheme procedure whose behavior is to concatenate together all the arguments, which are expected to be strings, that it is given. So the expression (string-append "/home" "/" "andrew") is a procedure invocation whose result is the string value ‘"/home/andrew"’. Similarly, ‘string-length’ is a standard Scheme procedure that returns the length of a single string argument, so (string-length "abc") is a procedure invocation whose result is the numeric value 3. Each of the parameters in a procedure invocation can itself be any Scheme expression. Since a procedure invocation is itself a type of expression, we can put these two examples together to get (string-length (string-append "/home" "/" "andrew")) -- a procedure invocation whose result is the numeric value 12. (You may be wondering what happens if the two examples are combined the other way round. If we do this, we can make a procedure invocation expression that is _syntactically_ correct: (string-append "/home" (string-length "abc")) but when this expression is executed, it will cause an error, because the result of ‘(string-length "abc")’ is a numeric value, and ‘string-append’ is not designed to accept a numeric value as one of its arguments.) 3.2.3 Creating and Using a New Procedure ---------------------------------------- Scheme has lots of standard procedures, and Guile provides all of these via predefined top level variables. All of these standard procedures are documented in the later chapters of this reference manual. Before very long, though, you will want to create new procedures that encapsulate aspects of your own applications' functionality. To do this, you can use the famous ‘lambda’ syntax. For example, the value of the following Scheme expression (lambda (name address) BODY ...) is a newly created procedure that takes two arguments: ‘name’ and ‘address’. The behavior of the new procedure is determined by the sequence of expressions and definitions in the BODY of the procedure definition. (Typically, BODY would use the arguments in some way, or else there wouldn't be any point in giving them to the procedure.) When invoked, the new procedure returns a value that is the value of the last expression in the BODY. To make things more concrete, let's suppose that the two arguments are both strings, and that the purpose of this procedure is to form a combined string that includes these arguments. Then the full lambda expression might look like this: (lambda (name address) (string-append "Name=" name ":Address=" address)) We noted in the previous subsection that the PROCEDURE part of a procedure invocation expression can be any Scheme expression whose value is a procedure. But that's exactly what a lambda expression is! So we can use a lambda expression directly in a procedure invocation, like this: ((lambda (name address) (string-append "Name=" name ":Address=" address)) "FSF" "Cambridge") This is a valid procedure invocation expression, and its result is the string: "Name=FSF:Address=Cambridge" It is more common, though, to store the procedure value in a variable -- (define make-combined-string (lambda (name address) (string-append "Name=" name ":Address=" address))) -- and then to use the variable name in the procedure invocation: (make-combined-string "FSF" "Cambridge") Which has exactly the same result. It's important to note that procedures created using ‘lambda’ have exactly the same status as the standard built in Scheme procedures, and can be invoked, passed around, and stored in variables in exactly the same ways. 3.2.4 Lambda Alternatives ------------------------- Since it is so common in Scheme programs to want to create a procedure and then store it in a variable, there is an alternative form of the ‘define’ syntax that allows you to do just that. A ‘define’ expression of the form (define (NAME [ARG1 [ARG2 ...]]) BODY ...) is exactly equivalent to the longer form (define NAME (lambda ([ARG1 [ARG2 ...]]) BODY ...)) So, for example, the definition of ‘make-combined-string’ in the previous subsection could equally be written: (define (make-combined-string name address) (string-append "Name=" name ":Address=" address)) This kind of procedure definition creates a procedure that requires exactly the expected number of arguments. There are two further forms of the ‘lambda’ expression, which create a procedure that can accept a variable number of arguments: (lambda (ARG1 ... . ARGS) BODY ...) (lambda ARGS BODY ...) The corresponding forms of the alternative ‘define’ syntax are: (define (NAME ARG1 ... . ARGS) BODY ...) (define (NAME . ARGS) BODY ...) For details on how these forms work, see *Note Lambda::. Prior to Guile 2.0, Guile provided an extension to ‘define’ syntax that allowed you to nest the previous extension up to an arbitrary depth. These are no longer provided by default, and instead have been moved to *note Curried Definitions::. (It could be argued that the alternative ‘define’ forms are rather confusing, especially for newcomers to the Scheme language, as they hide both the role of ‘lambda’ and the fact that procedures are values that are stored in variables in the same way as any other kind of value. On the other hand, they are very convenient, and they are also a good example of another of Scheme's powerful features: the ability to specify arbitrary syntactic transformations at run time, which can be applied to subsequently read input.) 3.3 Expressions and Evaluation ============================== So far, we have met expressions that _do_ things, such as the ‘define’ expressions that create and initialize new variables, and we have also talked about expressions that have _values_, for example the value of the procedure invocation expression: (string-append "/home" "/" "andrew") but we haven't yet been precise about what causes an expression like this procedure invocation to be reduced to its "value", or how the processing of such expressions relates to the execution of a Scheme program as a whole. This section clarifies what we mean by an expression's value, by introducing the idea of “evaluation”. It discusses the side effects that evaluation can have, explains how each of the various types of Scheme expression is evaluated, and describes the behavior and use of the Guile REPL as a mechanism for exploring evaluation. The section concludes with a very brief summary of Scheme's common syntactic expressions. 3.3.1 Evaluating Expressions and Executing Programs --------------------------------------------------- In Scheme, the process of executing an expression is known as “evaluation”. Evaluation has two kinds of result: • the “value” of the evaluated expression • the “side effects” of the evaluation, which consist of any effects of evaluating the expression that are not represented by the value. Of the expressions that we have met so far, ‘define’ and ‘set!’ expressions have side effects -- the creation or modification of a variable -- but no value; ‘lambda’ expressions have values -- the newly constructed procedures -- but no side effects; and procedure invocation expressions, in general, have either values, or side effects, or both. It is tempting to try to define more intuitively what we mean by "value" and "side effects", and what the difference between them is. In general, though, this is extremely difficult. It is also unnecessary; instead, we can quite happily define the behavior of a Scheme program by specifying how Scheme executes a program as a whole, and then by describing the value and side effects of evaluation for each type of expression individually. So, some(1) definitions... • A Scheme program consists of a sequence of expressions. • A Scheme interpreter executes the program by evaluating these expressions in order, one by one. • An expression can be • a piece of literal data, such as a number ‘2.3’ or a string ‘"Hello world!"’ • a variable name • a procedure invocation expression • one of Scheme's special syntactic expressions. The following subsections describe how each of these types of expression is evaluated. ---------- Footnotes ---------- (1) These definitions are approximate. For the whole and detailed truth, see *note R5RS syntax: (r5rs)Formal syntax and semantics. 3.3.1.1 Evaluating Literal Data ............................... When a literal data expression is evaluated, the value of the expression is simply the value that the expression describes. The evaluation of a literal data expression has no side effects. So, for example, • the value of the expression ‘"abc"’ is the string value ‘"abc"’ • the value of the expression ‘3+4i’ is the complex number 3 + 4i • the value of the expression ‘#(1 2 3)’ is a three-element vector containing the numeric values 1, 2 and 3. For any data type which can be expressed literally like this, the syntax of the literal data expression for that data type -- in other words, what you need to write in your code to indicate a literal value of that type -- is known as the data type's “read syntax”. This manual specifies the read syntax for each such data type in the section that describes that data type. Some data types do not have a read syntax. Procedures, for example, cannot be expressed as literal data; they must be created using a ‘lambda’ expression (*note Creating a Procedure::) or implicitly using the shorthand form of ‘define’ (*note Lambda Alternatives::). 3.3.1.2 Evaluating a Variable Reference ....................................... When an expression that consists simply of a variable name is evaluated, the value of the expression is the value of the named variable. The evaluation of a variable reference expression has no side effects. So, after (define key "Paul Evans") the value of the expression ‘key’ is the string value ‘"Paul Evans"’. If KEY is then modified by (set! key 3.74) the value of the expression ‘key’ is the numeric value 3.74. If there is no variable with the specified name, evaluation of the variable reference expression signals an error. 3.3.1.3 Evaluating a Procedure Invocation Expression .................................................... This is where evaluation starts getting interesting! As already noted, a procedure invocation expression has the form (PROCEDURE [ARG1 [ARG2 ...]]) where PROCEDURE must be an expression whose value, when evaluated, is a procedure. The evaluation of a procedure invocation expression like this proceeds by • evaluating individually the expressions PROCEDURE, ARG1, ARG2, and so on • calling the procedure that is the value of the PROCEDURE expression with the list of values obtained from the evaluations of ARG1, ARG2 etc. as its parameters. For a procedure defined in Scheme, "calling the procedure with the list of values as its parameters" means binding the values to the procedure's formal parameters and then evaluating the sequence of expressions that make up the body of the procedure definition. The value of the procedure invocation expression is the value of the last evaluated expression in the procedure body. The side effects of calling the procedure are the combination of the side effects of the sequence of evaluations of expressions in the procedure body. For a built-in procedure, the value and side-effects of calling the procedure are best described by that procedure's documentation. Note that the complete side effects of evaluating a procedure invocation expression consist not only of the side effects of the procedure call, but also of any side effects of the preceding evaluation of the expressions PROCEDURE, ARG1, ARG2, and so on. To illustrate this, let's look again at the procedure invocation expression: (string-length (string-append "/home" "/" "andrew")) In the outermost expression, PROCEDURE is ‘string-length’ and ARG1 is ‘(string-append "/home" "/" "andrew")’. • Evaluation of ‘string-length’, which is a variable, gives a procedure value that implements the expected behavior for "string-length". • Evaluation of ‘(string-append "/home" "/" "andrew")’, which is another procedure invocation expression, means evaluating each of • ‘string-append’, which gives a procedure value that implements the expected behavior for "string-append" • ‘"/home"’, which gives the string value ‘"/home"’ • ‘"/"’, which gives the string value ‘"/"’ • ‘"andrew"’, which gives the string value ‘"andrew"’ and then invoking the procedure value with this list of string values as its arguments. The resulting value is a single string value that is the concatenation of all the arguments, namely ‘"/home/andrew"’. In the evaluation of the outermost expression, the interpreter can now invoke the procedure value obtained from PROCEDURE with the value obtained from ARG1 as its arguments. The resulting value is a numeric value that is the length of the argument string, which is 12. 3.3.1.4 Evaluating Special Syntactic Expressions ................................................ When a procedure invocation expression is evaluated, the procedure and _all_ the argument expressions must be evaluated before the procedure can be invoked. Special syntactic expressions are special because they are able to manipulate their arguments in an unevaluated form, and can choose whether to evaluate any or all of the argument expressions. Why is this needed? Consider a program fragment that asks the user whether or not to delete a file, and then deletes the file if the user answers yes. (if (string=? (read-answer "Should I delete this file?") "yes") (delete-file file)) If the outermost ‘(if ...)’ expression here was a procedure invocation expression, the expression ‘(delete-file file)’, whose side effect is to actually delete a file, would already have been evaluated before the ‘if’ procedure even got invoked! Clearly this is no use -- the whole point of an ‘if’ expression is that the “consequent” expression is only evaluated if the condition of the ‘if’ expression is "true". Therefore ‘if’ must be special syntax, not a procedure. Other special syntaxes that we have already met are ‘define’, ‘set!’ and ‘lambda’. ‘define’ and ‘set!’ are syntax because they need to know the variable _name_ that is given as the first argument in a ‘define’ or ‘set!’ expression, not that variable's value. ‘lambda’ is syntax because it does not immediately evaluate the expressions that define the procedure body; instead it creates a procedure object that incorporates these expressions so that they can be evaluated in the future, when that procedure is invoked. The rules for evaluating each special syntactic expression are specified individually for each special syntax. For a summary of standard special syntax, see *Note Syntax Summary::. 3.3.2 Tail calls ---------------- Scheme is "properly tail recursive", meaning that tail calls or recursions from certain contexts do not consume stack space or other resources and can therefore be used on arbitrarily large data or for an arbitrarily long calculation. Consider for example, (define (foo n) (display n) (newline) (foo (1+ n))) (foo 1) ⊣ 1 2 3 ... ‘foo’ prints numbers infinitely, starting from the given N. It's implemented by printing N then recursing to itself to print N+1 and so on. This recursion is a tail call, it's the last thing done, and in Scheme such tail calls can be made without limit. Or consider a case where a value is returned, a version of the SRFI-1 ‘last’ function (*note SRFI-1 Selectors::) returning the last element of a list, (define (my-last lst) (if (null? (cdr lst)) (car lst) (my-last (cdr lst)))) (my-last '(1 2 3)) ⇒ 3 If the list has more than one element, ‘my-last’ applies itself to the ‘cdr’. This recursion is a tail call, there's no code after it, and the return value is the return value from that call. In Scheme this can be used on an arbitrarily long list argument. A proper tail call is only available from certain contexts, namely the following special form positions, • ‘and’ -- last expression • ‘begin’ -- last expression • ‘case’ -- last expression in each clause • ‘cond’ -- last expression in each clause, and the call to a ‘=>’ procedure is a tail call • ‘do’ -- last result expression • ‘if’ -- "true" and "false" leg expressions • ‘lambda’ -- last expression in body • ‘let’, ‘let*’, ‘letrec’, ‘let-syntax’, ‘letrec-syntax’ -- last expression in body • ‘or’ -- last expression The following core functions make tail calls, • ‘apply’ -- tail call to given procedure • ‘call-with-current-continuation’ -- tail call to the procedure receiving the new continuation • ‘call-with-values’ -- tail call to the values-receiving procedure • ‘eval’ -- tail call to evaluate the form • ‘string-any’, ‘string-every’ -- tail call to predicate on the last character (if that point is reached) The above are just core functions and special forms. Tail calls in other modules are described with the relevant documentation, for example SRFI-1 ‘any’ and ‘every’ (*note SRFI-1 Searching::). It will be noted there are a lot of places which could potentially be tail calls, for instance the last call in a ‘for-each’, but only those explicitly described are guaranteed. 3.3.3 Using the Guile REPL -------------------------- If you start Guile without specifying a particular program for it to execute, Guile enters its standard Read Evaluate Print Loop -- or “REPL” for short. In this mode, Guile repeatedly reads in the next Scheme expression that the user types, evaluates it, and prints the resulting value. The REPL is a useful mechanism for exploring the evaluation behavior described in the previous subsection. If you type ‘string-append’, for example, the REPL replies ‘#’, illustrating the relationship between the variable ‘string-append’ and the procedure value stored in that variable. In this manual, the notation ⇒ is used to mean "evaluates to". Wherever you see an example of the form EXPRESSION ⇒ RESULT feel free to try it out yourself by typing EXPRESSION into the REPL and checking that it gives the expected RESULT. 3.3.4 Summary of Common Syntax ------------------------------ This subsection lists the most commonly used Scheme syntactic expressions, simply so that you will recognize common special syntax when you see it. For a full description of each of these syntaxes, follow the appropriate reference. ‘lambda’ (*note Lambda::) is used to construct procedure objects. ‘define’ (*note Top Level::) is used to create a new variable and set its initial value. ‘set!’ (*note Top Level::) is used to modify an existing variable's value. ‘let’, ‘let*’ and ‘letrec’ (*note Local Bindings::) create an inner lexical environment for the evaluation of a sequence of expressions, in which a specified set of local variables is bound to the values of a corresponding set of expressions. For an introduction to environments, see *Note About Closure::. ‘begin’ (*note begin::) executes a sequence of expressions in order and returns the value of the last expression. Note that this is not the same as a procedure which returns its last argument, because the evaluation of a procedure invocation expression does not guarantee to evaluate the arguments in order. ‘if’ and ‘cond’ (*note Conditionals::) provide conditional evaluation of argument expressions depending on whether one or more conditions evaluate to "true" or "false". ‘case’ (*note Conditionals::) provides conditional evaluation of argument expressions depending on whether a variable has one of a specified group of values. ‘and’ (*note and or::) executes a sequence of expressions in order until either there are no expressions left, or one of them evaluates to "false". ‘or’ (*note and or::) executes a sequence of expressions in order until either there are no expressions left, or one of them evaluates to "true". 3.4 The Concept of Closure ========================== The concept of “closure” is the idea that a lambda expression "captures" the variable bindings that are in lexical scope at the point where the lambda expression occurs. The procedure created by the lambda expression can refer to and mutate the captured bindings, and the values of those bindings persist between procedure calls. This section explains and explores the various parts of this idea in more detail. 3.4.1 Names, Locations, Values and Environments ----------------------------------------------- We said earlier that a variable name in a Scheme program is associated with a location in which any kind of Scheme value may be stored. (Incidentally, the term "vcell" is often used in Lisp and Scheme circles as an alternative to "location".) Thus part of what we mean when we talk about "creating a variable" is in fact establishing an association between a name, or identifier, that is used by the Scheme program code, and the variable location to which that name refers. Although the value that is stored in that location may change, the location to which a given name refers is always the same. We can illustrate this by breaking down the operation of the ‘define’ syntax into three parts: ‘define’ • creates a new location • establishes an association between that location and the name specified as the first argument of the ‘define’ expression • stores in that location the value obtained by evaluating the second argument of the ‘define’ expression. A collection of associations between names and locations is called an “environment”. When you create a top level variable in a program using ‘define’, the name-location association for that variable is added to the "top level" environment. The "top level" environment also includes name-location associations for all the procedures that are supplied by standard Scheme. It is also possible to create environments other than the top level one, and to create variable bindings, or name-location associations, in those environments. This ability is a key ingredient in the concept of closure; the next subsection shows how it is done. 3.4.2 Local Variables and Environments -------------------------------------- We have seen how to create top level variables using the ‘define’ syntax (*note Definition::). It is often useful to create variables that are more limited in their scope, typically as part of a procedure body. In Scheme, this is done using the ‘let’ syntax, or one of its modified forms ‘let*’ and ‘letrec’. These syntaxes are described in full later in the manual (*note Local Bindings::). Here our purpose is to illustrate their use just enough that we can see how local variables work. For example, the following code uses a local variable ‘s’ to simplify the computation of the area of a triangle given the lengths of its three sides. (define a 5.3) (define b 4.7) (define c 2.8) (define area (let ((s (/ (+ a b c) 2))) (sqrt (* s (- s a) (- s b) (- s c))))) The effect of the ‘let’ expression is to create a new environment and, within this environment, an association between the name ‘s’ and a new location whose initial value is obtained by evaluating ‘(/ (+ a b c) 2)’. The expressions in the body of the ‘let’, namely ‘(sqrt (* s (- s a) (- s b) (- s c)))’, are then evaluated in the context of the new environment, and the value of the last expression evaluated becomes the value of the whole ‘let’ expression, and therefore the value of the variable ‘area’. 3.4.3 Environment Chaining -------------------------- In the example of the previous subsection, we glossed over an important point. The body of the ‘let’ expression in that example refers not only to the local variable ‘s’, but also to the top level variables ‘a’, ‘b’, ‘c’ and ‘sqrt’. (‘sqrt’ is the standard Scheme procedure for calculating a square root.) If the body of the ‘let’ expression is evaluated in the context of the _local_ ‘let’ environment, how does the evaluation get at the values of these top level variables? The answer is that the local environment created by a ‘let’ expression automatically has a reference to its containing environment -- in this case the top level environment -- and that the Scheme interpreter automatically looks for a variable binding in the containing environment if it doesn't find one in the local environment. More generally, every environment except for the top level one has a reference to its containing environment, and the interpreter keeps searching back up the chain of environments -- from most local to top level -- until it either finds a variable binding for the required identifier or exhausts the chain. This description also determines what happens when there is more than one variable binding with the same name. Suppose, continuing the example of the previous subsection, that there was also a pre-existing top level variable ‘s’ created by the expression: (define s "Some beans, my lord!") Then both the top level environment and the local ‘let’ environment would contain bindings for the name ‘s’. When evaluating code within the ‘let’ body, the interpreter looks first in the local ‘let’ environment, and so finds the binding for ‘s’ created by the ‘let’ syntax. Even though this environment has a reference to the top level environment, which also has a binding for ‘s’, the interpreter doesn't get as far as looking there. When evaluating code outside the ‘let’ body, the interpreter looks up variable names in the top level environment, so the name ‘s’ refers to the top level variable. Within the ‘let’ body, the binding for ‘s’ in the local environment is said to “shadow” the binding for ‘s’ in the top level environment. 3.4.4 Lexical Scope ------------------- The rules that we have just been describing are the details of how Scheme implements "lexical scoping". This subsection takes a brief diversion to explain what lexical scope means in general and to present an example of non-lexical scoping. "Lexical scope" in general is the idea that • an identifier at a particular place in a program always refers to the same variable location -- where "always" means "every time that the containing expression is executed", and that • the variable location to which it refers can be determined by static examination of the source code context in which that identifier appears, without having to consider the flow of execution through the program as a whole. In practice, lexical scoping is the norm for most programming languages, and probably corresponds to what you would intuitively consider to be "normal". You may even be wondering how the situation could possibly -- and usefully -- be otherwise. To demonstrate that another kind of scoping is possible, therefore, and to compare it against lexical scoping, the following subsection presents an example of non-lexical scoping and examines in detail how its behavior differs from the corresponding lexically scoped code. 3.4.4.1 An Example of Non-Lexical Scoping ......................................... To demonstrate that non-lexical scoping does exist and can be useful, we present the following example from Emacs Lisp, which is a "dynamically scoped" language. (defvar currency-abbreviation "USD") (defun currency-string (units hundredths) (concat currency-abbreviation (number-to-string units) "." (number-to-string hundredths))) (defun french-currency-string (units hundredths) (let ((currency-abbreviation "FRF")) (currency-string units hundredths))) The question to focus on here is: what does the identifier ‘currency-abbreviation’ refer to in the ‘currency-string’ function? The answer, in Emacs Lisp, is that all variable bindings go onto a single stack, and that ‘currency-abbreviation’ refers to the topmost binding from that stack which has the name "currency-abbreviation". The binding that is created by the ‘defvar’ form, to the value ‘"USD"’, is only relevant if none of the code that calls ‘currency-string’ rebinds the name "currency-abbreviation" in the meanwhile. The second function ‘french-currency-string’ works precisely by taking advantage of this behavior. It creates a new binding for the name "currency-abbreviation" which overrides the one established by the ‘defvar’ form. ;; Note! This is Emacs Lisp evaluation, not Scheme! (french-currency-string 33 44) ⇒ "FRF33.44" Now let's look at the corresponding, _lexically scoped_ Scheme code: (define currency-abbreviation "USD") (define (currency-string units hundredths) (string-append currency-abbreviation (number->string units) "." (number->string hundredths))) (define (french-currency-string units hundredths) (let ((currency-abbreviation "FRF")) (currency-string units hundredths))) According to the rules of lexical scoping, the ‘currency-abbreviation’ in ‘currency-string’ refers to the variable location in the innermost environment at that point in the code which has a binding for ‘currency-abbreviation’, which is the variable location in the top level environment created by the preceding ‘(define currency-abbreviation ...)’ expression. In Scheme, therefore, the ‘french-currency-string’ procedure does not work as intended. The variable binding that it creates for "currency-abbreviation" is purely local to the code that forms the body of the ‘let’ expression. Since this code doesn't directly use the name "currency-abbreviation" at all, the binding is pointless. (french-currency-string 33 44) ⇒ "USD33.44" This begs the question of how the Emacs Lisp behavior can be implemented in Scheme. In general, this is a design question whose answer depends upon the problem that is being addressed. In this case, the best answer may be that ‘currency-string’ should be redesigned so that it can take an optional third argument. This third argument, if supplied, is interpreted as a currency abbreviation that overrides the default. It is possible to change ‘french-currency-string’ so that it mostly works without changing ‘currency-string’, but the fix is inelegant, and susceptible to interrupts that could leave the ‘currency-abbreviation’ variable in the wrong state: (define (french-currency-string units hundredths) (set! currency-abbreviation "FRF") (let ((result (currency-string units hundredths))) (set! currency-abbreviation "USD") result)) The key point here is that the code does not create any local binding for the identifier ‘currency-abbreviation’, so all occurrences of this identifier refer to the top level variable. 3.4.5 Closure ------------- Consider a ‘let’ expression that doesn't contain any ‘lambda’s: (let ((s (/ (+ a b c) 2))) (sqrt (* s (- s a) (- s b) (- s c)))) When the Scheme interpreter evaluates this, it • creates a new environment with a reference to the environment that was current when it encountered the ‘let’ • creates a variable binding for ‘s’ in the new environment, with value given by ‘(/ (+ a b c) 2)’ • evaluates the expression in the body of the ‘let’ in the context of the new local environment, and remembers the value ‘V’ • forgets the local environment • continues evaluating the expression that contained the ‘let’, using the value ‘V’ as the value of the ‘let’ expression, in the context of the containing environment. After the ‘let’ expression has been evaluated, the local environment that was created is simply forgotten, and there is no longer any way to access the binding that was created in this environment. If the same code is evaluated again, it will follow the same steps again, creating a second new local environment that has no connection with the first, and then forgetting this one as well. If the ‘let’ body contains a ‘lambda’ expression, however, the local environment is _not_ forgotten. Instead, it becomes associated with the procedure that is created by the ‘lambda’ expression, and is reinstated every time that that procedure is called. In detail, this works as follows. • When the Scheme interpreter evaluates a ‘lambda’ expression, to create a procedure object, it stores the current environment as part of the procedure definition. • Then, whenever that procedure is called, the interpreter reinstates the environment that is stored in the procedure definition and evaluates the procedure body within the context of that environment. The result is that the procedure body is always evaluated in the context of the environment that was current when the procedure was created. This is what is meant by “closure”. The next few subsections present examples that explore the usefulness of this concept. 3.4.6 Example 1: A Serial Number Generator ------------------------------------------ This example uses closure to create a procedure with a variable binding that is private to the procedure, like a local variable, but whose value persists between procedure calls. (define (make-serial-number-generator) (let ((current-serial-number 0)) (lambda () (set! current-serial-number (+ current-serial-number 1)) current-serial-number))) (define entry-sn-generator (make-serial-number-generator)) (entry-sn-generator) ⇒ 1 (entry-sn-generator) ⇒ 2 When ‘make-serial-number-generator’ is called, it creates a local environment with a binding for ‘current-serial-number’ whose initial value is 0, then, within this environment, creates a procedure. The local environment is stored within the created procedure object and so persists for the lifetime of the created procedure. Every time the created procedure is invoked, it increments the value of the ‘current-serial-number’ binding in the captured environment and then returns the current value. Note that ‘make-serial-number-generator’ can be called again to create a second serial number generator that is independent of the first. Every new invocation of ‘make-serial-number-generator’ creates a new local ‘let’ environment and returns a new procedure object with an association to this environment. 3.4.7 Example 2: A Shared Persistent Variable --------------------------------------------- This example uses closure to create two procedures, ‘get-balance’ and ‘deposit’, that both refer to the same captured local environment so that they can both access the ‘balance’ variable binding inside that environment. The value of this variable binding persists between calls to either procedure. Note that the captured ‘balance’ variable binding is private to these two procedures: it is not directly accessible to any other code. It can only be accessed indirectly via ‘get-balance’ or ‘deposit’, as illustrated by the ‘withdraw’ procedure. (define get-balance #f) (define deposit #f) (let ((balance 0)) (set! get-balance (lambda () balance)) (set! deposit (lambda (amount) (set! balance (+ balance amount)) balance))) (define (withdraw amount) (deposit (- amount))) (get-balance) ⇒ 0 (deposit 50) ⇒ 50 (withdraw 75) ⇒ -25 An important detail here is that the ‘get-balance’ and ‘deposit’ variables must be set up by ‘define’ing them at top level and then ‘set!’ing their values inside the ‘let’ body. Using ‘define’ within the ‘let’ body would not work: this would create variable bindings within the local ‘let’ environment that would not be accessible at top level. 3.4.8 Example 3: The Callback Closure Problem --------------------------------------------- A frequently used programming model for library code is to allow an application to register a callback function for the library to call when some particular event occurs. It is often useful for the application to make several such registrations using the same callback function, for example if several similar library events can be handled using the same application code, but the need then arises to distinguish the callback function calls that are associated with one callback registration from those that are associated with different callback registrations. In languages without the ability to create functions dynamically, this problem is usually solved by passing a ‘user_data’ parameter on the registration call, and including the value of this parameter as one of the parameters on the callback function. Here is an example of declarations using this solution in C: typedef void (event_handler_t) (int event_type, void *user_data); void register_callback (int event_type, event_handler_t *handler, void *user_data); In Scheme, closure can be used to achieve the same functionality without requiring the library code to store a ‘user-data’ for each callback registration. ;; In the library: (define (register-callback event-type handler-proc) ...) ;; In the application: (define (make-handler event-type user-data) (lambda () ... ...)) (register-callback event-type (make-handler event-type ...)) As far as the library is concerned, ‘handler-proc’ is a procedure with no arguments, and all the library has to do is call it when the appropriate event occurs. From the application's point of view, though, the handler procedure has used closure to capture an environment that includes all the context that the handler code needs -- ‘event-type’ and ‘user-data’ -- to handle the event correctly. 3.4.9 Example 4: Object Orientation ----------------------------------- Closure is the capture of an environment, containing persistent variable bindings, within the definition of a procedure or a set of related procedures. This is rather similar to the idea in some object oriented languages of encapsulating a set of related data variables inside an "object", together with a set of "methods" that operate on the encapsulated data. The following example shows how closure can be used to emulate the ideas of objects, methods and encapsulation in Scheme. (define (make-account) (let ((balance 0)) (define (get-balance) balance) (define (deposit amount) (set! balance (+ balance amount)) balance) (define (withdraw amount) (deposit (- amount))) (lambda args (apply (case (car args) ((get-balance) get-balance) ((deposit) deposit) ((withdraw) withdraw) (else (error "Invalid method!"))) (cdr args))))) Each call to ‘make-account’ creates and returns a new procedure, created by the expression in the example code that begins "(lambda args". (define my-account (make-account)) my-account ⇒ # This procedure acts as an account object with methods ‘get-balance’, ‘deposit’ and ‘withdraw’. To apply one of the methods to the account, you call the procedure with a symbol indicating the required method as the first parameter, followed by any other parameters that are required by that method. (my-account 'get-balance) ⇒ 0 (my-account 'withdraw 5) ⇒ -5 (my-account 'deposit 396) ⇒ 391 (my-account 'get-balance) ⇒ 391 Note how, in this example, both the current balance and the helper procedures ‘get-balance’, ‘deposit’ and ‘withdraw’, used to implement the guts of the account object's methods, are all stored in variable bindings within the private local environment captured by the ‘lambda’ expression that creates the account object procedure. 3.5 Further Reading =================== • The website is a good starting point for all things Scheme. • Dorai Sitaram's online Scheme tutorial, “Teach Yourself Scheme in Fixnum Days”, at . Includes a nice explanation of continuations. • The complete text of “Structure and Interpretation of Computer Programs”, the classic introduction to computer science and Scheme by Hal Abelson, Jerry Sussman and Julie Sussman, is now available online at . This site also provides teaching materials related to the book, and all the source code used in the book, in a form suitable for loading and running. 4 Programming in Scheme *********************** Guile's core language is Scheme, and a lot can be achieved simply by using Guile to write and run Scheme programs -- as opposed to having to dive into C code. In this part of the manual, we explain how to use Guile in this mode, and describe the tools that Guile provides to help you with script writing, debugging, and packaging your programs for distribution. For detailed reference information on the variables, functions, and so on that make up Guile's application programming interface (API), see *note API Reference::. 4.1 Guile's Implementation of Scheme ==================================== Guile's core language is Scheme, which is specified and described in the series of reports known as “RnRS”. “RnRS” is shorthand for the “Revised^n Report on the Algorithmic Language Scheme”. Guile complies fully with R5RS (*note Introduction: (r5rs)Top.), and is largely compliant with R6RS and R7RS. Guile also has many extensions that go beyond these reports. Some of the areas where Guile extends standard Scheme are: • Guile's interactive documentation system • Guile's support for POSIX-compliant network programming • GOOPS - Guile's framework for object oriented programming. 4.2 Invoking Guile ================== Many features of Guile depend on and can be changed by information that the user provides either before or when Guile is started. Below is a description of what information to provide and how to provide it. 4.2.1 Command-line Options -------------------------- Here we describe Guile's command-line processing in detail. Guile processes its arguments from left to right, recognizing the switches described below. For examples, see *note Scripting Examples::. ‘SCRIPT ARG...’ ‘-s SCRIPT ARG...’ By default, Guile will read a file named on the command line as a script. Any command-line arguments ARG... following SCRIPT become the script's arguments; the ‘command-line’ function returns a list of strings of the form ‘(SCRIPT ARG...)’. It is possible to name a file using a leading hyphen, for example, ‘-myfile.scm’. In this case, the file name must be preceded by ‘-s’ to tell Guile that a (script) file is being named. Scripts are read and evaluated as Scheme source code just as the ‘load’ function would. After loading SCRIPT, Guile exits. ‘-c EXPR ARG...’ Evaluate EXPR as Scheme code, and then exit. Any command-line arguments ARG... following EXPR become command-line arguments; the ‘command-line’ function returns a list of strings of the form ‘(GUILE ARG...)’, where GUILE is the path of the Guile executable. ‘-- ARG...’ Run interactively, prompting the user for expressions and evaluating them. Any command-line arguments ARG... following the ‘--’ become command-line arguments for the interactive session; the ‘command-line’ function returns a list of strings of the form ‘(GUILE ARG...)’, where GUILE is the path of the Guile executable. ‘-L DIRECTORY’ Add DIRECTORY to the front of Guile's module load path. The given directories are searched in the order given on the command line and before any directories in the ‘GUILE_LOAD_PATH’ environment variable. Paths added here are _not_ in effect during execution of the user's ‘.guile’ file. ‘-C DIRECTORY’ Like ‘-L’, but adjusts the load path for _compiled_ files. ‘-x EXTENSION’ Add EXTENSION to the front of Guile's load extension list (*note ‘%load-extensions’: Load Paths.). The specified extensions are tried in the order given on the command line, and before the default load extensions. Extensions added here are _not_ in effect during execution of the user's ‘.guile’ file. ‘-l FILE’ Load Scheme source code from FILE, and continue processing the command line. ‘-e FUNCTION’ Make FUNCTION the “entry point” of the script. After loading the script file (with ‘-s’) or evaluating the expression (with ‘-c’), apply FUNCTION to a list containing the program name and the command-line arguments--the list provided by the ‘command-line’ function. A ‘-e’ switch can appear anywhere in the argument list, but Guile always invokes the FUNCTION as the _last_ action it performs. This is weird, but because of the way script invocation works under POSIX, the ‘-s’ option must always come last in the list. The FUNCTION is most often a simple symbol that names a function that is defined in the script. It can also be of the form ‘(@ MODULE-NAME SYMBOL)’, and in that case, the symbol is looked up in the module named MODULE-NAME. As a shorthand you can use the form ‘(symbol ...)’, that is, a list of only symbols that doesn't start with ‘@’. It is equivalent to ‘(@ MODULE-NAME main)’, where MODULE-NAME is ‘(symbol ...)’ form. *Note Using Guile Modules:: and *note Scripting Examples::. ‘-ds’ Treat a final ‘-s’ option as if it occurred at this point in the command line; load the script here. This switch is necessary because, although the POSIX script invocation mechanism effectively requires the ‘-s’ option to appear last, the programmer may well want to run the script before other actions requested on the command line. For examples, see *note Scripting Examples::. ‘\’ Read more command-line arguments, starting from the second line of the script file. *Note The Meta Switch::. ‘--use-srfi=LIST’ The option ‘--use-srfi’ expects a comma-separated list of numbers, each representing a SRFI module to be loaded into the interpreter before evaluating a script file or starting the REPL. Additionally, the feature identifier for the loaded SRFIs is recognized by the procedure ‘cond-expand’ when this option is used. Here is an example that loads the modules SRFI-8 ('receive') and SRFI-13 ('string library') before the GUILE interpreter is started: guile --use-srfi=8,13 ‘--r6rs’ Adapt Guile's initial environment to better support R6RS. *Note R6RS Incompatibilities::, for some caveats. ‘--r7rs’ Adapt Guile's initial environment to better support R7RS. *Note R7RS Incompatibilities::, for some caveats. ‘--debug’ Start with the debugging virtual machine (VM) engine. Using the debugging VM will enable support for VM hooks, which are needed for tracing, breakpoints, and accurate call counts when profiling. The debugging VM is slower than the regular VM, though, by about ten percent. *Note VM Hooks::, for more information. By default, the debugging VM engine is only used when entering an interactive session. When executing a script with ‘-s’ or ‘-c’, the normal, faster VM is used by default. ‘--no-debug’ Do not use the debugging VM engine, even when entering an interactive session. Note that, despite the name, Guile running with ‘--no-debug’ _does_ support the usual debugging facilities, such as printing a detailed backtrace upon error. The only difference with ‘--debug’ is lack of support for VM hooks and the facilities that build upon it (see above). ‘-q’ Do not load the initialization file, ‘.guile’. This option only has an effect when running interactively; running scripts does not load the ‘.guile’ file. *Note Init File::. ‘--listen[=P]’ While this program runs, listen on a local port or a path for REPL clients. If P starts with a number, it is assumed to be a local port on which to listen. If it starts with a forward slash, it is assumed to be the file name of a UNIX domain socket on which to listen. If P is not given, the default is local port 37146. If you look at it upside down, it almost spells "Guile". If you have netcat installed, you should be able to ‘nc localhost 37146’ and get a Guile prompt. Alternately you can fire up Emacs and connect to the process; see *note Using Guile in Emacs:: for more details. Note: Opening a port allows anyone who can connect to that port to do anything Guile can do, as the user that the Guile process is running as. Do not use ‘--listen’ on multi-user machines. Of course, if you do not pass ‘--listen’ to Guile, no port will be opened. Guile protects against the “HTTP inter-protocol exploitation attack” (https://en.wikipedia.org/wiki/Inter-protocol_exploitation), a scenario whereby an attacker can, via an HTML page, cause a web browser to send data to TCP servers listening on a loopback interface or private network. Nevertheless, you are advised to use UNIX domain sockets, as in ‘--listen=/some/local/file’, whenever possible. That said, ‘--listen’ is great for interactive debugging and development. ‘--auto-compile’ Compile source files automatically (default behavior). ‘--fresh-auto-compile’ Treat the auto-compilation cache as invalid, forcing recompilation. ‘--no-auto-compile’ Disable automatic source file compilation. ‘--language=LANG’ For the remainder of the command line arguments, assume that files mentioned with ‘-l’ and expressions passed with ‘-c’ are written in LANG. LANG must be the name of one of the languages supported by the compiler (*note Compiler Tower::). When run interactively, set the REPL's language to LANG (*note Using Guile Interactively::). The default language is ‘scheme’; other interesting values include ‘elisp’ (for Emacs Lisp), and ‘ecmascript’. The example below shows the evaluation of expressions in Scheme, Emacs Lisp, and ECMAScript: guile -c "(apply + '(1 2))" guile --language=elisp -c "(= (funcall (symbol-function '+) 1 2) 3)" guile --language=ecmascript -c '(function (x) { return x * x; })(2);' To load a file written in Scheme and one written in Emacs Lisp, and then start a Scheme REPL, type: guile -l foo.scm --language=elisp -l foo.el --language=scheme ‘-h, --help’ Display help on invoking Guile, and then exit. ‘-v, --version’ Display the current version of Guile, and then exit. 4.2.2 Environment Variables --------------------------- The “environment” is a feature of the operating system; it consists of a collection of variables with names and values. Each variable is called an “environment variable” (or, sometimes, a "shell variable"); environment variable names are case-sensitive, and it is conventional to use upper-case letters only. The values are all text strings, even those that are written as numerals. (Note that here we are referring to names and values that are defined in the operating system shell from which Guile is invoked. This is not the same as a Scheme environment that is defined within a running instance of Guile. For a description of Scheme environments, *note About Environments::.) How to set environment variables before starting Guile depends on the operating system and, especially, the shell that you are using. For example, here is how to tell Guile to provide detailed warning messages about deprecated features by setting ‘GUILE_WARN_DEPRECATED’ using Bash: $ export GUILE_WARN_DEPRECATED="detailed" $ guile Or, detailed warnings can be turned on for a single invocation using: $ env GUILE_WARN_DEPRECATED="detailed" guile If you wish to retrieve or change the value of the shell environment variables that affect the run-time behavior of Guile from within a running instance of Guile, see *note Runtime Environment::. Here are the environment variables that affect the run-time behavior of Guile: ‘GUILE_AUTO_COMPILE’ This is a flag that can be used to tell Guile whether or not to compile Scheme source files automatically. Starting with Guile 2.0, Scheme source files will be compiled automatically, by default. If a compiled (‘.go’) file corresponding to a ‘.scm’ file is not found or is not newer than the ‘.scm’ file, the ‘.scm’ file will be compiled on the fly, and the resulting ‘.go’ file stored away. An advisory note will be printed on the console. Compiled files will be stored in the directory ‘$XDG_CACHE_HOME/guile/ccache’, where ‘XDG_CACHE_HOME’ defaults to the directory ‘$HOME/.cache’. This directory will be created if it does not already exist. Note that this mechanism depends on the timestamp of the ‘.go’ file being newer than that of the ‘.scm’ file; if the ‘.scm’ or ‘.go’ files are moved after installation, care should be taken to preserve their original timestamps. Set ‘GUILE_AUTO_COMPILE’ to zero (0), to prevent Scheme files from being compiled automatically. Set this variable to "fresh" to tell Guile to compile Scheme files whether they are newer than the compiled files or not. *Note Compilation::. ‘GUILE_HISTORY’ This variable names the file that holds the Guile REPL command history. You can specify a different history file by setting this environment variable. By default, the history file is ‘$HOME/.guile_history’. ‘GUILE_INSTALL_LOCALE’ This is a flag that can be used to tell Guile whether or not to install the current locale at startup, via a call to ‘(setlocale LC_ALL "")’(1). *Note Locales::, for more information on locales. You may explicitly indicate that you do not want to install the locale by setting ‘GUILE_INSTALL_LOCALE’ to ‘0’, or explicitly enable it by setting the variable to ‘1’. Usually, installing the current locale is the right thing to do. It allows Guile to correctly parse and print strings with non-ASCII characters. Therefore, this option is on by default. ‘GUILE_LOAD_COMPILED_PATH’ This variable may be used to augment the path that is searched for compiled Scheme files (‘.go’ files) when loading. Its value should be a colon-separated list of directories. If it contains the special path component ‘...’ (ellipsis), then the default path is put in place of the ellipsis, otherwise the default path is placed at the end. The result is stored in ‘%load-compiled-path’ (*note Load Paths::). Here is an example using the Bash shell that adds the current directory, ‘.’, and the relative directory ‘../my-library’ to ‘%load-compiled-path’: $ export GUILE_LOAD_COMPILED_PATH=".:../my-library" $ guile -c '(display %load-compiled-path) (newline)' (. ../my-library /usr/local/lib/guile/3.0/ccache) ‘GUILE_LOAD_PATH’ This variable may be used to augment the path that is searched for Scheme files when loading. Its value should be a colon-separated list of directories. If it contains the special path component ‘...’ (ellipsis), then the default path is put in place of the ellipsis, otherwise the default path is placed at the end. The result is stored in ‘%load-path’ (*note Load Paths::). Here is an example using the Bash shell that prepends the current directory to ‘%load-path’, and adds the relative directory ‘../srfi’ to the end: $ env GUILE_LOAD_PATH=".:...:../srfi" \ guile -c '(display %load-path) (newline)' (. /usr/local/share/guile/3.0 \ /usr/local/share/guile/site/3.0 \ /usr/local/share/guile/site \ /usr/local/share/guile \ ../srfi) (Note: The line breaks, above, are for documentation purposes only, and not required in the actual example.) ‘GUILE_EXTENSIONS_PATH’ This variable may be used to augment the path that is searched for foreign libraries via ‘load-extension’, ‘dynamic-link’, ‘load-foreign-library’, or the like. Its value should be a colon-separated (semicolon on Windows) list of directories. *Note Foreign Libraries::. ‘GUILE_WARN_DEPRECATED’ As Guile evolves, some features will be eliminated or replaced by newer features. To help users migrate their code as this evolution occurs, Guile will issue warning messages about code that uses features that have been marked for eventual elimination. ‘GUILE_WARN_DEPRECATED’ can be set to "no" to tell Guile not to display these warning messages, or set to "detailed" to tell Guile to display more lengthy messages describing the warning. *Note Deprecation::. ‘HOME’ Guile uses the environment variable ‘HOME’, the name of your home directory, to locate various files, such as ‘.guile’ or ‘.guile_history’. ‘GUILE_JIT_THRESHOLD’ Guile has a just-in-time (JIT) code generator that makes running Guile code fast. *Note Just-In-Time Native Code::, for more. The unit of code generation is the function. Each function has its own counter that gets incremented when the function is called and at each loop iteration in the function. When the counter exceeds the ‘GUILE_JIT_THRESHOLD’, the function will get JIT-compiled. Set ‘GUILE_JIT_THRESHOLD’ to ‘-1’ to disable JIT compilation, or ‘0’ to eagerly JIT-compile each function as it's first seen. ‘GUILE_JIT_LOG’ Set to ‘1’, ‘2’, or ‘3’ to give increasing amounts of logging for JIT compilation events. Used for debugging. ‘GUILE_JIT_STOP_AFTER’ Though we have tested the JIT compiler as well as we can, it's possible that it has bugs. If you suspect that Guile's JIT compiler is causing your program to fail, set ‘GUILE_JIT_STOP_AFTER’ to a positive integer indicating the maximum number of functions to JIT-compile. By bisecting over the value of ‘GUILE_JIT_STOP_AFTER’, you can pinpoint the precise function that is being miscompiled. ---------- Footnotes ---------- (1) The ‘GUILE_INSTALL_LOCALE’ environment variable was ignored in Guile versions prior to 2.0.9. 4.3 Guile Scripting =================== Like AWK, Perl, or any shell, Guile can interpret script files. A Guile script is simply a file of Scheme code with some extra information at the beginning which tells the operating system how to invoke Guile, and then tells Guile how to handle the Scheme code. 4.3.1 The Top of a Script File ------------------------------ The first line of a Guile script must tell the operating system to use Guile to evaluate the script, and then tell Guile how to go about doing that. Here is the simplest case: • The first two characters of the file must be ‘#!’. The operating system interprets this to mean that the rest of the line is the name of an executable that can interpret the script. Guile, however, interprets these characters as the beginning of a multi-line comment, terminated by the characters ‘!#’ on a line by themselves. (This is an extension to the syntax described in R5RS, added to support shell scripts.) • Immediately after those two characters must come the full pathname to the Guile interpreter. On most systems, this would be ‘/usr/local/bin/guile’. • Then must come a space, followed by a command-line argument to pass to Guile; this should be ‘-s’. This switch tells Guile to run a script, instead of soliciting the user for input from the terminal. There are more elaborate things one can do here; see *note The Meta Switch::. • Follow this with a newline. • The second line of the script should contain only the characters ‘!#’ -- just like the top of the file, but reversed. The operating system never reads this far, but Guile treats this as the end of the comment begun on the first line by the ‘#!’ characters. • If this source code file is not ASCII or ISO-8859-1 encoded, a coding declaration such as ‘coding: utf-8’ should appear in a comment somewhere in the first five lines of the file: see *note Character Encoding of Source Files::. • The rest of the file should be a Scheme program. Guile reads the program, evaluating expressions in the order that they appear. Upon reaching the end of the file, Guile exits. 4.3.2 The Meta Switch --------------------- Guile's command-line switches allow the programmer to describe reasonably complicated actions in scripts. Unfortunately, the POSIX script invocation mechanism only allows one argument to appear on the ‘#!’ line after the path to the Guile executable, and imposes arbitrary limits on that argument's length. Suppose you wrote a script starting like this: #!/usr/local/bin/guile -e main -s !# (define (main args) (map (lambda (arg) (display arg) (display " ")) (cdr args)) (newline)) The intended meaning is clear: load the file, and then call ‘main’ on the command-line arguments. However, the system will treat everything after the Guile path as a single argument -- the string ‘"-e main -s"’ -- which is not what we want. As a workaround, the meta switch ‘\’ allows the Guile programmer to specify an arbitrary number of options without patching the kernel. If the first argument to Guile is ‘\’, Guile will open the script file whose name follows the ‘\’, parse arguments starting from the file's second line (according to rules described below), and substitute them for the ‘\’ switch. Working in concert with the meta switch, Guile treats the characters ‘#!’ as the beginning of a comment which extends through the next line containing only the characters ‘!#’. This sort of comment may appear anywhere in a Guile program, but it is most useful at the top of a file, meshing magically with the POSIX script invocation mechanism. Thus, consider a script named ‘/u/jimb/ekko’ which starts like this: #!/usr/local/bin/guile \ -e main -s !# (define (main args) (map (lambda (arg) (display arg) (display " ")) (cdr args)) (newline)) Suppose a user invokes this script as follows: $ /u/jimb/ekko a b c Here's what happens: • the operating system recognizes the ‘#!’ token at the top of the file, and rewrites the command line to: /usr/local/bin/guile \ /u/jimb/ekko a b c This is the usual behavior, prescribed by POSIX. • When Guile sees the first two arguments, ‘\ /u/jimb/ekko’, it opens ‘/u/jimb/ekko’, parses the three arguments ‘-e’, ‘main’, and ‘-s’ from it, and substitutes them for the ‘\’ switch. Thus, Guile's command line now reads: /usr/local/bin/guile -e main -s /u/jimb/ekko a b c • Guile then processes these switches: it loads ‘/u/jimb/ekko’ as a file of Scheme code (treating the first three lines as a comment), and then performs the application ‘(main "/u/jimb/ekko" "a" "b" "c")’. When Guile sees the meta switch ‘\’, it parses command-line argument from the script file according to the following rules: • Each space character terminates an argument. This means that two spaces in a row introduce an argument ‘""’. • The tab character is not permitted (unless you quote it with the backslash character, as described below), to avoid confusion. • The newline character terminates the sequence of arguments, and will also terminate a final non-empty argument. (However, a newline following a space will not introduce a final empty-string argument; it only terminates the argument list.) • The backslash character is the escape character. It escapes backslash, space, tab, and newline. The ANSI C escape sequences like ‘\n’ and ‘\t’ are also supported. These produce argument constituents; the two-character combination ‘\n’ doesn't act like a terminating newline. The escape sequence ‘\NNN’ for exactly three octal digits reads as the character whose ASCII code is NNN. As above, characters produced this way are argument constituents. Backslash followed by other characters is not allowed. 4.3.3 Command Line Handling --------------------------- The ability to accept and handle command line arguments is very important when writing Guile scripts to solve particular problems, such as extracting information from text files or interfacing with existing command line applications. This chapter describes how Guile makes command line arguments available to a Guile script, and the utilities that Guile provides to help with the processing of command line arguments. When a Guile script is invoked, Guile makes the command line arguments accessible via the procedure ‘command-line’, which returns the arguments as a list of strings. For example, if the script #! /usr/local/bin/guile -s !# (write (command-line)) (newline) is saved in a file ‘cmdline-test.scm’ and invoked using the command line ‘./cmdline-test.scm bar.txt -o foo -frumple grob’, the output is ("./cmdline-test.scm" "bar.txt" "-o" "foo" "-frumple" "grob") If the script invocation includes a ‘-e’ option, specifying a procedure to call after loading the script, Guile will call that procedure with ‘(command-line)’ as its argument. So a script that uses ‘-e’ doesn't need to refer explicitly to ‘command-line’ in its code. For example, the script above would have identical behavior if it was written instead like this: #! /usr/local/bin/guile \ -e main -s !# (define (main args) (write args) (newline)) (Note the use of the meta switch ‘\’ so that the script invocation can include more than one Guile option: *Note The Meta Switch::.) These scripts use the ‘#!’ POSIX convention so that they can be executed using their own file names directly, as in the example command line ‘./cmdline-test.scm bar.txt -o foo -frumple grob’. But they can also be executed by typing out the implied Guile command line in full, as in: $ guile -s ./cmdline-test.scm bar.txt -o foo -frumple grob or $ guile -e main -s ./cmdline-test2.scm bar.txt -o foo -frumple grob Even when a script is invoked using this longer form, the arguments that the script receives are the same as if it had been invoked using the short form. Guile ensures that the ‘(command-line)’ or ‘-e’ arguments are independent of how the script is invoked, by stripping off the arguments that Guile itself processes. A script is free to parse and handle its command line arguments in any way that it chooses. Where the set of possible options and arguments is complex, however, it can get tricky to extract all the options, check the validity of given arguments, and so on. This task can be greatly simplified by taking advantage of the module ‘(ice-9 getopt-long)’, which is distributed with Guile, *Note getopt-long::. 4.3.4 Scripting Examples ------------------------ To start with, here are some examples of invoking Guile directly: ‘guile -- a b c’ Run Guile interactively; ‘(command-line)’ will return ‘("/usr/local/bin/guile" "a" "b" "c")’. ‘guile -s /u/jimb/ex2 a b c’ Load the file ‘/u/jimb/ex2’; ‘(command-line)’ will return ‘("/u/jimb/ex2" "a" "b" "c")’. ‘guile -c '(write %load-path) (newline)'’ Write the value of the variable ‘%load-path’, print a newline, and exit. ‘guile -e main -s /u/jimb/ex4 foo’ Load the file ‘/u/jimb/ex4’, and then call the function ‘main’, passing it the list ‘("/u/jimb/ex4" "foo")’. ‘guile -e '(ex4)' -s /u/jimb/ex4.scm foo’ Load the file ‘/u/jimb/ex4.scm’, and then call the function ‘main’ from the module '(ex4)', passing it the list ‘("/u/jimb/ex4" "foo")’. ‘guile -l first -ds -l last -s script’ Load the files ‘first’, ‘script’, and ‘last’, in that order. The ‘-ds’ switch says when to process the ‘-s’ switch. For a more motivated example, see the scripts below. Here is a very simple Guile script: #!/usr/local/bin/guile -s !# (display "Hello, world!") (newline) The first line marks the file as a Guile script. When the user invokes it, the system runs ‘/usr/local/bin/guile’ to interpret the script, passing ‘-s’, the script's filename, and any arguments given to the script as command-line arguments. When Guile sees ‘-s SCRIPT’, it loads SCRIPT. Thus, running this program produces the output: Hello, world! Here is a script which prints the factorial of its argument: #!/usr/local/bin/guile -s !# (define (fact n) (if (zero? n) 1 (* n (fact (- n 1))))) (display (fact (string->number (cadr (command-line))))) (newline) In action: $ ./fact 5 120 $ However, suppose we want to use the definition of ‘fact’ in this file from another script. We can't simply ‘load’ the script file, and then use ‘fact’'s definition, because the script will try to compute and display a factorial when we load it. To avoid this problem, we might write the script this way: #!/usr/local/bin/guile \ -e main -s !# (define (fact n) (if (zero? n) 1 (* n (fact (- n 1))))) (define (main args) (display (fact (string->number (cadr args)))) (newline)) This version packages the actions the script should perform in a function, ‘main’. This allows us to load the file purely for its definitions, without any extraneous computation taking place. Then we used the meta switch ‘\’ and the entry point switch ‘-e’ to tell Guile to call ‘main’ after loading the script. $ ./fact 50 30414093201713378043612608166064768844377641568960512000000000000 Suppose that we now want to write a script which computes the ‘choose’ function: given a set of M distinct objects, ‘(choose N M)’ is the number of distinct subsets containing N objects each. It's easy to write ‘choose’ given ‘fact’, so we might write the script this way: #!/usr/local/bin/guile \ -l fact -e main -s !# (define (choose n m) (/ (fact m) (* (fact (- m n)) (fact n)))) (define (main args) (let ((n (string->number (cadr args))) (m (string->number (caddr args)))) (display (choose n m)) (newline))) The command-line arguments here tell Guile to first load the file ‘fact’, and then run the script, with ‘main’ as the entry point. In other words, the ‘choose’ script can use definitions made in the ‘fact’ script. Here are some sample runs: $ ./choose 0 4 1 $ ./choose 1 4 4 $ ./choose 2 4 6 $ ./choose 3 4 4 $ ./choose 4 4 1 $ ./choose 50 100 100891344545564193334812497256 To call a specific procedure from a given module, we can use the special form ‘(@ (MODULE) PROCEDURE)’: #!/usr/local/bin/guile \ -l fact -e (@ (fac) main) -s !# (define-module (fac) #:export (main)) (define (choose n m) (/ (fact m) (* (fact (- m n)) (fact n)))) (define (main args) (let ((n (string->number (cadr args))) (m (string->number (caddr args)))) (display (choose n m)) (newline))) We can use ‘@@’ to invoke non-exported procedures. For exported procedures, we can simplify this call with the shorthand ‘(MODULE)’: #!/usr/local/bin/guile \ -l fact -e (fac) -s !# (define-module (fac) #:export (main)) (define (choose n m) (/ (fact m) (* (fact (- m n)) (fact n)))) (define (main args) (let ((n (string->number (cadr args))) (m (string->number (caddr args)))) (display (choose n m)) (newline))) For maximum portability, we can instead use the shell to execute ‘guile’ with specified command line arguments. Here we need to take care to quote the command arguments correctly: #!/usr/bin/env sh exec guile -l fact -e '(@ (fac) main)' -s "$0" "$@" !# (define-module (fac) #:export (main)) (define (choose n m) (/ (fact m) (* (fact (- m n)) (fact n)))) (define (main args) (let ((n (string->number (cadr args))) (m (string->number (caddr args)))) (display (choose n m)) (newline))) Finally, seasoned scripters are probably missing a mention of subprocesses. In Bash, for example, most shell scripts run other programs like ‘sed’ or the like to do the actual work. In Guile it's often possible get everything done within Guile itself, so do give that a try first. But if you just need to run a program and wait for it to finish, use ‘system*’. If you need to run a sub-program and capture its output, or give it input, use ‘open-pipe’. *Note Processes::, and *Note Pipes::, for more information. 4.4 Using Guile Interactively ============================= When you start up Guile by typing just ‘guile’, without a ‘-c’ argument or the name of a script to execute, you get an interactive interpreter where you can enter Scheme expressions, and Guile will evaluate them and print the results for you. Here are some simple examples. scheme@(guile-user)> (+ 3 4 5) $1 = 12 scheme@(guile-user)> (display "Hello world!\n") Hello world! scheme@(guile-user)> (values 'a 'b) $2 = a $3 = b This mode of use is called a “REPL”, which is short for "Read-Eval-Print Loop", because the Guile interpreter first reads the expression that you have typed, then evaluates it, and then prints the result. The prompt shows you what language and module you are in. In this case, the current language is ‘scheme’, and the current module is ‘(guile-user)’. *Note Other Languages::, for more information on Guile's support for languages other than Scheme. 4.4.1 The Init File, ‘~/.guile’ ------------------------------- When run interactively, Guile will load a local initialization file from ‘~/.guile’. This file should contain Scheme expressions for evaluation. This facility lets the user customize their interactive Guile environment, pulling in extra modules or parameterizing the REPL implementation. To run Guile without loading the init file, use the ‘-q’ command-line option. 4.4.2 Readline -------------- To make it easier for you to repeat and vary previously entered expressions, or to edit the expression that you're typing in, Guile can use the GNU Readline library. This is not enabled by default because of licensing reasons, but all you need to activate Readline is the following pair of lines. scheme@(guile-user)> (use-modules (ice-9 readline)) scheme@(guile-user)> (activate-readline) It's a good idea to put these two lines (without the ‘scheme@(guile-user)>’ prompts) in your ‘.guile’ file. *Note Init File::, for more on ‘.guile’. 4.4.3 Value History ------------------- Just as Readline helps you to reuse a previous input line, “value history” allows you to use the _result_ of a previous evaluation in a new expression. When value history is enabled, each evaluation result is automatically assigned to the next in the sequence of variables ‘$1’, ‘$2’, .... You can then use these variables in subsequent expressions. scheme@(guile-user)> (iota 10) $1 = (0 1 2 3 4 5 6 7 8 9) scheme@(guile-user)> (apply * (cdr $1)) $2 = 362880 scheme@(guile-user)> (sqrt $2) $3 = 602.3952191045344 scheme@(guile-user)> (cons $2 $1) $4 = (362880 0 1 2 3 4 5 6 7 8 9) Value history is enabled by default, because Guile's REPL imports the ‘(ice-9 history)’ module. Value history may be turned off or on within the repl, using the options interface: scheme@(guile-user)> ,option value-history #f scheme@(guile-user)> 'foo foo scheme@(guile-user)> ,option value-history #t scheme@(guile-user)> 'bar $5 = bar Note that previously recorded values are still accessible, even if value history is off. In rare cases, these references to past computations can cause Guile to use too much memory. One may clear these values, possibly enabling garbage collection, via the ‘clear-value-history!’ procedure, described below. The programmatic interface to value history is in a module: (use-modules (ice-9 history)) -- Scheme Procedure: value-history-enabled? Return true if value history is enabled, or false otherwise. -- Scheme Procedure: enable-value-history! Turn on value history, if it was off. -- Scheme Procedure: disable-value-history! Turn off value history, if it was on. -- Scheme Procedure: clear-value-history! Clear the value history. If the stored values are not captured by some other data structure or closure, they may then be reclaimed by the garbage collector. 4.4.4 REPL Commands ------------------- The REPL exists to read expressions, evaluate them, and then print their results. But sometimes one wants to tell the REPL to evaluate an expression in a different way, or to do something else altogether. A user can affect the way the REPL works with a “REPL command”. The previous section had an example of a command, in the form of ‘,option’. scheme@(guile-user)> ,option value-history #t Commands are distinguished from expressions by their initial comma (‘,’). Since a comma cannot begin an expression in most languages, it is an effective indicator to the REPL that the following text forms a command, not an expression. REPL commands are convenient because they are always there. Even if the current module doesn't have a binding for ‘pretty-print’, one can always ‘,pretty-print’. The following sections document the various commands, grouped together by functionality. Many of the commands have abbreviations; see the online help (‘,help’) for more information. 4.4.4.1 Help Commands ..................... When Guile starts interactively, it notifies the user that help can be had by typing ‘,help’. Indeed, ‘help’ is a command, and a particularly useful one, as it allows the user to discover the rest of the commands. -- REPL Command: help [all | group | [-c] command] Show help. With one argument, tries to look up the argument as a group name, giving help on that group if successful. Otherwise tries to look up the argument as a command, giving help on the command. If there is a command whose name is also a group name, use the ‘-c COMMAND’ form to give help on the command instead of the group. Without any argument, a list of help commands and command groups are displayed. -- REPL Command: show [topic] Gives information about Guile. With one argument, tries to show a particular piece of information; currently supported topics are 'warranty' (or 'w'), 'copying' (or 'c'), and 'version' (or 'v'). Without any argument, a list of topics is displayed. -- REPL Command: apropos regexp Find bindings/modules/packages. -- REPL Command: describe obj Show description/documentation. 4.4.4.2 Module Commands ....................... -- REPL Command: module [module] Change modules / Show current module. -- REPL Command: import module ... Import modules / List those imported. -- REPL Command: load file Load a file in the current module. -- REPL Command: reload [module] Reload the given module, or the current module if none was given. -- REPL Command: binding List current bindings. -- REPL Command: in module expression -- REPL Command: in module command arg ... Evaluate an expression, or alternatively, execute another meta-command in the context of a module. For example, ‘,in (foo bar) ,binding’ will show the bindings in the module ‘(foo bar)’. 4.4.4.3 Language Commands ......................... -- REPL Command: language language Change languages. 4.4.4.4 Compile Commands ........................ -- REPL Command: compile exp Generate compiled code. -- REPL Command: compile-file file Compile a file. -- REPL Command: expand exp Expand any macros in a form. -- REPL Command: optimize exp Run the optimizer on a piece of code and print the result. -- REPL Command: disassemble exp Disassemble a compiled procedure. -- REPL Command: disassemble-file file Disassemble a file. 4.4.4.5 Profile Commands ........................ -- REPL Command: time exp Time execution. -- REPL Command: profile exp [#:hz hz=100] [#:count-calls? count-calls?=#f] [#:display-style display-style=list] Profile execution of an expression. This command compiled EXP and then runs it within the statprof profiler, passing all keyword options to the ‘statprof’ procedure. For more on statprof and on the the options available to this command, *Note Statprof::. -- REPL Command: trace exp [#:width w] [#:max-indent i] Trace execution. By default, the trace will limit its width to the width of your terminal, or WIDTH if specified. Nested procedure invocations will be printed farther to the right, though if the width of the indentation passes the MAX-INDENT, the indentation is abbreviated. These REPL commands can also be called as regular functions in scheme code on including the ‘(ice-9 time)’ module. 4.4.4.6 Debug Commands ...................... These debugging commands are only available within a recursive REPL; they do not work at the top level. -- REPL Command: backtrace [count] [#:width w] [#:full? f] Print a backtrace. Print a backtrace of all stack frames, or innermost COUNT frames. If COUNT is negative, the last COUNT frames will be shown. -- REPL Command: up [count] Select a calling stack frame. Select and print stack frames that called this one. An argument says how many frames up to go. -- REPL Command: down [count] Select a called stack frame. Select and print stack frames called by this one. An argument says how many frames down to go. -- REPL Command: frame [idx] Show a frame. Show the selected frame. With an argument, select a frame by index, then show it. -- REPL Command: locals Show local variables. Show locally-bound variables in the selected frame. -- REPL Command: error-message -- REPL Command: error Show error message. Display the message associated with the error that started the current debugging REPL. -- REPL Command: registers Show the VM registers associated with the current frame. *Note Stack Layout::, for more information on VM stack frames. -- REPL Command: width [cols] Sets the number of display columns in the output of ‘,backtrace’ and ‘,locals’ to COLS. If COLS is not given, the width of the terminal is used. The next 3 commands work at any REPL. -- REPL Command: break proc Set a breakpoint at PROC. -- REPL Command: break-at-source file line Set a breakpoint at the given source location. -- REPL Command: tracepoint proc Set a tracepoint on the given procedure. This will cause all calls to the procedure to print out a tracing message. *Note Tracing Traps::, for more information. The rest of the commands in this subsection all apply only when the stack is “continuable” -- in other words when it makes sense for the program that the stack comes from to continue running. Usually this means that the program stopped because of a trap or a breakpoint. -- REPL Command: step Tell the debugged program to step to the next source location. -- REPL Command: next Tell the debugged program to step to the next source location in the same frame. (See *note Traps:: for the details of how this works.) -- REPL Command: finish Tell the program being debugged to continue running until the completion of the current stack frame, and at that time to print the result and reenter the REPL. 4.4.4.7 Inspect Commands ........................ -- REPL Command: inspect exp Inspect the result(s) of evaluating EXP. -- REPL Command: pretty-print exp Pretty-print the result(s) of evaluating EXP. 4.4.4.8 System Commands ....................... -- REPL Command: gc Garbage collection. -- REPL Command: statistics Display statistics. -- REPL Command: option [name] [exp] With no arguments, lists all options. With one argument, shows the current value of the NAME option. With two arguments, sets the NAME option to the result of evaluating the Scheme expression EXP. -- REPL Command: quit Quit this session. Current REPL options include: ‘compile-options’ The options used when compiling expressions entered at the REPL. *Note Compilation::, for more on compilation options. ‘interp’ Whether to interpret or compile expressions given at the REPL, if such a choice is available. Off by default (indicating compilation). ‘prompt’ A customized REPL prompt. ‘#f’ by default, indicating the default prompt. ‘print’ A procedure of two arguments used to print the result of evaluating each expression. The arguments are the current REPL and the value to print. By default, ‘#f’, to use the default procedure. ‘value-history’ Whether value history is on or not. *Note Value History::. ‘on-error’ What to do when an error happens. By default, ‘debug’, meaning to enter the debugger. Other values include ‘backtrace’, to show a backtrace without entering the debugger, or ‘report’, to simply show a short error printout. Default values for REPL options may be set using ‘repl-default-option-set!’ from ‘(system repl common)’: -- Scheme Procedure: repl-default-option-set! key value Set the default value of a REPL option. This function is particularly useful in a user's init file. *Note Init File::. 4.4.5 Error Handling -------------------- When code being evaluated from the REPL hits an error, Guile enters a new prompt, allowing you to inspect the context of the error. scheme@(guile-user)> (map string-append '("a" "b") '("c" #\d)) ERROR: In procedure string-append: ERROR: Wrong type (expecting string): #\d Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. scheme@(guile-user) [1]> The new prompt runs inside the old one, in the dynamic context of the error. It is a recursive REPL, augmented with a reified representation of the stack, ready for debugging. ‘,backtrace’ (abbreviated ‘,bt’) displays the Scheme call stack at the point where the error occurred: scheme@(guile-user) [1]> ,bt 1 (map # ("a" "b") ("c" #\d)) 0 (string-append "b" #\d) In the above example, the backtrace doesn't have much source information, as ‘map’ and ‘string-append’ are both primitives. But in the general case, the space on the left of the backtrace indicates the line and column in which a given procedure calls another. You can exit a recursive REPL in the same way that you exit any REPL: via ‘(quit)’, ‘,quit’ (abbreviated ‘,q’), or ‘C-d’, among other options. 4.4.6 Interactive Debugging --------------------------- A recursive debugging REPL exposes a number of other meta-commands that inspect the state of the computation at the time of the error. These commands allow you to • display the Scheme call stack at the point where the error occurred; • move up and down the call stack, to see in detail the expression being evaluated, or the procedure being applied, in each “frame”; and • examine the values of variables and expressions in the context of each frame. *Note Debug Commands::, for documentation of the individual commands. This section aims to give more of a walkthrough of a typical debugging session. First, we're going to need a good error. Let's try to macroexpand the expression ‘(unquote foo)’, outside of a ‘quasiquote’ form, and see how the macroexpander reports this error. scheme@(guile-user)> (macroexpand '(unquote foo)) ERROR: In procedure macroexpand: ERROR: unquote: expression not valid outside of quasiquote in (unquote foo) Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. scheme@(guile-user) [1]> The ‘backtrace’ command, which can also be invoked as ‘bt’, displays the call stack (aka backtrace) at the point where the debugger was entered: scheme@(guile-user) [1]> ,bt In ice-9/psyntax.scm: 1130:21 3 (chi-top (unquote foo) () ((top)) e (eval) (hygiene #)) 1071:30 2 (syntax-type (unquote foo) () ((top)) #f #f (# #) #f) 1368:28 1 (chi-macro # ...) In unknown file: 0 (scm-error syntax-error macroexpand "~a: ~a in ~a" # #f) A call stack consists of a sequence of stack “frames”, with each frame describing one procedure which is waiting to do something with the values returned by another. Here we see that there are four frames on the stack. Note that ‘macroexpand’ is not on the stack - it must have made a tail call to ‘chi-top’, as indeed we would find if we searched ‘ice-9/psyntax.scm’ for its definition. When you enter the debugger, the innermost frame is selected, which means that the commands for getting information about the "current" frame, or for evaluating expressions in the context of the current frame, will do so by default with respect to the innermost frame. To select a different frame, so that these operations will apply to it instead, use the ‘up’, ‘down’ and ‘frame’ commands like this: scheme@(guile-user) [1]> ,up In ice-9/psyntax.scm: 1368:28 1 (chi-macro # ...) scheme@(guile-user) [1]> ,frame 3 In ice-9/psyntax.scm: 1130:21 3 (chi-top (unquote foo) () ((top)) e (eval) (hygiene #)) scheme@(guile-user) [1]> ,down In ice-9/psyntax.scm: 1071:30 2 (syntax-type (unquote foo) () ((top)) #f #f (# #) #f) Perhaps we're interested in what's going on in frame 2, so we take a look at its local variables: scheme@(guile-user) [1]> ,locals Local variables: $1 = e = (unquote foo) $2 = r = () $3 = w = ((top)) $4 = s = #f $5 = rib = #f $6 = mod = (hygiene guile-user) $7 = for-car? = #f $8 = first = unquote $9 = ftype = macro $10 = fval = # $11 = fe = unquote $12 = fw = ((top)) $13 = fs = #f $14 = fmod = (hygiene guile-user) All of the values are accessible by their value-history names (‘$N’): scheme@(guile-user) [1]> $10 $15 = # We can even invoke the procedure at the REPL directly: scheme@(guile-user) [1]> ($10 'not-going-to-work) ERROR: In procedure macroexpand: ERROR: source expression failed to match any pattern in not-going-to-work Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. Well at this point we've caused an error within an error. Let's just quit back to the top level: scheme@(guile-user) [2]> ,q scheme@(guile-user) [1]> ,q scheme@(guile-user)> Finally, as a word to the wise: hackers close their REPL prompts with ‘C-d’. 4.5 Using Guile in Emacs ======================== Any text editor can edit Scheme, but some are better than others. Emacs is the best, of course, and not just because it is a fine text editor. Emacs has good support for Scheme out of the box, with sensible indentation rules, parenthesis-matching, syntax highlighting, and even a set of keybindings for structural editing, allowing navigation, cut-and-paste, and transposition operations that work on balanced S-expressions. As good as it is, though, two things will vastly improve your experience with Emacs and Guile. The first is Taylor Campbell's Paredit (http://www.emacswiki.org/emacs/ParEdit). You should not code in any dialect of Lisp without Paredit. (They say that unopinionated writing is boring--hence this tone--but it's the truth, regardless.) Paredit is the bee's knees. The second is José Antonio Ortega Ruiz's Geiser (http://www.nongnu.org/geiser/). Geiser complements Emacs' ‘scheme-mode’ with tight integration to running Guile processes via a ‘comint-mode’ REPL buffer. Of course there are keybindings to switch to the REPL, and a good REPL environment, but Geiser goes beyond that, providing: • Form evaluation in the context of the current file's module. • Macro expansion. • File/module loading and/or compilation. • Namespace-aware identifier completion (including local bindings, names visible in the current module, and module names). • Autodoc: the echo area shows information about the signature of the procedure/macro around point automatically. • Jump to definition of identifier at point. • Access to documentation (including docstrings when the implementation provides it). • Listings of identifiers exported by a given module. • Listings of callers/callees of procedures. • Rudimentary support for debugging and error navigation. • Support for multiple, simultaneous REPLs. See Geiser's web page at , for more information. 4.6 Using Guile Tools ===================== Guile also comes with a growing number of command-line utilities: a compiler, a disassembler, some module inspectors, and in the future, a system to install Guile packages from the internet. These tools may be invoked using the ‘guild’ program. $ guild compile -o foo.go foo.scm wrote `foo.go' This program used to be called ‘guile-tools’ up to Guile version 2.0.1, and for backward compatibility it still may be called as such. However we changed the name to ‘guild’, not only because it is pleasantly shorter and easier to read, but also because this tool will serve to bind Guile wizards together, by allowing hackers to share code with each other using a CPAN-like system. *Note Compilation::, for more on ‘guild compile’. A complete list of guild scripts can be had by invoking ‘guild list’, or simply ‘guild’. 4.7 Installing Site Packages ============================ At some point, you will probably want to share your code with other people. To do so effectively, it is important to follow a set of common conventions, to make it easy for the user to install and use your package. The first thing to do is to install your Scheme files where Guile can find them. When Guile goes to find a Scheme file, it will search a “load path” to find the file: first in Guile's own path, then in paths for “site packages”. A site package is any Scheme code that is installed and not part of Guile itself. *Note Load Paths::, for more on load paths. There are several site paths, for historical reasons, but the one that should generally be used can be obtained by invoking the ‘%site-dir’ procedure. *Note Build Config::. If Guile 3.0 is installed on your system in ‘/usr/’, then ‘(%site-dir)’ will be ‘/usr/share/guile/site/3.0’. Scheme files should be installed there. If you do not install compiled ‘.go’ files, Guile will compile your modules and programs when they are first used, and cache them in the user's home directory. *Note Compilation::, for more on auto-compilation. However, it is better to compile the files before they are installed, and to just copy the files to a place that Guile can find them. As with Scheme files, Guile searches a path to find compiled ‘.go’ files, the ‘%load-compiled-path’. By default, this path has two entries: a path for Guile's files, and a path for site packages. You should install your ‘.go’ files into the latter directory, whose value is returned by invoking the ‘%site-ccache-dir’ procedure. As in the previous example, if Guile 3.0 is installed on your system in ‘/usr/’, then ‘(%site-ccache-dir)’ site packages will be ‘/usr/lib/guile/3.0/site-ccache’. Note that a ‘.go’ file will only be loaded in preference to a ‘.scm’ file if it is newer. For that reason, you should install your Scheme files first, and your compiled files second. *Note Load Paths::, for more on the loading process. Finally, although this section is only about Scheme, sometimes you need to install C extensions too. Shared libraries should be installed in the “extensions dir”. This value can be had from the build config (*note Build Config::). Again, if Guile 3.0 is installed on your system in ‘/usr/’, then the extensions dir will be ‘/usr/lib/guile/3.0/extensions’. 4.8 Distributing Guile Code =========================== There's a tool that doesn't come bundled with Guile and yet can be very useful in your day to day experience with it. This tool is Hall (https://gitlab.com/a-sassmannshausen/guile-hall). Hall helps you create, manage, and package your Guile projects through a simple command-line interface. When you start a new project, Hall creates a folder containing a scaffold of your new project. It contains a directory for your tests, for your libraries, for your scripts and for your documentation. This means you immediately know where to put the files you are hacking on. In addition, the scaffold will include your basic "Autotools" setup, so you don't have to take care of that yourself (*note (autoconf)The GNU Build System::, for more information on the GNU "Autotools"). Having Autotools set up with your project means you can immediately start hacking on your project without worrying about whether your code will work on other people's computers. Hall can also generate package definitions for the GNU Guix package manager, making it easy for Guix users to install it. 5 Programming in C ****************** This part of the manual explains the general concepts that you need to understand when interfacing to Guile from C. You will learn about how the latent typing of Scheme is embedded into the static typing of C, how the garbage collection of Guile is made available to C code, and how continuations influence the control flow in a C program. This knowledge should make it straightforward to add new functions to Guile that can be called from Scheme. Adding new data types is also possible and is done by defining “foreign objects”. The *note Programming Overview:: section of this part contains general musings and guidelines about programming with Guile. It explores different ways to design a program around Guile, or how to embed Guile into existing programs. For a pedagogical yet detailed explanation of how the data representation of Guile is implemented, *Note Data Representation::. You don't need to know the details given there to use Guile from C, but they are useful when you want to modify Guile itself or when you are just curious about how it is all done. For detailed reference information on the variables, functions etc. that make up Guile's application programming interface (API), *Note API Reference::. 5.1 Parallel Installations ========================== Guile provides strong API and ABI stability guarantees during stable series, so that if a user writes a program against Guile version 2.2.3, it will be compatible with some future version 2.2.7. We say in this case that 2.2 is the “effective version”, composed of the major and minor versions, in this case 2 and 2. Users may install multiple effective versions of Guile, with each version's headers, libraries, and Scheme files under their own directories. This provides the necessary stability guarantee for users, while also allowing Guile developers to evolve the language and its implementation. However, parallel installability does have a down-side, in that users need to know which version of Guile to ask for, when they build against Guile. Guile solves this problem by installing a file to be read by the ‘pkg-config’ utility, a tool to query installed packages by name. Guile encodes the version into its pkg-config name, so that users can ask for ‘guile-2.2’ or ‘guile-3.0’, as appropriate. For effective version 3.0, for example, you would invoke ‘pkg-config --cflags --libs guile-3.0’ to get the compilation and linking flags necessary to link to version 3.0 of Guile. You would typically run ‘pkg-config’ during the configuration phase of your program and use the obtained information in the Makefile. Guile's ‘pkg-config’ file, ‘guile-3.0.pc’, defines additional useful variables: ‘sitedir’ The default directory where Guile looks for Scheme source and compiled files (*note %site-dir: Installing Site Packages.). Run ‘pkg-config guile-3.0 --variable=sitedir’ to see its value. *Note GUILE_SITE_DIR: Autoconf Macros, for more on how to use it from Autoconf. ‘extensiondir’ The default directory where Guile looks for extensions--i.e., shared libraries providing additional features (*note Foreign Extensions::). Run ‘pkg-config guile-3.0 --variable=extensiondir’ to see its value. ‘guile’ ‘guild’ The absolute file name of the ‘guile’ and ‘guild’ commands(1). Run ‘pkg-config guile-3.0 --variable=guile’ or ‘--variable=guild’ to see their value. These variables allow users to deal with program name transformations that may be specified when configuring Guile with ‘--program-transform-name’, ‘--program-suffix’, or ‘--program-prefix’ (*note (autoconf)Transformation Options::). See the ‘pkg-config’ man page, for more information, or its web site, . *Note Autoconf Support::, for more on checking for Guile from within a ‘configure.ac’ file. ---------- Footnotes ---------- (1) The ‘guile’ and ‘guild’ variables defined starting from Guile version 2.0.12. 5.2 Linking Programs With Guile =============================== This section covers the mechanics of linking your program with Guile on a typical POSIX system. The header file ‘’ provides declarations for all of Guile's functions and constants. You should ‘#include’ it at the head of any C source file that uses identifiers described in this manual. Once you've compiled your source files, you need to link them against the Guile object code library, ‘libguile’. As noted in the previous section, ‘’ is not in the default search path for headers. The following command lines give respectively the C compilation and link flags needed to build programs using Guile 3.0: pkg-config guile-3.0 --cflags pkg-config guile-3.0 --libs 5.2.1 Guile Initialization Functions ------------------------------------ To initialize Guile, you can use one of several functions. The first, ‘scm_with_guile’, is the most portable way to initialize Guile. It will initialize Guile when necessary and then call a function that you can specify. Multiple threads can call ‘scm_with_guile’ concurrently and it can also be called more than once in a given thread. The global state of Guile will survive from one call of ‘scm_with_guile’ to the next. Your function is called from within ‘scm_with_guile’ since the garbage collector of Guile needs to know where the stack of each thread is. A second function, ‘scm_init_guile’, initializes Guile for the current thread. When it returns, you can use the Guile API in the current thread. This function employs some non-portable magic to learn about stack bounds and might thus not be available on all platforms. One common way to use Guile is to write a set of C functions which perform some useful task, make them callable from Scheme, and then link the program with Guile. This yields a Scheme interpreter just like ‘guile’, but augmented with extra functions for some specific application -- a special-purpose scripting language. In this situation, the application should probably process its command-line arguments in the same manner as the stock Guile interpreter. To make that straightforward, Guile provides the ‘scm_boot_guile’ and ‘scm_shell’ function. For more about these functions, see *note Initialization::. 5.2.2 A Sample Guile Main Program --------------------------------- Here is ‘simple-guile.c’, source code for a ‘main’ and an ‘inner_main’ function that will produce a complete Guile interpreter. /* simple-guile.c --- Start Guile from C. */ #include static void inner_main (void *closure, int argc, char **argv) { /* preparation */ scm_shell (argc, argv); /* after exit */ } int main (int argc, char **argv) { scm_boot_guile (argc, argv, inner_main, 0); return 0; /* never reached, see inner_main */ } The ‘main’ function calls ‘scm_boot_guile’ to initialize Guile, passing it ‘inner_main’. Once ‘scm_boot_guile’ is ready, it invokes ‘inner_main’, which calls ‘scm_shell’ to process the command-line arguments in the usual way. 5.2.3 Building the Example with Make ------------------------------------ Here is a Makefile which you can use to compile the example program. It uses ‘pkg-config’ to learn about the necessary compiler and linker flags. # Use GCC, if you have it installed. CC=gcc # Tell the C compiler where to find CFLAGS=`pkg-config --cflags guile-3.0` # Tell the linker what libraries to use and where to find them. LIBS=`pkg-config --libs guile-3.0` simple-guile: simple-guile.o ${CC} simple-guile.o ${LIBS} -o simple-guile simple-guile.o: simple-guile.c ${CC} -c ${CFLAGS} simple-guile.c 5.2.4 Building the Example with Autoconf ---------------------------------------- If you are using the GNU Autoconf package to make your application more portable, Autoconf will settle many of the details in the Makefile automatically, making it much simpler and more portable; we recommend using Autoconf with Guile. Here is a ‘configure.ac’ file for ‘simple-guile’ that uses the standard ‘PKG_CHECK_MODULES’ macro to check for Guile. Autoconf will process this file into a ‘configure’ script. We recommend invoking Autoconf via the ‘autoreconf’ utility. AC_INIT(simple-guile.c) # Find a C compiler. AC_PROG_CC # Check for Guile PKG_CHECK_MODULES([GUILE], [guile-3.0]) # Generate a Makefile, based on the results. AC_OUTPUT(Makefile) Run ‘autoreconf -vif’ to generate ‘configure’. Here is a ‘Makefile.in’ template, from which the ‘configure’ script produces a Makefile customized for the host system: # The configure script fills in these values. CC=@CC@ CFLAGS=@GUILE_CFLAGS@ LIBS=@GUILE_LIBS@ simple-guile: simple-guile.o ${CC} simple-guile.o ${LIBS} -o simple-guile simple-guile.o: simple-guile.c ${CC} -c ${CFLAGS} simple-guile.c The developer should use Autoconf to generate the ‘configure’ script from the ‘configure.ac’ template, and distribute ‘configure’ with the application. Here's how a user might go about building the application: $ ls Makefile.in configure* configure.ac simple-guile.c $ ./configure checking for gcc... ccache gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether ccache gcc accepts -g... yes checking for ccache gcc option to accept ISO C89... none needed checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for GUILE... yes configure: creating ./config.status config.status: creating Makefile $ make [...] $ ./simple-guile guile> (+ 1 2 3) 6 guile> (getpwnam "jimb") #("jimb" "83Z7d75W2tyJQ" 4008 10 "Jim Blandy" "/u/jimb" "/usr/local/bin/bash") guile> (exit) $ 5.3 Linking Guile with Libraries ================================ The previous section has briefly explained how to write programs that make use of an embedded Guile interpreter. But sometimes, all you want to do is make new primitive procedures and data types available to the Scheme programmer. Writing a new version of ‘guile’ is inconvenient in this case and it would in fact make the life of the users of your new features needlessly hard. For example, suppose that there is a program ‘guile-db’ that is a version of Guile with additional features for accessing a database. People who want to write Scheme programs that use these features would have to use ‘guile-db’ instead of the usual ‘guile’ program. Now suppose that there is also a program ‘guile-gtk’ that extends Guile with access to the popular Gtk+ toolkit for graphical user interfaces. People who want to write GUIs in Scheme would have to use ‘guile-gtk’. Now, what happens when you want to write a Scheme application that uses a GUI to let the user access a database? You would have to write a _third_ program that incorporates both the database stuff and the GUI stuff. This might not be easy (because ‘guile-gtk’ might be a quite obscure program, say) and taking this example further makes it easy to see that this approach can not work in practice. It would have been much better if both the database features and the GUI feature had been provided as libraries that can just be linked with ‘guile’. Guile makes it easy to do just this, and we encourage you to make your extensions to Guile available as libraries whenever possible. You write the new primitive procedures and data types in the normal fashion, and link them into a shared library instead of into a stand-alone program. The shared library can then be loaded dynamically by Guile. 5.3.1 A Sample Guile Extension ------------------------------ This section explains how to make the Bessel functions of the C library available to Scheme. First we need to write the appropriate glue code to convert the arguments and return values of the functions from Scheme to C and back. Additionally, we need a function that will add them to the set of Guile primitives. Because this is just an example, we will only implement this for the ‘j0’ function. Consider the following file ‘bessel.c’. #include #include SCM j0_wrapper (SCM x) { return scm_from_double (j0 (scm_to_double (x))); } void init_bessel () { scm_c_define_gsubr ("j0", 1, 0, 0, j0_wrapper); } This C source file needs to be compiled into a shared library. Here is how to do it on GNU/Linux: gcc `pkg-config --cflags guile-3.0` \ -shared -o libguile-bessel.so -fPIC bessel.c For creating shared libraries portably, we recommend the use of GNU Libtool (*note Introduction: (libtool)Top.). A shared library can be loaded into a running Guile process with the function ‘load-extension’. In addition to the name of the library to load, this function also expects the name of a function from that library that will be called to initialize it. For our example, we are going to call the function ‘init_bessel’ which will make ‘j0_wrapper’ available to Scheme programs with the name ‘j0’. Note that we do not specify a filename extension such as ‘.so’ when invoking ‘load-extension’. The right extension for the host platform will be provided automatically. (load-extension "libguile-bessel" "init_bessel") (j0 2) ⇒ 0.223890779141236 For this to work, ‘load-extension’ must be able to find ‘libguile-bessel’, of course. It will look in the places that are usual for your operating system, and it will additionally look into the directories listed in the ‘LTDL_LIBRARY_PATH’ environment variable. To see how these Guile extensions via shared libraries relate to the module system, *Note Putting Extensions into Modules::. 5.4 General concepts for using libguile ======================================= When you want to embed the Guile Scheme interpreter into your program or library, you need to link it against the ‘libguile’ library (*note Linking Programs With Guile::). Once you have done this, your C code has access to a number of data types and functions that can be used to invoke the interpreter, or make new functions that you have written in C available to be called from Scheme code, among other things. Scheme is different from C in a number of significant ways, and Guile tries to make the advantages of Scheme available to C as well. Thus, in addition to a Scheme interpreter, libguile also offers dynamic types, garbage collection, continuations, arithmetic on arbitrary sized numbers, and other things. The two fundamental concepts are dynamic types and garbage collection. You need to understand how libguile offers them to C programs in order to use the rest of libguile. Also, the more general control flow of Scheme caused by continuations needs to be dealt with. Running asynchronous signal handlers and multi-threading is known to C code already, but there are of course a few additional rules when using them together with libguile. 5.4.1 Dynamic Types ------------------- Scheme is a dynamically-typed language; this means that the system cannot, in general, determine the type of a given expression at compile time. Types only become apparent at run time. Variables do not have fixed types; a variable may hold a pair at one point, an integer at the next, and a thousand-element vector later. Instead, values, not variables, have fixed types. In order to implement standard Scheme functions like ‘pair?’ and ‘string?’ and provide garbage collection, the representation of every value must contain enough information to accurately determine its type at run time. Often, Scheme systems also use this information to determine whether a program has attempted to apply an operation to an inappropriately typed value (such as taking the ‘car’ of a string). Because variables, pairs, and vectors may hold values of any type, Scheme implementations use a uniform representation for values -- a single type large enough to hold either a complete value or a pointer to a complete value, along with the necessary typing information. In Guile, this uniform representation of all Scheme values is the C type ‘SCM’. This is an opaque type and its size is typically equivalent to that of a pointer to ‘void’. Thus, ‘SCM’ values can be passed around efficiently and they take up reasonably little storage on their own. The most important rule is: You never access a ‘SCM’ value directly; you only pass it to functions or macros defined in libguile. As an obvious example, although a ‘SCM’ variable can contain integers, you can of course not compute the sum of two ‘SCM’ values by adding them with the C ‘+’ operator. You must use the libguile function ‘scm_sum’. Less obvious and therefore more important to keep in mind is that you also cannot directly test ‘SCM’ values for trueness. In Scheme, the value ‘#f’ is considered false and of course a ‘SCM’ variable can represent that value. But there is no guarantee that the ‘SCM’ representation of ‘#f’ looks false to C code as well. You need to use ‘scm_is_true’ or ‘scm_is_false’ to test a ‘SCM’ value for trueness or falseness, respectively. You also can not directly compare two ‘SCM’ values to find out whether they are identical (that is, whether they are ‘eq?’ in Scheme terms). You need to use ‘scm_is_eq’ for this. The one exception is that you can directly assign a ‘SCM’ value to a ‘SCM’ variable by using the C ‘=’ operator. The following (contrived) example shows how to do it right. It implements a function of two arguments (A and FLAG) that returns A+1 if FLAG is true, else it returns A unchanged. SCM my_incrementing_function (SCM a, SCM flag) { SCM result; if (scm_is_true (flag)) result = scm_sum (a, scm_from_int (1)); else result = a; return result; } Often, you need to convert between ‘SCM’ values and appropriate C values. For example, we needed to convert the integer ‘1’ to its ‘SCM’ representation in order to add it to A. Libguile provides many function to do these conversions, both from C to ‘SCM’ and from ‘SCM’ to C. The conversion functions follow a common naming pattern: those that make a ‘SCM’ value from a C value have names of the form ‘scm_from_TYPE (...)’ and those that convert a ‘SCM’ value to a C value use the form ‘scm_to_TYPE (...)’. However, it is best to avoid converting values when you can. When you must combine C values and ‘SCM’ values in a computation, it is often better to convert the C values to ‘SCM’ values and do the computation by using libguile functions than to the other way around (converting ‘SCM’ to C and doing the computation some other way). As a simple example, consider this version of ‘my_incrementing_function’ from above: SCM my_other_incrementing_function (SCM a, SCM flag) { int result; if (scm_is_true (flag)) result = scm_to_int (a) + 1; else result = scm_to_int (a); return scm_from_int (result); } This version is much less general than the original one: it will only work for values A that can fit into a ‘int’. The original function will work for all values that Guile can represent and that ‘scm_sum’ can understand, including integers bigger than ‘long long’, floating point numbers, complex numbers, and new numerical types that have been added to Guile by third-party libraries. Also, computing with ‘SCM’ is not necessarily inefficient. Small integers will be encoded directly in the ‘SCM’ value, for example, and do not need any additional memory on the heap. See *note Data Representation:: to find out the details. Some special ‘SCM’ values are available to C code without needing to convert them from C values: Scheme value C representation #f SCM_BOOL_F #t SCM_BOOL_T () SCM_EOL In addition to ‘SCM’, Guile also defines the related type ‘scm_t_bits’. This is an unsigned integral type of sufficient size to hold all information that is directly contained in a ‘SCM’ value. The ‘scm_t_bits’ type is used internally by Guile to do all the bit twiddling explained in *note Data Representation::, but you will encounter it occasionally in low-level user code as well. 5.4.2 Garbage Collection ------------------------ As explained above, the ‘SCM’ type can represent all Scheme values. Some values fit entirely into a ‘SCM’ value (such as small integers), but other values require additional storage in the heap (such as strings and vectors). This additional storage is managed automatically by Guile. You don't need to explicitly deallocate it when a ‘SCM’ value is no longer used. Two things must be guaranteed so that Guile is able to manage the storage automatically: it must know about all blocks of memory that have ever been allocated for Scheme values, and it must know about all Scheme values that are still being used. Given this knowledge, Guile can periodically free all blocks that have been allocated but are not used by any active Scheme values. This activity is called “garbage collection”. Guile's garbage collector will automatically discover references to ‘SCM’ objects that originate in global variables, static data sections, function arguments or local variables on the C and Scheme stacks, and values in machine registers. Other references to ‘SCM’ objects, such as those in other random data structures in the C heap that contain fields of type ‘SCM’, can be made visible to the garbage collector by calling the functions ‘scm_gc_protect_object’ or ‘scm_permanent_object’. Collectively, these values form the "root set" of garbage collection; any value on the heap that is referenced directly or indirectly by a member of the root set is preserved, and all other objects are eligible for reclamation. In Guile, garbage collection has two logical phases: the “mark phase”, in which the collector discovers the set of all live objects, and the “sweep phase”, in which the collector reclaims the resources associated with dead objects. The mark phase pauses the program and traces all ‘SCM’ object references, starting with the root set. The sweep phase actually runs concurrently with the main program, incrementally reclaiming memory as needed by allocation. In the mark phase, the garbage collector traces the Scheme stack and heap “precisely”. Because the Scheme stack and heap are managed by Guile, Guile can know precisely where in those data structures it might find references to other heap objects. This is not the case, unfortunately, for pointers on the C stack and static data segment. Instead of requiring the user to inform Guile about all variables in C that might point to heap objects, Guile traces the C stack and static data segment “conservatively”. That is to say, Guile just treats every word on the C stack and every C global variable as a potential reference in to the Scheme heap(1). Any value that looks like a pointer to a GC-managed object is treated as such, whether it actually is a reference or not. Thus, scanning the C stack and static data segment is guaranteed to find all actual references, but it might also find words that only accidentally look like references. These "false positives" might keep ‘SCM’ objects alive that would otherwise be considered dead. While this might waste memory, keeping an object around longer than it strictly needs to is harmless. This is why this technique is called "conservative garbage collection". In practice, the wasted memory seems to be no problem, as the static C root set is almost always finite and small, given that the Scheme stack is separate from the C stack. The stack of every thread is scanned in this way and the registers of the CPU and all other memory locations where local variables or function parameters might show up are included in this scan as well. The consequence of the conservative scanning is that you can just declare local variables and function parameters of type ‘SCM’ and be sure that the garbage collector will not free the corresponding objects. However, a local variable or function parameter is only protected as long as it is really on the stack (or in some register). As an optimization, the C compiler might reuse its location for some other value and the ‘SCM’ object would no longer be protected. Normally, this leads to exactly the right behavior: the compiler will only overwrite a reference when it is no longer needed and thus the object becomes unprotected precisely when the reference disappears, just as wanted. There are situations, however, where a ‘SCM’ object needs to be around longer than its reference from a local variable or function parameter. This happens, for example, when you retrieve some pointer from a foreign object and work with that pointer directly. The reference to the ‘SCM’ foreign object might be dead after the pointer has been retrieved, but the pointer itself (and the memory pointed to) is still in use and thus the foreign object must be protected. The compiler does not know about this connection and might overwrite the ‘SCM’ reference too early. To get around this problem, you can use ‘scm_remember_upto_here_1’ and its cousins. It will keep the compiler from overwriting the reference. *Note Foreign Object Memory Management::. ---------- Footnotes ---------- (1) Note that Guile does not scan the C heap for references, so a reference to a ‘SCM’ object from a memory segment allocated with ‘malloc’ will have to use some other means to keep the ‘SCM’ object alive. *Note Garbage Collection Functions::. 5.4.3 Control Flow ------------------ Scheme has a more general view of program flow than C, both locally and non-locally. Controlling the local flow of control involves things like gotos, loops, calling functions and returning from them. Non-local control flow refers to situations where the program jumps across one or more levels of function activations without using the normal call or return operations. The primitive means of C for local control flow is the ‘goto’ statement, together with ‘if’. Loops done with ‘for’, ‘while’ or ‘do’ could in principle be rewritten with just ‘goto’ and ‘if’. In Scheme, the primitive means for local control flow is the _function call_ (together with ‘if’). Thus, the repetition of some computation in a loop is ultimately implemented by a function that calls itself, that is, by recursion. This approach is theoretically very powerful since it is easier to reason formally about recursion than about gotos. In C, using recursion exclusively would not be practical, though, since it would eat up the stack very quickly. In Scheme, however, it is practical: function calls that appear in a “tail position” do not use any additional stack space (*note Tail Calls::). A function call is in a tail position when it is the last thing the calling function does. The value returned by the called function is immediately returned from the calling function. In the following example, the call to ‘bar-1’ is in a tail position, while the call to ‘bar-2’ is not. (The call to ‘1-’ in ‘foo-2’ is in a tail position, though.) (define (foo-1 x) (bar-1 (1- x))) (define (foo-2 x) (1- (bar-2 x))) Thus, when you take care to recurse only in tail positions, the recursion will only use constant stack space and will be as good as a loop constructed from gotos. Scheme offers a few syntactic abstractions (‘do’ and “named” ‘let’) that make writing loops slightly easier. But only Scheme functions can call other functions in a tail position: C functions can not. This matters when you have, say, two functions that call each other recursively to form a common loop. The following (unrealistic) example shows how one might go about determining whether a non-negative integer N is even or odd. (define (my-even? n) (cond ((zero? n) #t) (else (my-odd? (1- n))))) (define (my-odd? n) (cond ((zero? n) #f) (else (my-even? (1- n))))) Because the calls to ‘my-even?’ and ‘my-odd?’ are in tail positions, these two procedures can be applied to arbitrary large integers without overflowing the stack. (They will still take a lot of time, of course.) However, when one or both of the two procedures would be rewritten in C, it could no longer call its companion in a tail position (since C does not have this concept). You might need to take this consideration into account when deciding which parts of your program to write in Scheme and which in C. In addition to calling functions and returning from them, a Scheme program can also exit non-locally from a function so that the control flow returns directly to an outer level. This means that some functions might not return at all. Even more, it is not only possible to jump to some outer level of control, a Scheme program can also jump back into the middle of a function that has already exited. This might cause some functions to return more than once. In general, these non-local jumps are done by invoking “continuations” that have previously been captured using ‘call-with-current-continuation’. Guile also offers a slightly restricted set of functions, ‘catch’ and ‘throw’, that can only be used for non-local exits. This restriction makes them more efficient. Error reporting (with the function ‘error’) is implemented by invoking ‘throw’, for example. The functions ‘catch’ and ‘throw’ belong to the topic of “exceptions”. Since Scheme functions can call C functions and vice versa, C code can experience the more general control flow of Scheme as well. It is possible that a C function will not return at all, or will return more than once. While C does offer ‘setjmp’ and ‘longjmp’ for non-local exits, it is still an unusual thing for C code. In contrast, non-local exits are very common in Scheme, mostly to report errors. You need to be prepared for the non-local jumps in the control flow whenever you use a function from ‘libguile’: it is best to assume that any ‘libguile’ function might signal an error or run a pending signal handler (which in turn can do arbitrary things). It is often necessary to take cleanup actions when the control leaves a function non-locally. Also, when the control returns non-locally, some setup actions might be called for. For example, the Scheme function ‘with-output-to-port’ needs to modify the global state so that ‘current-output-port’ returns the port passed to ‘with-output-to-port’. The global output port needs to be reset to its previous value when ‘with-output-to-port’ returns normally or when it is exited non-locally. Likewise, the port needs to be set again when control enters non-locally. Scheme code can use the ‘dynamic-wind’ function to arrange for the setting and resetting of the global state. C code can use the corresponding ‘scm_internal_dynamic_wind’ function, or a ‘scm_dynwind_begin’/‘scm_dynwind_end’ pair together with suitable 'dynwind actions' (*note Dynamic Wind::). Instead of coping with non-local control flow, you can also prevent it by erecting a _continuation barrier_, *Note Continuation Barriers::. The function ‘scm_c_with_continuation_barrier’, for example, is guaranteed to return exactly once. 5.4.4 Asynchronous Signals -------------------------- You can not call libguile functions from handlers for POSIX signals, but you can register Scheme handlers for POSIX signals such as ‘SIGINT’. These handlers do not run during the actual signal delivery. Instead, they are run when the program (more precisely, the thread that the handler has been registered for) reaches the next _safe point_. The libguile functions themselves have many such safe points. Consequently, you must be prepared for arbitrary actions anytime you call a libguile function. For example, even ‘scm_cons’ can contain a safe point and when a signal handler is pending for your thread, calling ‘scm_cons’ will run this handler and anything might happen, including a non-local exit although ‘scm_cons’ would not ordinarily do such a thing on its own. If you do not want to allow the running of asynchronous signal handlers, you can block them temporarily with ‘scm_dynwind_block_asyncs’, for example. *Note Asyncs::. Since signal handling in Guile relies on safe points, you need to make sure that your functions do offer enough of them. Normally, calling libguile functions in the normal course of action is all that is needed. But when a thread might spent a long time in a code section that calls no libguile function, it is good to include explicit safe points. This can allow the user to interrupt your code with , for example. You can do this with the macro ‘SCM_TICK’. This macro is syntactically a statement. That is, you could use it like this: while (1) { SCM_TICK; do_some_work (); } Frequent execution of a safe point is even more important in multi threaded programs, *Note Multi-Threading::. 5.4.5 Multi-Threading --------------------- Guile can be used in multi-threaded programs just as well as in single-threaded ones. Each thread that wants to use functions from libguile must put itself into _guile mode_ and must then follow a few rules. If it doesn't want to honor these rules in certain situations, a thread can temporarily leave guile mode (but can no longer use libguile functions during that time, of course). Threads enter guile mode by calling ‘scm_with_guile’, ‘scm_boot_guile’, or ‘scm_init_guile’. As explained in the reference documentation for these functions, Guile will then learn about the stack bounds of the thread and can protect the ‘SCM’ values that are stored in local variables. When a thread puts itself into guile mode for the first time, it gets a Scheme representation and is listed by ‘all-threads’, for example. Threads in guile mode can block (e.g., do blocking I/O) without causing any problems(1); temporarily leaving guile mode with ‘scm_without_guile’ before blocking slightly improves GC performance, though. For some common blocking operations, Guile provides convenience functions. For example, if you want to lock a pthread mutex while in guile mode, you might want to use ‘scm_pthread_mutex_lock’ which is just like ‘pthread_mutex_lock’ except that it leaves guile mode while blocking. All libguile functions are (intended to be) robust in the face of multiple threads using them concurrently. This means that there is no risk of the internal data structures of libguile becoming corrupted in such a way that the process crashes. A program might still produce nonsensical results, though. Taking hashtables as an example, Guile guarantees that you can use them from multiple threads concurrently and a hashtable will always remain a valid hashtable and Guile will not crash when you access it. It does not guarantee, however, that inserting into it concurrently from two threads will give useful results: only one insertion might actually happen, none might happen, or the table might in general be modified in a totally arbitrary manner. (It will still be a valid hashtable, but not the one that you might have expected.) Guile might also signal an error when it detects a harmful race condition. Thus, you need to put in additional synchronizations when multiple threads want to use a single hashtable, or any other mutable Scheme object. When writing C code for use with libguile, you should try to make it robust as well. An example that converts a list into a vector will help to illustrate. Here is a correct version: SCM my_list_to_vector (SCM list) { SCM vector = scm_make_vector (scm_length (list), SCM_UNDEFINED); size_t len, i; len = scm_c_vector_length (vector); i = 0; while (i < len && scm_is_pair (list)) { scm_c_vector_set_x (vector, i, scm_car (list)); list = scm_cdr (list); i++; } return vector; } The first thing to note is that storing into a ‘SCM’ location concurrently from multiple threads is guaranteed to be robust: you don't know which value wins but it will in any case be a valid ‘SCM’ value. But there is no guarantee that the list referenced by LIST is not modified in another thread while the loop iterates over it. Thus, while copying its elements into the vector, the list might get longer or shorter. For this reason, the loop must check both that it doesn't overrun the vector and that it doesn't overrun the list. Otherwise, ‘scm_c_vector_set_x’ would raise an error if the index is out of range, and ‘scm_car’ and ‘scm_cdr’ would raise an error if the value is not a pair. It is safe to use ‘scm_car’ and ‘scm_cdr’ on the local variable LIST once it is known that the variable contains a pair. The contents of the pair might change spontaneously, but it will always stay a valid pair (and a local variable will of course not spontaneously point to a different Scheme object). Likewise, a vector such as the one returned by ‘scm_make_vector’ is guaranteed to always stay the same length so that it is safe to only use scm_c_vector_length once and store the result. (In the example, VECTOR is safe anyway since it is a fresh object that no other thread can possibly know about until it is returned from ‘my_list_to_vector’.) Of course the behavior of ‘my_list_to_vector’ is suboptimal when LIST does indeed get asynchronously lengthened or shortened in another thread. But it is robust: it will always return a valid vector. That vector might be shorter than expected, or its last elements might be unspecified, but it is a valid vector and if a program wants to rule out these cases, it must avoid modifying the list asynchronously. Here is another version that is also correct: SCM my_pedantic_list_to_vector (SCM list) { SCM vector = scm_make_vector (scm_length (list), SCM_UNDEFINED); size_t len, i; len = scm_c_vector_length (vector); i = 0; while (i < len) { scm_c_vector_set_x (vector, i, scm_car (list)); list = scm_cdr (list); i++; } return vector; } This version relies on the error-checking behavior of ‘scm_car’ and ‘scm_cdr’. When the list is shortened (that is, when LIST holds a non-pair), ‘scm_car’ will throw an error. This might be preferable to just returning a half-initialized vector. The API for accessing vectors and arrays of various kinds from C takes a slightly different approach to thread-robustness. In order to get at the raw memory that stores the elements of an array, you need to _reserve_ that array as long as you need the raw memory. During the time an array is reserved, its elements can still spontaneously change their values, but the memory itself and other things like the size of the array are guaranteed to stay fixed. Any operation that would change these parameters of an array that is currently reserved will signal an error. In order to avoid these errors, a program should of course put suitable synchronization mechanisms in place. As you can see, Guile itself is again only concerned about robustness, not about correctness: without proper synchronization, your program will likely not be correct, but the worst consequence is an error message. Real thread-safety often requires that a critical section of code is executed in a certain restricted manner. A common requirement is that the code section is not entered a second time when it is already being executed. Locking a mutex while in that section ensures that no other thread will start executing it, blocking asyncs ensures that no asynchronous code enters the section again from the current thread, and the error checking of Guile mutexes guarantees that an error is signaled when the current thread accidentally reenters the critical section via recursive function calls. Guile provides two mechanisms to support critical sections as outlined above. You can either use the macros ‘SCM_CRITICAL_SECTION_START’ and ‘SCM_CRITICAL_SECTION_END’ for very simple sections; or use a dynwind context together with a call to ‘scm_dynwind_critical_section’. The macros only work reliably for critical sections that are guaranteed to not cause a non-local exit. They also do not detect an accidental reentry by the current thread. Thus, you should probably only use them to delimit critical sections that do not contain calls to libguile functions or to other external functions that might do complicated things. The function ‘scm_dynwind_critical_section’, on the other hand, will correctly deal with non-local exits because it requires a dynwind context. Also, by using a separate mutex for each critical section, it can detect accidental reentries. ---------- Footnotes ---------- (1) In Guile 1.8, a thread blocking in guile mode would prevent garbage collection to occur. Thus, threads had to leave guile mode whenever they could block. This is no longer needed with Guile 2.X. 5.5 Defining New Foreign Object Types ===================================== The “foreign object type” facility is Guile's mechanism for importing object and types from C or other languages into Guile's system. If you have a C ‘struct foo’ type, for example, you can define a corresponding Guile foreign object type that allows Scheme code to handle ‘struct foo *’ objects. To define a new foreign object type, the programmer provides Guile with some essential information about the type -- what its name is, how many fields it has, and its finalizer (if any) -- and Guile allocates a fresh type for it. Foreign objects can be accessed from Scheme or from C. 5.5.1 Defining Foreign Object Types ----------------------------------- To create a new foreign object type from C, call ‘scm_make_foreign_object_type’. It returns a value of type ‘SCM’ which identifies the new type. Here is how one might declare a new type representing eight-bit gray-scale images: #include struct image { int width, height; char *pixels; /* The name of this image */ SCM name; /* A function to call when this image is modified, e.g., to update the screen, or SCM_BOOL_F if no action necessary */ SCM update_func; }; static SCM image_type; void init_image_type (void) { SCM name, slots; scm_t_struct_finalize finalizer; name = scm_from_utf8_symbol ("image"); slots = scm_list_1 (scm_from_utf8_symbol ("data")); finalizer = NULL; image_type = scm_make_foreign_object_type (name, slots, finalizer); } The result is an initialized ‘image_type’ value that identifies the new foreign object type. The next section describes how to create foreign objects and how to access their slots. 5.5.2 Creating Foreign Objects ------------------------------ Foreign objects contain zero or more "slots" of data. A slot can hold a pointer, an integer that fits into a ‘size_t’ or ‘ssize_t’, or a ‘SCM’ value. All objects of a given foreign type have the same number of slots. In the example from the previous section, the ‘image’ type has one slot, because the slots list passed to ‘scm_make_foreign_object_type’ is of length one. (The actual names given to slots are unimportant for most users of the C interface, but can be used on the Scheme side to introspect on the foreign object.) To construct a foreign object and initialize its first slot, call ‘scm_make_foreign_object_1 (TYPE, FIRST_SLOT_VALUE)’. There are similarly named constructors for initializing 0, 1, 2, or 3 slots, or initializing N slots via an array. *Note Foreign Objects::, for full details. Any fields that are not explicitly initialized are set to 0. To get or set the value of a slot by index, you can use the ‘scm_foreign_object_ref’ and ‘scm_foreign_object_set_x’ functions. These functions take and return values as ‘void *’ pointers; there are corresponding convenience procedures like ‘_signed_ref’, ‘_unsigned_set_x’ and so on for dealing with slots as signed or unsigned integers. Foreign objects fields that are pointers can be tricky to manage. If possible, it is best that all memory that is referenced by a foreign object be managed by the garbage collector. That way, the GC can automatically ensure that memory is accessible when it is needed, and freed when it becomes inaccessible. If this is not the case for your program - for example, if you are exposing an object to Scheme that was allocated by some other, Guile-unaware part of your program - then you will probably need to implement a finalizer. *Note Foreign Object Memory Management::, for more. Continuing the example from the previous section, if the global variable ‘image_type’ contains the type returned by ‘scm_make_foreign_object_type’, here is how we could construct a foreign object whose "data" field contains a pointer to a freshly allocated ‘struct image’: SCM make_image (SCM name, SCM s_width, SCM s_height) { struct image *image; int width = scm_to_int (s_width); int height = scm_to_int (s_height); /* Allocate the `struct image'. Because we use scm_gc_malloc, this memory block will be automatically reclaimed when it becomes inaccessible, and its members will be traced by the garbage collector. */ image = (struct image *) scm_gc_malloc (sizeof (struct image), "image"); image->width = width; image->height = height; /* Allocating the pixels with scm_gc_malloc_pointerless means that the pixels data is collectable by GC, but that GC shouldn't spend time tracing its contents for nested pointers because there aren't any. */ image->pixels = scm_gc_malloc_pointerless (width * height, "image pixels"); image->name = name; image->update_func = SCM_BOOL_F; /* Now wrap the struct image* in a new foreign object, and return that object. */ return scm_make_foreign_object_1 (image_type, image); } We use ‘scm_gc_malloc_pointerless’ for the pixel buffer to tell the garbage collector not to scan it for pointers. Calls to ‘scm_gc_malloc’, ‘scm_make_foreign_object_1’, and ‘scm_gc_malloc_pointerless’ raise an exception in out-of-memory conditions; the garbage collector is able to reclaim previously allocated memory if that happens. 5.5.3 Type Checking of Foreign Objects -------------------------------------- Functions that operate on foreign objects should check that the passed ‘SCM’ value indeed is of the correct type before accessing its data. They can do this with ‘scm_assert_foreign_object_type’. For example, here is a simple function that operates on an image object, and checks the type of its argument. SCM clear_image (SCM image_obj) { int area; struct image *image; scm_assert_foreign_object_type (image_type, image_obj); image = scm_foreign_object_ref (image_obj, 0); area = image->width * image->height; memset (image->pixels, 0, area); /* Invoke the image's update function. */ if (scm_is_true (image->update_func)) scm_call_0 (image->update_func); return SCM_UNSPECIFIED; } 5.5.4 Foreign Object Memory Management -------------------------------------- Once a foreign object has been released to the tender mercies of the Scheme system, it must be prepared to survive garbage collection. In the example above, all the memory associated with the foreign object is managed by the garbage collector because we used the ‘scm_gc_’ allocation functions. Thus, no special care must be taken: the garbage collector automatically scans them and reclaims any unused memory. However, when data associated with a foreign object is managed in some other way--e.g., ‘malloc’'d memory or file descriptors--it is possible to specify a “finalizer” function to release those resources when the foreign object is reclaimed. As discussed in *note Garbage Collection::, Guile's garbage collector will reclaim inaccessible memory as needed. This reclamation process runs concurrently with the main program. When Guile analyzes the heap and determines that an object's memory can be reclaimed, that memory is put on a "free list" of objects that can be reclaimed. Usually that's the end of it--the object is available for immediate re-use. However some objects can have "finalizers" associated with them--functions that are called on reclaimable objects to effect any external cleanup actions. Finalizers are tricky business and it is best to avoid them. They can be invoked at unexpected times, or not at all--for example, they are not invoked on process exit. They don't help the garbage collector do its job; in fact, they are a hindrance. Furthermore, they perturb the garbage collector's internal accounting. The GC decides to scan the heap when it thinks that it is necessary, after some amount of allocation. Finalizable objects almost always represent an amount of allocation that is invisible to the garbage collector. The effect can be that the actual resource usage of a system with finalizable objects is higher than what the GC thinks it should be. All those caveats aside, some foreign object types will need finalizers. For example, if we had a foreign object type that wrapped file descriptors--and we aren't suggesting this, as Guile already has ports --then you might define the type like this: static SCM file_type; static void finalize_file (SCM file) { int fd = scm_foreign_object_signed_ref (file, 0); if (fd >= 0) { scm_foreign_object_signed_set_x (file, 0, -1); close (fd); } } static void init_file_type (void) { SCM name, slots; scm_t_struct_finalize finalizer; name = scm_from_utf8_symbol ("file"); slots = scm_list_1 (scm_from_utf8_symbol ("fd")); finalizer = finalize_file; image_type = scm_make_foreign_object_type (name, slots, finalizer); } static SCM make_file (int fd) { return scm_make_foreign_object_1 (file_type, (void *) fd); } Note that the finalizer may be invoked in ways and at times you might not expect. In a Guile built without threading support, finalizers are invoked via "asyncs", which interleaves them with running Scheme code; *note Asyncs::. If the user's Guile is built with support for threads, the finalizer will probably be called by a dedicated finalization thread, unless the user invokes ‘scm_run_finalizers ()’ explicitly. In either case, finalizers run concurrently with the main program, and so they need to be async-safe and thread-safe. If for some reason this is impossible, perhaps because you are embedding Guile in some application that is not itself thread-safe, you have a few options. One is to use guardians instead of finalizers, and arrange to pump the guardians for finalizable objects. *Note Guardians::, for more information. The other option is to disable automatic finalization entirely, and arrange to call ‘scm_run_finalizers ()’ at appropriate points. *Note Foreign Objects::, for more on these interfaces. Finalizers are allowed to allocate memory, access GC-managed memory, and in general can do anything any Guile user code can do. This was not the case in Guile 1.8, where finalizers were much more restricted. In particular, in Guile 2.0, finalizers can resuscitate objects. We do not recommend that users avail themselves of this possibility, however, as a resuscitated object can re-expose other finalizable objects that have been already finalized back to Scheme. These objects will not be finalized again, but they could cause use-after-free problems to code that handles objects of that particular foreign object type. To guard against this possibility, robust finalization routines should clear state from the foreign object, as in the above ‘free_file’ example. One final caveat. Foreign object finalizers are associated with the lifetime of a foreign object, not of its fields. If you access a field of a finalizable foreign object, and do not arrange to keep a reference on the foreign object itself, it could be that the outer foreign object gets finalized while you are working with its field. For example, consider a procedure to read some data from a file, from our example above. SCM read_bytes (SCM file, SCM n) { int fd; SCM buf; size_t len, pos; scm_assert_foreign_object_type (file_type, file); fd = scm_foreign_object_signed_ref (file, 0); if (fd < 0) scm_wrong_type_arg_msg ("read-bytes", SCM_ARG1, file, "open file"); len = scm_to_size_t (n); SCM buf = scm_c_make_bytevector (scm_to_size_t (n)); pos = 0; while (pos < len) { char *bytes = SCM_BYTEVECTOR_CONTENTS (buf); ssize_t count = read (fd, bytes + pos, len - pos); if (count < 0) scm_syserror ("read-bytes"); if (count == 0) break; pos += count; } scm_remember_upto_here_1 (file); return scm_values (scm_list_2 (buf, scm_from_size_t (pos))); } After the prelude, only the ‘fd’ value is used and the C compiler has no reason to keep the ‘file’ object around. If ‘scm_c_make_bytevector’ results in a garbage collection, ‘file’ might not be on the stack or anywhere else and could be finalized, leaving ‘read’ to read a closed (or, in a multi-threaded program, possibly re-used) file descriptor. The use of ‘scm_remember_upto_here_1’ prevents this, by creating a reference to ‘file’ after all data accesses. *Note Garbage Collection Functions::. ‘scm_remember_upto_here_1’ is only needed on finalizable objects, because garbage collection of other values is invisible to the program - it happens when needed, and is not observable. But if you can, save yourself the headache and build your program in such a way that it doesn't need finalization. 5.5.5 Foreign Objects and Scheme -------------------------------- It is also possible to create foreign objects and object types from Scheme, and to access fields of foreign objects from Scheme. For example, the file example from the last section could be equivalently expressed as: (define-module (my-file) #:use-module (system foreign-object) #:use-module ((oop goops) #:select (make)) #:export (make-file)) (define (finalize-file file) (let ((fd (struct-ref file 0))) (unless (< fd 0) (struct-set! file 0 -1) (close-fdes fd)))) (define (make-foreign-object-type ' '(fd) #:finalizer finalize-file)) (define (make-file fd) (make #:fd fd)) Here we see that the result of ‘make-foreign-object-type’, which is the equivalent of ‘scm_make_foreign_object_type’, is a struct vtable. *Note Vtables::, for more information. To instantiate the foreign object, which is really a Guile struct, we use ‘make’. (We could have used ‘make-struct/no-tail’, but as an implementation detail, finalizers are attached in the ‘initialize’ method called by ‘make’). To access the fields, we use ‘struct-ref’ and ‘struct-set!’. *Note Structure Basics::. There is a convenience syntax, ‘define-foreign-object-type’, that defines a type along with a constructor, and getters for the fields. An appropriate invocation of ‘define-foreign-object-type’ for the file object type could look like this: (use-modules (system foreign-object)) (define-foreign-object-type make-file (fd) #:finalizer finalize-file) This defines the ‘’ type with one field, a ‘make-file’ constructor, and a getter for the ‘fd’ field, bound to ‘fd’. Foreign object types are not only vtables but are actually GOOPS classes, as hinted at above. *Note GOOPS::, for more on Guile's object-oriented programming system. Thus one can define print and equality methods using GOOPS: (use-modules (oop goops)) (define-method (write (file ) port) ;; Assuming existence of the `fd' getter (format port "#< ~a>" (fd file))) (define-method (equal? (a ) (b )) (eqv? (fd a) (fd b))) One can even sub-class foreign types. (define-class () (name #:init-keyword #:name #:init-value #f #:accessor name)) The question arises of how to construct these values, given that ‘make-file’ returns a plain old ‘’ object. It turns out that you can use the GOOPS construction interface, where every field of the foreign object has an associated initialization keyword argument. (define* (my-open-file name #:optional (flags O_RDONLY)) (make #:fd (open-fdes name flags) #:name name)) (define-method (write (file ) port) (format port "#< ~s ~a>" (name file) (fd file))) *Note Foreign Objects::, for full documentation on the Scheme interface to foreign objects. *Note GOOPS::, for more on GOOPS. As a final note, you might wonder how this system supports encapsulation of sensitive values. First, we have to recognize that some facilities are essentially unsafe and have global scope. For example, in C, the integrity and confidentiality of a part of a program is at the mercy of every other part of that program - because any part of the program can read and write anything in its address space. At the same time, principled access to structured data is organized in C on lexical boundaries; if you don't expose accessors for your object, you trust other parts of the program not to work around that barrier. The situation is not dissimilar in Scheme. Although Scheme's unsafe constructs are fewer in number than in C, they do exist. The ‘(system foreign)’ module can be used to violate confidentiality and integrity, and shouldn't be exposed to untrusted code. Although ‘struct-ref’ and ‘struct-set!’ are less unsafe, they still have a cross-cutting capability of drilling through abstractions. Performing a ‘struct-set!’ on a foreign object slot could cause unsafe foreign code to crash. Ultimately, structures in Scheme are capabilities for abstraction, and not abstractions themselves. That leaves us with the lexical capabilities, like constructors and accessors. Here is where encapsulation lies: the practical degree to which the innards of your foreign objects are exposed is the degree to which their accessors are lexically available in user code. If you want to allow users to reference fields of your foreign object, provide them with a getter. Otherwise you should assume that the only access to your object may come from your code, which has the relevant authority, or via code with access to cross-cutting ‘struct-ref’ and such, which also has the cross-cutting authority. 5.6 Function Snarfing ===================== When writing C code for use with Guile, you typically define a set of C functions, and then make some of them visible to the Scheme world by calling ‘scm_c_define_gsubr’ or related functions. If you have many functions to publish, it can sometimes be annoying to keep the list of calls to ‘scm_c_define_gsubr’ in sync with the list of function definitions. Guile provides the ‘guile-snarf’ program to manage this problem. Using this tool, you can keep all the information needed to define the function alongside the function definition itself; ‘guile-snarf’ will extract this information from your source code, and automatically generate a file of calls to ‘scm_c_define_gsubr’ which you can ‘#include’ into an initialization function. The snarfing mechanism works for many kind of initialization actions, not just for collecting calls to ‘scm_c_define_gsubr’. For a full list of what can be done, *Note Snarfing Macros::. The ‘guile-snarf’ program is invoked like this: guile-snarf [-o OUTFILE] [CPP-ARGS ...] This command will extract initialization actions to OUTFILE. When no OUTFILE has been specified or when OUTFILE is ‘-’, standard output will be used. The C preprocessor is called with CPP-ARGS (which usually include an input file) and the output is filtered to extract the initialization actions. If there are errors during processing, OUTFILE is deleted and the program exits with non-zero status. During snarfing, the pre-processor macro ‘SCM_MAGIC_SNARFER’ is defined. You could use this to avoid including snarfer output files that don't yet exist by writing code like this: #ifndef SCM_MAGIC_SNARFER #include "foo.x" #endif Here is how you might define the Scheme function ‘clear-image’, implemented by the C function ‘clear_image’: #include SCM_DEFINE (clear_image, "clear-image", 1, 0, 0, (SCM image), "Clear the image.") { /* C code to clear the image in image... */ } void init_image_type () { #include "image-type.x" } The ‘SCM_DEFINE’ declaration says that the C function ‘clear_image’ implements a Scheme function called ‘clear-image’, which takes one required argument (of type ‘SCM’ and named ‘image’), no optional arguments, and no rest argument. The string ‘"Clear the image."’ provides a short help text for the function, it is called a “docstring”. ‘SCM_DEFINE’ macro also defines a static array of characters initialized to the Scheme name of the function. In this case, ‘s_clear_image’ is set to the C string, "clear-image". You might want to use this symbol when generating error messages. Assuming the text above lives in a file named ‘image-type.c’, you will need to execute the following command to prepare this file for compilation: guile-snarf -o image-type.x image-type.c This scans ‘image-type.c’ for ‘SCM_DEFINE’ declarations, and writes to ‘image-type.x’ the output: scm_c_define_gsubr ("clear-image", 1, 0, 0, (SCM (*)() ) clear_image); When compiled normally, ‘SCM_DEFINE’ is a macro which expands to the function header for ‘clear_image’. Note that the output file name matches the ‘#include’ from the input file. Also, you still need to provide all the same information you would if you were using ‘scm_c_define_gsubr’ yourself, but you can place the information near the function definition itself, so it is less likely to become incorrect or out-of-date. If you have many files that ‘guile-snarf’ must process, you should consider using a fragment like the following in your Makefile: snarfcppopts = $(DEFS) $(INCLUDES) $(CPPFLAGS) $(CFLAGS) .SUFFIXES: .x .c.x: guile-snarf -o $@ $< $(snarfcppopts) This tells make to run ‘guile-snarf’ to produce each needed ‘.x’ file from the corresponding ‘.c’ file. The program ‘guile-snarf’ passes its command-line arguments directly to the C preprocessor, which it uses to extract the information it needs from the source code. this means you can pass normal compilation flags to ‘guile-snarf’ to define preprocessor symbols, add header file directories, and so on. 5.7 An Overview of Guile Programming ==================================== Guile is designed as an extension language interpreter that is straightforward to integrate with applications written in C (and C++). The big win here for the application developer is that Guile integration, as the Guile web page says, "lowers your project's hacktivation energy." Lowering the hacktivation energy means that you, as the application developer, _and your users_, reap the benefits that flow from being able to extend the application in a high level extension language rather than in plain old C. In abstract terms, it's difficult to explain what this really means and what the integration process involves, so instead let's begin by jumping straight into an example of how you might integrate Guile into an existing program, and what you could expect to gain by so doing. With that example under our belts, we'll then return to a more general analysis of the arguments involved and the range of programming options available. 5.7.1 How One Might Extend Dia Using Guile ------------------------------------------ Dia is a free software program for drawing schematic diagrams like flow charts and floor plans (). This section conducts the thought experiment of adding Guile to Dia. In so doing, it aims to illustrate several of the steps and considerations involved in adding Guile to applications in general. 5.7.1.1 Deciding Why You Want to Add Guile .......................................... First off, you should understand why you want to add Guile to Dia at all, and that means forming a picture of what Dia does and how it does it. So, what are the constituents of the Dia application? • Most importantly, the “application domain objects” -- in other words, the concepts that differentiate Dia from another application such as a word processor or spreadsheet: shapes, templates, connectors, pages, plus the properties of all these things. • The code that manages the graphical face of the application, including the layout and display of the objects above. • The code that handles input events, which indicate that the application user is wanting to do something. (In other words, a textbook example of the “model - view - controller” paradigm.) Next question: how will Dia benefit once the Guile integration is complete? Several (positive!) answers are possible here, and the choice is obviously up to the application developers. Still, one answer is that the main benefit will be the ability to manipulate Dia's application domain objects from Scheme. Suppose that Dia made a set of procedures available in Scheme, representing the most basic operations on objects such as shapes, connectors, and so on. Using Scheme, the application user could then write code that builds upon these basic operations to create more complex procedures. For example, given basic procedures to enumerate the objects on a page, to determine whether an object is a square, and to change the fill pattern of a single shape, the user can write a Scheme procedure to change the fill pattern of all squares on the current page: (define (change-squares'-fill-pattern new-pattern) (for-each-shape current-page (lambda (shape) (if (square? shape) (change-fill-pattern shape new-pattern))))) 5.7.1.2 Four Steps Required to Add Guile ........................................ Assuming this objective, four steps are needed to achieve it. First, you need a way of representing your application-specific objects -- such as ‘shape’ in the previous example -- when they are passed into the Scheme world. Unless your objects are so simple that they map naturally into builtin Scheme data types like numbers and strings, you will probably want to use Guile's “foreign object” interface to create a new Scheme data type for your objects. Second, you need to write code for the basic operations like ‘for-each-shape’ and ‘square?’ such that they access and manipulate your existing data structures correctly, and then make these operations available as “primitives” on the Scheme level. Third, you need to provide some mechanism within the Dia application that a user can hook into to cause arbitrary Scheme code to be evaluated. Finally, you need to restructure your top-level application C code a little so that it initializes the Guile interpreter correctly and declares your “foreign objects” and “primitives” to the Scheme world. The following subsections expand on these four points in turn. 5.7.1.3 How to Represent Dia Data in Scheme ........................................... For all but the most trivial applications, you will probably want to allow some representation of your domain objects to exist on the Scheme level. This is where foreign objects come in, and with them issues of lifetime management and garbage collection. To get more concrete about this, let's look again at the example we gave earlier of how application users can use Guile to build higher-level functions from the primitives that Dia itself provides. (define (change-squares'-fill-pattern new-pattern) (for-each-shape current-page (lambda (shape) (if (square? shape) (change-fill-pattern shape new-pattern))))) Consider what is stored here in the variable ‘shape’. For each shape on the current page, the ‘for-each-shape’ primitive calls ‘(lambda (shape) ...)’ with an argument representing that shape. Question is: how is that argument represented on the Scheme level? The issues are as follows. • Whatever the representation, it has to be decodable again by the C code for the ‘square?’ and ‘change-fill-pattern’ primitives. In other words, a primitive like ‘square?’ has somehow to be able to turn the value that it receives back into something that points to the underlying C structure describing a shape. • The representation must also cope with Scheme code holding on to the value for later use. What happens if the Scheme code stores ‘shape’ in a global variable, but then that shape is deleted (in a way that the Scheme code is not aware of), and later on some other Scheme code uses that global variable again in a call to, say, ‘square?’? • The lifetime and memory allocation of objects that exist _only_ in the Scheme world is managed automatically by Guile's garbage collector using one simple rule: when there are no remaining references to an object, the object is considered dead and so its memory is freed. But for objects that exist in both C and Scheme, the picture is more complicated; in the case of Dia, where the ‘shape’ argument passes transiently in and out of the Scheme world, it would be quite wrong the *delete* the underlying C shape just because the Scheme code has finished evaluation. How do we avoid this happening? One resolution of these issues is for the Scheme-level representation of a shape to be a new, Scheme-specific C structure wrapped up as a foreign object. The foreign object is what is passed into and out of Scheme code, and the Scheme-specific C structure inside the foreign object points to Dia's underlying C structure so that the code for primitives like ‘square?’ can get at it. To cope with an underlying shape being deleted while Scheme code is still holding onto a Scheme shape value, the underlying C structure should have a new field that points to the Scheme-specific foreign object. When a shape is deleted, the relevant code chains through to the Scheme-specific structure and sets its pointer back to the underlying structure to NULL. Thus the foreign object value for the shape continues to exist, but any primitive code that tries to use it will detect that the underlying shape has been deleted because the underlying structure pointer is NULL. So, to summarize the steps involved in this resolution of the problem (and assuming that the underlying C structure for a shape is ‘struct dia_shape’): • Define a new Scheme-specific structure that _points_ to the underlying C structure: struct dia_guile_shape { struct dia_shape * c_shape; /* NULL => deleted */ } • Add a field to ‘struct dia_shape’ that points to its ‘struct dia_guile_shape’ if it has one -- struct dia_shape { ... struct dia_guile_shape * guile_shape; } -- so that C code can set ‘guile_shape->c_shape’ to NULL when the underlying shape is deleted. • Wrap ‘struct dia_guile_shape’ as a foreign object type. • Whenever you need to represent a C shape onto the Scheme level, create a foreign object instance for it, and pass that. • In primitive code that receives a shape foreign object instance, check the ‘c_shape’ field when decoding it, to find out whether the underlying C shape is still there. As far as memory management is concerned, the foreign object values and their Scheme-specific structures are under the control of the garbage collector, whereas the underlying C structures are explicitly managed in exactly the same way that Dia managed them before we thought of adding Guile. When the garbage collector decides to free a shape foreign object value, it calls the “finalizer” function that was specified when defining the shape foreign object type. To maintain the correctness of the ‘guile_shape’ field in the underlying C structure, this function should chain through to the underlying C structure (if it still exists) and set its ‘guile_shape’ field to NULL. For full documentation on defining and using foreign object types, see *note Defining New Foreign Object Types::. 5.7.1.4 Writing Guile Primitives for Dia ........................................ Once the details of object representation are decided, writing the primitive function code that you need is usually straightforward. A primitive is simply a C function whose arguments and return value are all of type ‘SCM’, and whose body does whatever you want it to do. As an example, here is a possible implementation of the ‘square?’ primitive: static SCM square_p (SCM shape) { struct dia_guile_shape * guile_shape; /* Check that arg is really a shape object. */ scm_assert_foreign_object_type (shape_type, shape); /* Access Scheme-specific shape structure. */ guile_shape = scm_foreign_object_ref (shape, 0); /* Find out if underlying shape exists and is a square; return answer as a Scheme boolean. */ return scm_from_bool (guile_shape->c_shape && (guile_shape->c_shape->type == DIA_SQUARE)); } Notice how easy it is to chain through from the ‘SCM shape’ parameter that ‘square_p’ receives -- which is a foreign object -- to the Scheme-specific structure inside the foreign object, and thence to the underlying C structure for the shape. In this code, ‘scm_assert_foreign_object_type’, ‘scm_foreign_object_ref’, and ‘scm_from_bool’ are from the standard Guile API. We assume that ‘shape_type’ was given to us when we made the shape foreign object type, using ‘scm_make_foreign_object_type’. The call to ‘scm_assert_foreign_object_type’ ensures that SHAPE is indeed a shape. This is needed to guard against Scheme code using the ‘square?’ procedure incorrectly, as in ‘(square? "hello")’; Scheme's latent typing means that usage errors like this must be caught at run time. Having written the C code for your primitives, you need to make them available as Scheme procedures by calling the ‘scm_c_define_gsubr’ function. ‘scm_c_define_gsubr’ (*note Primitive Procedures::) takes arguments that specify the Scheme-level name for the primitive and how many required, optional and rest arguments it can accept. The ‘square?’ primitive always requires exactly one argument, so the call to make it available in Scheme reads like this: scm_c_define_gsubr ("square?", 1, 0, 0, square_p); For where to put this call, see the subsection after next on the structure of Guile-enabled code (*note Dia Structure::). 5.7.1.5 Providing a Hook for the Evaluation of Scheme Code .......................................................... To make the Guile integration useful, you have to design some kind of hook into your application that application users can use to cause their Scheme code to be evaluated. Technically, this is straightforward; you just have to decide on a mechanism that is appropriate for your application. Think of Emacs, for example: when you type ‘ :’, you get a prompt where you can type in any Elisp code, which Emacs will then evaluate. Or, again like Emacs, you could provide a mechanism (such as an init file) to allow Scheme code to be associated with a particular key sequence, and evaluate the code when that key sequence is entered. In either case, once you have the Scheme code that you want to evaluate, as a null terminated string, you can tell Guile to evaluate it by calling the ‘scm_c_eval_string’ function. 5.7.1.6 Top-level Structure of Guile-enabled Dia ................................................ Let's assume that the pre-Guile Dia code looks structurally like this: • ‘main ()’ • do lots of initialization and setup stuff • enter Gtk main loop When you add Guile to a program, one (rather technical) requirement is that Guile's garbage collector needs to know where the bottom of the C stack is. The easiest way to ensure this is to use ‘scm_boot_guile’ like this: • ‘main ()’ • do lots of initialization and setup stuff • ‘scm_boot_guile (argc, argv, inner_main, NULL)’ • ‘inner_main ()’ • define all foreign object types • export primitives to Scheme using ‘scm_c_define_gsubr’ • enter Gtk main loop In other words, you move the guts of what was previously in your ‘main’ function into a new function called ‘inner_main’, and then add a ‘scm_boot_guile’ call, with ‘inner_main’ as a parameter, to the end of ‘main’. Assuming that you are using foreign objects and have written primitive code as described in the preceding subsections, you also need to insert calls to declare your new foreign objects and export the primitives to Scheme. These declarations must happen _inside_ the dynamic scope of the ‘scm_boot_guile’ call, but also _before_ any code is run that could possibly use them -- the beginning of ‘inner_main’ is an ideal place for this. 5.7.1.7 Going Further with Dia and Guile ........................................ The steps described so far implement an initial Guile integration that already gives a lot of additional power to Dia application users. But there are further steps that you could take, and it's interesting to consider a few of these. In general, you could progressively move more of Dia's source code from C into Scheme. This might make the code more maintainable and extensible, and it could open the door to new programming paradigms that are tricky to effect in C but straightforward in Scheme. A specific example of this is that you could use the guile-gtk package, which provides Scheme-level procedures for most of the Gtk+ library, to move the code that lays out and displays Dia objects from C to Scheme. As you follow this path, it naturally becomes less useful to maintain a distinction between Dia's original non-Guile-related source code, and its later code implementing foreign objects and primitives for the Scheme world. For example, suppose that the original source code had a ‘dia_change_fill_pattern’ function: void dia_change_fill_pattern (struct dia_shape * shape, struct dia_pattern * pattern) { /* real pattern change work */ } During initial Guile integration, you add a ‘change_fill_pattern’ primitive for Scheme purposes, which accesses the underlying structures from its foreign object values and uses ‘dia_change_fill_pattern’ to do the real work: SCM change_fill_pattern (SCM shape, SCM pattern) { struct dia_shape * d_shape; struct dia_pattern * d_pattern; ... dia_change_fill_pattern (d_shape, d_pattern); return SCM_UNSPECIFIED; } At this point, it makes sense to keep ‘dia_change_fill_pattern’ and ‘change_fill_pattern’ separate, because ‘dia_change_fill_pattern’ can also be called without going through Scheme at all, say because the user clicks a button which causes a C-registered Gtk+ callback to be called. But, if the code for creating buttons and registering their callbacks is moved into Scheme (using guile-gtk), it may become true that ‘dia_change_fill_pattern’ can no longer be called other than through Scheme. In which case, it makes sense to abolish it and move its contents directly into ‘change_fill_pattern’, like this: SCM change_fill_pattern (SCM shape, SCM pattern) { struct dia_shape * d_shape; struct dia_pattern * d_pattern; ... /* real pattern change work */ return SCM_UNSPECIFIED; } So further Guile integration progressively _reduces_ the amount of functional C code that you have to maintain over the long term. A similar argument applies to data representation. In the discussion of foreign objects earlier, issues arose because of the different memory management and lifetime models that normally apply to data structures in C and in Scheme. However, with further Guile integration, you can resolve this issue in a more radical way by allowing all your data structures to be under the control of the garbage collector, and kept alive by references from the Scheme world. Instead of maintaining an array or linked list of shapes in C, you would instead maintain a list in Scheme. Rather like the coalescing of ‘dia_change_fill_pattern’ and ‘change_fill_pattern’, the practical upshot of such a change is that you would no longer have to keep the ‘dia_shape’ and ‘dia_guile_shape’ structures separate, and so wouldn't need to worry about the pointers between them. Instead, you could change the foreign object definition to wrap the ‘dia_shape’ structure directly, and send ‘dia_guile_shape’ off to the scrap yard. Cut out the middle man! Finally, we come to the holy grail of Guile's free software / extension language approach. Once you have a Scheme representation for interesting Dia data types like shapes, and a handy bunch of primitives for manipulating them, it suddenly becomes clear that you have a bundle of functionality that could have far-ranging use beyond Dia itself. In other words, the data types and primitives could now become a library, and Dia becomes just one of the many possible applications using that library -- albeit, at this early stage, a rather important one! In this model, Guile becomes just the glue that binds everything together. Imagine an application that usefully combined functionality from Dia, Gnumeric and GnuCash -- it's tricky right now, because no such application yet exists; but it'll happen some day ... 5.7.2 Why Scheme is More Hackable Than C ---------------------------------------- Underlying Guile's value proposition is the assumption that programming in a high level language, specifically Guile's implementation of Scheme, is necessarily better in some way than programming in C. What do we mean by this claim, and how can we be so sure? One class of advantages applies not only to Scheme, but more generally to any interpretable, high level, scripting language, such as Emacs Lisp, Python, Ruby, or TeX's macro language. Common features of all such languages, when compared to C, are that: • They lend themselves to rapid and experimental development cycles, owing usually to a combination of their interpretability and the integrated development environment in which they are used. • They free developers from some of the low level bookkeeping tasks associated with C programming, notably memory management. • They provide high level features such as container objects and exception handling that make common programming tasks easier. In the case of Scheme, particular features that make programming easier -- and more fun! -- are its powerful mechanisms for abstracting parts of programs (closures -- *note About Closure::) and for iteration (*note while do::). The evidence in support of this argument is empirical: the huge amount of code that has been written in extension languages for applications that support this mechanism. Most notable are extensions written in Emacs Lisp for GNU Emacs, in TeX's macro language for TeX, and in Script-Fu for the Gimp, but there is increasingly now a significant code eco-system for Guile-based applications as well, such as Lilypond and GnuCash. It is close to inconceivable that similar amounts of functionality could have been added to these applications just by writing new code in their base implementation languages. 5.7.3 Example: Using Guile for an Application Testbed ----------------------------------------------------- As an example of what this means in practice, imagine writing a testbed for an application that is tested by submitting various requests (via a C interface) and validating the output received. Suppose further that the application keeps an idea of its current state, and that the "correct" output for a given request may depend on the current application state. A complete "white box"(1) test plan for this application would aim to submit all possible requests in each distinguishable state, and validate the output for all request/state combinations. To write all this test code in C would be very tedious. Suppose instead that the testbed code adds a single new C function, to submit an arbitrary request and return the response, and then uses Guile to export this function as a Scheme procedure. The rest of the testbed can then be written in Scheme, and so benefits from all the advantages of programming in Scheme that were described in the previous section. (In this particular example, there is an additional benefit of writing most of the testbed in Scheme. A common problem for white box testing is that mistakes and mistaken assumptions in the application under test can easily be reproduced in the testbed code. It is more difficult to copy mistakes like this when the testbed is written in a different language from the application.) ---------- Footnotes ---------- (1) A “white box” test plan is one that incorporates knowledge of the internal design of the application under test. 5.7.4 A Choice of Programming Options ------------------------------------- The preceding arguments and example point to a model of Guile programming that is applicable in many cases. According to this model, Guile programming involves a balance between C and Scheme programming, with the aim being to extract the greatest possible Scheme level benefit from the least amount of C level work. The C level work required in this model usually consists of packaging and exporting functions and application objects such that they can be seen and manipulated on the Scheme level. To help with this, Guile's C language interface includes utility features that aim to make this kind of integration very easy for the application developer. This model, though, is really just one of a range of possible programming options. If all of the functionality that you need is available from Scheme, you could choose instead to write your whole application in Scheme (or one of the other high level languages that Guile supports through translation), and simply use Guile as an interpreter for Scheme. (In the future, we hope that Guile will also be able to compile Scheme code, so lessening the performance gap between C and Scheme code.) Or, at the other end of the C-Scheme scale, you could write the majority of your application in C, and only call out to Guile occasionally for specific actions such as reading a configuration file or executing a user-specified extension. The choices boil down to two basic questions: • Which parts of the application do you write in C, and which in Scheme (or another high level translated language)? • How do you design the interface between the C and Scheme parts of your application? These are of course design questions, and the right design for any given application will always depend upon the particular requirements that you are trying to meet. In the context of Guile, however, there are some generally applicable considerations that can help you when designing your answers. 5.7.4.1 What Functionality is Already Available? ................................................ Suppose, for the sake of argument, that you would prefer to write your whole application in Scheme. Then the API available to you consists of: • standard Scheme • plus the extensions to standard Scheme provided by Guile in its core distribution • plus any additional functionality that you or others have packaged so that it can be loaded as a Guile Scheme module. A module in the last category can either be a pure Scheme module -- in other words a collection of utility procedures coded in Scheme -- or a module that provides a Scheme interface to an extension library coded in C -- in other words a nice package where someone else has done the work of wrapping up some useful C code for you. The set of available modules is growing quickly and already includes such useful examples as ‘(gtk gtk)’, which makes Gtk+ drawing functions available in Scheme, and ‘(database postgres)’, which provides SQL access to a Postgres database. Given the growing collection of pre-existing modules, it is quite feasible that your application could be implemented by combining a selection of these modules together with new application code written in Scheme. If this approach is not enough, because the functionality that your application needs is not already available in this form, and it is impossible to write the new functionality in Scheme, you will need to write some C code. If the required function is already available in C (e.g. in a library), all you need is a little glue to connect it to the world of Guile. If not, you need both to write the basic code and to plumb it into Guile. In either case, two general considerations are important. Firstly, what is the interface by which the functionality is presented to the Scheme world? Does the interface consist only of function calls (for example, a simple drawing interface), or does it need to include “objects” of some kind that can be passed between C and Scheme and manipulated by both worlds. Secondly, how does the lifetime and memory management of objects in the C code relate to the garbage collection governed approach of Scheme objects? In the case where the basic C code is not already written, most of the difficulties of memory management can be avoided by using Guile's C interface features from the start. For the full documentation on writing C code for Guile and connecting existing C code to the Guile world, see *note Defining New Foreign Object Types::, *note Primitive Procedures::, and *note Foreign Function Interface::. 5.7.4.2 Functional and Performance Constraints .............................................. 5.7.4.3 Your Preferred Programming Style ........................................ 5.7.4.4 What Controls Program Execution? ........................................ 5.7.5 How About Application Users? ---------------------------------- So far we have considered what Guile programming means for an application developer. But what if you are instead _using_ an existing Guile-based application, and want to know what your options are for programming and extending this application? The answer to this question varies from one application to another, because the options available depend inevitably on whether the application developer has provided any hooks for you to hang your own code on and, if there are such hooks, what they allow you to do.(1) For example... • If the application permits you to load and execute any Guile code, the world is your oyster. You can extend the application in any way that you choose. • A more cautious application might allow you to load and execute Guile code, but only in a “safe” environment, where the interface available is restricted by the application from the standard Guile API. • Or a really fearful application might not provide a hook to really execute user code at all, but just use Scheme syntax as a convenient way for users to specify application data or configuration options. In the last two cases, what you can do is, by definition, restricted by the application, and you should refer to the application's own manual to find out your options. The most well known example of the first case is Emacs, with its extension language Emacs Lisp: as well as being a text editor, Emacs supports the loading and execution of arbitrary Emacs Lisp code. The result of such openness has been dramatic: Emacs now benefits from user-contributed Emacs Lisp libraries that extend the basic editing function to do everything from reading news to psychoanalysis and playing adventure games. The only limitation is that extensions are restricted to the functionality provided by Emacs's built-in set of primitive operations. For example, you can interact and display data by manipulating the contents of an Emacs buffer, but you can't pop-up and draw a window with a layout that is totally different to the Emacs standard. This situation with a Guile application that supports the loading of arbitrary user code is similar, except perhaps even more so, because Guile also supports the loading of extension libraries written in C. This last point enables user code to add new primitive operations to Guile, and so to bypass the limitation present in Emacs Lisp. At this point, the distinction between an application developer and an application user becomes rather blurred. Instead of seeing yourself as a user extending an application, you could equally well say that you are developing a new application of your own using some of the primitive functionality provided by the original application. As such, all the discussions of the preceding sections of this chapter are relevant to how you can proceed with developing your extension. ---------- Footnotes ---------- (1) Of course, in the world of free software, you always have the freedom to modify the application's source code to your own requirements. Here we are concerned with the extension options that the application has provided for without your needing to modify its source code. 5.8 Autoconf Support ==================== Autoconf, a part of the GNU build system, makes it easy for users to build your package. This section documents Guile's Autoconf support. 5.8.1 Autoconf Background ------------------------- As explained in the ‘GNU Autoconf Manual’, any package needs configuration at build-time (*note Introduction: (autoconf)Top.). If your package uses Guile (or uses a package that in turn uses Guile), you probably need to know what specific Guile features are available and details about them. The way to do this is to write feature tests and arrange for their execution by the ‘configure’ script, typically by adding the tests to ‘configure.ac’, and running ‘autoconf’ to create ‘configure’. Users of your package then run ‘configure’ in the normal way. Macros are a way to make common feature tests easy to express. Autoconf provides a wide range of macros (*note (autoconf)Existing Tests::), and Guile installation provides Guile-specific tests in the areas of: program detection, compilation flags reporting, and Scheme module checks. 5.8.2 Autoconf Macros --------------------- As mentioned earlier in this chapter, Guile supports parallel installation, and uses ‘pkg-config’ to let the user choose which version of Guile they are interested in. ‘pkg-config’ has its own set of Autoconf macros that are probably installed on most every development system. The most useful of these macros is ‘PKG_CHECK_MODULES’. PKG_CHECK_MODULES([GUILE], [guile-3.0]) This example looks for Guile and sets the ‘GUILE_CFLAGS’ and ‘GUILE_LIBS’ variables accordingly, or prints an error and exits if Guile was not found. Guile comes with additional Autoconf macros providing more information, installed as ‘PREFIX/share/aclocal/guile.m4’. Their names all begin with ‘GUILE_’. -- Autoconf Macro: GUILE_PKG [VERSIONS] This macro runs the ‘pkg-config’ tool to find development files for an available version of Guile. By default, this macro will search for the latest stable version of Guile (e.g. 3.0), falling back to the previous stable version (e.g. 2.2) if it is available. If no guile-VERSION.pc file is found, an error is signaled. The found version is stored in GUILE_EFFECTIVE_VERSION. If ‘GUILE_PROGS’ was already invoked, this macro ensures that the development files have the same effective version as the Guile program. GUILE_EFFECTIVE_VERSION is marked for substitution, as by ‘AC_SUBST’. -- Autoconf Macro: GUILE_FLAGS This macro runs the ‘pkg-config’ tool to find out how to compile and link programs against Guile. It sets four variables: GUILE_CFLAGS, GUILE_LDFLAGS, GUILE_LIBS, and GUILE_LTLIBS. GUILE_CFLAGS: flags to pass to a C or C++ compiler to build code that uses Guile header files. This is almost always just one or more ‘-I’ flags. GUILE_LDFLAGS: flags to pass to the compiler to link a program against Guile. This includes ‘-lguile-VERSION’ for the Guile library itself, and may also include one or more ‘-L’ flag to tell the compiler where to find the libraries. But it does not include flags that influence the program's runtime search path for libraries, and will therefore lead to a program that fails to start, unless all necessary libraries are installed in a standard location such as ‘/usr/lib’. GUILE_LIBS and GUILE_LTLIBS: flags to pass to the compiler or to libtool, respectively, to link a program against Guile. It includes flags that augment the program's runtime search path for libraries, so that shared libraries will be found at the location where they were during linking, even in non-standard locations. GUILE_LIBS is to be used when linking the program directly with the compiler, whereas GUILE_LTLIBS is to be used when linking the program is done through libtool. The variables are marked for substitution, as by ‘AC_SUBST’. -- Autoconf Macro: GUILE_SITE_DIR This looks for Guile's "site" directories. The variable GUILE_SITE will be set to Guile's "site" directory for Scheme source files (usually something like PREFIX/share/guile/site). GUILE_SITE_CCACHE will be set to the directory for compiled Scheme files also known as ‘.go’ files (usually something like PREFIX/lib/guile/GUILE_EFFECTIVE_VERSION/site-ccache). GUILE_EXTENSION will be set to the directory for compiled C extensions (usually something like PREFIX/lib/guile/GUILE_EFFECTIVE_VERSION/extensions). The latter two are set to blank if the particular version of Guile does not support them. Note that this macro will run the macros ‘GUILE_PKG’ and ‘GUILE_PROGS’ if they have not already been run. The variables are marked for substitution, as by ‘AC_SUBST’. -- Autoconf Macro: GUILE_PROGS [VERSION] This macro looks for programs ‘guile’ and ‘guild’, setting variables GUILE and GUILD to their paths, respectively. The macro will attempt to find ‘guile’ with the suffix of ‘-X.Y’, followed by looking for it with the suffix ‘X.Y’, and then fall back to looking for ‘guile’ with no suffix. If ‘guile’ is still not found, signal an error. The suffix, if any, that was required to find ‘guile’ will be used for ‘guild’ as well. By default, this macro will search for the latest stable version of Guile (e.g. 3.0). x.y or x.y.z versions can be specified. If an older version is found, the macro will signal an error. The effective version of the found ‘guile’ is set to GUILE_EFFECTIVE_VERSION. This macro ensures that the effective version is compatible with the result of a previous invocation of ‘GUILE_FLAGS’, if any. As a legacy interface, it also looks for ‘guile-config’ and ‘guile-tools’, setting GUILE_CONFIG and GUILE_TOOLS. The variables are marked for substitution, as by ‘AC_SUBST’. -- Autoconf Macro: GUILE_CHECK_RETVAL var check VAR is a shell variable name to be set to the return value. CHECK is a Guile Scheme expression, evaluated with "$GUILE -c", and returning either 0 or non-#f to indicate the check passed. Non-0 number or #f indicates failure. Avoid using the character "#" since that confuses autoconf. -- Autoconf Macro: GUILE_MODULE_CHECK var module featuretest description VAR is a shell variable name to be set to "yes" or "no". MODULE is a list of symbols, like: (ice-9 common-list). FEATURETEST is an expression acceptable to GUILE_CHECK, q.v. DESCRIPTION is a present-tense verb phrase (passed to AC_MSG_CHECKING). -- Autoconf Macro: GUILE_MODULE_AVAILABLE var module VAR is a shell variable name to be set to "yes" or "no". MODULE is a list of symbols, like: (ice-9 common-list). -- Autoconf Macro: GUILE_MODULE_REQUIRED symlist SYMLIST is a list of symbols, WITHOUT surrounding parens, like: ice-9 common-list. -- Autoconf Macro: GUILE_MODULE_EXPORTS var module modvar VAR is a shell variable to be set to "yes" or "no". MODULE is a list of symbols, like: (ice-9 common-list). MODVAR is the Guile Scheme variable to check. -- Autoconf Macro: GUILE_MODULE_REQUIRED_EXPORT module modvar MODULE is a list of symbols, like: (ice-9 common-list). MODVAR is the Guile Scheme variable to check. 5.8.3 Using Autoconf Macros --------------------------- Using the autoconf macros is straightforward: Add the macro "calls" (actually instantiations) to ‘configure.ac’, run ‘aclocal’, and finally, run ‘autoconf’. If your system doesn't have guile.m4 installed, place the desired macro definitions (‘AC_DEFUN’ forms) in ‘acinclude.m4’, and ‘aclocal’ will do the right thing. Some of the macros can be used inside normal shell constructs: ‘if foo ; then GUILE_BAZ ; fi’, but this is not guaranteed. It's probably a good idea to instantiate macros at top-level. We now include two examples, one simple and one complicated. The first example is for a package that uses libguile, and thus needs to know how to compile and link against it. So we use ‘PKG_CHECK_MODULES’ to set the vars ‘GUILE_CFLAGS’ and ‘GUILE_LIBS’, which are automatically substituted in the Makefile. In configure.ac: PKG_CHECK_MODULES([GUILE], [guile-3.0]) In Makefile.in: GUILE_CFLAGS = @GUILE_CFLAGS@ GUILE_LIBS = @GUILE_LIBS@ myprog.o: myprog.c $(CC) -o $ $(GUILE_CFLAGS) $< myprog: myprog.o $(CC) -o $ $< $(GUILE_LIBS) The second example is for a package of Guile Scheme modules that uses an external program and other Guile Scheme modules (some might call this a "pure scheme" package). So we use the ‘GUILE_SITE_DIR’ macro, a regular ‘AC_PATH_PROG’ macro, and the ‘GUILE_MODULE_AVAILABLE’ macro. In configure.ac: GUILE_SITE_DIR probably_wont_work="" # pgtype pgtable GUILE_MODULE_AVAILABLE(have_guile_pg, (database postgres)) test $have_guile_pg = no && probably_wont_work="(my pgtype) (my pgtable) $probably_wont_work" # gpgutils AC_PATH_PROG(GNUPG,gpg) test x"$GNUPG" = x && probably_wont_work="(my gpgutils) $probably_wont_work" if test ! "$probably_wont_work" = "" ; then p=" ***" echo echo "$p" echo "$p NOTE:" echo "$p The following modules probably won't work:" echo "$p $probably_wont_work" echo "$p They can be installed anyway, and will work if their" echo "$p dependencies are installed later. Please see README." echo "$p" echo fi In Makefile.in: instdir = @GUILE_SITE@/my install: $(INSTALL) my/*.scm $(instdir) 6 API Reference *************** Guile provides an application programming interface (“API”) to developers in two core languages: Scheme and C. This part of the manual contains reference documentation for all of the functionality that is available through both Scheme and C interfaces. 6.1 Overview of the Guile API ============================= Guile's application programming interface (“API”) makes functionality available that an application developer can use in either C or Scheme programming. The interface consists of “elements” that may be macros, functions or variables in C, and procedures, variables, syntax or other types of object in Scheme. Many elements are available to both Scheme and C, in a form that is appropriate. For example, the ‘assq’ Scheme procedure is also available as ‘scm_assq’ to C code. These elements are documented only once, addressing both the Scheme and C aspects of them. The Scheme name of an element is related to its C name in a regular way. Also, a C function takes its parameters in a systematic way. Normally, the name of a C function can be derived given its Scheme name, using some simple textual transformations: • Replace ‘-’ (hyphen) with ‘_’ (underscore). • Replace ‘?’ (question mark) with ‘_p’. • Replace ‘!’ (exclamation point) with ‘_x’. • Replace internal ‘->’ with ‘_to_’. • Replace ‘<=’ (less than or equal) with ‘_leq’. • Replace ‘>=’ (greater than or equal) with ‘_geq’. • Replace ‘<’ (less than) with ‘_less’. • Replace ‘>’ (greater than) with ‘_gr’. • Prefix with ‘scm_’. A C function always takes a fixed number of arguments of type ‘SCM’, even when the corresponding Scheme function takes a variable number. For some Scheme functions, some last arguments are optional; the corresponding C function must always be invoked with all optional arguments specified. To get the effect as if an argument has not been specified, pass ‘SCM_UNDEFINED’ as its value. You can not do this for an argument in the middle; when one argument is ‘SCM_UNDEFINED’ all the ones following it must be ‘SCM_UNDEFINED’ as well. Some Scheme functions take an arbitrary number of _rest_ arguments; the corresponding C function must be invoked with a list of all these arguments. This list is always the last argument of the C function. These two variants can also be combined. The type of the return value of a C function that corresponds to a Scheme function is always ‘SCM’. In the descriptions below, types are therefore often omitted but for the return value and for the arguments. 6.2 Deprecation =============== From time to time functions and other features of Guile become obsolete. Guile's “deprecation” is a mechanism that can help you cope with this. When you use a feature that is deprecated, you will likely get a warning message at run-time. Also, if you have a new enough toolchain, using a deprecated function from ‘libguile’ will cause a link-time warning. The primary source for information about just what interfaces are deprecated in a given release is the file ‘NEWS’. That file also documents what you should use instead of the obsoleted things. The file ‘README’ contains instructions on how to control the inclusion or removal of the deprecated features from the public API of Guile, and how to control the deprecation warning messages. The idea behind this mechanism is that normally all deprecated interfaces are available, but you get feedback when compiling and running code that uses them, so that you can migrate to the newer APIs at your leisure. 6.3 The SCM Type ================ Guile represents all Scheme values with the single C type ‘SCM’. For an introduction to this topic, *Note Dynamic Types::. -- C Type: SCM ‘SCM’ is the user level abstract C type that is used to represent all of Guile's Scheme objects, no matter what the Scheme object type is. No C operation except assignment is guaranteed to work with variables of type ‘SCM’, so you should only use macros and functions to work with ‘SCM’ values. Values are converted between C data types and the ‘SCM’ type with utility functions and macros. -- C Type: scm_t_bits ‘scm_t_bits’ is an unsigned integral data type that is guaranteed to be large enough to hold all information that is required to represent any Scheme object. While this data type is mostly used to implement Guile's internals, the use of this type is also necessary to write certain kinds of extensions to Guile. -- C Type: scm_t_signed_bits This is a signed integral type of the same size as ‘scm_t_bits’. -- C Macro: scm_t_bits SCM_UNPACK (SCM X) Transforms the ‘SCM’ value X into its representation as an integral type. Only after applying ‘SCM_UNPACK’ it is possible to access the bits and contents of the ‘SCM’ value. -- C Macro: SCM SCM_PACK (scm_t_bits X) Takes a valid integral representation of a Scheme object and transforms it into its representation as a ‘SCM’ value. 6.4 Initializing Guile ====================== Each thread that wants to use functions from the Guile API needs to put itself into guile mode with either ‘scm_with_guile’ or ‘scm_init_guile’. The global state of Guile is initialized automatically when the first thread enters guile mode. When a thread wants to block outside of a Guile API function, it should leave guile mode temporarily with ‘scm_without_guile’, *Note Blocking::. Threads that are created by ‘call-with-new-thread’ or ‘scm_spawn_thread’ start out in guile mode so you don't need to initialize them. -- C Function: void * scm_with_guile (void *(*func)(void *), void *data) Call FUNC, passing it DATA and return what FUNC returns. While FUNC is running, the current thread is in guile mode and can thus use the Guile API. When ‘scm_with_guile’ is called from guile mode, the thread remains in guile mode when ‘scm_with_guile’ returns. Otherwise, it puts the current thread into guile mode and, if needed, gives it a Scheme representation that is contained in the list returned by ‘all-threads’, for example. This Scheme representation is not removed when ‘scm_with_guile’ returns so that a given thread is always represented by the same Scheme value during its lifetime, if at all. When this is the first thread that enters guile mode, the global state of Guile is initialized before calling ‘func’. The function FUNC is called via ‘scm_with_continuation_barrier’; thus, ‘scm_with_guile’ returns exactly once. When ‘scm_with_guile’ returns, the thread is no longer in guile mode (except when ‘scm_with_guile’ was called from guile mode, see above). Thus, only ‘func’ can store ‘SCM’ variables on the stack and be sure that they are protected from the garbage collector. See ‘scm_init_guile’ for another approach at initializing Guile that does not have this restriction. It is OK to call ‘scm_with_guile’ while a thread has temporarily left guile mode via ‘scm_without_guile’. It will then simply temporarily enter guile mode again. -- C Function: void scm_init_guile () Arrange things so that all of the code in the current thread executes as if from within a call to ‘scm_with_guile’. That is, all functions called by the current thread can assume that ‘SCM’ values on their stack frames are protected from the garbage collector (except when the thread has explicitly left guile mode, of course). When ‘scm_init_guile’ is called from a thread that already has been in guile mode once, nothing happens. This behavior matters when you call ‘scm_init_guile’ while the thread has only temporarily left guile mode: in that case the thread will not be in guile mode after ‘scm_init_guile’ returns. Thus, you should not use ‘scm_init_guile’ in such a scenario. When a uncaught throw happens in a thread that has been put into guile mode via ‘scm_init_guile’, a short message is printed to the current error port and the thread is exited via ‘scm_pthread_exit (NULL)’. No restrictions are placed on continuations. The function ‘scm_init_guile’ might not be available on all platforms since it requires some stack-bounds-finding magic that might not have been ported to all platforms that Guile runs on. Thus, if you can, it is better to use ‘scm_with_guile’ or its variation ‘scm_boot_guile’ instead of this function. -- C Function: void scm_boot_guile (int ARGC, char **ARGV, void (*MAIN_FUNC) (void *DATA, int ARGC, char **ARGV), void *DATA) Enter guile mode as with ‘scm_with_guile’ and call MAIN_FUNC, passing it DATA, ARGC, and ARGV as indicated. When MAIN_FUNC returns, ‘scm_boot_guile’ calls ‘exit (0)’; ‘scm_boot_guile’ never returns. If you want some other exit value, have MAIN_FUNC call ‘exit’ itself. If you don't want to exit at all, use ‘scm_with_guile’ instead of ‘scm_boot_guile’. The function ‘scm_boot_guile’ arranges for the Scheme ‘command-line’ function to return the strings given by ARGC and ARGV. If MAIN_FUNC modifies ARGC or ARGV, it should call ‘scm_set_program_arguments’ with the final list, so Scheme code will know which arguments have been processed (*note Runtime Environment::). -- C Function: void scm_shell (int ARGC, char **ARGV) Process command-line arguments in the manner of the ‘guile’ executable. This includes loading the normal Guile initialization files, interacting with the user or running any scripts or expressions specified by ‘-s’ or ‘-e’ options, and then exiting. *Note Invoking Guile::, for more details. Since this function does not return, you must do all application-specific initialization before calling this function. 6.5 Snarfing Macros =================== The following macros do two different things: when compiled normally, they expand in one way; when processed during snarfing, they cause the ‘guile-snarf’ program to pick up some initialization code, *Note Function Snarfing::. The descriptions below use the term 'normally' to refer to the case when the code is compiled normally, and 'while snarfing' when the code is processed by ‘guile-snarf’. -- C Macro: SCM_SNARF_INIT (code) Normally, ‘SCM_SNARF_INIT’ expands to nothing; while snarfing, it causes CODE to be included in the initialization action file, followed by a semicolon. This is the fundamental macro for snarfing initialization actions. The more specialized macros below use it internally. -- C Macro: SCM_DEFINE (c_name, scheme_name, req, opt, var, arglist, docstring) Normally, this macro expands into static const char s_C_NAME[] = SCHEME_NAME; SCM C_NAME ARGLIST While snarfing, it causes scm_c_define_gsubr (s_C_NAME, REQ, OPT, VAR, C_NAME); to be added to the initialization actions. Thus, you can use it to declare a C function named C_NAME that will be made available to Scheme with the name SCHEME_NAME. Note that the ARGLIST argument must have parentheses around it. -- C Macro: SCM_SYMBOL (c_name, scheme_name) -- C Macro: SCM_GLOBAL_SYMBOL (c_name, scheme_name) Normally, these macros expand into static SCM C_NAME or SCM C_NAME respectively. While snarfing, they both expand into the initialization code C_NAME = scm_permanent_object (scm_from_locale_symbol (SCHEME_NAME)); Thus, you can use them declare a static or global variable of type ‘SCM’ that will be initialized to the symbol named SCHEME_NAME. -- C Macro: SCM_KEYWORD (c_name, scheme_name) -- C Macro: SCM_GLOBAL_KEYWORD (c_name, scheme_name) Normally, these macros expand into static SCM C_NAME or SCM C_NAME respectively. While snarfing, they both expand into the initialization code C_NAME = scm_permanent_object (scm_c_make_keyword (SCHEME_NAME)); Thus, you can use them declare a static or global variable of type ‘SCM’ that will be initialized to the keyword named SCHEME_NAME. -- C Macro: SCM_VARIABLE (c_name, scheme_name) -- C Macro: SCM_GLOBAL_VARIABLE (c_name, scheme_name) These macros are equivalent to ‘SCM_VARIABLE_INIT’ and ‘SCM_GLOBAL_VARIABLE_INIT’, respectively, with a VALUE of ‘SCM_BOOL_F’. -- C Macro: SCM_VARIABLE_INIT (c_name, scheme_name, value) -- C Macro: SCM_GLOBAL_VARIABLE_INIT (c_name, scheme_name, value) Normally, these macros expand into static SCM C_NAME or SCM C_NAME respectively. While snarfing, they both expand into the initialization code C_NAME = scm_permanent_object (scm_c_define (SCHEME_NAME, VALUE)); Thus, you can use them declare a static or global C variable of type ‘SCM’ that will be initialized to the object representing the Scheme variable named SCHEME_NAME in the current module. The variable will be defined when it doesn't already exist. It is always set to VALUE. 6.6 Data Types ============== Guile's data types form a powerful built-in library of representations and functionality that you can apply to your problem domain. This chapter surveys the data types built-in to Guile, from the simple to the complex. 6.6.1 Booleans -------------- The two boolean values are ‘#t’ for true and ‘#f’ for false. They can also be written as ‘#true’ and ‘#false’, as per R7RS. Boolean values are returned by predicate procedures, such as the general equality predicates ‘eq?’, ‘eqv?’ and ‘equal?’ (*note Equality::) and numerical and string comparison operators like ‘string=?’ (*note String Comparison::) and ‘<=’ (*note Comparison::). (<= 3 8) ⇒ #t (<= 3 -3) ⇒ #f (equal? "house" "houses") ⇒ #f (eq? #f #f) ⇒ #t In test condition contexts like ‘if’ and ‘cond’ (*note Conditionals::), where a group of subexpressions will be evaluated only if a CONDITION expression evaluates to "true", "true" means any value at all except ‘#f’. (if #t "yes" "no") ⇒ "yes" (if 0 "yes" "no") ⇒ "yes" (if #f "yes" "no") ⇒ "no" A result of this asymmetry is that typical Scheme source code more often uses ‘#f’ explicitly than ‘#t’: ‘#f’ is necessary to represent an ‘if’ or ‘cond’ false value, whereas ‘#t’ is not necessary to represent an ‘if’ or ‘cond’ true value. It is important to note that ‘#f’ is *not* equivalent to any other Scheme value. In particular, ‘#f’ is not the same as the number 0 (like in C and C++), and not the same as the "empty list" (like in some Lisp dialects). In C, the two Scheme boolean values are available as the two constants ‘SCM_BOOL_T’ for ‘#t’ and ‘SCM_BOOL_F’ for ‘#f’. Care must be taken with the false value ‘SCM_BOOL_F’: it is not false when used in C conditionals. In order to test for it, use ‘scm_is_false’ or ‘scm_is_true’. -- Scheme Procedure: not x -- C Function: scm_not (x) Return ‘#t’ if X is ‘#f’, else return ‘#f’. -- Scheme Procedure: boolean? obj -- C Function: scm_boolean_p (obj) Return ‘#t’ if OBJ is either ‘#t’ or ‘#f’, else return ‘#f’. -- C Macro: SCM SCM_BOOL_T The ‘SCM’ representation of the Scheme object ‘#t’. -- C Macro: SCM SCM_BOOL_F The ‘SCM’ representation of the Scheme object ‘#f’. -- C Function: int scm_is_true (SCM obj) Return ‘0’ if OBJ is ‘#f’, else return ‘1’. -- C Function: int scm_is_false (SCM obj) Return ‘1’ if OBJ is ‘#f’, else return ‘0’. -- C Function: int scm_is_bool (SCM obj) Return ‘1’ if OBJ is either ‘#t’ or ‘#f’, else return ‘0’. -- C Function: SCM scm_from_bool (int val) Return ‘#f’ if VAL is ‘0’, else return ‘#t’. -- C Function: int scm_to_bool (SCM val) Return ‘1’ if VAL is ‘SCM_BOOL_T’, return ‘0’ when VAL is ‘SCM_BOOL_F’, else signal a 'wrong type' error. You should probably use ‘scm_is_true’ instead of this function when you just want to test a ‘SCM’ value for trueness. 6.6.2 Numerical data types -------------------------- Guile supports a rich "tower" of numerical types -- integer, rational, real and complex -- and provides an extensive set of mathematical and scientific functions for operating on numerical data. This section of the manual documents those types and functions. You may also find it illuminating to read R5RS's presentation of numbers in Scheme, which is particularly clear and accessible: see *note (r5rs)Numbers::. 6.6.2.1 Scheme's Numerical "Tower" .................................. Scheme's numerical "tower" consists of the following categories of numbers: “integers” Whole numbers, positive or negative; e.g. -5, 0, 18. “rationals” The set of numbers that can be expressed as P/Q where P and Q are integers; e.g. 9/16 works, but pi (an irrational number) doesn't. These include integers (N/1). “real numbers” The set of numbers that describes all possible positions along a one-dimensional line. This includes rationals as well as irrational numbers. “complex numbers” The set of numbers that describes all possible positions in a two dimensional space. This includes real as well as imaginary numbers (A+Bi, where A is the “real part”, B is the “imaginary part”, and i is the square root of −1.) It is called a tower because each category "sits on" the one that follows it, in the sense that every integer is also a rational, every rational is also real, and every real number is also a complex number (but with zero imaginary part). In addition to the classification into integers, rationals, reals and complex numbers, Scheme also distinguishes between whether a number is represented exactly or not. For example, the result of 2*sin(pi/4) is exactly 2^(1/2), but Guile can represent neither pi/4 nor 2^(1/2) exactly. Instead, it stores an inexact approximation, using the C type ‘double’. Guile can represent exact rationals of any magnitude, inexact rationals that fit into a C ‘double’, and inexact complex numbers with ‘double’ real and imaginary parts. The ‘number?’ predicate may be applied to any Scheme value to discover whether the value is any of the supported numerical types. -- Scheme Procedure: number? obj -- C Function: scm_number_p (obj) Return ‘#t’ if OBJ is any kind of number, else ‘#f’. For example: (number? 3) ⇒ #t (number? "hello there!") ⇒ #f (define pi 3.141592654) (number? pi) ⇒ #t -- C Function: int scm_is_number (SCM obj) This is equivalent to ‘scm_is_true (scm_number_p (obj))’. The next few subsections document each of Guile's numerical data types in detail. 6.6.2.2 Integers ................ Integers are whole numbers, that is numbers with no fractional part, such as 2, 83, and −3789. Integers in Guile can be arbitrarily big, as shown by the following example. (define (factorial n) (let loop ((n n) (product 1)) (if (= n 0) product (loop (- n 1) (* product n))))) (factorial 3) ⇒ 6 (factorial 20) ⇒ 2432902008176640000 (- (factorial 45)) ⇒ -119622220865480194561963161495657715064383733760000000000 Readers whose background is in programming languages where integers are limited by the need to fit into just 4 or 8 bytes of memory may find this surprising, or suspect that Guile's representation of integers is inefficient. In fact, Guile achieves a near optimal balance of convenience and efficiency by using the host computer's native representation of integers where possible, and a more general representation where the required number does not fit in the native form. Conversion between these two representations is automatic and completely invisible to the Scheme level programmer. C has a host of different integer types, and Guile offers a host of functions to convert between them and the ‘SCM’ representation. For example, a C ‘int’ can be handled with ‘scm_to_int’ and ‘scm_from_int’. Guile also defines a few C integer types of its own, to help with differences between systems. C integer types that are not covered can be handled with the generic ‘scm_to_signed_integer’ and ‘scm_from_signed_integer’ for signed types, or with ‘scm_to_unsigned_integer’ and ‘scm_from_unsigned_integer’ for unsigned types. Scheme integers can be exact and inexact. For example, a number written as ‘3.0’ with an explicit decimal-point is inexact, but it is also an integer. The functions ‘integer?’ and ‘scm_is_integer’ report true for such a number, but the functions ‘exact-integer?’, ‘scm_is_exact_integer’, ‘scm_is_signed_integer’, and ‘scm_is_unsigned_integer’ only allow exact integers and thus report false. Likewise, the conversion functions like ‘scm_to_signed_integer’ only accept exact integers. The motivation for this behavior is that the inexactness of a number should not be lost silently. If you want to allow inexact integers, you can explicitly insert a call to ‘inexact->exact’ or to its C equivalent ‘scm_inexact_to_exact’. (Only inexact integers will be converted by this call into exact integers; inexact non-integers will become exact fractions.) -- Scheme Procedure: integer? x -- C Function: scm_integer_p (x) Return ‘#t’ if X is an exact or inexact integer number, else return ‘#f’. (integer? 487) ⇒ #t (integer? 3.0) ⇒ #t (integer? -3.4) ⇒ #f (integer? +inf.0) ⇒ #f -- C Function: int scm_is_integer (SCM x) This is equivalent to ‘scm_is_true (scm_integer_p (x))’. -- Scheme Procedure: exact-integer? x -- C Function: scm_exact_integer_p (x) Return ‘#t’ if X is an exact integer number, else return ‘#f’. (exact-integer? 37) ⇒ #t (exact-integer? 3.0) ⇒ #f -- C Function: int scm_is_exact_integer (SCM x) This is equivalent to ‘scm_is_true (scm_exact_integer_p (x))’. -- C Type: scm_t_int8 -- C Type: scm_t_uint8 -- C Type: scm_t_int16 -- C Type: scm_t_uint16 -- C Type: scm_t_int32 -- C Type: scm_t_uint32 -- C Type: scm_t_int64 -- C Type: scm_t_uint64 -- C Type: scm_t_intmax -- C Type: scm_t_uintmax The C types are equivalent to the corresponding ISO C types but are defined on all platforms, with the exception of ‘scm_t_int64’ and ‘scm_t_uint64’, which are only defined when a 64-bit type is available. For example, ‘scm_t_int8’ is equivalent to ‘int8_t’. You can regard these definitions as a stop-gap measure until all platforms provide these types. If you know that all the platforms that you are interested in already provide these types, it is better to use them directly instead of the types provided by Guile. -- C Function: int scm_is_signed_integer (SCM x, scm_t_intmax min, scm_t_intmax max) -- C Function: int scm_is_unsigned_integer (SCM x, scm_t_uintmax min, scm_t_uintmax max) Return ‘1’ when X represents an exact integer that is between MIN and MAX, inclusive. These functions can be used to check whether a ‘SCM’ value will fit into a given range, such as the range of a given C integer type. If you just want to convert a ‘SCM’ value to a given C integer type, use one of the conversion functions directly. -- C Function: scm_t_intmax scm_to_signed_integer (SCM x, scm_t_intmax min, scm_t_intmax max) -- C Function: scm_t_uintmax scm_to_unsigned_integer (SCM x, scm_t_uintmax min, scm_t_uintmax max) When X represents an exact integer that is between MIN and MAX inclusive, return that integer. Else signal an error, either a 'wrong-type' error when X is not an exact integer, or an 'out-of-range' error when it doesn't fit the given range. -- C Function: SCM scm_from_signed_integer (scm_t_intmax x) -- C Function: SCM scm_from_unsigned_integer (scm_t_uintmax x) Return the ‘SCM’ value that represents the integer X. This function will always succeed and will always return an exact number. -- C Function: char scm_to_char (SCM x) -- C Function: signed char scm_to_schar (SCM x) -- C Function: unsigned char scm_to_uchar (SCM x) -- C Function: short scm_to_short (SCM x) -- C Function: unsigned short scm_to_ushort (SCM x) -- C Function: int scm_to_int (SCM x) -- C Function: unsigned int scm_to_uint (SCM x) -- C Function: long scm_to_long (SCM x) -- C Function: unsigned long scm_to_ulong (SCM x) -- C Function: long long scm_to_long_long (SCM x) -- C Function: unsigned long long scm_to_ulong_long (SCM x) -- C Function: size_t scm_to_size_t (SCM x) -- C Function: ssize_t scm_to_ssize_t (SCM x) -- C Function: scm_t_uintptr scm_to_uintptr_t (SCM x) -- C Function: scm_t_ptrdiff scm_to_ptrdiff_t (SCM x) -- C Function: scm_t_int8 scm_to_int8 (SCM x) -- C Function: scm_t_uint8 scm_to_uint8 (SCM x) -- C Function: scm_t_int16 scm_to_int16 (SCM x) -- C Function: scm_t_uint16 scm_to_uint16 (SCM x) -- C Function: scm_t_int32 scm_to_int32 (SCM x) -- C Function: scm_t_uint32 scm_to_uint32 (SCM x) -- C Function: scm_t_int64 scm_to_int64 (SCM x) -- C Function: scm_t_uint64 scm_to_uint64 (SCM x) -- C Function: scm_t_intmax scm_to_intmax (SCM x) -- C Function: scm_t_uintmax scm_to_uintmax (SCM x) -- C Function: scm_t_intptr scm_to_intptr_t (SCM x) -- C Function: scm_t_uintptr scm_to_uintptr_t (SCM x) When X represents an exact integer that fits into the indicated C type, return that integer. Else signal an error, either a 'wrong-type' error when X is not an exact integer, or an 'out-of-range' error when it doesn't fit the given range. The functions ‘scm_to_long_long’, ‘scm_to_ulong_long’, ‘scm_to_int64’, and ‘scm_to_uint64’ are only available when the corresponding types are. -- C Function: SCM scm_from_char (char x) -- C Function: SCM scm_from_schar (signed char x) -- C Function: SCM scm_from_uchar (unsigned char x) -- C Function: SCM scm_from_short (short x) -- C Function: SCM scm_from_ushort (unsigned short x) -- C Function: SCM scm_from_int (int x) -- C Function: SCM scm_from_uint (unsigned int x) -- C Function: SCM scm_from_long (long x) -- C Function: SCM scm_from_ulong (unsigned long x) -- C Function: SCM scm_from_long_long (long long x) -- C Function: SCM scm_from_ulong_long (unsigned long long x) -- C Function: SCM scm_from_size_t (size_t x) -- C Function: SCM scm_from_ssize_t (ssize_t x) -- C Function: SCM scm_from_uintptr_t (uintptr_t x) -- C Function: SCM scm_from_ptrdiff_t (scm_t_ptrdiff x) -- C Function: SCM scm_from_int8 (scm_t_int8 x) -- C Function: SCM scm_from_uint8 (scm_t_uint8 x) -- C Function: SCM scm_from_int16 (scm_t_int16 x) -- C Function: SCM scm_from_uint16 (scm_t_uint16 x) -- C Function: SCM scm_from_int32 (scm_t_int32 x) -- C Function: SCM scm_from_uint32 (scm_t_uint32 x) -- C Function: SCM scm_from_int64 (scm_t_int64 x) -- C Function: SCM scm_from_uint64 (scm_t_uint64 x) -- C Function: SCM scm_from_intmax (scm_t_intmax x) -- C Function: SCM scm_from_uintmax (scm_t_uintmax x) -- C Function: SCM scm_from_intptr_t (scm_t_intptr x) -- C Function: SCM scm_from_uintptr_t (scm_t_uintptr x) Return the ‘SCM’ value that represents the integer X. These functions will always succeed and will always return an exact number. -- C Function: void scm_to_mpz (SCM val, mpz_t rop) Assign VAL to the multiple precision integer ROP. VAL must be an exact integer, otherwise an error will be signaled. ROP must have been initialized with ‘mpz_init’ before this function is called. When ROP is no longer needed the occupied space must be freed with ‘mpz_clear’. *Note (gmp)Initializing Integers::, for details. -- C Function: SCM scm_from_mpz (mpz_t val) Return the ‘SCM’ value that represents VAL. 6.6.2.3 Real and Rational Numbers ................................. Mathematically, the real numbers are the set of numbers that describe all possible points along a continuous, infinite, one-dimensional line. The rational numbers are the set of all numbers that can be written as fractions P/Q, where P and Q are integers. All rational numbers are also real, but there are real numbers that are not rational, for example the square root of 2, and pi. Guile can represent both exact and inexact rational numbers, but it cannot represent precise finite irrational numbers. Exact rationals are represented by storing the numerator and denominator as two exact integers. Inexact rationals are stored as floating point numbers using the C type ‘double’. Exact rationals are written as a fraction of integers. There must be no whitespace around the slash: 1/2 -22/7 Even though the actual encoding of inexact rationals is in binary, it may be helpful to think of it as a decimal number with a limited number of significant figures and a decimal point somewhere, since this corresponds to the standard notation for non-whole numbers. For example: 0.34 -0.00000142857931198 -5648394822220000000000.0 4.0 The limited precision of Guile's encoding means that any finite "real" number in Guile can be written in a rational form, by multiplying and then dividing by sufficient powers of 10 (or in fact, 2). For example, ‘-0.00000142857931198’ is the same as −142857931198 divided by 100000000000000000. In Guile's current incarnation, therefore, the ‘rational?’ and ‘real?’ predicates are equivalent for finite numbers. Dividing by an exact zero leads to a error message, as one might expect. However, dividing by an inexact zero does not produce an error. Instead, the result of the division is either plus or minus infinity, depending on the sign of the divided number and the sign of the zero divisor (some platforms support signed zeroes ‘-0.0’ and ‘+0.0’; ‘0.0’ is the same as ‘+0.0’). Dividing zero by an inexact zero yields a NaN ('not a number') value, although they are actually considered numbers by Scheme. Attempts to compare a NaN value with any number (including itself) using ‘=’, ‘<’, ‘>’, ‘<=’ or ‘>=’ always returns ‘#f’. Although a NaN value is not ‘=’ to itself, it is both ‘eqv?’ and ‘equal?’ to itself and other NaN values. However, the preferred way to test for them is by using ‘nan?’. The real NaN values and infinities are written ‘+nan.0’, ‘+inf.0’ and ‘-inf.0’. This syntax is also recognized by ‘read’ as an extension to the usual Scheme syntax. These special values are considered by Scheme to be inexact real numbers but not rational. Note that non-real complex numbers may also contain infinities or NaN values in their real or imaginary parts. To test a real number to see if it is infinite, a NaN value, or neither, use ‘inf?’, ‘nan?’, or ‘finite?’, respectively. Every real number in Scheme belongs to precisely one of those three classes. On platforms that follow IEEE 754 for their floating point arithmetic, the ‘+inf.0’, ‘-inf.0’, and ‘+nan.0’ values are implemented using the corresponding IEEE 754 values. They behave in arithmetic operations like IEEE 754 describes it, i.e., ‘(= +nan.0 +nan.0)’ ⇒ ‘#f’. -- Scheme Procedure: real? obj -- C Function: scm_real_p (obj) Return ‘#t’ if OBJ is a real number, else ‘#f’. Note that the sets of integer and rational values form subsets of the set of real numbers, so the predicate will also be fulfilled if OBJ is an integer number or a rational number. -- Scheme Procedure: rational? x -- C Function: scm_rational_p (x) Return ‘#t’ if X is a rational number, ‘#f’ otherwise. Note that the set of integer values forms a subset of the set of rational numbers, i.e. the predicate will also be fulfilled if X is an integer number. -- Scheme Procedure: rationalize x eps -- C Function: scm_rationalize (x, eps) Returns the _simplest_ rational number differing from X by no more than EPS. As required by R5RS, ‘rationalize’ only returns an exact result when both its arguments are exact. Thus, you might need to use ‘inexact->exact’ on the arguments. (rationalize (inexact->exact 1.2) 1/100) ⇒ 6/5 -- Scheme Procedure: inf? x -- C Function: scm_inf_p (x) Return ‘#t’ if the real number X is ‘+inf.0’ or ‘-inf.0’. Otherwise return ‘#f’. -- Scheme Procedure: nan? x -- C Function: scm_nan_p (x) Return ‘#t’ if the real number X is ‘+nan.0’, or ‘#f’ otherwise. -- Scheme Procedure: finite? x -- C Function: scm_finite_p (x) Return ‘#t’ if the real number X is neither infinite nor a NaN, ‘#f’ otherwise. -- Scheme Procedure: nan -- C Function: scm_nan () Return ‘+nan.0’, a NaN value. -- Scheme Procedure: inf -- C Function: scm_inf () Return ‘+inf.0’, positive infinity. -- Scheme Procedure: numerator x -- C Function: scm_numerator (x) Return the numerator of the rational number X. -- Scheme Procedure: denominator x -- C Function: scm_denominator (x) Return the denominator of the rational number X. -- C Function: int scm_is_real (SCM val) -- C Function: int scm_is_rational (SCM val) Equivalent to ‘scm_is_true (scm_real_p (val))’ and ‘scm_is_true (scm_rational_p (val))’, respectively. -- C Function: double scm_to_double (SCM val) Returns the number closest to VAL that is representable as a ‘double’. Returns infinity for a VAL that is too large in magnitude. The argument VAL must be a real number. -- C Function: SCM scm_from_double (double val) Return the ‘SCM’ value that represents VAL. The returned value is inexact according to the predicate ‘inexact?’, but it will be exactly equal to VAL. 6.6.2.4 Complex Numbers ....................... Complex numbers are the set of numbers that describe all possible points in a two-dimensional space. The two coordinates of a particular point in this space are known as the “real” and “imaginary” parts of the complex number that describes that point. In Guile, complex numbers are written in rectangular form as the sum of their real and imaginary parts, using the symbol ‘i’ to indicate the imaginary part. 3+4i ⇒ 3.0+4.0i (* 3-8i 2.3+0.3i) ⇒ 9.3-17.5i Polar form can also be used, with an ‘@’ between magnitude and angle, 1@3.141592 ⇒ -1.0 (approx) -1@1.57079 ⇒ 0.0-1.0i (approx) Guile represents a complex number as a pair of inexact reals, so the real and imaginary parts of a complex number have the same properties of inexactness and limited precision as single inexact real numbers. Note that each part of a complex number may contain any inexact real value, including the special values ‘+nan.0’, ‘+inf.0’ and ‘-inf.0’, as well as either of the signed zeroes ‘0.0’ or ‘-0.0’. -- Scheme Procedure: complex? z -- C Function: scm_complex_p (z) Return ‘#t’ if Z is a complex number, ‘#f’ otherwise. Note that the sets of real, rational and integer values form subsets of the set of complex numbers, i.e. the predicate will also be fulfilled if Z is a real, rational or integer number. -- C Function: int scm_is_complex (SCM val) Equivalent to ‘scm_is_true (scm_complex_p (val))’. 6.6.2.5 Exact and Inexact Numbers ................................. R5RS requires that, with few exceptions, a calculation involving inexact numbers always produces an inexact result. To meet this requirement, Guile distinguishes between an exact integer value such as ‘5’ and the corresponding inexact integer value which, to the limited precision available, has no fractional part, and is printed as ‘5.0’. Guile will only convert the latter value to the former when forced to do so by an invocation of the ‘inexact->exact’ procedure. The only exception to the above requirement is when the values of the inexact numbers do not affect the result. For example ‘(expt n 0)’ is ‘1’ for any value of ‘n’, therefore ‘(expt 5.0 0)’ is permitted to return an exact ‘1’. -- Scheme Procedure: exact? z -- C Function: scm_exact_p (z) Return ‘#t’ if the number Z is exact, ‘#f’ otherwise. (exact? 2) ⇒ #t (exact? 0.5) ⇒ #f (exact? (/ 2)) ⇒ #t -- C Function: int scm_is_exact (SCM z) Return a ‘1’ if the number Z is exact, and ‘0’ otherwise. This is equivalent to ‘scm_is_true (scm_exact_p (z))’. An alternate approach to testing the exactness of a number is to use ‘scm_is_signed_integer’ or ‘scm_is_unsigned_integer’. -- Scheme Procedure: inexact? z -- C Function: scm_inexact_p (z) Return ‘#t’ if the number Z is inexact, ‘#f’ else. -- C Function: int scm_is_inexact (SCM z) Return a ‘1’ if the number Z is inexact, and ‘0’ otherwise. This is equivalent to ‘scm_is_true (scm_inexact_p (z))’. -- Scheme Procedure: inexact->exact z -- C Function: scm_inexact_to_exact (z) Return an exact number that is numerically closest to Z, when there is one. For inexact rationals, Guile returns the exact rational that is numerically equal to the inexact rational. Inexact complex numbers with a non-zero imaginary part can not be made exact. (inexact->exact 0.5) ⇒ 1/2 The following happens because 12/10 is not exactly representable as a ‘double’ (on most platforms). However, when reading a decimal number that has been marked exact with the "#e" prefix, Guile is able to represent it correctly. (inexact->exact 1.2) ⇒ 5404319552844595/4503599627370496 #e1.2 ⇒ 6/5 -- Scheme Procedure: exact->inexact z -- C Function: scm_exact_to_inexact (z) Convert the number Z to its inexact representation. 6.6.2.6 Read Syntax for Numerical Data ...................................... The read syntax for integers is a string of digits, optionally preceded by a minus or plus character, a code indicating the base in which the integer is encoded, and a code indicating whether the number is exact or inexact. The supported base codes are: ‘#b’ ‘#B’ the integer is written in binary (base 2) ‘#o’ ‘#O’ the integer is written in octal (base 8) ‘#d’ ‘#D’ the integer is written in decimal (base 10) ‘#x’ ‘#X’ the integer is written in hexadecimal (base 16) If the base code is omitted, the integer is assumed to be decimal. The following examples show how these base codes are used. -13 ⇒ -13 #d-13 ⇒ -13 #x-13 ⇒ -19 #b+1101 ⇒ 13 #o377 ⇒ 255 The codes for indicating exactness (which can, incidentally, be applied to all numerical values) are: ‘#e’ ‘#E’ the number is exact ‘#i’ ‘#I’ the number is inexact. If the exactness indicator is omitted, the number is exact unless it contains a radix point. Since Guile can not represent exact complex numbers, an error is signaled when asking for them. (exact? 1.2) ⇒ #f (exact? #e1.2) ⇒ #t (exact? #e+1i) ERROR: Wrong type argument Guile also understands the syntax ‘+inf.0’ and ‘-inf.0’ for plus and minus infinity, respectively. The value must be written exactly as shown, that is, they always must have a sign and exactly one zero digit after the decimal point. It also understands ‘+nan.0’ and ‘-nan.0’ for the special 'not-a-number' value. The sign is ignored for 'not-a-number' and the value is always printed as ‘+nan.0’. 6.6.2.7 Operations on Integer Values .................................... -- Scheme Procedure: odd? n -- C Function: scm_odd_p (n) Return ‘#t’ if N is an odd number, ‘#f’ otherwise. -- Scheme Procedure: even? n -- C Function: scm_even_p (n) Return ‘#t’ if N is an even number, ‘#f’ otherwise. -- Scheme Procedure: quotient n d -- Scheme Procedure: remainder n d -- C Function: scm_quotient (n, d) -- C Function: scm_remainder (n, d) Return the quotient or remainder from N divided by D. The quotient is rounded towards zero, and the remainder will have the same sign as N. In all cases quotient and remainder satisfy N = Q*D + R. (remainder 13 4) ⇒ 1 (remainder -13 4) ⇒ -1 See also ‘truncate-quotient’, ‘truncate-remainder’ and related operations in *note Arithmetic::. -- Scheme Procedure: modulo n d -- C Function: scm_modulo (n, d) Return the remainder from N divided by D, with the same sign as D. (modulo 13 4) ⇒ 1 (modulo -13 4) ⇒ 3 (modulo 13 -4) ⇒ -3 (modulo -13 -4) ⇒ -1 See also ‘floor-quotient’, ‘floor-remainder’ and related operations in *note Arithmetic::. -- Scheme Procedure: gcd x... -- C Function: scm_gcd (x, y) Return the greatest common divisor of all arguments. If called without arguments, 0 is returned. The C function ‘scm_gcd’ always takes two arguments, while the Scheme function can take an arbitrary number. -- Scheme Procedure: lcm x... -- C Function: scm_lcm (x, y) Return the least common multiple of the arguments. If called without arguments, 1 is returned. The C function ‘scm_lcm’ always takes two arguments, while the Scheme function can take an arbitrary number. -- Scheme Procedure: modulo-expt n k m -- C Function: scm_modulo_expt (n, k, m) Return N raised to the integer exponent K, modulo M. (modulo-expt 2 3 5) ⇒ 3 -- Scheme Procedure: exact-integer-sqrt K -- C Function: void scm_exact_integer_sqrt (SCM K, SCM *S, SCM *R) Return two exact non-negative integers S and R such that K = S^2 + R and S^2 <= K < (S + 1)^2. An error is raised if K is not an exact non-negative integer. (exact-integer-sqrt 10) ⇒ 3 and 1 6.6.2.8 Comparison Predicates ............................. The C comparison functions below always takes two arguments, while the Scheme functions can take an arbitrary number. Also keep in mind that the C functions return one of the Scheme boolean values ‘SCM_BOOL_T’ or ‘SCM_BOOL_F’ which are both true as far as C is concerned. Thus, always write ‘scm_is_true (scm_num_eq_p (x, y))’ when testing the two Scheme numbers ‘x’ and ‘y’ for equality, for example. -- Scheme Procedure: = -- C Function: scm_num_eq_p (x, y) Return ‘#t’ if all parameters are numerically equal. -- Scheme Procedure: < -- C Function: scm_less_p (x, y) Return ‘#t’ if the list of parameters is monotonically increasing. -- Scheme Procedure: > -- C Function: scm_gr_p (x, y) Return ‘#t’ if the list of parameters is monotonically decreasing. -- Scheme Procedure: <= -- C Function: scm_leq_p (x, y) Return ‘#t’ if the list of parameters is monotonically non-decreasing. -- Scheme Procedure: >= -- C Function: scm_geq_p (x, y) Return ‘#t’ if the list of parameters is monotonically non-increasing. -- Scheme Procedure: zero? z -- C Function: scm_zero_p (z) Return ‘#t’ if Z is an exact or inexact number equal to zero. -- Scheme Procedure: positive? x -- C Function: scm_positive_p (x) Return ‘#t’ if X is an exact or inexact number greater than zero. -- Scheme Procedure: negative? x -- C Function: scm_negative_p (x) Return ‘#t’ if X is an exact or inexact number less than zero. 6.6.2.9 Converting Numbers To and From Strings .............................................. The following procedures read and write numbers according to their external representation as defined by R5RS (*note R5RS Lexical Structure: (r5rs)Lexical structure.). *Note the ‘(ice-9 i18n)’ module: Number Input and Output, for locale-dependent number parsing. -- Scheme Procedure: number->string n [radix] -- C Function: scm_number_to_string (n, radix) Return a string holding the external representation of the number N in the given RADIX. If N is inexact, a radix of 10 will be used. -- Scheme Procedure: string->number string [radix] -- C Function: scm_string_to_number (string, radix) Return a number of the maximally precise representation expressed by the given STRING. RADIX must be an exact integer, either 2, 8, 10, or 16. If supplied, RADIX is a default radix that may be overridden by an explicit radix prefix in STRING (e.g. "#o177"). If RADIX is not supplied, then the default radix is 10. If string is not a syntactically valid notation for a number, then ‘string->number’ returns ‘#f’. -- C Function: SCM scm_c_locale_stringn_to_number (const char *string, size_t len, unsigned radix) As per ‘string->number’ above, but taking a C string, as pointer and length. The string characters should be in the current locale encoding (‘locale’ in the name refers only to that, there's no locale-dependent parsing). 6.6.2.10 Complex Number Operations .................................. -- Scheme Procedure: make-rectangular real_part imaginary_part -- C Function: scm_make_rectangular (real_part, imaginary_part) Return a complex number constructed of the given REAL-PART and IMAGINARY-PART parts. -- Scheme Procedure: make-polar mag ang -- C Function: scm_make_polar (mag, ang) Return the complex number MAG * e^(i * ANG). -- Scheme Procedure: real-part z -- C Function: scm_real_part (z) Return the real part of the number Z. -- Scheme Procedure: imag-part z -- C Function: scm_imag_part (z) Return the imaginary part of the number Z. -- Scheme Procedure: magnitude z -- C Function: scm_magnitude (z) Return the magnitude of the number Z. This is the same as ‘abs’ for real arguments, but also allows complex numbers. -- Scheme Procedure: angle z -- C Function: scm_angle (z) Return the angle of the complex number Z. -- C Function: SCM scm_c_make_rectangular (double re, double im) -- C Function: SCM scm_c_make_polar (double x, double y) Like ‘scm_make_rectangular’ or ‘scm_make_polar’, respectively, but these functions take ‘double’s as their arguments. -- C Function: double scm_c_real_part (z) -- C Function: double scm_c_imag_part (z) Returns the real or imaginary part of Z as a ‘double’. -- C Function: double scm_c_magnitude (z) -- C Function: double scm_c_angle (z) Returns the magnitude or angle of Z as a ‘double’. 6.6.2.11 Arithmetic Functions ............................. The C arithmetic functions below always takes two arguments, while the Scheme functions can take an arbitrary number. When you need to invoke them with just one argument, for example to compute the equivalent of ‘(- x)’, pass ‘SCM_UNDEFINED’ as the second one: ‘scm_difference (x, SCM_UNDEFINED)’. -- Scheme Procedure: + z1 ... -- C Function: scm_sum (z1, z2) Return the sum of all parameter values. Return 0 if called without any parameters. -- Scheme Procedure: - z1 z2 ... -- C Function: scm_difference (z1, z2) If called with one argument Z1, -Z1 is returned. Otherwise the sum of all but the first argument are subtracted from the first argument. -- Scheme Procedure: * z1 ... -- C Function: scm_product (z1, z2) Return the product of all arguments. If called without arguments, 1 is returned. -- Scheme Procedure: / z1 z2 ... -- C Function: scm_divide (z1, z2) Divide the first argument by the product of the remaining arguments. If called with one argument Z1, 1/Z1 is returned. -- Scheme Procedure: 1+ z -- C Function: scm_oneplus (z) Return Z + 1. -- Scheme Procedure: 1- z -- C function: scm_oneminus (z) Return Z - 1. -- Scheme Procedure: abs x -- C Function: scm_abs (x) Return the absolute value of X. X must be a number with zero imaginary part. To calculate the magnitude of a complex number, use ‘magnitude’ instead. -- Scheme Procedure: max x1 x2 ... -- C Function: scm_max (x1, x2) Return the maximum of all parameter values. -- Scheme Procedure: min x1 x2 ... -- C Function: scm_min (x1, x2) Return the minimum of all parameter values. -- Scheme Procedure: truncate x -- C Function: scm_truncate_number (x) Round the inexact number X towards zero. -- Scheme Procedure: round x -- C Function: scm_round_number (x) Round the inexact number X to the nearest integer. When exactly halfway between two integers, round to the even one. -- Scheme Procedure: floor x -- C Function: scm_floor (x) Round the number X towards minus infinity. -- Scheme Procedure: ceiling x -- C Function: scm_ceiling (x) Round the number X towards infinity. -- C Function: double scm_c_truncate (double x) -- C Function: double scm_c_round (double x) Like ‘scm_truncate_number’ or ‘scm_round_number’, respectively, but these functions take and return ‘double’ values. -- Scheme Procedure: euclidean/ X Y -- Scheme Procedure: euclidean-quotient X Y -- Scheme Procedure: euclidean-remainder X Y -- C Function: void scm_euclidean_divide (SCM X, SCM Y, SCM *Q, SCM *R) -- C Function: SCM scm_euclidean_quotient (SCM X, SCM Y) -- C Function: SCM scm_euclidean_remainder (SCM X, SCM Y) These procedures accept two real numbers X and Y, where the divisor Y must be non-zero. ‘euclidean-quotient’ returns the integer Q and ‘euclidean-remainder’ returns the real number R such that X = Q*Y + R and 0 <= R < |Y|. ‘euclidean/’ returns both Q and R, and is more efficient than computing each separately. Note that when Y > 0, ‘euclidean-quotient’ returns floor(X/Y), otherwise it returns ceiling(X/Y). Note that these operators are equivalent to the R6RS operators ‘div’, ‘mod’, and ‘div-and-mod’. (euclidean-quotient 123 10) ⇒ 12 (euclidean-remainder 123 10) ⇒ 3 (euclidean/ 123 10) ⇒ 12 and 3 (euclidean/ 123 -10) ⇒ -12 and 3 (euclidean/ -123 10) ⇒ -13 and 7 (euclidean/ -123 -10) ⇒ 13 and 7 (euclidean/ -123.2 -63.5) ⇒ 2.0 and 3.8 (euclidean/ 16/3 -10/7) ⇒ -3 and 22/21 -- Scheme Procedure: floor/ X Y -- Scheme Procedure: floor-quotient X Y -- Scheme Procedure: floor-remainder X Y -- C Function: void scm_floor_divide (SCM X, SCM Y, SCM *Q, SCM *R) -- C Function: SCM scm_floor_quotient (X, Y) -- C Function: SCM scm_floor_remainder (X, Y) These procedures accept two real numbers X and Y, where the divisor Y must be non-zero. ‘floor-quotient’ returns the integer Q and ‘floor-remainder’ returns the real number R such that Q = floor(X/Y) and X = Q*Y + R. ‘floor/’ returns both Q and R, and is more efficient than computing each separately. Note that R, if non-zero, will have the same sign as Y. When X and Y are integers, ‘floor-remainder’ is equivalent to the R5RS integer-only operator ‘modulo’. (floor-quotient 123 10) ⇒ 12 (floor-remainder 123 10) ⇒ 3 (floor/ 123 10) ⇒ 12 and 3 (floor/ 123 -10) ⇒ -13 and -7 (floor/ -123 10) ⇒ -13 and 7 (floor/ -123 -10) ⇒ 12 and -3 (floor/ -123.2 -63.5) ⇒ 1.0 and -59.7 (floor/ 16/3 -10/7) ⇒ -4 and -8/21 -- Scheme Procedure: ceiling/ X Y -- Scheme Procedure: ceiling-quotient X Y -- Scheme Procedure: ceiling-remainder X Y -- C Function: void scm_ceiling_divide (SCM X, SCM Y, SCM *Q, SCM *R) -- C Function: SCM scm_ceiling_quotient (X, Y) -- C Function: SCM scm_ceiling_remainder (X, Y) These procedures accept two real numbers X and Y, where the divisor Y must be non-zero. ‘ceiling-quotient’ returns the integer Q and ‘ceiling-remainder’ returns the real number R such that Q = ceiling(X/Y) and X = Q*Y + R. ‘ceiling/’ returns both Q and R, and is more efficient than computing each separately. Note that R, if non-zero, will have the opposite sign of Y. (ceiling-quotient 123 10) ⇒ 13 (ceiling-remainder 123 10) ⇒ -7 (ceiling/ 123 10) ⇒ 13 and -7 (ceiling/ 123 -10) ⇒ -12 and 3 (ceiling/ -123 10) ⇒ -12 and -3 (ceiling/ -123 -10) ⇒ 13 and 7 (ceiling/ -123.2 -63.5) ⇒ 2.0 and 3.8 (ceiling/ 16/3 -10/7) ⇒ -3 and 22/21 -- Scheme Procedure: truncate/ X Y -- Scheme Procedure: truncate-quotient X Y -- Scheme Procedure: truncate-remainder X Y -- C Function: void scm_truncate_divide (SCM X, SCM Y, SCM *Q, SCM *R) -- C Function: SCM scm_truncate_quotient (X, Y) -- C Function: SCM scm_truncate_remainder (X, Y) These procedures accept two real numbers X and Y, where the divisor Y must be non-zero. ‘truncate-quotient’ returns the integer Q and ‘truncate-remainder’ returns the real number R such that Q is X/Y rounded toward zero, and X = Q*Y + R. ‘truncate/’ returns both Q and R, and is more efficient than computing each separately. Note that R, if non-zero, will have the same sign as X. When X and Y are integers, these operators are equivalent to the R5RS integer-only operators ‘quotient’ and ‘remainder’. (truncate-quotient 123 10) ⇒ 12 (truncate-remainder 123 10) ⇒ 3 (truncate/ 123 10) ⇒ 12 and 3 (truncate/ 123 -10) ⇒ -12 and 3 (truncate/ -123 10) ⇒ -12 and -3 (truncate/ -123 -10) ⇒ 12 and -3 (truncate/ -123.2 -63.5) ⇒ 1.0 and -59.7 (truncate/ 16/3 -10/7) ⇒ -3 and 22/21 -- Scheme Procedure: centered/ X Y -- Scheme Procedure: centered-quotient X Y -- Scheme Procedure: centered-remainder X Y -- C Function: void scm_centered_divide (SCM X, SCM Y, SCM *Q, SCM *R) -- C Function: SCM scm_centered_quotient (SCM X, SCM Y) -- C Function: SCM scm_centered_remainder (SCM X, SCM Y) These procedures accept two real numbers X and Y, where the divisor Y must be non-zero. ‘centered-quotient’ returns the integer Q and ‘centered-remainder’ returns the real number R such that X = Q*Y + R and -|Y/2| <= R < |Y/2|. ‘centered/’ returns both Q and R, and is more efficient than computing each separately. Note that ‘centered-quotient’ returns X/Y rounded to the nearest integer. When X/Y lies exactly half-way between two integers, the tie is broken according to the sign of Y. If Y > 0, ties are rounded toward positive infinity, otherwise they are rounded toward negative infinity. This is a consequence of the requirement that -|Y/2| <= R < |Y/2|. Note that these operators are equivalent to the R6RS operators ‘div0’, ‘mod0’, and ‘div0-and-mod0’. (centered-quotient 123 10) ⇒ 12 (centered-remainder 123 10) ⇒ 3 (centered/ 123 10) ⇒ 12 and 3 (centered/ 123 -10) ⇒ -12 and 3 (centered/ -123 10) ⇒ -12 and -3 (centered/ -123 -10) ⇒ 12 and -3 (centered/ 125 10) ⇒ 13 and -5 (centered/ 127 10) ⇒ 13 and -3 (centered/ 135 10) ⇒ 14 and -5 (centered/ -123.2 -63.5) ⇒ 2.0 and 3.8 (centered/ 16/3 -10/7) ⇒ -4 and -8/21 -- Scheme Procedure: round/ X Y -- Scheme Procedure: round-quotient X Y -- Scheme Procedure: round-remainder X Y -- C Function: void scm_round_divide (SCM X, SCM Y, SCM *Q, SCM *R) -- C Function: SCM scm_round_quotient (X, Y) -- C Function: SCM scm_round_remainder (X, Y) These procedures accept two real numbers X and Y, where the divisor Y must be non-zero. ‘round-quotient’ returns the integer Q and ‘round-remainder’ returns the real number R such that X = Q*Y + R and Q is X/Y rounded to the nearest integer, with ties going to the nearest even integer. ‘round/’ returns both Q and R, and is more efficient than computing each separately. Note that ‘round/’ and ‘centered/’ are almost equivalent, but their behavior differs when X/Y lies exactly half-way between two integers. In this case, ‘round/’ chooses the nearest even integer, whereas ‘centered/’ chooses in such a way to satisfy the constraint -|Y/2| <= R < |Y/2|, which is stronger than the corresponding constraint for ‘round/’, -|Y/2| <= R <= |Y/2|. In particular, when X and Y are integers, the number of possible remainders returned by ‘centered/’ is |Y|, whereas the number of possible remainders returned by ‘round/’ is |Y|+1 when Y is even. (round-quotient 123 10) ⇒ 12 (round-remainder 123 10) ⇒ 3 (round/ 123 10) ⇒ 12 and 3 (round/ 123 -10) ⇒ -12 and 3 (round/ -123 10) ⇒ -12 and -3 (round/ -123 -10) ⇒ 12 and -3 (round/ 125 10) ⇒ 12 and 5 (round/ 127 10) ⇒ 13 and -3 (round/ 135 10) ⇒ 14 and -5 (round/ -123.2 -63.5) ⇒ 2.0 and 3.8 (round/ 16/3 -10/7) ⇒ -4 and -8/21 6.6.2.12 Scientific Functions ............................. The following procedures accept any kind of number as arguments, including complex numbers. -- Scheme Procedure: sqrt z Return the square root of Z. Of the two possible roots (positive and negative), the one with a positive real part is returned, or if that's zero then a positive imaginary part. Thus, (sqrt 9.0) ⇒ 3.0 (sqrt -9.0) ⇒ 0.0+3.0i (sqrt 1.0+1.0i) ⇒ 1.09868411346781+0.455089860562227i (sqrt -1.0-1.0i) ⇒ 0.455089860562227-1.09868411346781i -- Scheme Procedure: expt z1 z2 Return Z1 raised to the power of Z2. -- Scheme Procedure: sin z Return the sine of Z. -- Scheme Procedure: cos z Return the cosine of Z. -- Scheme Procedure: tan z Return the tangent of Z. -- Scheme Procedure: asin z Return the arcsine of Z. -- Scheme Procedure: acos z Return the arccosine of Z. -- Scheme Procedure: atan z -- Scheme Procedure: atan y x Return the arctangent of Z, or of Y/X. -- Scheme Procedure: exp z Return e to the power of Z, where e is the base of natural logarithms (2.71828...). -- Scheme Procedure: log z Return the natural logarithm of Z. -- Scheme Procedure: log10 z Return the base 10 logarithm of Z. -- Scheme Procedure: sinh z Return the hyperbolic sine of Z. -- Scheme Procedure: cosh z Return the hyperbolic cosine of Z. -- Scheme Procedure: tanh z Return the hyperbolic tangent of Z. -- Scheme Procedure: asinh z Return the hyperbolic arcsine of Z. -- Scheme Procedure: acosh z Return the hyperbolic arccosine of Z. -- Scheme Procedure: atanh z Return the hyperbolic arctangent of Z. 6.6.2.13 Bitwise Operations ........................... For the following bitwise functions, negative numbers are treated as infinite precision twos-complements. For instance -6 is bits ...111010, with infinitely many ones on the left. It can be seen that adding 6 (binary 110) to such a bit pattern gives all zeros. -- Scheme Procedure: logand n1 n2 ... -- C Function: scm_logand (n1, n2) Return the bitwise AND of the integer arguments. (logand) ⇒ -1 (logand 7) ⇒ 7 (logand #b111 #b011 #b001) ⇒ 1 -- Scheme Procedure: logior n1 n2 ... -- C Function: scm_logior (n1, n2) Return the bitwise OR of the integer arguments. (logior) ⇒ 0 (logior 7) ⇒ 7 (logior #b000 #b001 #b011) ⇒ 3 -- Scheme Procedure: logxor n1 n2 ... -- C Function: scm_loxor (n1, n2) Return the bitwise XOR of the integer arguments. A bit is set in the result if it is set in an odd number of arguments. (logxor) ⇒ 0 (logxor 7) ⇒ 7 (logxor #b000 #b001 #b011) ⇒ 2 (logxor #b000 #b001 #b011 #b011) ⇒ 1 -- Scheme Procedure: lognot n -- C Function: scm_lognot (n) Return the integer which is the ones-complement of the integer argument, ie. each 0 bit is changed to 1 and each 1 bit to 0. (number->string (lognot #b10000000) 2) ⇒ "-10000001" (number->string (lognot #b0) 2) ⇒ "-1" -- Scheme Procedure: logtest j k -- C Function: scm_logtest (j, k) Test whether J and K have any 1 bits in common. This is equivalent to ‘(not (zero? (logand j k)))’, but without actually calculating the ‘logand’, just testing for non-zero. (logtest #b0100 #b1011) ⇒ #f (logtest #b0100 #b0111) ⇒ #t -- Scheme Procedure: logbit? index j -- C Function: scm_logbit_p (index, j) Test whether bit number INDEX in J is set. INDEX starts from 0 for the least significant bit. (logbit? 0 #b1101) ⇒ #t (logbit? 1 #b1101) ⇒ #f (logbit? 2 #b1101) ⇒ #t (logbit? 3 #b1101) ⇒ #t (logbit? 4 #b1101) ⇒ #f -- Scheme Procedure: ash n count -- C Function: scm_ash (n, count) Return floor(n * 2^{count}). N and COUNT must be exact integers. With N viewed as an infinite-precision twos-complement integer, ‘ash’ means a left shift introducing zero bits when COUNT is positive, or a right shift dropping bits when COUNT is negative. This is an "arithmetic" shift. (number->string (ash #b1 3) 2) ⇒ "1000" (number->string (ash #b1010 -1) 2) ⇒ "101" ;; -23 is bits ...11101001, -6 is bits ...111010 (ash -23 -2) ⇒ -6 -- Scheme Procedure: round-ash n count -- C Function: scm_round_ash (n, count) Return round(n * 2^count). N and COUNT must be exact integers. With N viewed as an infinite-precision twos-complement integer, ‘round-ash’ means a left shift introducing zero bits when COUNT is positive, or a right shift rounding to the nearest integer (with ties going to the nearest even integer) when COUNT is negative. This is a rounded "arithmetic" shift. (number->string (round-ash #b1 3) 2) ⇒ \"1000\" (number->string (round-ash #b1010 -1) 2) ⇒ \"101\" (number->string (round-ash #b1010 -2) 2) ⇒ \"10\" (number->string (round-ash #b1011 -2) 2) ⇒ \"11\" (number->string (round-ash #b1101 -2) 2) ⇒ \"11\" (number->string (round-ash #b1110 -2) 2) ⇒ \"100\" -- Scheme Procedure: logcount n -- C Function: scm_logcount (n) Return the number of bits in integer N. If N is positive, the 1-bits in its binary representation are counted. If negative, the 0-bits in its two's-complement binary representation are counted. If zero, 0 is returned. (logcount #b10101010) ⇒ 4 (logcount 0) ⇒ 0 (logcount -2) ⇒ 1 -- Scheme Procedure: integer-length n -- C Function: scm_integer_length (n) Return the number of bits necessary to represent N. For positive N this is how many bits to the most significant one bit. For negative N it's how many bits to the most significant zero bit in twos complement form. (integer-length #b10101010) ⇒ 8 (integer-length #b1111) ⇒ 4 (integer-length 0) ⇒ 0 (integer-length -1) ⇒ 0 (integer-length -256) ⇒ 8 (integer-length -257) ⇒ 9 -- Scheme Procedure: integer-expt n k -- C Function: scm_integer_expt (n, k) Return N raised to the power K. K must be an exact integer, N can be any number. Negative K is supported, and results in 1/n^abs(k) in the usual way. N^0 is 1, as usual, and that includes 0^0 is 1. (integer-expt 2 5) ⇒ 32 (integer-expt -3 3) ⇒ -27 (integer-expt 5 -3) ⇒ 1/125 (integer-expt 0 0) ⇒ 1 -- Scheme Procedure: bit-extract n start end -- C Function: scm_bit_extract (n, start, end) Return the integer composed of the START (inclusive) through END (exclusive) bits of N. The STARTth bit becomes the 0-th bit in the result. (number->string (bit-extract #b1101101010 0 4) 2) ⇒ "1010" (number->string (bit-extract #b1101101010 4 9) 2) ⇒ "10110" 6.6.2.14 Random Number Generation ................................. Pseudo-random numbers are generated from a random state object, which can be created with ‘seed->random-state’ or ‘datum->random-state’. An external representation (i.e. one which can written with ‘write’ and read with ‘read’) of a random state object can be obtained via ‘random-state->datum’. The STATE parameter to the various functions below is optional, it defaults to the state object in the ‘*random-state*’ variable. -- Scheme Procedure: copy-random-state [state] -- C Function: scm_copy_random_state (state) Return a copy of the random state STATE. -- Scheme Procedure: random n [state] -- C Function: scm_random (n, state) Return a number in [0, N). Accepts a positive integer or real n and returns a number of the same type between zero (inclusive) and N (exclusive). The values returned have a uniform distribution. -- Scheme Procedure: random:exp [state] -- C Function: scm_random_exp (state) Return an inexact real in an exponential distribution with mean 1. For an exponential distribution with mean U use ‘(* U (random:exp))’. -- Scheme Procedure: random:hollow-sphere! vect [state] -- C Function: scm_random_hollow_sphere_x (vect, state) Fills VECT with inexact real random numbers the sum of whose squares is equal to 1.0. Thinking of VECT as coordinates in space of dimension N = ‘(vector-length VECT)’, the coordinates are uniformly distributed over the surface of the unit n-sphere. -- Scheme Procedure: random:normal [state] -- C Function: scm_random_normal (state) Return an inexact real in a normal distribution. The distribution used has mean 0 and standard deviation 1. For a normal distribution with mean M and standard deviation D use ‘(+ M (* D (random:normal)))’. -- Scheme Procedure: random:normal-vector! vect [state] -- C Function: scm_random_normal_vector_x (vect, state) Fills VECT with inexact real random numbers that are independent and standard normally distributed (i.e., with mean 0 and variance 1). -- Scheme Procedure: random:solid-sphere! vect [state] -- C Function: scm_random_solid_sphere_x (vect, state) Fills VECT with inexact real random numbers the sum of whose squares is less than 1.0. Thinking of VECT as coordinates in space of dimension N = ‘(vector-length VECT)’, the coordinates are uniformly distributed within the unit N-sphere. -- Scheme Procedure: random:uniform [state] -- C Function: scm_random_uniform (state) Return a uniformly distributed inexact real random number in [0,1). -- Scheme Procedure: seed->random-state seed -- C Function: scm_seed_to_random_state (seed) Return a new random state using SEED. -- Scheme Procedure: datum->random-state datum -- C Function: scm_datum_to_random_state (datum) Return a new random state from DATUM, which should have been obtained by ‘random-state->datum’. -- Scheme Procedure: random-state->datum state -- C Function: scm_random_state_to_datum (state) Return a datum representation of STATE that may be written out and read back with the Scheme reader. -- Scheme Procedure: random-state-from-platform -- C Function: scm_random_state_from_platform () Construct a new random state seeded from a platform-specific source of entropy, appropriate for use in non-security-critical applications. Currently ‘/dev/urandom’ is tried first, or else the seed is based on the time, date, process ID, an address from a freshly allocated heap cell, an address from the local stack frame, and a high-resolution timer if available. -- Variable: *random-state* The global random state used by the above functions when the STATE parameter is not given. Note that the initial value of ‘*random-state*’ is the same every time Guile starts up. Therefore, if you don't pass a STATE parameter to the above procedures, and you don't set ‘*random-state*’ to ‘(seed->random-state your-seed)’, where ‘your-seed’ is something that _isn't_ the same every time, you'll get the same sequence of "random" numbers on every run. For example, unless the relevant source code has changed, ‘(map random (cdr (iota 30)))’, if the first use of random numbers since Guile started up, will always give: (map random (cdr (iota 19))) ⇒ (0 1 1 2 2 2 1 2 6 7 10 0 5 3 12 5 5 12) To seed the random state in a sensible way for non-security-critical applications, do this during initialization of your program: (set! *random-state* (random-state-from-platform)) 6.6.3 Characters ---------------- In Scheme, there is a data type to describe a single character. Defining what exactly a character _is_ can be more complicated than it seems. Guile follows the advice of R6RS and uses The Unicode Standard to help define what a character is. So, for Guile, a character is anything in the Unicode Character Database. The Unicode Character Database is basically a table of characters indexed using integers called 'code points'. Valid code points are in the ranges 0 to ‘#xD7FF’ inclusive or ‘#xE000’ to ‘#x10FFFF’ inclusive, which is about 1.1 million code points. Any code point that has been assigned to a character or that has otherwise been given a meaning by Unicode is called a 'designated code point'. Most of the designated code points, about 200,000 of them, indicate characters, accents or other combining marks that modify other characters, symbols, whitespace, and control characters. Some are not characters but indicators that suggest how to format or display neighboring characters. If a code point is not a designated code point - if it has not been assigned to a character by The Unicode Standard - it is a 'reserved code point', meaning that they are reserved for future use. Most of the code points, about 800,000, are 'reserved code points'. By convention, a Unicode code point is written as "U+XXXX" where "XXXX" is a hexadecimal number. Please note that this convenient notation is not valid code. Guile does not interpret "U+XXXX" as a character. In Scheme, a character literal is written as ‘#\NAME’ where NAME is the name of the character that you want. Printable characters have their usual single character name; for example, ‘#\a’ is a lower case ‘a’. Some of the code points are 'combining characters' that are not meant to be printed by themselves but are instead meant to modify the appearance of the previous character. For combining characters, an alternate form of the character literal is ‘#\’ followed by U+25CC (a small, dotted circle), followed by the combining character. This allows the combining character to be drawn on the circle, not on the backslash of ‘#\’. Many of the non-printing characters, such as whitespace characters and control characters, also have names. The most commonly used non-printing characters have long character names, described in the table below. Character Codepoint Name ‘#\nul’ U+0000 ‘#\alarm’ U+0007 ‘#\backspace’ U+0008 ‘#\tab’ U+0009 ‘#\linefeed’ U+000A ‘#\newline’ U+000A ‘#\vtab’ U+000B ‘#\page’ U+000C ‘#\return’ U+000D ‘#\esc’ U+001B ‘#\space’ U+0020 ‘#\delete’ U+007F There are also short names for all of the "C0 control characters" (those with code points below 32). The following table lists the short name for each character. 0 = ‘#\nul’ 1 = ‘#\soh’ 2 = ‘#\stx’ 3 = ‘#\etx’ 4 = ‘#\eot’ 5 = ‘#\enq’ 6 = ‘#\ack’ 7 = ‘#\bel’ 8 = ‘#\bs’ 9 = ‘#\ht’ 10 = ‘#\lf’ 11 = ‘#\vt’ 12 = ‘#\ff’ 13 = ‘#\cr’ 14 = ‘#\so’ 15 = ‘#\si’ 16 = ‘#\dle’ 17 = ‘#\dc1’ 18 = ‘#\dc2’ 19 = ‘#\dc3’ 20 = ‘#\dc4’ 21 = ‘#\nak’ 22 = ‘#\syn’ 23 = ‘#\etb’ 24 = ‘#\can’ 25 = ‘#\em’ 26 = ‘#\sub’ 27 = ‘#\esc’ 28 = ‘#\fs’ 29 = ‘#\gs’ 30 = ‘#\rs’ 31 = ‘#\us’ 32 = ‘#\sp’ The short name for the "delete" character (code point U+007F) is ‘#\del’. The R7RS name for the "escape" character (code point U+001B) is ‘#\escape’. There are also a few alternative names left over for compatibility with previous versions of Guile. Alternate Standard ‘#\nl’ ‘#\newline’ ‘#\np’ ‘#\page’ ‘#\null’ ‘#\nul’ Characters may also be written using their code point values. They can be written with as an octal number, such as ‘#\10’ for ‘#\bs’ or ‘#\177’ for ‘#\del’. If one prefers hex to octal, there is an additional syntax for character escapes: ‘#\xHHHH’ - the letter 'x' followed by a hexadecimal number of one to eight digits. -- Scheme Procedure: char? x -- C Function: scm_char_p (x) Return ‘#t’ if X is a character, else ‘#f’. Fundamentally, the character comparison operations below are numeric comparisons of the character's code points. -- Scheme Procedure: char=? x y Return ‘#t’ if code point of X is equal to the code point of Y, else ‘#f’. -- Scheme Procedure: char? x y Return ‘#t’ if the code point of X is greater than the code point of Y, else ‘#f’. -- Scheme Procedure: char>=? x y Return ‘#t’ if the code point of X is greater than or equal to the code point of Y, else ‘#f’. Case-insensitive character comparisons use _Unicode case folding_. In case folding comparisons, if a character is lowercase and has an uppercase form that can be expressed as a single character, it is converted to uppercase before comparison. All other characters undergo no conversion before the comparison occurs. This includes the German sharp S (Eszett) which is not uppercased before conversion because its uppercase form has two characters. Unicode case folding is language independent: it uses rules that are generally true, but, it cannot cover all cases for all languages. -- Scheme Procedure: char-ci=? x y Return ‘#t’ if the case-folded code point of X is the same as the case-folded code point of Y, else ‘#f’. -- Scheme Procedure: char-ci? x y Return ‘#t’ if the case-folded code point of X is greater than the case-folded code point of Y, else ‘#f’. -- Scheme Procedure: char-ci>=? x y Return ‘#t’ if the case-folded code point of X is greater than or equal to the case-folded code point of Y, else ‘#f’. -- Scheme Procedure: char-alphabetic? chr -- C Function: scm_char_alphabetic_p (chr) Return ‘#t’ if CHR is alphabetic, else ‘#f’. -- Scheme Procedure: char-numeric? chr -- C Function: scm_char_numeric_p (chr) Return ‘#t’ if CHR is numeric, else ‘#f’. -- Scheme Procedure: char-whitespace? chr -- C Function: scm_char_whitespace_p (chr) Return ‘#t’ if CHR is whitespace, else ‘#f’. -- Scheme Procedure: char-upper-case? chr -- C Function: scm_char_upper_case_p (chr) Return ‘#t’ if CHR is uppercase, else ‘#f’. -- Scheme Procedure: char-lower-case? chr -- C Function: scm_char_lower_case_p (chr) Return ‘#t’ if CHR is lowercase, else ‘#f’. -- Scheme Procedure: char-is-both? chr -- C Function: scm_char_is_both_p (chr) Return ‘#t’ if CHR is either uppercase or lowercase, else ‘#f’. -- Scheme Procedure: char-general-category chr -- C Function: scm_char_general_category (chr) Return a symbol giving the two-letter name of the Unicode general category assigned to CHR or ‘#f’ if no named category is assigned. The following table provides a list of category names along with their meanings. Lu Uppercase letter Pf Final quote punctuation Ll Lowercase letter Po Other punctuation Lt Titlecase letter Sm Math symbol Lm Modifier letter Sc Currency symbol Lo Other letter Sk Modifier symbol Mn Non-spacing mark So Other symbol Mc Combining spacing mark Zs Space separator Me Enclosing mark Zl Line separator Nd Decimal digit number Zp Paragraph separator Nl Letter number Cc Control No Other number Cf Format Pc Connector punctuation Cs Surrogate Pd Dash punctuation Co Private use Ps Open punctuation Cn Unassigned Pe Close punctuation Pi Initial quote punctuation -- Scheme Procedure: char->integer chr -- C Function: scm_char_to_integer (chr) Return the code point of CHR. -- Scheme Procedure: integer->char n -- C Function: scm_integer_to_char (n) Return the character that has code point N. The integer N must be a valid code point. Valid code points are in the ranges 0 to ‘#xD7FF’ inclusive or ‘#xE000’ to ‘#x10FFFF’ inclusive. -- Scheme Procedure: char-upcase chr -- C Function: scm_char_upcase (chr) Return the uppercase character version of CHR. -- Scheme Procedure: char-downcase chr -- C Function: scm_char_downcase (chr) Return the lowercase character version of CHR. -- Scheme Procedure: char-titlecase chr -- C Function: scm_char_titlecase (chr) Return the titlecase character version of CHR if one exists; otherwise return the uppercase version. For most characters these will be the same, but the Unicode Standard includes certain digraph compatibility characters, such as ‘U+01F3’ "dz", for which the uppercase and titlecase characters are different (‘U+01F1’ "DZ" and ‘U+01F2’ "Dz" in this case, respectively). -- C Function: scm_t_wchar scm_c_upcase (scm_t_wchar C) -- C Function: scm_t_wchar scm_c_downcase (scm_t_wchar C) -- C Function: scm_t_wchar scm_c_titlecase (scm_t_wchar C) These C functions take an integer representation of a Unicode codepoint and return the codepoint corresponding to its uppercase, lowercase, and titlecase forms respectively. The type ‘scm_t_wchar’ is a signed, 32-bit integer. Characters also have "formal names", which are defined by Unicode. These names can be accessed in Guile from the ‘(ice-9 unicode)’ module: (use-modules (ice-9 unicode)) -- Scheme Procedure: char->formal-name chr Return the formal all-upper-case Unicode name of CH, as a string, or ‘#f’ if the character has no name. -- Scheme Procedure: formal-name->char name Return the character whose formal all-upper-case Unicode name is NAME, or ‘#f’ if no such character is known. 6.6.4 Character Sets -------------------- The features described in this section correspond directly to SRFI-14. The data type “charset” implements sets of characters (*note Characters::). Because the internal representation of character sets is not visible to the user, a lot of procedures for handling them are provided. Character sets can be created, extended, tested for the membership of a characters and be compared to other character sets. 6.6.4.1 Character Set Predicates/Comparison ........................................... Use these procedures for testing whether an object is a character set, or whether several character sets are equal or subsets of each other. ‘char-set-hash’ can be used for calculating a hash value, maybe for usage in fast lookup procedures. -- Scheme Procedure: char-set? obj -- C Function: scm_char_set_p (obj) Return ‘#t’ if OBJ is a character set, ‘#f’ otherwise. -- Scheme Procedure: char-set= char_set ... -- C Function: scm_char_set_eq (char_sets) Return ‘#t’ if all given character sets are equal. -- Scheme Procedure: char-set<= char_set ... -- C Function: scm_char_set_leq (char_sets) Return ‘#t’ if every character set CHAR_SETi is a subset of character set CHAR_SETi+1. -- Scheme Procedure: char-set-hash cs [bound] -- C Function: scm_char_set_hash (cs, bound) Compute a hash value for the character set CS. If BOUND is given and non-zero, it restricts the returned value to the range 0 ... BOUND - 1. 6.6.4.2 Iterating Over Character Sets ..................................... Character set cursors are a means for iterating over the members of a character sets. After creating a character set cursor with ‘char-set-cursor’, a cursor can be dereferenced with ‘char-set-ref’, advanced to the next member with ‘char-set-cursor-next’. Whether a cursor has passed past the last element of the set can be checked with ‘end-of-char-set?’. Additionally, mapping and (un-)folding procedures for character sets are provided. -- Scheme Procedure: char-set-cursor cs -- C Function: scm_char_set_cursor (cs) Return a cursor into the character set CS. -- Scheme Procedure: char-set-ref cs cursor -- C Function: scm_char_set_ref (cs, cursor) Return the character at the current cursor position CURSOR in the character set CS. It is an error to pass a cursor for which ‘end-of-char-set?’ returns true. -- Scheme Procedure: char-set-cursor-next cs cursor -- C Function: scm_char_set_cursor_next (cs, cursor) Advance the character set cursor CURSOR to the next character in the character set CS. It is an error if the cursor given satisfies ‘end-of-char-set?’. -- Scheme Procedure: end-of-char-set? cursor -- C Function: scm_end_of_char_set_p (cursor) Return ‘#t’ if CURSOR has reached the end of a character set, ‘#f’ otherwise. -- Scheme Procedure: char-set-fold kons knil cs -- C Function: scm_char_set_fold (kons, knil, cs) Fold the procedure KONS over the character set CS, initializing it with KNIL. -- Scheme Procedure: char-set-unfold p f g seed [base_cs] -- C Function: scm_char_set_unfold (p, f, g, seed, base_cs) This is a fundamental constructor for character sets. • G is used to generate a series of "seed" values from the initial seed: SEED, (G SEED), (G^2 SEED), (G^3 SEED), ... • P tells us when to stop - when it returns true when applied to one of the seed values. • F maps each seed value to a character. These characters are added to the base character set BASE_CS to form the result; BASE_CS defaults to the empty set. -- Scheme Procedure: char-set-unfold! p f g seed base_cs -- C Function: scm_char_set_unfold_x (p, f, g, seed, base_cs) This is a fundamental constructor for character sets. • G is used to generate a series of "seed" values from the initial seed: SEED, (G SEED), (G^2 SEED), (G^3 SEED), ... • P tells us when to stop - when it returns true when applied to one of the seed values. • F maps each seed value to a character. These characters are added to the base character set BASE_CS to form the result; BASE_CS defaults to the empty set. -- Scheme Procedure: char-set-for-each proc cs -- C Function: scm_char_set_for_each (proc, cs) Apply PROC to every character in the character set CS. The return value is not specified. -- Scheme Procedure: char-set-map proc cs -- C Function: scm_char_set_map (proc, cs) Map the procedure PROC over every character in CS. PROC must be a character -> character procedure. 6.6.4.3 Creating Character Sets ............................... New character sets are produced with these procedures. -- Scheme Procedure: char-set-copy cs -- C Function: scm_char_set_copy (cs) Return a newly allocated character set containing all characters in CS. -- Scheme Procedure: char-set chr ... -- C Function: scm_char_set (chrs) Return a character set containing all given characters. -- Scheme Procedure: list->char-set list [base_cs] -- C Function: scm_list_to_char_set (list, base_cs) Convert the character list LIST to a character set. If the character set BASE_CS is given, the character in this set are also included in the result. -- Scheme Procedure: list->char-set! list base_cs -- C Function: scm_list_to_char_set_x (list, base_cs) Convert the character list LIST to a character set. The characters are added to BASE_CS and BASE_CS is returned. -- Scheme Procedure: string->char-set str [base_cs] -- C Function: scm_string_to_char_set (str, base_cs) Convert the string STR to a character set. If the character set BASE_CS is given, the characters in this set are also included in the result. -- Scheme Procedure: string->char-set! str base_cs -- C Function: scm_string_to_char_set_x (str, base_cs) Convert the string STR to a character set. The characters from the string are added to BASE_CS, and BASE_CS is returned. -- Scheme Procedure: char-set-filter pred cs [base_cs] -- C Function: scm_char_set_filter (pred, cs, base_cs) Return a character set containing every character from CS so that it satisfies PRED. If provided, the characters from BASE_CS are added to the result. -- Scheme Procedure: char-set-filter! pred cs base_cs -- C Function: scm_char_set_filter_x (pred, cs, base_cs) Return a character set containing every character from CS so that it satisfies PRED. The characters are added to BASE_CS and BASE_CS is returned. -- Scheme Procedure: ucs-range->char-set lower upper [error [base_cs]] -- C Function: scm_ucs_range_to_char_set (lower, upper, error, base_cs) Return a character set containing all characters whose character codes lie in the half-open range [LOWER,UPPER). If ERROR is a true value, an error is signaled if the specified range contains characters which are not contained in the implemented character range. If ERROR is ‘#f’, these characters are silently left out of the resulting character set. The characters in BASE_CS are added to the result, if given. -- Scheme Procedure: ucs-range->char-set! lower upper error base_cs -- C Function: scm_ucs_range_to_char_set_x (lower, upper, error, base_cs) Return a character set containing all characters whose character codes lie in the half-open range [LOWER,UPPER). If ERROR is a true value, an error is signaled if the specified range contains characters which are not contained in the implemented character range. If ERROR is ‘#f’, these characters are silently left out of the resulting character set. The characters are added to BASE_CS and BASE_CS is returned. -- Scheme Procedure: ->char-set x -- C Function: scm_to_char_set (x) Coerces x into a char-set. X may be a string, character or char-set. A string is converted to the set of its constituent characters; a character is converted to a singleton set; a char-set is returned as-is. 6.6.4.4 Querying Character Sets ............................... Access the elements and other information of a character set with these procedures. -- Scheme Procedure: %char-set-dump cs Returns an association list containing debugging information for CS. The association list has the following entries. ‘char-set’ The char-set itself ‘len’ The number of groups of contiguous code points the char-set contains ‘ranges’ A list of lists where each sublist is a range of code points and their associated characters The return value of this function cannot be relied upon to be consistent between versions of Guile and should not be used in code. -- Scheme Procedure: char-set-size cs -- C Function: scm_char_set_size (cs) Return the number of elements in character set CS. -- Scheme Procedure: char-set-count pred cs -- C Function: scm_char_set_count (pred, cs) Return the number of the elements int the character set CS which satisfy the predicate PRED. -- Scheme Procedure: char-set->list cs -- C Function: scm_char_set_to_list (cs) Return a list containing the elements of the character set CS. -- Scheme Procedure: char-set->string cs -- C Function: scm_char_set_to_string (cs) Return a string containing the elements of the character set CS. The order in which the characters are placed in the string is not defined. -- Scheme Procedure: char-set-contains? cs ch -- C Function: scm_char_set_contains_p (cs, ch) Return ‘#t’ if the character CH is contained in the character set CS, or ‘#f’ otherwise. -- Scheme Procedure: char-set-every pred cs -- C Function: scm_char_set_every (pred, cs) Return a true value if every character in the character set CS satisfies the predicate PRED. -- Scheme Procedure: char-set-any pred cs -- C Function: scm_char_set_any (pred, cs) Return a true value if any character in the character set CS satisfies the predicate PRED. 6.6.4.5 Character-Set Algebra ............................. Character sets can be manipulated with the common set algebra operation, such as union, complement, intersection etc. All of these procedures provide side-effecting variants, which modify their character set argument(s). -- Scheme Procedure: char-set-adjoin cs chr ... -- C Function: scm_char_set_adjoin (cs, chrs) Add all character arguments to the first argument, which must be a character set. -- Scheme Procedure: char-set-delete cs chr ... -- C Function: scm_char_set_delete (cs, chrs) Delete all character arguments from the first argument, which must be a character set. -- Scheme Procedure: char-set-adjoin! cs chr ... -- C Function: scm_char_set_adjoin_x (cs, chrs) Add all character arguments to the first argument, which must be a character set. -- Scheme Procedure: char-set-delete! cs chr ... -- C Function: scm_char_set_delete_x (cs, chrs) Delete all character arguments from the first argument, which must be a character set. -- Scheme Procedure: char-set-complement cs -- C Function: scm_char_set_complement (cs) Return the complement of the character set CS. Note that the complement of a character set is likely to contain many reserved code points (code points that are not associated with characters). It may be helpful to modify the output of ‘char-set-complement’ by computing its intersection with the set of designated code points, ‘char-set:designated’. -- Scheme Procedure: char-set-union cs ... -- C Function: scm_char_set_union (char_sets) Return the union of all argument character sets. -- Scheme Procedure: char-set-intersection cs ... -- C Function: scm_char_set_intersection (char_sets) Return the intersection of all argument character sets. -- Scheme Procedure: char-set-difference cs1 cs ... -- C Function: scm_char_set_difference (cs1, char_sets) Return the difference of all argument character sets. -- Scheme Procedure: char-set-xor cs ... -- C Function: scm_char_set_xor (char_sets) Return the exclusive-or of all argument character sets. -- Scheme Procedure: char-set-diff+intersection cs1 cs ... -- C Function: scm_char_set_diff_plus_intersection (cs1, char_sets) Return the difference and the intersection of all argument character sets. -- Scheme Procedure: char-set-complement! cs -- C Function: scm_char_set_complement_x (cs) Return the complement of the character set CS. -- Scheme Procedure: char-set-union! cs1 cs ... -- C Function: scm_char_set_union_x (cs1, char_sets) Return the union of all argument character sets. -- Scheme Procedure: char-set-intersection! cs1 cs ... -- C Function: scm_char_set_intersection_x (cs1, char_sets) Return the intersection of all argument character sets. -- Scheme Procedure: char-set-difference! cs1 cs ... -- C Function: scm_char_set_difference_x (cs1, char_sets) Return the difference of all argument character sets. -- Scheme Procedure: char-set-xor! cs1 cs ... -- C Function: scm_char_set_xor_x (cs1, char_sets) Return the exclusive-or of all argument character sets. -- Scheme Procedure: char-set-diff+intersection! cs1 cs2 cs ... -- C Function: scm_char_set_diff_plus_intersection_x (cs1, cs2, char_sets) Return the difference and the intersection of all argument character sets. 6.6.4.6 Standard Character Sets ............................... In order to make the use of the character set data type and procedures useful, several predefined character set variables exist. These character sets are locale independent and are not recomputed upon a ‘setlocale’ call. They contain characters from the whole range of Unicode code points. For instance, ‘char-set:letter’ contains about 100,000 characters. -- Scheme Variable: char-set:lower-case -- C Variable: scm_char_set_lower_case All lower-case characters. -- Scheme Variable: char-set:upper-case -- C Variable: scm_char_set_upper_case All upper-case characters. -- Scheme Variable: char-set:title-case -- C Variable: scm_char_set_title_case All single characters that function as if they were an upper-case letter followed by a lower-case letter. -- Scheme Variable: char-set:letter -- C Variable: scm_char_set_letter All letters. This includes ‘char-set:lower-case’, ‘char-set:upper-case’, ‘char-set:title-case’, and many letters that have no case at all. For example, Chinese and Japanese characters typically have no concept of case. -- Scheme Variable: char-set:digit -- C Variable: scm_char_set_digit All digits. -- Scheme Variable: char-set:letter+digit -- C Variable: scm_char_set_letter_and_digit The union of ‘char-set:letter’ and ‘char-set:digit’. -- Scheme Variable: char-set:graphic -- C Variable: scm_char_set_graphic All characters which would put ink on the paper. -- Scheme Variable: char-set:printing -- C Variable: scm_char_set_printing The union of ‘char-set:graphic’ and ‘char-set:whitespace’. -- Scheme Variable: char-set:whitespace -- C Variable: scm_char_set_whitespace All whitespace characters. -- Scheme Variable: char-set:blank -- C Variable: scm_char_set_blank All horizontal whitespace characters, which notably includes ‘#\space’ and ‘#\tab’. -- Scheme Variable: char-set:iso-control -- C Variable: scm_char_set_iso_control The ISO control characters are the C0 control characters (U+0000 to U+001F), delete (U+007F), and the C1 control characters (U+0080 to U+009F). -- Scheme Variable: char-set:punctuation -- C Variable: scm_char_set_punctuation All punctuation characters, such as the characters ‘!"#%&'()*,-./:;?@[\\]_{}’ -- Scheme Variable: char-set:symbol -- C Variable: scm_char_set_symbol All symbol characters, such as the characters ‘$+<=>^`|~’. -- Scheme Variable: char-set:hex-digit -- C Variable: scm_char_set_hex_digit The hexadecimal digits ‘0123456789abcdefABCDEF’. -- Scheme Variable: char-set:ascii -- C Variable: scm_char_set_ascii All ASCII characters. -- Scheme Variable: char-set:empty -- C Variable: scm_char_set_empty The empty character set. -- Scheme Variable: char-set:designated -- C Variable: scm_char_set_designated This character set contains all designated code points. This includes all the code points to which Unicode has assigned a character or other meaning. -- Scheme Variable: char-set:full -- C Variable: scm_char_set_full This character set contains all possible code points. This includes both designated and reserved code points. 6.6.5 Strings ------------- Strings are fixed-length sequences of characters. They can be created by calling constructor procedures, but they can also literally get entered at the REPL or in Scheme source files. Strings always carry the information about how many characters they are composed of with them, so there is no special end-of-string character, like in C. That means that Scheme strings can contain any character, even the ‘#\nul’ character ‘\0’. To use strings efficiently, you need to know a bit about how Guile implements them. In Guile, a string consists of two parts, a head and the actual memory where the characters are stored. When a string (or a substring of it) is copied, only a new head gets created, the memory is usually not copied. The two heads start out pointing to the same memory. When one of these two strings is modified, as with ‘string-set!’, their common memory does get copied so that each string has its own memory and modifying one does not accidentally modify the other as well. Thus, Guile's strings are 'copy on write'; the actual copying of their memory is delayed until one string is written to. This implementation makes functions like ‘substring’ very efficient in the common case that no modifications are done to the involved strings. If you do know that your strings are getting modified right away, you can use ‘substring/copy’ instead of ‘substring’. This function performs the copy immediately at the time of creation. This is more efficient, especially in a multi-threaded program. Also, ‘substring/copy’ can avoid the problem that a short substring holds on to the memory of a very large original string that could otherwise be recycled. If you want to avoid the copy altogether, so that modifications of one string show up in the other, you can use ‘substring/shared’. The strings created by this procedure are called “mutation sharing substrings” since the substring and the original string share modifications to each other. If you want to prevent modifications, use ‘substring/read-only’. Guile provides all procedures of SRFI-13 and a few more. 6.6.5.1 String Read Syntax .......................... The read syntax for strings is an arbitrarily long sequence of characters enclosed in double quotes ("). Backslash is an escape character and can be used to insert the following special characters. \" and \\ are R5RS standard, \| is R7RS standard, the next seven are R6RS standard -- notice they follow C syntax -- and the remaining four are Guile extensions. \\ Backslash character. \" Double quote character (an unescaped " is otherwise the end of the string). \| Vertical bar character. \a Bell character (ASCII 7). \f Formfeed character (ASCII 12). \n Newline character (ASCII 10). \r Carriage return character (ASCII 13). \t Tab character (ASCII 9). \v Vertical tab character (ASCII 11). \b Backspace character (ASCII 8). \0 NUL character (ASCII 0). \( Open parenthesis. This is intended for use at the beginning of lines in multiline strings to avoid confusing Emacs lisp modes. \ followed by newline (ASCII 10) Nothing. This way if \ is the last character in a line, the string will continue with the first character from the next line, without a line break. If the ‘hungry-eol-escapes’ reader option is enabled, which is not the case by default, leading whitespace on the next line is discarded. "foo\ bar" ⇒ "foo bar" (read-enable 'hungry-eol-escapes) "foo\ bar" ⇒ "foobar" \xHH Character code given by two hexadecimal digits. For example \x7f for an ASCII DEL (127). \uHHHH Character code given by four hexadecimal digits. For example \u0100 for a capital A with macron (U+0100). \UHHHHHH Character code given by six hexadecimal digits. For example \U010402. The following are examples of string literals: "foo" "bar plonk" "Hello World" "\"Hi\", he said." The three escape sequences ‘\xHH’, ‘\uHHHH’ and ‘\UHHHHHH’ were chosen to not break compatibility with code written for previous versions of Guile. The R6RS specification suggests a different, incompatible syntax for hex escapes: ‘\xHHHH;’ - a character code followed by one to eight hexadecimal digits terminated with a semicolon. If this escape format is desired instead, it can be enabled with the reader option ‘r6rs-hex-escapes’. (read-enable 'r6rs-hex-escapes) For more on reader options, *Note Scheme Read::. 6.6.5.2 String Predicates ......................... The following procedures can be used to check whether a given string fulfills some specified property. -- Scheme Procedure: string? obj -- C Function: scm_string_p (obj) Return ‘#t’ if OBJ is a string, else ‘#f’. -- C Function: int scm_is_string (SCM obj) Returns ‘1’ if OBJ is a string, ‘0’ otherwise. -- Scheme Procedure: string-null? str -- C Function: scm_string_null_p (str) Return ‘#t’ if STR's length is zero, and ‘#f’ otherwise. (string-null? "") ⇒ #t y ⇒ "foo" (string-null? y) ⇒ #f -- Scheme Procedure: string-any char_pred s [start [end]] -- C Function: scm_string_any (char_pred, s, start, end) Check if CHAR_PRED is true for any character in string S. CHAR_PRED can be a character to check for any equal to that, or a character set (*note Character Sets::) to check for any in that set, or a predicate procedure to call. For a procedure, calls ‘(CHAR_PRED c)’ are made successively on the characters from START to END. If CHAR_PRED returns true (ie. non-‘#f’), ‘string-any’ stops and that return value is the return from ‘string-any’. The call on the last character (ie. at END-1), if that point is reached, is a tail call. If there are no characters in S (ie. START equals END) then the return is ‘#f’. -- Scheme Procedure: string-every char_pred s [start [end]] -- C Function: scm_string_every (char_pred, s, start, end) Check if CHAR_PRED is true for every character in string S. CHAR_PRED can be a character to check for every character equal to that, or a character set (*note Character Sets::) to check for every character being in that set, or a predicate procedure to call. For a procedure, calls ‘(CHAR_PRED c)’ are made successively on the characters from START to END. If CHAR_PRED returns ‘#f’, ‘string-every’ stops and returns ‘#f’. The call on the last character (ie. at END-1), if that point is reached, is a tail call and the return from that call is the return from ‘string-every’. If there are no characters in S (ie. START equals END) then the return is ‘#t’. 6.6.5.3 String Constructors ........................... The string constructor procedures create new string objects, possibly initializing them with some specified character data. See also *Note String Selection::, for ways to create strings from existing strings. -- Scheme Procedure: string char... Return a newly allocated string made from the given character arguments. (string #\x #\y #\z) ⇒ "xyz" (string) ⇒ "" -- Scheme Procedure: list->string lst -- C Function: scm_string (lst) Return a newly allocated string made from a list of characters. (list->string '(#\a #\b #\c)) ⇒ "abc" -- Scheme Procedure: reverse-list->string lst -- C Function: scm_reverse_list_to_string (lst) Return a newly allocated string made from a list of characters, in reverse order. (reverse-list->string '(#\a #\B #\c)) ⇒ "cBa" -- Scheme Procedure: make-string k [chr] -- C Function: scm_make_string (k, chr) Return a newly allocated string of length K. If CHR is given, then all elements of the string are initialized to CHR, otherwise the contents of the string are unspecified. -- C Function: SCM scm_c_make_string (size_t len, SCM chr) Like ‘scm_make_string’, but expects the length as a ‘size_t’. -- Scheme Procedure: string-tabulate proc len -- C Function: scm_string_tabulate (proc, len) PROC is an integer->char procedure. Construct a string of size LEN by applying PROC to each index to produce the corresponding string element. The order in which PROC is applied to the indices is not specified. -- Scheme Procedure: string-join ls [delimiter [grammar]] -- C Function: scm_string_join (ls, delimiter, grammar) Append the string in the string list LS, using the string DELIMITER as a delimiter between the elements of LS. DELIMITER defaults to ‘ ’, that is, strings in LS are appended with the space character in between them. GRAMMAR is a symbol which specifies how the delimiter is placed between the strings, and defaults to the symbol ‘infix’. ‘infix’ Insert the separator between list elements. An empty string will produce an empty list. ‘strict-infix’ Like ‘infix’, but will raise an error if given the empty list. ‘suffix’ Insert the separator after every list element. ‘prefix’ Insert the separator before each list element. 6.6.5.4 List/String conversion .............................. When processing strings, it is often convenient to first convert them into a list representation by using the procedure ‘string->list’, work with the resulting list, and then convert it back into a string. These procedures are useful for similar tasks. -- Scheme Procedure: string->list str [start [end]] -- C Function: scm_substring_to_list (str, start, end) -- C Function: scm_string_to_list (str) Convert the string STR into a list of characters. -- Scheme Procedure: string-split str char_pred -- C Function: scm_string_split (str, char_pred) Split the string STR into a list of substrings delimited by appearances of characters that • equal CHAR_PRED, if it is a character, • satisfy the predicate CHAR_PRED, if it is a procedure, • are in the set CHAR_PRED, if it is a character set. Note that an empty substring between separator characters will result in an empty string in the result list. (string-split "root:x:0:0:root:/root:/bin/bash" #\:) ⇒ ("root" "x" "0" "0" "root" "/root" "/bin/bash") (string-split "::" #\:) ⇒ ("" "" "") (string-split "" #\:) ⇒ ("") 6.6.5.5 String Selection ........................ Portions of strings can be extracted by these procedures. ‘string-ref’ delivers individual characters whereas ‘substring’ can be used to extract substrings from longer strings. -- Scheme Procedure: string-length string -- C Function: scm_string_length (string) Return the number of characters in STRING. -- C Function: size_t scm_c_string_length (SCM str) Return the number of characters in STR as a ‘size_t’. -- Scheme Procedure: string-ref str k -- C Function: scm_string_ref (str, k) Return character K of STR using zero-origin indexing. K must be a valid index of STR. -- C Function: SCM scm_c_string_ref (SCM str, size_t k) Return character K of STR using zero-origin indexing. K must be a valid index of STR. -- Scheme Procedure: string-copy str [start [end]] -- C Function: scm_substring_copy (str, start, end) -- C Function: scm_string_copy (str) Return a copy of the given string STR. The returned string shares storage with STR initially, but it is copied as soon as one of the two strings is modified. -- Scheme Procedure: substring str start [end] -- C Function: scm_substring (str, start, end) Return a new string formed from the characters of STR beginning with index START (inclusive) and ending with index END (exclusive). STR must be a string, START and END must be exact integers satisfying: 0 <= START <= END <= ‘(string-length STR)’. The returned string shares storage with STR initially, but it is copied as soon as one of the two strings is modified. -- Scheme Procedure: substring/shared str start [end] -- C Function: scm_substring_shared (str, start, end) Like ‘substring’, but the strings continue to share their storage even if they are modified. Thus, modifications to STR show up in the new string, and vice versa. -- Scheme Procedure: substring/copy str start [end] -- C Function: scm_substring_copy (str, start, end) Like ‘substring’, but the storage for the new string is copied immediately. -- Scheme Procedure: substring/read-only str start [end] -- C Function: scm_substring_read_only (str, start, end) Like ‘substring’, but the resulting string can not be modified. -- C Function: SCM scm_c_substring (SCM str, size_t start, size_t end) -- C Function: SCM scm_c_substring_shared (SCM str, size_t start, size_t end) -- C Function: SCM scm_c_substring_copy (SCM str, size_t start, size_t end) -- C Function: SCM scm_c_substring_read_only (SCM str, size_t start, size_t end) Like ‘scm_substring’, etc. but the bounds are given as a ‘size_t’. -- Scheme Procedure: string-take s n -- C Function: scm_string_take (s, n) Return the N first characters of S. -- Scheme Procedure: string-drop s n -- C Function: scm_string_drop (s, n) Return all but the first N characters of S. -- Scheme Procedure: string-take-right s n -- C Function: scm_string_take_right (s, n) Return the N last characters of S. -- Scheme Procedure: string-drop-right s n -- C Function: scm_string_drop_right (s, n) Return all but the last N characters of S. -- Scheme Procedure: string-pad s len [chr [start [end]]] -- Scheme Procedure: string-pad-right s len [chr [start [end]]] -- C Function: scm_string_pad (s, len, chr, start, end) -- C Function: scm_string_pad_right (s, len, chr, start, end) Take characters START to END from the string S and either pad with CHR or truncate them to give LEN characters. ‘string-pad’ pads or truncates on the left, so for example (string-pad "x" 3) ⇒ " x" (string-pad "abcde" 3) ⇒ "cde" ‘string-pad-right’ pads or truncates on the right, so for example (string-pad-right "x" 3) ⇒ "x " (string-pad-right "abcde" 3) ⇒ "abc" -- Scheme Procedure: string-trim s [char_pred [start [end]]] -- Scheme Procedure: string-trim-right s [char_pred [start [end]]] -- Scheme Procedure: string-trim-both s [char_pred [start [end]]] -- C Function: scm_string_trim (s, char_pred, start, end) -- C Function: scm_string_trim_right (s, char_pred, start, end) -- C Function: scm_string_trim_both (s, char_pred, start, end) Trim occurrences of CHAR_PRED from the ends of S. ‘string-trim’ trims CHAR_PRED characters from the left (start) of the string, ‘string-trim-right’ trims them from the right (end) of the string, ‘string-trim-both’ trims from both ends. CHAR_PRED can be a character, a character set, or a predicate procedure to call on each character. If CHAR_PRED is not given the default is whitespace as per ‘char-set:whitespace’ (*note Standard Character Sets::). (string-trim " x ") ⇒ "x " (string-trim-right "banana" #\a) ⇒ "banan" (string-trim-both ".,xy:;" char-set:punctuation) ⇒ "xy" (string-trim-both "xyzzy" (lambda (c) (or (eqv? c #\x) (eqv? c #\y)))) ⇒ "zz" 6.6.5.6 String Modification ........................... These procedures are for modifying strings in-place. This means that the result of the operation is not a new string; instead, the original string's memory representation is modified. -- Scheme Procedure: string-set! str k chr -- C Function: scm_string_set_x (str, k, chr) Store CHR in element K of STR and return an unspecified value. K must be a valid index of STR. -- C Function: void scm_c_string_set_x (SCM str, size_t k, SCM chr) Like ‘scm_string_set_x’, but the index is given as a ‘size_t’. -- Scheme Procedure: string-fill! str chr [start [end]] -- C Function: scm_substring_fill_x (str, chr, start, end) -- C Function: scm_string_fill_x (str, chr) Stores CHR in every element of the given STR and returns an unspecified value. -- Scheme Procedure: substring-fill! str start end fill -- C Function: scm_substring_fill_x (str, start, end, fill) Change every character in STR between START and END to FILL. (define y (string-copy "abcdefg")) (substring-fill! y 1 3 #\r) y ⇒ "arrdefg" -- Scheme Procedure: substring-move! str1 start1 end1 str2 start2 -- C Function: scm_substring_move_x (str1, start1, end1, str2, start2) Copy the substring of STR1 bounded by START1 and END1 into STR2 beginning at position START2. STR1 and STR2 can be the same string. -- Scheme Procedure: string-copy! target tstart s [start [end]] -- C Function: scm_string_copy_x (target, tstart, s, start, end) Copy the sequence of characters from index range [START, END) in string S to string TARGET, beginning at index TSTART. The characters are copied left-to-right or right-to-left as needed - the copy is guaranteed to work, even if TARGET and S are the same string. It is an error if the copy operation runs off the end of the target string. 6.6.5.7 String Comparison ......................... The procedures in this section are similar to the character ordering predicates (*note Characters::), but are defined on character sequences. The first set is specified in R5RS and has names that end in ‘?’. The second set is specified in SRFI-13 and the names have not ending ‘?’. The predicates ending in ‘-ci’ ignore the character case when comparing strings. For now, case-insensitive comparison is done using the R5RS rules, where every lower-case character that has a single character upper-case form is converted to uppercase before comparison. See *Note the ‘(ice-9 i18n)’ module: Text Collation, for locale-dependent string comparison. -- Scheme Procedure: string=? s1 s2 s3 ... Lexicographic equality predicate; return ‘#t’ if all strings are the same length and contain the same characters in the same positions, otherwise return ‘#f’. The procedure ‘string-ci=?’ treats upper and lower case letters as though they were the same character, but ‘string=?’ treats upper and lower case as distinct characters. -- Scheme Procedure: string? s1 s2 s3 ... Lexicographic ordering predicate; return ‘#t’ if, for every pair of consecutive string arguments STR_I and STR_I+1, STR_I is lexicographically greater than STR_I+1. -- Scheme Procedure: string>=? s1 s2 s3 ... Lexicographic ordering predicate; return ‘#t’ if, for every pair of consecutive string arguments STR_I and STR_I+1, STR_I is lexicographically greater than or equal to STR_I+1. -- Scheme Procedure: string-ci=? s1 s2 s3 ... Case-insensitive string equality predicate; return ‘#t’ if all strings are the same length and their component characters match (ignoring case) at each position; otherwise return ‘#f’. -- Scheme Procedure: string-ci? s1 s2 s3 ... Case insensitive lexicographic ordering predicate; return ‘#t’ if, for every pair of consecutive string arguments STR_I and STR_I+1, STR_I is lexicographically greater than STR_I+1 regardless of case. -- Scheme Procedure: string-ci>=? s1 s2 s3 ... Case insensitive lexicographic ordering predicate; return ‘#t’ if, for every pair of consecutive string arguments STR_I and STR_I+1, STR_I is lexicographically greater than or equal to STR_I+1 regardless of case. -- Scheme Procedure: string-compare s1 s2 proc_lt proc_eq proc_gt [start1 [end1 [start2 [end2]]]] -- C Function: scm_string_compare (s1, s2, proc_lt, proc_eq, proc_gt, start1, end1, start2, end2) Apply PROC_LT, PROC_EQ, PROC_GT to the mismatch index, depending upon whether S1 is less than, equal to, or greater than S2. The mismatch index is the largest index I such that for every 0 <= J < I, S1[J] = S2[J] - that is, I is the first position that does not match. -- Scheme Procedure: string-compare-ci s1 s2 proc_lt proc_eq proc_gt [start1 [end1 [start2 [end2]]]] -- C Function: scm_string_compare_ci (s1, s2, proc_lt, proc_eq, proc_gt, start1, end1, start2, end2) Apply PROC_LT, PROC_EQ, PROC_GT to the mismatch index, depending upon whether S1 is less than, equal to, or greater than S2. The mismatch index is the largest index I such that for every 0 <= J < I, S1[J] = S2[J] - that is, I is the first position where the lowercased letters do not match. -- Scheme Procedure: string= s1 s2 [start1 [end1 [start2 [end2]]]] -- C Function: scm_string_eq (s1, s2, start1, end1, start2, end2) Return ‘#f’ if S1 and S2 are not equal, a true value otherwise. -- Scheme Procedure: string<> s1 s2 [start1 [end1 [start2 [end2]]]] -- C Function: scm_string_neq (s1, s2, start1, end1, start2, end2) Return ‘#f’ if S1 and S2 are equal, a true value otherwise. -- Scheme Procedure: string< s1 s2 [start1 [end1 [start2 [end2]]]] -- C Function: scm_string_lt (s1, s2, start1, end1, start2, end2) Return ‘#f’ if S1 is greater or equal to S2, a true value otherwise. -- Scheme Procedure: string> s1 s2 [start1 [end1 [start2 [end2]]]] -- C Function: scm_string_gt (s1, s2, start1, end1, start2, end2) Return ‘#f’ if S1 is less or equal to S2, a true value otherwise. -- Scheme Procedure: string<= s1 s2 [start1 [end1 [start2 [end2]]]] -- C Function: scm_string_le (s1, s2, start1, end1, start2, end2) Return ‘#f’ if S1 is greater to S2, a true value otherwise. -- Scheme Procedure: string>= s1 s2 [start1 [end1 [start2 [end2]]]] -- C Function: scm_string_ge (s1, s2, start1, end1, start2, end2) Return ‘#f’ if S1 is less to S2, a true value otherwise. -- Scheme Procedure: string-ci= s1 s2 [start1 [end1 [start2 [end2]]]] -- C Function: scm_string_ci_eq (s1, s2, start1, end1, start2, end2) Return ‘#f’ if S1 and S2 are not equal, a true value otherwise. The character comparison is done case-insensitively. -- Scheme Procedure: string-ci<> s1 s2 [start1 [end1 [start2 [end2]]]] -- C Function: scm_string_ci_neq (s1, s2, start1, end1, start2, end2) Return ‘#f’ if S1 and S2 are equal, a true value otherwise. The character comparison is done case-insensitively. -- Scheme Procedure: string-ci< s1 s2 [start1 [end1 [start2 [end2]]]] -- C Function: scm_string_ci_lt (s1, s2, start1, end1, start2, end2) Return ‘#f’ if S1 is greater or equal to S2, a true value otherwise. The character comparison is done case-insensitively. -- Scheme Procedure: string-ci> s1 s2 [start1 [end1 [start2 [end2]]]] -- C Function: scm_string_ci_gt (s1, s2, start1, end1, start2, end2) Return ‘#f’ if S1 is less or equal to S2, a true value otherwise. The character comparison is done case-insensitively. -- Scheme Procedure: string-ci<= s1 s2 [start1 [end1 [start2 [end2]]]] -- C Function: scm_string_ci_le (s1, s2, start1, end1, start2, end2) Return ‘#f’ if S1 is greater to S2, a true value otherwise. The character comparison is done case-insensitively. -- Scheme Procedure: string-ci>= s1 s2 [start1 [end1 [start2 [end2]]]] -- C Function: scm_string_ci_ge (s1, s2, start1, end1, start2, end2) Return ‘#f’ if S1 is less to S2, a true value otherwise. The character comparison is done case-insensitively. -- Scheme Procedure: string-hash s [bound [start [end]]] -- C Function: scm_substring_hash (s, bound, start, end) Compute a hash value for S. The optional argument BOUND is a non-negative exact integer specifying the range of the hash function. A positive value restricts the return value to the range [0,bound). -- Scheme Procedure: string-hash-ci s [bound [start [end]]] -- C Function: scm_substring_hash_ci (s, bound, start, end) Compute a hash value for S. The optional argument BOUND is a non-negative exact integer specifying the range of the hash function. A positive value restricts the return value to the range [0,bound). Because the same visual appearance of an abstract Unicode character can be obtained via multiple sequences of Unicode characters, even the case-insensitive string comparison functions described above may return ‘#f’ when presented with strings containing different representations of the same character. For example, the Unicode character "LATIN SMALL LETTER S WITH DOT BELOW AND DOT ABOVE" can be represented with a single character (U+1E69) or by the character "LATIN SMALL LETTER S" (U+0073) followed by the combining marks "COMBINING DOT BELOW" (U+0323) and "COMBINING DOT ABOVE" (U+0307). For this reason, it is often desirable to ensure that the strings to be compared are using a mutually consistent representation for every character. The Unicode standard defines two methods of normalizing the contents of strings: Decomposition, which breaks composite characters into a set of constituent characters with an ordering defined by the Unicode Standard; and composition, which performs the converse. There are two decomposition operations. "Canonical decomposition" produces character sequences that share the same visual appearance as the original characters, while "compatibility decomposition" produces ones whose visual appearances may differ from the originals but which represent the same abstract character. These operations are encapsulated in the following set of normalization forms: “NFD” Characters are decomposed to their canonical forms. “NFKD” Characters are decomposed to their compatibility forms. “NFC” Characters are decomposed to their canonical forms, then composed. “NFKC” Characters are decomposed to their compatibility forms, then composed. The functions below put their arguments into one of the forms described above. -- Scheme Procedure: string-normalize-nfd s -- C Function: scm_string_normalize_nfd (s) Return the ‘NFD’ normalized form of S. -- Scheme Procedure: string-normalize-nfkd s -- C Function: scm_string_normalize_nfkd (s) Return the ‘NFKD’ normalized form of S. -- Scheme Procedure: string-normalize-nfc s -- C Function: scm_string_normalize_nfc (s) Return the ‘NFC’ normalized form of S. -- Scheme Procedure: string-normalize-nfkc s -- C Function: scm_string_normalize_nfkc (s) Return the ‘NFKC’ normalized form of S. 6.6.5.8 String Searching ........................ -- Scheme Procedure: string-index s char_pred [start [end]] -- C Function: scm_string_index (s, char_pred, start, end) Search through the string S from left to right, returning the index of the first occurrence of a character which • equals CHAR_PRED, if it is character, • satisfies the predicate CHAR_PRED, if it is a procedure, • is in the set CHAR_PRED, if it is a character set. Return ‘#f’ if no match is found. -- Scheme Procedure: string-rindex s char_pred [start [end]] -- C Function: scm_string_rindex (s, char_pred, start, end) Search through the string S from right to left, returning the index of the last occurrence of a character which • equals CHAR_PRED, if it is character, • satisfies the predicate CHAR_PRED, if it is a procedure, • is in the set if CHAR_PRED is a character set. Return ‘#f’ if no match is found. -- Scheme Procedure: string-prefix-length s1 s2 [start1 [end1 [start2 [end2]]]] -- C Function: scm_string_prefix_length (s1, s2, start1, end1, start2, end2) Return the length of the longest common prefix of the two strings. -- Scheme Procedure: string-prefix-length-ci s1 s2 [start1 [end1 [start2 [end2]]]] -- C Function: scm_string_prefix_length_ci (s1, s2, start1, end1, start2, end2) Return the length of the longest common prefix of the two strings, ignoring character case. -- Scheme Procedure: string-suffix-length s1 s2 [start1 [end1 [start2 [end2]]]] -- C Function: scm_string_suffix_length (s1, s2, start1, end1, start2, end2) Return the length of the longest common suffix of the two strings. -- Scheme Procedure: string-suffix-length-ci s1 s2 [start1 [end1 [start2 [end2]]]] -- C Function: scm_string_suffix_length_ci (s1, s2, start1, end1, start2, end2) Return the length of the longest common suffix of the two strings, ignoring character case. -- Scheme Procedure: string-prefix? s1 s2 [start1 [end1 [start2 [end2]]]] -- C Function: scm_string_prefix_p (s1, s2, start1, end1, start2, end2) Is S1 a prefix of S2? -- Scheme Procedure: string-prefix-ci? s1 s2 [start1 [end1 [start2 [end2]]]] -- C Function: scm_string_prefix_ci_p (s1, s2, start1, end1, start2, end2) Is S1 a prefix of S2, ignoring character case? -- Scheme Procedure: string-suffix? s1 s2 [start1 [end1 [start2 [end2]]]] -- C Function: scm_string_suffix_p (s1, s2, start1, end1, start2, end2) Is S1 a suffix of S2? -- Scheme Procedure: string-suffix-ci? s1 s2 [start1 [end1 [start2 [end2]]]] -- C Function: scm_string_suffix_ci_p (s1, s2, start1, end1, start2, end2) Is S1 a suffix of S2, ignoring character case? -- Scheme Procedure: string-index-right s char_pred [start [end]] -- C Function: scm_string_index_right (s, char_pred, start, end) Search through the string S from right to left, returning the index of the last occurrence of a character which • equals CHAR_PRED, if it is character, • satisfies the predicate CHAR_PRED, if it is a procedure, • is in the set if CHAR_PRED is a character set. Return ‘#f’ if no match is found. -- Scheme Procedure: string-skip s char_pred [start [end]] -- C Function: scm_string_skip (s, char_pred, start, end) Search through the string S from left to right, returning the index of the first occurrence of a character which • does not equal CHAR_PRED, if it is character, • does not satisfy the predicate CHAR_PRED, if it is a procedure, • is not in the set if CHAR_PRED is a character set. -- Scheme Procedure: string-skip-right s char_pred [start [end]] -- C Function: scm_string_skip_right (s, char_pred, start, end) Search through the string S from right to left, returning the index of the last occurrence of a character which • does not equal CHAR_PRED, if it is character, • does not satisfy the predicate CHAR_PRED, if it is a procedure, • is not in the set if CHAR_PRED is a character set. -- Scheme Procedure: string-count s char_pred [start [end]] -- C Function: scm_string_count (s, char_pred, start, end) Return the count of the number of characters in the string S which • equals CHAR_PRED, if it is character, • satisfies the predicate CHAR_PRED, if it is a procedure. • is in the set CHAR_PRED, if it is a character set. -- Scheme Procedure: string-contains s1 s2 [start1 [end1 [start2 [end2]]]] -- C Function: scm_string_contains (s1, s2, start1, end1, start2, end2) Does string S1 contain string S2? Return the index in S1 where S2 occurs as a substring, or false. The optional start/end indices restrict the operation to the indicated substrings. -- Scheme Procedure: string-contains-ci s1 s2 [start1 [end1 [start2 [end2]]]] -- C Function: scm_string_contains_ci (s1, s2, start1, end1, start2, end2) Does string S1 contain string S2? Return the index in S1 where S2 occurs as a substring, or false. The optional start/end indices restrict the operation to the indicated substrings. Character comparison is done case-insensitively. 6.6.5.9 Alphabetic Case Mapping ............................... These are procedures for mapping strings to their upper- or lower-case equivalents, respectively, or for capitalizing strings. They use the basic case mapping rules for Unicode characters. No special language or context rules are considered. The resulting strings are guaranteed to be the same length as the input strings. *Note the ‘(ice-9 i18n)’ module: Character Case Mapping, for locale-dependent case conversions. -- Scheme Procedure: string-upcase str [start [end]] -- C Function: scm_substring_upcase (str, start, end) -- C Function: scm_string_upcase (str) Upcase every character in ‘str’. -- Scheme Procedure: string-upcase! str [start [end]] -- C Function: scm_substring_upcase_x (str, start, end) -- C Function: scm_string_upcase_x (str) Destructively upcase every character in ‘str’. (string-upcase! y) ⇒ "ARRDEFG" y ⇒ "ARRDEFG" -- Scheme Procedure: string-downcase str [start [end]] -- C Function: scm_substring_downcase (str, start, end) -- C Function: scm_string_downcase (str) Downcase every character in STR. -- Scheme Procedure: string-downcase! str [start [end]] -- C Function: scm_substring_downcase_x (str, start, end) -- C Function: scm_string_downcase_x (str) Destructively downcase every character in STR. y ⇒ "ARRDEFG" (string-downcase! y) ⇒ "arrdefg" y ⇒ "arrdefg" -- Scheme Procedure: string-capitalize str -- C Function: scm_string_capitalize (str) Return a freshly allocated string with the characters in STR, where the first character of every word is capitalized. -- Scheme Procedure: string-capitalize! str -- C Function: scm_string_capitalize_x (str) Upcase the first character of every word in STR destructively and return STR. y ⇒ "hello world" (string-capitalize! y) ⇒ "Hello World" y ⇒ "Hello World" -- Scheme Procedure: string-titlecase str [start [end]] -- C Function: scm_string_titlecase (str, start, end) Titlecase every first character in a word in STR. -- Scheme Procedure: string-titlecase! str [start [end]] -- C Function: scm_string_titlecase_x (str, start, end) Destructively titlecase every first character in a word in STR. 6.6.5.10 Reversing and Appending Strings ........................................ -- Scheme Procedure: string-reverse str [start [end]] -- C Function: scm_string_reverse (str, start, end) Reverse the string STR. The optional arguments START and END delimit the region of STR to operate on. -- Scheme Procedure: string-reverse! str [start [end]] -- C Function: scm_string_reverse_x (str, start, end) Reverse the string STR in-place. The optional arguments START and END delimit the region of STR to operate on. The return value is unspecified. -- Scheme Procedure: string-append arg ... -- C Function: scm_string_append (args) Return a newly allocated string whose characters form the concatenation of the given strings, ARG .... (let ((h "hello ")) (string-append h "world")) ⇒ "hello world" -- Scheme Procedure: string-append/shared arg ... -- C Function: scm_string_append_shared (args) Like ‘string-append’, but the result may share memory with the argument strings. -- Scheme Procedure: string-concatenate ls -- C Function: scm_string_concatenate (ls) Append the elements (which must be strings) of LS together into a single string. Guaranteed to return a freshly allocated string. -- Scheme Procedure: string-concatenate-reverse ls [final_string [end]] -- C Function: scm_string_concatenate_reverse (ls, final_string, end) Without optional arguments, this procedure is equivalent to (string-concatenate (reverse ls)) If the optional argument FINAL_STRING is specified, it is consed onto the beginning to LS before performing the list-reverse and string-concatenate operations. If END is given, only the characters of FINAL_STRING up to index END are used. Guaranteed to return a freshly allocated string. -- Scheme Procedure: string-concatenate/shared ls -- C Function: scm_string_concatenate_shared (ls) Like ‘string-concatenate’, but the result may share memory with the strings in the list LS. -- Scheme Procedure: string-concatenate-reverse/shared ls [final_string [end]] -- C Function: scm_string_concatenate_reverse_shared (ls, final_string, end) Like ‘string-concatenate-reverse’, but the result may share memory with the strings in the LS arguments. 6.6.5.11 Mapping, Folding, and Unfolding ........................................ -- Scheme Procedure: string-map proc s [start [end]] -- C Function: scm_string_map (proc, s, start, end) PROC is a char->char procedure, it is mapped over S. The order in which the procedure is applied to the string elements is not specified. -- Scheme Procedure: string-map! proc s [start [end]] -- C Function: scm_string_map_x (proc, s, start, end) PROC is a char->char procedure, it is mapped over S. The order in which the procedure is applied to the string elements is not specified. The string S is modified in-place, the return value is not specified. -- Scheme Procedure: string-for-each proc s [start [end]] -- C Function: scm_string_for_each (proc, s, start, end) PROC is mapped over S in left-to-right order. The return value is not specified. -- Scheme Procedure: string-for-each-index proc s [start [end]] -- C Function: scm_string_for_each_index (proc, s, start, end) Call ‘(PROC i)’ for each index i in S, from left to right. For example, to change characters to alternately upper and lower case, (define str (string-copy "studly")) (string-for-each-index (lambda (i) (string-set! str i ((if (even? i) char-upcase char-downcase) (string-ref str i)))) str) str ⇒ "StUdLy" -- Scheme Procedure: string-fold kons knil s [start [end]] -- C Function: scm_string_fold (kons, knil, s, start, end) Fold KONS over the characters of S, with KNIL as the terminating element, from left to right. KONS must expect two arguments: The actual character and the last result of KONS' application. -- Scheme Procedure: string-fold-right kons knil s [start [end]] -- C Function: scm_string_fold_right (kons, knil, s, start, end) Fold KONS over the characters of S, with KNIL as the terminating element, from right to left. KONS must expect two arguments: The actual character and the last result of KONS' application. -- Scheme Procedure: string-unfold p f g seed [base [make_final]] -- C Function: scm_string_unfold (p, f, g, seed, base, make_final) • G is used to generate a series of _seed_ values from the initial SEED: SEED, (G SEED), (G^2 SEED), (G^3 SEED), ... • P tells us when to stop - when it returns true when applied to one of these seed values. • F maps each seed value to the corresponding character in the result string. These chars are assembled into the string in a left-to-right order. • BASE is the optional initial/leftmost portion of the constructed string; it default to the empty string. • MAKE_FINAL is applied to the terminal seed value (on which P returns true) to produce the final/rightmost portion of the constructed string. The default is nothing extra. -- Scheme Procedure: string-unfold-right p f g seed [base [make_final]] -- C Function: scm_string_unfold_right (p, f, g, seed, base, make_final) • G is used to generate a series of _seed_ values from the initial SEED: SEED, (G SEED), (G^2 SEED), (G^3 SEED), ... • P tells us when to stop - when it returns true when applied to one of these seed values. • F maps each seed value to the corresponding character in the result string. These chars are assembled into the string in a right-to-left order. • BASE is the optional initial/rightmost portion of the constructed string; it default to the empty string. • MAKE_FINAL is applied to the terminal seed value (on which P returns true) to produce the final/leftmost portion of the constructed string. It defaults to ‘(lambda (x) )’. 6.6.5.12 Miscellaneous String Operations ........................................ -- Scheme Procedure: xsubstring s from [to [start [end]]] -- C Function: scm_xsubstring (s, from, to, start, end) This is the _extended substring_ procedure that implements replicated copying of a substring of some string. S is a string, START and END are optional arguments that demarcate a substring of S, defaulting to 0 and the length of S. Replicate this substring up and down index space, in both the positive and negative directions. ‘xsubstring’ returns the substring of this string beginning at index FROM, and ending at TO, which defaults to FROM + (END - START). -- Scheme Procedure: string-xcopy! target tstart s sfrom [sto [start [end]]] -- C Function: scm_string_xcopy_x (target, tstart, s, sfrom, sto, start, end) Exactly the same as ‘xsubstring’, but the extracted text is written into the string TARGET starting at index TSTART. The operation is not defined if ‘(eq? TARGET S)’ or these arguments share storage - you cannot copy a string on top of itself. -- Scheme Procedure: string-replace s1 s2 [start1 [end1 [start2 [end2]]]] -- C Function: scm_string_replace (s1, s2, start1, end1, start2, end2) Return the string S1, but with the characters START1 ... END1 replaced by the characters START2 ... END2 from S2. -- Scheme Procedure: string-tokenize s [token_set [start [end]]] -- C Function: scm_string_tokenize (s, token_set, start, end) Split the string S into a list of substrings, where each substring is a maximal non-empty contiguous sequence of characters from the character set TOKEN_SET, which defaults to ‘char-set:graphic’. If START or END indices are provided, they restrict ‘string-tokenize’ to operating on the indicated substring of S. -- Scheme Procedure: string-filter char_pred s [start [end]] -- C Function: scm_string_filter (char_pred, s, start, end) Filter the string S, retaining only those characters which satisfy CHAR_PRED. If CHAR_PRED is a procedure, it is applied to each character as a predicate, if it is a character, it is tested for equality and if it is a character set, it is tested for membership. -- Scheme Procedure: string-delete char_pred s [start [end]] -- C Function: scm_string_delete (char_pred, s, start, end) Delete characters satisfying CHAR_PRED from S. If CHAR_PRED is a procedure, it is applied to each character as a predicate, if it is a character, it is tested for equality and if it is a character set, it is tested for membership. The following additional functions are available in the module ‘(ice-9 string-fun)’. They can be used with: (use-modules (ice-9 string-fun)) -- Scheme Procedure: string-replace-substring str substring replacement Return a new string where every instance of SUBSTRING in string STR has been replaced by REPLACEMENT. For example: (string-replace-substring "a ring of strings" "ring" "rut") ⇒ "a rut of struts" 6.6.5.13 Representing Strings as Bytes ...................................... In the cold world outside of Guile, not all strings are treated in the same way. Out there there are only bytes, and there are many ways of representing a strings (sequences of characters) as binary data (sequences of bytes). As a user, usually you don't have to think about this very much. When you type on your keyboard, your system encodes your keystrokes as bytes according to the locale that you have configured on your computer. Guile uses the locale to decode those bytes back into characters - hopefully the same characters that you typed in. All is not so clear when dealing with a system with multiple users, such as a web server. Your web server might get a request from one user for data encoded in the ISO-8859-1 character set, and then another request from a different user for UTF-8 data. Guile provides an “iconv” module for converting between strings and sequences of bytes. *Note Bytevectors::, for more on how Guile represents raw byte sequences. This module gets its name from the common UNIX command of the same name. Note that often it is sufficient to just read and write strings from ports instead of using these functions. To do this, specify the port encoding using ‘set-port-encoding!’. *Note Ports::, for more on ports and character encodings. Unlike the rest of the procedures in this section, you have to load the ‘iconv’ module before having access to these procedures: (use-modules (ice-9 iconv)) -- Scheme Procedure: string->bytevector string encoding [conversion-strategy] Encode STRING as a sequence of bytes. The string will be encoded in the character set specified by the ENCODING string. If the string has characters that cannot be represented in the encoding, by default this procedure raises an ‘encoding-error’. Pass a CONVERSION-STRATEGY argument to specify other behaviors. The return value is a bytevector. *Note Bytevectors::, for more on bytevectors. *Note Ports::, for more on character encodings and conversion strategies. -- Scheme Procedure: bytevector->string bytevector encoding [conversion-strategy] Decode BYTEVECTOR into a string. The bytes will be decoded from the character set by the ENCODING string. If the bytes do not form a valid encoding, by default this procedure raises an ‘decoding-error’. As with ‘string->bytevector’, pass the optional CONVERSION-STRATEGY argument to modify this behavior. *Note Ports::, for more on character encodings and conversion strategies. -- Scheme Procedure: call-with-output-encoded-string encoding proc [conversion-strategy] Like ‘call-with-output-string’, but instead of returning a string, returns a encoding of the string according to ENCODING, as a bytevector. This procedure can be more efficient than collecting a string and then converting it via ‘string->bytevector’. 6.6.5.14 Conversion to/from C ............................. When creating a Scheme string from a C string or when converting a Scheme string to a C string, the concept of character encoding becomes important. In C, a string is just a sequence of bytes, and the character encoding describes the relation between these bytes and the actual characters that make up the string. For Scheme strings, character encoding is not an issue (most of the time), since in Scheme you usually treat strings as character sequences, not byte sequences. Converting to C and converting from C each have their own challenges. When converting from C to Scheme, it is important that the sequence of bytes in the C string be valid with respect to its encoding. ASCII strings, for example, can't have any bytes greater than 127. An ASCII byte greater than 127 is considered _ill-formed_ and cannot be converted into a Scheme character. Problems can occur in the reverse operation as well. Not all character encodings can hold all possible Scheme characters. Some encodings, like ASCII for example, can only describe a small subset of all possible characters. So, when converting to C, one must first decide what to do with Scheme characters that can't be represented in the C string. Converting a Scheme string to a C string will often allocate fresh memory to hold the result. You must take care that this memory is properly freed eventually. In many cases, this can be achieved by using ‘scm_dynwind_free’ inside an appropriate dynwind context, *Note Dynamic Wind::. -- C Function: SCM scm_from_locale_string (const char *str) -- C Function: SCM scm_from_locale_stringn (const char *str, size_t len) Creates a new Scheme string that has the same contents as STR when interpreted in the character encoding of the current locale. For ‘scm_from_locale_string’, STR must be null-terminated. For ‘scm_from_locale_stringn’, LEN specifies the length of STR in bytes, and STR does not need to be null-terminated. If LEN is ‘(size_t)-1’, then STR does need to be null-terminated and the real length will be found with ‘strlen’. If the C string is ill-formed, an error will be raised. Note that these functions should _not_ be used to convert C string constants, because there is no guarantee that the current locale will match that of the execution character set, used for string and character constants. Most modern C compilers use UTF-8 by default, so to convert C string constants we recommend ‘scm_from_utf8_string’. -- C Function: SCM scm_take_locale_string (char *str) -- C Function: SCM scm_take_locale_stringn (char *str, size_t len) Like ‘scm_from_locale_string’ and ‘scm_from_locale_stringn’, respectively, but also frees STR with ‘free’ eventually. Thus, you can use this function when you would free STR anyway immediately after creating the Scheme string. In certain cases, Guile can then use STR directly as its internal representation. -- C Function: char * scm_to_locale_string (SCM str) -- C Function: char * scm_to_locale_stringn (SCM str, size_t *lenp) Returns a C string with the same contents as STR in the character encoding of the current locale. The C string must be freed with ‘free’ eventually, maybe by using ‘scm_dynwind_free’, *Note Dynamic Wind::. For ‘scm_to_locale_string’, the returned string is null-terminated and an error is signaled when STR contains ‘#\nul’ characters. For ‘scm_to_locale_stringn’ and LENP not ‘NULL’, STR might contain ‘#\nul’ characters and the length of the returned string in bytes is stored in ‘*LENP’. The returned string will not be null-terminated in this case. If LENP is ‘NULL’, ‘scm_to_locale_stringn’ behaves like ‘scm_to_locale_string’. If a character in STR cannot be represented in the character encoding of the current locale, the default port conversion strategy is used. *Note Ports::, for more on conversion strategies. If the conversion strategy is ‘error’, an error will be raised. If it is ‘substitute’, a replacement character, such as a question mark, will be inserted in its place. If it is ‘escape’, a hex escape will be inserted in its place. -- C Function: size_t scm_to_locale_stringbuf (SCM str, char *buf, size_t max_len) Puts STR as a C string in the current locale encoding into the memory pointed to by BUF. The buffer at BUF has room for MAX_LEN bytes and ‘scm_to_local_stringbuf’ will never store more than that. No terminating ‘'\0'’ will be stored. The return value of ‘scm_to_locale_stringbuf’ is the number of bytes that are needed for all of STR, regardless of whether BUF was large enough to hold them. Thus, when the return value is larger than MAX_LEN, only MAX_LEN bytes have been stored and you probably need to try again with a larger buffer. For most situations, string conversion should occur using the current locale, such as with the functions above. But there may be cases where one wants to convert strings from a character encoding other than the locale's character encoding. For these cases, the lower-level functions ‘scm_to_stringn’ and ‘scm_from_stringn’ are provided. These functions should seldom be necessary if one is properly using locales. -- C Type: scm_t_string_failed_conversion_handler This is an enumerated type that can take one of three values: ‘SCM_FAILED_CONVERSION_ERROR’, ‘SCM_FAILED_CONVERSION_QUESTION_MARK’, and ‘SCM_FAILED_CONVERSION_ESCAPE_SEQUENCE’. They are used to indicate a strategy for handling characters that cannot be converted to or from a given character encoding. ‘SCM_FAILED_CONVERSION_ERROR’ indicates that a conversion should throw an error if some characters cannot be converted. ‘SCM_FAILED_CONVERSION_QUESTION_MARK’ indicates that a conversion should replace unconvertable characters with the question mark character. And, ‘SCM_FAILED_CONVERSION_ESCAPE_SEQUENCE’ requests that a conversion should replace an unconvertable character with an escape sequence. While all three strategies apply when converting Scheme strings to C, only ‘SCM_FAILED_CONVERSION_ERROR’ and ‘SCM_FAILED_CONVERSION_QUESTION_MARK’ can be used when converting C strings to Scheme. -- C Function: char *scm_to_stringn (SCM str, size_t *lenp, const char *encoding, scm_t_string_failed_conversion_handler handler) This function returns a newly allocated C string from the Guile string STR. The length of the returned string in bytes will be returned in LENP. The character encoding of the C string is passed as the ASCII, null-terminated C string ENCODING. The HANDLER parameter gives a strategy for dealing with characters that cannot be converted into ENCODING. If LENP is ‘NULL’, this function will return a null-terminated C string. It will throw an error if the string contains a null character. The Scheme interface to this function is ‘string->bytevector’, from the ‘ice-9 iconv’ module. *Note Representing Strings as Bytes::. -- C Function: SCM scm_from_stringn (const char *str, size_t len, const char *encoding, scm_t_string_failed_conversion_handler handler) This function returns a scheme string from the C string STR. The length in bytes of the C string is input as LEN. The encoding of the C string is passed as the ASCII, null-terminated C string ‘encoding’. The HANDLER parameters suggests a strategy for dealing with unconvertable characters. The Scheme interface to this function is ‘bytevector->string’. *Note Representing Strings as Bytes::. The following conversion functions are provided as a convenience for the most commonly used encodings. -- C Function: SCM scm_from_latin1_string (const char *str) -- C Function: SCM scm_from_utf8_string (const char *str) -- C Function: SCM scm_from_utf32_string (const scm_t_wchar *str) Return a scheme string from the null-terminated C string STR, which is ISO-8859-1-, UTF-8-, or UTF-32-encoded. These functions should be used to convert hard-coded C string constants into Scheme strings. -- C Function: SCM scm_from_latin1_stringn (const char *str, size_t len) -- C Function: SCM scm_from_utf8_stringn (const char *str, size_t len) -- C Function: SCM scm_from_utf32_stringn (const scm_t_wchar *str, size_t len) Return a scheme string from C string STR, which is ISO-8859-1-, UTF-8-, or UTF-32-encoded, of length LEN. LEN is the number of bytes pointed to by STR for ‘scm_from_latin1_stringn’ and ‘scm_from_utf8_stringn’; it is the number of elements (code points) in STR in the case of ‘scm_from_utf32_stringn’. -- C function: char *scm_to_latin1_stringn (SCM str, size_t *lenp) -- C function: char *scm_to_utf8_stringn (SCM str, size_t *lenp) -- C function: scm_t_wchar *scm_to_utf32_stringn (SCM str, size_t *lenp) Return a newly allocated, ISO-8859-1-, UTF-8-, or UTF-32-encoded C string from Scheme string STR. An error is thrown when STR cannot be converted to the specified encoding. If LENP is ‘NULL’, the returned C string will be null terminated, and an error will be thrown if the C string would otherwise contain null characters. If LENP is not ‘NULL’, the string is not null terminated, and the length of the returned string is returned in LENP. The length returned is the number of bytes for ‘scm_to_latin1_stringn’ and ‘scm_to_utf8_stringn’; it is the number of elements (code points) for ‘scm_to_utf32_stringn’. It is not often the case, but sometimes when you are dealing with the implementation details of a port, you need to encode and decode strings according to the encoding and conversion strategy of the port. There are some convenience functions for that purpose as well. -- C Function: SCM scm_from_port_string (const char *str, SCM port) -- C Function: SCM scm_from_port_stringn (const char *str, size_t len, SCM port) -- C Function: char* scm_to_port_string (SCM str, SCM port) -- C Function: char* scm_to_port_stringn (SCM str, size_t *lenp, SCM port) Like ‘scm_from_stringn’ and friends, except they take their encoding and conversion strategy from a given port object. 6.6.5.15 String Internals ......................... Guile stores each string in memory as a contiguous array of Unicode code points along with an associated set of attributes. If all of the code points of a string have an integer range between 0 and 255 inclusive, the code point array is stored as one byte per code point: it is stored as an ISO-8859-1 (aka Latin-1) string. If any of the code points of the string has an integer value greater that 255, the code point array is stored as four bytes per code point: it is stored as a UTF-32 string. Conversion between the one-byte-per-code-point and four-bytes-per-code-point representations happens automatically as necessary. No API is provided to set the internal representation of strings; however, there are pair of procedures available to query it. These are debugging procedures. Using them in production code is discouraged, since the details of Guile's internal representation of strings may change from release to release. -- Scheme Procedure: string-bytes-per-char str -- C Function: scm_string_bytes_per_char (str) Return the number of bytes used to encode a Unicode code point in string STR. The result is one or four. -- Scheme Procedure: %string-dump str -- C Function: scm_sys_string_dump (str) Returns an association list containing debugging information for STR. The association list has the following entries. ‘string’ The string itself. ‘start’ The start index of the string into its stringbuf ‘length’ The length of the string ‘shared’ If this string is a substring, it returns its parent string. Otherwise, it returns ‘#f’ ‘read-only’ ‘#t’ if the string is read-only ‘stringbuf-chars’ A new string containing this string's stringbuf's characters ‘stringbuf-length’ The number of characters in this stringbuf ‘stringbuf-shared’ ‘#t’ if this stringbuf is shared ‘stringbuf-wide’ ‘#t’ if this stringbuf's characters are stored in a 32-bit buffer, or ‘#f’ if they are stored in an 8-bit buffer 6.6.6 Symbols ------------- Symbols in Scheme are widely used in three ways: as items of discrete data, as lookup keys for alists and hash tables, and to denote variable references. A “symbol” is similar to a string in that it is defined by a sequence of characters. The sequence of characters is known as the symbol's “name”. In the usual case -- that is, where the symbol's name doesn't include any characters that could be confused with other elements of Scheme syntax -- a symbol is written in a Scheme program by writing the sequence of characters that make up the name, _without_ any quotation marks or other special syntax. For example, the symbol whose name is "multiply-by-2" is written, simply: multiply-by-2 Notice how this differs from a _string_ with contents "multiply-by-2", which is written with double quotation marks, like this: "multiply-by-2" Looking beyond how they are written, symbols are different from strings in two important respects. The first important difference is uniqueness. If the same-looking string is read twice from two different places in a program, the result is two _different_ string objects whose contents just happen to be the same. If, on the other hand, the same-looking symbol is read twice from two different places in a program, the result is the _same_ symbol object both times. Given two read symbols, you can use ‘eq?’ to test whether they are the same (that is, have the same name). ‘eq?’ is the most efficient comparison operator in Scheme, and comparing two symbols like this is as fast as comparing, for example, two numbers. Given two strings, on the other hand, you must use ‘equal?’ or ‘string=?’, which are much slower comparison operators, to determine whether the strings have the same contents. (define sym1 (quote hello)) (define sym2 (quote hello)) (eq? sym1 sym2) ⇒ #t (define str1 "hello") (define str2 "hello") (eq? str1 str2) ⇒ #f (equal? str1 str2) ⇒ #t The second important difference is that symbols, unlike strings, are not self-evaluating. This is why we need the ‘(quote ...)’s in the example above: ‘(quote hello)’ evaluates to the symbol named "hello" itself, whereas an unquoted ‘hello’ is _read_ as the symbol named "hello" and evaluated as a variable reference ... about which more below (*note Symbol Variables::). 6.6.6.1 Symbols as Discrete Data ................................ Numbers and symbols are similar to the extent that they both lend themselves to ‘eq?’ comparison. But symbols are more descriptive than numbers, because a symbol's name can be used directly to describe the concept for which that symbol stands. For example, imagine that you need to represent some colors in a computer program. Using numbers, you would have to choose arbitrarily some mapping between numbers and colors, and then take care to use that mapping consistently: ;; 1=red, 2=green, 3=purple (if (eq? (color-of vehicle) 1) ...) You can make the mapping more explicit and the code more readable by defining constants: (define red 1) (define green 2) (define purple 3) (if (eq? (color-of vehicle) red) ...) But the simplest and clearest approach is not to use numbers at all, but symbols whose names specify the colors that they refer to: (if (eq? (color-of vehicle) 'red) ...) The descriptive advantages of symbols over numbers increase as the set of concepts that you want to describe grows. Suppose that a car object can have other properties as well, such as whether it has or uses: • automatic or manual transmission • leaded or unleaded fuel • power steering (or not). Then a car's combined property set could be naturally represented and manipulated as a list of symbols: (properties-of vehicle1) ⇒ (red manual unleaded power-steering) (if (memq 'power-steering (properties-of vehicle1)) (display "Unfit people can drive this vehicle.\n") (display "You'll need strong arms to drive this vehicle!\n")) ⊣ Unfit people can drive this vehicle. Remember, the fundamental property of symbols that we are relying on here is that an occurrence of ‘'red’ in one part of a program is an _indistinguishable_ symbol from an occurrence of ‘'red’ in another part of a program; this means that symbols can usefully be compared using ‘eq?’. At the same time, symbols have naturally descriptive names. This combination of efficiency and descriptive power makes them ideal for use as discrete data. 6.6.6.2 Symbols as Lookup Keys .............................. Given their efficiency and descriptive power, it is natural to use symbols as the keys in an association list or hash table. To illustrate this, consider a more structured representation of the car properties example from the preceding subsection. Rather than mixing all the properties up together in a flat list, we could use an association list like this: (define car1-properties '((color . red) (transmission . manual) (fuel . unleaded) (steering . power-assisted))) Notice how this structure is more explicit and extensible than the flat list. For example it makes clear that ‘manual’ refers to the transmission rather than, say, the windows or the locking of the car. It also allows further properties to use the same symbols among their possible values without becoming ambiguous: (define car1-properties '((color . red) (transmission . manual) (fuel . unleaded) (steering . power-assisted) (seat-color . red) (locking . manual))) With a representation like this, it is easy to use the efficient ‘assq-XXX’ family of procedures (*note Association Lists::) to extract or change individual pieces of information: (assq-ref car1-properties 'fuel) ⇒ unleaded (assq-ref car1-properties 'transmission) ⇒ manual (assq-set! car1-properties 'seat-color 'black) ⇒ ((color . red) (transmission . manual) (fuel . unleaded) (steering . power-assisted) (seat-color . black) (locking . manual))) Hash tables also have keys, and exactly the same arguments apply to the use of symbols in hash tables as in association lists. The hash value that Guile uses to decide where to add a symbol-keyed entry to a hash table can be obtained by calling the ‘symbol-hash’ procedure: -- Scheme Procedure: symbol-hash symbol -- C Function: scm_symbol_hash (symbol) Return a hash value for SYMBOL. See *note Hash Tables:: for information about hash tables in general, and for why you might choose to use a hash table rather than an association list. 6.6.6.3 Symbols as Denoting Variables ..................................... When an unquoted symbol in a Scheme program is evaluated, it is interpreted as a variable reference, and the result of the evaluation is the appropriate variable's value. For example, when the expression ‘(string-length "abcd")’ is read and evaluated, the sequence of characters ‘string-length’ is read as the symbol whose name is "string-length". This symbol is associated with a variable whose value is the procedure that implements string length calculation. Therefore evaluation of the ‘string-length’ symbol results in that procedure. The details of the connection between an unquoted symbol and the variable to which it refers are explained elsewhere. See *note Binding Constructs::, for how associations between symbols and variables are created, and *note Modules::, for how those associations are affected by Guile's module system. 6.6.6.4 Operations Related to Symbols ..................................... Given any Scheme value, you can determine whether it is a symbol using the ‘symbol?’ primitive: -- Scheme Procedure: symbol? obj -- C Function: scm_symbol_p (obj) Return ‘#t’ if OBJ is a symbol, otherwise return ‘#f’. -- C Function: int scm_is_symbol (SCM val) Equivalent to ‘scm_is_true (scm_symbol_p (val))’. Once you know that you have a symbol, you can obtain its name as a string by calling ‘symbol->string’. Note that Guile differs by default from R5RS on the details of ‘symbol->string’ as regards case-sensitivity: -- Scheme Procedure: symbol->string s -- C Function: scm_symbol_to_string (s) Return the name of symbol S as a string. By default, Guile reads symbols case-sensitively, so the string returned will have the same case variation as the sequence of characters that caused S to be created. If Guile is set to read symbols case-insensitively (as specified by R5RS), and S comes into being as part of a literal expression (*note (r5rs)Literal expressions::) or by a call to the ‘read’ or ‘string-ci->symbol’ procedures, Guile converts any alphabetic characters in the symbol's name to lower case before creating the symbol object, so the string returned here will be in lower case. If S was created by ‘string->symbol’, the case of characters in the string returned will be the same as that in the string that was passed to ‘string->symbol’, regardless of Guile's case-sensitivity setting at the time S was created. It is an error to apply mutation procedures like ‘string-set!’ to strings returned by this procedure. Most symbols are created by writing them literally in code. However it is also possible to create symbols programmatically using the following procedures: -- Scheme Procedure: symbol char... Return a newly allocated symbol made from the given character arguments. (symbol #\x #\y #\z) ⇒ xyz -- Scheme Procedure: list->symbol lst Return a newly allocated symbol made from a list of characters. (list->symbol '(#\a #\b #\c)) ⇒ abc -- Scheme Procedure: symbol-append arg ... Return a newly allocated symbol whose characters form the concatenation of the given symbols, ARG .... (let ((h 'hello)) (symbol-append h 'world)) ⇒ helloworld -- Scheme Procedure: string->symbol string -- C Function: scm_string_to_symbol (string) Return the symbol whose name is STRING. This procedure can create symbols with names containing special characters or letters in the non-standard case, but it is usually a bad idea to create such symbols because in some implementations of Scheme they cannot be read as themselves. -- Scheme Procedure: string-ci->symbol str -- C Function: scm_string_ci_to_symbol (str) Return the symbol whose name is STR. If Guile is currently reading symbols case-insensitively, STR is converted to lowercase before the returned symbol is looked up or created. The following examples illustrate Guile's detailed behavior as regards the case-sensitivity of symbols: (read-enable 'case-insensitive) ; R5RS compliant behavior (symbol->string 'flying-fish) ⇒ "flying-fish" (symbol->string 'Martin) ⇒ "martin" (symbol->string (string->symbol "Malvina")) ⇒ "Malvina" (eq? 'mISSISSIppi 'mississippi) ⇒ #t (string->symbol "mISSISSIppi") ⇒ mISSISSIppi (eq? 'bitBlt (string->symbol "bitBlt")) ⇒ #f (eq? 'LolliPop (string->symbol (symbol->string 'LolliPop))) ⇒ #t (string=? "K. Harper, M.D." (symbol->string (string->symbol "K. Harper, M.D."))) ⇒ #t (read-disable 'case-insensitive) ; Guile default behavior (symbol->string 'flying-fish) ⇒ "flying-fish" (symbol->string 'Martin) ⇒ "Martin" (symbol->string (string->symbol "Malvina")) ⇒ "Malvina" (eq? 'mISSISSIppi 'mississippi) ⇒ #f (string->symbol "mISSISSIppi") ⇒ mISSISSIppi (eq? 'bitBlt (string->symbol "bitBlt")) ⇒ #t (eq? 'LolliPop (string->symbol (symbol->string 'LolliPop))) ⇒ #t (string=? "K. Harper, M.D." (symbol->string (string->symbol "K. Harper, M.D."))) ⇒ #t From C, there are lower level functions that construct a Scheme symbol from a C string in the current locale encoding. When you want to do more from C, you should convert between symbols and strings using ‘scm_symbol_to_string’ and ‘scm_string_to_symbol’ and work with the strings. -- C Function: SCM scm_from_latin1_symbol (const char *name) -- C Function: SCM scm_from_utf8_symbol (const char *name) Construct and return a Scheme symbol whose name is specified by the null-terminated C string NAME. These are appropriate when the C string is hard-coded in the source code. -- C Function: SCM scm_from_locale_symbol (const char *name) -- C Function: SCM scm_from_locale_symboln (const char *name, size_t len) Construct and return a Scheme symbol whose name is specified by NAME. For ‘scm_from_locale_symbol’, NAME must be null terminated; for ‘scm_from_locale_symboln’ the length of NAME is specified explicitly by LEN. Note that these functions should _not_ be used when NAME is a C string constant, because there is no guarantee that the current locale will match that of the execution character set, used for string and character constants. Most modern C compilers use UTF-8 by default, so in such cases we recommend ‘scm_from_utf8_symbol’. -- C Function: SCM scm_take_locale_symbol (char *str) -- C Function: SCM scm_take_locale_symboln (char *str, size_t len) Like ‘scm_from_locale_symbol’ and ‘scm_from_locale_symboln’, respectively, but also frees STR with ‘free’ eventually. Thus, you can use this function when you would free STR anyway immediately after creating the Scheme string. In certain cases, Guile can then use STR directly as its internal representation. The size of a symbol can also be obtained from C: -- C Function: size_t scm_c_symbol_length (SCM sym) Return the number of characters in SYM. Finally, some applications, especially those that generate new Scheme code dynamically, need to generate symbols for use in the generated code. The ‘gensym’ primitive meets this need: -- Scheme Procedure: gensym [prefix] -- C Function: scm_gensym (prefix) Create a new symbol with a name constructed from a prefix and a counter value. The string PREFIX can be specified as an optional argument. Default prefix is ‘ g’. The counter is increased by 1 at each call. There is no provision for resetting the counter. The symbols generated by ‘gensym’ are _likely_ to be unique, since their names begin with a space and it is only otherwise possible to generate such symbols if a programmer goes out of their way to do so. Uniqueness can be guaranteed by instead using uninterned symbols (*note Symbol Uninterned::), though they can't be usefully written out and read back in. 6.6.6.5 Extended Read Syntax for Symbols ........................................ The read syntax for a symbol is a sequence of letters, digits, and “extended alphabetic characters”, beginning with a character that cannot begin a number. In addition, the special cases of ‘+’, ‘-’, and ‘...’ are read as symbols even though numbers can begin with ‘+’, ‘-’ or ‘.’. Extended alphabetic characters may be used within identifiers as if they were letters. The set of extended alphabetic characters is: ! $ % & * + - . / : < = > ? @ ^ _ ~ In addition to the standard read syntax defined above (which is taken from R5RS (*note (r5rs)Formal syntax::)), Guile provides an extended symbol read syntax that allows the inclusion of unusual characters such as space characters, newlines and parentheses. If (for whatever reason) you need to write a symbol containing characters not mentioned above, you can do so as follows. • Begin the symbol with the characters ‘#{’, • write the characters of the symbol and • finish the symbol with the characters ‘}#’. Here are a few examples of this form of read syntax. The first symbol needs to use extended syntax because it contains a space character, the second because it contains a line break, and the last because it looks like a number. #{foo bar}# #{what ever}# #{4242}# Although Guile provides this extended read syntax for symbols, widespread usage of it is discouraged because it is not portable and not very readable. Alternatively, if you enable the ‘r7rs-symbols’ read option (see *note Scheme Read::), you can write arbitrary symbols using the same notation used for strings, except delimited by vertical bars instead of double quotes. |foo bar| |\x3BB; is a greek lambda| |\| is a vertical bar| Note that there's also an ‘r7rs-symbols’ print option (*note Scheme Write::). To enable the use of this notation, evaluate one or both of the following expressions: (read-enable 'r7rs-symbols) (print-enable 'r7rs-symbols) 6.6.6.6 Uninterned Symbols .......................... What makes symbols useful is that they are automatically kept unique. There are no two symbols that are distinct objects but have the same name. But of course, there is no rule without exception. In addition to the normal symbols that have been discussed up to now, you can also create special “uninterned” symbols that behave slightly differently. To understand what is different about them and why they might be useful, we look at how normal symbols are actually kept unique. Whenever Guile wants to find the symbol with a specific name, for example during ‘read’ or when executing ‘string->symbol’, it first looks into a table of all existing symbols to find out whether a symbol with the given name already exists. When this is the case, Guile just returns that symbol. When not, a new symbol with the name is created and entered into the table so that it can be found later. Sometimes you might want to create a symbol that is guaranteed 'fresh', i.e. a symbol that did not exist previously. You might also want to somehow guarantee that no one else will ever unintentionally stumble across your symbol in the future. These properties of a symbol are often needed when generating code during macro expansion. When introducing new temporary variables, you want to guarantee that they don't conflict with variables in other people's code. The simplest way to arrange for this is to create a new symbol but not enter it into the global table of all symbols. That way, no one will ever get access to your symbol by chance. Symbols that are not in the table are called “uninterned”. Of course, symbols that _are_ in the table are called “interned”. You create new uninterned symbols with the function ‘make-symbol’. You can test whether a symbol is interned or not with ‘symbol-interned?’. Uninterned symbols break the rule that the name of a symbol uniquely identifies the symbol object. Because of this, they can not be written out and read back in like interned symbols. Currently, Guile has no support for reading uninterned symbols. Note that the function ‘gensym’ does not return uninterned symbols for this reason. -- Scheme Procedure: make-symbol name -- C Function: scm_make_symbol (name) Return a new uninterned symbol with the name NAME. The returned symbol is guaranteed to be unique and future calls to ‘string->symbol’ will not return it. -- Scheme Procedure: symbol-interned? symbol -- C Function: scm_symbol_interned_p (symbol) Return ‘#t’ if SYMBOL is interned, otherwise return ‘#f’. For example: (define foo-1 (string->symbol "foo")) (define foo-2 (string->symbol "foo")) (define foo-3 (make-symbol "foo")) (define foo-4 (make-symbol "foo")) (eq? foo-1 foo-2) ⇒ #t ; Two interned symbols with the same name are the same object, (eq? foo-1 foo-3) ⇒ #f ; but a call to make-symbol with the same name returns a ; distinct object. (eq? foo-3 foo-4) ⇒ #f ; A call to make-symbol always returns a new object, even for ; the same name. foo-3 ⇒ # ; Uninterned symbols print differently from interned symbols, (symbol? foo-3) ⇒ #t ; but they are still symbols, (symbol-interned? foo-3) ⇒ #f ; just not interned. 6.6.7 Keywords -------------- Keywords are self-evaluating objects with a convenient read syntax that makes them easy to type. Guile's keyword support conforms to R5RS, and adds a (switchable) read syntax extension to permit keywords to begin with ‘:’ as well as ‘#:’, or to end with ‘:’. 6.6.7.1 Why Use Keywords? ......................... Keywords are useful in contexts where a program or procedure wants to be able to accept a large number of optional arguments without making its interface unmanageable. To illustrate this, consider a hypothetical ‘make-window’ procedure, which creates a new window on the screen for drawing into using some graphical toolkit. There are many parameters that the caller might like to specify, but which could also be sensibly defaulted, for example: • color depth - Default: the color depth for the screen • background color - Default: white • width - Default: 600 • height - Default: 400 If ‘make-window’ did not use keywords, the caller would have to pass in a value for each possible argument, remembering the correct argument order and using a special value to indicate the default value for that argument: (make-window 'default ;; Color depth 'default ;; Background color 800 ;; Width 100 ;; Height ...) ;; More make-window arguments With keywords, on the other hand, defaulted arguments are omitted, and non-default arguments are clearly tagged by the appropriate keyword. As a result, the invocation becomes much clearer: (make-window #:width 800 #:height 100) On the other hand, for a simpler procedure with few arguments, the use of keywords would be a hindrance rather than a help. The primitive procedure ‘cons’, for example, would not be improved if it had to be invoked as (cons #:car x #:cdr y) So the decision whether to use keywords or not is purely pragmatic: use them if they will clarify the procedure invocation at point of call. 6.6.7.2 Coding With Keywords ............................ If a procedure wants to support keywords, it should take a rest argument and then use whatever means is convenient to extract keywords and their corresponding arguments from the contents of that rest argument. The following example illustrates the principle: the code for ‘make-window’ uses a helper procedure called ‘get-keyword-value’ to extract individual keyword arguments from the rest argument. (define (get-keyword-value args keyword default) (let ((kv (memq keyword args))) (if (and kv (>= (length kv) 2)) (cadr kv) default))) (define (make-window . args) (let ((depth (get-keyword-value args #:depth screen-depth)) (bg (get-keyword-value args #:bg "white")) (width (get-keyword-value args #:width 800)) (height (get-keyword-value args #:height 100)) ...) ...)) But you don't need to write ‘get-keyword-value’. The ‘(ice-9 optargs)’ module provides a set of powerful macros that you can use to implement keyword-supporting procedures like this: (use-modules (ice-9 optargs)) (define (make-window . args) (let-keywords args #f ((depth screen-depth) (bg "white") (width 800) (height 100)) ...)) Or, even more economically, like this: (use-modules (ice-9 optargs)) (define* (make-window #:key (depth screen-depth) (bg "white") (width 800) (height 100)) ...) For further details on ‘let-keywords’, ‘define*’ and other facilities provided by the ‘(ice-9 optargs)’ module, see *note Optional Arguments::. To handle keyword arguments from procedures implemented in C, use ‘scm_c_bind_keyword_arguments’ (*note Keyword Procedures::). 6.6.7.3 Keyword Read Syntax ........................... Guile, by default, only recognizes a keyword syntax that is compatible with R5RS. A token of the form ‘#:NAME’, where ‘NAME’ has the same syntax as a Scheme symbol (*note Symbol Read Syntax::), is the external representation of the keyword named ‘NAME’. Keyword objects print using this syntax as well, so values containing keyword objects can be read back into Guile. When used in an expression, keywords are self-quoting objects. If the ‘keywords’ read option is set to ‘'prefix’, Guile also recognizes the alternative read syntax ‘:NAME’. Otherwise, tokens of the form ‘:NAME’ are read as symbols, as required by R5RS. If the ‘keywords’ read option is set to ‘'postfix’, Guile recognizes the SRFI-88 read syntax ‘NAME:’ (*note SRFI-88::). Otherwise, tokens of this form are read as symbols. To enable and disable the alternative non-R5RS keyword syntax, you use the ‘read-set!’ procedure documented *note Scheme Read::. Note that the ‘prefix’ and ‘postfix’ syntax are mutually exclusive. (read-set! keywords 'prefix) #:type ⇒ #:type :type ⇒ #:type (read-set! keywords 'postfix) type: ⇒ #:type :type ⇒ :type (read-set! keywords #f) #:type ⇒ #:type :type ⊣ ERROR: In expression :type: ERROR: Unbound variable: :type ABORT: (unbound-variable) 6.6.7.4 Keyword Procedures .......................... -- Scheme Procedure: keyword? obj -- C Function: scm_keyword_p (obj) Return ‘#t’ if the argument OBJ is a keyword, else ‘#f’. -- Scheme Procedure: keyword->symbol keyword -- C Function: scm_keyword_to_symbol (keyword) Return the symbol with the same name as KEYWORD. -- Scheme Procedure: symbol->keyword symbol -- C Function: scm_symbol_to_keyword (symbol) Return the keyword with the same name as SYMBOL. -- C Function: int scm_is_keyword (SCM obj) Equivalent to ‘scm_is_true (scm_keyword_p (OBJ))’. -- C Function: SCM scm_from_locale_keyword (const char *name) -- C Function: SCM scm_from_locale_keywordn (const char *name, size_t len) Equivalent to ‘scm_symbol_to_keyword (scm_from_locale_symbol (NAME))’ and ‘scm_symbol_to_keyword (scm_from_locale_symboln (NAME, LEN))’, respectively. Note that these functions should _not_ be used when NAME is a C string constant, because there is no guarantee that the current locale will match that of the execution character set, used for string and character constants. Most modern C compilers use UTF-8 by default, so in such cases we recommend ‘scm_from_utf8_keyword’. -- C Function: SCM scm_from_latin1_keyword (const char *name) -- C Function: SCM scm_from_utf8_keyword (const char *name) Equivalent to ‘scm_symbol_to_keyword (scm_from_latin1_symbol (NAME))’ and ‘scm_symbol_to_keyword (scm_from_utf8_symbol (NAME))’, respectively. -- C Function: void scm_c_bind_keyword_arguments (const char *subr, SCM rest, scm_t_keyword_arguments_flags flags, SCM keyword1, SCM *argp1, ..., SCM keywordN, SCM *argpN, SCM_UNDEFINED) Extract the specified keyword arguments from REST, which is not modified. If the keyword argument KEYWORD1 is present in REST with an associated value, that value is stored in the variable pointed to by ARGP1, otherwise the variable is left unchanged. Similarly for the other keywords and argument pointers up to KEYWORDN and ARGPN. The argument list to ‘scm_c_bind_keyword_arguments’ must be terminated by ‘SCM_UNDEFINED’. Note that since the variables pointed to by ARGP1 through ARGPN are left unchanged if the associated keyword argument is not present, they should be initialized to their default values before calling ‘scm_c_bind_keyword_arguments’. Alternatively, you can initialize them to ‘SCM_UNDEFINED’ before the call, and then use ‘SCM_UNBNDP’ after the call to see which ones were provided. If an unrecognized keyword argument is present in REST and FLAGS does not contain ‘SCM_ALLOW_OTHER_KEYS’, or if non-keyword arguments are present and FLAGS does not contain ‘SCM_ALLOW_NON_KEYWORD_ARGUMENTS’, an exception is raised. SUBR should be the name of the procedure receiving the keyword arguments, for purposes of error reporting. For example: SCM k_delimiter; SCM k_grammar; SCM sym_infix; SCM my_string_join (SCM strings, SCM rest) { SCM delimiter = SCM_UNDEFINED; SCM grammar = sym_infix; scm_c_bind_keyword_arguments ("my-string-join", rest, 0, k_delimiter, &delimiter, k_grammar, &grammar, SCM_UNDEFINED); if (SCM_UNBNDP (delimiter)) delimiter = scm_from_utf8_string (" "); return scm_string_join (strings, delimiter, grammar); } void my_init () { k_delimiter = scm_from_utf8_keyword ("delimiter"); k_grammar = scm_from_utf8_keyword ("grammar"); sym_infix = scm_from_utf8_symbol ("infix"); scm_c_define_gsubr ("my-string-join", 1, 0, 1, my_string_join); } 6.6.8 Pairs ----------- Pairs are used to combine two Scheme objects into one compound object. Hence the name: A pair stores a pair of objects. The data type “pair” is extremely important in Scheme, just like in any other Lisp dialect. The reason is that pairs are not only used to make two values available as one object, but that pairs are used for constructing lists of values. Because lists are so important in Scheme, they are described in a section of their own (*note Lists::). Pairs can literally get entered in source code or at the REPL, in the so-called “dotted list” syntax. This syntax consists of an opening parentheses, the first element of the pair, a dot, the second element and a closing parentheses. The following example shows how a pair consisting of the two numbers 1 and 2, and a pair containing the symbols ‘foo’ and ‘bar’ can be entered. It is very important to write the whitespace before and after the dot, because otherwise the Scheme parser would not be able to figure out where to split the tokens. (1 . 2) (foo . bar) But beware, if you want to try out these examples, you have to “quote” the expressions. More information about quotation is available in the section *note Expression Syntax::. The correct way to try these examples is as follows. '(1 . 2) ⇒ (1 . 2) '(foo . bar) ⇒ (foo . bar) A new pair is made by calling the procedure ‘cons’ with two arguments. Then the argument values are stored into a newly allocated pair, and the pair is returned. The name ‘cons’ stands for "construct". Use the procedure ‘pair?’ to test whether a given Scheme object is a pair or not. -- Scheme Procedure: cons x y -- C Function: scm_cons (x, y) Return a newly allocated pair whose car is X and whose cdr is Y. The pair is guaranteed to be different (in the sense of ‘eq?’) from every previously existing object. -- Scheme Procedure: pair? x -- C Function: scm_pair_p (x) Return ‘#t’ if X is a pair; otherwise return ‘#f’. -- C Function: int scm_is_pair (SCM x) Return 1 when X is a pair; otherwise return 0. The two parts of a pair are traditionally called “car” and “cdr”. They can be retrieved with procedures of the same name (‘car’ and ‘cdr’), and can be modified with the procedures ‘set-car!’ and ‘set-cdr!’. Since a very common operation in Scheme programs is to access the car of a car of a pair, or the car of the cdr of a pair, etc., the procedures called ‘caar’, ‘cadr’ and so on are also predefined. However, using these procedures is often detrimental to readability, and error-prone. Thus, accessing the contents of a list is usually better achieved using pattern matching techniques (*note Pattern Matching::). -- Scheme Procedure: car pair -- Scheme Procedure: cdr pair -- C Function: scm_car (pair) -- C Function: scm_cdr (pair) Return the car or the cdr of PAIR, respectively. -- C Macro: SCM SCM_CAR (SCM pair) -- C Macro: SCM SCM_CDR (SCM pair) These two macros are the fastest way to access the car or cdr of a pair; they can be thought of as compiling into a single memory reference. These macros do no checking at all. The argument PAIR must be a valid pair. -- Scheme Procedure: cddr pair -- Scheme Procedure: cdar pair -- Scheme Procedure: cadr pair -- Scheme Procedure: caar pair -- Scheme Procedure: cdddr pair -- Scheme Procedure: cddar pair -- Scheme Procedure: cdadr pair -- Scheme Procedure: cdaar pair -- Scheme Procedure: caddr pair -- Scheme Procedure: cadar pair -- Scheme Procedure: caadr pair -- Scheme Procedure: caaar pair -- Scheme Procedure: cddddr pair -- Scheme Procedure: cdddar pair -- Scheme Procedure: cddadr pair -- Scheme Procedure: cddaar pair -- Scheme Procedure: cdaddr pair -- Scheme Procedure: cdadar pair -- Scheme Procedure: cdaadr pair -- Scheme Procedure: cdaaar pair -- Scheme Procedure: cadddr pair -- Scheme Procedure: caddar pair -- Scheme Procedure: cadadr pair -- Scheme Procedure: cadaar pair -- Scheme Procedure: caaddr pair -- Scheme Procedure: caadar pair -- Scheme Procedure: caaadr pair -- Scheme Procedure: caaaar pair -- C Function: scm_cddr (pair) -- C Function: scm_cdar (pair) -- C Function: scm_cadr (pair) -- C Function: scm_caar (pair) -- C Function: scm_cdddr (pair) -- C Function: scm_cddar (pair) -- C Function: scm_cdadr (pair) -- C Function: scm_cdaar (pair) -- C Function: scm_caddr (pair) -- C Function: scm_cadar (pair) -- C Function: scm_caadr (pair) -- C Function: scm_caaar (pair) -- C Function: scm_cddddr (pair) -- C Function: scm_cdddar (pair) -- C Function: scm_cddadr (pair) -- C Function: scm_cddaar (pair) -- C Function: scm_cdaddr (pair) -- C Function: scm_cdadar (pair) -- C Function: scm_cdaadr (pair) -- C Function: scm_cdaaar (pair) -- C Function: scm_cadddr (pair) -- C Function: scm_caddar (pair) -- C Function: scm_cadadr (pair) -- C Function: scm_cadaar (pair) -- C Function: scm_caaddr (pair) -- C Function: scm_caadar (pair) -- C Function: scm_caaadr (pair) -- C Function: scm_caaaar (pair) These procedures are compositions of ‘car’ and ‘cdr’, where for example ‘caddr’ could be defined by (define caddr (lambda (x) (car (cdr (cdr x))))) ‘cadr’, ‘caddr’ and ‘cadddr’ pick out the second, third or fourth elements of a list, respectively. SRFI-1 provides the same under the names ‘second’, ‘third’ and ‘fourth’ (*note SRFI-1 Selectors::). -- Scheme Procedure: set-car! pair value -- C Function: scm_set_car_x (pair, value) Stores VALUE in the car field of PAIR. The value returned by ‘set-car!’ is unspecified. -- Scheme Procedure: set-cdr! pair value -- C Function: scm_set_cdr_x (pair, value) Stores VALUE in the cdr field of PAIR. The value returned by ‘set-cdr!’ is unspecified. 6.6.9 Lists ----------- A very important data type in Scheme--as well as in all other Lisp dialects--is the data type “list”.(1) This is the short definition of what a list is: • Either the empty list ‘()’, • or a pair which has a list in its cdr. ---------- Footnotes ---------- (1) Strictly speaking, Scheme does not have a real datatype “list”. Lists are made up of “chained pairs”, and only exist by definition--a list is a chain of pairs which looks like a list. 6.6.9.1 List Read Syntax ........................ The syntax for lists is an opening parentheses, then all the elements of the list (separated by whitespace) and finally a closing parentheses.(1). (1 2 3) ; a list of the numbers 1, 2 and 3 ("foo" bar 3.1415) ; a string, a symbol and a real number () ; the empty list The last example needs a bit more explanation. A list with no elements, called the “empty list”, is special in some ways. It is used for terminating lists by storing it into the cdr of the last pair that makes up a list. An example will clear that up: (car '(1)) ⇒ 1 (cdr '(1)) ⇒ () This example also shows that lists have to be quoted when written (*note Expression Syntax::), because they would otherwise be mistakenly taken as procedure applications (*note Simple Invocation::). ---------- Footnotes ---------- (1) Note that there is no separation character between the list elements, like a comma or a semicolon. 6.6.9.2 List Predicates ....................... Often it is useful to test whether a given Scheme object is a list or not. List-processing procedures could use this information to test whether their input is valid, or they could do different things depending on the datatype of their arguments. -- Scheme Procedure: list? x -- C Function: scm_list_p (x) Return ‘#t’ if X is a proper list, else ‘#f’. The predicate ‘null?’ is often used in list-processing code to tell whether a given list has run out of elements. That is, a loop somehow deals with the elements of a list until the list satisfies ‘null?’. Then, the algorithm terminates. -- Scheme Procedure: null? x -- C Function: scm_null_p (x) Return ‘#t’ if X is the empty list, else ‘#f’. -- C Function: int scm_is_null (SCM x) Return 1 when X is the empty list; otherwise return 0. 6.6.9.3 List Constructors ......................... This section describes the procedures for constructing new lists. ‘list’ simply returns a list where the elements are the arguments, ‘cons*’ is similar, but the last argument is stored in the cdr of the last pair of the list. -- Scheme Procedure: list elem ... -- C Function: scm_list_1 (elem1) -- C Function: scm_list_2 (elem1, elem2) -- C Function: scm_list_3 (elem1, elem2, elem3) -- C Function: scm_list_4 (elem1, elem2, elem3, elem4) -- C Function: scm_list_5 (elem1, elem2, elem3, elem4, elem5) -- C Function: scm_list_n (elem1, ..., elemN, SCM_UNDEFINED) Return a new list containing elements ELEM .... ‘scm_list_n’ takes a variable number of arguments, terminated by the special ‘SCM_UNDEFINED’. That final ‘SCM_UNDEFINED’ is not included in the list. None of ELEM ... can themselves be ‘SCM_UNDEFINED’, or ‘scm_list_n’ will terminate at that point. -- Scheme Procedure: cons* arg1 arg2 ... Like ‘list’, but the last arg provides the tail of the constructed list, returning ‘(cons ARG1 (cons ARG2 (cons ... ARGN)))’. Requires at least one argument. If given one argument, that argument is returned as result. This function is called ‘list*’ in some other Schemes and in Common LISP. -- Scheme Procedure: list-copy lst -- C Function: scm_list_copy (lst) Return a (newly-created) copy of LST. -- Scheme Procedure: make-list n [init] Create a list containing of N elements, where each element is initialized to INIT. INIT defaults to the empty list ‘()’ if not given. Note that ‘list-copy’ only makes a copy of the pairs which make up the spine of the lists. The list elements are not copied, which means that modifying the elements of the new list also modifies the elements of the old list. On the other hand, applying procedures like ‘set-cdr!’ or ‘delv!’ to the new list will not alter the old list. If you also need to copy the list elements (making a deep copy), use the procedure ‘copy-tree’ from ‘(ice-9 copy-tree)’ (*note Copying::). 6.6.9.4 List Selection ...................... These procedures are used to get some information about a list, or to retrieve one or more elements of a list. -- Scheme Procedure: length lst -- C Function: scm_length (lst) Return the number of elements in list LST. -- Scheme Procedure: last-pair lst -- C Function: scm_last_pair (lst) Return the last pair in LST, signaling an error if LST is circular. -- Scheme Procedure: list-ref list k -- C Function: scm_list_ref (list, k) Return the Kth element from LIST. -- Scheme Procedure: list-tail lst k -- Scheme Procedure: list-cdr-ref lst k -- C Function: scm_list_tail (lst, k) Return the "tail" of LST beginning with its Kth element. The first element of the list is considered to be element 0. ‘list-tail’ and ‘list-cdr-ref’ are identical. It may help to think of ‘list-cdr-ref’ as accessing the Kth cdr of the list, or returning the results of cdring K times down LST. -- Scheme Procedure: list-head lst k -- C Function: scm_list_head (lst, k) Copy the first K elements from LST into a new list, and return it. 6.6.9.5 Append and Reverse .......................... ‘append’ and ‘append!’ are used to concatenate two or more lists in order to form a new list. ‘reverse’ and ‘reverse!’ return lists with the same elements as their arguments, but in reverse order. The procedure variants with an ‘!’ directly modify the pairs which form the list, whereas the other procedures create new pairs. This is why you should be careful when using the side-effecting variants. -- Scheme Procedure: append lst ... obj -- Scheme Procedure: append -- Scheme Procedure: append! lst ... obj -- Scheme Procedure: append! -- C Function: scm_append (lstlst) -- C Function: scm_append_x (lstlst) Return a list comprising all the elements of lists LST ... OBJ. If called with no arguments, return the empty list. (append '(x) '(y)) ⇒ (x y) (append '(a) '(b c d)) ⇒ (a b c d) (append '(a (b)) '((c))) ⇒ (a (b) (c)) The last argument OBJ may actually be any object; an improper list results if the last argument is not a proper list. (append '(a b) '(c . d)) ⇒ (a b c . d) (append '() 'a) ⇒ a ‘append’ doesn't modify the given lists, but the return may share structure with the final OBJ. ‘append!’ is permitted, but not required, to modify the given lists to form its return. For ‘scm_append’ and ‘scm_append_x’, LSTLST is a list of the list operands LST ... OBJ. That LSTLST itself is not modified or used in the return. -- Scheme Procedure: reverse lst -- Scheme Procedure: reverse! lst [newtail] -- C Function: scm_reverse (lst) -- C Function: scm_reverse_x (lst, newtail) Return a list comprising the elements of LST, in reverse order. ‘reverse’ constructs a new list. ‘reverse!’ is permitted, but not required, to modify LST in constructing its return. For ‘reverse!’, the optional NEWTAIL is appended to the result. NEWTAIL isn't reversed, it simply becomes the list tail. For ‘scm_reverse_x’, the NEWTAIL parameter is mandatory, but can be ‘SCM_EOL’ if no further tail is required. 6.6.9.6 List Modification ......................... The following procedures modify an existing list, either by changing elements of the list, or by changing the list structure itself. -- Scheme Procedure: list-set! list k val -- C Function: scm_list_set_x (list, k, val) Set the Kth element of LIST to VAL. -- Scheme Procedure: list-cdr-set! list k val -- C Function: scm_list_cdr_set_x (list, k, val) Set the Kth cdr of LIST to VAL. -- Scheme Procedure: delq item lst -- C Function: scm_delq (item, lst) Return a newly-created copy of LST with elements ‘eq?’ to ITEM removed. This procedure mirrors ‘memq’: ‘delq’ compares elements of LST against ITEM with ‘eq?’. -- Scheme Procedure: delv item lst -- C Function: scm_delv (item, lst) Return a newly-created copy of LST with elements ‘eqv?’ to ITEM removed. This procedure mirrors ‘memv’: ‘delv’ compares elements of LST against ITEM with ‘eqv?’. -- Scheme Procedure: delete item lst -- C Function: scm_delete (item, lst) Return a newly-created copy of LST with elements ‘equal?’ to ITEM removed. This procedure mirrors ‘member’: ‘delete’ compares elements of LST against ITEM with ‘equal?’. See also SRFI-1 which has an extended ‘delete’ (*note SRFI-1 Deleting::), and also an ‘lset-difference’ which can delete multiple ITEMs in one call (*note SRFI-1 Set Operations::). -- Scheme Procedure: delq! item lst -- Scheme Procedure: delv! item lst -- Scheme Procedure: delete! item lst -- C Function: scm_delq_x (item, lst) -- C Function: scm_delv_x (item, lst) -- C Function: scm_delete_x (item, lst) These procedures are destructive versions of ‘delq’, ‘delv’ and ‘delete’: they modify the pointers in the existing LST rather than creating a new list. Caveat evaluator: Like other destructive list functions, these functions cannot modify the binding of LST, and so cannot be used to delete the first element of LST destructively. -- Scheme Procedure: delq1! item lst -- C Function: scm_delq1_x (item, lst) Like ‘delq!’, but only deletes the first occurrence of ITEM from LST. Tests for equality using ‘eq?’. See also ‘delv1!’ and ‘delete1!’. -- Scheme Procedure: delv1! item lst -- C Function: scm_delv1_x (item, lst) Like ‘delv!’, but only deletes the first occurrence of ITEM from LST. Tests for equality using ‘eqv?’. See also ‘delq1!’ and ‘delete1!’. -- Scheme Procedure: delete1! item lst -- C Function: scm_delete1_x (item, lst) Like ‘delete!’, but only deletes the first occurrence of ITEM from LST. Tests for equality using ‘equal?’. See also ‘delq1!’ and ‘delv1!’. -- Scheme Procedure: filter pred lst -- Scheme Procedure: filter! pred lst Return a list containing all elements from LST which satisfy the predicate PRED. The elements in the result list have the same order as in LST. The order in which PRED is applied to the list elements is not specified. ‘filter’ does not change LST, but the result may share a tail with it. ‘filter!’ may modify LST to construct its return. 6.6.9.7 List Searching ...................... The following procedures search lists for particular elements. They use different comparison predicates for comparing list elements with the object to be searched. When they fail, they return ‘#f’, otherwise they return the sublist whose car is equal to the search object, where equality depends on the equality predicate used. -- Scheme Procedure: memq x lst -- C Function: scm_memq (x, lst) Return the first sublist of LST whose car is ‘eq?’ to X where the sublists of LST are the non-empty lists returned by ‘(list-tail LST K)’ for K less than the length of LST. If X does not occur in LST, then ‘#f’ (not the empty list) is returned. -- Scheme Procedure: memv x lst -- C Function: scm_memv (x, lst) Return the first sublist of LST whose car is ‘eqv?’ to X where the sublists of LST are the non-empty lists returned by ‘(list-tail LST K)’ for K less than the length of LST. If X does not occur in LST, then ‘#f’ (not the empty list) is returned. -- Scheme Procedure: member x lst -- C Function: scm_member (x, lst) Return the first sublist of LST whose car is ‘equal?’ to X where the sublists of LST are the non-empty lists returned by ‘(list-tail LST K)’ for K less than the length of LST. If X does not occur in LST, then ‘#f’ (not the empty list) is returned. See also SRFI-1 which has an extended ‘member’ function (*note SRFI-1 Searching::). 6.6.9.8 List Mapping .................... List processing is very convenient in Scheme because the process of iterating over the elements of a list can be highly abstracted. The procedures in this section are the most basic iterating procedures for lists. They take a procedure and one or more lists as arguments, and apply the procedure to each element of the list. They differ in their return value. -- Scheme Procedure: map proc arg1 arg2 ... -- Scheme Procedure: map-in-order proc arg1 arg2 ... -- C Function: scm_map (proc, arg1, args) Apply PROC to each element of the list ARG1 (if only two arguments are given), or to the corresponding elements of the argument lists (if more than two arguments are given). The result(s) of the procedure applications are saved and returned in a list. For ‘map’, the order of procedure applications is not specified, ‘map-in-order’ applies the procedure from left to right to the list elements. -- Scheme Procedure: for-each proc arg1 arg2 ... Like ‘map’, but the procedure is always applied from left to right, and the result(s) of the procedure applications are thrown away. The return value is not specified. See also SRFI-1 which extends these functions to take lists of unequal lengths (*note SRFI-1 Fold and Map::). 6.6.10 Vectors -------------- Vectors are sequences of Scheme objects. Unlike lists, the length of a vector, once the vector is created, cannot be changed. The advantage of vectors over lists is that the time required to access one element of a vector given its “position” (synonymous with “index”), a zero-origin number, is constant, whereas lists have an access time linear to the position of the accessed element in the list. Vectors can contain any kind of Scheme object; it is even possible to have different types of objects in the same vector. For vectors containing vectors, you may wish to use *note Arrays:: instead. Note, too, that vectors are a special case of one dimensional non-uniform arrays and that array procedures operate happily on vectors. Also see *note SRFI-43::, *note R6RS Support::, or *note R7RS Support::, for more comprehensive vector libraries. 6.6.10.1 Read Syntax for Vectors ................................ Vectors can literally be entered in source code, just like strings, characters or some of the other data types. The read syntax for vectors is as follows: A sharp sign (‘#’), followed by an opening parentheses, all elements of the vector in their respective read syntax, and finally a closing parentheses. Like strings, vectors do not have to be quoted. The following are examples of the read syntax for vectors; where the first vector only contains numbers and the second three different object types: a string, a symbol and a number in hexadecimal notation. #(1 2 3) #("Hello" foo #xdeadbeef) 6.6.10.2 Dynamic Vector Creation and Validation ............................................... Instead of creating a vector implicitly by using the read syntax just described, you can create a vector dynamically by calling one of the ‘vector’ and ‘list->vector’ primitives with the list of Scheme values that you want to place into a vector. The size of the vector thus created is determined implicitly by the number of arguments given. -- Scheme Procedure: vector arg ... -- Scheme Procedure: list->vector l -- C Function: scm_vector (l) Return a newly allocated vector composed of the given arguments. Analogous to ‘list’. (vector 'a 'b 'c) ⇒ #(a b c) The inverse operation is ‘vector->list’: -- Scheme Procedure: vector->list v -- C Function: scm_vector_to_list (v) Return a newly allocated list composed of the elements of V. (vector->list #(dah dah didah)) ⇒ (dah dah didah) (list->vector '(dididit dah)) ⇒ #(dididit dah) To allocate a vector with an explicitly specified size, use ‘make-vector’. With this primitive you can also specify an initial value for the vector elements (the same value for all elements, that is): -- Scheme Procedure: make-vector len [fill] -- C Function: scm_make_vector (len, fill) Return a newly allocated vector of LEN elements. If a second argument is given, then each position is initialized to FILL. Otherwise the initial contents of each position is unspecified. -- C Function: SCM scm_c_make_vector (size_t k, SCM fill) Like ‘scm_make_vector’, but the length is given as a ‘size_t’. To check whether an arbitrary Scheme value _is_ a vector, use the ‘vector?’ primitive: -- Scheme Procedure: vector? obj -- C Function: scm_vector_p (obj) Return ‘#t’ if OBJ is a vector, otherwise return ‘#f’. -- C Function: int scm_is_vector (SCM obj) Return non-zero when OBJ is a vector, otherwise return ‘zero’. 6.6.10.3 Accessing and Modifying Vector Contents ................................................ ‘vector-length’ and ‘vector-ref’ return information about a given vector, respectively its size and the elements that are contained in the vector. -- Scheme Procedure: vector-length vector -- C Function: scm_vector_length (vector) Return the number of elements in VECTOR as an exact integer. -- C Function: size_t scm_c_vector_length (SCM vec) Return the number of elements in VEC as a ‘size_t’. -- Scheme Procedure: vector-ref vec k -- C Function: scm_vector_ref (vec, k) Return the contents of position K of VEC. K must be a valid index of VEC. (vector-ref #(1 1 2 3 5 8 13 21) 5) ⇒ 8 (vector-ref #(1 1 2 3 5 8 13 21) (let ((i (round (* 2 (acos -1))))) (if (inexact? i) (inexact->exact i) i))) ⇒ 13 -- C Function: SCM scm_c_vector_ref (SCM vec, size_t k) Return the contents of position K (a ‘size_t’) of VEC. A vector created by one of the dynamic vector constructor procedures (*note Vector Creation::) can be modified using the following procedures. _NOTE:_ According to R5RS, it is an error to use any of these procedures on a literally read vector, because such vectors should be considered as constants. Currently, however, Guile does not detect this error. -- Scheme Procedure: vector-set! vec k obj -- C Function: scm_vector_set_x (vec, k, obj) Store OBJ in position K of VEC. K must be a valid index of VEC. The value returned by ‘vector-set!’ is unspecified. (let ((vec (vector 0 '(2 2 2 2) "Anna"))) (vector-set! vec 1 '("Sue" "Sue")) vec) ⇒ #(0 ("Sue" "Sue") "Anna") -- C Function: void scm_c_vector_set_x (SCM vec, size_t k, SCM obj) Store OBJ in position K (a ‘size_t’) of VEC. -- Scheme Procedure: vector-fill! vec fill [start [end]] -- C Function: scm_vector_fill_x (vec, fill) Store FILL in every position of VEC in the range [START ... END). START defaults to 0 and END defaults to the length of VEC. The value returned by ‘vector-fill!’ is unspecified. -- Scheme Procedure: vector-copy vec [start [end]] -- C Function: scm_vector_copy (vec) Returns a freshly allocated vector containing the elements of VEC in the range [START ... END). START defaults to 0 and END defaults to the length of VEC. -- Scheme Procedure: vector-copy! dst at src [start [end]] Copy the block of elements from vector SRC in the range [START ... END) into vector DST, starting at position AT. AT and START default to 0 and END defaults to the length of SRC. It is an error for DST to have a length less than AT + (END - START). The order in which elements are copied is unspecified, except that if the source and destination overlap, copying takes place as if the source is first copied into a temporary vector and then into the destination. The value returned by ‘vector-copy!’ is unspecified. -- Scheme Procedure: vector-move-left! vec1 start1 end1 vec2 start2 -- C Function: scm_vector_move_left_x (vec1, start1, end1, vec2, start2) Copy elements from VEC1, positions START1 to END1, to VEC2 starting at position START2. START1 and START2 are inclusive indices; END1 is exclusive. ‘vector-move-left!’ copies elements in leftmost order. Therefore, in the case where VEC1 and VEC2 refer to the same vector, ‘vector-move-left!’ is usually appropriate when START1 is greater than START2. The value returned by ‘vector-move-left!’ is unspecified. -- Scheme Procedure: vector-move-right! vec1 start1 end1 vec2 start2 -- C Function: scm_vector_move_right_x (vec1, start1, end1, vec2, start2) Copy elements from VEC1, positions START1 to END1, to VEC2 starting at position START2. START1 and START2 are inclusive indices; END1 is exclusive. ‘vector-move-right!’ copies elements in rightmost order. Therefore, in the case where VEC1 and VEC2 refer to the same vector, ‘vector-move-right!’ is usually appropriate when START1 is less than START2. The value returned by ‘vector-move-right!’ is unspecified. 6.6.10.4 Vector Accessing from C ................................ A vector can be read and modified from C with the functions *note ‘scm_c_vector_ref’: x-scm_c_vector_ref. and *note ‘scm_c_vector_set_x’: x-scm_c_vector_set_x. In addition to these functions, there are two other ways to access vectors from C that might be more efficient in certain situations: you can use the unsafe _vector macros_; or you can use the general framework for accessing all kinds of arrays (*note Accessing Arrays from C::), which is more verbose, but can deal efficiently with all kinds of vectors (and arrays). For arrays of rank 1 whose backing store is a vector, you can use the ‘scm_vector_elements’ and ‘scm_vector_writable_elements’ functions as shortcuts. -- C Macro: size_t SCM_SIMPLE_VECTOR_LENGTH (SCM vec) Evaluates to the length of the vector VEC. No type checking is done. -- C Macro: SCM SCM_SIMPLE_VECTOR_REF (SCM vec, size_t idx) Evaluates to the element at position IDX in the vector VEC. No type or range checking is done. -- C Macro: void SCM_SIMPLE_VECTOR_SET (SCM vec, size_t idx, SCM val) Sets the element at position IDX in the vector VEC to VAL. No type or range checking is done. -- C Function: const SCM * scm_vector_elements (SCM array, scm_t_array_handle *handle, size_t *lenp, ssize_t *incp) Acquire a *note handle: Accessing Arrays from C. for ARRAY and return a read-only pointer to its elements. ARRAY must be either a vector, or an array of rank 1 whose backing store is a vector; otherwise an error is signaled. The handle must eventually be released with *note ‘scm_array_handle_release’: x-scm_array_handle_release. The variables pointed to by LENP and INCP are filled with the number of elements of the array and the increment (number of elements) between successive elements, respectively. Successive elements of ARRAY need not be contiguous in their underlying "root vector" returned here; hence the increment is not necessarily equal to 1 and may well be negative too (*note Shared Arrays::). The following example shows the typical way to use this function. It creates a list of all elements of ARRAY (in reverse order). scm_t_array_handle handle; size_t i, len; ssize_t inc; const SCM *elt; SCM list; elt = scm_vector_elements (array, &handle, &len, &inc); list = SCM_EOL; for (i = 0; i < len; i++, elt += inc) list = scm_cons (*elt, list); scm_array_handle_release (&handle); -- C Function: SCM * scm_vector_writable_elements (SCM array, scm_t_array_handle *handle, size_t *lenp, ssize_t *incp) Like ‘scm_vector_elements’ but the pointer can be used to modify the array. The following example shows the typical way to use this function. It fills an array with ‘#t’. scm_t_array_handle handle; size_t i, len; ssize_t inc; SCM *elt; elt = scm_vector_writable_elements (array, &handle, &len, &inc); for (i = 0; i < len; i++, elt += inc) *elt = SCM_BOOL_T; scm_array_handle_release (&handle); 6.6.10.5 Uniform Numeric Vectors ................................ A uniform numeric vector is a vector whose elements are all of a single numeric type. Guile offers uniform numeric vectors for signed and unsigned 8-bit, 16-bit, 32-bit, and 64-bit integers, two sizes of floating point values, and complex floating-point numbers of these two sizes. *Note SRFI-4::, for more information. For many purposes, bytevectors work just as well as uniform vectors, and have the advantage that they integrate well with binary input and output. *Note Bytevectors::, for more information on bytevectors. 6.6.11 Bit Vectors ------------------ Bit vectors are zero-origin, one-dimensional arrays of booleans. They are displayed as a sequence of ‘0’s and ‘1’s prefixed by ‘#*’, e.g., (make-bitvector 8 #f) ⇒ #*00000000 Bit vectors are the special case of one dimensional bit arrays, and can thus be used with the array procedures, *Note Arrays::. -- Scheme Procedure: bitvector? obj Return ‘#t’ when OBJ is a bitvector, else return ‘#f’. -- Scheme Procedure: make-bitvector len [fill] Create a new bitvector of length LEN and optionally initialize all elements to FILL. -- Scheme Procedure: bitvector bit ... Create a new bitvector with the arguments as elements. -- Scheme Procedure: bitvector-length vec Return the length of the bitvector VEC. -- Scheme Procedure: bitvector-bit-set? vec idx -- Scheme Procedure: bitvector-bit-clear? vec idx Return ‘#t’ if the bit at index IDX of the bitvector VEC is set (for ‘bitvector-bit-set?’) or clear (for ‘bitvector-bit-clear?’). -- Scheme Procedure: bitvector-set-bit! vec idx -- Scheme Procedure: bitvector-clear-bit! vec idx Set (for ‘bitvector-set-bit!’) or clear (for ‘bitvector-clear-bit!’) the bit at index IDX of the bitvector VEC. -- Scheme Procedure: bitvector-set-all-bits! vec -- Scheme Procedure: bitvector-clear-all-bits! vec -- Scheme Procedure: bitvector-flip-all-bits! vec Set, clear, or flip all bits of VEC. -- Scheme Procedure: list->bitvector list -- C Function: scm_list_to_bitvector (list) Return a new bitvector initialized with the elements of LIST. -- Scheme Procedure: bitvector->list vec -- C Function: scm_bitvector_to_list (vec) Return a new list initialized with the elements of the bitvector VEC. -- Scheme Procedure: bitvector-copy bitvector [start [end]] -- C Function: scm_bitvector_copy (bitvector, start, end) Returns a freshly allocated bitvector containing the elements of BITVECTOR in the range [START ... END). START defaults to 0 and END defaults to the length of BITVECTOR. -- Scheme Procedure: bitvector-count bitvector Return a count of how many entries in BITVECTOR are set. (bitvector-count #*000111000) ⇒ 3 -- Scheme Procedure: bitvector-count-bits bitvector bits Return a count of how many entries in BITVECTOR are set, with the bitvector BITS selecting the entries to consider. BITVECTOR must be at least as long as BITS. For example, (bitvector-count-bits #*01110111 #*11001101) ⇒ 3 -- Scheme Procedure: bitvector-position bitvector bool start -- C Function: scm_bitvector_position (bitvector, bool, start) Return the index of the first occurrence of BOOL in BITVECTOR, starting from START. If there is no BOOL entry between START and the end of BITVECTOR, then return ‘#f’. For example, (bitvector-position #*000101 #t 0) ⇒ 3 (bitvector-position #*0001111 #f 3) ⇒ #f -- Scheme Procedure: bitvector-set-bits! bitvector bits Set entries of BITVECTOR to ‘#t’, with BITS selecting the bits to set. The return value is unspecified. BITVECTOR must be at least as long as BITS. (define bv (bitvector-copy #*11000010)) (bitvector-set-bits! bv #*10010001) bv ⇒ #*11010011 -- Scheme Procedure: bitvector-clear-bits! bitvector bits Set entries of BITVECTOR to ‘#f’, with BITS selecting the bits to clear. The return value is unspecified. BITVECTOR must be at least as long as BITS. (define bv (bitvector-copy #*11000010)) (bitvector-clear-bits! bv #*10010001) bv ⇒ #*01000010 -- C Function: int scm_is_bitvector (SCM obj) -- C Function: SCM scm_c_make_bitvector (size_t len, SCM fill) -- C Function: int scm_bitvector_bit_is_set (SCM vec, size_t idx) -- C Function: int scm_bitvector_bit_is_clear (SCM vec, size_t idx) -- C Function: void scm_c_bitvector_set_bit_x (SCM vec, size_t idx) -- C Function: void scm_c_bitvector_clear_bit_x (SCM vec, size_t idx) -- C Function: void scm_c_bitvector_set_bits_x (SCM vec, SCM bits) -- C Function: void scm_c_bitvector_clear_bits_x (SCM vec, SCM bits) -- C Function: void scm_c_bitvector_set_all_bits_x (SCM vec) -- C Function: void scm_c_bitvector_clear_all_bits_x (SCM vec) -- C Function: void scm_c_bitvector_flip_all_bits_x (SCM vec) -- C Function: size_t scm_c_bitvector_length (SCM bitvector) -- C Function: size_t scm_c_bitvector_count (SCM bitvector) -- C Function: size_t scm_c_bitvector_count_bits (SCM bitvector, SCM bits) C API for the corresponding Scheme bitvector interfaces. -- C Function: const scm_t_uint32 * scm_bitvector_elements (SCM vec, scm_t_array_handle *handle, size_t *offp, size_t *lenp, ssize_t *incp) Like ‘scm_vector_elements’ (*note Vector Accessing from C::), but for bitvectors. The variable pointed to by OFFP is set to the value returned by ‘scm_array_handle_bit_elements_offset’. See ‘scm_array_handle_bit_elements’ for how to use the returned pointer and the offset. -- C Function: scm_t_uint32 * scm_bitvector_writable_elements (SCM vec, scm_t_array_handle *handle, size_t *offp, size_t *lenp, ssize_t *incp) Like ‘scm_bitvector_elements’, but the pointer is good for reading and writing. 6.6.12 Bytevectors ------------------ A “bytevector” is a raw byte string. The ‘(rnrs bytevectors)’ module provides the programming interface specified by the Revised^6 Report on the Algorithmic Language Scheme (R6RS) (http://www.r6rs.org/). It contains procedures to manipulate bytevectors and interpret their contents in a number of ways: as signed or unsigned integer of various sizes and endianness, as IEEE-754 floating point numbers, or as strings. It is a useful tool to encode and decode binary data. The *note R7RS: R7RS Support. offers its own set of bytevector procedures (*note Bytevector Procedures in R7RS::). The R6RS (Section 4.3.4) specifies an external representation for bytevectors, whereby the octets (integers in the range 0-255) contained in the bytevector are represented as a list prefixed by ‘#vu8’: #vu8(1 53 204) denotes a 3-byte bytevector containing the octets 1, 53, and 204. Like string literals, booleans, etc., bytevectors are "self-quoting", i.e., they do not need to be quoted: #vu8(1 53 204) ⇒ #vu8(1 53 204) Bytevectors can be used with the binary input/output primitives (*note Binary I/O::). 6.6.12.1 Endianness ................... Some of the following procedures take an ENDIANNESS parameter. The “endianness” is defined as the order of bytes in multi-byte numbers: numbers encoded in “big endian” have their most significant bytes written first, whereas numbers encoded in “little endian” have their least significant bytes first(1). Little-endian is the native endianness of the IA32 architecture and its derivatives, while big-endian is native to SPARC and PowerPC, among others. The ‘native-endianness’ procedure returns the native endianness of the machine it runs on. -- Scheme Procedure: native-endianness -- C Function: scm_native_endianness () Return a value denoting the native endianness of the host machine. -- Scheme Macro: endianness symbol Return an object denoting the endianness specified by SYMBOL. If SYMBOL is neither ‘big’ nor ‘little’ then an error is raised at expand-time. -- C Variable: scm_endianness_big -- C Variable: scm_endianness_little The objects denoting big- and little-endianness, respectively. ---------- Footnotes ---------- (1) Big-endian and little-endian are the most common "endiannesses", but others do exist. For instance, the GNU MP library allows “word order” to be specified independently of “byte order” (*note (gmp)Integer Import and Export::). 6.6.12.2 Manipulating Bytevectors ................................. Bytevectors can be created, copied, and analyzed with the following procedures and C functions. -- Scheme Procedure: make-bytevector len [fill] -- C Function: scm_make_bytevector (len, fill) -- C Function: scm_c_make_bytevector (size_t len) Return a new bytevector of LEN bytes. Optionally, if FILL is given, fill it with FILL; FILL must be in the range [-128,255]. -- Scheme Procedure: bytevector? obj -- C Function: scm_bytevector_p (obj) Return true if OBJ is a bytevector. -- C Function: int scm_is_bytevector (SCM obj) Equivalent to ‘scm_is_true (scm_bytevector_p (obj))’. -- Scheme Procedure: bytevector-length bv -- C Function: scm_bytevector_length (bv) Return the length in bytes of bytevector BV. -- C Function: size_t scm_c_bytevector_length (SCM bv) Likewise, return the length in bytes of bytevector BV. -- Scheme Procedure: bytevector=? bv1 bv2 -- C Function: scm_bytevector_eq_p (bv1, bv2) Return ‘#t’ if BV1 equals BV2--i.e., if they have the same length and contents. -- Scheme Procedure: bytevector-fill! bv fill [start [end]] -- C Function: scm_bytevector_fill_x (bv, fill) Fill positions [START ... END) of bytevector BV with byte FILL. START defaults to 0 and END defaults to the length of BV.(1) -- Scheme Procedure: bytevector-copy! source source-start target target-start len -- C Function: scm_bytevector_copy_x (source, source_start, target, target_start, len) Copy LEN bytes from SOURCE into TARGET, starting reading from SOURCE-START (an index index within SOURCE) and writing at TARGET-START. It is permitted for the SOURCE and TARGET regions to overlap. In that case, copying takes place as if the source is first copied into a temporary bytevector and then into the destination. -- Scheme Procedure: bytevector-copy bv -- C Function: scm_bytevector_copy (bv) Return a newly allocated copy of BV. -- C Function: scm_t_uint8 scm_c_bytevector_ref (SCM bv, size_t index) Return the byte at INDEX in bytevector BV. -- C Function: void scm_c_bytevector_set_x (SCM bv, size_t index, scm_t_uint8 value) Set the byte at INDEX in BV to VALUE. Low-level C macros are available. They do not perform any type-checking; as such they should be used with care. -- C Macro: size_t SCM_BYTEVECTOR_LENGTH (bv) Return the length in bytes of bytevector BV. -- C Macro: signed char * SCM_BYTEVECTOR_CONTENTS (bv) Return a pointer to the contents of bytevector BV. ---------- Footnotes ---------- (1) R6RS only defines ‘(bytevector-fill! bv fill)’. Arguments START and END are a Guile extension (cf. *note ‘vector-fill!’: x-vector-fill!, *note ‘string-fill!’: x-string-fill!.). 6.6.12.3 Interpreting Bytevector Contents as Integers ..................................................... The contents of a bytevector can be interpreted as a sequence of integers of any given size, sign, and endianness. (let ((bv (make-bytevector 4))) (bytevector-u8-set! bv 0 #x12) (bytevector-u8-set! bv 1 #x34) (bytevector-u8-set! bv 2 #x56) (bytevector-u8-set! bv 3 #x78) (map (lambda (number) (number->string number 16)) (list (bytevector-u8-ref bv 0) (bytevector-u16-ref bv 0 (endianness big)) (bytevector-u32-ref bv 0 (endianness little))))) ⇒ ("12" "1234" "78563412") The most generic procedures to interpret bytevector contents as integers are described below. -- Scheme Procedure: bytevector-uint-ref bv index endianness size -- C Function: scm_bytevector_uint_ref (bv, index, endianness, size) Return the SIZE-byte long unsigned integer at index INDEX in BV, decoded according to ENDIANNESS. -- Scheme Procedure: bytevector-sint-ref bv index endianness size -- C Function: scm_bytevector_sint_ref (bv, index, endianness, size) Return the SIZE-byte long signed integer at index INDEX in BV, decoded according to ENDIANNESS. -- Scheme Procedure: bytevector-uint-set! bv index value endianness size -- C Function: scm_bytevector_uint_set_x (bv, index, value, endianness, size) Set the SIZE-byte long unsigned integer at INDEX to VALUE, encoded according to ENDIANNESS. -- Scheme Procedure: bytevector-sint-set! bv index value endianness size -- C Function: scm_bytevector_sint_set_x (bv, index, value, endianness, size) Set the SIZE-byte long signed integer at INDEX to VALUE, encoded according to ENDIANNESS. The following procedures are similar to the ones above, but specialized to a given integer size: -- Scheme Procedure: bytevector-u8-ref bv index -- Scheme Procedure: bytevector-s8-ref bv index -- Scheme Procedure: bytevector-u16-ref bv index endianness -- Scheme Procedure: bytevector-s16-ref bv index endianness -- Scheme Procedure: bytevector-u32-ref bv index endianness -- Scheme Procedure: bytevector-s32-ref bv index endianness -- Scheme Procedure: bytevector-u64-ref bv index endianness -- Scheme Procedure: bytevector-s64-ref bv index endianness -- C Function: scm_bytevector_u8_ref (bv, index) -- C Function: scm_bytevector_s8_ref (bv, index) -- C Function: scm_bytevector_u16_ref (bv, index, endianness) -- C Function: scm_bytevector_s16_ref (bv, index, endianness) -- C Function: scm_bytevector_u32_ref (bv, index, endianness) -- C Function: scm_bytevector_s32_ref (bv, index, endianness) -- C Function: scm_bytevector_u64_ref (bv, index, endianness) -- C Function: scm_bytevector_s64_ref (bv, index, endianness) Return the unsigned N-bit (signed) integer (where N is 8, 16, 32 or 64) from BV at INDEX, decoded according to ENDIANNESS. -- Scheme Procedure: bytevector-u8-set! bv index value -- Scheme Procedure: bytevector-s8-set! bv index value -- Scheme Procedure: bytevector-u16-set! bv index value endianness -- Scheme Procedure: bytevector-s16-set! bv index value endianness -- Scheme Procedure: bytevector-u32-set! bv index value endianness -- Scheme Procedure: bytevector-s32-set! bv index value endianness -- Scheme Procedure: bytevector-u64-set! bv index value endianness -- Scheme Procedure: bytevector-s64-set! bv index value endianness -- C Function: scm_bytevector_u8_set_x (bv, index, value) -- C Function: scm_bytevector_s8_set_x (bv, index, value) -- C Function: scm_bytevector_u16_set_x (bv, index, value, endianness) -- C Function: scm_bytevector_s16_set_x (bv, index, value, endianness) -- C Function: scm_bytevector_u32_set_x (bv, index, value, endianness) -- C Function: scm_bytevector_s32_set_x (bv, index, value, endianness) -- C Function: scm_bytevector_u64_set_x (bv, index, value, endianness) -- C Function: scm_bytevector_s64_set_x (bv, index, value, endianness) Store VALUE as an N-bit (signed) integer (where N is 8, 16, 32 or 64) in BV at INDEX, encoded according to ENDIANNESS. Finally, a variant specialized for the host's endianness is available for each of these functions (with the exception of the ‘u8’ and ‘s8’ accessors, as endianness is about byte order and there is only 1 byte): -- Scheme Procedure: bytevector-u16-native-ref bv index -- Scheme Procedure: bytevector-s16-native-ref bv index -- Scheme Procedure: bytevector-u32-native-ref bv index -- Scheme Procedure: bytevector-s32-native-ref bv index -- Scheme Procedure: bytevector-u64-native-ref bv index -- Scheme Procedure: bytevector-s64-native-ref bv index -- C Function: scm_bytevector_u16_native_ref (bv, index) -- C Function: scm_bytevector_s16_native_ref (bv, index) -- C Function: scm_bytevector_u32_native_ref (bv, index) -- C Function: scm_bytevector_s32_native_ref (bv, index) -- C Function: scm_bytevector_u64_native_ref (bv, index) -- C Function: scm_bytevector_s64_native_ref (bv, index) Return the unsigned N-bit (signed) integer (where N is 8, 16, 32 or 64) from BV at INDEX, decoded according to the host's native endianness. -- Scheme Procedure: bytevector-u16-native-set! bv index value -- Scheme Procedure: bytevector-s16-native-set! bv index value -- Scheme Procedure: bytevector-u32-native-set! bv index value -- Scheme Procedure: bytevector-s32-native-set! bv index value -- Scheme Procedure: bytevector-u64-native-set! bv index value -- Scheme Procedure: bytevector-s64-native-set! bv index value -- C Function: scm_bytevector_u16_native_set_x (bv, index, value) -- C Function: scm_bytevector_s16_native_set_x (bv, index, value) -- C Function: scm_bytevector_u32_native_set_x (bv, index, value) -- C Function: scm_bytevector_s32_native_set_x (bv, index, value) -- C Function: scm_bytevector_u64_native_set_x (bv, index, value) -- C Function: scm_bytevector_s64_native_set_x (bv, index, value) Store VALUE as an N-bit (signed) integer (where N is 8, 16, 32 or 64) in BV at INDEX, encoded according to the host's native endianness. 6.6.12.4 Converting Bytevectors to/from Integer Lists ..................................................... Bytevector contents can readily be converted to/from lists of signed or unsigned integers: (bytevector->sint-list (u8-list->bytevector (make-list 4 255)) (endianness little) 2) ⇒ (-1 -1) -- Scheme Procedure: bytevector->u8-list bv -- C Function: scm_bytevector_to_u8_list (bv) Return a newly allocated list of unsigned 8-bit integers from the contents of BV. -- Scheme Procedure: u8-list->bytevector lst -- C Function: scm_u8_list_to_bytevector (lst) Return a newly allocated bytevector consisting of the unsigned 8-bit integers listed in LST. -- Scheme Procedure: bytevector->uint-list bv endianness size -- C Function: scm_bytevector_to_uint_list (bv, endianness, size) Return a list of unsigned integers of SIZE bytes representing the contents of BV, decoded according to ENDIANNESS. -- Scheme Procedure: bytevector->sint-list bv endianness size -- C Function: scm_bytevector_to_sint_list (bv, endianness, size) Return a list of signed integers of SIZE bytes representing the contents of BV, decoded according to ENDIANNESS. -- Scheme Procedure: uint-list->bytevector lst endianness size -- C Function: scm_uint_list_to_bytevector (lst, endianness, size) Return a new bytevector containing the unsigned integers listed in LST and encoded on SIZE bytes according to ENDIANNESS. -- Scheme Procedure: sint-list->bytevector lst endianness size -- C Function: scm_sint_list_to_bytevector (lst, endianness, size) Return a new bytevector containing the signed integers listed in LST and encoded on SIZE bytes according to ENDIANNESS. 6.6.12.5 Interpreting Bytevector Contents as Floating Point Numbers ................................................................... Bytevector contents can also be accessed as IEEE-754 single- or double-precision floating point numbers (respectively 32 and 64-bit long) using the procedures described here. -- Scheme Procedure: bytevector-ieee-single-ref bv index endianness -- Scheme Procedure: bytevector-ieee-double-ref bv index endianness -- C Function: scm_bytevector_ieee_single_ref (bv, index, endianness) -- C Function: scm_bytevector_ieee_double_ref (bv, index, endianness) Return the IEEE-754 single-precision floating point number from BV at INDEX according to ENDIANNESS. -- Scheme Procedure: bytevector-ieee-single-set! bv index value endianness -- Scheme Procedure: bytevector-ieee-double-set! bv index value endianness -- C Function: scm_bytevector_ieee_single_set_x (bv, index, value, endianness) -- C Function: scm_bytevector_ieee_double_set_x (bv, index, value, endianness) Store real number VALUE in BV at INDEX according to ENDIANNESS. Specialized procedures are also available: -- Scheme Procedure: bytevector-ieee-single-native-ref bv index -- Scheme Procedure: bytevector-ieee-double-native-ref bv index -- C Function: scm_bytevector_ieee_single_native_ref (bv, index) -- C Function: scm_bytevector_ieee_double_native_ref (bv, index) Return the IEEE-754 single-precision floating point number from BV at INDEX according to the host's native endianness. -- Scheme Procedure: bytevector-ieee-single-native-set! bv index value -- Scheme Procedure: bytevector-ieee-double-native-set! bv index value -- C Function: scm_bytevector_ieee_single_native_set_x (bv, index, value) -- C Function: scm_bytevector_ieee_double_native_set_x (bv, index, value) Store real number VALUE in BV at INDEX according to the host's native endianness. 6.6.12.6 Interpreting Bytevector Contents as Unicode Strings ............................................................ Bytevector contents can also be interpreted as Unicode strings encoded in one of the most commonly available encoding formats. *Note Representing Strings as Bytes::, for a more generic interface. (utf8->string (u8-list->bytevector '(99 97 102 101))) ⇒ "cafe" (string->utf8 "café") ;; SMALL LATIN LETTER E WITH ACUTE ACCENT ⇒ #vu8(99 97 102 195 169) -- Scheme Procedure: string-utf8-length str -- C function: SCM scm_string_utf8_length (str) -- C function: size_t scm_c_string_utf8_length (str) Return the number of bytes in the UTF-8 representation of STR. -- Scheme Procedure: string->utf8 str -- Scheme Procedure: string->utf16 str [endianness] -- Scheme Procedure: string->utf32 str [endianness] -- C Function: scm_string_to_utf8 (str) -- C Function: scm_string_to_utf16 (str, endianness) -- C Function: scm_string_to_utf32 (str, endianness) Return a newly allocated bytevector that contains the UTF-8, UTF-16, or UTF-32 (aka. UCS-4) encoding of STR. For UTF-16 and UTF-32, ENDIANNESS should be the symbol ‘big’ or ‘little’; when omitted, it defaults to big endian. -- Scheme Procedure: utf8->string utf -- Scheme Procedure: utf16->string utf [endianness] -- Scheme Procedure: utf32->string utf [endianness] -- C Function: scm_utf8_to_string (utf) -- C Function: scm_utf16_to_string (utf, endianness) -- C Function: scm_utf32_to_string (utf, endianness) Return a newly allocated string that contains from the UTF-8-, UTF-16-, or UTF-32-decoded contents of bytevector UTF. For UTF-16 and UTF-32, ENDIANNESS should be the symbol ‘big’ or ‘little’; when omitted, it defaults to big endian. 6.6.12.7 Accessing Bytevectors with the Array API ................................................. As an extension to the R6RS, Guile allows bytevectors to be manipulated with the “array” procedures (*note Arrays::). When using these APIs, bytes are accessed one at a time as 8-bit unsigned integers: (define bv #vu8(0 1 2 3)) (array? bv) ⇒ #t (array-rank bv) ⇒ 1 (array-ref bv 2) ⇒ 2 ;; Note the different argument order on array-set!. (array-set! bv 77 2) (array-ref bv 2) ⇒ 77 (array-type bv) ⇒ vu8 6.6.12.8 Accessing Bytevectors with the SRFI-4 API .................................................. Bytevectors may also be accessed with the SRFI-4 API. *Note SRFI-4 and Bytevectors::, for more information. 6.6.12.9 Bytevector Procedures in R7RS ...................................... The *note R7RS: R7RS Support. (Section 6.9) defines a set of bytevector manipulation procedures, accessible with (use-modules (scheme base)) Of these, *note ‘make-bytevector’: x-make-bytevector, *note ‘bytevector?’: x-bytevector?, *note ‘bytevector-length’: x-bytevector-length, *note ‘bytevector-u8-ref’: x-bytevector-u8-ref. and *note ‘bytevector-u8-set!’: x-bytevector-u8-set!. have the same definition as in R6RS. The procedures listed below either have a different definition in R7RS and R6RS, or are not defined in R6RS. -- Scheme Procedure: bytevector arg ... Return a newly allocated bytevector composed of the given arguments. Analogous to ‘list’. (bytevector 2 3 4) ⇒ #vu8(2 3 4) See also *note ‘u8-list->bytevector’: x-u8-list->bytevector. -- Scheme Procedure: bytevector-copy bv [start [end]] Returns a newly allocated bytevector containing the elements of BV in the range [START ... END). START defaults to 0 and END defaults to the length of BV. (define bv #vu8(0 1 2 3 4 5)) (bytevector-copy bv) ⇒ #vu8(0 1 2 3 4 5) (bytevector-copy bv 2) ⇒ #vu8(2 3 4 5) (bytevector-copy bv 2 4) ⇒ #vu8(2 3) See also *note the R6RS version: x-r6:bytevector-copy. -- Scheme Procedure: bytevector-copy! dst at src [start [end]] Copy the block of elements from bytevector SRC in the range [START ... END) into bytevector DST, starting at position AT. START defaults to 0 and END defaults to the length of SRC. It is an error for DST to have a length less than AT + (END - START). See also *note the R6RS version: x-r6:bytevector-copy!. With (use-modules ((rnrs bytevectors) #:prefix r6:) ((scheme base) #:prefix r7:)) the following calls are equivalent: (r6:bytevector-copy! source source-start target target-start len) (r7:bytevector-copy! target target-start source source-start (+ source-start len)) -- Scheme Procedure: bytevector-append arg ... Return a newly allocated bytevector whose characters form the concatenation of the given bytevectors ARG ... (bytevector-append #vu8(0 1 2) #vu8(3 4 5)) ⇒ #vu8(0 1 2 3 4 5) 6.6.12.10 Bytevector Slices ........................... As an extension to the R6RS specification, the ‘(rnrs bytevectors gnu)’ module provides the ‘bytevector-slice’ procedure, which returns a bytevector aliasing part of an existing bytevector. -- Scheme Procedure: bytevector-slice BV OFFSET [SIZE] -- C Function: scm_bytevector_slice (BV, OFFSET, SIZE) Return the slice of BV starting at OFFSET and counting SIZE bytes. When SIZE is omitted, the slice covers all of BV starting from OFFSET. The returned slice shares storage with BV: changes to the slice are visible in BV and vice-versa. When BV is actually a SRFI-4 uniform vector, its element type is preserved unless OFFSET and SIZE are not aligned on its element type size. Here is an example showing how to use it: (use-modules (rnrs bytevectors) (rnrs bytevectors gnu)) (define bv (u8-list->bytevector (iota 10))) (define slice (bytevector-slice bv 2 3)) slice ⇒ #vu8(2 3 4) (bytevector-u8-set! slice 0 77) slice ⇒ #vu8(77 3 4) bv ⇒ #vu8(0 1 77 3 4 5 6 7 8 9) 6.6.13 Arrays ------------- “Arrays” are a collection of cells organized into an arbitrary number of dimensions. Each cell can be accessed in constant time by supplying an index for each dimension. In the current implementation, an array uses a vector of some kind for the actual storage of its elements. Any kind of vector will do, so you can have arrays of uniform numeric values, arrays of characters, arrays of bits, and of course, arrays of arbitrary Scheme values. For example, arrays with an underlying ‘c64vector’ might be nice for digital signal processing, while arrays made from a ‘u8vector’ might be used to hold gray-scale images. The number of dimensions of an array is called its “rank”. Thus, a matrix is an array of rank 2, while a vector has rank 1. When accessing an array element, you have to specify one exact integer for each dimension. These integers are called the “indices” of the element. An array specifies the allowed range of indices for each dimension via an inclusive lower and upper bound. These bounds can well be negative, but the upper bound must be greater than or equal to the lower bound minus one. When all lower bounds of an array are zero, it is called a “zero-origin” array. Arrays can be of rank 0, which could be interpreted as a scalar. Thus, a zero-rank array can store exactly one object and the list of indices of this element is the empty list. Arrays contain zero elements when one of their dimensions has a zero length. These empty arrays maintain information about their shape: a matrix with zero columns and 3 rows is different from a matrix with 3 columns and zero rows, which again is different from a vector of length zero. The array procedures are all polymorphic, treating strings, uniform numeric vectors, bytevectors, bit vectors and ordinary vectors as one dimensional arrays. 6.6.13.1 Array Syntax ..................... An array is displayed as ‘#’ followed by its rank, followed by a tag that describes the underlying vector, optionally followed by information about its shape, and finally followed by the cells, organized into dimensions using parentheses. In more words, the array tag is of the form #<@lower><:len><@lower><:len>... where ‘’ is a positive integer in decimal giving the rank of the array. It is omitted when the rank is 1 and the array is non-shared and has zero-origin (see below). For shared arrays and for a non-zero origin, the rank is always printed even when it is 1 to distinguish them from ordinary vectors. The ‘’ part is the tag for a uniform numeric vector, like ‘u8’, ‘s16’, etc, ‘b’ for bitvectors, or ‘a’ for strings. It is empty for ordinary vectors. The ‘<@lower>’ part is a ‘@’ character followed by a signed integer in decimal giving the lower bound of a dimension. There is one ‘<@lower>’ for each dimension. When all lower bounds are zero, all ‘<@lower>’ parts are omitted. The ‘<:len>’ part is a ‘:’ character followed by an unsigned integer in decimal giving the length of a dimension. Like for the lower bounds, there is one ‘<:len>’ for each dimension, and the ‘<:len>’ part always follows the ‘<@lower>’ part for a dimension. Lengths are only then printed when they can't be deduced from the nested lists of elements of the array literal, which can happen when at least one length is zero. As a special case, an array of rank 0 is printed as ‘#0()’, where ‘’ is the result of printing the single element of the array. Thus, ‘#(1 2 3)’ is an ordinary array of rank 1 with lower bound 0 in dimension 0. (I.e., a regular vector.) ‘#@2(1 2 3)’ is an ordinary array of rank 1 with lower bound 2 in dimension 0. ‘#2((1 2 3) (4 5 6))’ is a non-uniform array of rank 2; a 2x3 matrix with index ranges 0..1 and 0..2. ‘#u8(0 1 2)’ is a uniform u8 array of rank 1. ‘#2u32@2@3((1 2) (2 3))’ is a uniform u32 array of rank 2 with index ranges 2..3 and 3..4. ‘#2()’ is a two-dimensional array with index ranges 0..-1 and 0..-1, i.e. both dimensions have length zero. ‘#2:0:2()’ is a two-dimensional array with index ranges 0..-1 and 0..1, i.e. the first dimension has length zero, but the second has length 2. ‘#0(12)’ is a rank-zero array with contents 12. In addition, bytevectors are also arrays, but use a different syntax (*note Bytevectors::): ‘#vu8(1 2 3)’ is a 3-byte long bytevector, with contents 1, 2, 3. 6.6.13.2 Array Procedures ......................... When an array is created, the range of each dimension must be specified, e.g., to create a 2x3 array with a zero-based index: (make-array 'ho 2 3) ⇒ #2((ho ho ho) (ho ho ho)) The range of each dimension can also be given explicitly, e.g., another way to create the same array: (make-array 'ho '(0 1) '(0 2)) ⇒ #2((ho ho ho) (ho ho ho)) The following procedures can be used with arrays (or vectors). An argument shown as IDX... means one parameter for each dimension in the array. A IDXLIST argument means a list of such values, one for each dimension. -- Scheme Procedure: array? obj -- C Function: scm_array_p (obj, unused) Return ‘#t’ if the OBJ is an array, and ‘#f’ if not. The second argument to scm_array_p is there for historical reasons, but it is not used. You should always pass ‘SCM_UNDEFINED’ as its value. -- Scheme Procedure: typed-array? obj type -- C Function: scm_typed_array_p (obj, type) Return ‘#t’ if the OBJ is an array of type TYPE, and ‘#f’ if not. -- C Function: int scm_is_array (SCM obj) Return ‘1’ if the OBJ is an array and ‘0’ if not. -- C Function: int scm_is_typed_array (SCM obj, SCM type) Return ‘0’ if the OBJ is an array of type TYPE, and ‘1’ if not. -- Scheme Procedure: make-array fill bound ... -- C Function: scm_make_array (fill, bounds) Equivalent to ‘(make-typed-array #t FILL BOUND ...)’. -- Scheme Procedure: make-typed-array type fill bound ... -- C Function: scm_make_typed_array (type, fill, bounds) Create and return an array that has as many dimensions as there are BOUNDs and (maybe) fill it with FILL. The underlying storage vector is created according to TYPE, which must be a symbol whose name is the 'vectag' of the array as explained above, or ‘#t’ for ordinary, non-specialized arrays. For example, using the symbol ‘f64’ for TYPE will create an array that uses a ‘f64vector’ for storing its elements, and ‘a’ will use a string. When FILL is not the special _unspecified_ value, the new array is filled with FILL. Otherwise, the initial contents of the array is unspecified. The special _unspecified_ value is stored in the variable ‘*unspecified*’ so that for example ‘(make-typed-array 'u32 *unspecified* 4)’ creates a uninitialized ‘u32’ vector of length 4. Each BOUND may be a positive non-zero integer N, in which case the index for that dimension can range from 0 through N-1; or an explicit index range specifier in the form ‘(LOWER UPPER)’, where both LOWER and UPPER are integers, possibly less than zero, and possibly the same number (however, LOWER cannot be greater than UPPER). -- Scheme Procedure: list->array dimspec list Equivalent to ‘(list->typed-array #t DIMSPEC LIST)’. -- Scheme Procedure: list->typed-array type dimspec list -- C Function: scm_list_to_typed_array (type, dimspec, list) Return an array of the type indicated by TYPE with elements the same as those of LIST. The argument DIMSPEC determines the number of dimensions of the array and their lower bounds. When DIMSPEC is an exact integer, it gives the number of dimensions directly and all lower bounds are zero. When it is a list of exact integers, then each element is the lower index bound of a dimension, and there will be as many dimensions as elements in the list. -- Scheme Procedure: array-type array -- C Function: scm_array_type (array) Return the type of ARRAY. This is the 'vectag' used for printing ARRAY (or ‘#t’ for ordinary arrays) and can be used with ‘make-typed-array’ to create an array of the same kind as ARRAY. -- Scheme Procedure: array-ref array idx ... -- C Function: scm_array_ref (array, idxlist) Return the element at ‘(idx ...)’ in ARRAY. (define a (make-array 999 '(1 2) '(3 4))) (array-ref a 2 4) ⇒ 999 -- Scheme Procedure: array-in-bounds? array idx ... -- C Function: scm_array_in_bounds_p (array, idxlist) Return ‘#t’ if the given indices would be acceptable to ‘array-ref’. (define a (make-array #f '(1 2) '(3 4))) (array-in-bounds? a 2 3) ⇒ #t (array-in-bounds? a 0 0) ⇒ #f -- Scheme Procedure: array-set! array obj idx ... -- C Function: scm_array_set_x (array, obj, idxlist) Set the element at ‘(idx ...)’ in ARRAY to OBJ. The return value is unspecified. (define a (make-array #f '(0 1) '(0 1))) (array-set! a #t 1 1) a ⇒ #2((#f #f) (#f #t)) -- Scheme Procedure: array-shape array -- Scheme Procedure: array-dimensions array -- C Function: scm_array_dimensions (array) Return a list of the bounds for each dimension of ARRAY. ‘array-shape’ gives ‘(LOWER UPPER)’ for each dimension. ‘array-dimensions’ instead returns just UPPER+1 for dimensions with a 0 lower bound. Both are suitable as input to ‘make-array’. For example, (define a (make-array 'foo '(-1 3) 5)) (array-shape a) ⇒ ((-1 3) (0 4)) (array-dimensions a) ⇒ ((-1 3) 5) -- Scheme Procedure: array-length array -- C Function: scm_array_length (array) -- C Function: size_t scm_c_array_length (array) Return the length of an array: its first dimension. It is an error to ask for the length of an array of rank 0. -- Scheme Procedure: array-rank array -- C Function: scm_array_rank (array) Return the rank of ARRAY. -- C Function: size_t scm_c_array_rank (SCM array) Return the rank of ARRAY as a ‘size_t’. -- Scheme Procedure: array->list array -- C Function: scm_array_to_list (array) Return a list consisting of all the elements, in order, of ARRAY. -- Scheme Procedure: array-copy! src dst -- Scheme Procedure: array-copy-in-order! src dst -- C Function: scm_array_copy_x (src, dst) Copy every element from vector or array SRC to the corresponding element of DST. DST must have the same rank as SRC, and be at least as large in each dimension. The return value is unspecified. -- Scheme Procedure: array-fill! array fill -- C Function: scm_array_fill_x (array, fill) Store FILL in every element of ARRAY. The value returned is unspecified. -- Scheme Procedure: array-equal? array ... Return ‘#t’ if all arguments are arrays with the same shape, the same type, and have corresponding elements which are either ‘equal?’ or ‘array-equal?’. This function differs from ‘equal?’ (*note Equality::) in that all arguments must be arrays. -- Scheme Procedure: array-map! dst proc src ... -- Scheme Procedure: array-map-in-order! dst proc src ... -- C Function: scm_array_map_x (dst, proc, srclist) Set each element of the DST array to values obtained from calls to PROC. The list of SRC arguments may be empty. The value returned is unspecified. Each call is ‘(PROC ELEM ...)’, where each ELEM is from the corresponding SRC array, at the DST index. ‘array-map-in-order!’ makes the calls in row-major order, ‘array-map!’ makes them in an unspecified order. The SRC arrays must have the same number of dimensions as DST, and must have a range for each dimension which covers the range in DST. This ensures all DST indices are valid in each SRC. -- Scheme Procedure: array-for-each proc src1 src2 ... -- C Function: scm_array_for_each (proc, src1, srclist) Apply PROC to each tuple of elements of SRC1 SRC2 ..., in row-major order. The value returned is unspecified. -- Scheme Procedure: array-index-map! dst proc -- C Function: scm_array_index_map_x (dst, proc) Set each element of the DST array to values returned by calls to PROC. The value returned is unspecified. Each call is ‘(PROC I1 ... IN)’, where I1...IN is the destination index, one parameter for each dimension. The order in which the calls are made is unspecified. For example, to create a 4x4 matrix representing a cyclic group, / 0 1 2 3 \ | 1 2 3 0 | | 2 3 0 1 | \ 3 0 1 2 / (define a (make-array #f 4 4)) (array-index-map! a (lambda (i j) (modulo (+ i j) 4))) An additional array function is available in the module ‘(ice-9 arrays)’. It can be used with: (use-modules (ice-9 arrays)) -- Scheme Procedure: array-copy src Return a new array with the same elements, type and shape as SRC. However, the array increments may not be the same as those of SRC. In the current implementation, the returned array will be in row-major order, but that might change in the future. Use ‘array-copy!’ on an array of known order if that is a concern. 6.6.13.3 Shared Arrays ...................... -- Scheme Procedure: make-shared-array oldarray mapfunc bound ... -- C Function: scm_make_shared_array (oldarray, mapfunc, boundlist) Return a new array which shares the storage of OLDARRAY. Changes made through either affect the same underlying storage. The BOUND ... arguments are the shape of the new array, the same as ‘make-array’ (*note Array Procedures::). MAPFUNC translates coordinates from the new array to the OLDARRAY. It's called as ‘(MAPFUNC newidx1 ...)’ with one parameter for each dimension of the new array, and should return a list of indices for OLDARRAY, one for each dimension of OLDARRAY. MAPFUNC must be affine linear, meaning that each OLDARRAY index must be formed by adding integer multiples (possibly negative) of some or all of NEWIDX1 etc, plus a possible integer offset. The multiples and offset must be the same in each call. One good use for a shared array is to restrict the range of some dimensions, so as to apply say ‘array-for-each’ or ‘array-fill!’ to only part of an array. The plain ‘list’ function can be used for MAPFUNC in this case, making no changes to the index values. For example, (make-shared-array #2((a b c) (d e f) (g h i)) list 3 2) ⇒ #2((a b) (d e) (g h)) The new array can have fewer dimensions than OLDARRAY, for example to take a column from an array. (make-shared-array #2((a b c) (d e f) (g h i)) (lambda (i) (list i 2)) '(0 2)) ⇒ #1(c f i) A diagonal can be taken by using the single new array index for both row and column in the old array. For example, (make-shared-array #2((a b c) (d e f) (g h i)) (lambda (i) (list i i)) '(0 2)) ⇒ #1(a e i) Dimensions can be increased by for instance considering portions of a one dimensional array as rows in a two dimensional array. (‘array-contents’ below can do the opposite, flattening an array.) (make-shared-array #1(a b c d e f g h i j k l) (lambda (i j) (list (+ (* i 3) j))) 4 3) ⇒ #2((a b c) (d e f) (g h i) (j k l)) By negating an index the order that elements appear can be reversed. The following just reverses the column order, (make-shared-array #2((a b c) (d e f) (g h i)) (lambda (i j) (list i (- 2 j))) 3 3) ⇒ #2((c b a) (f e d) (i h g)) A fixed offset on indexes allows for instance a change from a 0 based to a 1 based array, (define x #2((a b c) (d e f) (g h i))) (define y (make-shared-array x (lambda (i j) (list (1- i) (1- j))) '(1 3) '(1 3))) (array-ref x 0 0) ⇒ a (array-ref y 1 1) ⇒ a A multiple on an index allows every Nth element of an array to be taken. The following is every third element, (make-shared-array #1(a b c d e f g h i j k l) (lambda (i) (list (* i 3))) 4) ⇒ #1(a d g j) The above examples can be combined to make weird and wonderful selections from an array, but it's important to note that because MAPFUNC must be affine linear, arbitrary permutations are not possible. In the current implementation, MAPFUNC is not called for every access to the new array but only on some sample points to establish a base and stride for new array indices in OLDARRAY data. A few sample points are enough because MAPFUNC is linear. -- Scheme Procedure: shared-array-increments array -- C Function: scm_shared_array_increments (array) For each dimension, return the distance between elements in the root vector. -- Scheme Procedure: shared-array-offset array -- C Function: scm_shared_array_offset (array) Return the root vector index of the first element in the array. -- Scheme Procedure: shared-array-root array -- C Function: scm_shared_array_root (array) Return the root vector of a shared array. -- Scheme Procedure: array-contents array [strict] -- C Function: scm_array_contents (array, strict) If ARRAY may be “unrolled” into a one dimensional shared array without changing their order (last subscript changing fastest), then ‘array-contents’ returns that shared array, otherwise it returns ‘#f’. All arrays made by ‘make-array’ and ‘make-typed-array’ may be unrolled, some arrays made by ‘make-shared-array’ may not be. If the optional argument STRICT is provided, a shared array will be returned only if its elements are stored internally contiguous in memory. -- Scheme Procedure: transpose-array array dim1 dim2 ... -- C Function: scm_transpose_array (array, dimlist) Return an array sharing contents with ARRAY, but with dimensions arranged in a different order. There must be one DIM argument for each dimension of ARRAY. DIM1, DIM2, ... should be integers between 0 and the rank of the array to be returned. Each integer in that range must appear at least once in the argument list. The values of DIM1, DIM2, ... correspond to dimensions in the array to be returned, and their positions in the argument list to dimensions of ARRAY. Several DIMs may have the same value, in which case the returned array will have smaller rank than ARRAY. (transpose-array '#2((a b) (c d)) 1 0) ⇒ #2((a c) (b d)) (transpose-array '#2((a b) (c d)) 0 0) ⇒ #1(a d) (transpose-array '#3(((a b c) (d e f)) ((1 2 3) (4 5 6))) 1 1 0) ⇒ #2((a 4) (b 5) (c 6)) 6.6.13.4 Arrays as arrays of arrays ................................... One can see an array of rank n (an n-array) as an array of lower rank where the elements are themselves arrays ('cells'). We speak of the first n-k dimensions of the array as the n-k-'frame' of the array, while the last k dimensions are the dimensions of the k-'cells'. For example, a 3-array can be seen as a 2-array of vectors (1-arrays) or as a 1-array of matrices (2-arrays). In each case, the vectors or matrices are the 1-cells or 2-cells of the array. This terminology originates in the J language. The more vague concept of a 'slice' refers to a subset of the array where some indices are fixed and others are left free. As a Guile data object, a cell is the same as a 'prefix slice' (the first n-k indices into the original array are fixed), except that a 0-cell is not a shared array of the original array, but a 0-slice (where all the indices into the original array are fixed) is. Before version 2.0, Guile had a feature called 'enclosed arrays' to create special 'array of arrays' objects. The functions in this section do not need special types; instead, the frame rank is stated in each function call, either implicitly or explicitly. -- Scheme Procedure: array-cell-ref array idx ... -- C Function: scm_array_cell_ref (array, idxlist) If the length of IDXLIST equals the rank n of ARRAY, return the element at ‘(idx ...)’, just like ‘(array-ref array idx ...)’. If, however, the length k of IDXLIST is smaller than n, then return the (n-k)-cell of ARRAY given by IDXLIST, as a shared array. For example: (array-cell-ref #2((a b) (c d)) 0) ⇒ #(a b) (array-cell-ref #2((a b) (c d)) 1) ⇒ #(c d) (array-cell-ref #2((a b) (c d)) 1 1) ⇒ d (array-cell-ref #2((a b) (c d))) ⇒ #2((a b) (c d)) ‘(apply array-cell-ref array indices)’ is equivalent to (let ((len (length indices))) (if (= (array-rank a) len) (apply array-ref a indices) (apply make-shared-array a (lambda t (append indices t)) (drop (array-dimensions a) len)))) -- Scheme Procedure: array-slice array idx ... -- C Function: scm_array_slice (array, idxlist) Like ‘(array-cell-ref array idx ...)’, but return a 0-rank shared array into ARRAY if the length of IDXLIST matches the rank of ARRAY. This can be useful when using ARRAY as a place to write to. Compare: (array-cell-ref #2((a b) (c d)) 1 1) ⇒ d (array-slice #2((a b) (c d)) 1 1) ⇒ #0(d) (define a (make-array 'a 2 2)) (array-fill! (array-slice a 1 1) 'b) a ⇒ #2((a a) (a b)). (array-fill! (array-cell-ref a 1 1) 'b) ⇒ error: not an array ‘(apply array-slice array indices)’ is equivalent to (apply make-shared-array a (lambda t (append indices t)) (drop (array-dimensions a) (length indices))) -- Scheme Procedure: array-cell-set! array x idx ... -- C Function: scm_array_cell_set_x (array, x, idxlist) If the length of IDXLIST equals the rank n of ARRAY, set the element at ‘(idx ...)’ of ARRAY to X, just like ‘(array-set! array x idx ...)’. If, however, the length k of IDXLIST is smaller than n, then copy the (n-k)-rank array X into the (n-k)-cell of ARRAY given by IDXLIST. In this case, the last (n-k) dimensions of ARRAY and the dimensions of X must match exactly. This function returns the modified ARRAY. For example: (array-cell-set! (make-array 'a 2 2) b 1 1) ⇒ #2((a a) (a b)) (array-cell-set! (make-array 'a 2 2) #(x y) 1) ⇒ #2((a a) (x y)) Note that ‘array-cell-set!’ will expect elements, not arrays, when the destination has rank 0. Use ‘array-slice’ for the opposite behavior. (array-cell-set! (make-array 'a 2 2) #0(b) 1 1) ⇒ #2((a a) (a #0(b))) (let ((a (make-array 'a 2 2))) (array-copy! #0(b) (array-slice a 1 1)) a) ⇒ #2((a a) (a b)) ‘(apply array-cell-set! array x indices)’ is equivalent to (let ((len (length indices))) (if (= (array-rank array) len) (apply array-set! array x indices) (array-copy! x (apply array-cell-ref array indices))) array) -- Scheme Procedure: array-slice-for-each frame-rank op x ... -- C Function: scm_array_slice_for_each (array, frame_rank, op, xlist) Each X must be an array of rank ≥ FRAME-RANK, and the first FRAME-RANK dimensions of each X must all be the same. ARRAY-SLICE-FOR-EACH calls OP with each set of (rank(X) - FRAME-RANK)-cells from X, in unspecified order. ARRAY-SLICE-FOR-EACH allows you to loop over cells of any rank without having to carry an index list or construct shared arrays manually. The slices passed to OP are always shared arrays of X, even if they are of rank 0, so it is possible to write to them. This function returns an unspecified value. For example, to sort the rows of rank-2 array ‘a’: (array-slice-for-each 1 (lambda (x) (sort! x <)) a) As another example, let ‘a’ be a rank-2 array where each row is a 2-element vector (x,y). Let's compute the arguments of these vectors and store them in rank-1 array ‘b’. (array-slice-for-each 1 (lambda (a b) (array-set! b (atan (array-ref a 1) (array-ref a 0)))) a b) ‘(apply array-slice-for-each frame-rank op x)’ is equivalent to (let ((frame (take (array-dimensions (car x)) frank))) (unless (every (lambda (x) (equal? frame (take (array-dimensions x) frank))) (cdr x)) (error)) (array-index-map! (apply make-shared-array (make-array #t) (const '()) frame) (lambda i (apply op (map (lambda (x) (apply array-slice x i)) x))))) -- Scheme Procedure: array-slice-for-each-in-order frame-rank op x ... -- C Function: scm_array_slice_for_each_in_order (array, frame_rank, op, xlist) Same as ‘array-slice-for-each’, but the arguments are traversed sequentially and in row-major order. 6.6.13.5 Accessing Arrays from C ................................ For interworking with external C code, Guile provides an API to allow C code to access the elements of a Scheme array. In particular, for uniform numeric arrays, the API exposes the underlying uniform data as a C array of numbers of the relevant type. While pointers to the elements of an array are in use, the array itself must be protected so that the pointer remains valid. Such a protected array is said to be “reserved”. A reserved array can be read but modifications to it that would cause the pointer to its elements to become invalid are prevented. When you attempt such a modification, an error is signaled. (This is similar to locking the array while it is in use, but without the danger of a deadlock. In a multi-threaded program, you will need additional synchronization to avoid modifying reserved arrays.) You must take care to always unreserve an array after reserving it, even in the presence of non-local exits. If a non-local exit can happen between these two calls, you should install a dynwind context that releases the array when it is left (*note Dynamic Wind::). In addition, array reserving and unreserving must be properly paired. For instance, when reserving two or more arrays in a certain order, you need to unreserve them in the opposite order. Once you have reserved an array and have retrieved the pointer to its elements, you must figure out the layout of the elements in memory. Guile allows slices to be taken out of arrays without actually making a copy, such as making an alias for the diagonal of a matrix that can be treated as a vector. Arrays that result from such an operation are not stored contiguously in memory and when working with their elements directly, you need to take this into account. The layout of array elements in memory can be defined via a _mapping function_ that computes a scalar position from a vector of indices. The scalar position then is the offset of the element with the given indices from the start of the storage block of the array. In Guile, this mapping function is restricted to be “affine”: all mapping functions of Guile arrays can be written as ‘p = b + c[0]*i[0] + c[1]*i[1] + ... + c[n-1]*i[n-1]’ where ‘i[k]’ is the kth index and ‘n’ is the rank of the array. For example, a matrix of size 3x3 would have ‘b == 0’, ‘c[0] == 3’ and ‘c[1] == 1’. When you transpose this matrix (with ‘transpose-array’, say), you will get an array whose mapping function has ‘b == 0’, ‘c[0] == 1’ and ‘c[1] == 3’. The function ‘scm_array_handle_dims’ gives you (indirect) access to the coefficients ‘c[k]’. Note that there are no functions for accessing the elements of a character array yet. Once the string implementation of Guile has been changed to use Unicode, we will provide them. -- C Type: scm_t_array_handle This is a structure type that holds all information necessary to manage the reservation of arrays as explained above. Structures of this type must be allocated on the stack and must only be accessed by the functions listed below. -- C Function: void scm_array_get_handle (SCM array, scm_t_array_handle *handle) Reserve ARRAY, which must be an array, and prepare HANDLE to be used with the functions below. You must eventually call ‘scm_array_handle_release’ on HANDLE, and do this in a properly nested fashion, as explained above. The structure pointed to by HANDLE does not need to be initialized before calling this function. -- C Function: void scm_array_handle_release (scm_t_array_handle *handle) End the array reservation represented by HANDLE. After a call to this function, HANDLE might be used for another reservation. -- C Function: size_t scm_array_handle_rank (scm_t_array_handle *handle) Return the rank of the array represented by HANDLE. -- C Type: scm_t_array_dim This structure type holds information about the layout of one dimension of an array. It includes the following fields: ‘ssize_t lbnd’ ‘ssize_t ubnd’ The lower and upper bounds (both inclusive) of the permissible index range for the given dimension. Both values can be negative, but LBND is always less than or equal to UBND. ‘ssize_t inc’ The distance from one element of this dimension to the next. Note, too, that this can be negative. -- C Function: const scm_t_array_dim * scm_array_handle_dims (scm_t_array_handle *handle) Return a pointer to a C vector of information about the dimensions of the array represented by HANDLE. This pointer is valid as long as the array remains reserved. As explained above, the ‘scm_t_array_dim’ structures returned by this function can be used calculate the position of an element in the storage block of the array from its indices. This position can then be used as an index into the C array pointer returned by the various ‘scm_array_handle__elements’ functions, or with ‘scm_array_handle_ref’ and ‘scm_array_handle_set’. Here is how one can compute the position POS of an element given its indices in the vector INDICES: ssize_t indices[RANK]; scm_t_array_dim *dims; ssize_t pos; size_t i; pos = 0; for (i = 0; i < RANK; i++) { if (indices[i] < dims[i].lbnd || indices[i] > dims[i].ubnd) out_of_range (); pos += (indices[i] - dims[i].lbnd) * dims[i].inc; } -- C Function: ssize_t scm_array_handle_pos (scm_t_array_handle *handle, SCM indices) Compute the position corresponding to INDICES, a list of indices. The position is computed as described above for ‘scm_array_handle_dims’. The number of the indices and their range is checked and an appropriate error is signaled for invalid indices. -- C Function: SCM scm_array_handle_ref (scm_t_array_handle *handle, ssize_t pos) Return the element at position POS in the storage block of the array represented by HANDLE. Any kind of array is acceptable. No range checking is done on POS. -- C Function: void scm_array_handle_set (scm_t_array_handle *handle, ssize_t pos, SCM val) Set the element at position POS in the storage block of the array represented by HANDLE to VAL. Any kind of array is acceptable. No range checking is done on POS. An error is signaled when the array can not store VAL. -- C Function: const SCM * scm_array_handle_elements (scm_t_array_handle *handle) Return a pointer to the elements of a ordinary array of general Scheme values (i.e., a non-uniform array) for reading. This pointer is valid as long as the array remains reserved. -- C Function: SCM * scm_array_handle_writable_elements (scm_t_array_handle *handle) Like ‘scm_array_handle_elements’, but the pointer is good for reading and writing. -- C Function: const void * scm_array_handle_uniform_elements (scm_t_array_handle *handle) Return a pointer to the elements of a uniform numeric array for reading. This pointer is valid as long as the array remains reserved. The size of each element is given by ‘scm_array_handle_uniform_element_size’. -- C Function: void * scm_array_handle_uniform_writable_elements (scm_t_array_handle *handle) Like ‘scm_array_handle_uniform_elements’, but the pointer is good reading and writing. -- C Function: size_t scm_array_handle_uniform_element_size (scm_t_array_handle *handle) Return the size of one element of the uniform numeric array represented by HANDLE. -- C Function: const scm_t_uint8 * scm_array_handle_u8_elements (scm_t_array_handle *handle) -- C Function: const scm_t_int8 * scm_array_handle_s8_elements (scm_t_array_handle *handle) -- C Function: const scm_t_uint16 * scm_array_handle_u16_elements (scm_t_array_handle *handle) -- C Function: const scm_t_int16 * scm_array_handle_s16_elements (scm_t_array_handle *handle) -- C Function: const scm_t_uint32 * scm_array_handle_u32_elements (scm_t_array_handle *handle) -- C Function: const scm_t_int32 * scm_array_handle_s32_elements (scm_t_array_handle *handle) -- C Function: const scm_t_uint64 * scm_array_handle_u64_elements (scm_t_array_handle *handle) -- C Function: const scm_t_int64 * scm_array_handle_s64_elements (scm_t_array_handle *handle) -- C Function: const float * scm_array_handle_f32_elements (scm_t_array_handle *handle) -- C Function: const double * scm_array_handle_f64_elements (scm_t_array_handle *handle) -- C Function: const float * scm_array_handle_c32_elements (scm_t_array_handle *handle) -- C Function: const double * scm_array_handle_c64_elements (scm_t_array_handle *handle) Return a pointer to the elements of a uniform numeric array of the indicated kind for reading. This pointer is valid as long as the array remains reserved. The pointers for ‘c32’ and ‘c64’ uniform numeric arrays point to pairs of floating point numbers. The even index holds the real part, the odd index the imaginary part of the complex number. -- C Function: scm_t_uint8 * scm_array_handle_u8_writable_elements (scm_t_array_handle *handle) -- C Function: scm_t_int8 * scm_array_handle_s8_writable_elements (scm_t_array_handle *handle) -- C Function: scm_t_uint16 * scm_array_handle_u16_writable_elements (scm_t_array_handle *handle) -- C Function: scm_t_int16 * scm_array_handle_s16_writable_elements (scm_t_array_handle *handle) -- C Function: scm_t_uint32 * scm_array_handle_u32_writable_elements (scm_t_array_handle *handle) -- C Function: scm_t_int32 * scm_array_handle_s32_writable_elements (scm_t_array_handle *handle) -- C Function: scm_t_uint64 * scm_array_handle_u64_writable_elements (scm_t_array_handle *handle) -- C Function: scm_t_int64 * scm_array_handle_s64_writable_elements (scm_t_array_handle *handle) -- C Function: float * scm_array_handle_f32_writable_elements (scm_t_array_handle *handle) -- C Function: double * scm_array_handle_f64_writable_elements (scm_t_array_handle *handle) -- C Function: float * scm_array_handle_c32_writable_elements (scm_t_array_handle *handle) -- C Function: double * scm_array_handle_c64_writable_elements (scm_t_array_handle *handle) Like ‘scm_array_handle__elements’, but the pointer is good for reading and writing. -- C Function: const scm_t_uint32 * scm_array_handle_bit_elements (scm_t_array_handle *handle) Return a pointer to the words that store the bits of the represented array, which must be a bit array. Unlike other arrays, bit arrays have an additional offset that must be figured into index calculations. That offset is returned by ‘scm_array_handle_bit_elements_offset’. To find a certain bit you first need to calculate its position as explained above for ‘scm_array_handle_dims’ and then add the offset. This gives the absolute position of the bit, which is always a non-negative integer. Each word of the bit array storage block contains exactly 32 bits, with the least significant bit in that word having the lowest absolute position number. The next word contains the next 32 bits. Thus, the following code can be used to access a bit whose position according to ‘scm_array_handle_dims’ is given in POS: SCM bit_array; scm_t_array_handle handle; scm_t_uint32 *bits; ssize_t pos; size_t abs_pos; size_t word_pos, mask; scm_array_get_handle (&bit_array, &handle); bits = scm_array_handle_bit_elements (&handle); pos = ... abs_pos = pos + scm_array_handle_bit_elements_offset (&handle); word_pos = abs_pos / 32; mask = 1L << (abs_pos % 32); if (bits[word_pos] & mask) /* bit is set. */ scm_array_handle_release (&handle); -- C Function: scm_t_uint32 * scm_array_handle_bit_writable_elements (scm_t_array_handle *handle) Like ‘scm_array_handle_bit_elements’ but the pointer is good for reading and writing. You must take care not to modify bits outside of the allowed index range of the array, even for contiguous arrays. 6.6.14 VLists ------------- The ‘(ice-9 vlist)’ module provides an implementation of the “VList” data structure designed by Phil Bagwell in 2002. VLists are immutable lists, which can contain any Scheme object. They improve on standard Scheme linked lists in several areas: • Random access has typically constant-time complexity. • Computing the length of a VList has time complexity logarithmic in the number of elements. • VLists use less storage space than standard lists. • VList elements are stored in contiguous regions, which improves memory locality and leads to more efficient use of hardware caches. The idea behind VLists is to store vlist elements in increasingly large contiguous blocks (implemented as vectors here). These blocks are linked to one another using a pointer to the next block and an offset within that block. The size of these blocks form a geometric series with ratio ‘block-growth-factor’ (2 by default). The VList structure also serves as the basis for the “VList-based hash lists” or "vhashes", an immutable dictionary type (*note VHashes::). However, the current implementation in ‘(ice-9 vlist)’ has several noteworthy shortcomings: • It is _not_ thread-safe. Although operations on vlists are all “referentially transparent” (i.e., purely functional), adding elements to a vlist with ‘vlist-cons’ mutates part of its internal structure, which makes it non-thread-safe. This could be fixed, but it would slow down ‘vlist-cons’. • ‘vlist-cons’ always allocates at least as much memory as ‘cons’. Again, Phil Bagwell describes how to fix it, but that would require tuning the garbage collector in a way that may not be generally beneficial. • ‘vlist-cons’ is a Scheme procedure compiled to bytecode, and it does not compete with the straightforward C implementation of ‘cons’, and with the fact that the VM has a special ‘cons’ instruction. We hope to address these in the future. The programming interface exported by ‘(ice-9 vlist)’ is defined below. Most of it is the same as SRFI-1 with an added ‘vlist-’ prefix to function names. -- Scheme Procedure: vlist? obj Return true if OBJ is a VList. -- Scheme Variable: vlist-null The empty VList. Note that it's possible to create an empty VList not ‘eq?’ to ‘vlist-null’; thus, callers should always use ‘vlist-null?’ when testing whether a VList is empty. -- Scheme Procedure: vlist-null? vlist Return true if VLIST is empty. -- Scheme Procedure: vlist-cons item vlist Return a new vlist with ITEM as its head and VLIST as its tail. -- Scheme Procedure: vlist-head vlist Return the head of VLIST. -- Scheme Procedure: vlist-tail vlist Return the tail of VLIST. -- Scheme Variable: block-growth-factor A fluid that defines the growth factor of VList blocks, 2 by default. The functions below provide the usual set of higher-level list operations. -- Scheme Procedure: vlist-fold proc init vlist -- Scheme Procedure: vlist-fold-right proc init vlist Fold over VLIST, calling PROC for each element, as for SRFI-1 ‘fold’ and ‘fold-right’ (*note ‘fold’: SRFI-1.). -- Scheme Procedure: vlist-ref vlist index Return the element at index INDEX in VLIST. This is typically a constant-time operation. -- Scheme Procedure: vlist-length vlist Return the length of VLIST. This is typically logarithmic in the number of elements in VLIST. -- Scheme Procedure: vlist-reverse vlist Return a new VLIST whose content are those of VLIST in reverse order. -- Scheme Procedure: vlist-map proc vlist Map PROC over the elements of VLIST and return a new vlist. -- Scheme Procedure: vlist-for-each proc vlist Call PROC on each element of VLIST. The result is unspecified. -- Scheme Procedure: vlist-drop vlist count Return a new vlist that does not contain the COUNT first elements of VLIST. This is typically a constant-time operation. -- Scheme Procedure: vlist-take vlist count Return a new vlist that contains only the COUNT first elements of VLIST. -- Scheme Procedure: vlist-filter pred vlist Return a new vlist containing all the elements from VLIST that satisfy PRED. -- Scheme Procedure: vlist-delete x vlist [equal?] Return a new vlist corresponding to VLIST without the elements EQUAL? to X. -- Scheme Procedure: vlist-unfold p f g seed [tail-gen] -- Scheme Procedure: vlist-unfold-right p f g seed [tail] Return a new vlist, as for SRFI-1 ‘unfold’ and ‘unfold-right’ (*note ‘unfold’: SRFI-1.). -- Scheme Procedure: vlist-append vlist ... Append the given vlists and return the resulting vlist. -- Scheme Procedure: list->vlist lst Return a new vlist whose contents correspond to LST. -- Scheme Procedure: vlist->list vlist Return a new list whose contents match those of VLIST. 6.6.15 Record Overview ---------------------- “Records”, also called “structures”, are Scheme's primary mechanism to define new disjoint types. A “record type” defines a list of “fields” that instances of the type consist of. This is like C's ‘struct’. Historically, Guile has offered several different ways to define record types and to create records, offering different features, and making different trade-offs. Over the years, each "standard" has also come with its own new record interface, leading to a maze of record APIs. At the highest level is SRFI-9, a high-level record interface implemented by most Scheme implementations (*note SRFI-9 Records::). It defines a simple and efficient syntactic abstraction of record types and their associated type predicate, fields, and field accessors. SRFI-9 is suitable for most uses, and this is the recommended way to create record types in Guile. Similar high-level record APIs include SRFI-35 (*note SRFI-35::) and R6RS records (*note rnrs records syntactic::). Then comes Guile's historical "records" API (*note Records::). Record types defined this way are first-class objects. Introspection facilities are available, allowing users to query the list of fields or the value of a specific field at run-time, without prior knowledge of the type. Finally, the common denominator of these interfaces is Guile's “structure” API (*note Structures::). Guile's structures are the low-level building block for all other record APIs. Application writers will normally not need to use it. Records created with these APIs may all be pattern-matched using Guile's standard pattern matcher (*note Pattern Matching::). 6.6.16 SRFI-9 Records --------------------- SRFI-9 standardizes a syntax for defining new record types and creating predicate, constructor, and field getter and setter functions. In Guile this is the recommended option to create new record types (*note Record Overview::). It can be used with: (use-modules (srfi srfi-9)) -- Scheme Syntax: define-record-type type (constructor fieldname ...) predicate (fieldname accessor [modifier]) ... Create a new record type, and make various ‘define’s for using it. This syntax can only occur at the top-level, not nested within some other form. TYPE is bound to the record type, which is as per the return from the core ‘make-record-type’. TYPE also provides the name for the record, as per ‘record-type-name’. CONSTRUCTOR is bound to a function to be called as ‘(CONSTRUCTOR fieldval ...)’ to create a new record of this type. The arguments are initial values for the fields, one argument for each field, in the order they appear in the ‘define-record-type’ form. The FIELDNAMEs provide the names for the record fields, as per the core ‘record-type-fields’ etc, and are referred to in the subsequent accessor/modifier forms. PREDICATE is bound to a function to be called as ‘(PREDICATE obj)’. It returns ‘#t’ or ‘#f’ according to whether OBJ is a record of this type. Each ACCESSOR is bound to a function to be called ‘(ACCESSOR record)’ to retrieve the respective field from a RECORD. Similarly each MODIFIER is bound to a function to be called ‘(MODIFIER record val)’ to set the respective field in a RECORD. An example will illustrate typical usage, (define-record-type (make-employee name age salary) employee? (name employee-name) (age employee-age set-employee-age!) (salary employee-salary set-employee-salary!)) This creates a new employee data type, with name, age and salary fields. Accessor functions are created for each field, but no modifier function for the name (the intention in this example being that it's established only when an employee object is created). These can all then be used as for example, ⇒ #> (define fred (make-employee "Fred" 45 20000.00)) (employee? fred) ⇒ #t (employee-age fred) ⇒ 45 (set-employee-salary! fred 25000.00) ;; pay rise The functions created by ‘define-record-type’ are ordinary top-level ‘define’s. They can be redefined or ‘set!’ as desired, exported from a module, etc. Non-toplevel Record Definitions ............................... The SRFI-9 specification explicitly disallows record definitions in a non-toplevel context, such as inside ‘lambda’ body or inside a LET block. However, Guile's implementation does not enforce that restriction. Custom Printers ............... You may use ‘set-record-type-printer!’ to customize the default printing behavior of records. This is a Guile extension and is not part of SRFI-9. It is located in the (srfi srfi-9 gnu) module. -- Scheme Syntax: set-record-type-printer! type proc Where TYPE corresponds to the first argument of ‘define-record-type’, and PROC is a procedure accepting two arguments, the record to print, and an output port. This example prints the employee's name in brackets, for instance ‘[Fred]’. (set-record-type-printer! (lambda (record port) (write-char #\[ port) (display (employee-name record) port) (write-char #\] port))) Functional "Setters" .................... When writing code in a functional style, it is desirable to never alter the contents of records. For such code, a simple way to return new record instances based on existing ones is highly desirable. The ‘(srfi srfi-9 gnu)’ module extends SRFI-9 with facilities to return new record instances based on existing ones, only with one or more field values changed--“functional setters”. First, the ‘define-immutable-record-type’ works like ‘define-record-type’, except that fields are immutable and setters are defined as functional setters. -- Scheme Syntax: define-immutable-record-type type (constructor fieldname ...) predicate (fieldname accessor [modifier]) ... Define TYPE as a new record type, like ‘define-record-type’. However, the record type is made _immutable_ (records may not be mutated, even with ‘struct-set!’), and any MODIFIER is defined to be a functional setter--a procedure that returns a new record instance with the specified field changed, and leaves the original unchanged (see example below.) In addition, the generic ‘set-field’ and ‘set-fields’ macros may be applied to any SRFI-9 record. -- Scheme Syntax: set-field record (field sub-fields ...) value Return a new record of RECORD's type whose fields are equal to the corresponding fields of RECORD except for the one specified by FIELD. FIELD must be the name of the getter corresponding to the field of RECORD being "set". Subsequent SUB-FIELDS must be record getters designating sub-fields within that field value to be set (see example below.) -- Scheme Syntax: set-fields record ((field sub-fields ...) value) ... Like ‘set-field’, but can be used to set more than one field at a time. This expands to code that is more efficient than a series of single ‘set-field’ calls. To illustrate the use of functional setters, let's assume these two record type definitions: (define-record-type
(address street city country) address? (street address-street) (city address-city) (country address-country)) (define-immutable-record-type (person age email address) person? (age person-age set-person-age) (email person-email set-person-email) (address person-address set-person-address)) First, note that the ‘’ record type definition introduces named functional setters. These may be used like this: (define fsf-address (address "Franklin Street" "Boston" "USA")) (define rms (person 30 "rms@gnu.org" fsf-address)) (and (equal? (set-person-age rms 60) (person 60 "rms@gnu.org" fsf-address)) (= (person-age rms) 30)) ⇒ #t Here, the original ‘’ record, to which RMS is bound, is left unchanged. Now, suppose we want to change both the street and age of RMS. This can be achieved using ‘set-fields’: (set-fields rms ((person-age) 60) ((person-address address-street) "Temple Place")) ⇒ #< age: 60 email: "rms@gnu.org" address: #<
street: "Temple Place" city: "Boston" country: "USA">> Notice how the above changed two fields of RMS, including the ‘street’ field of its ‘address’ field, in a concise way. Also note that ‘set-fields’ works equally well for types defined with just ‘define-record-type’. 6.6.17 Records -------------- A “record type” is a first class object representing a user-defined data type. A “record” is an instance of a record type. Note that in many ways, this interface is too low-level for every-day use. Most uses of records are better served by SRFI-9 records. *Note SRFI-9 Records::. -- Scheme Procedure: record? obj Return ‘#t’ if OBJ is a record of any type and ‘#f’ otherwise. Note that ‘record?’ may be true of any Scheme value; there is no promise that records are disjoint with other Scheme types. -- Scheme Procedure: make-record-type type-name field-names [print] [#:parent=#f] [#:uid=#f] [#:extensible?=#f] [#:opaque?=#f] [#:allow-duplicate-field-names?=#t] Create and return a new “record-type descriptor”. TYPE-NAME is a string naming the type. Currently it's only used in the printed representation of records, and in diagnostics. FIELD-NAMES is a list of elements of the form ‘(immutable NAME)’, ‘(mutable NAME)’, or NAME, where NAME are symbols naming the fields of a record of the type. Duplicates are not allowed among these symbols, unless ALLOW-DUPLICATE-FIELD-NAMES? is true. (make-record-type "employee" '(name age salary)) The optional PRINT argument is a function used by ‘display’, ‘write’, etc, for printing a record of the new type. It's called as ‘(PRINT record port)’ and should look at RECORD and write to PORT. Pass the ‘#:parent’ keyword to derive a record type from a supertype. A derived record type has the fields from its parent type, followed by fields declared in the ‘make-record-type’ call. Record predicates and field accessors for instance of a parent type will also work on any instance of a subtype. Allowing record subtyping has a small amount of overhead. To avoid this overhead, prevent extensibility by passing ‘#:extensible? #f’. By default, record types in Guile are not extensible. Generally speaking, calling ‘make-record-type’ returns a fresh record type; it _generates_ new record types. However sometimes you only want to define a record type if one hasn't been defined already. For a _nongenerative_ record type definition, pass a symbol as the ‘#:uid’ keyword parameter. If a record with the given UID was already defined, it will be returned instead. The type name, fields, parent (if any), and so on for the previously-defined type must be compatible. R6RS defines a notion of "opaque" record types. Given an instance of an opaque record type, one cannot obtain a run-time representation of the record type. *Note rnrs records procedural::, for full details. The ‘#:opaque?’ flag is used by Guile's R6RS layer to record this information. The default is determined by whether the parent type, if any, was opaque. Fields are mutable by default, meaning that ‘record-modifier’ will return a procedure that can update a record in place. Specifying a field using the form ‘(immutable NAME)’ instead marks a field as immutable. -- Scheme Procedure: record-constructor rtd Return a procedure for constructing new members of the type represented by RTD. The result will be a procedure accepting exactly as many arguments as there are fields in the record type. -- Scheme Procedure: record-predicate rtd Return a procedure for testing membership in the type represented by RTD. The returned procedure accepts exactly one argument and returns a true value if the argument is a member of the indicated record type; it returns a false value otherwise. -- Scheme Procedure: record-accessor rtd field-name Return a procedure for reading the value of a particular field of a member of the type represented by RTD. The returned procedure accepts exactly one argument which must be a record of the appropriate type; it returns the current value of the field named by the symbol FIELD-NAME in that record. If FIELD-NAME is a symbol, it must be a member of the list of field-names in the call to ‘make-record-type’ that created the type represented by RTD. If multiple fields in RTD have the same name, ‘record-accessor’ returns the first one. If FIELD-NAME is an integer, it should be an index into ‘(record-type-fields RTD)’. This allows accessing fields with duplicate names. -- Scheme Procedure: record-modifier rtd field-name Return a procedure for writing the value of a particular field of a member of the type represented by RTD. The returned procedure accepts exactly two arguments: first, a record of the appropriate type, and second, an arbitrary Scheme value; it modifies the field named by the symbol FIELD-NAME in that record to contain the given value. The returned value of the modifier procedure is unspecified. The symbol FIELD-NAME is a field name or a field index, as in ‘record-modifier’. -- Scheme Procedure: record-type-descriptor record Return a record-type descriptor representing the type of the given record. That is, for example, if the returned descriptor were passed to ‘record-predicate’, the resulting predicate would return a true value when passed the given record. Note that it is not necessarily the case that the returned descriptor is the one that was passed to ‘record-constructor’ in the call that created the constructor procedure that created the given record. -- Scheme Procedure: record-type-name rtd Return the type-name associated with the type represented by rtd. The returned value is ‘eqv?’ to the TYPE-NAME argument given in the call to ‘make-record-type’ that created the type represented by RTD. -- Scheme Procedure: record-type-fields rtd Return a list of the symbols naming the fields in members of the type represented by RTD. The returned value is ‘equal?’ to the field-names argument given in the call to ‘make-record-type’ that created the type represented by RTD. 6.6.18 Structures ----------------- A “structure” is a first class data type which holds Scheme values or C words in fields numbered 0 upwards. A “vtable” is a structure that represents a structure type, giving field types and permissions, and an optional print function for ‘write’ etc. Structures are lower level than records (*note Records::). Usually, when you need to represent structured data, you just want to use records. But sometimes you need to implement new kinds of structured data abstractions, and for that purpose structures are useful. Indeed, records in Guile are implemented with structures. 6.6.18.1 Vtables ................ A vtable is a structure type, specifying its layout, and other information. A vtable is actually itself a structure, but there's no need to worry about that initially (*note Vtable Contents::.) -- Scheme Procedure: make-vtable fields [print] Create a new vtable. FIELDS is a string describing the fields in the structures to be created. Each field is represented by two characters, a type letter and a permissions letter, for example ‘"pw"’. The types are as follows. • ‘p’ - a Scheme value. "p" stands for "protected" meaning it's protected against garbage collection. • ‘u’ - an arbitrary word of data (an ‘scm_t_bits’). At the Scheme level it's read and written as an unsigned integer. "u" stands for "unboxed", as it's stored as a raw value without additional type annotations. It used to be that the second letter for each field was a permission code, such as ‘w’ for writable or ‘r’ for read-only. However over time structs have become more of a raw low-level facility; access control is better implemented as a layer on top. After all, ‘struct-set!’ is a cross-cutting operator that can bypass abstractions made by higher-level record facilities; it's not generally safe (in the sense of abstraction-preserving) to expose ‘struct-set!’ to "untrusted" code, even if the fields happen to be writable. Additionally, permission checks added overhead to every structure access in a way that couldn't be optimized out, hampering the ability of structs to act as a low-level building block. For all of these reasons, all fields in Guile structs are now writable; attempting to make a read-only field will now issue a deprecation warning, and the field will be writable regardless. (make-vtable "pw") ;; one scheme field (make-vtable "pwuwuw") ;; one scheme and two unboxed fields The optional PRINT argument is a function called by ‘display’ and ‘write’ (etc) to give a printed representation of a structure created from this vtable. It's called ‘(PRINT struct port)’ and should look at STRUCT and write to PORT. The default print merely gives a form like ‘#’ with a pair of machine addresses. The following print function for example shows the two fields of its structure. (make-vtable "pwpw" (lambda (struct port) (format port "#<~a and ~a>" (struct-ref struct 0) (struct-ref struct 1)))) 6.6.18.2 Structure Basics ......................... This section describes the basic procedures for working with structures. ‘make-struct/no-tail’ creates a structure, and ‘struct-ref’ and ‘struct-set!’ access its fields. -- Scheme Procedure: make-struct/no-tail vtable init ... Create a new structure, with layout per the given VTABLE (*note Vtables::). The optional INIT... arguments are initial values for the fields of the structure. This is the only way to put values in read-only fields. If there are fewer INIT arguments than fields then the defaults are ‘#f’ for a Scheme field (type ‘p’) or 0 for an unboxed field (type ‘u’). The name is a bit strange, we admit. The reason for it is that Guile used to have a ‘make-struct’ that took an additional argument; while we deprecate that old interface, ‘make-struct/no-tail’ is the new name for this functionality. For example, (define v (make-vtable "pwpwpw")) (define s (make-struct/no-tail v 123 "abc" 456)) (struct-ref s 0) ⇒ 123 (struct-ref s 1) ⇒ "abc" -- C Function: SCM scm_make_struct (SCM vtable, SCM tail_size, SCM init_list) -- C Function: SCM scm_c_make_struct (SCM vtable, SCM tail_size, SCM init, ...) -- C Function: SCM scm_c_make_structv (SCM vtable, SCM tail_size, size_t n_inits, scm_t_bits init[]) There are a few ways to make structures from C. ‘scm_make_struct’ takes a list, ‘scm_c_make_struct’ takes variable arguments terminated with SCM_UNDEFINED, and ‘scm_c_make_structv’ takes a packed array. For all of these, TAIL_SIZE should be zero (as a SCM value). -- Scheme Procedure: struct? obj -- C Function: scm_struct_p (obj) Return ‘#t’ if OBJ is a structure, or ‘#f’ if not. -- Scheme Procedure: struct-ref struct n -- C Function: scm_struct_ref (struct, n) Return the contents of field number N in STRUCT. The first field is number 0. An error is thrown if N is out of range. -- Scheme Procedure: struct-set! struct n value -- C Function: scm_struct_set_x (struct, n, value) Set field number N in STRUCT to VALUE. The first field is number 0. An error is thrown if N is out of range, or if the field cannot be written because it's ‘r’ read-only. Unboxed fields (those with type ‘u’) need to be accessed with special procedures. -- Scheme Procedure: struct-ref/unboxed struct n -- Scheme Procedure: struct-set!/unboxed struct n value -- C Function: scm_struct_ref_unboxed (struct, n) -- C Function: scm_struct_set_x_unboxed (struct, n, value) Like ‘struct-ref’ and ‘struct-set!’, except that these may only be used on unboxed fields. ‘struct-ref/unboxed’ will always return a positive integer. Likewise, ‘struct-set!/unboxed’ takes an unsigned integer as the VALUE argument, and will signal an error otherwise. -- Scheme Procedure: struct-vtable struct -- C Function: scm_struct_vtable (struct) Return the vtable that describes STRUCT. The vtable is effectively the type of the structure. See *note Vtable Contents::, for more on vtables. 6.6.18.3 Vtable Contents ........................ A vtable is itself a structure. It has a specific set of fields describing various aspects of its “instances”: the structures created from a vtable. Some of the fields are internal to Guile, some of them are part of the public interface, and there may be additional fields added on by the user. Every vtable has a field for the layout of their instances, a field for the procedure used to print its instances, and a field for the name of the vtable itself. Access to the layout and printer is exposed directly via field indexes. Access to the vtable name is exposed via accessor procedures. -- Scheme Variable: vtable-index-layout -- C Macro: scm_vtable_index_layout The field number of the layout specification in a vtable. The layout specification is a symbol like ‘pwpw’ formed from the fields string passed to ‘make-vtable’, or created by ‘make-struct-layout’ (*note Meta-Vtables::). (define v (make-vtable "pwpw" 0)) (struct-ref v vtable-index-layout) ⇒ pwpw This field is read-only, since the layout of structures using a vtable cannot be changed. -- Scheme Variable: vtable-index-printer -- C Macro: scm_vtable_index_printer The field number of the printer function. This field contains ‘#f’ if the default print function should be used. (define (my-print-func struct port) ...) (define v (make-vtable "pwpw" my-print-func)) (struct-ref v vtable-index-printer) ⇒ my-print-func This field is writable, allowing the print function to be changed dynamically. -- Scheme Procedure: struct-vtable-name vtable -- Scheme Procedure: set-struct-vtable-name! vtable name -- C Function: scm_struct_vtable_name (vtable) -- C Function: scm_set_struct_vtable_name_x (vtable, name) Get or set the name of VTABLE. NAME is a symbol and is used in the default print function when printing structures created from VTABLE. (define v (make-vtable "pw")) (set-struct-vtable-name! v 'my-name) (define s (make-struct v 0)) (display s) ⊣ # 6.6.18.4 Meta-Vtables ..................... As a structure, a vtable also has a vtable, which is also a structure. Structures, their vtables, the vtables of the vtables, and so on form a tree of structures. Making a new structure adds a leaf to the tree, and if that structure is a vtable, it may be used to create other leaves. If you traverse up the tree of vtables, via calling ‘struct-vtable’, eventually you reach a root which is the vtable of itself: scheme@(guile-user)> (current-module) $1 = # scheme@(guile-user)> (struct-vtable $1) $2 = # scheme@(guile-user)> (struct-vtable $2) $3 = #< 12c30a0> scheme@(guile-user)> (struct-vtable $3) $4 = #< 12c3fa0> scheme@(guile-user)> (struct-vtable $4) $5 = #< 12c3fa0> scheme@(guile-user)> $6 = #< 12c3fa0> In this example, we can say that ‘$1’ is an instance of ‘$2’, ‘$2’ is an instance of ‘$3’, ‘$3’ is an instance of ‘$4’, and ‘$4’, strangely enough, is an instance of itself. The value bound to ‘$4’ in this console session also bound to ‘’ in the default environment. -- Scheme Variable: A meta-vtable, useful for making new vtables. All of these values are structures. All but ‘$1’ are vtables. As ‘$2’ is an instance of ‘$3’, and ‘$3’ is a vtable, we can say that ‘$3’ is a “meta-vtable”: a vtable that can create vtables. With this definition, we can specify more precisely what a vtable is: a vtable is a structure made from a meta-vtable. Making a structure from a meta-vtable runs some special checks to ensure that the first field of the structure is a valid layout. Additionally, if these checks see that the layout of the child vtable contains all the required fields of a vtable, in the correct order, then the child vtable will also be a meta-table, inheriting a magical bit from the parent. -- Scheme Procedure: struct-vtable? obj -- C Function: scm_struct_vtable_p (obj) Return ‘#t’ if OBJ is a vtable structure: an instance of a meta-vtable. ‘’ is a root of the vtable tree. (Normally there is only one root in a given Guile process, but due to some legacy interfaces there may be more than one.) The set of required fields of a vtable is the set of fields in the ‘’, and is bound to ‘standard-vtable-fields’ in the default environment. It is possible to create a meta-vtable that with additional fields in its layout, which can be used to create vtables with additional data: scheme@(guile-user)> (struct-ref $3 vtable-index-layout) $6 = pwuhuhpwphuhuhpwpwpw scheme@(guile-user)> (struct-ref $4 vtable-index-layout) $7 = pwuhuhpwphuhuh scheme@(guile-user)> standard-vtable-fields $8 = "pwuhuhpwphuhuh" scheme@(guile-user)> (struct-ref $2 vtable-offset-user) $9 = module In this continuation of our earlier example, ‘$2’ is a vtable that has extra fields, because its vtable, ‘$3’, was made from a meta-vtable with an extended layout. ‘vtable-offset-user’ is a convenient definition that indicates the number of fields in ‘standard-vtable-fields’. -- Scheme Variable: standard-vtable-fields A string containing the ordered set of fields that a vtable must have. -- Scheme Variable: vtable-offset-user The first index in a vtable that is available for a user. -- Scheme Procedure: make-struct-layout fields -- C Function: scm_make_struct_layout (fields) Return a structure layout symbol, from a FIELDS string. FIELDS is as described under ‘make-vtable’ (*note Vtables::). An invalid FIELDS string is an error. With these definitions, one can define ‘make-vtable’ in this way: (define* (make-vtable fields #:optional printer) (make-struct/no-tail (make-struct-layout fields) printer)) 6.6.18.5 Vtable Example ....................... Let us bring these points together with an example. Consider a simple object system with single inheritance. Objects will be normal structures, and classes will be vtables with three extra class fields: the name of the class, the parent class, and the list of fields. So, first we need a meta-vtable that allocates instances with these extra class fields. (define (make-vtable (string-append standard-vtable-fields "pwpwpw") (lambda (x port) (format port "< ~a>" (class-name x))))) (define (class? x) (and (struct? x) (eq? (struct-vtable x) ))) To make a structure with a specific meta-vtable, we will use ‘make-struct/no-tail’, passing it the computed instance layout and printer, as with ‘make-vtable’, and additionally the extra three class fields. (define (make-class name parent fields) (let* ((fields (compute-fields parent fields)) (layout (compute-layout fields))) (make-struct/no-tail layout (lambda (x port) (print-instance x port)) name parent fields))) Instances will store their associated data in slots in the structure: as many slots as there are fields. The ‘compute-layout’ procedure below can compute a layout, and ‘field-index’ returns the slot corresponding to a field. (define-syntax-rule (define-accessor name n) (define (name obj) (struct-ref obj n))) ;; Accessors for classes (define-accessor class-name (+ vtable-offset-user 0)) (define-accessor class-parent (+ vtable-offset-user 1)) (define-accessor class-fields (+ vtable-offset-user 2)) (define (compute-fields parent fields) (if parent (append (class-fields parent) fields) fields)) (define (compute-layout fields) (make-struct-layout (string-concatenate (make-list (length fields) "pw")))) (define (field-index class field) (list-index (class-fields class) field)) (define (print-instance x port) (format port "<~a" (class-name (struct-vtable x))) (for-each (lambda (field idx) (format port " ~a: ~a" field (struct-ref x idx))) (class-fields (struct-vtable x)) (iota (length (class-fields (struct-vtable x))))) (format port ">")) So, at this point we can actually make a few classes: (define-syntax-rule (define-class name parent field ...) (define name (make-class 'name parent '(field ...)))) (define-class #f width height) (define-class x y) And finally, make an instance: (make-struct/no-tail 400 300 10 20) ⇒ < width: 400 height: 300 x: 10 y: 20> And that's that. Note that there are many possible optimizations and feature enhancements that can be made to this object system, and the included GOOPS system does make most of them. For more simple use cases, the records facility is usually sufficient. But sometimes you need to make new kinds of data abstractions, and for that purpose, structs are here. 6.6.19 Dictionary Types ----------------------- A “dictionary” object is a data structure used to index information in a user-defined way. In standard Scheme, the main aggregate data types are lists and vectors. Lists are not really indexed at all, and vectors are indexed only by number (e.g. ‘(vector-ref foo 5)’). Often you will find it useful to index your data on some other type; for example, in a library catalog you might want to look up a book by the name of its author. Dictionaries are used to help you organize information in such a way. An “association list” (or “alist” for short) is a list of key-value pairs. Each pair represents a single quantity or object; the ‘car’ of the pair is a key which is used to identify the object, and the ‘cdr’ is the object's value. A “hash table” also permits you to index objects with arbitrary keys, but in a way that makes looking up any one object extremely fast. A well-designed hash system makes hash table lookups almost as fast as conventional array or vector references. Alists are popular among Lisp programmers because they use only the language's primitive operations (lists, “car”, “cdr” and the equality primitives). No changes to the language core are necessary. Therefore, with Scheme's built-in list manipulation facilities, it is very convenient to handle data stored in an association list. Also, alists are highly portable and can be easily implemented on even the most minimal Lisp systems. However, alists are inefficient, especially for storing large quantities of data. Because we want Guile to be useful for large software systems as well as small ones, Guile provides a rich set of tools for using either association lists or hash tables. 6.6.20 Association Lists ------------------------ An association list is a conventional data structure that is often used to implement simple key-value databases. It consists of a list of entries in which each entry is a pair. The “key” of each entry is the ‘car’ of the pair and the “value” of each entry is the ‘cdr’. ASSOCIATION LIST ::= '( (KEY1 . VALUE1) (KEY2 . VALUE2) (KEY3 . VALUE3) ... ) Association lists are also known, for short, as “alists”. The structure of an association list is just one example of the infinite number of possible structures that can be built using pairs and lists. As such, the keys and values in an association list can be manipulated using the general list structure procedures ‘cons’, ‘car’, ‘cdr’, ‘set-car!’, ‘set-cdr!’ and so on. However, because association lists are so useful, Guile also provides specific procedures for manipulating them. 6.6.20.1 Alist Key Equality ........................... All of Guile's dedicated association list procedures, apart from ‘acons’, come in three flavors, depending on the level of equality that is required to decide whether an existing key in the association list is the same as the key that the procedure call uses to identify the required entry. • Procedures with “assq” in their name use ‘eq?’ to determine key equality. • Procedures with “assv” in their name use ‘eqv?’ to determine key equality. • Procedures with “assoc” in their name use ‘equal?’ to determine key equality. ‘acons’ is an exception because it is used to build association lists which do not require their entries' keys to be unique. 6.6.20.2 Adding or Setting Alist Entries ........................................ ‘acons’ adds a new entry to an association list and returns the combined association list. The combined alist is formed by consing the new entry onto the head of the alist specified in the ‘acons’ procedure call. So the specified alist is not modified, but its contents become shared with the tail of the combined alist that ‘acons’ returns. In the most common usage of ‘acons’, a variable holding the original association list is updated with the combined alist: (set! address-list (acons name address address-list)) In such cases, it doesn't matter that the old and new values of ‘address-list’ share some of their contents, since the old value is usually no longer independently accessible. Note that ‘acons’ adds the specified new entry regardless of whether the alist may already contain entries with keys that are, in some sense, the same as that of the new entry. Thus ‘acons’ is ideal for building alists where there is no concept of key uniqueness. (set! task-list (acons 3 "pay gas bill" '())) task-list ⇒ ((3 . "pay gas bill")) (set! task-list (acons 3 "tidy bedroom" task-list)) task-list ⇒ ((3 . "tidy bedroom") (3 . "pay gas bill")) ‘assq-set!’, ‘assv-set!’ and ‘assoc-set!’ are used to add or replace an entry in an association list where there _is_ a concept of key uniqueness. If the specified association list already contains an entry whose key is the same as that specified in the procedure call, the existing entry is replaced by the new one. Otherwise, the new entry is consed onto the head of the old association list to create the combined alist. In all cases, these procedures return the combined alist. ‘assq-set!’ and friends _may_ destructively modify the structure of the old association list in such a way that an existing variable is correctly updated without having to ‘set!’ it to the value returned: address-list ⇒ (("mary" . "34 Elm Road") ("james" . "16 Bow Street")) (assoc-set! address-list "james" "1a London Road") ⇒ (("mary" . "34 Elm Road") ("james" . "1a London Road")) address-list ⇒ (("mary" . "34 Elm Road") ("james" . "1a London Road")) Or they may not: (assoc-set! address-list "bob" "11 Newington Avenue") ⇒ (("bob" . "11 Newington Avenue") ("mary" . "34 Elm Road") ("james" . "1a London Road")) address-list ⇒ (("mary" . "34 Elm Road") ("james" . "1a London Road")) The only safe way to update an association list variable when adding or replacing an entry like this is to ‘set!’ the variable to the returned value: (set! address-list (assoc-set! address-list "bob" "11 Newington Avenue")) address-list ⇒ (("bob" . "11 Newington Avenue") ("mary" . "34 Elm Road") ("james" . "1a London Road")) Because of this slight inconvenience, you may find it more convenient to use hash tables to store dictionary data. If your application will not be modifying the contents of an alist very often, this may not make much difference to you. If you need to keep the old value of an association list in a form independent from the list that results from modification by ‘acons’, ‘assq-set!’, ‘assv-set!’ or ‘assoc-set!’, use ‘list-copy’ to copy the old association list before modifying it. -- Scheme Procedure: acons key value alist -- C Function: scm_acons (key, value, alist) Add a new key-value pair to ALIST. A new pair is created whose car is KEY and whose cdr is VALUE, and the pair is consed onto ALIST, and the new list is returned. This function is _not_ destructive; ALIST is not modified. -- Scheme Procedure: assq-set! alist key val -- Scheme Procedure: assv-set! alist key value -- Scheme Procedure: assoc-set! alist key value -- C Function: scm_assq_set_x (alist, key, val) -- C Function: scm_assv_set_x (alist, key, val) -- C Function: scm_assoc_set_x (alist, key, val) Reassociate KEY in ALIST with VALUE: find any existing ALIST entry for KEY and associate it with the new VALUE. If ALIST does not contain an entry for KEY, add a new one. Return the (possibly new) alist. These functions do not attempt to verify the structure of ALIST, and so may cause unusual results if passed an object that is not an association list. 6.6.20.3 Retrieving Alist Entries ................................. ‘assq’, ‘assv’ and ‘assoc’ find the entry in an alist for a given key, and return the ‘(KEY . VALUE)’ pair. ‘assq-ref’, ‘assv-ref’ and ‘assoc-ref’ do a similar lookup, but return just the VALUE. -- Scheme Procedure: assq key alist -- Scheme Procedure: assv key alist -- Scheme Procedure: assoc key alist -- C Function: scm_assq (key, alist) -- C Function: scm_assv (key, alist) -- C Function: scm_assoc (key, alist) Return the first entry in ALIST with the given KEY. The return is the pair ‘(KEY . VALUE)’ from ALIST. If there's no matching entry the return is ‘#f’. ‘assq’ compares keys with ‘eq?’, ‘assv’ uses ‘eqv?’ and ‘assoc’ uses ‘equal?’. See also SRFI-1 which has an extended ‘assoc’ (*note SRFI-1 Association Lists::). -- Scheme Procedure: assq-ref alist key -- Scheme Procedure: assv-ref alist key -- Scheme Procedure: assoc-ref alist key -- C Function: scm_assq_ref (alist, key) -- C Function: scm_assv_ref (alist, key) -- C Function: scm_assoc_ref (alist, key) Return the value from the first entry in ALIST with the given KEY, or ‘#f’ if there's no such entry. ‘assq-ref’ compares keys with ‘eq?’, ‘assv-ref’ uses ‘eqv?’ and ‘assoc-ref’ uses ‘equal?’. Notice these functions have the KEY argument last, like other ‘-ref’ functions, but this is opposite to what ‘assq’ etc above use. When the return is ‘#f’ it can be either KEY not found, or an entry which happens to have value ‘#f’ in the ‘cdr’. Use ‘assq’ etc above if you need to differentiate these cases. 6.6.20.4 Removing Alist Entries ............................... To remove the element from an association list whose key matches a specified key, use ‘assq-remove!’, ‘assv-remove!’ or ‘assoc-remove!’ (depending, as usual, on the level of equality required between the key that you specify and the keys in the association list). As with ‘assq-set!’ and friends, the specified alist may or may not be modified destructively, and the only safe way to update a variable containing the alist is to ‘set!’ it to the value that ‘assq-remove!’ and friends return. address-list ⇒ (("bob" . "11 Newington Avenue") ("mary" . "34 Elm Road") ("james" . "1a London Road")) (set! address-list (assoc-remove! address-list "mary")) address-list ⇒ (("bob" . "11 Newington Avenue") ("james" . "1a London Road")) Note that, when ‘assq/v/oc-remove!’ is used to modify an association list that has been constructed only using the corresponding ‘assq/v/oc-set!’, there can be at most one matching entry in the alist, so the question of multiple entries being removed in one go does not arise. If ‘assq/v/oc-remove!’ is applied to an association list that has been constructed using ‘acons’, or an ‘assq/v/oc-set!’ with a different level of equality, or any mixture of these, it removes only the first matching entry from the alist, even if the alist might contain further matching entries. For example: (define address-list '()) (set! address-list (assq-set! address-list "mary" "11 Elm Street")) (set! address-list (assq-set! address-list "mary" "57 Pine Drive")) address-list ⇒ (("mary" . "57 Pine Drive") ("mary" . "11 Elm Street")) (set! address-list (assoc-remove! address-list "mary")) address-list ⇒ (("mary" . "11 Elm Street")) In this example, the two instances of the string "mary" are not the same when compared using ‘eq?’, so the two ‘assq-set!’ calls add two distinct entries to ‘address-list’. When compared using ‘equal?’, both "mary"s in ‘address-list’ are the same as the "mary" in the ‘assoc-remove!’ call, but ‘assoc-remove!’ stops after removing the first matching entry that it finds, and so one of the "mary" entries is left in place. -- Scheme Procedure: assq-remove! alist key -- Scheme Procedure: assv-remove! alist key -- Scheme Procedure: assoc-remove! alist key -- C Function: scm_assq_remove_x (alist, key) -- C Function: scm_assv_remove_x (alist, key) -- C Function: scm_assoc_remove_x (alist, key) Delete the first entry in ALIST associated with KEY, and return the resulting alist. 6.6.20.5 Sloppy Alist Functions ............................... ‘sloppy-assq’, ‘sloppy-assv’ and ‘sloppy-assoc’ behave like the corresponding non-‘sloppy-’ procedures, except that they return ‘#f’ when the specified association list is not well-formed, where the non-‘sloppy-’ versions would signal an error. Specifically, there are two conditions for which the non-‘sloppy-’ procedures signal an error, which the ‘sloppy-’ procedures handle instead by returning ‘#f’. Firstly, if the specified alist as a whole is not a proper list: (assoc "mary" '((1 . 2) ("key" . "door") . "open sesame")) ⇒ ERROR: In procedure assoc in expression (assoc "mary" (quote #)): ERROR: Wrong type argument in position 2 (expecting association list): ((1 . 2) ("key" . "door") . "open sesame") (sloppy-assoc "mary" '((1 . 2) ("key" . "door") . "open sesame")) ⇒ #f Secondly, if one of the entries in the specified alist is not a pair: (assoc 2 '((1 . 1) 2 (3 . 9))) ⇒ ERROR: In procedure assoc in expression (assoc 2 (quote #)): ERROR: Wrong type argument in position 2 (expecting association list): ((1 . 1) 2 (3 . 9)) (sloppy-assoc 2 '((1 . 1) 2 (3 . 9))) ⇒ #f Unless you are explicitly working with badly formed association lists, it is much safer to use the non-‘sloppy-’ procedures, because they help to highlight coding and data errors that the ‘sloppy-’ versions would silently cover up. -- Scheme Procedure: sloppy-assq key alist -- C Function: scm_sloppy_assq (key, alist) Behaves like ‘assq’ but does not do any error checking. Recommended only for use in Guile internals. -- Scheme Procedure: sloppy-assv key alist -- C Function: scm_sloppy_assv (key, alist) Behaves like ‘assv’ but does not do any error checking. Recommended only for use in Guile internals. -- Scheme Procedure: sloppy-assoc key alist -- C Function: scm_sloppy_assoc (key, alist) Behaves like ‘assoc’ but does not do any error checking. Recommended only for use in Guile internals. 6.6.20.6 Alist Example ...................... Here is a longer example of how alists may be used in practice. (define capitals '(("New York" . "Albany") ("Oregon" . "Salem") ("Florida" . "Miami"))) ;; What's the capital of Oregon? (assoc "Oregon" capitals) ⇒ ("Oregon" . "Salem") (assoc-ref capitals "Oregon") ⇒ "Salem" ;; We left out South Dakota. (set! capitals (assoc-set! capitals "South Dakota" "Pierre")) capitals ⇒ (("South Dakota" . "Pierre") ("New York" . "Albany") ("Oregon" . "Salem") ("Florida" . "Miami")) ;; And we got Florida wrong. (set! capitals (assoc-set! capitals "Florida" "Tallahassee")) capitals ⇒ (("South Dakota" . "Pierre") ("New York" . "Albany") ("Oregon" . "Salem") ("Florida" . "Tallahassee")) ;; After Oregon secedes, we can remove it. (set! capitals (assoc-remove! capitals "Oregon")) capitals ⇒ (("South Dakota" . "Pierre") ("New York" . "Albany") ("Florida" . "Tallahassee")) 6.6.21 VList-Based Hash Lists or "VHashes" ------------------------------------------ The ‘(ice-9 vlist)’ module provides an implementation of “VList-based hash lists” (*note VLists::). VList-based hash lists, or “vhashes”, are an immutable dictionary type similar to association lists that maps “keys” to “values”. However, unlike association lists, accessing a value given its key is typically a constant-time operation. The VHash programming interface of ‘(ice-9 vlist)’ is mostly the same as that of association lists found in SRFI-1, with procedure names prefixed by ‘vhash-’ instead of ‘alist-’ (*note SRFI-1 Association Lists::). In addition, vhashes can be manipulated using VList operations: (vlist-head (vhash-consq 'a 1 vlist-null)) ⇒ (a . 1) (define vh1 (vhash-consq 'b 2 (vhash-consq 'a 1 vlist-null))) (define vh2 (vhash-consq 'c 3 (vlist-tail vh1))) (vhash-assq 'a vh2) ⇒ (a . 1) (vhash-assq 'b vh2) ⇒ #f (vhash-assq 'c vh2) ⇒ (c . 3) (vlist->list vh2) ⇒ ((c . 3) (a . 1)) However, keep in mind that procedures that construct new VLists (‘vlist-map’, ‘vlist-filter’, etc.) return raw VLists, not vhashes: (define vh (alist->vhash '((a . 1) (b . 2) (c . 3)) hashq)) (vhash-assq 'a vh) ⇒ (a . 1) (define vl ;; This will create a raw vlist. (vlist-filter (lambda (key+value) (odd? (cdr key+value))) vh)) (vhash-assq 'a vl) ⇒ ERROR: Wrong type argument in position 2 (vlist->list vl) ⇒ ((a . 1) (c . 3)) -- Scheme Procedure: vhash? obj Return true if OBJ is a vhash. -- Scheme Procedure: vhash-cons key value vhash [hash-proc] -- Scheme Procedure: vhash-consq key value vhash -- Scheme Procedure: vhash-consv key value vhash Return a new hash list based on VHASH where KEY is associated with VALUE, using HASH-PROC to compute the hash of KEY. VHASH must be either ‘vlist-null’ or a vhash returned by a previous call to ‘vhash-cons’. HASH-PROC defaults to ‘hash’ (*note ‘hash’ procedure: Hash Table Reference.). With ‘vhash-consq’, the ‘hashq’ hash function is used; with ‘vhash-consv’ the ‘hashv’ hash function is used. All ‘vhash-cons’ calls made to construct a vhash should use the same HASH-PROC. Failing to do that, the result is undefined. -- Scheme Procedure: vhash-assoc key vhash [equal? [hash-proc]] -- Scheme Procedure: vhash-assq key vhash -- Scheme Procedure: vhash-assv key vhash Return the first key/value pair from VHASH whose key is equal to KEY according to the EQUAL? equality predicate (which defaults to ‘equal?’), and using HASH-PROC (which defaults to ‘hash’) to compute the hash of KEY. The second form uses ‘eq?’ as the equality predicate and ‘hashq’ as the hash function; the last form uses ‘eqv?’ and ‘hashv’. Note that it is important to consistently use the same hash function for HASH-PROC as was passed to ‘vhash-cons’. Failing to do that, the result is unpredictable. -- Scheme Procedure: vhash-delete key vhash [equal? [hash-proc]] -- Scheme Procedure: vhash-delq key vhash -- Scheme Procedure: vhash-delv key vhash Remove all associations from VHASH with KEY, comparing keys with EQUAL? (which defaults to ‘equal?’), and computing the hash of KEY using HASH-PROC (which defaults to ‘hash’). The second form uses ‘eq?’ as the equality predicate and ‘hashq’ as the hash function; the last one uses ‘eqv?’ and ‘hashv’. Again the choice of HASH-PROC must be consistent with previous calls to ‘vhash-cons’. -- Scheme Procedure: vhash-fold proc init vhash -- Scheme Procedure: vhash-fold-right proc init vhash Fold over the key/value elements of VHASH in the given direction, with each call to PROC having the form ‘(PROC key value result)’, where RESULT is the result of the previous call to PROC and INIT the value of RESULT for the first call to PROC. -- Scheme Procedure: vhash-fold* proc init key vhash [equal? [hash]] -- Scheme Procedure: vhash-foldq* proc init key vhash -- Scheme Procedure: vhash-foldv* proc init key vhash Fold over all the values associated with KEY in VHASH, with each call to PROC having the form ‘(proc value result)’, where RESULT is the result of the previous call to PROC and INIT the value of RESULT for the first call to PROC. Keys in VHASH are hashed using HASH are compared using EQUAL?. The second form uses ‘eq?’ as the equality predicate and ‘hashq’ as the hash function; the third one uses ‘eqv?’ and ‘hashv’. Example: (define vh (alist->vhash '((a . 1) (a . 2) (z . 0) (a . 3)))) (vhash-fold* cons '() 'a vh) ⇒ (3 2 1) (vhash-fold* cons '() 'z vh) ⇒ (0) -- Scheme Procedure: alist->vhash alist [hash-proc] Return the vhash corresponding to ALIST, an association list, using HASH-PROC to compute key hashes. When omitted, HASH-PROC defaults to ‘hash’. 6.6.22 Hash Tables ------------------ Hash tables are dictionaries which offer similar functionality as association lists: They provide a mapping from keys to values. The difference is that association lists need time linear in the size of elements when searching for entries, whereas hash tables can normally search in constant time. The drawback is that hash tables require a little bit more memory, and that you can not use the normal list procedures (*note Lists::) for working with them. 6.6.22.1 Hash Table Examples ............................ For demonstration purposes, this section gives a few usage examples of some hash table procedures, together with some explanation what they do. First we start by creating a new hash table with 31 slots, and populate it with two key/value pairs. (define h (make-hash-table 31)) ;; This is an opaque object h ⇒ # ;; Inserting into a hash table can be done with hashq-set! (hashq-set! h 'foo "bar") ⇒ "bar" (hashq-set! h 'braz "zonk") ⇒ "zonk" ;; Or with hash-create-handle! (hashq-create-handle! h 'frob #f) ⇒ (frob . #f) You can get the value for a given key with the procedure ‘hashq-ref’, but the problem with this procedure is that you cannot reliably determine whether a key does exists in the table. The reason is that the procedure returns ‘#f’ if the key is not in the table, but it will return the same value if the key is in the table and just happens to have the value ‘#f’, as you can see in the following examples. (hashq-ref h 'foo) ⇒ "bar" (hashq-ref h 'frob) ⇒ #f (hashq-ref h 'not-there) ⇒ #f It is often better is to use the procedure ‘hashq-get-handle’, which makes a distinction between the two cases. Just like ‘assq’, this procedure returns a key/value-pair on success, and ‘#f’ if the key is not found. (hashq-get-handle h 'foo) ⇒ (foo . "bar") (hashq-get-handle h 'not-there) ⇒ #f Interesting results can be computed by using ‘hash-fold’ to work through each element. This example will count the total number of elements: (hash-fold (lambda (key value seed) (+ 1 seed)) 0 h) ⇒ 3 The same thing can be done with the procedure ‘hash-count’, which can also count the number of elements matching a particular predicate. For example, count the number of elements with string values: (hash-count (lambda (key value) (string? value)) h) ⇒ 2 Counting all the elements is a simple task using ‘const’: (hash-count (const #t) h) ⇒ 3 6.6.22.2 Hash Table Reference ............................. Like the association list functions, the hash table functions come in several varieties, according to the equality test used for the keys. Plain ‘hash-’ functions use ‘equal?’, ‘hashq-’ functions use ‘eq?’, ‘hashv-’ functions use ‘eqv?’, and the ‘hashx-’ functions use an application supplied test. A single ‘make-hash-table’ creates a hash table suitable for use with any set of functions, but it's imperative that just one set is then used consistently, or results will be unpredictable. Hash tables are implemented as a vector indexed by a hash value formed from the key, with an association list of key/value pairs for each bucket in case distinct keys hash together. Direct access to the pairs in those lists is provided by the ‘-handle-’ functions. When the number of entries in a hash table goes above a threshold, the vector is made larger and the entries are rehashed, to prevent the bucket lists from becoming too long and slowing down accesses. When the number of entries goes below a threshold, the vector is shrunk to save space. For the ‘hashx-’ "extended" routines, an application supplies a HASH function producing an integer index like ‘hashq’ etc below, and an ASSOC alist search function like ‘assq’ etc (*note Retrieving Alist Entries::). Here's an example of such functions implementing case-insensitive hashing of string keys, (use-modules (srfi srfi-1) (srfi srfi-13)) (define (my-hash str size) (remainder (string-hash-ci str) size)) (define (my-assoc str alist) (find (lambda (pair) (string-ci=? str (car pair))) alist)) (define my-table (make-hash-table)) (hashx-set! my-hash my-assoc my-table "foo" 123) (hashx-ref my-hash my-assoc my-table "FOO") ⇒ 123 In a ‘hashx-’ HASH function the aim is to spread keys across the vector, so bucket lists don't become long. But the actual values are arbitrary as long as they're in the range 0 to SIZE-1. Helpful functions for forming a hash value, in addition to ‘hashq’ etc below, include ‘symbol-hash’ (*note Symbol Keys::), ‘string-hash’ and ‘string-hash-ci’ (*note String Comparison::), and ‘char-set-hash’ (*note Character Set Predicates/Comparison::). -- Scheme Procedure: make-hash-table [size] Create a new hash table object, with an optional minimum vector SIZE. When SIZE is given, the table vector will still grow and shrink automatically, as described above, but with SIZE as a minimum. If an application knows roughly how many entries the table will hold then it can use SIZE to avoid rehashing when initial entries are added. -- Scheme Procedure: alist->hash-table alist -- Scheme Procedure: alist->hashq-table alist -- Scheme Procedure: alist->hashv-table alist -- Scheme Procedure: alist->hashx-table hash assoc alist Convert ALIST into a hash table. When keys are repeated in ALIST, the leftmost association takes precedence. (use-modules (ice-9 hash-table)) (alist->hash-table '((foo . 1) (bar . 2))) When converting to an extended hash table, custom HASH and ASSOC procedures must be provided. (alist->hashx-table hash assoc '((foo . 1) (bar . 2))) -- Scheme Procedure: hash-table? obj -- C Function: scm_hash_table_p (obj) Return ‘#t’ if OBJ is a abstract hash table object. -- Scheme Procedure: hash-clear! table -- C Function: scm_hash_clear_x (table) Remove all items from TABLE (without triggering a resize). -- Scheme Procedure: hash-ref table key [dflt] -- Scheme Procedure: hashq-ref table key [dflt] -- Scheme Procedure: hashv-ref table key [dflt] -- Scheme Procedure: hashx-ref hash assoc table key [dflt] -- C Function: scm_hash_ref (table, key, dflt) -- C Function: scm_hashq_ref (table, key, dflt) -- C Function: scm_hashv_ref (table, key, dflt) -- C Function: scm_hashx_ref (hash, assoc, table, key, dflt) Lookup KEY in the given hash TABLE, and return the associated value. If KEY is not found, return DFLT, or ‘#f’ if DFLT is not given. -- Scheme Procedure: hash-set! table key val -- Scheme Procedure: hashq-set! table key val -- Scheme Procedure: hashv-set! table key val -- Scheme Procedure: hashx-set! hash assoc table key val -- C Function: scm_hash_set_x (table, key, val) -- C Function: scm_hashq_set_x (table, key, val) -- C Function: scm_hashv_set_x (table, key, val) -- C Function: scm_hashx_set_x (hash, assoc, table, key, val) Associate VAL with KEY in the given hash TABLE. If KEY is already present then it's associated value is changed. If it's not present then a new entry is created. -- Scheme Procedure: hash-remove! table key -- Scheme Procedure: hashq-remove! table key -- Scheme Procedure: hashv-remove! table key -- Scheme Procedure: hashx-remove! hash assoc table key -- C Function: scm_hash_remove_x (table, key) -- C Function: scm_hashq_remove_x (table, key) -- C Function: scm_hashv_remove_x (table, key) -- C Function: scm_hashx_remove_x (hash, assoc, table, key) Remove any association for KEY in the given hash TABLE. If KEY is not in TABLE then nothing is done. -- Scheme Procedure: hash key size -- Scheme Procedure: hashq key size -- Scheme Procedure: hashv key size -- C Function: scm_hash (key, size) -- C Function: scm_hashq (key, size) -- C Function: scm_hashv (key, size) Return a hash value for KEY. This is a number in the range 0 to SIZE-1, which is suitable for use in a hash table of the given SIZE. Note that ‘hashq’ and ‘hashv’ may use internal addresses of objects, so if an object is garbage collected and re-created it can have a different hash value, even when the two are notionally ‘eq?’. For instance with symbols, (hashq 'something 123) ⇒ 19 (gc) (hashq 'something 123) ⇒ 62 In normal use this is not a problem, since an object entered into a hash table won't be garbage collected until removed. It's only if hashing calculations are somehow separated from normal references that its lifetime needs to be considered. -- Scheme Procedure: hash-get-handle table key -- Scheme Procedure: hashq-get-handle table key -- Scheme Procedure: hashv-get-handle table key -- Scheme Procedure: hashx-get-handle hash assoc table key -- C Function: scm_hash_get_handle (table, key) -- C Function: scm_hashq_get_handle (table, key) -- C Function: scm_hashv_get_handle (table, key) -- C Function: scm_hashx_get_handle (hash, assoc, table, key) Return the ‘(KEY . VALUE)’ pair for KEY in the given hash TABLE, or ‘#f’ if KEY is not in TABLE. -- Scheme Procedure: hash-create-handle! table key init -- Scheme Procedure: hashq-create-handle! table key init -- Scheme Procedure: hashv-create-handle! table key init -- Scheme Procedure: hashx-create-handle! hash assoc table key init -- C Function: scm_hash_create_handle_x (table, key, init) -- C Function: scm_hashq_create_handle_x (table, key, init) -- C Function: scm_hashv_create_handle_x (table, key, init) -- C Function: scm_hashx_create_handle_x (hash, assoc, table, key, init) Return the ‘(KEY . VALUE)’ pair for KEY in the given hash TABLE. If KEY is not in TABLE then create an entry for it with INIT as the value, and return that pair. -- Scheme Procedure: hash-map->list proc table -- Scheme Procedure: hash-for-each proc table -- C Function: scm_hash_map_to_list (proc, table) -- C Function: scm_hash_for_each (proc, table) Apply PROC to the entries in the given hash TABLE. Each call is ‘(PROC KEY VALUE)’. ‘hash-map->list’ returns a list of the results from these calls, ‘hash-for-each’ discards the results and returns an unspecified value. Calls are made over the table entries in an unspecified order, and for ‘hash-map->list’ the order of the values in the returned list is unspecified. Results will be unpredictable if TABLE is modified while iterating. For example the following returns a new alist comprising all the entries from ‘mytable’, in no particular order. (hash-map->list cons mytable) -- Scheme Procedure: hash-for-each-handle proc table -- C Function: scm_hash_for_each_handle (proc, table) Apply PROC to the entries in the given hash TABLE. Each call is ‘(PROC HANDLE)’, where HANDLE is a ‘(KEY . VALUE)’ pair. Return an unspecified value. ‘hash-for-each-handle’ differs from ‘hash-for-each’ only in the argument list of PROC. -- Scheme Procedure: hash-fold proc init table -- C Function: scm_hash_fold (proc, init, table) Accumulate a result by applying PROC to the elements of the given hash TABLE. Each call is ‘(PROC KEY VALUE PRIOR-RESULT)’, where KEY and VALUE are from the TABLE and PRIOR-RESULT is the return from the previous PROC call. For the first call, PRIOR-RESULT is the given INIT value. Calls are made over the table entries in an unspecified order. Results will be unpredictable if TABLE is modified while ‘hash-fold’ is running. For example, the following returns a count of how many keys in ‘mytable’ are strings. (hash-fold (lambda (key value prior) (if (string? key) (1+ prior) prior)) 0 mytable) -- Scheme Procedure: hash-count pred table -- C Function: scm_hash_count (pred, table) Return the number of elements in the given hash TABLE that cause ‘(PRED KEY VALUE)’ to return true. To quickly determine the total number of elements, use ‘(const #t)’ for PRED. 6.6.23 Other Types ------------------ Procedures are documented in their own section. *Note Procedures::. Variable objects are documented as part of the description of Guile's module system: see *note Variables::. *Note Scheduling::, for discussion of threads, mutexes, and so on. Ports are described in the section on I/O: see *note Input and Output::. Regular expressions are described in their own section: see *note Regular Expressions::. There are quite a number of additional data types documented in this manual; if you feel a link is missing here, please file a bug. 6.7 Procedures ============== 6.7.1 Lambda: Basic Procedure Creation -------------------------------------- A ‘lambda’ expression evaluates to a procedure. The environment which is in effect when a ‘lambda’ expression is evaluated is enclosed in the newly created procedure, this is referred to as a “closure” (*note About Closure::). When a procedure created by ‘lambda’ is called with some actual arguments, the environment enclosed in the procedure is extended by binding the variables named in the formal argument list to new locations and storing the actual arguments into these locations. Then the body of the ‘lambda’ expression is evaluated sequentially. The result of the last expression in the procedure body is then the result of the procedure invocation. The following examples will show how procedures can be created using ‘lambda’, and what you can do with these procedures. (lambda (x) (+ x x)) ⇒ a procedure ((lambda (x) (+ x x)) 4) ⇒ 8 The fact that the environment in effect when creating a procedure is enclosed in the procedure is shown with this example: (define add4 (let ((x 4)) (lambda (y) (+ x y)))) (add4 6) ⇒ 10 -- syntax: lambda formals body FORMALS should be a formal argument list as described in the following table. ‘(VARIABLE1 ...)’ The procedure takes a fixed number of arguments; when the procedure is called, the arguments will be stored into the newly created location for the formal variables. ‘VARIABLE’ The procedure takes any number of arguments; when the procedure is called, the sequence of actual arguments will be converted into a list and stored into the newly created location for the formal variable. ‘(VARIABLE1 ... VARIABLEN . VARIABLEN+1)’ If a space-delimited period precedes the last variable, then the procedure takes N or more variables where N is the number of formal arguments before the period. There must be at least one argument before the period. The first N actual arguments will be stored into the newly allocated locations for the first N formal arguments and the sequence of the remaining actual arguments is converted into a list and the stored into the location for the last formal argument. If there are exactly N actual arguments, the empty list is stored into the location of the last formal argument. The list in VARIABLE or VARIABLEN+1 is always newly created and the procedure can modify it if desired. This is the case even when the procedure is invoked via ‘apply’, the required part of the list argument there will be copied (*note Procedures for On the Fly Evaluation: Fly Evaluation.). BODY is a sequence of Scheme expressions which are evaluated in order when the procedure is invoked. 6.7.2 Primitive Procedures -------------------------- Procedures written in C can be registered for use from Scheme, provided they take only arguments of type ‘SCM’ and return ‘SCM’ values. ‘scm_c_define_gsubr’ is likely to be the most useful mechanism, combining the process of registration (‘scm_c_make_gsubr’) and definition (‘scm_define’). -- Function: SCM scm_c_make_gsubr (const char *name, int req, int opt, int rst, fcn) Register a C procedure FCN as a "subr" -- a primitive subroutine that can be called from Scheme. It will be associated with the given NAME but no environment binding will be created. The arguments REQ, OPT and RST specify the number of required, optional and "rest" arguments respectively. The total number of these arguments should match the actual number of arguments to FCN, but may not exceed 10. The number of rest arguments should be 0 or 1. ‘scm_c_make_gsubr’ returns a value of type ‘SCM’ which is a "handle" for the procedure. -- Function: SCM scm_c_define_gsubr (const char *name, int req, int opt, int rst, fcn) Register a C procedure FCN, as for ‘scm_c_make_gsubr’ above, and additionally create a top-level Scheme binding for the procedure in the "current environment" using ‘scm_define’. ‘scm_c_define_gsubr’ returns a handle for the procedure in the same way as ‘scm_c_make_gsubr’, which is usually not further required. *Note Foreign Functions::, for another interface to call procedures written in C from Scheme. 6.7.3 Compiled Procedures ------------------------- The evaluation strategy given in *note Lambda:: describes how procedures are “interpreted”. Interpretation operates directly on expanded Scheme source code, recursively calling the evaluator to obtain the value of nested expressions. Most procedures are compiled, however. This means that Guile has done some pre-computation on the procedure, to determine what it will need to do each time the procedure runs. Compiled procedures run faster than interpreted procedures. Loading files is the normal way that compiled procedures come to being. If Guile sees that a file is uncompiled, or that its compiled file is out of date, it will attempt to compile the file when it is loaded, and save the result to disk. Procedures can be compiled at runtime as well. *Note Read/Load/Eval/Compile::, for more information on runtime compilation. Compiled procedures, also known as “programs”, respond to all procedures that operate on procedures: you can pass a program to ‘procedure?’, ‘procedure-name’, and so on (*note Procedure Properties::). In addition, there are a few more accessors for low-level details on programs. Most people won't need to use the routines described in this section, but it's good to have them documented. You'll have to include the appropriate module first, though: (use-modules (system vm program)) -- Scheme Procedure: program? obj -- C Function: scm_program_p (obj) Returns ‘#t’ if OBJ is a compiled procedure, or ‘#f’ otherwise. -- Scheme Procedure: program-code program -- C Function: scm_program_code (program) Returns the address of the program's entry, as an integer. This address is mostly useful to procedures in ‘(system vm debug)’. -- Scheme Procedure: program-num-free-variable program -- C Function: scm_program_num_free_variables (program) Return the number of free variables captured by this program. -- Scheme Procedure: program-free-variable-ref program n -- C Function: scm_program_free_variable-ref (program, n) -- Scheme Procedure: program-free-variable-set! program n val -- C Function: scm_program_free_variable_set_x (program, n, val) Accessors for a program's free variables. Some of the values captured are actually in variable "boxes". *Note Variables and the VM::, for more information. Users must not modify the returned value unless they think they're really clever. -- Scheme Procedure: program-sources program -- Scheme Procedure: source:addr source -- Scheme Procedure: source:line source -- Scheme Procedure: source:column source -- Scheme Procedure: source:file source Source location annotations for programs, along with their accessors. Source location information propagates through the compiler and ends up being serialized to the program's metadata. This information is keyed by the offset of the instruction pointer within the object code of the program. Specifically, it is keyed on the ‘ip’ _just following_ an instruction, so that backtraces can find the source location of a call that is in progress. -- Scheme Procedure: program-arities program -- C Function: scm_program_arities (program) -- Scheme Procedure: program-arity program ip -- Scheme Procedure: arity:start arity -- Scheme Procedure: arity:end arity -- Scheme Procedure: arity:nreq arity -- Scheme Procedure: arity:nopt arity -- Scheme Procedure: arity:rest? arity -- Scheme Procedure: arity:kw arity -- Scheme Procedure: arity:allow-other-keys? arity Accessors for a representation of the "arity" of a program. The normal case is that a procedure has one arity. For example, ‘(lambda (x) x)’, takes one required argument, and that's it. One could access that number of required arguments via ‘(arity:nreq (program-arities (lambda (x) x)))’. Similarly, ‘arity:nopt’ gets the number of optional arguments, and ‘arity:rest?’ returns a true value if the procedure has a rest arg. ‘arity:kw’ returns a list of ‘(KW . IDX)’ pairs, if the procedure has keyword arguments. The IDX refers to the IDXth local variable; *Note Variables and the VM::, for more information. Finally ‘arity:allow-other-keys?’ returns a true value if other keys are allowed. *Note Optional Arguments::, for more information. So what about ‘arity:start’ and ‘arity:end’, then? They return the range of bytes in the program's bytecode for which a given arity is valid. You see, a procedure can actually have more than one arity. The question, "what is a procedure's arity" only really makes sense at certain points in the program, delimited by these ‘arity:start’ and ‘arity:end’ values. -- Scheme Procedure: program-arguments-alist program [ip] Return an association list describing the arguments that PROGRAM accepts, or ‘#f’ if the information cannot be obtained. The alist keys that are currently defined are 'required', 'optional', 'keyword', 'allow-other-keys?', and 'rest'. For example: (program-arguments-alist (lambda* (a b #:optional c #:key (d 1) #:rest e) #t)) ⇒ ((required . (a b)) (optional . (c)) (keyword . ((#:d . 4))) (allow-other-keys? . #f) (rest . d)) -- Scheme Procedure: program-lambda-list program [ip] Return a representation of the arguments of PROGRAM as a lambda list, or ‘#f’ if this information is not available. For example: (program-lambda-list (lambda* (a b #:optional c #:key (d 1) #:rest e) #t)) ⇒ 6.7.4 Optional Arguments ------------------------ Scheme procedures, as defined in R5RS, can either handle a fixed number of actual arguments, or a fixed number of actual arguments followed by arbitrarily many additional arguments. Writing procedures of variable arity can be useful, but unfortunately, the syntactic means for handling argument lists of varying length is a bit inconvenient. It is possible to give names to the fixed number of arguments, but the remaining (optional) arguments can be only referenced as a list of values (*note Lambda::). For this reason, Guile provides an extension to ‘lambda’, ‘lambda*’, which allows the user to define procedures with optional and keyword arguments. In addition, Guile's virtual machine has low-level support for optional and keyword argument dispatch. Calls to procedures with optional and keyword arguments can be made cheaply, without allocating a rest list. 6.7.4.1 lambda* and define*. ............................ ‘lambda*’ is like ‘lambda’, except with some extensions to allow optional and keyword arguments. -- library syntax: lambda* ([var...] [#:optional vardef...] [#:key vardef... [#:allow-other-keys]] [#:rest var | . var]) body1 body2 ... Create a procedure which takes optional and/or keyword arguments specified with ‘#:optional’ and ‘#:key’. For example, (lambda* (a b #:optional c d . e) '()) is a procedure with fixed arguments A and B, optional arguments C and D, and rest argument E. If the optional arguments are omitted in a call, the variables for them are bound to ‘#f’. Likewise, ‘define*’ is syntactic sugar for defining procedures using ‘lambda*’. ‘lambda*’ can also make procedures with keyword arguments. For example, a procedure defined like this: (define* (sir-yes-sir #:key action how-high) (list action how-high)) can be called as ‘(sir-yes-sir #:action 'jump)’, ‘(sir-yes-sir #:how-high 13)’, ‘(sir-yes-sir #:action 'lay-down #:how-high 0)’, or just ‘(sir-yes-sir)’. Whichever arguments are given as keywords are bound to values (and those not given are ‘#f’). Optional and keyword arguments can also have default values to take when not present in a call, by giving a two-element list of variable name and expression. For example in (define* (frob foo #:optional (bar 42) #:key (baz 73)) (list foo bar baz)) FOO is a fixed argument, BAR is an optional argument with default value 42, and baz is a keyword argument with default value 73. Default value expressions are not evaluated unless they are needed, and until the procedure is called. Normally it's an error if a call has keywords other than those specified by ‘#:key’, but adding ‘#:allow-other-keys’ to the definition (after the keyword argument declarations) will ignore unknown keywords. If a call has a keyword given twice, the last value is used. For example, (define* (flips #:key (heads 0) (tails 0)) (display (list heads tails))) (flips #:heads 37 #:tails 42 #:heads 99) ⊣ (99 42) ‘#:rest’ is a synonym for the dotted syntax rest argument. The argument lists ‘(a . b)’ and ‘(a #:rest b)’ are equivalent in all respects. This is provided for more similarity to DSSSL, MIT-Scheme and Kawa among others, as well as for refugees from other Lisp dialects. When ‘#:key’ is used together with a rest argument, the keyword parameters in a call all remain in the rest list. This is the same as Common Lisp. For example, ((lambda* (#:key (x 0) #:allow-other-keys #:rest r) (display r)) #:x 123 #:y 456) ⊣ (#:x 123 #:y 456) ‘#:optional’ and ‘#:key’ establish their bindings successively, from left to right. This means default expressions can refer back to prior parameters, for example (lambda* (start #:optional (end (+ 10 start))) (do ((i start (1+ i))) ((> i end)) (display i))) The exception to this left-to-right scoping rule is the rest argument. If there is a rest argument, it is bound after the optional arguments, but before the keyword arguments. 6.7.4.2 (ice-9 optargs) ....................... Before Guile 2.0, ‘lambda*’ and ‘define*’ were implemented using macros that processed rest list arguments. This was not optimal, as calling procedures with optional arguments had to allocate rest lists at every procedure invocation. Guile 2.0 improved this situation by bringing optional and keyword arguments into Guile's core. However there are occasions in which you have a list and want to parse it for optional or keyword arguments. Guile's ‘(ice-9 optargs)’ provides some macros to help with that task. The syntax ‘let-optional’ and ‘let-optional*’ are for destructuring rest argument lists and giving names to the various list elements. ‘let-optional’ binds all variables simultaneously, while ‘let-optional*’ binds them sequentially, consistent with ‘let’ and ‘let*’ (*note Local Bindings::). -- library syntax: let-optional rest-arg (binding ...) body1 body2 ... -- library syntax: let-optional* rest-arg (binding ...) body1 body2 ... These two macros give you an optional argument interface that is very “Schemey” and introduces no fancy syntax. They are compatible with the scsh macros of the same name, but are slightly extended. Each of BINDING may be of one of the forms VAR or ‘(VAR DEFAULT-VALUE)’. REST-ARG should be the rest-argument of the procedures these are used from. The items in REST-ARG are sequentially bound to the variable names are given. When REST-ARG runs out, the remaining vars are bound either to the default values or ‘#f’ if no default value was specified. REST-ARG remains bound to whatever may have been left of REST-ARG. After binding the variables, the expressions BODY1 BODY2 ... are evaluated in order. Similarly, ‘let-keywords’ and ‘let-keywords*’ extract values from keyword style argument lists, binding local variables to those values or to defaults. -- library syntax: let-keywords args allow-other-keys? (binding ...) body1 body2 ... -- library syntax: let-keywords* args allow-other-keys? (binding ...) body1 body2 ... ARGS is evaluated and should give a list of the form ‘(#:keyword1 value1 #:keyword2 value2 ...)’. The BINDINGs are variables and default expressions, with the variables to be set (by name) from the keyword values. The BODY1 BODY2 ... forms are then evaluated and the last is the result. An example will make the syntax clearest, (define args '(#:xyzzy "hello" #:foo "world")) (let-keywords args #t ((foo "default for foo") (bar (string-append "default" "for" "bar"))) (display foo) (display ", ") (display bar)) ⊣ world, defaultforbar The binding for ‘foo’ comes from the ‘#:foo’ keyword in ‘args’. But the binding for ‘bar’ is the default in the ‘let-keywords’, since there's no ‘#:bar’ in the args. ALLOW-OTHER-KEYS? is evaluated and controls whether unknown keywords are allowed in the ARGS list. When true other keys are ignored (such as ‘#:xyzzy’ in the example), when ‘#f’ an error is thrown for anything unknown. ‘(ice-9 optargs)’ also provides some more ‘define*’ sugar, which is not so useful with modern Guile coding, but still supported: ‘define*-public’ is the ‘lambda*’ version of ‘define-public’; ‘defmacro*’ and ‘defmacro*-public’ exist for defining macros with the improved argument list handling possibilities. The ‘-public’ versions not only define the procedures/macros, but also export them from the current module. -- library syntax: define*-public formals body1 body2 ... Like a mix of ‘define*’ and ‘define-public’. -- library syntax: defmacro* name formals body1 body2 ... -- library syntax: defmacro*-public name formals body1 body2 ... These are just like ‘defmacro’ and ‘defmacro-public’ except that they take ‘lambda*’-style extended parameter lists, where ‘#:optional’, ‘#:key’, ‘#:allow-other-keys’ and ‘#:rest’ are allowed with the usual semantics. Here is an example of a macro with an optional argument: (defmacro* transmogrify (a #:optional b) (a 1)) 6.7.5 Case-lambda ----------------- R5RS's rest arguments are indeed useful and very general, but they often aren't the most appropriate or efficient means to get the job done. For example, ‘lambda*’ is a much better solution to the optional argument problem than ‘lambda’ with rest arguments. Likewise, ‘case-lambda’ works well for when you want one procedure to do double duty (or triple, or ...), without the penalty of consing a rest list. For example: (define (make-accum n) (case-lambda (() n) ((m) (set! n (+ n m)) n))) (define a (make-accum 20)) (a) ⇒ 20 (a 10) ⇒ 30 (a) ⇒ 30 The value returned by a ‘case-lambda’ form is a procedure which matches the number of actual arguments against the formals in the various clauses, in order. The first matching clause is selected, the corresponding values from the actual parameter list are bound to the variable names in the clauses and the body of the clause is evaluated. If no clause matches, an error is signaled. The syntax of the ‘case-lambda’ form is defined in the following EBNF grammar. “Formals” means a formal argument list just like with ‘lambda’ (*note Lambda::). --> (case-lambda *) --> (case-lambda *) --> ( *) --> (*) | (* . ) | Rest lists can be useful with ‘case-lambda’: (define plus (case-lambda "Return the sum of all arguments." (() 0) ((a) a) ((a b) (+ a b)) ((a b . rest) (apply plus (+ a b) rest)))) (plus 1 2 3) ⇒ 6 Also, for completeness. Guile defines ‘case-lambda*’ as well, which is like ‘case-lambda’, except with ‘lambda*’ clauses. A ‘case-lambda*’ clause matches if the arguments fill the required arguments, but are not too many for the optional and/or rest arguments. Keyword arguments are possible with ‘case-lambda*’ as well, but they do not contribute to the "matching" behavior, and their interactions with required, optional, and rest arguments can be surprising. For the purposes of ‘case-lambda*’ (and of ‘case-lambda’, as a special case), a clause “matches” if it has enough required arguments, and not too many positional arguments. The required arguments are any arguments before the ‘#:optional’, ‘#:key’, and ‘#:rest’ arguments. “Positional” arguments are the required arguments, together with the optional arguments. In the absence of ‘#:key’ or ‘#:rest’ arguments, it's easy to see how there could be too many positional arguments: you pass 5 arguments to a function that only takes 4 arguments, including optional arguments. If there is a ‘#:rest’ argument, there can never be too many positional arguments: any application with enough required arguments for a clause will match that clause, even if there are also ‘#:key’ arguments. Otherwise, for applications to a clause with ‘#:key’ arguments (and without a ‘#:rest’ argument), a clause will match there only if there are enough required arguments and if the next argument after binding required and optional arguments, if any, is a keyword. For efficiency reasons, Guile is currently unable to include keyword arguments in the matching algorithm. Clauses match on positional arguments only, not by comparing a given keyword to the available set of keyword arguments that a function has. Some examples follow. (define f (case-lambda* ((a #:optional b) 'clause-1) ((a #:optional b #:key c) 'clause-2) ((a #:key d) 'clause-3) ((#:key e #:rest f) 'clause-4))) (f) ⇒ clause-4 (f 1) ⇒ clause-1 (f) ⇒ clause-4 (f #:e 10) clause-1 (f 1 #:foo) clause-1 (f 1 #:c 2) clause-2 (f #:a #:b #:c #:d #:e) clause-4 ;; clause-2 will match anything that clause-3 would match. (f 1 #:d 2) ⇒ error: bad keyword args in clause 2 Don't forget that the clauses are matched in order, and the first matching clause will be taken. This can result in a keyword being bound to a required argument, as in the case of ‘f #:e 10’. 6.7.6 Higher-Order Functions ---------------------------- As a functional programming language, Scheme allows the definition of “higher-order functions”, i.e., functions that take functions as arguments and/or return functions. Utilities to derive procedures from other procedures are provided and described below. -- Scheme Procedure: const value Return a procedure that accepts any number of arguments and returns VALUE. (procedure? (const 3)) ⇒ #t ((const 'hello)) ⇒ hello ((const 'hello) 'world) ⇒ hello -- Scheme Procedure: negate proc Return a procedure with the same arity as PROC that returns the ‘not’ of PROC's result. (procedure? (negate number?)) ⇒ #t ((negate odd?) 2) ⇒ #t ((negate real?) 'dream) ⇒ #t ((negate string-prefix?) "GNU" "GNU Guile") ⇒ #f (filter (negate number?) '(a 2 "b")) ⇒ (a "b") -- Scheme Procedure: compose proc1 proc2 ... Compose PROC1 with the procedures PROC2 ... such that the last PROC argument is applied first and PROC1 last, and return the resulting procedure. The given procedures must have compatible arity. (procedure? (compose 1+ 1-)) ⇒ #t ((compose sqrt 1+ 1+) 2) ⇒ 2.0 ((compose 1+ sqrt) 3) ⇒ 2.73205080756888 (eq? (compose 1+) 1+) ⇒ #t ((compose zip unzip2) '((1 2) (a b))) ⇒ ((1 2) (a b)) -- Scheme Procedure: identity x Return X. -- Scheme Procedure: and=> value proc When VALUE is ‘#f’, return ‘#f’. Otherwise, return ‘(PROC VALUE)’. 6.7.7 Procedure Properties and Meta-information ----------------------------------------------- In addition to the information that is strictly necessary to run, procedures may have other associated information. For example, the name of a procedure is information not for the procedure, but about the procedure. This meta-information can be accessed via the procedure properties interface. -- Scheme Procedure: procedure? obj -- C Function: scm_procedure_p (obj) Return ‘#t’ if OBJ is a procedure. -- Scheme Procedure: thunk? obj -- C Function: scm_thunk_p (obj) Return ‘#t’ if OBJ is a procedure that can be called with zero arguments. *Note Compiled Procedures::, to get more information on what arguments a procedure will accept. Procedure properties are general properties associated with procedures. These can be the name of a procedure or other relevant information, such as debug hints. The most general way to associate a property of a procedure is programmatically: -- Scheme Procedure: procedure-property proc key -- C Function: scm_procedure_property (proc, key) Return the property of PROC with name KEY, or ‘#f’ if not found. -- Scheme Procedure: set-procedure-property! proc key value -- C Function: scm_set_procedure_property_x (proc, key, value) Set PROC's property named KEY to VALUE. However, there is a more efficient interface that allows constant properties to be embedded into compiled binaries in a way that does not incur any overhead until someone asks for the property: initial non-tail elements of the body of a lambda expression that are literal vectors of pairs are interpreted as declaring procedure properties. This is easiest to see with an example: (define proc (lambda args #((a . "hey") (b . "ho")) ;; procedure properties! 42)) (procedure-property proc 'a) ; ⇒ "hey" (procedure-property proc 'b) ; ⇒ "ho" There is a shorthand for declaring the ‘documentation’ property, which is a literal string instead of a literal vector: (define proc (lambda args "This is a docstring." 42)) (procedure-property proc 'documentation) ;; ⇒ "This is a docstring." Calling ‘procedure-property’ with a key of ‘documentation’ is exactly the same as calling ‘procedure-documentation’. Similarly, ‘procedure-name’ is the same as the ‘name’ procedure property, and ‘procedure-source’ is for the ‘source’ property. -- Scheme Procedure: procedure-name proc -- C Function: scm_procedure_name (proc) -- Scheme Procedure: procedure-source proc -- C Function: scm_procedure_source (proc) -- Scheme Procedure: procedure-documentation proc -- C Function: scm_procedure_documentation (proc) Return the value of the ‘name’, ‘source’, or ‘documentation’ property for PROC, or ‘#f’ if no property is set. One can also work on the entire set of procedure properties. -- Scheme Procedure: procedure-properties proc -- C Function: scm_procedure_properties (proc) Return the properties associated with PROC, as an association list. -- Scheme Procedure: set-procedure-properties! proc alist -- C Function: scm_set_procedure_properties_x (proc, alist) Set PROC's property list to ALIST. 6.7.8 Procedures with Setters ----------------------------- A “procedure with setter” is a special kind of procedure which normally behaves like any accessor procedure, that is a procedure which accesses a data structure. The difference is that this kind of procedure has a so-called “setter” attached, which is a procedure for storing something into a data structure. Procedures with setters are treated specially when the procedure appears in the special form ‘set!’. How it works is best shown by example. Suppose we have a procedure called ‘foo-ref’, which accepts two arguments, a value of type ‘foo’ and an integer. The procedure returns the value stored at the given index in the ‘foo’ object. Let ‘f’ be a variable containing such a ‘foo’ data structure.(1) (foo-ref f 0) ⇒ bar (foo-ref f 1) ⇒ braz Also suppose that a corresponding setter procedure called ‘foo-set!’ does exist. (foo-set! f 0 'bla) (foo-ref f 0) ⇒ bla Now we could create a new procedure called ‘foo’, which is a procedure with setter, by calling ‘make-procedure-with-setter’ with the accessor and setter procedures ‘foo-ref’ and ‘foo-set!’. Let us call this new procedure ‘foo’. (define foo (make-procedure-with-setter foo-ref foo-set!)) ‘foo’ can from now on be used to either read from the data structure stored in ‘f’, or to write into the structure. (set! (foo f 0) 'dum) (foo f 0) ⇒ dum -- Scheme Procedure: make-procedure-with-setter procedure setter -- C Function: scm_make_procedure_with_setter (procedure, setter) Create a new procedure which behaves like PROCEDURE, but with the associated setter SETTER. -- Scheme Procedure: procedure-with-setter? obj -- C Function: scm_procedure_with_setter_p (obj) Return ‘#t’ if OBJ is a procedure with an associated setter procedure. -- Scheme Procedure: procedure proc -- C Function: scm_procedure (proc) Return the procedure of PROC, which must be an applicable struct. -- Scheme Procedure: setter proc Return the setter of PROC, which must be either a procedure with setter or an operator struct. ---------- Footnotes ---------- (1) Working definitions would be: (define foo-ref vector-ref) (define foo-set! vector-set!) (define f (make-vector 2 #f)) 6.7.9 Inlinable Procedures -------------------------- You can define an “inlinable procedure” by using ‘define-inlinable’ instead of ‘define’. An inlinable procedure behaves the same as a regular procedure, but direct calls will result in the procedure body being inlined into the caller. Bear in mind that starting from version 2.0.3, Guile has a partial evaluator that can inline the body of inner procedures when deemed appropriate: scheme@(guile-user)> ,optimize (define (foo x) (define (bar) (+ x 3)) (* (bar) 2)) $1 = (define foo (lambda (#{x 94}#) (* (+ #{x 94}# 3) 2))) The partial evaluator does not inline top-level bindings, though, so this is a situation where you may find it interesting to use ‘define-inlinable’. Procedures defined with ‘define-inlinable’ are _always_ inlined, at all direct call sites. This eliminates function call overhead at the expense of an increase in code size. Additionally, the caller will not transparently use the new definition if the inline procedure is redefined. It is not possible to trace an inlined procedures or install a breakpoint in it (*note Traps::). For these reasons, you should not make a procedure inlinable unless it demonstrably improves performance in a crucial way. In general, only small procedures should be considered for inlining, as making large procedures inlinable will probably result in an increase in code size. Additionally, the elimination of the call overhead rarely matters for large procedures. -- Scheme Syntax: define-inlinable (name parameter ...) body1 body2 ... Define NAME as a procedure with parameters PARAMETERs and bodies BODY1, BODY2, .... 6.8 Macros ========== At its best, programming in Lisp is an iterative process of building up a language appropriate to the problem at hand, and then solving the problem in that language. Defining new procedures is part of that, but Lisp also allows the user to extend its syntax, with its famous “macros”. Macros are syntactic extensions which cause the expression that they appear in to be transformed in some way _before_ being evaluated. In expressions that are intended for macro transformation, the identifier that names the relevant macro must appear as the first element, like this: (MACRO-NAME MACRO-ARGS ...) Macro expansion is a separate phase of evaluation, run before code is interpreted or compiled. A macro is a program that runs on programs, translating an embedded language into core Scheme(1). ---------- Footnotes ---------- (1) These days such embedded languages are often referred to as “embedded domain-specific languages”, or EDSLs. 6.8.1 Defining Macros --------------------- A macro is a binding between a keyword and a syntax transformer. Since it's difficult to discuss ‘define-syntax’ without discussing the format of transformers, consider the following example macro definition: (define-syntax when (syntax-rules () ((when condition exp ...) (if condition (begin exp ...))))) (when #t (display "hey ho\n") (display "let's go\n")) ⊣ hey ho ⊣ let's go In this example, the ‘when’ binding is bound with ‘define-syntax’. Syntax transformers are discussed in more depth in *note Syntax Rules:: and *note Syntax Case::. -- Syntax: define-syntax keyword transformer Bind KEYWORD to the syntax transformer obtained by evaluating TRANSFORMER. After a macro has been defined, further instances of KEYWORD in Scheme source code will invoke the syntax transformer defined by TRANSFORMER. One can also establish local syntactic bindings with ‘let-syntax’. -- Syntax: let-syntax ((keyword transformer) ...) exp1 exp2 ... Bind each KEYWORD to its corresponding TRANSFORMER while expanding EXP1 EXP2 .... A ‘let-syntax’ binding only exists at expansion-time. (let-syntax ((unless (syntax-rules () ((unless condition exp ...) (if (not condition) (begin exp ...)))))) (unless #t (primitive-exit 1)) "rock rock rock") ⇒ "rock rock rock" A ‘define-syntax’ form is valid anywhere a definition may appear: at the top-level, or locally. Just as a local ‘define’ expands out to an instance of ‘letrec’, a local ‘define-syntax’ expands out to ‘letrec-syntax’. -- Syntax: letrec-syntax ((keyword transformer) ...) exp1 exp2 ... Bind each KEYWORD to its corresponding TRANSFORMER while expanding EXP1 EXP2 .... In the spirit of ‘letrec’ versus ‘let’, an expansion produced by TRANSFORMER may reference a KEYWORD bound by the same LETREC-SYNTAX. (letrec-syntax ((my-or (syntax-rules () ((my-or) #t) ((my-or exp) exp) ((my-or exp rest ...) (let ((t exp)) (if t t (my-or rest ...))))))) (my-or #f "rockaway beach")) ⇒ "rockaway beach" 6.8.2 Syntax-rules Macros ------------------------- ‘syntax-rules’ macros are simple, pattern-driven syntax transformers, with a beauty worthy of Scheme. -- Syntax: syntax-rules literals (pattern template) ... Create a syntax transformer that will rewrite an expression using the rules embodied in the PATTERN and TEMPLATE clauses. A ‘syntax-rules’ macro consists of three parts: the literals (if any), the patterns, and as many templates as there are patterns. When the syntax expander sees the invocation of a ‘syntax-rules’ macro, it matches the expression against the patterns, in order, and rewrites the expression using the template from the first matching pattern. If no pattern matches, a syntax error is signaled. 6.8.2.1 Patterns ................ We have already seen some examples of patterns in the previous section: ‘(unless condition exp ...)’, ‘(my-or exp)’, and so on. A pattern is structured like the expression that it is to match. It can have nested structure as well, like ‘(let ((var val) ...) exp exp* ...)’. Broadly speaking, patterns are made of lists, improper lists, vectors, identifiers, and datums. Users can match a sequence of patterns using the ellipsis (‘...’). Identifiers in a pattern are called “literals” if they are present in the ‘syntax-rules’ literals list, and “pattern variables” otherwise. When building up the macro output, the expander replaces instances of a pattern variable in the template with the matched subexpression. (define-syntax kwote (syntax-rules () ((kwote exp) (quote exp)))) (kwote (foo . bar)) ⇒ (foo . bar) An improper list of patterns matches as rest arguments do: (define-syntax let1 (syntax-rules () ((_ (var val) . exps) (let ((var val)) . exps)))) However this definition of ‘let1’ probably isn't what you want, as the tail pattern EXPS will match non-lists, like ‘(let1 (foo 'bar) . baz)’. So often instead of using improper lists as patterns, ellipsized patterns are better. Instances of a pattern variable in the template must be followed by an ellipsis. (define-syntax let1 (syntax-rules () ((_ (var val) exp ...) (let ((var val)) exp ...)))) This ‘let1’ probably still doesn't do what we want, because the body matches sequences of zero expressions, like ‘(let1 (foo 'bar))’. In this case we need to assert we have at least one body expression. A common idiom for this is to name the ellipsized pattern variable with an asterisk: (define-syntax let1 (syntax-rules () ((_ (var val) exp exp* ...) (let ((var val)) exp exp* ...)))) A vector of patterns matches a vector whose contents match the patterns, including ellipsizing and tail patterns. (define-syntax letv (syntax-rules () ((_ #((var val) ...) exp exp* ...) (let ((var val) ...) exp exp* ...)))) (letv #((foo 'bar)) foo) ⇒ bar Literals are used to match specific datums in an expression, like the use of ‘=>’ and ‘else’ in ‘cond’ expressions. (define-syntax cond1 (syntax-rules (=> else) ((cond1 test => fun) (let ((exp test)) (if exp (fun exp) #f))) ((cond1 else exp exp* ...) (begin exp exp* ...)) ((cond1 test exp exp* ...) (if test (begin exp exp* ...))))) (define (square x) (* x x)) (cond1 10 => square) ⇒ 100 (let ((=> #t)) (cond1 10 => square)) ⇒ # A literal matches an input expression if the input expression is an identifier with the same name as the literal, and both are unbound(1). Although literals can be unbound, usually they are bound to allow them to be imported, exported, and renamed. *Note Modules::, for more information on imports and exports. In Guile there are a few standard auxiliary syntax definitions, as specified by R6RS and R7RS: -- Scheme Syntax: else -- Scheme Syntax: => -- Scheme Syntax: _ -- Scheme Syntax: ... Auxiliary syntax definitions. These are defined with a macro that never matches, e.g.: (define-syntax else (syntax-rules ())) If a pattern is not a list, vector, or an identifier, it matches as a literal, with ‘equal?’. (define-syntax define-matcher-macro (syntax-rules () ((_ name lit) (define-syntax name (syntax-rules () ((_ lit) #t) ((_ else) #f)))))) (define-matcher-macro is-literal-foo? "foo") (is-literal-foo? "foo") ⇒ #t (is-literal-foo? "bar") ⇒ #f (let ((foo "foo")) (is-literal-foo? foo)) ⇒ #f The last example indicates that matching happens at expansion-time, not at run-time. Syntax-rules macros are always used as ‘(MACRO . ARGS)’, and the MACRO will always be a symbol. Correspondingly, a ‘syntax-rules’ pattern must be a list (proper or improper), and the first pattern in that list must be an identifier. Incidentally it can be any identifier - it doesn't have to actually be the name of the macro. Thus the following three are equivalent: (define-syntax when (syntax-rules () ((when c e ...) (if c (begin e ...))))) (define-syntax when (syntax-rules () ((_ c e ...) (if c (begin e ...))))) (define-syntax when (syntax-rules () ((something-else-entirely c e ...) (if c (begin e ...))))) For clarity, use one of the first two variants. Also note that since the pattern variable will always match the macro itself (e.g., ‘cond1’), it is actually left unbound in the template. 6.8.2.2 Hygiene ............... ‘syntax-rules’ macros have a magical property: they preserve referential transparency. When you read a macro definition, any free bindings in that macro are resolved relative to the macro definition; and when you read a macro instantiation, all free bindings in that expression are resolved relative to the expression. This property is sometimes known as “hygiene”, and it does aid in code cleanliness. In your macro definitions, you can feel free to introduce temporary variables, without worrying about inadvertently introducing bindings into the macro expansion. Consider the definition of ‘my-or’ from the previous section: (define-syntax my-or (syntax-rules () ((my-or) #t) ((my-or exp) exp) ((my-or exp rest ...) (let ((t exp)) (if t t (my-or rest ...)))))) A naive expansion of ‘(let ((t #t)) (my-or #f t))’ would yield: (let ((t #t)) (let ((t #f)) (if t t t))) ⇒ #f Which clearly is not what we want. Somehow the ‘t’ in the definition is distinct from the ‘t’ at the site of use; and it is indeed this distinction that is maintained by the syntax expander, when expanding hygienic macros. This discussion is mostly relevant in the context of traditional Lisp macros (*note Defmacros::), which do not preserve referential transparency. Hygiene adds to the expressive power of Scheme. 6.8.2.3 Shorthands .................. One often ends up writing simple one-clause ‘syntax-rules’ macros. There is a convenient shorthand for this idiom, in the form of ‘define-syntax-rule’. -- Syntax: define-syntax-rule (keyword . pattern) [docstring] template Define KEYWORD as a new ‘syntax-rules’ macro with one clause. Cast into this form, our ‘when’ example is significantly shorter: (define-syntax-rule (when c e ...) (if c (begin e ...))) 6.8.2.4 Reporting Syntax Errors in Macros ......................................... -- Syntax: syntax-error message [arg ...] Report an error at macro-expansion time. MESSAGE must be a string literal, and the optional ARG operands can be arbitrary expressions providing additional information. ‘syntax-error’ is intended to be used within ‘syntax-rules’ templates. For example: (define-syntax simple-let (syntax-rules () ((_ (head ... ((x . y) val) . tail) body1 body2 ...) (syntax-error "expected an identifier but got" (x . y))) ((_ ((name val) ...) body1 body2 ...) ((lambda (name ...) body1 body2 ...) val ...)))) 6.8.2.5 Specifying a Custom Ellipsis Identifier ............................................... When writing macros that generate macro definitions, it is convenient to use a different ellipsis identifier at each level. Guile allows the desired ellipsis identifier to be specified as the first operand to ‘syntax-rules’, as specified by SRFI-46 and R7RS. For example: (define-syntax define-quotation-macros (syntax-rules () ((_ (macro-name head-symbol) ...) (begin (define-syntax macro-name (syntax-rules ::: () ((_ x :::) (quote (head-symbol x :::))))) ...)))) (define-quotation-macros (quote-a a) (quote-b b) (quote-c c)) (quote-a 1 2 3) ⇒ (a 1 2 3) 6.8.2.6 Further Information ........................... For a formal definition of ‘syntax-rules’ and its pattern language, see *Note Macros: (r5rs)Macros. ‘syntax-rules’ macros are simple and clean, but do they have limitations. They do not lend themselves to expressive error messages: patterns either match or they don't. Their ability to generate code is limited to template-driven expansion; often one needs to define a number of helper macros to get real work done. Sometimes one wants to introduce a binding into the lexical context of the generated code; this is impossible with ‘syntax-rules’. Relatedly, they cannot programmatically generate identifiers. The solution to all of these problems is to use ‘syntax-case’ if you need its features. But if for some reason you're stuck with ‘syntax-rules’, you might enjoy Joe Marshall's ‘syntax-rules’ Primer for the Merely Eccentric (https://web.archive.org/web/20121111060531/ https://d655165b-a-62cb3a1a-s-sites.googlegroups.com/site/evalapply/ eccentric.txt?attachauth=ANoY7cqZJK0iAkVoFlTZqjKSFX1rW6pgA71to347P957URfJwmFRH 5Yyddp6gASBSaG38_9MfSlq59KN5Ozzja0WMVuHWi5a_bfGeJHv13bfhYbtwA8WcVHaL_xTA5AvlLH __qHKE2UVPj2qrWYyrcBCx3ihmR8CWUfyo8D4GbdvFGkNon3owtrR_CL_wbPr7VGE_8Gq0aJp7tWGt tZSjip9rySlqAO4aQ%3D%3D&attredirects=0).(2) ---------- Footnotes ---------- (1) Language lawyers probably see the need here for use of ‘literal-identifier=?’ rather than ‘free-identifier=?’, and would probably be correct. Patches accepted. (2) Archived from the original (http://sites.google.com/site/evalapply/eccentric.txt) on 2013-05-03. 6.8.3 Support for the ‘syntax-case’ System ------------------------------------------ ‘syntax-case’ macros are procedural syntax transformers, with a power worthy of Scheme. -- Syntax: syntax-case syntax literals (pattern [guard] exp) ... Match the syntax object SYNTAX against the given patterns, in order. If a PATTERN matches, return the result of evaluating the associated EXP. Compare the following definitions of ‘when’: (define-syntax when (syntax-rules () ((_ test e e* ...) (if test (begin e e* ...))))) (define-syntax when (lambda (x) (syntax-case x () ((_ test e e* ...) #'(if test (begin e e* ...)))))) Clearly, the ‘syntax-case’ definition is similar to its ‘syntax-rules’ counterpart, and equally clearly there are some differences. The ‘syntax-case’ definition is wrapped in a ‘lambda’, a function of one argument; that argument is passed to the ‘syntax-case’ invocation; and the "return value" of the macro has a ‘#'’ prefix. All of these differences stem from the fact that ‘syntax-case’ does not define a syntax transformer itself - instead, ‘syntax-case’ expressions provide a way to destructure a “syntax object”, and to rebuild syntax objects as output. So the ‘lambda’ wrapper is simply a leaky implementation detail, that syntax transformers are just functions that transform syntax to syntax. This should not be surprising, given that we have already described macros as "programs that write programs". ‘syntax-case’ is simply a way to take apart and put together program text, and to be a valid syntax transformer it needs to be wrapped in a procedure. Unlike traditional Lisp macros (*note Defmacros::), ‘syntax-case’ macros transform syntax objects, not raw Scheme forms. Recall the naive expansion of ‘my-or’ given in the previous section: (let ((t #t)) (my-or #f t)) ;; naive expansion: (let ((t #t)) (let ((t #f)) (if t t t))) Raw Scheme forms simply don't have enough information to distinguish the first two ‘t’ instances in ‘(if t t t)’ from the third ‘t’. So instead of representing identifiers as symbols, the syntax expander represents identifiers as annotated syntax objects, attaching such information to those syntax objects as is needed to maintain referential transparency. -- Syntax: syntax form Create a syntax object wrapping FORM within the current lexical context. Syntax objects are typically created internally to facilitate the process of expansion, but it is possible to create them outside of syntax expansion: (syntax (foo bar baz)) ⇒ # However it is more common, and useful, to create syntax objects when building output from a ‘syntax-case’ expression. (define-syntax add1 (lambda (x) (syntax-case x () ((_ exp) (syntax (+ exp 1)))))) It is not strictly necessary for a ‘syntax-case’ expression to return a syntax object, because ‘syntax-case’ expressions can be used in helper functions, or otherwise used outside of syntax expansion itself. However a syntax transformer procedure must return a syntax object, so most uses of ‘syntax-case’ do end up returning syntax objects. Here in this case, the form that built the return value was ‘(syntax (+ exp 1))’. The interesting thing about this is that within a ‘syntax’ expression, any appearance of a pattern variable is substituted into the resulting syntax object, carrying with it all relevant metadata from the source expression, such as lexical identity and source location. Indeed, a pattern variable may only be referenced from inside a ‘syntax’ form. The syntax expander would raise an error when defining ‘add1’ if it found EXP referenced outside a ‘syntax’ form. Since ‘syntax’ appears frequently in macro-heavy code, it has a special reader macro: ‘#'’. ‘#'foo’ is transformed by the reader into ‘(syntax foo)’, just as ‘'foo’ is transformed into ‘(quote foo)’. The pattern language used by ‘syntax-case’ is conveniently the same language used by ‘syntax-rules’. Given this, Guile actually defines ‘syntax-rules’ in terms of ‘syntax-case’: (define-syntax syntax-rules (lambda (x) (syntax-case x () ((_ (k ...) ((keyword . pattern) template) ...) #'(lambda (x) (syntax-case x (k ...) ((dummy . pattern) #'template) ...)))))) And that's that. 6.8.3.1 Why ‘syntax-case’? .......................... The examples we have shown thus far could just as well have been expressed with ‘syntax-rules’, and have just shown that ‘syntax-case’ is more verbose, which is true. But there is a difference: ‘syntax-case’ creates _procedural_ macros, giving the full power of Scheme to the macro expander. This has many practical applications. A common desire is to be able to match a form only if it is an identifier. This is impossible with ‘syntax-rules’, given the datum matching forms. But with ‘syntax-case’ it is easy: -- Scheme Procedure: identifier? syntax-object Returns ‘#t’ if SYNTAX-OBJECT is an identifier, or ‘#f’ otherwise. ;; relying on previous add1 definition (define-syntax add1! (lambda (x) (syntax-case x () ((_ var) (identifier? #'var) #'(set! var (add1 var)))))) (define foo 0) (add1! foo) foo ⇒ 1 (add1! "not-an-identifier") ⇒ error With ‘syntax-rules’, the error for ‘(add1! "not-an-identifier")’ would be something like "invalid ‘set!’". With ‘syntax-case’, it will say something like "invalid ‘add1!’", because we attach the “guard clause” to the pattern: ‘(identifier? #'var)’. This becomes more important with more complicated macros. It is necessary to use ‘identifier?’, because to the expander, an identifier is more than a bare symbol. Note that even in the guard clause, we reference the VAR pattern variable within a ‘syntax’ form, via ‘#'var’. Another common desire is to introduce bindings into the lexical context of the output expression. One example would be in the so-called "anaphoric macros", like ‘aif’. Anaphoric macros bind some expression to a well-known identifier, often ‘it’, within their bodies. For example, in ‘(aif (foo) (bar it))’, ‘it’ would be bound to the result of ‘(foo)’. To begin with, we should mention a solution that doesn't work: ;; doesn't work (define-syntax aif (lambda (x) (syntax-case x () ((_ test then else) #'(let ((it test)) (if it then else)))))) The reason that this doesn't work is that, by default, the expander will preserve referential transparency; the THEN and ELSE expressions won't have access to the binding of ‘it’. But they can, if we explicitly introduce a binding via ‘datum->syntax’. -- Scheme Procedure: datum->syntax template-id datum [#:source=#f] Create a syntax object that wraps DATUM, within the lexical context corresponding to the identifier TEMPLATE-ID. If TEMPLATE-ID is false, the datum will have no lexical context information. Syntax objects have an associated source location. Internally this is represented as a 3-element vector of filename, line, and column. Usually this location ultimately is provided by ‘read-syntax’; *Note Annotated Scheme Read::. If a syntax object is passed as SOURCE, the resulting syntax object will have the source location of SOURCE. Otherwise if SOURCE is a 3-element source location vector, that vector will be the source location of the resulting syntax object. If SOURCE is a source properties alist, those will be parsed and set as the source location of the resulting syntax object. Otherwise if SOURCE is false, the source properties are looked up from ‘(source-properties DATUM)’. *Note Source Properties::. For completeness, we should mention that it is possible to strip the metadata from a syntax object, returning a raw Scheme datum: -- Scheme Procedure: syntax->datum syntax-object Strip the metadata from SYNTAX-OBJECT, returning its contents as a raw Scheme datum. In this case we want to introduce ‘it’ in the context of the whole expression, so we can create a syntax object as ‘(datum->syntax x 'it)’, where ‘x’ is the whole expression, as passed to the transformer procedure. Here's another solution that doesn't work: ;; doesn't work either (define-syntax aif (lambda (x) (syntax-case x () ((_ test then else) (let ((it (datum->syntax x 'it))) #'(let ((it test)) (if it then else))))))) The reason that this one doesn't work is that there are really two environments at work here - the environment of pattern variables, as bound by ‘syntax-case’, and the environment of lexical variables, as bound by normal Scheme. The outer let form establishes a binding in the environment of lexical variables, but the inner let form is inside a syntax form, where only pattern variables will be substituted. Here we need to introduce a piece of the lexical environment into the pattern variable environment, and we can do so using ‘syntax-case’ itself: ;; works, but is obtuse (define-syntax aif (lambda (x) (syntax-case x () ((_ test then else) ;; invoking syntax-case on the generated ;; syntax object to expose it to `syntax' (syntax-case (datum->syntax x 'it) () (it #'(let ((it test)) (if it then else)))))))) (aif (getuid) (display it) (display "none")) (newline) ⊣ 500 However there are easier ways to write this. ‘with-syntax’ is often convenient: -- Syntax: with-syntax ((pat val) ...) exp ... Bind patterns PAT from their corresponding values VAL, within the lexical context of EXP .... ;; better (define-syntax aif (lambda (x) (syntax-case x () ((_ test then else) (with-syntax ((it (datum->syntax x 'it))) #'(let ((it test)) (if it then else))))))) As you might imagine, ‘with-syntax’ is defined in terms of ‘syntax-case’. But even that might be off-putting to you if you are an old Lisp macro hacker, used to building macro output with ‘quasiquote’. The issue is that ‘with-syntax’ creates a separation between the point of definition of a value and its point of substitution. So for cases in which a ‘quasiquote’ style makes more sense, ‘syntax-case’ also defines ‘quasisyntax’, and the related ‘unsyntax’ and ‘unsyntax-splicing’, abbreviated by the reader as ‘#`’, ‘#,’, and ‘#,@’, respectively. For example, to define a macro that inserts a compile-time timestamp into a source file, one may write: (define-syntax display-compile-timestamp (lambda (x) (syntax-case x () ((_) #`(begin (display "The compile timestamp was: ") (display #,(current-time)) (newline)))))) Readers interested in further information on ‘syntax-case’ macros should see R. Kent Dybvig's excellent ‘The Scheme Programming Language’, either edition 3 or 4, in the chapter on syntax. Dybvig was the primary author of the ‘syntax-case’ system. The book itself is available online at . 6.8.3.2 Custom Ellipsis Identifiers for syntax-case Macros .......................................................... When writing procedural macros that generate macro definitions, it is convenient to use a different ellipsis identifier at each level. Guile supports this for procedural macros using the ‘with-ellipsis’ special form: -- Syntax: with-ellipsis ellipsis body ... ELLIPSIS must be an identifier. Evaluate BODY in a special lexical environment such that all macro patterns and templates within BODY will use ELLIPSIS as the ellipsis identifier instead of the usual three dots (‘...’). For example: (define-syntax define-quotation-macros (lambda (x) (syntax-case x () ((_ (macro-name head-symbol) ...) #'(begin (define-syntax macro-name (lambda (x) (with-ellipsis ::: (syntax-case x () ((_ x :::) #'(quote (head-symbol x :::))))))) ...))))) (define-quotation-macros (quote-a a) (quote-b b) (quote-c c)) (quote-a 1 2 3) ⇒ (a 1 2 3) Note that ‘with-ellipsis’ does not affect the ellipsis identifier of the generated code, unless ‘with-ellipsis’ is included around the generated code. 6.8.3.3 Syntax objects can be data too ...................................... Generally speaking, you want the macro expander to pick apart all syntax objects in a source term. The source and scope annotations attached to the syntax object are of interest to how the macro expander computes the result, but no syntax object itself should appear in the expanded term--usually. Sometimes, though, a macro will want a syntax object to appear in the expanded output. Normally you would just use ‘quote’ to introduce the syntax object as a value, but the expander strips syntax objects from subexpression of ‘quote’. For this rare use case, Guile has ‘quote-syntax’, which does not strip its subexpression. -- Syntax: quote-syntax form Expand to the syntax object ‘form’, as a constant literal. Like ‘quote’, but without calling ‘syntax->datum’. 6.8.4 Syntax Transformer Helpers -------------------------------- As noted in the previous section, Guile's syntax expander operates on syntax objects. Procedural macros consume and produce syntax objects. This section describes some of the auxiliary helpers that procedural macros can use to compare, generate, and query objects of this data type. -- Scheme Procedure: bound-identifier=? a b Return ‘#t’ if the syntax objects A and B refer to the same lexically-bound identifier, or ‘#f’ otherwise. -- Scheme Procedure: free-identifier=? a b Return ‘#t’ if the syntax objects A and B refer to the same free identifier, or ‘#f’ otherwise. -- Scheme Procedure: generate-temporaries ls Return a list of temporary identifiers as long as LS is long. -- Scheme Procedure: syntax-source x Return the source properties that correspond to the syntax object X. *Note Source Properties::, for more information. Guile also offers some more experimental interfaces in a separate module. As was the case with the Large Hadron Collider, it is unclear to our senior macrologists whether adding these interfaces will result in awesomeness or in the destruction of Guile via the creation of a singularity. We will preserve their functionality through the 2.0 series, but we reserve the right to modify them in a future stable series, to a more than usual degree. (use-modules (system syntax)) -- Scheme Procedure: syntax-module id Return the name of the module whose source contains the identifier ID. -- Scheme Procedure: syntax-sourcev stx Like ‘syntax-source’, but returns its result in a more compact ‘#(FILENAME LINE COLUMN)’ format. This format is used as the internal representation of source locations for syntax objects. -- Scheme Procedure: syntax-local-binding id [#:resolve-syntax-parameters?=#t] Resolve the identifier ID, a syntax object, within the current lexical environment, and return two values, the binding type and a binding value. The binding type is a symbol, which may be one of the following: ‘lexical’ A lexically-bound variable. The value is a unique token (in the sense of ‘eq?’) identifying this binding. ‘macro’ A syntax transformer, either local or global. The value is the transformer procedure. ‘syntax-parameter’ A syntax parameter (*note Syntax Parameters::). By default, ‘syntax-local-binding’ will resolve syntax parameters, so that this value will not be returned. Pass ‘#:resolve-syntax-parameters? #f’ to indicate that you are interested in syntax parameters. The value is the default transformer procedure, as in ‘macro’. ‘pattern-variable’ A pattern variable, bound via ‘syntax-case’. The value is an opaque object, internal to the expander. ‘ellipsis’ An internal binding, bound via ‘with-ellipsis’. The value is the (anti-marked) local ellipsis identifier. ‘displaced-lexical’ A lexical variable that has gone out of scope. This can happen if a badly-written procedural macro saves a syntax object, then attempts to introduce it in a context in which it is unbound. The value is ‘#f’. ‘global’ A global binding. The value is a pair, whose head is the symbol, and whose tail is the name of the module in which to resolve the symbol. ‘other’ Some other binding, like ‘lambda’ or other core bindings. The value is ‘#f’. This is a very low-level procedure, with limited uses. One case in which it is useful is to build abstractions that associate auxiliary information with macros: (define aux-property (make-object-property)) (define-syntax-rule (with-aux aux value) (let ((trans value)) (set! (aux-property trans) aux) trans)) (define-syntax retrieve-aux (lambda (x) (syntax-case x () ((x id) (call-with-values (lambda () (syntax-local-binding #'id)) (lambda (type val) (with-syntax ((aux (datum->syntax #'here (and (eq? type 'macro) (aux-property val))))) #''aux))))))) (define-syntax foo (with-aux 'bar (syntax-rules () ((_) 'foo)))) (foo) ⇒ foo (retrieve-aux foo) ⇒ bar ‘syntax-local-binding’ must be called within the dynamic extent of a syntax transformer; to call it otherwise will signal an error. -- Scheme Procedure: syntax-locally-bound-identifiers id Return a list of identifiers that were visible lexically when the identifier ID was created, in order from outermost to innermost. This procedure is intended to be used in specialized procedural macros, to provide a macro with the set of bound identifiers that the macro can reference. As a technical implementation detail, the identifiers returned by ‘syntax-locally-bound-identifiers’ will be anti-marked, like the syntax object that is given as input to a macro. This is to signal to the macro expander that these bindings were present in the original source, and do not need to be hygienically renamed, as would be the case with other introduced identifiers. See the discussion of hygiene in section 12.1 of the R6RS, for more information on marks. (define (local-lexicals id) (filter (lambda (x) (eq? (syntax-local-binding x) 'lexical)) (syntax-locally-bound-identifiers id))) (define-syntax lexicals (lambda (x) (syntax-case x () ((lexicals) #'(lexicals lexicals)) ((lexicals scope) (with-syntax (((id ...) (local-lexicals #'scope))) #'(list (cons 'id id) ...)))))) (let* ((x 10) (x 20)) (lexicals)) ⇒ ((x . 10) (x . 20)) 6.8.5 Lisp-style Macro Definitions ---------------------------------- The traditional way to define macros in Lisp is very similar to procedure definitions. The key differences are that the macro definition body should return a list that describes the transformed expression, and that the definition is marked as a macro definition (rather than a procedure definition) by the use of a different definition keyword: in Lisp, ‘defmacro’ rather than ‘defun’, and in Scheme, ‘define-macro’ rather than ‘define’. Guile supports this style of macro definition using both ‘defmacro’ and ‘define-macro’. The only difference between them is how the macro name and arguments are grouped together in the definition: (defmacro NAME (ARGS ...) BODY ...) is the same as (define-macro (NAME ARGS ...) BODY ...) The difference is analogous to the corresponding difference between Lisp's ‘defun’ and Scheme's ‘define’. Having read the previous section on ‘syntax-case’, it's probably clear that Guile actually implements defmacros in terms of ‘syntax-case’, applying the transformer on the expression between invocations of ‘syntax->datum’ and ‘datum->syntax’. This realization leads us to the problem with defmacros, that they do not preserve referential transparency. One can be careful to not introduce bindings into expanded code, via liberal use of ‘gensym’, but there is no getting around the lack of referential transparency for free bindings in the macro itself. Even a macro as simple as our ‘when’ from before is difficult to get right: (define-macro (when cond exp . rest) `(if ,cond (begin ,exp . ,rest))) (when #f (display "Launching missiles!\n")) ⇒ #f (let ((if list)) (when #f (display "Launching missiles!\n"))) ⊣ Launching missiles! ⇒ (#f #) Guile's perspective is that defmacros have had a good run, but that modern macros should be written with ‘syntax-rules’ or ‘syntax-case’. There are still many uses of defmacros within Guile itself, but we will be phasing them out over time. Of course we won't take away ‘defmacro’ or ‘define-macro’ themselves, as there is lots of code out there that uses them. 6.8.6 Identifier Macros ----------------------- When the syntax expander sees a form in which the first element is a macro, the whole form gets passed to the macro's syntax transformer. One may visualize this as: (define-syntax foo foo-transformer) (foo ARG...) ;; expands via (foo-transformer #'(foo ARG...)) If, on the other hand, a macro is referenced in some other part of a form, the syntax transformer is invoked with only the macro reference, not the whole form. (define-syntax foo foo-transformer) foo ;; expands via (foo-transformer #'foo) This allows bare identifier references to be replaced programmatically via a macro. ‘syntax-rules’ provides some syntax to effect this transformation more easily. -- Syntax: identifier-syntax exp Returns a macro transformer that will replace occurrences of the macro with EXP. For example, if you are importing external code written in terms of ‘fx+’, the fixnum addition operator, but Guile doesn't have ‘fx+’, you may use the following to replace ‘fx+’ with ‘+’: (define-syntax fx+ (identifier-syntax +)) There is also special support for recognizing identifiers on the left-hand side of a ‘set!’ expression, as in the following: (define-syntax foo foo-transformer) (set! foo VAL) ;; expands via (foo-transformer #'(set! foo VAL)) ;; if foo-transformer is a "variable transformer" As the example notes, the transformer procedure must be explicitly marked as being a "variable transformer", as most macros aren't written to discriminate on the form in the operator position. -- Scheme Procedure: make-variable-transformer transformer Mark the TRANSFORMER procedure as being a "variable transformer". In practice this means that, when bound to a syntactic keyword, it may detect references to that keyword on the left-hand-side of a ‘set!’. (define bar 10) (define-syntax bar-alias (make-variable-transformer (lambda (x) (syntax-case x (set!) ((set! var val) #'(set! bar val)) ((var arg ...) #'(bar arg ...)) (var (identifier? #'var) #'bar))))) bar-alias ⇒ 10 (set! bar-alias 20) bar ⇒ 20 (set! bar 30) bar-alias ⇒ 30 There is an extension to identifier-syntax which allows it to handle the ‘set!’ case as well: -- Syntax: identifier-syntax (var exp1) ((set! var val) exp2) Create a variable transformer. The first clause is used for references to the variable in operator or operand position, and the second for appearances of the variable on the left-hand-side of an assignment. For example, the previous ‘bar-alias’ example could be expressed more succinctly like this: (define-syntax bar-alias (identifier-syntax (var bar) ((set! var val) (set! bar val)))) As before, the templates in ‘identifier-syntax’ forms do not need wrapping in ‘#'’ syntax forms. 6.8.7 Syntax Parameters ----------------------- Syntax parameters(1) are a mechanism for rebinding a macro definition within the dynamic extent of a macro expansion. This provides a convenient solution to one of the most common types of unhygienic macro: those that introduce a unhygienic binding each time the macro is used. Examples include a ‘lambda’ form with a ‘return’ keyword, or class macros that introduce a special ‘self’ binding. With syntax parameters, instead of introducing the binding unhygienically each time, we instead create one binding for the keyword, which we can then adjust later when we want the keyword to have a different meaning. As no new bindings are introduced, hygiene is preserved. This is similar to the dynamic binding mechanisms we have at run-time (*note parameters: SRFI-39.), except that the dynamic binding only occurs during macro expansion. The code after macro expansion remains lexically scoped. -- Syntax: define-syntax-parameter keyword transformer Binds KEYWORD to the value obtained by evaluating TRANSFORMER. The TRANSFORMER provides the default expansion for the syntax parameter, and in the absence of ‘syntax-parameterize’, is functionally equivalent to ‘define-syntax’. Usually, you will just want to have the TRANSFORMER throw a syntax error indicating that the KEYWORD is supposed to be used in conjunction with another macro, for example: (define-syntax-parameter return (lambda (stx) (syntax-violation 'return "return used outside of a lambda^" stx))) -- Syntax: syntax-parameterize ((keyword transformer) ...) exp ... Adjusts KEYWORD ... to use the values obtained by evaluating their TRANSFORMER ..., in the expansion of the EXP ... forms. Each KEYWORD must be bound to a syntax-parameter. ‘syntax-parameterize’ differs from ‘let-syntax’, in that the binding is not shadowed, but adjusted, and so uses of the keyword in the expansion of EXP ... use the new transformers. This is somewhat similar to how ‘parameterize’ adjusts the values of regular parameters, rather than creating new bindings. (define-syntax lambda^ (syntax-rules () [(lambda^ argument-list body body* ...) (lambda argument-list (call-with-current-continuation (lambda (escape) ;; In the body we adjust the 'return' keyword so that calls ;; to 'return' are replaced with calls to the escape ;; continuation. (syntax-parameterize ([return (syntax-rules () [(return vals (... ...)) (escape vals (... ...))])]) body body* ...))))])) ;; Now we can write functions that return early. Here, 'product' will ;; return immediately if it sees any 0 element. (define product (lambda^ (list) (fold (lambda (n o) (if (zero? n) (return 0) (* n o))) 1 list))) ---------- Footnotes ---------- (1) Described in the paper ‘Keeping it Clean with Syntax Parameters’ by Barzilay, Culpepper and Flatt. 6.8.8 Eval-when --------------- As ‘syntax-case’ macros have the whole power of Scheme available to them, they present a problem regarding time: when a macro runs, what parts of the program are available for the macro to use? The default answer to this question is that when you import a module (via ‘define-module’ or ‘use-modules’), that module will be loaded up at expansion-time, as well as at run-time. Additionally, top-level syntactic definitions within one compilation unit made by ‘define-syntax’ are also evaluated at expansion time, in the order that they appear in the compilation unit (file). But if a syntactic definition needs to call out to a normal procedure at expansion-time, it might well need special declarations to indicate that the procedure should be made available at expansion-time. For example, the following code tries to embed a compilation timestamp in the compiled bytecode using a macro that expands to the date as a string literal. It will work at a REPL, but not in a file, as it cannot be byte-compiled: (use-modules (srfi srfi-19)) (define start-date (date->string (current-date))) (define-syntax *compilation-date* (lambda (syntax) start-date)) (display *compilation-date*) (newline) It works at a REPL because the expressions are evaluated one-by-one, in order, but if placed in a file, the expressions are expanded one-by-one, but not evaluated until the compiled file is loaded. The fix is to use ‘eval-when’. (use-modules (srfi srfi-19)) (eval-when (expand load eval) (define start-date (date->string (current-date)))) (define-syntax *compilation-date* (lambda (syntax) start-date)) (display *compilation-date*) (newline) -- Syntax: eval-when conditions exp... Evaluate EXP... under the given CONDITIONS. Valid conditions include: ‘expand’ Evaluate during macro expansion, whether compiling or not. ‘load’ Evaluate during the evaluation phase of compiled code, e.g. when loading a compiled module or running compiled code at the REPL. ‘eval’ Evaluate during the evaluation phase of non-compiled code. ‘compile’ Evaluate during macro expansion, but only when compiling. In other words, when using the primitive evaluator, ‘eval-when’ expressions with ‘expand’ are run during macro expansion, and those with ‘eval’ are run during the evaluation phase. When using the compiler, ‘eval-when’ expressions with either ‘expand’ or ‘compile’ are run during macro expansion, and those with ‘load’ are run during the evaluation phase. When in doubt, use the three conditions ‘(expand load eval)’, as in the example above. Other uses of ‘eval-when’ may void your warranty or poison your cat. 6.8.9 Macro Expansion --------------------- Usually, macros are expanded on behalf of the user as needed. Macro expansion is an integral part of ‘eval’ and ‘compile’. Users can also expand macros at the REPL prompt via the ‘expand’ REPL command; *Note Compile Commands::. Macros can also be expanded programmatically, via ‘macroexpand’, but the details get a bit hairy for two reasons. The first complication is that the result of macro-expansion isn't Scheme: it's Tree-IL, Guile's high-level intermediate language. *Note Tree-IL::. As "hygienic macros" can produce identifiers that are distinct but have the same name, the output format needs to be able to represent distinctions between variable identities and names. Again, *Note Tree-IL::, for all the details. The easiest thing is to just run ‘tree-il->scheme’ on the result of macro-expansion: (macroexpand '(+ 1 2)) ⇒ # (use-modules (language tree-il)) (tree-il->scheme (macroexpand '(+ 1 2))) ⇒ (+ 1 2) The second complication involves ‘eval-when’. As an example, what would it mean to macro-expand the definition of a macro? (macroexpand '(define-syntax qux (identifier-syntax 'bar))) ⇒ ? The answer is that it depends who is macro-expanding, and why. Do you define the macro in the current environment? Residualize a macro definition? Both? Neither? The default is to expand in "eval" mode, which means an ‘eval-when’ clauses will only proceed when ‘eval’ (or ‘expand’) is in its condition set. Top-level macros will be ‘eval’'d in the top-level environment. In this way ‘(macroexpand FOO)’ is equivalent to ‘(macroexpand FOO 'e '(eval))’. The second argument is the mode (‘'e’ for "eval") and the third is the eval-syntax-expanders-when parameter (only ‘eval’ in this default setting). But if you are compiling the macro definition, probably you want to reify the macro definition itself. In that case you pass ‘'c’ as the second argument to ‘macroexpand’. But probably you want the macro definition to be present at compile time as well, so you pass ‘'(compile load eval)’ as the ESEW parameter. In fact ‘(compile FOO #:to 'tree-il)’ is entirely equivalent to ‘(macroexpand FOO 'c '(compile load eval))’; *Note The Scheme Compiler::. It's a terrible interface; we know. The macroexpander is somewhat tricky regarding modes, so unless you are building a macro-expanding tool, we suggest to avoid invoking it directly. 6.8.10 Hygiene and the Top-Level -------------------------------- Consider the following macro. (define-syntax-rule (defconst name val) (begin (define t val) (define-syntax-rule (name) t))) If we use it to make a couple of bindings: (defconst foo 42) (defconst bar 37) The expansion would look something like this: (begin (define t 42) (define-syntax-rule (foo) t)) (begin (define t 37) (define-syntax-rule (bar) t)) As the two ‘t’ bindings were introduced by the macro, they should be introduced hygienically - and indeed they are, inside a lexical contour (a ‘let’ or some other lexical scope). The ‘t’ reference in ‘foo’ is distinct to the reference in ‘bar’. At the top-level things are more complicated. Before Guile 2.2, a use of ‘defconst’ at the top-level would not introduce a fresh binding for ‘t’. This was consistent with a weaselly interpretation of the Scheme standard, in which all possible bindings may be assumed to exist, at the top-level, and in which we merely take advantage of toplevel ‘define’ of an existing binding being equivalent to ‘set!’. But it's not a good reason. The solution is to create fresh names for all bindings introduced by macros - not just bindings in lexical contours, but also bindings introduced at the top-level. However, the obvious strategy of just giving random names to introduced toplevel identifiers poses a problem for separate compilation. Consider without loss of generality a ‘defconst’ of ‘foo’ in module ‘a’ that introduces the fresh top-level name ‘t-1’. If we then compile a module ‘b’ that uses ‘foo’, there is now a reference to ‘t-1’ in module ‘b’. If module ‘a’ is then expanded again, for whatever reason, for example in a simple recompilation, the introduced ‘t’ gets a fresh name; say, ‘t-2’. Now module ‘b’ has broken because module ‘a’ no longer has a binding for ‘t-1’. If introduced top-level identifiers "escape" a module, in whatever way, they then form part of the binary interface (ABI) of a module. It is unacceptable from an engineering point of view to allow the ABI to change randomly. (It also poses practical problems in meeting the recompilation conditions of the Lesser GPL license, for such modules.) For this reason many people prefer to never use identifier-introducing macros at the top-level, instead making those macros receive the names for their introduced identifiers as part of their arguments, or to construct them programmatically and use ‘datum->syntax’. But this approach requires omniscience as to the implementation of all macros one might use, and also limits the expressive power of Scheme macros. There is no perfect solution to this issue. Guile does a terrible thing here. When it goes to introduce a top-level identifier, Guile gives the identifier a pseudo-fresh name: a name that depends on the hash of the source expression in which the name occurs. The result in this case is that the introduced definitions expand as: (begin (define t-1dc5e42de7c1050c 42) (define-syntax-rule (foo) t-1dc5e42de7c1050c)) (begin (define t-10cb8ce9fdddd6e9 37) (define-syntax-rule (bar) t-10cb8ce9fdddd6e9)) However, note that as the hash depends solely on the expression introducing the definition, we also have: (defconst baz 42) ⇒ (begin (define t-1dc5e42de7c1050c 42) (define-syntax-rule (baz) t-1dc5e42de7c1050c)) Note that the introduced binding has the same name! This is because the source expression, ‘(define t 42)’, was the same. Probably you will never see an error in this area, but it is important to understand the components of the interface of a module, and that interface may include macro-introduced identifiers. 6.8.11 Internal Macros ---------------------- -- Scheme Procedure: make-syntax-transformer name type binding Construct a syntax transformer object. This is part of Guile's low-level support for syntax-case. -- Scheme Procedure: macro? obj -- C Function: scm_macro_p (obj) Return ‘#t’ if OBJ is a syntax transformer, or ‘#f’ otherwise. Note that it's a bit difficult to actually get a macro as a first-class object; simply naming it (like ‘case’) will produce a syntax error. But it is possible to get these objects using ‘module-ref’: (macro? (module-ref (current-module) 'case)) ⇒ #t -- Scheme Procedure: macro-type m -- C Function: scm_macro_type (m) Return the TYPE that was given when M was constructed, via ‘make-syntax-transformer’. -- Scheme Procedure: macro-name m -- C Function: scm_macro_name (m) Return the name of the macro M. -- Scheme Procedure: macro-binding m -- C Function: scm_macro_binding (m) Return the binding of the macro M. -- Scheme Procedure: macro-transformer m -- C Function: scm_macro_transformer (m) Return the transformer of the macro M. This will return a procedure, for which one may ask the docstring. That's the whole reason this section is documented. Actually a part of the result of ‘macro-binding’. 6.9 General Utility Functions ============================= This chapter contains information about procedures which are not cleanly tied to a specific data type. Because of their wide range of applications, they are collected in a “utility” chapter. 6.9.1 Equality -------------- There are three kinds of core equality predicates in Scheme, described below. The same kinds of comparisons arise in other functions, like ‘memq’ and friends (*note List Searching::). For all three tests, objects of different types are never equal. So for instance a list and a vector are not ‘equal?’, even if their contents are the same. Exact and inexact numbers are considered different types too, and are hence not equal even if their values are the same. ‘eq?’ tests just for the same object (essentially a pointer comparison). This is fast, and can be used when searching for a particular object, or when working with symbols or keywords (which are always unique objects). ‘eqv?’ extends ‘eq?’ to look at the value of numbers and characters. It can for instance be used somewhat like ‘=’ (*note Comparison::) but without an error if one operand isn't a number. ‘equal?’ goes further, it looks (recursively) into the contents of lists, vectors, etc. This is good for instance on lists that have been read or calculated in various places and are the same, just not made up of the same pairs. Such lists look the same (when printed), and ‘equal?’ will consider them the same. -- Scheme Procedure: eq? ... -- C Function: scm_eq_p (x, y) The Scheme procedure returns ‘#t’ if all of its arguments are the same object, except for numbers and characters. The C function does the same but takes exactly two arguments. For example, (define x (vector 1 2 3)) (define y (vector 1 2 3)) (eq? x x) ⇒ #t (eq? x y) ⇒ #f Numbers and characters are not equal to any other object, but the problem is they're not necessarily ‘eq?’ to themselves either. This is even so when the number comes directly from a variable, (let ((n (+ 2 3))) (eq? n n)) ⇒ *unspecified* Generally ‘eqv?’ below should be used when comparing numbers or characters. ‘=’ (*note Comparison::) or ‘char=?’ (*note Characters::) can be used too. It's worth noting that end-of-list ‘()’, ‘#t’, ‘#f’, a symbol of a given name, and a keyword of a given name, are unique objects. There's just one of each, so for instance no matter how ‘()’ arises in a program, it's the same object and can be compared with ‘eq?’, (define x (cdr '(123))) (define y (cdr '(456))) (eq? x y) ⇒ #t (define x (string->symbol "foo")) (eq? x 'foo) ⇒ #t -- C Function: int scm_is_eq (SCM x, SCM y) Return ‘1’ when X and Y are equal in the sense of ‘eq?’, otherwise return ‘0’. The ‘==’ operator should not be used on ‘SCM’ values, an ‘SCM’ is a C type which cannot necessarily be compared using ‘==’ (*note The SCM Type::). -- Scheme Procedure: eqv? ... -- C Function: scm_eqv_p (x, y) The Scheme procedure returns ‘#t’ if all of its arguments are the same object, or for characters and numbers the same value. The C function is similar but takes exactly two arguments. On objects except characters and numbers, ‘eqv?’ is the same as ‘eq?’ above. ‘(eqv? x y)’ is true if X and Y are the same object. If X and Y are numbers or characters, ‘eqv?’ compares their type and value. An exact number is not ‘eqv?’ to an inexact number (even if their value is the same). (eqv? 3 (+ 1 2)) ⇒ #t (eqv? 1 1.0) ⇒ #f -- Scheme Procedure: equal? ... -- C Function: scm_equal_p (x, y) The Scheme procedure returns ‘#t’ if all of its arguments are the same type, and their contents or value are equal. The C function is similar, but takes exactly two arguments. For a pair, string, vector, array or structure, ‘equal?’ compares the contents, and does so using the same ‘equal?’ recursively, so a deep structure can be traversed. (equal? (list 1 2 3) (list 1 2 3)) ⇒ #t (equal? (list 1 2 3) (vector 1 2 3)) ⇒ #f For other objects, ‘equal?’ compares as per ‘eqv?’ above, which means characters and numbers are compared by type and value (and like ‘eqv?’, exact and inexact numbers are not ‘equal?’, even if their value is the same). (equal? 3 (+ 1 2)) ⇒ #t (equal? 1 1.0) ⇒ #f Hash tables are currently only compared as per ‘eq?’, so two different tables are not ‘equal?’, even if their contents are the same. ‘equal?’ does not support circular data structures, it may go into an infinite loop if asked to compare two circular lists or similar. GOOPS object types (*note GOOPS::), including foreign object types (*note Defining New Foreign Object Types::), can have an ‘equal?’ implementation specialized on two values of the same type. If ‘equal?’ is called on two GOOPS objects of the same type, ‘equal?’ will dispatch out to a generic function. This lets an application traverse the contents or control what is considered ‘equal?’ for two objects of such a type. If there's no such handler, the default is to just compare as per ‘eq?’. 6.9.2 Object Properties ----------------------- It's often useful to associate a piece of additional information with a Scheme object even though that object does not have a dedicated slot available in which the additional information could be stored. Object properties allow you to do just that. Guile's representation of an object property is a procedure-with-setter (*note Procedures with Setters::) that can be used with the generalized form of ‘set!’ to set and retrieve that property for any Scheme object. So, setting a property looks like this: (set! (my-property obj1) value-for-obj1) (set! (my-property obj2) value-for-obj2) And retrieving values of the same property looks like this: (my-property obj1) ⇒ value-for-obj1 (my-property obj2) ⇒ value-for-obj2 To create an object property in the first place, use the ‘make-object-property’ procedure: (define my-property (make-object-property)) -- Scheme Procedure: make-object-property Create and return an object property. An object property is a procedure-with-setter that can be called in two ways. ‘(set! (PROPERTY OBJ) VAL)’ sets OBJ's PROPERTY to VAL. ‘(PROPERTY OBJ)’ returns the current setting of OBJ's PROPERTY. A single object property created by ‘make-object-property’ can associate distinct property values with all Scheme values that are distinguishable by ‘eq?’ (ruling out numeric values). Internally, object properties are implemented using a weak key hash table. This means that, as long as a Scheme value with property values is protected from garbage collection, its property values are also protected. When the Scheme value is collected, its entry in the property table is removed and so the (ex-) property values are no longer protected by the table. Guile also implements a more traditional Lispy interface to properties, in which each object has an list of key-value pairs associated with it. Properties in that list are keyed by symbols. This is a legacy interface; you should use weak hash tables or object properties instead. -- Scheme Procedure: object-properties obj -- C Function: scm_object_properties (obj) Return OBJ's property list. -- Scheme Procedure: set-object-properties! obj alist -- C Function: scm_set_object_properties_x (obj, alist) Set OBJ's property list to ALIST. -- Scheme Procedure: object-property obj key -- C Function: scm_object_property (obj, key) Return the property of OBJ with name KEY. -- Scheme Procedure: set-object-property! obj key value -- C Function: scm_set_object_property_x (obj, key, value) In OBJ's property list, set the property named KEY to VALUE. 6.9.3 Sorting ------------- Sorting is very important in computer programs. Therefore, Guile comes with several sorting procedures built-in. As always, procedures with names ending in ‘!’ are side-effecting, that means that they may modify their parameters in order to produce their results. The first group of procedures can be used to merge two lists (which must be already sorted on their own) and produce sorted lists containing all elements of the input lists. -- Scheme Procedure: merge alist blist less -- C Function: scm_merge (alist, blist, less) Merge two already sorted lists into one. Given two lists ALIST and BLIST, such that ‘(sorted? alist less?)’ and ‘(sorted? blist less?)’, return a new list in which the elements of ALIST and BLIST have been stably interleaved so that ‘(sorted? (merge alist blist less?) less?)’. Note: this does _not_ accept vectors. -- Scheme Procedure: merge! alist blist less -- C Function: scm_merge_x (alist, blist, less) Takes two lists ALIST and BLIST such that ‘(sorted? alist less?)’ and ‘(sorted? blist less?)’ and returns a new list in which the elements of ALIST and BLIST have been stably interleaved so that ‘(sorted? (merge alist blist less?) less?)’. This is the destructive variant of ‘merge’ Note: this does _not_ accept vectors. The following procedures can operate on sequences which are either vectors or list. According to the given arguments, they return sorted vectors or lists, respectively. The first of the following procedures determines whether a sequence is already sorted, the other sort a given sequence. The variants with names starting with ‘stable-’ are special in that they maintain a special property of the input sequences: If two or more elements are the same according to the comparison predicate, they are left in the same order as they appeared in the input. -- Scheme Procedure: sorted? items less -- C Function: scm_sorted_p (items, less) Return ‘#t’ if ITEMS is a list or vector such that, for each element X and the next element Y of ITEMS, ‘(LESS Y X)’ returns ‘#f’. Otherwise return ‘#f’. -- Scheme Procedure: sort items less -- C Function: scm_sort (items, less) Sort the sequence ITEMS, which may be a list or a vector. LESS is used for comparing the sequence elements. This is not a stable sort. -- Scheme Procedure: sort! items less -- C Function: scm_sort_x (items, less) Sort the sequence ITEMS, which may be a list or a vector. LESS is used for comparing the sequence elements. The sorting is destructive, that means that the input sequence is modified to produce the sorted result. This is not a stable sort. -- Scheme Procedure: stable-sort items less -- C Function: scm_stable_sort (items, less) Sort the sequence ITEMS, which may be a list or a vector. LESS is used for comparing the sequence elements. This is a stable sort. -- Scheme Procedure: stable-sort! items less -- C Function: scm_stable_sort_x (items, less) Sort the sequence ITEMS, which may be a list or a vector. LESS is used for comparing the sequence elements. The sorting is destructive, that means that the input sequence is modified to produce the sorted result. This is a stable sort. The procedures in the last group only accept lists or vectors as input, as their names indicate. -- Scheme Procedure: sort-list items less -- C Function: scm_sort_list (items, less) Sort the list ITEMS, using LESS for comparing the list elements. This is a stable sort. -- Scheme Procedure: sort-list! items less -- C Function: scm_sort_list_x (items, less) Sort the list ITEMS, using LESS for comparing the list elements. The sorting is destructive, that means that the input list is modified to produce the sorted result. This is a stable sort. -- Scheme Procedure: restricted-vector-sort! vec less startpos endpos -- C Function: scm_restricted_vector_sort_x (vec, less, startpos, endpos) Sort the vector VEC, using LESS for comparing the vector elements. STARTPOS (inclusively) and ENDPOS (exclusively) delimit the range of the vector which gets sorted. The return value is not specified. 6.9.4 Copying Deep Structures ----------------------------- The procedures for copying lists (*note Lists::) only produce a flat copy of the input list, and currently Guile does not even contain procedures for copying vectors. The ‘(ice-9 copy-tree)’ module contains a ‘copy-tree’ function that can be used for this purpose, as it does not only copy the spine of a list, but also copies any pairs in the cars of the input lists. (use-modules (ice-9 copy-tree)) -- Scheme Procedure: copy-tree obj -- C Function: scm_copy_tree (obj) Recursively copy the data tree that is bound to OBJ, and return the new data structure. ‘copy-tree’ recurses down the contents of both pairs and vectors (since both cons cells and vector cells may point to arbitrary objects), and stops recursing when it hits any other object. 6.9.5 General String Conversion ------------------------------- When debugging Scheme programs, but also for providing a human-friendly interface, a procedure for converting any Scheme object into string format is very useful. Conversion from/to strings can of course be done with specialized procedures when the data type of the object to convert is known, but with this procedure, it is often more comfortable. ‘object->string’ converts an object by using a print procedure for writing to a string port, and then returning the resulting string. Converting an object back from the string is only possible if the object type has a read syntax and the read syntax is preserved by the printing procedure. -- Scheme Procedure: object->string obj [printer] -- C Function: scm_object_to_string (obj, printer) Return a Scheme string obtained by printing OBJ. Printing function can be specified by the optional second argument PRINTER (default: ‘write’). 6.9.6 Hooks ----------- A hook is a list of procedures to be called at well defined points in time. Typically, an application provides a hook H and promises its users that it will call all of the procedures in H at a defined point in the application's processing. By adding its own procedure to H, an application user can tap into or even influence the progress of the application. Guile itself provides several such hooks for debugging and customization purposes: these are listed in a subsection below. When an application first creates a hook, it needs to know how many arguments will be passed to the hook's procedures when the hook is run. The chosen number of arguments (which may be none) is declared when the hook is created, and all the procedures that are added to that hook must be capable of accepting that number of arguments. A hook is created using ‘make-hook’. A procedure can be added to or removed from a hook using ‘add-hook!’ or ‘remove-hook!’, and all of a hook's procedures can be removed together using ‘reset-hook!’. When an application wants to run a hook, it does so using ‘run-hook’. 6.9.6.1 Hook Usage by Example ............................. Hook usage is shown by some examples in this section. First, we will define a hook of arity 2 -- that is, the procedures stored in the hook will have to accept two arguments. (define hook (make-hook 2)) hook ⇒ # Now we are ready to add some procedures to the newly created hook with ‘add-hook!’. In the following example, two procedures are added, which print different messages and do different things with their arguments. (add-hook! hook (lambda (x y) (display "Foo: ") (display (+ x y)) (newline))) (add-hook! hook (lambda (x y) (display "Bar: ") (display (* x y)) (newline))) Once the procedures have been added, we can invoke the hook using ‘run-hook’. (run-hook hook 3 4) ⊣ Bar: 12 ⊣ Foo: 7 Note that the procedures are called in the reverse of the order with which they were added. This is because the default behavior of ‘add-hook!’ is to add its procedure to the _front_ of the hook's procedure list. You can force ‘add-hook!’ to add its procedure to the _end_ of the list instead by providing a third ‘#t’ argument on the second call to ‘add-hook!’. (add-hook! hook (lambda (x y) (display "Foo: ") (display (+ x y)) (newline))) (add-hook! hook (lambda (x y) (display "Bar: ") (display (* x y)) (newline)) #t) ; <- Change here! (run-hook hook 3 4) ⊣ Foo: 7 ⊣ Bar: 12 6.9.6.2 Hook Reference ...................... When you create a hook with ‘make-hook’, you must specify the arity of the procedures which can be added to the hook. If the arity is not given explicitly as an argument to ‘make-hook’, it defaults to zero. All procedures of a given hook must have the same arity, and when the procedures are invoked using ‘run-hook’, the number of arguments passed must match the arity specified at hook creation time. The order in which procedures are added to a hook matters. If the third parameter to ‘add-hook!’ is omitted or is equal to ‘#f’, the procedure is added in front of the procedures which might already be on that hook, otherwise the procedure is added at the end. The procedures are always called from the front to the end of the list when they are invoked via ‘run-hook’. The ordering of the list of procedures returned by ‘hook->list’ matches the order in which those procedures would be called if the hook was run using ‘run-hook’. Note that the C functions in the following entries are for handling “Scheme-level” hooks in C. There are also “C-level” hooks which have their own interface (*note C Hooks::). -- Scheme Procedure: make-hook [n_args] -- C Function: scm_make_hook (n_args) Create a hook for storing procedure of arity N_ARGS. N_ARGS defaults to zero. The returned value is a hook object to be used with the other hook procedures. -- Scheme Procedure: hook? x -- C Function: scm_hook_p (x) Return ‘#t’ if X is a hook, ‘#f’ otherwise. -- Scheme Procedure: hook-empty? hook -- C Function: scm_hook_empty_p (hook) Return ‘#t’ if HOOK is an empty hook, ‘#f’ otherwise. -- Scheme Procedure: add-hook! hook proc [append_p] -- C Function: scm_add_hook_x (hook, proc, append_p) Add the procedure PROC to the hook HOOK. The procedure is added to the end if APPEND_P is true, otherwise it is added to the front. The return value of this procedure is not specified. -- Scheme Procedure: remove-hook! hook proc -- C Function: scm_remove_hook_x (hook, proc) Remove the procedure PROC from the hook HOOK. The return value of this procedure is not specified. -- Scheme Procedure: reset-hook! hook -- C Function: scm_reset_hook_x (hook) Remove all procedures from the hook HOOK. The return value of this procedure is not specified. -- Scheme Procedure: hook->list hook -- C Function: scm_hook_to_list (hook) Convert the procedure list of HOOK to a list. -- Scheme Procedure: run-hook hook arg ... -- C Function: scm_run_hook (hook, args) Apply all procedures from the hook HOOK to the arguments ARG .... The order of the procedure application is first to last. The return value of this procedure is not specified. If, in C code, you are certain that you have a hook object and well formed argument list for that hook, you can also use ‘scm_c_run_hook’, which is identical to ‘scm_run_hook’ but does no type checking. -- C Function: void scm_c_run_hook (SCM hook, SCM args) The same as ‘scm_run_hook’ but without any type checking to confirm that HOOK is actually a hook object and that ARGS is a well-formed list matching the arity of the hook. For C code, ‘SCM_HOOKP’ is a faster alternative to ‘scm_hook_p’: -- C Macro: int SCM_HOOKP (x) Return 1 if X is a Scheme-level hook, 0 otherwise. 6.9.6.3 Hooks For C Code. ......................... The hooks already described are intended to be populated by Scheme-level procedures. In addition to this, the Guile library provides an independent set of interfaces for the creation and manipulation of hooks that are designed to be populated by functions implemented in C. The original motivation here was to provide a kind of hook that could safely be invoked at various points during garbage collection. Scheme-level hooks are unsuitable for this purpose as running them could itself require memory allocation, which would then invoke garbage collection recursively ... However, it is also the case that these hooks are easier to work with than the Scheme-level ones if you only want to register C functions with them. So if that is mainly what your code needs to do, you may prefer to use this interface. To create a C hook, you should allocate storage for a structure of type ‘scm_t_c_hook’ and then initialize it using ‘scm_c_hook_init’. -- C Type: scm_t_c_hook Data type for a C hook. The internals of this type should be treated as opaque. -- C Enum: scm_t_c_hook_type Enumeration of possible hook types, which are: ‘SCM_C_HOOK_NORMAL’ Type of hook for which all the registered functions will always be called. ‘SCM_C_HOOK_OR’ Type of hook for which the sequence of registered functions will be called only until one of them returns C true (a non-NULL pointer). ‘SCM_C_HOOK_AND’ Type of hook for which the sequence of registered functions will be called only until one of them returns C false (a NULL pointer). -- C Function: void scm_c_hook_init (scm_t_c_hook *hook, void *hook_data, scm_t_c_hook_type type) Initialize the C hook at memory pointed to by HOOK. TYPE should be one of the values of the ‘scm_t_c_hook_type’ enumeration, and controls how the hook functions will be called. HOOK_DATA is a closure parameter that will be passed to all registered hook functions when they are called. To add or remove a C function from a C hook, use ‘scm_c_hook_add’ or ‘scm_c_hook_remove’. A hook function must expect three ‘void *’ parameters which are, respectively: HOOK_DATA The hook closure data that was specified at the time the hook was initialized by ‘scm_c_hook_init’. FUNC_DATA The function closure data that was specified at the time that that function was registered with the hook by ‘scm_c_hook_add’. DATA The call closure data specified by the ‘scm_c_hook_run’ call that runs the hook. -- C Type: scm_t_c_hook_function Function type for a C hook function: takes three ‘void *’ parameters and returns a ‘void *’ result. -- C Function: void scm_c_hook_add (scm_t_c_hook *hook, scm_t_c_hook_function func, void *func_data, int appendp) Add function FUNC, with function closure data FUNC_DATA, to the C hook HOOK. The new function is appended to the hook's list of functions if APPENDP is non-zero, otherwise prepended. -- C Function: void scm_c_hook_remove (scm_t_c_hook *hook, scm_t_c_hook_function func, void *func_data) Remove function FUNC, with function closure data FUNC_DATA, from the C hook HOOK. ‘scm_c_hook_remove’ checks both FUNC and FUNC_DATA so as to allow for the same FUNC being registered multiple times with different closure data. Finally, to invoke a C hook, call the ‘scm_c_hook_run’ function specifying the hook and the call closure data for this run: -- C Function: void * scm_c_hook_run (scm_t_c_hook *hook, void *data) Run the C hook HOOK will call closure data DATA. Subject to the variations for hook types ‘SCM_C_HOOK_OR’ and ‘SCM_C_HOOK_AND’, ‘scm_c_hook_run’ calls HOOK's registered functions in turn, passing them the hook's closure data, each function's closure data, and the call closure data. ‘scm_c_hook_run’'s return value is the return value of the last function to be called. 6.9.6.4 Hooks for Garbage Collection .................................... Whenever Guile performs a garbage collection, it calls the following hooks in the order shown. -- C Hook: scm_before_gc_c_hook C hook called at the very start of a garbage collection, after setting ‘scm_gc_running_p’ to 1, but before entering the GC critical section. If garbage collection is blocked because ‘scm_block_gc’ is non-zero, GC exits early soon after calling this hook, and no further hooks will be called. -- C Hook: scm_before_mark_c_hook C hook called before beginning the mark phase of garbage collection, after the GC thread has entered a critical section. -- C Hook: scm_before_sweep_c_hook C hook called before beginning the sweep phase of garbage collection. This is the same as at the end of the mark phase, since nothing else happens between marking and sweeping. -- C Hook: scm_after_sweep_c_hook C hook called after the end of the sweep phase of garbage collection, but while the GC thread is still inside its critical section. -- C Hook: scm_after_gc_c_hook C hook called at the very end of a garbage collection, after the GC thread has left its critical section. -- Scheme Hook: after-gc-hook Scheme hook with arity 0. This hook is run asynchronously (*note Asyncs::) soon after the GC has completed and any other events that were deferred during garbage collection have been processed. (Also accessible from C with the name ‘scm_after_gc_hook’.) All the C hooks listed here have type ‘SCM_C_HOOK_NORMAL’, are initialized with hook closure data NULL, are invoked by ‘scm_c_hook_run’ with call closure data NULL. The Scheme hook ‘after-gc-hook’ is particularly useful in conjunction with guardians (*note Guardians::). Typically, if you are using a guardian, you want to call the guardian after garbage collection to see if any of the objects added to the guardian have been collected. By adding a thunk that performs this call to ‘after-gc-hook’, you can ensure that your guardian is tested after every garbage collection cycle. 6.9.6.5 Hooks into the Guile REPL ................................. 6.10 Definitions and Variable Bindings ====================================== Scheme supports the definition of variables in different contexts. Variables can be defined at the top level, so that they are visible in the entire program, and variables can be defined locally to procedures and expressions. This is important for modularity and data abstraction. 6.10.1 Top Level Variable Definitions ------------------------------------- At the top level of a program (i.e., not nested within any other expression), a definition of the form (define a VALUE) defines a variable called ‘a’ and sets it to the value VALUE. If the variable already exists in the current module, because it has already been created by a previous ‘define’ expression with the same name, its value is simply changed to the new VALUE. In this case, then, the above form is completely equivalent to (set! a VALUE) This equivalence means that ‘define’ can be used interchangeably with ‘set!’ to change the value of variables at the top level of the REPL or a Scheme source file. It is useful during interactive development when reloading a Scheme file that you have modified, because it allows the ‘define’ expressions in that file to work as expected both the first time that the file is loaded and on subsequent occasions. Note, though, that ‘define’ and ‘set!’ are not always equivalent. For example, a ‘set!’ is not allowed if the named variable does not already exist, and the two expressions can behave differently in the case where there are imported variables visible from another module. -- Scheme Syntax: define name value Create a top level variable named NAME with value VALUE. If the named variable already exists, just change its value. The return value of a ‘define’ expression is unspecified. The C API equivalents of ‘define’ are ‘scm_define’ and ‘scm_c_define’, which differ from each other in whether the variable name is specified as a ‘SCM’ symbol or as a null-terminated C string. -- C Function: scm_define (sym, value) -- C Function: scm_c_define (const char *name, value) C equivalents of ‘define’, with variable name specified either by SYM, a symbol, or by NAME, a null-terminated C string. Both variants return the new or preexisting variable object. ‘define’ (when it occurs at top level), ‘scm_define’ and ‘scm_c_define’ all create or set the value of a variable in the top level environment of the current module. If there was not already a variable with the specified name belonging to the current module, but a similarly named variable from another module was visible through having been imported, the newly created variable in the current module will shadow the imported variable, such that the imported variable is no longer visible. Attention: Scheme definitions inside local binding constructs (*note Local Bindings::) act differently (*note Internal Definitions::). Many people end up in a development style of adding and changing definitions at runtime, building out their program without restarting it. (You can do this using ‘reload-module’, the ‘reload’ REPL command, the ‘load’ procedure, or even just pasting code into a REPL.) If you are one of these people, you will find that sometimes there are some variables that you _don't_ want to redefine all the time. For these, use ‘define-once’. -- Scheme Syntax: define-once name value Create a top level variable named NAME with value VALUE, but only if NAME is not already bound in the current module. Old Lispers probably know ‘define-once’ under its Lisp name, ‘defvar’. 6.10.2 Local Variable Bindings ------------------------------ As opposed to definitions at the top level, which creates bindings that are visible to all code in a module, it is also possible to define variables which are only visible in a well-defined part of the program. Normally, this part of a program will be a procedure or a subexpression of a procedure. With the constructs for local binding (‘let’, ‘let*’, ‘letrec’, and ‘letrec*’), the Scheme language has a block structure like most other programming languages since the days of ALGOL 60. Readers familiar to languages like C or Java should already be used to this concept, but the family of ‘let’ expressions has a few properties which are well worth knowing. The most basic local binding construct is ‘let’. -- syntax: let bindings body BINDINGS has the form ((VARIABLE1 INIT1) ...) that is zero or more two-element lists of a variable and an arbitrary expression each. All VARIABLE names must be distinct. BODY is a sequence of expressions and definitions, ending in an expression. A ‘let’ expression is evaluated as follows. • All INIT expressions are evaluated. • New storage is allocated for the VARIABLES. • The values of the INIT expressions are stored into the variables. • The expressions and definitions in BODY are evaluated in order (*note Internal Definitions::), and the values of the last expression are returned as the result of the ‘let’ expression. The INIT expressions are not allowed to refer to any of the VARIABLES. The other binding constructs are variations on the same theme: making new values, binding them to variables, and executing a body in that new, extended lexical context. -- syntax: let* bindings body Similar to ‘let’, but the variable bindings are performed sequentially, that means that all INIT expression are allowed to use the variables defined on their left in the binding list. A ‘let*’ expression can always be expressed with nested ‘let’ expressions. (let* ((a 1) (b a)) b) ≡ (let ((a 1)) (let ((b a)) b)) -- syntax: letrec bindings body Similar to ‘let’, but it is possible to refer to the VARIABLE from lambda expression created in any of the INITS. That is, procedures created in the INIT expression can recursively refer to the defined variables. (letrec ((even? (lambda (n) (if (zero? n) #t (odd? (- n 1))))) (odd? (lambda (n) (if (zero? n) #f (even? (- n 1)))))) (even? 88)) ⇒ #t Note that while the INIT expressions may refer to the new variables, they may not access their values. For example, making the ‘even?’ function above creates a closure (*note About Closure::) referencing the ‘odd?’ variable. But ‘odd?’ can't be called until after execution has entered the body. -- syntax: letrec* bindings body Similar to ‘letrec’, except the INIT expressions are bound to their variables in order. ‘letrec*’ thus relaxes the letrec restriction, in that later INIT expressions may refer to the values of previously bound variables. (letrec ((a 42) (b (+ a 10))) ;; Illegal access (* a b)) ;; The behavior of the expression above is unspecified (letrec* ((a 42) (b (+ a 10))) (* a b)) ⇒ 2184 There is also an alternative form of the ‘let’ form, which is used for expressing iteration. Because of the use as a looping construct, this form (the “named let”) is documented in the section about iteration (*note Iteration: while do.) 6.10.3 Internal definitions --------------------------- A ‘define’ form which appears inside the body of a ‘lambda’, ‘let’, ‘let*’, ‘letrec’, ‘letrec*’ or equivalent expression is called an “internal definition”. An internal definition differs from a top level definition (*note Top Level::), because the definition is only visible inside the complete body of the enclosing form. Let us examine the following example. (let ((frumble "froz")) (define banana (lambda () (apple 'peach))) (define apple (lambda (x) x)) (banana)) ⇒ peach Here the enclosing form is a ‘let’, so the ‘define’s in the ‘let’-body are internal definitions. Because the scope of the internal definitions is the *complete* body of the ‘let’-expression, the ‘lambda’-expression which gets bound to the variable ‘banana’ may refer to the variable ‘apple’, even though its definition appears lexically _after_ the definition of ‘banana’. This is because a sequence of internal definition acts as if it were a ‘letrec*’ expression. (let () (define a 1) (define b 2) (+ a b)) is equivalent to (let () (letrec* ((a 1) (b 2)) (+ a b))) Internal definitions may be mixed with non-definition expressions. If an expression precedes a definition, it is treated as if it were a definition of an unreferenced variable. So this: (let () (define a 1) (foo) (define b 2) (+ a b)) is equivalent to (let () (letrec* ((a 1) (_ (begin (foo) #f)) (b 2)) (+ a b))) Another noteworthy difference to top level definitions is that within one group of internal definitions all variable names must be distinct. Whereas on the top level a second define for a given variable acts like a ‘set!’, for internal definitions, duplicate bound identifiers signals an error. As a historical note, it used to be that internal bindings were expanded in terms of ‘letrec’, not ‘letrec*’. This was the situation for the R5RS report and before. However with the R6RS, it was recognized that sequential definition was a more intuitive expansion, as in the following case: (let () (define a 1) (define b (+ a a)) (+ a b)) Guile decided to follow the R6RS in this regard, and now expands internal definitions using ‘letrec*’. Relatedly, it used to be that internal definitions had to precede all expressions in the body; this restriction was relaxed in Guile 3.0. 6.10.4 Querying variable bindings --------------------------------- Guile provides a procedure for checking whether a symbol is bound in the top level environment. -- Scheme Procedure: defined? sym [module] -- C Function: scm_defined_p (sym, module) Return ‘#t’ if SYM is defined in the module MODULE or the current module when MODULE is not specified; otherwise return ‘#f’. 6.10.5 Binding multiple return values ------------------------------------- -- Syntax: define-values formals expression The EXPRESSION is evaluated, and the FORMALS are bound to the return values in the same way that the formals in a ‘lambda’ expression are matched to the arguments in a procedure call. (define-values (q r) (floor/ 10 3)) (list q r) ⇒ (3 1) (define-values (x . y) (values 1 2 3)) x ⇒ 1 y ⇒ (2 3) (define-values x (values 1 2 3)) x ⇒ (1 2 3) 6.11 Controlling the Flow of Program Execution ============================================== See *note Control Flow:: for a discussion of how the more general control flow of Scheme affects C code. 6.11.1 Sequencing and Splicing ------------------------------ As an expression, the ‘begin’ syntax is used to evaluate a sequence of sub-expressions in order. Consider the conditional expression below: (if (> x 0) (begin (display "greater") (newline))) If the test is true, we want to display "greater" to the current output port, then display a newline. We use ‘begin’ to form a compound expression out of this sequence of sub-expressions. -- syntax: begin expr ... The expression(s) are evaluated in left-to-right order and the values of the last expression are returned as the result of the ‘begin’-expression. This expression type is used when the expressions before the last one are evaluated for their side effects. The ‘begin’ syntax has another role in definition context (*note Internal Definitions::). A ‘begin’ form in a definition context “splices” its subforms into its place. For example, consider the following procedure: (define (make-seal) (define-sealant seal open) (values seal open)) Let us assume the existence of a ‘define-sealant’ macro that expands out to some definitions wrapped in a ‘begin’, like so: (define (make-seal) (begin (define seal-tag (list 'seal)) (define (seal x) (cons seal-tag x)) (define (sealed? x) (and (pair? x) (eq? (car x) seal-tag))) (define (open x) (if (sealed? x) (cdr x) (error "Expected a sealed value:" x)))) (values seal open)) Here, because the ‘begin’ is in definition context, its subforms are “spliced” into the place of the ‘begin’. This allows the definitions created by the macro to be visible to the following expression, the ‘values’ form. It is a fine point, but splicing and sequencing are different. It can make sense to splice zero forms, because it can make sense to have zero internal definitions before the expressions in a procedure or lexical binding form. However it does not make sense to have a sequence of zero expressions, because in that case it would not be clear what the value of the sequence would be, because in a sequence of zero expressions, there can be no last value. Sequencing zero expressions is an error. It would be more elegant in some ways to eliminate splicing from the Scheme language, and without macros (*note Macros::), that would be a good idea. But it is useful to be able to write macros that expand out to multiple definitions, as in ‘define-sealant’ above, so Scheme abuses the ‘begin’ form for these two tasks. 6.11.2 Simple Conditional Evaluation ------------------------------------ Guile provides three syntactic constructs for conditional evaluation. ‘if’ is the normal if-then-else expression (with an optional else branch), ‘cond’ is a conditional expression with multiple branches, and ‘case’ branches if an expression has one of a set of constant values. -- syntax: if test consequent [alternate] All arguments may be arbitrary expressions. First, TEST is evaluated. If it returns a true value, the expression CONSEQUENT is evaluated and ALTERNATE is ignored. If TEST evaluates to ‘#f’, ALTERNATE is evaluated instead. The values of the evaluated branch (CONSEQUENT or ALTERNATE) are returned as the values of the ‘if’ expression. When ALTERNATE is omitted and the TEST evaluates to ‘#f’, the value of the expression is not specified. When you go to write an ‘if’ without an alternate (a “one-armed ‘if’”), part of what you are expressing is that you don't care about the return value (or values) of the expression. As such, you are more interested in the _effect_ of evaluating the consequent expression. (By convention, we use the word “statement” to refer to an expression that is evaluated for effect, not for value). In such a case, it is considered more clear to express these intentions with the special forms ‘when’ and ‘unless’. As an added bonus, these forms take a _body_ like in a ‘let’ expression, which can contain internal definitions and multiple statements to evaluate (*note Local Bindings::). -- Scheme Syntax: when test body -- Scheme Syntax: unless test body The actual definitions of these forms may be their most clear documentation: (define-syntax-rule (when test stmt stmt* ...) (if test (let () stmt stmt* ...))) (define-syntax-rule (unless test stmt stmt* ...) (if (not test) (let () stmt stmt* ...))) That is to say, ‘when’ evaluates its consequent statements in order if TEST is true. ‘unless’ is the opposite: it evaluates the statements if TEST is false. -- syntax: cond clause1 clause2 ... Each ‘cond’-clause must look like this: (TEST BODY) where TEST is an arbitrary expression, or like this (TEST => EXPRESSION) where EXPRESSION must evaluate to a procedure. The TESTs of the clauses are evaluated in order and as soon as one of them evaluates to a true value, the corresponding BODY is evaluated to produce the result of the ‘cond’-expression. For the ‘=>’ clause type, EXPRESSION is evaluated and the resulting procedure is applied to the value of TEST. The result of this procedure application is then the result of the ‘cond’-expression. One additional ‘cond’-clause is available as an extension to standard Scheme: (TEST GUARD => EXPRESSION) where GUARD and EXPRESSION must evaluate to procedures. For this clause type, TEST may return multiple values, and ‘cond’ ignores its boolean state; instead, ‘cond’ evaluates GUARD and applies the resulting procedure to the value(s) of TEST, as if GUARD were the CONSUMER argument of ‘call-with-values’. If the result of that procedure call is a true value, it evaluates EXPRESSION and applies the resulting procedure to the value(s) of TEST, in the same manner as the GUARD was called. The TEST of the last CLAUSE may be the symbol ‘else’. Then, if none of the preceding TESTs is true, the BODY following the ‘else’ is evaluated to produce the result of the ‘cond’-expression. -- syntax: case key clause1 clause2 ... KEY may be any expression, and the CLAUSEs must have the form ((DATUM1 ...) BODY) or ((DATUM1 ...) => EXPRESSION) and the last CLAUSE may have the form (else BODY) or (else => EXPRESSION) All DATUMs must be distinct. First, KEY is evaluated. The result of this evaluation is compared against all DATUM values using ‘eqv?’. When this comparison succeeds, the BODY following the DATUM is evaluated to produce the result of the ‘case’ expression. If the KEY matches no DATUM and there is an ‘else’-clause, the BODY following the ‘else’ is evaluated to produce the result of the ‘case’ expression. If there is no such clause, the result of the expression is unspecified. For the ‘=>’ clause types, EXPRESSION is evaluated and the resulting procedure is applied to the value of KEY. The result of this procedure application is then the result of the ‘case’-expression. 6.11.3 Conditional Evaluation of a Sequence of Expressions ---------------------------------------------------------- ‘and’ and ‘or’ evaluate all their arguments in order, similar to ‘begin’, but evaluation stops as soon as one of the expressions evaluates to false or true, respectively. -- syntax: and expr ... Evaluate the EXPRs from left to right and stop evaluation as soon as one expression evaluates to ‘#f’; the remaining expressions are not evaluated. The value of the last evaluated expression is returned. If no expression evaluates to ‘#f’, the value of the last expression is returned. If used without expressions, ‘#t’ is returned. -- syntax: or expr ... Evaluate the EXPRs from left to right and stop evaluation as soon as one expression evaluates to a true value (that is, a value different from ‘#f’); the remaining expressions are not evaluated. The value of the last evaluated expression is returned. If all expressions evaluate to ‘#f’, ‘#f’ is returned. If used without expressions, ‘#f’ is returned. 6.11.4 Iteration mechanisms --------------------------- Scheme has only few iteration mechanisms, mainly because iteration in Scheme programs is normally expressed using recursion. Nevertheless, R5RS defines a construct for programming loops, calling ‘do’. In addition, Guile has an explicit looping syntax called ‘while’. -- syntax: do ((variable init [step]) ...) (test expr ...) body ... Bind VARIABLEs and evaluate BODY until TEST is true. The return value is the last EXPR after TEST, if given. A simple example will illustrate the basic form, (do ((i 1 (1+ i))) ((> i 4)) (display i)) ⊣ 1234 Or with two variables and a final return value, (do ((i 1 (1+ i)) (p 3 (* 3 p))) ((> i 4) p) (format #t "3**~s is ~s\n" i p)) ⊣ 3**1 is 3 3**2 is 9 3**3 is 27 3**4 is 81 ⇒ 243 The VARIABLE bindings are established like a ‘let’, in that the expressions are all evaluated and then all bindings made. When iterating, the optional STEP expressions are evaluated with the previous bindings in scope, then new bindings all made. The TEST expression is a termination condition. Looping stops when the TEST is true. It's evaluated before running the BODY each time, so if it's true the first time then BODY is not run at all. The optional EXPRs after the TEST are evaluated at the end of looping, with the final VARIABLE bindings available. The last EXPR gives the return value, or if there are no EXPRs the return value is unspecified. Each iteration establishes bindings to fresh locations for the VARIABLEs, like a new ‘let’ for each iteration. This is done for VARIABLEs without STEP expressions too. The following illustrates this, showing how a new ‘i’ is captured by the ‘lambda’ in each iteration (*note The Concept of Closure: About Closure.). (define lst '()) (do ((i 1 (1+ i))) ((> i 4)) (set! lst (cons (lambda () i) lst))) (map (lambda (proc) (proc)) lst) ⇒ (4 3 2 1) -- syntax: while cond body ... Run a loop executing the BODY forms while COND is true. COND is tested at the start of each iteration, so if it's ‘#f’ the first time then BODY is not executed at all. Within ‘while’, two extra bindings are provided, they can be used from both COND and BODY. -- Scheme Procedure: break break-arg ... Break out of the ‘while’ form. -- Scheme Procedure: continue Abandon the current iteration, go back to the start and test COND again, etc. If the loop terminates normally, by the COND evaluating to ‘#f’, then the ‘while’ expression as a whole evaluates to ‘#f’. If it terminates by a call to ‘break’ with some number of arguments, those arguments are returned from the ‘while’ expression, as multiple values. Otherwise if it terminates by a call to ‘break’ with no arguments, then return value is ‘#t’. (while #f (error "not reached")) ⇒ #f (while #t (break)) ⇒ #t (while #t (break 1 2 3)) ⇒ 1 2 3 Each ‘while’ form gets its own ‘break’ and ‘continue’ procedures, operating on that ‘while’. This means when loops are nested the outer ‘break’ can be used to escape all the way out. For example, (while (test1) (let ((outer-break break)) (while (test2) (if (something) (outer-break #f)) ...))) Note that each ‘break’ and ‘continue’ procedure can only be used within the dynamic extent of its ‘while’. Outside the ‘while’ their behavior is unspecified. Another very common way of expressing iteration in Scheme programs is the use of the so-called “named let”. Named let is a variant of ‘let’ which creates a procedure and calls it in one step. Because of the newly created procedure, named let is more powerful than ‘do’-it can be used for iteration, but also for arbitrary recursion. -- syntax: let variable bindings body For the definition of BINDINGS see the documentation about ‘let’ (*note Local Bindings::). Named ‘let’ works as follows: • A new procedure which accepts as many arguments as are in BINDINGS is created and bound locally (using ‘let’) to VARIABLE. The new procedure's formal argument names are the name of the VARIABLES. • The BODY expressions are inserted into the newly created procedure. • The procedure is called with the INIT expressions as the formal arguments. The next example implements a loop which iterates (by recursion) 1000 times. (let lp ((x 1000)) (if (positive? x) (lp (- x 1)) x)) ⇒ 0 6.11.5 Prompts -------------- Prompts are control-flow barriers between different parts of a program. In the same way that a user sees a shell prompt (e.g., the Bash prompt) as a barrier between the operating system and her programs, Scheme prompts allow the Scheme programmer to treat parts of programs as if they were running in different operating systems. We use this roundabout explanation because, unless you're a functional programming junkie, you probably haven't heard the term, "delimited, composable continuation". That's OK; it's a relatively recent topic, but a very useful one to know about. 6.11.5.1 Prompt Primitives .......................... Guile's primitive delimited control operators are ‘call-with-prompt’ and ‘abort-to-prompt’. -- Scheme Procedure: call-with-prompt tag thunk handler Set up a prompt, and call THUNK within that prompt. During the dynamic extent of the call to THUNK, a prompt named TAG will be present in the dynamic context, such that if a user calls ‘abort-to-prompt’ (see below) with that tag, control rewinds back to the prompt, and the HANDLER is run. HANDLER must be a procedure. The first argument to HANDLER will be the state of the computation begun when THUNK was called, and ending with the call to ‘abort-to-prompt’. The remaining arguments to HANDLER are those passed to ‘abort-to-prompt’. -- Scheme Procedure: make-prompt-tag [stem] Make a new prompt tag. A prompt tag is simply a unique object. Currently, a prompt tag is a fresh pair. This may change in some future Guile version. -- Scheme Procedure: default-prompt-tag Return the default prompt tag. Having a distinguished default prompt tag allows some useful prompt and abort idioms, discussed in the next section. Note that ‘default-prompt-tag’ is actually a parameter, and so may be dynamically rebound using ‘parameterize’. *Note Parameters::. -- Scheme Procedure: abort-to-prompt tag val1 val2 ... Unwind the dynamic and control context to the nearest prompt named TAG, also passing the given values. C programmers may recognize ‘call-with-prompt’ and ‘abort-to-prompt’ as a fancy kind of ‘setjmp’ and ‘longjmp’, respectively. Prompts are indeed quite useful as non-local escape mechanisms. Guile's ‘with-exception-handler’ and ‘raise-exception’ are implemented in terms of prompts. Prompts are more convenient than ‘longjmp’, in that one has the opportunity to pass multiple values to the jump target. Also unlike ‘longjmp’, the prompt handler is given the full state of the process that was aborted, as the first argument to the prompt's handler. That state is the “continuation” of the computation wrapped by the prompt. It is a “delimited continuation”, because it is not the whole continuation of the program; rather, just the computation initiated by the call to ‘call-with-prompt’. The continuation is a procedure, and may be reinstated simply by invoking it, with any number of values. Here's where things get interesting, and complicated as well. Besides being described as delimited, continuations reified by prompts are also “composable”, because invoking a prompt-saved continuation composes that continuation with the current one. Imagine you have saved a continuation via call-with-prompt: (define cont (call-with-prompt ;; tag 'foo ;; thunk (lambda () (+ 34 (abort-to-prompt 'foo))) ;; handler (lambda (k) k))) The resulting continuation is the addition of 34. It's as if you had written: (define cont (lambda (x) (+ 34 x))) So, if we call ‘cont’ with one numeric value, we get that number, incremented by 34: (cont 8) ⇒ 42 (* 2 (cont 8)) ⇒ 84 The last example illustrates what we mean when we say, "composes with the current continuation". We mean that there is a current continuation - some remaining things to compute, like ‘(lambda (x) (* x 2))’ - and that calling the saved continuation doesn't wipe out the current continuation, it composes the saved continuation with the current one. We're belaboring the point here because traditional Scheme continuations, as discussed in the next section, aren't composable, and are actually less expressive than continuations captured by prompts. But there's a place for them both. Before moving on, we should mention that if the handler of a prompt is a ‘lambda’ expression, and the first argument isn't referenced, an abort to that prompt will not cause a continuation to be reified. This can be an important efficiency consideration to keep in mind. One example where this optimization matters is “escape continuations”. Escape continuations are delimited continuations whose only use is to make a non-local exit--i.e., to escape from the current continuation. A common use of escape continuations is when handling an exception (*note Exceptions::). The constructs below are syntactic sugar atop prompts to simplify the use of escape continuations. -- Scheme Procedure: call-with-escape-continuation proc -- Scheme Procedure: call/ec proc Call PROC with an escape continuation. In the example below, the RETURN continuation is used to escape the continuation of the call to ‘fold’. (use-modules (ice-9 control) (srfi srfi-1)) (define (prefix x lst) ;; Return all the elements before the first occurrence ;; of X in LST. (call/ec (lambda (return) (fold (lambda (element prefix) (if (equal? element x) (return (reverse prefix)) ; escape `fold' (cons element prefix))) '() lst)))) (prefix 'a '(0 1 2 a 3 4 5)) ⇒ (0 1 2) -- Scheme Syntax: let-escape-continuation k body ... -- Scheme Syntax: let/ec k body ... Bind K within BODY to an escape continuation. This is equivalent to ‘(call/ec (lambda (K) BODY ...))’. Additionally there is another helper primitive exported by ‘(ice-9 control)’, so load up that module for ‘suspendable-continuation?’: (use-modules (ice-9 control)) -- Scheme Procedure: suspendable-continuation? tag Return ‘#t’ if a call to ‘abort-to-prompt’ with the prompt tag TAG would produce a delimited continuation that could be resumed later. Almost all continuations have this property. The exception is where some code between the ‘call-with-prompt’ and the ‘abort-to-prompt’ recursed through C for some reason, the ‘abort-to-prompt’ will succeed but any attempt to resume the continuation (by calling it) would fail. This is because composing a saved continuation with the current continuation involves relocating the stack frames that were saved from the old stack onto a (possibly) new position on the new stack, and Guile can only do this for stack frames that it created for Scheme code, not stack frames created by the C compiler. It's a bit gnarly but if you stick with Scheme, you won't have any problem. If no prompt is found with the given tag, this procedure just returns ‘#f’. 6.11.5.2 Shift, Reset, and All That ................................... There is a whole zoo of delimited control operators, and as it does not seem to be a bounded set, Guile implements support for them in a separate module: (use-modules (ice-9 control)) Firstly, we have a helpful abbreviation for the ‘call-with-prompt’ operator. -- Scheme Syntax: % expr -- Scheme Syntax: % expr handler -- Scheme Syntax: % tag expr handler Evaluate EXPR in a prompt, optionally specifying a tag and a handler. If no tag is given, the default prompt tag is used. If no handler is given, a default handler is installed. The default handler accepts a procedure of one argument, which will be called on the captured continuation, within a prompt. Sometimes it's easier just to show code, as in this case: (define (default-prompt-handler k proc) (% (default-prompt-tag) (proc k) default-prompt-handler)) The ‘%’ symbol is chosen because it looks like a prompt. Likewise there is an abbreviation for ‘abort-to-prompt’, which assumes the default prompt tag: -- Scheme Procedure: abort val1 val2 ... Abort to the default prompt tag, passing VAL1 VAL2 ... to the handler. As mentioned before, ‘(ice-9 control)’ also provides other delimited control operators. This section is a bit technical, and first-time users of delimited continuations should probably come back to it after some practice with ‘%’. Still here? So, when one implements a delimited control operator like ‘call-with-prompt’, one needs to make two decisions. Firstly, does the handler run within or outside the prompt? Having the handler run within the prompt allows an abort inside the handler to return to the same prompt handler, which is often useful. However it prevents tail calls from the handler, so it is less general. Similarly, does invoking a captured continuation reinstate a prompt? Again we have the tradeoff of convenience versus proper tail calls. These decisions are captured in the Felleisen “F” operator. If neither the continuations nor the handlers implicitly add a prompt, the operator is known as “-F-”. This is the case for Guile's ‘call-with-prompt’ and ‘abort-to-prompt’. If both continuation and handler implicitly add prompts, then the operator is “+F+”. ‘shift’ and ‘reset’ are such operators. -- Scheme Syntax: reset body1 body2 ... Establish a prompt, and evaluate BODY1 BODY2 ... within that prompt. The prompt handler is designed to work with ‘shift’, described below. -- Scheme Syntax: shift cont body1 body2 ... Abort to the nearest ‘reset’, and evaluate BODY1 BODY2 ... in a context in which the captured continuation is bound to CONT. As mentioned above, taken together, the BODY1 BODY2 ... expressions and the invocations of CONT implicitly establish a prompt. Interested readers are invited to explore Oleg Kiselyov's wonderful web site at , for more information on these operators. 6.11.6 Continuations -------------------- A "continuation" is the code that will execute when a given function or expression returns. For example, consider (define (foo) (display "hello\n") (display (bar)) (newline) (exit)) The continuation from the call to ‘bar’ comprises a ‘display’ of the value returned, a ‘newline’ and an ‘exit’. This can be expressed as a function of one argument. (lambda (r) (display r) (newline) (exit)) In Scheme, continuations are represented as special procedures just like this. The special property is that when a continuation is called it abandons the current program location and jumps directly to that represented by the continuation. A continuation is like a dynamic label, capturing at run-time a point in program execution, including all the nested calls that have lead to it (or rather the code that will execute when those calls return). Continuations are created with the following functions. -- Scheme Procedure: call-with-current-continuation proc -- Scheme Procedure: call/cc proc Capture the current continuation and call ‘(PROC CONT)’ with it. The return value is the value returned by PROC, or when ‘(CONT VALUE)’ is later invoked, the return is the VALUE passed. Normally CONT should be called with one argument, but when the location resumed is expecting multiple values (*note Multiple Values::) then they should be passed as multiple arguments, for instance ‘(CONT X Y Z)’. CONT may only be used from the same side of a continuation barrier as it was created (*note Continuation Barriers::), and in a multi-threaded program only from the thread in which it was created. The call to PROC is not part of the continuation captured, it runs only when the continuation is created. Often a program will want to store CONT somewhere for later use; this can be done in PROC. The ‘call’ in the name ‘call-with-current-continuation’ refers to the way a call to PROC gives the newly created continuation. It's not related to the way a call is used later to invoke that continuation. ‘call/cc’ is an alias for ‘call-with-current-continuation’. This is in common use since the latter is rather long. Here is a simple example, (define kont #f) (format #t "the return is ~a\n" (call/cc (lambda (k) (set! kont k) 1))) ⇒ the return is 1 (kont 2) ⇒ the return is 2 ‘call/cc’ captures a continuation in which the value returned is going to be displayed by ‘format’. The ‘lambda’ stores this in ‘kont’ and gives an initial return ‘1’ which is displayed. The later invocation of ‘kont’ resumes the captured point, but this time returning ‘2’, which is displayed. When Guile is run interactively, a call to ‘format’ like this has an implicit return back to the read-eval-print loop. ‘call/cc’ captures that like any other return, which is why interactively ‘kont’ will come back to read more input. C programmers may note that ‘call/cc’ is like ‘setjmp’ in the way it records at runtime a point in program execution. A call to a continuation is like a ‘longjmp’ in that it abandons the present location and goes to the recorded one. Like ‘longjmp’, the value passed to the continuation is the value returned by ‘call/cc’ on resuming there. However ‘longjmp’ can only go up the program stack, but the continuation mechanism can go anywhere. When a continuation is invoked, ‘call/cc’ and subsequent code effectively "returns" a second time. It can be confusing to imagine a function returning more times than it was called. It may help instead to think of it being stealthily re-entered and then program flow going on as normal. ‘dynamic-wind’ (*note Dynamic Wind::) can be used to ensure setup and cleanup code is run when a program locus is resumed or abandoned through the continuation mechanism. Continuations are a powerful mechanism, and can be used to implement almost any sort of control structure, such as loops, coroutines, or exception handlers. However the implementation of continuations in Guile is not as efficient as one might hope, because Guile is designed to cooperate with programs written in other languages, such as C, which do not know about continuations. Basically continuations are captured by a block copy of the stack, and resumed by copying back. For this reason, continuations captured by ‘call/cc’ should be used only when there is no other simple way to achieve the desired result, or when the elegance of the continuation mechanism outweighs the need for performance. Escapes upwards from loops or nested functions are generally best handled with prompts (*note Prompts::). Coroutines can be efficiently implemented with cooperating threads (a thread holds a full program stack but doesn't copy it around the way continuations do). 6.11.7 Returning and Accepting Multiple Values ---------------------------------------------- Scheme allows a procedure to return more than one value to its caller. This is quite different to other languages which only allow single-value returns. Returning multiple values is different from returning a list (or pair or vector) of values to the caller, because conceptually not _one_ compound object is returned, but several distinct values. The primitive procedures for handling multiple values are ‘values’ and ‘call-with-values’. ‘values’ is used for returning multiple values from a procedure. This is done by placing a call to ‘values’ with zero or more arguments in tail position in a procedure body. ‘call-with-values’ combines a procedure returning multiple values with a procedure which accepts these values as parameters. -- Scheme Procedure: values arg ... -- C Function: scm_values (args) Delivers all of its arguments to its continuation. Except for continuations created by the ‘call-with-values’ procedure, all continuations take exactly one value. The effect of passing no value or more than one value to continuations that were not created by ‘call-with-values’ is unspecified. For ‘scm_values’, ARGS is a list of arguments and the return is a multiple-values object which the caller can return. In the current implementation that object shares structure with ARGS, so ARGS should not be modified subsequently. -- C Function: SCM scm_c_values (SCM *base, size_t n) ‘scm_c_values’ is an alternative to ‘scm_values’. It creates a new values object, and copies into it the N values starting from BASE. Currently this creates a list and passes it to ‘scm_values’, but we expect that in the future we will be able to use a more efficient representation. -- C Function: size_t scm_c_nvalues (SCM obj) If OBJ is a multiple-values object, returns the number of values it contains. Otherwise returns 1. -- C Function: SCM scm_c_value_ref (SCM obj, size_t idx) Returns the value at the position specified by IDX in OBJ. Note that OBJ will ordinarily be a multiple-values object, but it need not be. Any other object represents a single value (itself), and is handled appropriately. -- Scheme Procedure: call-with-values producer consumer Calls its PRODUCER argument with no values and a continuation that, when passed some values, calls the CONSUMER procedure with those values as arguments. The continuation for the call to CONSUMER is the continuation of the call to ‘call-with-values’. (call-with-values (lambda () (values 4 5)) (lambda (a b) b)) ⇒ 5 (call-with-values * -) ⇒ -1 In addition to the fundamental procedures described above, Guile has a module which exports a syntax called ‘receive’, which is much more convenient. This is in the ‘(ice-9 receive)’ and is the same as specified by SRFI-8 (*note SRFI-8::). (use-modules (ice-9 receive)) -- library syntax: receive formals expr body Evaluate the expression EXPR, and bind the result values (zero or more) to the formal arguments in FORMALS. FORMALS is a list of symbols, like the argument list in a ‘lambda’ (*note Lambda::). After binding the variables, the BODY is evaluated to produce the result of the ‘receive’ expression. For example getting results from ‘partition’ in SRFI-1 (*note SRFI-1::), (receive (odds evens) (partition odd? '(7 4 2 8 3)) (display odds) (display " and ") (display evens)) ⊣ (7 3) and (4 2 8) 6.11.8 Exceptions ----------------- What happens when things go wrong? Guile's exception facility exists to help answer this question, allowing programs to describe the problem and to handle the situation in a flexible way. When a program runs into a problem, such as division by zero, it will raise an exception. Sometimes exceptions get raised by Guile on a program's behalf. Sometimes a program will want to raise exceptions of its own. Raising an exception stops the current computation and instead invokes the current exception handler, passing it an exception object describing the unexpected situation. Usually an exception handler will unwind the computation back to some kind of safe point. For example, typical logic for a key press driven application might look something like this: main-loop: read the next key press and call dispatch-key dispatch-key: lookup the key in a keymap and call an appropriate procedure, say find-file find-file: interactively read the required file name, then call find-specified-file find-specified-file: check whether file exists; if not, raise an exception ... In this case, ‘main-loop’ can install an exception handler that would cause any exception raised inside ‘dispatch-key’ to print a warning and jump back to the main loop. The following subsections go into more detail about exception objects, raising exceptions, and handling exceptions. It also presents a historical interface that was used in Guile's first 25 years and which won't be going away any time soon. 6.11.8.1 Exception Objects .......................... When Guile encounters an exceptional situation, it raises an exception, where the exception is an object that describes the exceptional situation. Exception objects are structured data, built on the record facility (*note Records::). -- Exception Type: &exception The base exception type. All exception objects are composed of instances of subtypes of ‘&exception’. -- Scheme Procedure: exception-type? obj Return true if OBJ is an exception type. Exception types exist in a hierarchy. New exception types can be defined using ‘make-exception-type’. -- Scheme Procedure: make-exception-type id parent field-names Return a new exception type named ID, inheriting from PARENT, and with the fields whose names are listed in FIELD-NAMES. FIELD-NAMES must be a list of symbols and must not contain names already used by PARENT or one of its supertypes. Exception type objects are record type objects, and as such, one can use ‘record-constructor’ on an exception type to get its constructor. The constructor will take as many arguments as the exception has fields (including supertypes). *Note Records::. However, ‘record-predicate’ and ‘record-accessor’ aren't usually what you want to use as exception type predicates and field accessors. The reason is, instances of exception types can be composed into “compound exceptions”. Exception accessors should pick out the specific component of a compound exception, and then access the field on that specific component. -- Scheme Procedure: make-exception exceptions ... Return an exception object composed of EXCEPTIONS. -- Scheme Procedure: exception? obj Return true if OBJ is an exception object. -- Scheme Procedure: exception-predicate type Return a procedure that will return true if its argument is a simple exception that is an instance of TYPE, or a compound exception composed of such an instance. -- Scheme Procedure: exception-accessor rtd proc Return a procedure that will tail-call PROC on an instance of the exception type RTD, or on the component of a compound exception that is an instance of RTD. Compound exceptions are useful to separately express the different aspects of a situation. For example, compound exceptions allow a programmer to say that "this situation is a programming error, and also here's a useful message to show to the user, and here are some relevant objects that can give more information about the error". This error could be composed of instances of the ‘&programming-error’, ‘&message’, and ‘&irritants’ exception types. The subtyping relationship in exceptions is useful to let different-but-similar situations to be treated the same; for example there are many varieties of programming errors (for example, divide-by-zero or type mismatches), but perhaps there are common ways that the user would like to handle them all, and that common way might be different than how one might handle an error originating outside the program (for example, a file-not-found error). The standard exception hierarchy in Guile takes its cues from R6RS, though the names of some of the types are different. *Note rnrs exceptions::, for more details. To have access to Guile's exception type hierarchy, import the ‘(ice-9 exceptions)’ module: (use-modules (ice-9 exceptions)) The following diagram gives an overview of the standard exception type hierarchy. &exception |- &warning |- &message |- &irritants |- &origin \- &error |- &external-error \- &programming-error |- &assertion-failure |- &non-continuable |- &implementation-restriction |- &lexical |- &syntax \- &undefined-variable -- Exception Type: &warning An exception type denoting warnings. These are usually raised using ‘#:continuable? #t’; see the ‘raise-exception’ documentation for more. -- Scheme Procedure: make-warning -- Scheme Procedure: warning? obj Constructor and predicate for ‘&warning’ exception objects. -- Exception Type: &message message An exception type that provides a message to display to the user. Usually used as a component of a compound exception. -- Scheme Procedure: make-exception-with-message message -- Scheme Procedure: exception-with-message? obj -- Scheme Procedure: exception-message exn Constructor, predicate, and accessor for ‘&message’ exception objects. -- Exception Type: &irritants irritants An exception type that provides a list of objects that were unexpected in some way. Usually used as a component of a compound exception. -- Scheme Procedure: make-exception-with-irritants irritants -- Scheme Procedure: exception-with-irritants? obj -- Scheme Procedure: exception-irritants exn Constructor, predicate, and accessor for ‘&irritants’ exception objects. -- Exception Type: &origin origin An exception type that indicates the origin of an exception, typically expressed as a procedure name, as a symbol. Usually used as a component of a compound exception. -- Scheme Procedure: make-exception-with-origin origin -- Scheme Procedure: exception-with-origin? obj -- Scheme Procedure: exception-origin exn Constructor, predicate, and accessor for ‘&origin’ exception objects. -- Exception Type: &error An exception type denoting errors: situations that are not just exceptional, but wrong. -- Scheme Procedure: make-error -- Scheme Procedure: error? obj Constructor and predicate for ‘&error’ exception objects. -- Exception Type: &external-error An exception type denoting errors that proceed from the interaction of the program with the world, for example a "file not found" error. -- Scheme Procedure: make-external-error -- Scheme Procedure: external-error? obj Constructor and predicate for ‘&external-error’ exception objects. -- Exception Type: &programming-error An exception type denoting errors that proceed from inside a program: type mismatches and so on. -- Scheme Procedure: make-programming-error -- Scheme Procedure: programming-error? obj Constructor and predicate for ‘&programming-error’ exception objects. -- Exception Type: &non-continuable An exception type denoting errors that proceed from inside a program: type mismatches and so on. -- Scheme Procedure: make-non-continuable-error -- Scheme Procedure: non-continuable-error? obj Constructor and predicate for ‘&non-continuable’ exception objects. -- Exception Type: &lexical An exception type denoting lexical errors, for example unbalanced parentheses. -- Scheme Procedure: make-lexical-error -- Scheme Procedure: lexical-error? obj Constructor and predicate for ‘&lexical’ exception objects. -- Exception Type: &syntax form subform An exception type denoting syntax errors, for example a ‘cond’ expression with invalid syntax. The FORM field indicates the form containing the error, and SUBFORM indicates the unexpected subcomponent, or ‘#f’ if unavailable. -- Scheme Procedure: make-syntax-error form subform -- Scheme Procedure: syntax-error? obj -- Scheme Procedure: syntax-error-form exn -- Scheme Procedure: syntax-error-subform exn Constructor, predicate, and accessors for ‘&syntax’ exception objects. -- Exception Type: &undefined-variable An exception type denoting undefined variables. -- Scheme Procedure: make-undefine-variable-error -- Scheme Procedure: undefined-variable-error? obj Constructor and predicate for ‘&undefined-variable’ exception objects. Incidentally, the ‘(ice-9 exceptions)’ module also includes a ‘define-exception-type’ macro that can be used to conveniently add new exception types to the hierarchy. -- Syntax: define-exception-type name parent constructor predicate (field accessor) ... Define NAME to be a new exception type, inheriting from PARENT. Define CONSTRUCTOR and PREDICATE to be the exception constructor and predicate, respectively, and define an ACCESSOR for each FIELD. 6.11.8.2 Raising and Handling Exceptions ........................................ An exception object describes an exceptional situation. To bring that description to the attention of the user or to handle the situation programmatically, the first step is to “raise” the exception. -- Scheme Procedure: raise-exception obj [#:continuable?=#f] Raise an exception by invoking the current exception handler on OBJ. The handler is called with a continuation whose dynamic environment is that of the call to ‘raise’, except that the current exception handler is the one that was in place when the handler being called was installed. If CONTINUABLE? is true, the handler is invoked in tail position relative to the ‘raise-exception’ call. Otherwise if the handler returns, a non-continuable exception of type ‘&non-continuable’ is raised in the same dynamic environment as the handler. As the above description notes, Guile has a notion of a “current exception handler”. At the REPL, this exception handler may enter a recursive debugger; in a standalone program, it may simply print a representation of the error and exit. To establish an exception handler within the dynamic extent of a call, use ‘with-exception-handler’. -- Scheme Procedure: with-exception-handler handler thunk [#:unwind?=#f] [#:unwind-for-type=#t] Establish HANDLER, a procedure of one argument, as the current exception handler during the dynamic extent of invoking THUNK. If ‘raise-exception’ is called during the dynamic extent of invoking THUNK, HANDLER will be invoked on the argument of ‘raise-exception’. There are two kinds of exception handlers: unwinding and non-unwinding. By default, exception handlers are non-unwinding. Unless ‘with-exception-handler’ was invoked with ‘#:unwind? #t’, exception handlers are invoked within the continuation of the error, without unwinding the stack. The dynamic environment of the handler call will be that of the ‘raise-exception’ call, with the difference that the current exception handler will be "unwound" to the "outer" handler (the one that was in place when the corresponding ‘with-exception-handler’ was called). However, it's often the case that one would like to handle an exception by unwinding the computation to an earlier state and running the error handler there. After all, unless the ‘raise-exception’ call is continuable, the exception handler needs to abort the continuation. To support this use case, if ‘with-exception-handler’ was invoked with ‘#:unwind? #t’ is true, ‘raise-exception’ will first unwind the stack by invoking an “escape continuation” (*note ‘call/ec’: Prompt Primitives.), and then invoke the handler with the continuation of the ‘with-exception-handler’ call. Finally, one more wrinkle: for unwinding exception handlers, it can be useful to Guile if it can determine whether an exception handler would indeed handle a particular exception or not. This is especially the case for exceptions raised in resource-exhaustion scenarios like ‘stack-overflow’ or ‘out-of-memory’, where you want to immediately shrink resource use before recovering. *Note Stack Overflow::. For this purpose, the ‘#:unwind-for-type’ keyword argument allows users to specify the kind of exception handled by an exception handler; if ‘#t’, all exceptions will be handled; if an exception type object, only exceptions of that type will be handled; otherwise if a symbol, only that exceptions with the given ‘exception-kind’ will be handled. 6.11.8.3 Throw and Catch ........................ Guile only adopted ‘with-exception-handler’ and ‘raise-exception’ as its primary exception-handling facility in 2019. Before then, exception handling was fundamentally based on three other primitives with a somewhat more complex interface: ‘catch’, ‘with-throw-handler’, and ‘throw’. -- Scheme Procedure: catch key thunk handler [pre-unwind-handler] -- C Function: scm_catch_with_pre_unwind_handler (key, thunk, handler, pre_unwind_handler) -- C Function: scm_catch (key, thunk, handler) Establish an exception handler during the dynamic extent of the call to THUNK. KEY is either ‘#t’, indicating that all exceptions should be handled, or a symbol, restricting the exceptions handled to those having the KEY as their ‘exception-kind’. If THUNK executes normally, meaning without throwing any exceptions, the handler procedures are not called at all and the result of the ‘thunk’ call is the result of the ‘catch’. Otherwise if an exception is thrown that matches KEY, HANDLER is called with the continuation of the ‘catch’ call. Given the discussion from the previous section, it is most precise and concise to specify what ‘catch’ does by expressing it in terms of ‘with-exception-handler’. Calling ‘catch’ with the three arguments is the same as: (define (catch key thunk handler) (with-exception-handler (lambda (exn) (apply handler (exception-kind exn) (exception-args exn))) thunk #:unwind? #t #:unwind-for-type key)) By invoking ‘with-exception-handler’ with ‘#:unwind? #t’, ‘catch’ sets up an escape continuation that will be invoked in an exceptional situation before the handler is called. If ‘catch’ is called with four arguments, then the use of THUNK should be replaced with: (lambda () (with-throw-handler key thunk pre-unwind-handler)) As can be seen above, if a pre-unwind-handler is passed to ‘catch’, it's like calling ‘with-throw-handler’ inside the body thunk. ‘with-throw-handler’ is the second of the older primitives, and is used to be able to intercept an exception that is being thrown before the stack is unwound. This could be to clean up some related state, to print a backtrace, or to pass information about the exception to a debugger, for example. -- Scheme Procedure: with-throw-handler key thunk handler -- C Function: scm_with_throw_handler (key, thunk, handler) Add HANDLER to the dynamic context as a throw handler for key KEY, then invoke THUNK. It's not possible to exactly express ‘with-throw-handler’ in terms of ‘with-exception-handler’, but we can get close. (define (with-throw-handler key thunk handler) (with-exception-handler (lambda (exn) (when (or (eq? key #t) (eq? key (exception-kind exn))) (apply handler (exception-kind exn) (exception-args exn))) (raise-exception exn)) thunk)) As you can see, unlike in the case of ‘catch’, the handler for ‘with-throw-handler’ is invoked within the continuation of ‘raise-exception’, before unwinding the stack. If the throw handler returns normally, the exception will be re-raised, to be handled by the next exception handler. The special wrinkle of ‘with-throw-handler’ that can't be shown above is that if invoking the handler causes a ‘raise-exception’ instead of completing normally, the exception is thrown in the _original_ dynamic environment of the ‘raise-exception’. Any inner exception handler will get another shot at handling the exception. Here is an example to illustrate this behavior: (catch 'a (lambda () (with-throw-handler 'b (lambda () (catch 'a (lambda () (throw 'b)) inner-handler)) (lambda (key . args) (throw 'a)))) outer-handler) This code will call ‘inner-handler’ and then continue with the continuation of the inner ‘catch’. Finally, we get to ‘throw’, which is the older equivalent to ‘raise-exception’. -- Scheme Procedure: throw key arg ... -- C Function: scm_throw (key, args) Raise an exception with kind KEY and arguments ARGS. KEY is a symbol, denoting the "kind" of the exception. Again, we can specify what ‘throw’ does by expressing it in terms of ‘raise-exception’. (define (throw key . args) (raise-exception (make-exception-from-throw key args))) At this point, we should mention the primitive that manage the relationship between structured exception objects ‘throw’. -- Scheme Procedure: make-exception-from-throw key args Create an exception object for the given KEY and ARGS passed to ‘throw’. This may be a specific type of exception, for example ‘&programming-error’; Guile maintains a set of custom transformers for the various KEY values that have been used historically. -- Scheme Procedure: exception-kind exn If EXN is an exception created via ‘make-exception-from-throw’, return the corresponding KEY for the exception. Otherwise, unless EXN is an exception of a type with a known mapping to ‘throw’, return the symbol ‘%exception’. -- Scheme Procedure: exception-args exn If EXN is an exception created via ‘make-exception-from-throw’, return the corresponding ARGS for the exception. Otherwise, unless EXN is an exception of a type with a known mapping to ‘throw’, return ‘(list EXN)’. 6.11.8.4 Exceptions and C ......................... There are some specific versions of Guile's original ‘catch’ and ‘with-throw-handler’ exception-handling primitives that are still widely used in C code. -- C Function: SCM scm_c_catch (SCM tag, scm_t_catch_body body, void *body_data, scm_t_catch_handler handler, void *handler_data, scm_t_catch_handler pre_unwind_handler, void *pre_unwind_handler_data) -- C Function: SCM scm_internal_catch (SCM tag, scm_t_catch_body body, void *body_data, scm_t_catch_handler handler, void *handler_data) The above ‘scm_catch_with_pre_unwind_handler’ and ‘scm_catch’ take Scheme procedures as body and handler arguments. ‘scm_c_catch’ and ‘scm_internal_catch’ are equivalents taking C functions. BODY is called as ‘BODY (BODY_DATA)’ with a catch on exceptions of the given TAG type. If an exception is caught, PRE_UNWIND_HANDLER and HANDLER are called as ‘HANDLER (HANDLER_DATA, KEY, ARGS)’. KEY and ARGS are the ‘SCM’ key and argument list from the ‘throw’. BODY and HANDLER should have the following prototypes. ‘scm_t_catch_body’ and ‘scm_t_catch_handler’ are pointer typedefs for these. SCM body (void *data); SCM handler (void *data, SCM key, SCM args); The BODY_DATA and HANDLER_DATA parameters are passed to the respective calls so an application can communicate extra information to those functions. If the data consists of an ‘SCM’ object, care should be taken that it isn't garbage collected while still required. If the ‘SCM’ is a local C variable, one way to protect it is to pass a pointer to that variable as the data parameter, since the C compiler will then know the value must be held on the stack. Another way is to use ‘scm_remember_upto_here_1’ (*note Foreign Object Memory Management::). -- C Function: SCM scm_c_with_throw_handler (SCM tag, scm_t_catch_body body, void *body_data, scm_t_catch_handler handler, void *handler_data, int lazy_catch_p) The above ‘scm_with_throw_handler’ takes Scheme procedures as body (thunk) and handler arguments. ‘scm_c_with_throw_handler’ is an equivalent taking C functions. See ‘scm_c_catch’ (*note Exceptions and C::) for a description of the parameters, the behavior however of course follows ‘with-throw-handler’. 6.11.9 Procedures for Signaling Errors -------------------------------------- Guile provides a set of convenience procedures for signaling error conditions that are implemented on top of the exception primitives just described. -- Scheme Procedure: error msg arg ... Raise an error with key ‘misc-error’ and a message constructed by displaying MSG and writing ARG .... -- Scheme Procedure: scm-error key subr message args data -- C Function: scm_error_scm (key, subr, message, args, data) Raise an error with key KEY. SUBR can be a string naming the procedure associated with the error, or ‘#f’. MESSAGE is the error message string, possibly containing ‘~S’ and ‘~A’ escapes. When an error is reported, these are replaced by formatting the corresponding members of ARGS: ‘~A’ (was ‘%s’ in older versions of Guile) formats using ‘display’ and ‘~S’ (was ‘%S’) formats using ‘write’. DATA is a list or ‘#f’ depending on KEY: if KEY is ‘system-error’ then it should be a list containing the Unix ‘errno’ value; If KEY is ‘signal’ then it should be a list containing the Unix signal number; If KEY is ‘out-of-range’, ‘wrong-type-arg’, or ‘keyword-argument-error’, it is a list containing the bad value; otherwise it will usually be ‘#f’. -- Scheme Procedure: strerror err -- C Function: scm_strerror (err) Return the Unix error message corresponding to ERR, an integer ‘errno’ value. When ‘setlocale’ has been called (*note Locales::), the message is in the language and charset of ‘LC_MESSAGES’. (This is done by the C library.) -- syntax: false-if-exception expr Returns the result of evaluating its argument; however if an exception occurs then ‘#f’ is returned instead. 6.11.10 Dynamic Wind -------------------- For Scheme code, the fundamental procedure to react to non-local entry and exits of dynamic contexts is ‘dynamic-wind’. C code could use ‘scm_internal_dynamic_wind’, but since C does not allow the convenient construction of anonymous procedures that close over lexical variables, this will be, well, inconvenient. Therefore, Guile offers the functions ‘scm_dynwind_begin’ and ‘scm_dynwind_end’ to delimit a dynamic extent. Within this dynamic extent, which is called a “dynwind context”, you can perform various “dynwind actions” that control what happens when the dynwind context is entered or left. For example, you can register a cleanup routine with ‘scm_dynwind_unwind_handler’ that is executed when the context is left. There are several other more specialized dynwind actions as well, for example to temporarily block the execution of asyncs or to temporarily change the current output port. They are described elsewhere in this manual. Here is an example that shows how to prevent memory leaks. /* Suppose there is a function called FOO in some library that you would like to make available to Scheme code (or to C code that follows the Scheme conventions). FOO takes two C strings and returns a new string. When an error has occurred in FOO, it returns NULL. */ char *foo (char *s1, char *s2); /* SCM_FOO interfaces the C function FOO to the Scheme way of life. It takes care to free up all temporary strings in the case of non-local exits. */ SCM scm_foo (SCM s1, SCM s2) { char *c_s1, *c_s2, *c_res; scm_dynwind_begin (0); c_s1 = scm_to_locale_string (s1); /* Call 'free (c_s1)' when the dynwind context is left. */ scm_dynwind_unwind_handler (free, c_s1, SCM_F_WIND_EXPLICITLY); c_s2 = scm_to_locale_string (s2); /* Same as above, but more concisely. */ scm_dynwind_free (c_s2); c_res = foo (c_s1, c_s2); if (c_res == NULL) scm_report_out_of_memory (); scm_dynwind_end (); return scm_take_locale_string (res); } -- Scheme Procedure: dynamic-wind in_guard thunk out_guard -- C Function: scm_dynamic_wind (in_guard, thunk, out_guard) All three arguments must be 0-argument procedures. IN_GUARD is called, then THUNK, then OUT_GUARD. If, any time during the execution of THUNK, the dynamic extent of the ‘dynamic-wind’ expression is escaped non-locally, OUT_GUARD is called. If the dynamic extent of the dynamic-wind is re-entered, IN_GUARD is called. Thus IN_GUARD and OUT_GUARD may be called any number of times. (define x 'normal-binding) ⇒ x (define a-cont (call-with-current-continuation (lambda (escape) (let ((old-x x)) (dynamic-wind ;; in-guard: ;; (lambda () (set! x 'special-binding)) ;; thunk ;; (lambda () (display x) (newline) (call-with-current-continuation escape) (display x) (newline) x) ;; out-guard: ;; (lambda () (set! x old-x))))))) ;; Prints: special-binding ;; Evaluates to: ⇒ a-cont x ⇒ normal-binding (a-cont #f) ;; Prints: special-binding ;; Evaluates to: ⇒ a-cont ;; the value of the (define a-cont...) x ⇒ normal-binding a-cont ⇒ special-binding -- C Type: scm_t_dynwind_flags This is an enumeration of several flags that modify the behavior of ‘scm_dynwind_begin’. The flags are listed in the following table. ‘SCM_F_DYNWIND_REWINDABLE’ The dynamic context is “rewindable”. This means that it can be reentered non-locally (via the invocation of a continuation). The default is that a dynwind context can not be reentered non-locally. -- C Function: void scm_dynwind_begin (scm_t_dynwind_flags flags) The function ‘scm_dynwind_begin’ starts a new dynamic context and makes it the 'current' one. The FLAGS argument determines the default behavior of the context. Normally, use 0. This will result in a context that can not be reentered with a captured continuation. When you are prepared to handle reentries, include ‘SCM_F_DYNWIND_REWINDABLE’ in FLAGS. Being prepared for reentry means that the effects of unwind handlers can be undone on reentry. In the example above, we want to prevent a memory leak on non-local exit and thus register an unwind handler that frees the memory. But once the memory is freed, we can not get it back on reentry. Thus reentry can not be allowed. The consequence is that continuations become less useful when non-reentrant contexts are captured, but you don't need to worry about that too much. The context is ended either implicitly when a non-local exit happens, or explicitly with ‘scm_dynwind_end’. You must make sure that a dynwind context is indeed ended properly. If you fail to call ‘scm_dynwind_end’ for each ‘scm_dynwind_begin’, the behavior is undefined. -- C Function: void scm_dynwind_end () End the current dynamic context explicitly and make the previous one current. -- C Type: scm_t_wind_flags This is an enumeration of several flags that modify the behavior of ‘scm_dynwind_unwind_handler’ and ‘scm_dynwind_rewind_handler’. The flags are listed in the following table. ‘SCM_F_WIND_EXPLICITLY’ The registered action is also carried out when the dynwind context is entered or left locally. -- C Function: void scm_dynwind_unwind_handler (void (*func)(void *), void *data, scm_t_wind_flags flags) -- C Function: void scm_dynwind_unwind_handler_with_scm (void (*func)(SCM), SCM data, scm_t_wind_flags flags) Arranges for FUNC to be called with DATA as its arguments when the current context ends implicitly. If FLAGS contains ‘SCM_F_WIND_EXPLICITLY’, FUNC is also called when the context ends explicitly with ‘scm_dynwind_end’. The function ‘scm_dynwind_unwind_handler_with_scm’ takes care that DATA is protected from garbage collection. -- C Function: void scm_dynwind_rewind_handler (void (*func)(void *), void *data, scm_t_wind_flags flags) -- C Function: void scm_dynwind_rewind_handler_with_scm (void (*func)(SCM), SCM data, scm_t_wind_flags flags) Arrange for FUNC to be called with DATA as its argument when the current context is restarted by rewinding the stack. When FLAGS contains ‘SCM_F_WIND_EXPLICITLY’, FUNC is called immediately as well. The function ‘scm_dynwind_rewind_handler_with_scm’ takes care that DATA is protected from garbage collection. -- C Function: void scm_dynwind_free (void *mem) Arrange for MEM to be freed automatically whenever the current context is exited, whether normally or non-locally. ‘scm_dynwind_free (mem)’ is an equivalent shorthand for ‘scm_dynwind_unwind_handler (free, mem, SCM_F_WIND_EXPLICITLY)’. 6.11.11 Fluids and Dynamic States --------------------------------- A _fluid_ is a variable whose value is associated with the dynamic extent of a function call. In the same way that an operating system runs a process with a given set of current input and output ports (or file descriptors), in Guile you can arrange to call a function while binding a fluid to a particular value. That association between fluid and value will exist during the dynamic extent of the function call. Fluids are therefore a building block for implementing dynamically scoped variables. Dynamically scoped variables are useful when you want to set a variable to a value during some dynamic extent in the execution of your program and have them revert to their original value when the control flow is outside of this dynamic extent. See the description of ‘with-fluids’ below for details. This association between fluids, values, and dynamic extents is robust to multiple entries (as when a captured continuation is invoked more than once) and early exits (for example, when throwing exceptions). Guile uses fluids to implement parameters (*note Parameters::). Usually you just want to use parameters directly. However it can be useful to know what a fluid is and how it works, so that's what this section is about. The current set of fluid-value associations can be captured in a _dynamic state_ object. A dynamic extent is simply that: a snapshot of the current fluid-value associations. Guile users can capture the current dynamic state with ‘current-dynamic-state’ and restore it later via ‘with-dynamic-state’ or similar procedures. This facility is especially useful when implementing lightweight thread-like abstractions. New fluids are created with ‘make-fluid’ and ‘fluid?’ is used for testing whether an object is actually a fluid. The values stored in a fluid can be accessed with ‘fluid-ref’ and ‘fluid-set!’. *Note Thread Local Variables::, for further notes on fluids, threads, parameters, and dynamic states. -- Scheme Procedure: make-fluid [dflt] -- C Function: scm_make_fluid () -- C Function: scm_make_fluid_with_default (dflt) Return a newly created fluid, whose initial value is DFLT, or ‘#f’ if DFLT is not given. Fluids are objects that can hold one value per dynamic state. That is, modifications to this value are only visible to code that executes with the same dynamic state as the modifying code. When a new dynamic state is constructed, it inherits the values from its parent. Because each thread normally executes with its own dynamic state, you can use fluids for thread local storage. -- Scheme Procedure: make-unbound-fluid -- C Function: scm_make_unbound_fluid () Return a new fluid that is initially unbound (instead of being implicitly bound to some definite value). -- Scheme Procedure: fluid? obj -- C Function: scm_fluid_p (obj) Return ‘#t’ if OBJ is a fluid; otherwise, return ‘#f’. -- Scheme Procedure: fluid-ref fluid -- C Function: scm_fluid_ref (fluid) Return the value associated with FLUID in the current dynamic root. If FLUID has not been set, then return its default value. Calling ‘fluid-ref’ on an unbound fluid produces a runtime error. -- Scheme Procedure: fluid-set! fluid value -- C Function: scm_fluid_set_x (fluid, value) Set the value associated with FLUID in the current dynamic root. -- Scheme Procedure: fluid-ref* fluid depth -- C Function: scm_fluid_ref_star (fluid, depth) Return the DEPTHth oldest value associated with FLUID in the current thread. If DEPTH equals or exceeds the number of values that have been assigned to FLUID, return the default value of the fluid. ‘(fluid-ref* f 0)’ is equivalent to ‘(fluid-ref f)’. ‘fluid-ref*’ is useful when you want to maintain a stack-like structure in a fluid, such as the stack of current exception handlers. Using ‘fluid-ref*’ instead of an explicit stack allows any partial continuation captured by ‘call-with-prompt’ to only capture the bindings made within the limits of the prompt instead of the entire continuation. *Note Prompts::, for more on delimited continuations. -- Scheme Procedure: fluid-unset! fluid -- C Function: scm_fluid_unset_x (fluid) Disassociate the given fluid from any value, making it unbound. -- Scheme Procedure: fluid-bound? fluid -- C Function: scm_fluid_bound_p (fluid) Returns ‘#t’ if the given fluid is bound to a value, otherwise ‘#f’. ‘with-fluids*’ temporarily changes the values of one or more fluids, so that the given procedure and each procedure called by it access the given values. After the procedure returns, the old values are restored. -- Scheme Procedure: with-fluid* fluid value thunk -- C Function: scm_with_fluid (fluid, value, thunk) Set FLUID to VALUE temporarily, and call THUNK. THUNK must be a procedure with no argument. -- Scheme Procedure: with-fluids* fluids values thunk -- C Function: scm_with_fluids (fluids, values, thunk) Set FLUIDS to VALUES temporary, and call THUNK. FLUIDS must be a list of fluids and VALUES must be the same number of their values to be applied. Each substitution is done in the order given. THUNK must be a procedure with no argument. It is called inside a ‘dynamic-wind’ and the fluids are set/restored when control enter or leaves the established dynamic extent. -- Scheme Macro: with-fluids ((fluid value) ...) body Execute BODY (*note Local Bindings::) while each FLUID is set to the corresponding VALUE. Both FLUID and VALUE are evaluated and FLUID must yield a fluid. The body is executed inside a ‘dynamic-wind’ and the fluids are set/restored when control enter or leaves the established dynamic extent. -- C Function: SCM scm_c_with_fluids (SCM fluids, SCM vals, SCM (*cproc)(void *), void *data) -- C Function: SCM scm_c_with_fluid (SCM fluid, SCM val, SCM (*cproc)(void *), void *data) The function ‘scm_c_with_fluids’ is like ‘scm_with_fluids’ except that it takes a C function to call instead of a Scheme thunk. The function ‘scm_c_with_fluid’ is similar but only allows one fluid to be set instead of a list. -- C Function: void scm_dynwind_fluid (SCM fluid, SCM val) This function must be used inside a pair of calls to ‘scm_dynwind_begin’ and ‘scm_dynwind_end’ (*note Dynamic Wind::). During the dynwind context, the fluid FLUID is set to VAL. More precisely, the value of the fluid is swapped with a 'backup' value whenever the dynwind context is entered or left. The backup value is initialized with the VAL argument. -- Scheme Procedure: dynamic-state? obj -- C Function: scm_dynamic_state_p (obj) Return ‘#t’ if OBJ is a dynamic state object; return ‘#f’ otherwise. -- C Procedure: int scm_is_dynamic_state (SCM obj) Return non-zero if OBJ is a dynamic state object; return zero otherwise. -- Scheme Procedure: current-dynamic-state -- C Function: scm_current_dynamic_state () Return a snapshot of the current fluid-value associations as a fresh dynamic state object. -- Scheme Procedure: set-current-dynamic-state state -- C Function: scm_set_current_dynamic_state (state) Restore the saved fluid-value associations from STATE, replacing the current fluid-value associations. Return the current fluid-value associations as a dynamic state object, as in ‘current-dynamic-state’. -- Scheme Procedure: with-dynamic-state state proc -- C Function: scm_with_dynamic_state (state, proc) Call PROC while the fluid bindings from STATE have been made current, saving the current fluid bindings. When control leaves the invocation of PROC, restore the saved bindings, saving instead the fluid bindings from inside the call. If control later re-enters PROC, restore those saved bindings, saving the current bindings, and so on. -- C Procedure: void scm_dynwind_current_dynamic_state (SCM state) Set the current dynamic state to STATE for the current dynwind context. Like ‘with-dynamic-state’, but in terms of Guile's "dynwind" C API. -- C Procedure: void * scm_c_with_dynamic_state (SCM state, void *(*func)(void *), void *data) Like ‘scm_with_dynamic_state’, but call FUNC with DATA. 6.11.12 Parameters ------------------ Parameters are Guile's facility for dynamically bound variables. On the most basic level, a parameter object is a procedure. Calling it with no arguments returns its value. Calling it with one argument sets the value. (define my-param (make-parameter 123)) (my-param) ⇒ 123 (my-param 456) (my-param) ⇒ 456 The ‘parameterize’ special form establishes new locations for parameters, those new locations having effect within the dynamic extent of the ‘parameterize’ body. Leaving restores the previous locations. Re-entering (through a saved continuation) will again use the new locations. (parameterize ((my-param 789)) (my-param)) ⇒ 789 (my-param) ⇒ 456 Parameters are like dynamically bound variables in other Lisp dialects. They allow an application to establish parameter settings (as the name suggests) just for the execution of a particular bit of code, restoring when done. Examples of such parameters might be case-sensitivity for a search, or a prompt for user input. Global variables are not as good as parameter objects for this sort of thing. Changes to them are visible to all threads, but in Guile parameter object locations are per-thread, thereby truly limiting the effect of ‘parameterize’ to just its dynamic execution. Passing arguments to functions is thread-safe, but that soon becomes tedious when there's more than a few or when they need to pass down through several layers of calls before reaching the point they should affect. Introducing a new setting to existing code is often easier with a parameter object than adding arguments. -- Scheme Procedure: make-parameter init [converter] Return a new parameter object, with initial value INIT. If a CONVERTER is given, then a call ‘(CONVERTER val)’ is made for each value set, its return is the value stored. Such a call is made for the INIT initial value too. A CONVERTER allows values to be validated, or put into a canonical form. For example, (define my-param (make-parameter 123 (lambda (val) (if (not (number? val)) (error "must be a number")) (inexact->exact val)))) (my-param 0.75) (my-param) ⇒ 3/4 -- library syntax: parameterize ((param value) ...) body1 body2 ... Establish a new dynamic scope with the given PARAMs bound to new locations and set to the given VALUEs. BODY1 BODY2 ... is evaluated in that environment. The value returned is that of last body form. Each PARAM is an expression which is evaluated to get the parameter object. Often this will just be the name of a variable holding the object, but it can be anything that evaluates to a parameter. The PARAM expressions and VALUE expressions are all evaluated before establishing the new dynamic bindings, and they're evaluated in an unspecified order. For example, (define prompt (make-parameter "Type something: ")) (define (get-input) (display (prompt)) ...) (parameterize ((prompt "Type a number: ")) (get-input) ...) Parameter objects are implemented using fluids (*note Fluids and Dynamic States::), so each dynamic state has its own parameter locations. That includes the separate locations when outside any ‘parameterize’ form. When a parameter is created it gets a separate initial location in each dynamic state, all initialized to the given INIT value. New code should probably just use parameters instead of fluids, because the interface is better. But for migrating old code or otherwise providing interoperability, Guile provides the ‘fluid->parameter’ procedure: -- Scheme Procedure: fluid->parameter fluid [conv] Make a parameter that wraps a fluid. The value of the parameter will be the same as the value of the fluid. If the parameter is rebound in some dynamic extent, perhaps via ‘parameterize’, the new value will be run through the optional CONV procedure, as with any parameter. Note that unlike ‘make-parameter’, CONV is not applied to the initial value. As alluded to above, because each thread usually has a separate dynamic state, each thread has its own locations behind parameter objects, and changes in one thread are not visible to any other. When a new dynamic state or thread is created, the values of parameters in the originating context are copied, into new locations. Guile's parameters conform to SRFI-39 (*note SRFI-39::). 6.11.13 How to Handle Errors ---------------------------- Guile is currently in a transition from its historical ‘catch’ and ‘throw’ error handling and signaling operators to the new structured exception facility; *Note Exceptions::. However in the meantime, here is some documentation on errors and the older ‘catch’ and ‘throw’ interface. Errors are always thrown with a KEY and four arguments: • KEY: a symbol which indicates the type of error. The symbols used by libguile are listed below. • SUBR: the name of the procedure from which the error is thrown, or ‘#f’. • MESSAGE: a string (possibly language and system dependent) describing the error. The tokens ‘~A’ and ‘~S’ can be embedded within the message: they will be replaced with members of the ARGS list when the message is printed. ‘~A’ indicates an argument printed using ‘display’, while ‘~S’ indicates an argument printed using ‘write’. MESSAGE can also be ‘#f’, to allow it to be derived from the KEY by the error handler (may be useful if the KEY is to be thrown from both C and Scheme). • ARGS: a list of arguments to be used to expand ‘~A’ and ‘~S’ tokens in MESSAGE. Can also be ‘#f’ if no arguments are required. • REST: a list of any additional objects required. e.g., when the key is ‘'system-error’, this contains the C errno value. Can also be ‘#f’ if no additional objects are required. In addition to ‘catch’ and ‘throw’, the following Scheme facilities are available: -- Scheme Procedure: display-error frame port subr message args rest -- C Function: scm_display_error (frame, port, subr, message, args, rest) Display an error message to the output port PORT. FRAME is the frame in which the error occurred, SUBR is the name of the procedure in which the error occurred and MESSAGE is the actual error message, which may contain formatting instructions. These will format the arguments in the list ARGS accordingly. REST is currently ignored. The following are the error keys defined by libguile and the situations in which they are used: • ‘error-signal’: thrown after receiving an unhandled fatal signal such as SIGSEGV, SIGBUS, SIGFPE etc. The REST argument in the throw contains the coded signal number (at present this is not the same as the usual Unix signal number). • ‘system-error’: thrown after the operating system indicates an error condition. The REST argument in the throw contains the errno value. • ‘numerical-overflow’: numerical overflow. • ‘out-of-range’: the arguments to a procedure do not fall within the accepted domain. • ‘wrong-type-arg’: an argument to a procedure has the wrong type. • ‘wrong-number-of-args’: a procedure was called with the wrong number of arguments. • ‘memory-allocation-error’: memory allocation error. • ‘stack-overflow’: stack overflow error. • ‘regular-expression-syntax’: errors generated by the regular expression library. • ‘misc-error’: other errors. 6.11.13.1 C Support ................... In the following C functions, SUBR and MESSAGE parameters can be ‘NULL’ to give the effect of ‘#f’ described above. -- C Function: SCM scm_error (SCM KEY, const char *SUBR, const char *MESSAGE, SCM ARGS, SCM REST) Throw an error, as per ‘scm-error’ (*note Error Reporting::). -- C Function: void scm_syserror (const char *SUBR) -- C Function: void scm_syserror_msg (const char *SUBR, const char *MESSAGE, SCM ARGS) Throw an error with key ‘system-error’ and supply ‘errno’ in the REST argument. For ‘scm_syserror’ the message is generated using ‘strerror’. Care should be taken that any code in between the failing operation and the call to these routines doesn't change ‘errno’. -- C Function: void scm_num_overflow (const char *SUBR) -- C Function: void scm_out_of_range (const char *SUBR, SCM BAD_VALUE) -- C Function: void scm_wrong_num_args (SCM PROC) -- C Function: void scm_wrong_type_arg (const char *SUBR, int ARGNUM, SCM BAD_VALUE) -- C Function: void scm_wrong_type_arg_msg (const char *SUBR, int ARGNUM, SCM BAD_VALUE, const char *EXPECTED) -- C Function: void scm_misc_error (const char *SUBR, const char *MESSAGE, SCM ARGS) Throw an error with the various keys described above. In ‘scm_wrong_num_args’, PROC should be a Scheme symbol which is the name of the procedure incorrectly invoked. The other routines take the name of the invoked procedure as a C string. In ‘scm_wrong_type_arg_msg’, EXPECTED is a C string describing the type of argument that was expected. In ‘scm_misc_error’, MESSAGE is the error message string, possibly containing ‘simple-format’ escapes (*note Simple Output::), and the corresponding arguments in the ARGS list. 6.11.13.2 Signaling Type Errors ............................... Every function visible at the Scheme level should aggressively check the types of its arguments, to avoid misinterpreting a value, and perhaps causing a segmentation fault. Guile provides some macros to make this easier. -- Macro: void SCM_ASSERT (int TEST, SCM OBJ, unsigned int POSITION, const char *SUBR) -- Macro: void SCM_ASSERT_TYPE (int TEST, SCM OBJ, unsigned int POSITION, const char *SUBR, const char *EXPECTED) If TEST is zero, signal a "wrong type argument" error, attributed to the subroutine named SUBR, operating on the value OBJ, which is the POSITION'th argument of SUBR. In ‘SCM_ASSERT_TYPE’, EXPECTED is a C string describing the type of argument that was expected. -- Macro: int SCM_ARG1 -- Macro: int SCM_ARG2 -- Macro: int SCM_ARG3 -- Macro: int SCM_ARG4 -- Macro: int SCM_ARG5 -- Macro: int SCM_ARG6 -- Macro: int SCM_ARG7 One of the above values can be used for POSITION to indicate the number of the argument of SUBR which is being checked. Alternatively, a positive integer number can be used, which allows to check arguments after the seventh. However, for parameter numbers up to seven it is preferable to use ‘SCM_ARGN’ instead of the corresponding raw number, since it will make the code easier to understand. -- Macro: int SCM_ARGn Passing a value of zero or ‘SCM_ARGn’ for POSITION allows to leave it unspecified which argument's type is incorrect. Again, ‘SCM_ARGn’ should be preferred over a raw zero constant. 6.11.14 Continuation Barriers ----------------------------- The non-local flow of control caused by continuations might sometimes not be wanted. You can use ‘with-continuation-barrier’ to erect fences that continuations can not pass. -- Scheme Procedure: with-continuation-barrier proc -- C Function: scm_with_continuation_barrier (proc) Call PROC and return its result. Do not allow the invocation of continuations that would leave or enter the dynamic extent of the call to ‘with-continuation-barrier’. Such an attempt causes an error to be signaled. Throws (such as errors) that are not caught from within PROC are caught by ‘with-continuation-barrier’. In that case, a short message is printed to the current error port and ‘#f’ is returned. Thus, ‘with-continuation-barrier’ returns exactly once. -- C Function: void * scm_c_with_continuation_barrier (void *(*func) (void *), void *data) Like ‘scm_with_continuation_barrier’ but call FUNC on DATA. When an error is caught, ‘NULL’ is returned. 6.12 Input and Output ===================== 6.12.1 Ports ------------ Ports are the way that Guile performs input and output. Guile can read in characters or bytes from an “input port”, or write them out to an “output port”. Some ports support both interfaces. There are a number of different port types implemented in Guile. File ports provide input and output over files, as you might imagine. For example, we might display a string to a file like this: (let ((port (open-output-file "foo.txt"))) (display "Hello, world!\n" port) (close-port port)) There are also string ports, for taking input from a string, or collecting output to a string; bytevector ports, for doing the same but using a bytevector as a source or sink of data; and custom ports, for arranging to call Scheme functions to provide input or handle output. *Note Port Types::. Ports should be “closed” when they are not needed by calling ‘close-port’ on them, as in the example above. This will make sure that any pending output is successfully written out to disk, in the case of a file port, or otherwise to whatever mutable store is backed by the port. Any error that occurs while writing out that buffered data would also be raised promptly at the ‘close-port’, and not later when the port is closed by the garbage collector. *Note Buffering::, for more on buffered output. Closing a port also releases any precious resource the file might have. Usually in Scheme a programmer doesn't have to clean up after their data structures (*note Memory Management::), but most systems have strict limits on how many files can be open, both on a per-process and a system-wide basis. A program that uses many files should take care not to hit those limits. The same applies to similar system resources such as pipes and sockets. Indeed for these reasons the above example is not the most idiomatic way to use ports. It is more common to acquire ports via procedures like ‘call-with-output-file’, which handle the ‘close-port’ automatically: (call-with-output-file "foo.txt" (lambda (port) (display "Hello, world!\n" port))) Finally, all ports have associated input and output buffers, as appropriate. Buffering is a common strategy to limit the overhead of small reads and writes: without buffering, each character fetched from a file would involve at least one call into the kernel, and maybe more depending on the character and the encoding. Instead, Guile will batch reads and writes into internal buffers. However, sometimes you want to make output on a port show up immediately. *Note Buffering::, for more on interfaces to control port buffering. -- Scheme Procedure: port? x -- C Function: scm_port_p (x) Return a boolean indicating whether X is a port. Equivalent to ‘(or (input-port? X) (output-port? X))’. -- Scheme Procedure: input-port? x -- C Function: scm_input_port_p (x) Return ‘#t’ if X is an input port, otherwise return ‘#f’. Any object satisfying this predicate also satisfies ‘port?’. -- Scheme Procedure: output-port? x -- C Function: scm_output_port_p (x) Return ‘#t’ if X is an output port, otherwise return ‘#f’. Any object satisfying this predicate also satisfies ‘port?’. -- Scheme Procedure: close-port port -- C Function: scm_close_port (port) Close the specified port object. Return ‘#t’ if it successfully closes a port or ‘#f’ if it was already closed. An exception may be raised if an error occurs, for example when flushing buffered output. *Note Buffering::, for more on buffered output. *Note close: Ports and File Descriptors, for a procedure which can close file descriptors. -- Scheme Procedure: port-closed? port -- C Function: scm_port_closed_p (port) Return ‘#t’ if PORT is closed or ‘#f’ if it is open. -- Scheme Procedure: call-with-port port proc Call PROC, passing it PORT and closing PORT upon exit of PROC. Return the return values of PROC. 6.12.2 Binary I/O ----------------- Guile's ports are fundamentally binary in nature: at the lowest level, they work on bytes. This section describes Guile's core binary I/O operations. *Note Textual I/O::, for input and output of strings and characters. To use these routines, first include the binary I/O module: (use-modules (ice-9 binary-ports)) Note that although this module's name suggests that binary ports are some different kind of port, that's not the case: all ports in Guile are both binary and textual ports. -- Scheme Procedure: get-u8 port -- C Function: scm_get_u8 (port) Return an octet read from PORT, an input port, blocking as necessary, or the end-of-file object. -- Scheme Procedure: lookahead-u8 port -- C Function: scm_lookahead_u8 (port) Like ‘get-u8’ but does not update PORT's position to point past the octet. The end-of-file object is unlike any other kind of object: it's not a pair, a symbol, or anything else. To check if a value is the end-of-file object, use the ‘eof-object?’ predicate. -- Scheme Procedure: eof-object? x -- C Function: scm_eof_object_p (x) Return ‘#t’ if X is an end-of-file object, or ‘#f’ otherwise. Note that unlike other procedures in this module, ‘eof-object?’ is defined in the default environment. -- Scheme Procedure: get-bytevector-n port count -- C Function: scm_get_bytevector_n (port, count) Read COUNT octets from PORT, blocking as necessary and return a bytevector containing the octets read. If fewer bytes are available, a bytevector smaller than COUNT is returned. -- Scheme Procedure: get-bytevector-n! port bv start count -- C Function: scm_get_bytevector_n_x (port, bv, start, count) Read COUNT bytes from PORT and store them in BV starting at index START. Return either the number of bytes actually read or the end-of-file object. -- Scheme Procedure: get-bytevector-some port -- C Function: scm_get_bytevector_some (port) Read from PORT, blocking as necessary, until bytes are available or an end-of-file is reached. Return either the end-of-file object or a new bytevector containing some of the available bytes (at least one), and update the port position to point just past these bytes. -- Scheme Procedure: get-bytevector-some! port bv start count -- C Function: scm_get_bytevector_some_x (port, bv, start, count) Read up to COUNT bytes from PORT, blocking as necessary until at least one byte is available or an end-of-file is reached. Store them in BV starting at index START. Return the number of bytes actually read, or an end-of-file object. -- Scheme Procedure: get-bytevector-all port -- C Function: scm_get_bytevector_all (port) Read from PORT, blocking as necessary, until the end-of-file is reached. Return either a new bytevector containing the data read or the end-of-file object (if no data were available). -- Scheme Procedure: unget-bytevector port bv [start [count]] -- C Function: scm_unget_bytevector (port, bv, start, count) Place the contents of BV in PORT, optionally starting at index START and limiting to COUNT octets, so that its bytes will be read from left-to-right as the next bytes from PORT during subsequent read operations. If called multiple times, the unread bytes will be read again in last-in first-out order. To perform binary output on a port, use ‘put-u8’ or ‘put-bytevector’. -- Scheme Procedure: put-u8 port octet -- C Function: scm_put_u8 (port, octet) Write OCTET, an integer in the 0-255 range, to PORT, a binary output port. -- Scheme Procedure: put-bytevector port bv [start [count]] -- C Function: scm_put_bytevector (port, bv, start, count) Write the contents of BV to PORT, optionally starting at index START and limiting to COUNT octets. Binary I/O in R7RS .................. *note R7RS: R7RS Standard Libraries. defines the following binary I/O procedures. Access them with (use-modules (scheme base)) -- Scheme Procedure: open-output-bytevector Returns a binary output port that will accumulate bytes for retrieval by *note ‘get-output-bytevector’: x-get-output-bytevector. -- Scheme Procedure: write-u8 byte [out] Writes BYTE to the given binary output port OUT and returns an unspecified value. OUT defaults to ‘(current-output-port)’. See also *note ‘put-u8’: x-put-u8. -- Scheme Procedure: read-u8 [in] Returns the next byte available from the binary input port IN, updating the port to point to the following byte. If no more bytes are available, an end-of-file object is returned. IN defaults to ‘(current-input-port)’. See also *note ‘get-u8’: x-get-u8. -- Scheme Procedure: peek-u8 [in] Returns the next byte available from the binary input port IN, but without updating the port to point to the following byte. If no more bytes are available, an end-of-file object is returned. IN defaults to ‘(current-input-port)’. See also *note ‘lookahead-u8’: x-lookahead-u8. -- Scheme Procedure: get-output-bytevector port Returns a bytevector consisting of the bytes that have been output to PORT so far in the order they were output. It is an error if PORT was not created with *note ‘open-output-bytevector’: x-open-output-bytevector. (define out (open-output-bytevector)) (write-u8 1 out) (write-u8 2 out) (write-u8 3 out) (get-output-bytevector out) ⇒ #vu8(1 2 3) -- Scheme Procedure: open-input-bytevector bv Takes a bytevector BV and returns a binary input port that delivers bytes from BV. (define in (open-input-bytevector #vu8(1 2 3))) (read-u8 in) ⇒ 1 (peek-u8 in) ⇒ 2 (read-u8 in) ⇒ 2 (read-u8 in) ⇒ 3 (read-u8 in) ⇒ # -- Scheme Procedure: read-bytevector! bv [port [start [end]]] Reads the next END - START bytes, or as many as are available before the end of file, from the binary input port into the bytevector BV in left-to-right order beginning at the START position. If END is not supplied, reads until the end of BV has been reached. If START is not supplied, reads beginning at position 0. Returns the number of bytes read. If no bytes are available, an end-of-file object is returned. (define in (open-input-bytevector #vu8(1 2 3))) (define bv (make-bytevector 5 0)) (read-bytevector! bv in 1 3) ⇒ 2 bv ⇒ #vu8(0 1 2 0 0 0) -- Scheme Procedure: read-bytevector k in Reads the next K bytes, or as many as are available before the end of file if that is less than K, from the binary input port IN into a newly allocated bytevector in left-to-right order, and returns the bytevector. If no bytes are available before the end of file, an end-of-file object is returned. (define bv #vu8(1 2 3)) (read-bytevector 2 (open-input-bytevector bv)) ⇒ #vu8(1 2) (read-bytevector 10 (open-input-bytevector bv)) ⇒ #vu8(1 2 3) -- Scheme Procedure: write-bytevector bv [port [start [end]]] Writes the bytes of bytevector BV from START to END in left-to-right order to the binary output PORT. START defaults to 0 and END defaults to the length of BV. (define out (open-output-bytevector)) (write-bytevector #vu8(0 1 2 3 4) out 2 4) (get-output-bytevector out) ⇒ #vu8(2 3) 6.12.3 Encoding --------------- Textual input and output on Guile ports is layered on top of binary operations. To this end, each port has an associated character encoding that controls how bytes read from the port are converted to characters, and how characters written to the port are converted to bytes. -- Scheme Procedure: port-encoding port -- C Function: scm_port_encoding (port) Returns, as a string, the character encoding that PORT uses to interpret its input and output. -- Scheme Procedure: set-port-encoding! port enc -- C Function: scm_set_port_encoding_x (port, enc) Sets the character encoding that will be used to interpret I/O to PORT. ENC is a string containing the name of an encoding. Valid encoding names are those defined by IANA (http://www.iana.org/assignments/character-sets), for example ‘"UTF-8"’ or ‘"ISO-8859-1"’. When ports are created, they are assigned an encoding. The usual process to determine the initial encoding for a port is to take the value of the ‘%default-port-encoding’ fluid. -- Scheme Variable: %default-port-encoding A fluid containing name of the encoding to be used by default for newly created ports (*note Fluids and Dynamic States::). As a special case, the value ‘#f’ is equivalent to ‘"ISO-8859-1"’. The ‘%default-port-encoding’ itself defaults to the encoding appropriate for the current locale, if ‘setlocale’ has been called. *Note Locales::, for more on locales and when you might need to call ‘setlocale’ explicitly. Some port types have other ways of determining their initial locales. String ports, for example, default to the UTF-8 encoding, in order to be able to represent all characters regardless of the current locale. File ports can optionally sniff their file for a ‘coding:’ declaration; *Note File Ports::. Binary ports might be initialized to the ISO-8859-1 encoding in which each codepoint between 0 and 255 corresponds to a byte with that value. Currently, the ports only work with _non-modal_ encodings. Most encodings are non-modal, meaning that the conversion of bytes to a string doesn't depend on its context: the same byte sequence will always return the same string. A couple of modal encodings are in common use, like ISO-2022-JP and ISO-2022-KR, and they are not yet supported. Each port also has an associated conversion strategy, which determines what to do when a Guile character can't be converted to the port's encoded character representation for output. There are three possible strategies: to raise an error, to replace the character with a hex escape, or to replace the character with a substitute character. Port conversion strategies are also used when decoding characters from an input port. -- Scheme Procedure: port-conversion-strategy port -- C Function: scm_port_conversion_strategy (port) Returns the behavior of the port when outputting a character that is not representable in the port's current encoding. If PORT is ‘#f’, then the current default behavior will be returned. New ports will have this default behavior when they are created. -- Scheme Procedure: set-port-conversion-strategy! port sym -- C Function: scm_set_port_conversion_strategy_x (port, sym) Sets the behavior of Guile when outputting a character that is not representable in the port's current encoding, or when Guile encounters a decoding error when trying to read a character. SYM can be either ‘error’, ‘substitute’, or ‘escape’. If PORT is an open port, the conversion error behavior is set for that port. If it is ‘#f’, it is set as the default behavior for any future ports that get created in this thread. As with port encodings, there is a fluid which determines the initial conversion strategy for a port. -- Scheme Variable: %default-port-conversion-strategy The fluid that defines the conversion strategy for newly created ports, and also for other conversion routines such as ‘scm_to_stringn’, ‘scm_from_stringn’, ‘string->pointer’, and ‘pointer->string’. Its value must be one of the symbols described above, with the same semantics: ‘error’, ‘substitute’, or ‘escape’. When Guile starts, its value is ‘substitute’. Note that ‘(set-port-conversion-strategy! #f SYM)’ is equivalent to ‘(fluid-set! %default-port-conversion-strategy SYM)’. As mentioned above, for an output port there are three possible port conversion strategies. The ‘error’ strategy will throw an error when a nonconvertible character is encountered. The ‘substitute’ strategy will replace nonconvertible characters with a question mark (‘?’). Finally the ‘escape’ strategy will print nonconvertible characters as a hex escape, using the escaping that is recognized by Guile's string syntax. Note that if the port's encoding is a Unicode encoding, like ‘UTF-8’, then encoding errors are impossible. For an input port, the ‘error’ strategy will cause Guile to throw an error if it encounters an invalid encoding, such as might happen if you tried to read ‘ISO-8859-1’ as ‘UTF-8’. The error is thrown before advancing the read position. The ‘substitute’ strategy will replace the bad bytes with a U+FFFD replacement character, in accordance with Unicode recommendations. When reading from an input port, the ‘escape’ strategy is treated as if it were ‘error’. 6.12.4 Textual I/O ------------------ This section describes Guile's core textual I/O operations on characters and strings. *Note Binary I/O::, for input and output of bytes and bytevectors. *Note Encoding::, for more on how characters relate to bytes. To read general S-expressions from ports, *Note Scheme Read::. *Note Scheme Write::, for interfaces that write generic Scheme datums. To use these routines, first include the textual I/O module: (use-modules (ice-9 textual-ports)) Note that although this module's name suggests that textual ports are some different kind of port, that's not the case: all ports in Guile are both binary and textual ports. -- Scheme Procedure: get-char input-port Reads from INPUT-PORT, blocking as necessary, until a complete character is available from INPUT-PORT, or until an end of file is reached. If a complete character is available before the next end of file, ‘get-char’ returns that character and updates the input port to point past the character. If an end of file is reached before any character is read, ‘get-char’ returns the end-of-file object. -- Scheme Procedure: lookahead-char input-port The ‘lookahead-char’ procedure is like ‘get-char’, but it does not update INPUT-PORT to point past the character. In the same way that it's possible to "unget" a byte or bytes, it's possible to "unget" the bytes corresponding to an encoded character. -- Scheme Procedure: unget-char port char Place character CHAR in PORT so that it will be read by the next read operation. If called multiple times, the unread characters will be read again in last-in first-out order. -- Scheme Procedure: unget-string port str Place the string STR in PORT so that its characters will be read from left-to-right as the next characters from PORT during subsequent read operations. If called multiple times, the unread characters will be read again in last-in first-out order. Reading in a character at a time can be inefficient. If it's possible to perform I/O over multiple characters at a time, via strings, that might be faster. -- Scheme Procedure: get-string-n input-port count The ‘get-string-n’ procedure reads from INPUT-PORT, blocking as necessary, until COUNT characters are available, or until an end of file is reached. COUNT must be an exact, non-negative integer, representing the number of characters to be read. If COUNT characters are available before end of file, ‘get-string-n’ returns a string consisting of those COUNT characters. If fewer characters are available before an end of file, but one or more characters can be read, ‘get-string-n’ returns a string containing those characters. In either case, the input port is updated to point just past the characters read. If no characters can be read before an end of file, the end-of-file object is returned. -- Scheme Procedure: get-string-n! input-port string start count The ‘get-string-n!’ procedure reads from INPUT-PORT in the same manner as ‘get-string-n’. START and COUNT must be exact, non-negative integer objects, with COUNT representing the number of characters to be read. STRING must be a string with at least $START + COUNT$ characters. If COUNT characters are available before an end of file, they are written into STRING starting at index START, and COUNT is returned. If fewer characters are available before an end of file, but one or more can be read, those characters are written into STRING starting at index START and the number of characters actually read is returned as an exact integer object. If no characters can be read before an end of file, the end-of-file object is returned. -- Scheme Procedure: get-string-all input-port Reads from INPUT-PORT until an end of file, decoding characters in the same manner as ‘get-string-n’ and ‘get-string-n!’. If characters are available before the end of file, a string containing all the characters decoded from that data are returned. If no character precedes the end of file, the end-of-file object is returned. -- Scheme Procedure: get-line input-port Reads from INPUT-PORT up to and including the linefeed character or end of file, decoding characters in the same manner as ‘get-string-n’ and ‘get-string-n!’. If a linefeed character is read, a string containing all of the text up to (but not including) the linefeed character is returned, and the port is updated to point just past the linefeed character. If an end of file is encountered before any linefeed character is read, but some characters have been read and decoded as characters, a string containing those characters is returned. If an end of file is encountered before any characters are read, the end-of-file object is returned. Finally, there are just two core procedures to write characters to a port. -- Scheme Procedure: put-char port char Writes CHAR to the port. The ‘put-char’ procedure returns an unspecified value. -- Scheme Procedure: put-string port string -- Scheme Procedure: put-string port string start -- Scheme Procedure: put-string port string start count Write the COUNT characters of STRING starting at index START to the port. START and COUNT must be non-negative exact integer objects. STRING must have a length of at least START + COUNT. START defaults to 0. COUNT defaults to ‘(string-length STRING)’ - START$. Calling ‘put-string’ is equivalent in all respects to calling ‘put-char’ on the relevant sequence of characters, except that it will attempt to write multiple characters to the port at a time, even if the port is unbuffered. The ‘put-string’ procedure returns an unspecified value. Textual ports have a textual position associated with them: a line and a column. Reading in characters or writing them out advances the line and the column appropriately. -- Scheme Procedure: port-column port -- Scheme Procedure: port-line port -- C Function: scm_port_column (port) -- C Function: scm_port_line (port) Return the current column number or line number of PORT. Port lines and positions are represented as 0-origin integers, which is to say that the first character of the first line is line 0, column 0. However, when you display a line number, for example in an error message, we recommend you add 1 to get 1-origin integers. This is because lines numbers traditionally start with 1, and that is what non-programmers will find most natural. -- Scheme Procedure: set-port-column! port column -- Scheme Procedure: set-port-line! port line -- C Function: scm_set_port_column_x (port, column) -- C Function: scm_set_port_line_x (port, line) Set the current column or line number of PORT. 6.12.5 Simple Textual Output ---------------------------- Guile exports a simple formatted output function, ‘simple-format’. For a more capable formatted output facility, *Note Formatted Output::. -- Scheme Procedure: simple-format destination message . args -- C Function: scm_simple_format (destination, message, args) Write MESSAGE to DESTINATION, defaulting to the current output port. MESSAGE can contain ‘~A’ and ‘~S’ escapes. When printed, the escapes are replaced with corresponding members of ARGS: ‘~A’ formats using ‘display’ and ‘~S’ formats using ‘write’. If DESTINATION is ‘#t’, then use the current output port, if DESTINATION is ‘#f’, then return a string containing the formatted text. Does not add a trailing newline. Somewhat confusingly, Guile binds the ‘format’ identifier to ‘simple-format’ at startup. Once ‘(ice-9 format)’ loads, it actually replaces the core ‘format’ binding, so depending on whether you or a module you use has loaded ‘(ice-9 format)’, you may be using the simple or the more capable version. 6.12.6 Buffering ---------------- Every port has associated input and output buffers. You can think of ports as being backed by some mutable store, and that store might be far away. For example, ports backed by file descriptors have to go all the way to the kernel to read and write their data. To avoid this round-trip cost, Guile usually reads in data from the mutable store in chunks, and then services small requests like ‘get-char’ out of that intermediate buffer. Similarly, small writes like ‘write-char’ first go to a buffer, and are sent to the store when the buffer is full (or when port is flushed). Buffered ports speed up your program by reducing the number of round-trips to the mutable store, and they do so in a way that is mostly transparent to the user. There are two major ways, however, in which buffering affects program semantics. Building correct, performant programs requires understanding these situations. The first case is in random-access read/write ports (*note Random Access::). These ports, usually backed by a file, logically operate over the same mutable store when both reading and writing. So, if you read a character, causing the buffer to fill, then write a character, the bytes you filled in your read buffer are now invalid. Every time you switch between reading and writing, Guile has to flush any pending buffer. If this happens frequently, the cost can be high. In that case you should reduce the amount that you buffer, in both directions. Similarly, Guile has to flush buffers before seeking. None of these considerations apply to sockets, which don't logically read from and write to the same mutable store, and are not seekable. Note also that sockets are unbuffered by default. *Note Network Sockets and Communication::. The second case is the more pernicious one. If you write data to a buffered port, it probably doesn't go out to the mutable store directly. (This "probably" introduces some indeterminism in your program: what goes to the store, and when, depends on how full the buffer is. It is something that the user needs to explicitly be aware of.) The data is written to the store later - when the buffer fills up due to another write, or when ‘force-output’ is called, or when ‘close-port’ is called, or when the program exits, or even when the garbage collector runs. The salient point is, _the errors are signaled then too_. Buffered writes defer error detection (and defer the side effects to the mutable store), perhaps indefinitely if the port type does not need to be closed at GC. One common heuristic that works well for textual ports is to flush output when a newline (‘\n’) is written. This “line buffering” mode is on by default for TTY ports. Most other ports are “block buffered”, meaning that once the output buffer reaches the block size, which depends on the port and its configuration, the output is flushed as a block, without regard to what is in the block. Likewise reads are read in at the block size, though if there are fewer bytes available to read, the buffer may not be entirely filled. Note that binary reads or writes that are larger than the buffer size go directly to the mutable store without passing through the buffers. If your access pattern involves many big reads or writes, buffering might not matter so much to you. To control the buffering behavior of a port, use ‘setvbuf’. -- Scheme Procedure: setvbuf port mode [size] -- C Function: scm_setvbuf (port, mode, size) Set the buffering mode for PORT. MODE can be one of the following symbols: ‘none’ non-buffered ‘line’ line buffered ‘block’ block buffered, using a newly allocated buffer of SIZE bytes. If SIZE is omitted, a default size will be used. Another way to set the buffering, for file ports, is to open the file with ‘0’ or ‘l’ as part of the mode string, for unbuffered or line-buffered ports, respectively. *Note File Ports::, for more. Any buffered output data will be written out when the port is closed. To make sure to flush it at specific points in your program, use ‘force-output’. -- Scheme Procedure: force-output [port] -- C Function: scm_force_output (port) Flush the specified output port, or the current output port if PORT is omitted. The current output buffer contents, if any, are passed to the underlying port implementation. The return value is unspecified. -- Scheme Procedure: flush-all-ports -- C Function: scm_flush_all_ports () Equivalent to calling ‘force-output’ on all open output ports. The return value is unspecified. Similarly, sometimes you might want to switch from using Guile's ports to working directly on file descriptors. In that case, for input ports use ‘drain-input’ to get any buffered input from that port. -- Scheme Procedure: drain-input port -- C Function: scm_drain_input (port) This procedure clears a port's input buffers, similar to the way that force-output clears the output buffer. The contents of the buffers are returned as a single string, e.g., (define p (open-input-file ...)) (drain-input p) => empty string, nothing buffered yet. (unread-char (read-char p) p) (drain-input p) => initial chars from p, up to the buffer size. All of these considerations are very similar to those of streams in the C library, although Guile's ports are not built on top of C streams. Still, it is useful to read what other systems do. *Note (libc)Streams::, for more discussion on C streams. 6.12.7 Random Access -------------------- -- Scheme Procedure: seek fd_port offset whence -- C Function: scm_seek (fd_port, offset, whence) Sets the current position of FD_PORT to the integer OFFSET. For a file port, OFFSET is expressed as a number of bytes; for other types of ports, such as string ports, OFFSET is an abstract representation of the position within the port's data, not necessarily expressed as a number of bytes. OFFSET is interpreted according to the value of WHENCE. One of the following variables should be supplied for WHENCE: -- Variable: SEEK_SET Seek from the beginning of the file. -- Variable: SEEK_CUR Seek from the current position. -- Variable: SEEK_END Seek from the end of the file. On systems that support it, such as GNU/Linux, the following constants can be used for WHENCE to navigate "holes" in sparse files: -- Variable: SEEK_DATA Seek to the next location in the file greater than or equal to OFFSET containing data. If OFFSET points to data, then the file offset is set to OFFSET. -- Variable: SEEK_HOLE Seek to the next hole in the file greater than or equal to the OFFSET. If OFFSET points into the middle of a hole, then the file offset is set to OFFSET. If there is no hole past OFFSET, then the file offset is adjusted to the end of the file--i.e., there is an implicit hole at the end of any file. If FD_PORT is a file descriptor, the underlying system call is ‘lseek’ (*note (libc)File Position Primitive::). PORT may be a string port. The value returned is the new position in FD_PORT. This means that the current position of a port can be obtained using: (seek port 0 SEEK_CUR) -- Scheme Procedure: ftell fd_port -- C Function: scm_ftell (fd_port) Return an integer representing the current position of FD_PORT, measured from the beginning. Equivalent to: (seek port 0 SEEK_CUR) -- Scheme Procedure: truncate-file file [length] -- C Function: scm_truncate_file (file, length) Truncate FILE to LENGTH bytes. FILE can be a filename string, a port object, or an integer file descriptor. The return value is unspecified. For a port or file descriptor LENGTH can be omitted, in which case the file is truncated at the current position (per ‘ftell’ above). On most systems a file can be extended by giving a length greater than the current size, but this is not mandatory in the POSIX standard. 6.12.8 Line Oriented and Delimited Text --------------------------------------- The delimited-I/O module can be accessed with: (use-modules (ice-9 rdelim)) It can be used to read or write lines of text, or read text delimited by a specified set of characters. -- Scheme Procedure: read-line [port] [handle-delim] Return a line of text from PORT if specified, otherwise from the value returned by ‘(current-input-port)’. Under Unix, a line of text is terminated by the first end-of-line character or by end-of-file. If HANDLE-DELIM is specified, it should be one of the following symbols: ‘trim’ Discard the terminating delimiter. This is the default, but it will be impossible to tell whether the read terminated with a delimiter or end-of-file. ‘concat’ Append the terminating delimiter (if any) to the returned string. ‘peek’ Push the terminating delimiter (if any) back on to the port. ‘split’ Return a pair containing the string read from the port and the terminating delimiter or end-of-file object. -- Scheme Procedure: read-line! buf [port] Read a line of text into the supplied string BUF and return the number of characters added to BUF. If BUF is filled, then ‘#f’ is returned. Read from PORT if specified, otherwise from the value returned by ‘(current-input-port)’. -- Scheme Procedure: read-delimited delims [port] [handle-delim] Read text until one of the characters in the string DELIMS is found or end-of-file is reached. Read from PORT if supplied, otherwise from the value returned by ‘(current-input-port)’. HANDLE-DELIM takes the same values as described for ‘read-line’. -- Scheme Procedure: read-delimited! delims buf [port] [handle-delim] [start] [end] Read text into the supplied string BUF. If a delimiter was found, return the number of characters written, except if HANDLE-DELIM is ‘split’, in which case the return value is a pair, as noted above. As a special case, if PORT was already at end-of-stream, the EOF object is returned. Also, if no characters were written because the buffer was full, ‘#f’ is returned. It's something of a wacky interface, to be honest. -- Scheme Procedure: %read-delimited! delims str gobble [port [start [end]]] -- C Function: scm_read_delimited_x (delims, str, gobble, port, start, end) Read characters from PORT into STR until one of the characters in the DELIMS string is encountered. If GOBBLE is true, discard the delimiter character; otherwise, leave it in the input stream for the next read. If PORT is not specified, use the value of ‘(current-input-port)’. If START or END are specified, store data only into the substring of STR bounded by START and END (which default to the beginning and end of the string, respectively). Return a pair consisting of the delimiter that terminated the string and the number of characters read. If reading stopped at the end of file, the delimiter returned is the EOF-OBJECT; if the string was filled without encountering a delimiter, this value is ‘#f’. -- Scheme Procedure: %read-line [port] -- C Function: scm_read_line (port) Read a newline-terminated line from PORT, allocating storage as necessary. The newline terminator (if any) is removed from the string, and a pair consisting of the line and its delimiter is returned. The delimiter may be either a newline or the EOF-OBJECT; if ‘%read-line’ is called at the end of file, it returns the pair ‘(# . #)’. -- Scheme Procedure: write-line obj [port] -- C Function: scm_write_line (obj, port) Display OBJ and a newline character to PORT. If PORT is not specified, ‘(current-output-port)’ is used. This procedure is equivalent to: (display obj [port]) (newline [port]) 6.12.9 Default Ports for Input, Output and Errors ------------------------------------------------- -- Scheme Procedure: current-input-port -- C Function: scm_current_input_port () Return the current input port. This is the default port used by many input procedures. Initially this is the “standard input” in Unix and C terminology. When the standard input is a TTY the port is unbuffered, otherwise it's fully buffered. Unbuffered input is good if an application runs an interactive subprocess, since any type-ahead input won't go into Guile's buffer and be unavailable to the subprocess. Note that Guile buffering is completely separate from the TTY "line discipline". In the usual cooked mode on a TTY Guile only sees a line of input once the user presses . -- Scheme Procedure: current-output-port -- C Function: scm_current_output_port () Return the current output port. This is the default port used by many output procedures. Initially this is the “standard output” in Unix and C terminology. When the standard output is a TTY this port is unbuffered, otherwise it's fully buffered. Unbuffered output to a TTY is good for ensuring progress output or a prompt is seen. But an application which always prints whole lines could change to line buffered, or an application with a lot of output could go fully buffered and perhaps make explicit ‘force-output’ calls (*note Buffering::) at selected points. -- Scheme Procedure: current-error-port -- C Function: scm_current_error_port () Return the port to which errors and warnings should be sent. Initially this is the “standard error” in Unix and C terminology. When the standard error is a TTY this port is unbuffered, otherwise it's fully buffered. -- Scheme Procedure: set-current-input-port port -- Scheme Procedure: set-current-output-port port -- Scheme Procedure: set-current-error-port port -- C Function: scm_set_current_input_port (port) -- C Function: scm_set_current_output_port (port) -- C Function: scm_set_current_error_port (port) Change the ports returned by ‘current-input-port’, ‘current-output-port’ and ‘current-error-port’, respectively, so that they use the supplied PORT for input or output. -- Scheme Procedure: with-input-from-port port thunk -- Scheme Procedure: with-output-to-port port thunk -- Scheme Procedure: with-error-to-port port thunk Call THUNK in a dynamic environment in which ‘current-input-port’, ‘current-output-port’ or ‘current-error-port’ is rebound to the given PORT. -- C Function: void scm_dynwind_current_input_port (SCM port) -- C Function: void scm_dynwind_current_output_port (SCM port) -- C Function: void scm_dynwind_current_error_port (SCM port) These functions must be used inside a pair of calls to ‘scm_dynwind_begin’ and ‘scm_dynwind_end’ (*note Dynamic Wind::). During the dynwind context, the indicated port is set to PORT. More precisely, the current port is swapped with a 'backup' value whenever the dynwind context is entered or left. The backup value is initialized with the PORT argument. 6.12.10 Types of Port --------------------- 6.12.10.1 File Ports .................... The following procedures are used to open file ports. See also *note open: Ports and File Descriptors, for an interface to the Unix ‘open’ system call. All file access uses the "LFS" large file support functions when available, so files bigger than 2 gibibytes (2^31 bytes) can be read and written on a 32-bit system. Most systems have limits on how many files can be open, so it's strongly recommended that file ports be closed explicitly when no longer required (*note Ports::). -- Scheme Procedure: open-file filename mode [#:guess-encoding=#f] [#:encoding=#f] -- C Function: scm_open_file_with_encoding (filename, mode, guess_encoding, encoding) -- C Function: scm_open_file (filename, mode) Open the file whose name is FILENAME, and return a port representing that file. The attributes of the port are determined by the MODE string. The way in which this is interpreted is similar to C stdio. The first character must be one of the following: ‘r’ Open an existing file for input. ‘w’ Open a file for output, creating it if it doesn't already exist or removing its contents if it does. ‘a’ Open a file for output, creating it if it doesn't already exist. All writes to the port will go to the end of the file. The "append mode" can be turned off while the port is in use *note fcntl: Ports and File Descriptors. The following additional characters can be appended: ‘b’ Open the underlying file in binary mode, if supported by the system. Also, open the file using the binary-compatible character encoding "ISO-8859-1", ignoring the default port encoding. ‘+’ Open the port for both input and output. E.g., ‘r+’: open an existing file for both input and output. ‘e’ Mark the underlying file descriptor as close-on-exec, as per the ‘O_CLOEXEC’ flag. ‘0’ Create an "unbuffered" port. In this case input and output operations are passed directly to the underlying port implementation without additional buffering. This is likely to slow down I/O operations. The buffering mode can be changed while a port is in use (*note Buffering::). ‘l’ Add line-buffering to the port. The port output buffer will be automatically flushed whenever a newline character is written. ‘b’ Use binary mode, ensuring that each byte in the file will be read as one Scheme character. To provide this property, the file will be opened with the 8-bit character encoding "ISO-8859-1", ignoring the default port encoding. *Note Ports::, for more information on port encodings. Note that while it is possible to read and write binary data as characters or strings, it is usually better to treat bytes as octets, and byte sequences as bytevectors. *Note Binary I/O::, for more. This option had another historical meaning, for DOS compatibility: in the default (textual) mode, DOS reads a CR-LF sequence as one LF byte. The ‘b’ flag prevents this from happening, adding ‘O_BINARY’ to the underlying ‘open’ call. Still, the flag is generally useful because of its port encoding ramifications. Unless binary mode is requested, the character encoding of the new port is determined as follows: First, if GUESS-ENCODING is true, the ‘file-encoding’ procedure is used to guess the encoding of the file (*note Character Encoding of Source Files::). If GUESS-ENCODING is false or if ‘file-encoding’ fails, ENCODING is used unless it is also false. As a last resort, the default port encoding is used. *Note Ports::, for more information on port encodings. It is an error to pass a non-false GUESS-ENCODING or ENCODING if binary mode is requested. If a file cannot be opened with the access requested, ‘open-file’ throws an exception. -- Scheme Procedure: open-input-file filename [#:guess-encoding=#f] [#:encoding=#f] [#:binary=#f] Open FILENAME for input. If BINARY is true, open the port in binary mode, otherwise use text mode. ENCODING and GUESS-ENCODING determine the character encoding as described above for ‘open-file’. Equivalent to (open-file FILENAME (if BINARY "rb" "r") #:guess-encoding GUESS-ENCODING #:encoding ENCODING) -- Scheme Procedure: open-output-file filename [#:encoding=#f] [#:binary=#f] Open FILENAME for output. If BINARY is true, open the port in binary mode, otherwise use text mode. ENCODING specifies the character encoding as described above for ‘open-file’. Equivalent to (open-file FILENAME (if BINARY "wb" "w") #:encoding ENCODING) -- Scheme Procedure: call-with-input-file filename proc [#:guess-encoding=#f] [#:encoding=#f] [#:binary=#f] -- Scheme Procedure: call-with-output-file filename proc [#:encoding=#f] [#:binary=#f] Open FILENAME for input or output, and call ‘(PROC port)’ with the resulting port. Return the value returned by PROC. FILENAME is opened as per ‘open-input-file’ or ‘open-output-file’ respectively, and an error is signaled if it cannot be opened. When PROC returns, the port is closed. If PROC does not return (e.g. if it throws an error), then the port might not be closed automatically, though it will be garbage collected in the usual way if not otherwise referenced. -- Scheme Procedure: with-input-from-file filename thunk [#:guess-encoding=#f] [#:encoding=#f] [#:binary=#f] -- Scheme Procedure: with-output-to-file filename thunk [#:encoding=#f] [#:binary=#f] -- Scheme Procedure: with-error-to-file filename thunk [#:encoding=#f] [#:binary=#f] Open FILENAME and call ‘(THUNK)’ with the new port setup as respectively the ‘current-input-port’, ‘current-output-port’, or ‘current-error-port’. Return the value returned by THUNK. FILENAME is opened as per ‘open-input-file’ or ‘open-output-file’ respectively, and an error is signaled if it cannot be opened. When THUNK returns, the port is closed and the previous setting of the respective current port is restored. The current port setting is managed with ‘dynamic-wind’, so the previous value is restored no matter how THUNK exits (eg. an exception), and if THUNK is re-entered (via a captured continuation) then it's set again to the FILENAME port. The port is closed when THUNK returns normally, but not when exited via an exception or new continuation. This ensures it's still ready for use if THUNK is re-entered by a captured continuation. Of course the port is always garbage collected and closed in the usual way when no longer referenced anywhere. -- Scheme Procedure: port-mode port -- C Function: scm_port_mode (port) Return the port modes associated with the open port PORT. These will not necessarily be identical to the modes used when the port was opened, since modes such as "append" which are used only during port creation are not retained. -- Scheme Procedure: port-filename port -- C Function: scm_port_filename (port) Return the filename associated with PORT, or ‘#f’ if no filename is associated with the port. PORT must be open; ‘port-filename’ cannot be used once the port is closed. -- Scheme Procedure: set-port-filename! port filename -- C Function: scm_set_port_filename_x (port, filename) Change the filename associated with PORT, using the current input port if none is specified. Note that this does not change the port's source of data, but only the value that is returned by ‘port-filename’ and reported in diagnostic output. -- Scheme Procedure: file-port? obj -- C Function: scm_file_port_p (obj) Determine whether OBJ is a port that is related to a file. 6.12.10.2 Bytevector Ports .......................... -- Scheme Procedure: open-bytevector-input-port bv [transcoder] -- C Function: scm_open_bytevector_input_port (bv, transcoder) Return an input port whose contents are drawn from bytevector BV (*note Bytevectors::). The TRANSCODER argument is currently not supported. -- Scheme Procedure: open-bytevector-output-port [transcoder] -- C Function: scm_open_bytevector_output_port (transcoder) Return two values: a binary output port and a procedure. The latter should be called with zero arguments to obtain a bytevector containing the data accumulated by the port, as illustrated below. (call-with-values (lambda () (open-bytevector-output-port)) (lambda (port get-bytevector) (display "hello" port) (get-bytevector))) ⇒ #vu8(104 101 108 108 111) The TRANSCODER argument is currently not supported. -- Scheme Procedure: call-with-output-bytevector proc Call the one-argument procedure PROC with a newly created bytevector output port. When the function returns, the bytevector composed of the characters written into the port is returned. PROC should not close the port. -- Scheme Procedure: call-with-input-bytevector bytevector proc Call the one-argument procedure PROC with a newly created input port from which BYTEVECTOR's contents may be read. The values yielded by the PROC is returned. 6.12.10.3 String Ports ...................... -- Scheme Procedure: call-with-output-string proc -- C Function: scm_call_with_output_string (proc) Calls the one-argument procedure PROC with a newly created output port. When the function returns, the string composed of the characters written into the port is returned. PROC should not close the port. -- Scheme Procedure: call-with-input-string string proc -- C Function: scm_call_with_input_string (string, proc) Calls the one-argument procedure PROC with a newly created input port from which STRING's contents may be read. The value yielded by the PROC is returned. -- Scheme Procedure: with-output-to-string thunk Calls the zero-argument procedure THUNK with the current output port set temporarily to a new string port. It returns a string composed of the characters written to the current output. -- Scheme Procedure: with-input-from-string string thunk Calls the zero-argument procedure THUNK with the current input port set temporarily to a string port opened on the specified STRING. The value yielded by THUNK is returned. -- Scheme Procedure: open-input-string str -- C Function: scm_open_input_string (str) Take a string and return an input port that delivers characters from the string. The port can be closed by ‘close-input-port’, though its storage will be reclaimed by the garbage collector if it becomes inaccessible. -- Scheme Procedure: open-output-string -- C Function: scm_open_output_string () Return an output port that will accumulate characters for retrieval by ‘get-output-string’. The port can be closed by the procedure ‘close-output-port’, though its storage will be reclaimed by the garbage collector if it becomes inaccessible. -- Scheme Procedure: get-output-string port -- C Function: scm_get_output_string (port) Given an output port created by ‘open-output-string’, return a string consisting of the characters that have been output to the port so far. ‘get-output-string’ must be used before closing PORT, once closed the string cannot be obtained. With string ports, the port-encoding is treated differently than other types of ports. When string ports are created, they do not inherit a character encoding from the current locale. They are given a default locale that allows them to handle all valid string characters. Typically one should not modify a string port's character encoding away from its default. *Note Encoding::. 6.12.10.4 Custom Ports ...................... Custom ports allow the user to provide input and handle output via user-supplied procedures. The most basic of these operates on the level of bytes, calling user-supplied functions to supply bytes for input and accept bytes for output. In Guile, textual ports are built on top of binary ports, encoding and decoding their codepoint sequences from the bytes; the higher-level textual layer for custom ports allows users to deal in characters instead of bytes. Before using these procedures, import the appropriate module: (use-modules (ice-9 binary-ports)) (use-modules (ice-9 textual-ports)) -- Scheme Procedure: make-custom-binary-input-port id read! get-position set-position! close Return a new custom binary input port named ID (a string) whose input is drained by invoking READ! and passing it a bytevector, an index where bytes should be written, and the number of bytes to read. The ‘read!’ procedure must return an integer indicating the number of bytes read, or ‘0’ to indicate the end-of-file. Optionally, if GET-POSITION is not ‘#f’, it must be a thunk that will be called when ‘port-position’ is invoked on the custom binary port and should return an integer indicating the position within the underlying data stream; if GET-POSITION was not supplied, the returned port does not support ‘port-position’. Likewise, if SET-POSITION! is not ‘#f’, it should be a one-argument procedure. When ‘set-port-position!’ is invoked on the custom binary input port, SET-POSITION! is passed an integer indicating the position of the next byte is to read. Finally, if CLOSE is not ‘#f’, it must be a thunk. It is invoked when the custom binary input port is closed. The returned port is fully buffered by default, but its buffering mode can be changed using ‘setvbuf’ (*note Buffering::). Using a custom binary input port, the ‘open-bytevector-input-port’ procedure (*note Bytevector Ports::) could be implemented as follows: (define (open-bytevector-input-port source) (define position 0) (define length (bytevector-length source)) (define (read! bv start count) (let ((count (min count (- length position)))) (bytevector-copy! source position bv start count) (set! position (+ position count)) count)) (define (get-position) position) (define (set-position! new-position) (set! position new-position)) (make-custom-binary-input-port "the port" read! get-position set-position! #f)) (read (open-bytevector-input-port (string->utf8 "hello"))) ⇒ hello -- Scheme Procedure: make-custom-binary-output-port id write! get-position set-position! close Return a new custom binary output port named ID (a string) whose output is sunk by invoking WRITE! and passing it a bytevector, an index where bytes should be read from this bytevector, and the number of bytes to be "written". The ‘write!’ procedure must return an integer indicating the number of bytes actually written; when it is passed ‘0’ as the number of bytes to write, it should behave as though an end-of-file was sent to the byte sink. The other arguments are as for ‘make-custom-binary-input-port’. -- Scheme Procedure: make-custom-binary-input/output-port id read! write! get-position set-position! close Return a new custom binary input/output port named ID (a string). The various arguments are the same as for The other arguments are as for ‘make-custom-binary-input-port’ and ‘make-custom-binary-output-port’. If buffering is enabled on the port, as is the case by default, input will be buffered in both directions; *Note Buffering::. If the SET-POSITION! function is provided and not ‘#f’, then the port will also be marked as random-access, causing the buffer to be flushed between reads and writes. -- Scheme Procedure: make-custom-textual-input-port id read! get-position set-position! close -- Scheme Procedure: make-custom-textual-output-port id write! get-position set-position! close -- Scheme Procedure: make-custom-textual-input/output-port id read! write! get-position set-position! close Like their custom binary port counterparts, but for textual ports. Concretely this means that instead of being passed a bytevector, the READ function is passed a mutable string to fill, and likewise for the buffer supplied to WRITE. Port positions are still expressed in bytes, however. If string ports were not supplied with Guile, we could implement them With custom textual ports: (define (open-string-input-port source) (define position 0) (define length (string-length source)) (define (read! dst start count) (let ((count (min count (- length position)))) (string-copy! dst start source position (+ position count)) (set! position (+ position count)) count)) (make-custom-textual-input-port "strport" read! #f #f #f)) (read (open-string-input-port "hello")) 6.12.10.5 Soft Ports .................... Soft ports are what Guile had before it had custom binary and textual ports, and allow for customizable textual input and output. We recommend soft ports over R6RS custom textual ports because they are easier to use while also being more expressive. R6RS custom textual ports operate under the principle that a port has a mutable string buffer, and this is reflected in the ‘read’ and ‘write’ procedures which take a buffer, offset, and length. However in Guile as all ports have a byte buffer rather than some having a string buffer, the R6RS interface imposes overhead and complexity. Additionally, and unlike the R6RS interfaces, ‘make-soft-port’ from the ‘(ice-9 soft-ports)’ module accepts keyword arguments, allowing for its functionality to be extended over time. If you find yourself needing more power, notably the ability to seek, probably you want to use low-level custom ports. *Note Low-Level Custom Ports::. (use-modules (ice-9 soft-ports)) -- Scheme Procedure: make-soft-port [#:id] [#:read-string] [#:write-string] [#:input-waiting?] [#:close] [#:close-on-gc?] Return a new port. If the READ-STRING keyword argument is present, the port will be an input port. If WRITE-STRING is present, the port will be an output port. If both are supplied, the port will be open for input and output. When the port's internal buffers are empty, READ-STRING will be called with no arguments, and should return a string, or ‘#f’ to indicate end-of-stream. Similarly when a port flushes its write buffer, the characters in that buffer will be passed to the WRITE-STRING procedure as its single argument. WRITE-STRING returns unspecified values. If supplied, INPUT-WAITING? should return ‘#t’ if the soft port has input which would be returned directly by READ-STRING. If supplied, CLOSE will be called when the port is closed, with no arguments. If CLOSE-ON-GC? is ‘#t’, CLOSE will additionally be called when the port becomes unreachable, after flushing any pending write buffers. With soft ports, the ‘open-string-input-port’ example from the previous section is more simple: (define (open-string-input-port source) (define already-read? #f) (define (read-string) (cond (already-read? "") (else (set! already-read? #t) source))) (make-soft-port #:id "strport" #:read-string read-string)) Note that there was an earlier form of ‘make-soft-port’ which was exposed in Guile's default environment, and which is still there. Its interface is more clumsy and its users historically expect unbuffered input. This interface will be deprecated, but we document it here. -- Scheme Procedure: deprecated-make-soft-port pv modes Return a port capable of receiving or delivering characters as specified by the MODES string (*note open-file: File Ports.). PV must be a vector of length 5 or 6. Its components are as follows: 0. procedure accepting one character for output 1. procedure accepting a string for output 2. thunk for flushing output 3. thunk for getting one character 4. thunk for closing port (not by garbage collection) 5. (if present and not ‘#f’) thunk for computing the number of characters that can be read from the port without blocking. For an output-only port only elements 0, 1, 2, and 4 need be procedures. For an input-only port only elements 3 and 4 need be procedures. Thunks 2 and 4 can instead be ‘#f’ if there is no useful operation for them to perform. If thunk 3 returns ‘#f’ or an ‘eof-object’ (*note eof-object?: (r5rs)Input.) it indicates that the port has reached end-of-file. For example: (define stdout (current-output-port)) (define p (deprecated-make-soft-port (vector (lambda (c) (write c stdout)) (lambda (s) (display s stdout)) (lambda () (display "." stdout)) (lambda () (char-upcase (read-char))) (lambda () (display "@" stdout))) "rw")) (write p p) ⇒ # 6.12.10.6 Void Ports .................... This kind of port causes any data to be discarded when written to, and always returns the end-of-file object when read from. -- Scheme Procedure: %make-void-port mode -- C Function: scm_sys_make_void_port (mode) Create and return a new void port. A void port acts like ‘/dev/null’. The MODE argument specifies the input/output modes for this port: see the documentation for ‘open-file’ in *note File Ports::. 6.12.10.7 Low-Level Custom Ports ................................ This section describes how to implement a new kind of port using Guile's lowest-level, most primitive interfaces. First, load the ‘(ice-9 custom-ports)’ module: (use-modules (ice-9 custom-ports)) Then to make a new port, call ‘make-custom-port’: -- Scheme Procedure: make-custom-port [#:read] [#:write] [#:read-wait-fd] [#:write-wait-fd] [#:input-waiting?] [#:seek] [#:random-access?] [#:get-natural-buffer-sizes] [#:id] [#:print] [#:close] [#:close-on-gc?] [#:truncate] [#:encoding] [#:conversion-strategy] Make a new custom port. *Note Encoding::, for more on ‘#:encoding’ and ‘#:conversion-strategy’. A port has a number of associated procedures and properties which collectively implement its behavior. Creating a new custom port mostly involves writing these procedures, which are passed as keyword arguments to ‘make-custom-port’. -- Scheme Port Method: #:read port dst start count A port's ‘#:read’ implementation fills read buffers. It should copy bytes to the supplied bytevector DST, starting at offset START and continuing for COUNT bytes, and return the number of bytes that were read, or ‘#f’ to indicate that reading any bytes would block. -- Scheme Port Method: #:write port src start count A port's ‘#:write’ implementation flushes write buffers to the mutable store. It should write out bytes from the supplied bytevector SRC, starting at offset START and continuing for COUNT bytes, and return the number of bytes that were written, or ‘#f’ to indicate writing any bytes would block. If ‘make-custom-port’ is passed a ‘#:read’ argument, the port will be an input port. Passing a ‘#:write’ argument will make an output port, and passing both will make an input-output port. -- Scheme Port Method: #:read-wait-fd port -- Scheme Port Method: #:write-wait-fd port If a port's ‘#:read’ or ‘#:write’ method returns ‘#f’, that indicates that reading or writing would block, and that Guile should instead ‘poll’ on the file descriptor returned by the port's ‘#:read-wait-fd’ or ‘#:write-wait-fd’ method, respectively, until the operation can complete. *Note Non-Blocking I/O::, for a more in-depth discussion. These methods must be implemented if the ‘#:read’ or ‘#:write’ method can return ‘#f’, and should return a non-negative integer file descriptor. However they may be called explicitly by a user, for example to determine if a port may eventually be readable or writable. If there is no associated file descriptor with the port, they should return ‘#f’. The default implementation returns ‘#f’. -- Scheme Port Method: #:input-waiting? port In rare cases it is useful to be able to know whether data can be read from a port. For example, if the user inputs ‘1 2 3’ at the interactive console, after reading and evaluating ‘1’ the console shouldn't then print another prompt before reading and evaluating ‘2’ because there is input already waiting. If the port can look ahead, then it should implement the ‘#:input-waiting?’ method, which returns ‘#t’ if input is available, or ‘#f’ reading the next byte would block. The default implementation returns ‘#t’. -- Scheme Port Method: #:seek port offset whence Set or get the current byte position of the port. Guile will flush read and/or write buffers before seeking, as appropriate. The OFFSET and WHENCE parameters are as for the ‘seek’ procedure; *Note Random Access::. The ‘#:seek’ method returns the byte position after seeking. To query the current position, ‘#:seek’ will be called with an OFFSET of 0 and ‘SEEK_CUR’ for WHENCE. Other values of OFFSET and/or WHENCE will actually perform the seek. The ‘#:seek’ method should throw an error if the port is not seekable, which is what the default implementation does. -- Scheme Port Method: #:truncate port Truncate the port data to be specified length. Guile will flush buffers beforehand, as appropriate. The default implementation throws an error, indicating that truncation is not supported for this port. -- Scheme Port Method: #:random-access? port Return ‘#t’ if PORT is open for random access, or ‘#f’ otherwise. Seeking on a random-access port with buffered input, or switching to writing after reading, will cause the buffered input to be discarded and Guile will seek the port back the buffered number of bytes. Likewise seeking on a random-access port with buffered output, or switching to reading after writing, will flush pending bytes with a call to the ‘write’ procedure. *Note Buffering::. Indicate to Guile that your port needs this behavior by returning true from your ‘#:random-access?’ method. The default implementation of this function returns ‘#t’ if the port has a ‘#:seek’ implementation. -- Scheme Port Method: #:get-natural-buffer-sizes read-buf-size write-buf-size Guile will internally attach buffers to ports. An input port always has a read buffer, and an output port always has a write buffer. *Note Buffering::. A port buffer consists of a bytevector, along with some cursors into that bytevector denoting where to get and put data. Port implementations generally don't have to be concerned with buffering: a port's ‘#:read’ or ‘#:write’ method will receive the buffer's bytevector as an argument, along with an offset and a length into that bytevector, and should then either fill or empty that bytevector. However in some cases, port implementations may be able to provide an appropriate default buffer size to Guile. For example file ports implement ‘#:get-natural-buffer-sizes’ to let the operating system inform Guile about the appropriate buffer sizes for the particular file opened by the port. This method returns two values, corresponding to the natural read and write buffer sizes for the ports. The two parameters READ-BUF-SIZE and WRITE-BUF-SIZE are Guile's guesses for what sizes might be good. A custom ‘#:get-natural-buffer-sizes’ method could override Guile's choices, or just pass them on, as the default implementation does. -- Scheme Port Method: #:print port out Called when the port PORT is written to OUT, e.g. via ‘(write port out)’. If ‘#:print’ is not explicitly supplied, the default implementation prints something like ‘#’, where MODE is either ‘input’, ‘output’, or ‘input-output’, ID comes from the ‘#:id’ keyword argument (defaulting to ‘"custom-port"’), and ADDRESS is a unique integer associated with the port. -- Scheme Port Method: #:close port Called when PORT is closed. It should release any explicitly-managed resources used by the port. By default, ports that are garbage collected just go away without closing or flushing any buffered output. If your port needs to release some external resource like a file descriptor, or needs to make sure that its internal buffers are flushed even if the port is collected while it was open, then pass ‘#:close-on-gc? #t’ to ‘make-custom-port’. Note that in that case, the ‘#:close’ method will probably be called on a separate thread. Note that calls to all of these methods can proceed in parallel and concurrently and from any thread up until the point that the port is closed. The call to ‘close’ will happen when no other method is running, and no method will be called after the ‘close’ method is called. If your port implementation needs mutual exclusion to prevent concurrency, it is responsible for locking appropriately. 6.12.10.8 Low-Level Custom Ports in C ..................................... The ‘make-custom-port’ procedure described in the previous section has similar functionality on the C level, though it is organized a bit differently. In C, the mechanism is that one creates a new “port type object”. The methods are then associated with the port type object instead of the port itself. The port type object is an opaque pointer allocated when defining the port type, which serves as a key into the port API. Ports themselves have associated “stream” values. The stream is a pointer controlled by the user, which is set when the port is created. Given a port, the ‘SCM_STREAM’ macro returns its associated stream value, as a ‘scm_t_bits’. Note that your port methods are only ever called with ports of your type, so port methods can safely cast this value to the expected type. Contrast this to Scheme, which doesn't need access to the stream because the ‘make-custom-port’ methods can be closures that share port-specific data directly. A port type is created by calling ‘scm_make_port_type’. -- Function: scm_t_port_type* scm_make_port_type (char *name, size_t (*read) (SCM port, SCM dst, size_t start, size_t count), size_t (*write) (SCM port, SCM src, size_t start, size_t count)) Define a new port type. The NAME parameter is like the ‘#:id’ parameter to ‘make-custom-port’; and READ and WRITE are like ‘make-custom-port’'s ‘#:read’ and ‘#:write’, except that they should return ‘(size_t)-1’ if the read or write operation would block, instead of ‘#f’. -- Function: void scm_set_port_read_wait_fd (scm_t_port_type *type, int (*wait_fd) (SCM port)) -- Function: void scm_set_port_write_wait_fd (scm_t_port_type *type, int (*wait_fd) (SCM port)) -- Function: void scm_set_port_print (scm_t_port_type *type, int (*print) (SCM port, SCM dest_port, scm_print_state *pstate)) -- Function: void scm_set_port_close (scm_t_port_type *type, void (*close) (SCM port)) -- Function: void scm_set_port_needs_close_on_gc (scm_t_port_type *type, int needs_close_p) -- Function: void scm_set_port_seek (scm_t_port_type *type, scm_t_off (*seek) (SCM port, scm_t_off offset, int whence)) -- Function: void scm_set_port_truncate (scm_t_port_type *type, void (*truncate) (SCM port, scm_t_off length)) -- Function: void scm_set_port_random_access_p (scm_t_port_type *type, int (*random_access_p) (SCM port)); -- Function: void scm_set_port_input_waiting (scm_t_port_type *type, int (*input_waiting) (SCM port)); -- Function: void scm_set_port_get_natural_buffer_sizes (scm_t_port_type *type, void (*get_natural_buffer_sizes) (SCM, size_t *read_buf_size, size_t *write_buf_size)) Port method definitions. *Note Low-Level Custom Ports::, for more details on each of these methods. Once you have your port type, you can create ports with ‘scm_c_make_port’, or ‘scm_c_make_port_with_encoding’. -- Function: SCM scm_c_make_port_with_encoding (scm_t_port_type *type, unsigned long mode_bits, SCM encoding, SCM conversion_strategy, scm_t_bits stream) -- Function: SCM scm_c_make_port (scm_t_port_type *type, unsigned long mode_bits, scm_t_bits stream) Make a port with the given TYPE. The STREAM indicates the private data associated with the port, which your port implementation may later retrieve with ‘SCM_STREAM’. The mode bits should include one or more of the flags ‘SCM_RDNG’ or ‘SCM_WRTNG’, indicating that the port is an input and/or an output port, respectively. The mode bits may also include ‘SCM_BUF0’ or ‘SCM_BUFLINE’, indicating that the port should be unbuffered or line-buffered, respectively. The default is that the port will be block-buffered. *Note Buffering::. As you would imagine, ENCODING and CONVERSION_STRATEGY specify the port's initial textual encoding and conversion strategy. Both are symbols. ‘scm_c_make_port’ is the same as ‘scm_c_make_port_with_encoding’, except it uses the default port encoding and conversion strategy. At this point you may be wondering whether to implement your custom port type in C or Scheme. The answer is that probably you want to use Scheme's ‘make-custom-port’. The speed is similar between C and Scheme, and ports implemented in C have the disadvantage of not being suspendable. *Note Non-Blocking I/O::. 6.12.11 Venerable Port Interfaces --------------------------------- Over the 25 years or so that Guile has been around, its port system has evolved, adding many useful features. At the same time there have been four major Scheme standards released in those 25 years, which also evolve the common Scheme understanding of what a port interface should be. Alas, it would be too much to ask for all of these evolutionary branches to be consistent. Some of Guile's original interfaces don't mesh with the later Scheme standards, and yet Guile can't just drop old interfaces. Sadly as well, the R6RS and R7RS standards both part from a base of R5RS, but end up in different and somewhat incompatible designs. Guile's approach is to pick a set of port primitives that make sense together. We document that set of primitives, design our internal interfaces around them, and recommend them to users. As the R6RS I/O system is the most capable standard that Scheme has yet produced in this domain, we mostly recommend that; ‘(ice-9 binary-ports)’ and ‘(ice-9 textual-ports)’ are wholly modeled on ‘(rnrs io ports)’. Guile does not wholly copy R6RS, however; *Note R6RS Incompatibilities::. At the same time, we have many venerable port interfaces, lore handed down to us from our hacker ancestors. Most of these interfaces even predate the expectation that Scheme should have modules, so they are present in the default environment. In Guile we support them as well and we have no plans to remove them, but again we don't recommend them for new users. -- Scheme Procedure: char-ready? [port] Return ‘#t’ if a character is ready on input PORT and return ‘#f’ otherwise. If ‘char-ready?’ returns ‘#t’ then the next ‘read-char’ operation on PORT is guaranteed not to hang. If PORT is a file port at end of file then ‘char-ready?’ returns ‘#t’. ‘char-ready?’ exists to make it possible for a program to accept characters from interactive ports without getting stuck waiting for input. Any input editors associated with such ports must make sure that characters whose existence has been asserted by ‘char-ready?’ cannot be rubbed out. If ‘char-ready?’ were to return ‘#f’ at end of file, a port at end of file would be indistinguishable from an interactive port that has no ready characters. Note that ‘char-ready?’ only works reliably for terminals and sockets with one-byte encodings. Under the hood it will return ‘#t’ if the port has any input buffered, or if the file descriptor that backs the port polls as readable, indicating that Guile can fetch more bytes from the kernel. However being able to fetch one byte doesn't mean that a full character is available; *Note Encoding::. Also, on many systems it's possible for a file descriptor to poll as readable, but then block when it comes time to read bytes. Note also that on Linux kernels, all file ports backed by files always poll as readable. For non-file ports, this procedure always returns ‘#t’, except for soft ports, which have a ‘char-ready?’ handler. *Note Soft Ports::. In short, this is a legacy procedure whose semantics are hard to provide. However it is a useful check to see if any input is buffered. *Note Non-Blocking I/O::. -- Scheme Procedure: read-char [port] The same as ‘get-char’, except that PORT defaults to the current input port. *Note Textual I/O::. -- Scheme Procedure: peek-char [port] The same as ‘lookahead-char’, except that PORT defaults to the current input port. *Note Textual I/O::. -- Scheme Procedure: unread-char cobj [port] The same as ‘unget-char’, except that PORT defaults to the current input port, and the arguments are swapped. *Note Textual I/O::. -- Scheme Procedure: unread-string str [port] -- C Function: scm_unread_string (str, port) The same as ‘unget-string’, except that PORT defaults to the current input port, and the arguments are swapped. *Note Textual I/O::. -- Scheme Procedure: newline [port] Send a newline to PORT. If PORT is omitted, send to the current output port. Equivalent to ‘(put-char port #\newline)’. -- Scheme Procedure: write-char chr [port] The same as ‘put-char’, except that PORT defaults to the current input port, and the arguments are swapped. *Note Textual I/O::. 6.12.12 Using Ports from C -------------------------- Guile's C interfaces provides some niceties for sending and receiving bytes and characters in a way that works better with C. -- C Function: size_t scm_c_read (SCM port, void *buffer, size_t size) Read up to SIZE bytes from PORT and store them in BUFFER. The return value is the number of bytes actually read, which can be less than SIZE if end-of-file has been reached. Note that as this is a binary input procedure, this function does not update ‘port-line’ and ‘port-column’ (*note Textual I/O::). -- C Function: void scm_c_write (SCM port, const void *buffer, size_t size) Write SIZE bytes at BUFFER to PORT. Note that as this is a binary output procedure, this function does not update ‘port-line’ and ‘port-column’ (*note Textual I/O::). -- C Function: size_t scm_c_read_bytes (SCM port, SCM bv, size_t start, size_t count) -- C Function: void scm_c_write_bytes (SCM port, SCM bv, size_t start, size_t count) Like ‘scm_c_read’ and ‘scm_c_write’, but reading into or writing from the bytevector BV. COUNT indicates the byte index at which to start in the bytevector, and the read or write will continue for COUNT bytes. -- C Function: void scm_unget_bytes (const unsigned char *buf, size_t len, SCM port) -- C Function: void scm_unget_byte (int c, SCM port) -- C Function: void scm_ungetc (scm_t_wchar c, SCM port) Like ‘unget-bytevector’, ‘unget-byte’, and ‘unget-char’, respectively. *Note Textual I/O::. -- C Function: void scm_c_put_latin1_chars (SCM port, const scm_t_uint8 *buf, size_t len) -- C Function: void scm_c_put_utf32_chars (SCM port, const scm_t_uint32 *buf, size_t len); Write a string to PORT. In the first case, the ‘scm_t_uint8*’ buffer is a string in the latin-1 encoding. In the second, the ‘scm_t_uint32*’ buffer is a string in the UTF-32 encoding. These routines will update the port's line and column. 6.12.13 Non-Blocking I/O ------------------------ Most ports in Guile are “blocking”: when you try to read a character from a port, Guile will block on the read until a character is ready, or end-of-stream is detected. Likewise whenever Guile goes to write (possibly buffered) data to an output port, Guile will block until all the data is written. Interacting with ports in blocking mode is very convenient: you can write straightforward, sequential algorithms whose code flow reflects the flow of data. However, blocking I/O has two main limitations. The first is that it's easy to get into a situation where code is waiting on data. Time spent waiting on data when code could be doing something else is wasteful and prevents your program from reaching its peak throughput. If you implement a web server that sequentially handles requests from clients, it's very easy for the server to end up waiting on a client to finish its HTTP request, or waiting on it to consume the response. The end result is that you are able to serve fewer requests per second than you'd like to serve. The second limitation is related: a blocking parser over user-controlled input is a denial-of-service vulnerability. Indeed the so-called "slow loris" attack of the early 2010s was just that: an attack on common web servers that drip-fed HTTP requests, one character at a time. All it took was a handful of slow loris connections to occupy an entire web server. In Guile we would like to preserve the ability to write straightforward blocking networking processes of all kinds, but under the hood to allow those processes to suspend their requests if they would block. To do this, the first piece is to allow Guile ports to declare themselves as being nonblocking. This is currently supported only for file ports, which also includes sockets, terminals, or any other port that is backed by a file descriptor. To do that, we use an arcane UNIX incantation: (let ((flags (fcntl socket F_GETFL))) (fcntl socket F_SETFL (logior O_NONBLOCK flags))) Now the file descriptor is open in non-blocking mode. If Guile tries to read or write from this file and the read or write returns a result indicating that more data can only be had by doing a blocking read or write, Guile will block by polling on the socket's ‘read-wait-fd’ or ‘write-wait-fd’, to preserve the illusion of a blocking read or write. *Note Low-Level Custom Ports:: for more on those internal interfaces. So far we have just reproduced the status quo: the file descriptor is non-blocking, but the operations on the port do block. To go farther, it would be nice if we could suspend the "thread" using delimited continuations, and only resume the thread once the file descriptor is readable or writable. (*Note Prompts::). But here we run into a difficulty. The ports code is implemented in C, which means that although we can suspend the computation to some outer prompt, we can't resume it because Guile can't resume delimited continuations that capture the C stack. To overcome this difficulty we have created a compatible but entirely parallel implementation of port operations. To use this implementation, do the following: (use-modules (ice-9 suspendable-ports)) (install-suspendable-ports!) This will replace the core I/O primitives like ‘get-char’ and ‘put-bytevector’ with new versions that are exactly the same as the ones in the standard library, but with two differences. One is that when a read or a write would block, the suspendable port operations call out the value of the ‘current-read-waiter’ or ‘current-write-waiter’ parameter, as appropriate. *Note Parameters::. The default read and write waiters do the same thing that the C read and write waiters do, which is to poll. User code can parameterize the waiters, though, enabling the computation to suspend and allow the program to process other I/O operations. Because the new suspendable ports implementation is written in Scheme, that suspended computation can resume again later when it is able to make progress. Success! The other main difference is that because the new ports implementation is written in Scheme, it is slower than C, currently by a factor of 3 or 4, though it depends on many factors. For this reason we have to keep the C implementations as the default ones. One day when Guile's compiler is better, we can close this gap and have only one port operation implementation again. Note that Guile does not currently include an implementation of the facility to suspend the current thread and schedule other threads in the meantime. Before adding such a thing, we want to make sure that we're providing the right primitives that can be used to build schedulers and other user-space concurrency patterns, and that the patterns that we settle on are the right patterns. In the meantime, have a look at 8sync () for a prototype of an asynchronous I/O and concurrency facility. -- Scheme Procedure: install-suspendable-ports! Replace the core ports implementation with suspendable ports, as described above. This will mutate the values of the bindings like ‘get-char’, ‘put-u8’, and so on in place. -- Scheme Procedure: uninstall-suspendable-ports! Restore the original core ports implementation, un-doing the effect of ‘install-suspendable-ports!’. -- Scheme Parameter: current-read-waiter -- Scheme Parameter: current-write-waiter Parameters whose values are procedures of one argument, called when a suspendable port operation would block on a port while reading or writing, respectively. The default values of these parameters do a blocking ‘poll’ on the port's file descriptor. The procedures are passed the port in question as their one argument. 6.12.14 Handling of Unicode Byte Order Marks -------------------------------------------- This section documents the finer points of Guile's handling of Unicode byte order marks (BOMs). A byte order mark (U+FEFF) is typically found at the start of a UTF-16 or UTF-32 stream, to allow readers to reliably determine the byte order. Occasionally, a BOM is found at the start of a UTF-8 stream, but this is much less common and not generally recommended. Guile attempts to handle BOMs automatically, and in accordance with the recommendations of the Unicode Standard, when the port encoding is set to ‘UTF-8’, ‘UTF-16’, or ‘UTF-32’. In brief, Guile automatically writes a BOM at the start of a UTF-16 or UTF-32 stream, and automatically consumes one from the start of a UTF-8, UTF-16, or UTF-32 stream. As specified in the Unicode Standard, a BOM is only handled specially at the start of a stream, and only if the port encoding is set to ‘UTF-8’, ‘UTF-16’ or ‘UTF-32’. If the port encoding is set to ‘UTF-16BE’, ‘UTF-16LE’, ‘UTF-32BE’, or ‘UTF-32LE’, then BOMs are _not_ handled specially, and none of the special handling described in this section applies. • To ensure that Guile will properly detect the byte order of a UTF-16 or UTF-32 stream, you must perform a textual read before any writes, seeks, or binary I/O. Guile will not attempt to read a BOM unless a read is explicitly requested at the start of the stream. • If a textual write is performed before the first read, then an arbitrary byte order will be chosen. Currently, big endian is the default on all platforms, but that may change in the future. If you wish to explicitly control the byte order of an output stream, set the port encoding to ‘UTF-16BE’, ‘UTF-16LE’, ‘UTF-32BE’, or ‘UTF-32LE’, and explicitly write a BOM (‘#\xFEFF’) if desired. • If ‘set-port-encoding!’ is called in the middle of a stream, Guile treats this as a new logical "start of stream" for purposes of BOM handling, and will forget about any BOMs that had previously been seen. Therefore, it may choose a different byte order than had been used previously. This is intended to support multiple logical text streams embedded within a larger binary stream. • Binary I/O operations are not guaranteed to update Guile's notion of whether the port is at the "start of the stream", nor are they guaranteed to produce or consume BOMs. • For ports that support seeking (e.g. normal files), the input and output streams are considered linked: if the user reads first, then a BOM will be consumed (if appropriate), but later writes will _not_ produce a BOM. Similarly, if the user writes first, then later reads will _not_ consume a BOM. • For ports that are not random access (e.g. pipes, sockets, and terminals), the input and output streams are considered _independent_ for purposes of BOM handling: the first read will consume a BOM (if appropriate), and the first write will _also_ produce a BOM (if appropriate). However, the input and output streams will always use the same byte order. • Seeks to the beginning of a file will set the "start of stream" flags. Therefore, a subsequent textual read or write will consume or produce a BOM. However, unlike ‘set-port-encoding!’, if a byte order had already been chosen for the port, it will remain in effect after a seek, and cannot be changed by the presence of a BOM. Seeks anywhere other than the beginning of a file clear the "start of stream" flags. 6.13 Regular Expressions ======================== A “regular expression” (or “regexp”) is a pattern that describes a whole class of strings. A full description of regular expressions and their syntax is beyond the scope of this manual. If your system does not include a POSIX regular expression library, and you have not linked Guile with a third-party regexp library such as Rx, these functions will not be available. You can tell whether your Guile installation includes regular expression support by checking whether ‘(provided? 'regex)’ returns true. The following regexp and string matching features are provided by the ‘(ice-9 regex)’ module. Before using the described functions, you should load this module by executing ‘(use-modules (ice-9 regex))’. 6.13.1 Regexp Functions ----------------------- By default, Guile supports POSIX extended regular expressions. That means that the characters ‘(’, ‘)’, ‘+’ and ‘?’ are special, and must be escaped if you wish to match the literal characters and there is no support for "non-greedy" variants of ‘*’, ‘+’ or ‘?’. This regular expression interface was modeled after that implemented by SCSH, the Scheme Shell. It is intended to be upwardly compatible with SCSH regular expressions. Zero bytes (‘#\nul’) cannot be used in regex patterns or input strings, since the underlying C functions treat that as the end of string. If there's a zero byte an error is thrown. Internally, patterns and input strings are converted to the current locale's encoding, and then passed to the C library's regular expression routines (*note (libc)Regular Expressions::). The returned match structures always point to characters in the strings, not to individual bytes, even in the case of multi-byte encodings. This ensures that the match structures are correct when performing matching with characters that have a multi-byte representation in the locale encoding. Note, however, that using characters which cannot be represented in the locale encoding can lead to surprising results. -- Scheme Procedure: string-match pattern str [start] Compile the string PATTERN into a regular expression and compare it with STR. The optional numeric argument START specifies the position of STR at which to begin matching. ‘string-match’ returns a “match structure” which describes what, if anything, was matched by the regular expression. *Note Match Structures::. If STR does not match PATTERN at all, ‘string-match’ returns ‘#f’. Two examples of a match follow. In the first example, the pattern matches the four digits in the match string. In the second, the pattern matches nothing. (string-match "[0-9][0-9][0-9][0-9]" "blah2002") ⇒ #("blah2002" (4 . 8)) (string-match "[A-Za-z]" "123456") ⇒ #f Each time ‘string-match’ is called, it must compile its PATTERN argument into a regular expression structure. This operation is expensive, which makes ‘string-match’ inefficient if the same regular expression is used several times (for example, in a loop). For better performance, you can compile a regular expression in advance and then match strings against the compiled regexp. -- Scheme Procedure: make-regexp pat flag... -- C Function: scm_make_regexp (pat, flaglst) Compile the regular expression described by PAT, and return the compiled regexp structure. If PAT does not describe a legal regular expression, ‘make-regexp’ throws a ‘regular-expression-syntax’ error. The FLAG arguments change the behavior of the compiled regular expression. The following values may be supplied: -- Variable: regexp/icase Consider uppercase and lowercase letters to be the same when matching. -- Variable: regexp/newline If a newline appears in the target string, then permit the ‘^’ and ‘$’ operators to match immediately after or immediately before the newline, respectively. Also, the ‘.’ and ‘[^...]’ operators will never match a newline character. The intent of this flag is to treat the target string as a buffer containing many lines of text, and the regular expression as a pattern that may match a single one of those lines. -- Variable: regexp/basic Compile a basic ("obsolete") regexp instead of the extended ("modern") regexps that are the default. Basic regexps do not consider ‘|’, ‘+’ or ‘?’ to be special characters, and require the ‘{...}’ and ‘(...)’ metacharacters to be backslash-escaped (*note Backslash Escapes::). There are several other differences between basic and extended regular expressions, but these are the most significant. -- Variable: regexp/extended Compile an extended regular expression rather than a basic regexp. This is the default behavior; this flag will not usually be needed. If a call to ‘make-regexp’ includes both ‘regexp/basic’ and ‘regexp/extended’ flags, the one which comes last will override the earlier one. -- Scheme Procedure: regexp-exec rx str [start [flags]] -- C Function: scm_regexp_exec (rx, str, start, flags) Match the compiled regular expression RX against ‘str’. If the optional integer START argument is provided, begin matching from that position in the string. Return a match structure describing the results of the match, or ‘#f’ if no match could be found. The FLAGS argument changes the matching behavior. The following flag values may be supplied, use ‘logior’ (*note Bitwise Operations::) to combine them, -- Variable: regexp/notbol Consider that the START offset into STR is not the beginning of a line and should not match operator ‘^’. If RX was created with the ‘regexp/newline’ option above, ‘^’ will still match after a newline in STR. -- Variable: regexp/noteol Consider that the end of STR is not the end of a line and should not match operator ‘$’. If RX was created with the ‘regexp/newline’ option above, ‘$’ will still match before a newline in STR. ;; Regexp to match uppercase letters (define r (make-regexp "[A-Z]*")) ;; Regexp to match letters, ignoring case (define ri (make-regexp "[A-Z]*" regexp/icase)) ;; Search for bob using regexp r (match:substring (regexp-exec r "bob")) ⇒ "" ; no match ;; Search for bob using regexp ri (match:substring (regexp-exec ri "Bob")) ⇒ "Bob" ; matched case insensitive -- Scheme Procedure: regexp? obj -- C Function: scm_regexp_p (obj) Return ‘#t’ if OBJ is a compiled regular expression, or ‘#f’ otherwise. -- Scheme Procedure: list-matches regexp str [flags] Return a list of match structures which are the non-overlapping matches of REGEXP in STR. REGEXP can be either a pattern string or a compiled regexp. The FLAGS argument is as per ‘regexp-exec’ above. (map match:substring (list-matches "[a-z]+" "abc 42 def 78")) ⇒ ("abc" "def") -- Scheme Procedure: fold-matches regexp str init proc [flags] Apply PROC to the non-overlapping matches of REGEXP in STR, to build a result. REGEXP can be either a pattern string or a compiled regexp. The FLAGS argument is as per ‘regexp-exec’ above. PROC is called as ‘(PROC match prev)’ where MATCH is a match structure and PREV is the previous return from PROC. For the first call PREV is the given INIT parameter. ‘fold-matches’ returns the final value from PROC. For example to count matches, (fold-matches "[a-z][0-9]" "abc x1 def y2" 0 (lambda (match count) (1+ count))) ⇒ 2 Regular expressions are commonly used to find patterns in one string and replace them with the contents of another string. The following functions are convenient ways to do this. -- Scheme Procedure: regexp-substitute port match item ... Write to PORT selected parts of the match structure MATCH. Or if PORT is ‘#f’ then form a string from those parts and return that. Each ITEM specifies a part to be written, and may be one of the following, • A string. String arguments are written out verbatim. • An integer. The submatch with that number is written (‘match:substring’). Zero is the entire match. • The symbol ‘pre’. The portion of the matched string preceding the regexp match is written (‘match:prefix’). • The symbol ‘post’. The portion of the matched string following the regexp match is written (‘match:suffix’). For example, changing a match and retaining the text before and after, (regexp-substitute #f (string-match "[0-9]+" "number 25 is good") 'pre "37" 'post) ⇒ "number 37 is good" Or matching a YYYYMMDD format date such as ‘20020828’ and re-ordering and hyphenating the fields. (define date-regex "([0-9][0-9][0-9][0-9])([0-9][0-9])([0-9][0-9])") (define s "Date 20020429 12am.") (regexp-substitute #f (string-match date-regex s) 'pre 2 "-" 3 "-" 1 'post " (" 0 ")") ⇒ "Date 04-29-2002 12am. (20020429)" -- Scheme Procedure: regexp-substitute/global port regexp target item... Write to PORT selected parts of matches of REGEXP in TARGET. If PORT is ‘#f’ then form a string from those parts and return that. REGEXP can be a string or a compiled regex. This is similar to ‘regexp-substitute’, but allows global substitutions on TARGET. Each ITEM behaves as per ‘regexp-substitute’, with the following differences, • A function. Called as ‘(ITEM match)’ with the match structure for the REGEXP match, it should return a string to be written to PORT. • The symbol ‘post’. This doesn't output anything, but instead causes ‘regexp-substitute/global’ to recurse on the unmatched portion of TARGET. This _must_ be supplied to perform a global search and replace on TARGET; without it ‘regexp-substitute/global’ returns after a single match and output. For example, to collapse runs of tabs and spaces to a single hyphen each, (regexp-substitute/global #f "[ \t]+" "this is the text" 'pre "-" 'post) ⇒ "this-is-the-text" Or using a function to reverse the letters in each word, (regexp-substitute/global #f "[a-z]+" "to do and not-do" 'pre (lambda (m) (string-reverse (match:substring m))) 'post) ⇒ "ot od dna ton-od" Without the ‘post’ symbol, just one regexp match is made. For example the following is the date example from ‘regexp-substitute’ above, without the need for the separate ‘string-match’ call. (define date-regex "([0-9][0-9][0-9][0-9])([0-9][0-9])([0-9][0-9])") (define s "Date 20020429 12am.") (regexp-substitute/global #f date-regex s 'pre 2 "-" 3 "-" 1 'post " (" 0 ")") ⇒ "Date 04-29-2002 12am. (20020429)" 6.13.2 Match Structures ----------------------- A “match structure” is the object returned by ‘string-match’ and ‘regexp-exec’. It describes which portion of a string, if any, matched the given regular expression. Match structures include: a reference to the string that was checked for matches; the starting and ending positions of the regexp match; and, if the regexp included any parenthesized subexpressions, the starting and ending positions of each submatch. In each of the regexp match functions described below, the ‘match’ argument must be a match structure returned by a previous call to ‘string-match’ or ‘regexp-exec’. Most of these functions return some information about the original target string that was matched against a regular expression; we will call that string TARGET for easy reference. -- Scheme Procedure: regexp-match? obj Return ‘#t’ if OBJ is a match structure returned by a previous call to ‘regexp-exec’, or ‘#f’ otherwise. -- Scheme Procedure: match:substring match [n] Return the portion of TARGET matched by subexpression number N. Submatch 0 (the default) represents the entire regexp match. If the regular expression as a whole matched, but the subexpression number N did not match, return ‘#f’. (define s (string-match "[0-9][0-9][0-9][0-9]" "blah2002foo")) (match:substring s) ⇒ "2002" ;; match starting at offset 6 in the string (match:substring (string-match "[0-9][0-9][0-9][0-9]" "blah987654" 6)) ⇒ "7654" -- Scheme Procedure: match:start match [n] Return the starting position of submatch number N. In the following example, the result is 4, since the match starts at character index 4: (define s (string-match "[0-9][0-9][0-9][0-9]" "blah2002foo")) (match:start s) ⇒ 4 -- Scheme Procedure: match:end match [n] Return the ending position of submatch number N. In the following example, the result is 8, since the match runs between characters 4 and 8 (i.e. the "2002"). (define s (string-match "[0-9][0-9][0-9][0-9]" "blah2002foo")) (match:end s) ⇒ 8 -- Scheme Procedure: match:prefix match Return the unmatched portion of TARGET preceding the regexp match. (define s (string-match "[0-9][0-9][0-9][0-9]" "blah2002foo")) (match:prefix s) ⇒ "blah" -- Scheme Procedure: match:suffix match Return the unmatched portion of TARGET following the regexp match. (define s (string-match "[0-9][0-9][0-9][0-9]" "blah2002foo")) (match:suffix s) ⇒ "foo" -- Scheme Procedure: match:count match Return the number of parenthesized subexpressions from MATCH. Note that the entire regular expression match itself counts as a subexpression, and failed submatches are included in the count. -- Scheme Procedure: match:string match Return the original TARGET string. (define s (string-match "[0-9][0-9][0-9][0-9]" "blah2002foo")) (match:string s) ⇒ "blah2002foo" 6.13.3 Backslash Escapes ------------------------ Sometimes you will want a regexp to match characters like ‘*’ or ‘$’ exactly. For example, to check whether a particular string represents a menu entry from an Info node, it would be useful to match it against a regexp like ‘^* [^:]*::’. However, this won't work; because the asterisk is a metacharacter, it won't match the ‘*’ at the beginning of the string. In this case, we want to make the first asterisk un-magic. You can do this by preceding the metacharacter with a backslash character ‘\’. (This is also called “quoting” the metacharacter, and is known as a “backslash escape”.) When Guile sees a backslash in a regular expression, it considers the following glyph to be an ordinary character, no matter what special meaning it would ordinarily have. Therefore, we can make the above example work by changing the regexp to ‘^\* [^:]*::’. The ‘\*’ sequence tells the regular expression engine to match only a single asterisk in the target string. Since the backslash is itself a metacharacter, you may force a regexp to match a backslash in the target string by preceding the backslash with itself. For example, to find variable references in a TeX program, you might want to find occurrences of the string ‘\let\’ followed by any number of alphabetic characters. The regular expression ‘\\let\\[A-Za-z]*’ would do this: the double backslashes in the regexp each match a single backslash in the target string. -- Scheme Procedure: regexp-quote str Quote each special character found in STR with a backslash, and return the resulting string. *Very important:* Using backslash escapes in Guile source code (as in Emacs Lisp or C) can be tricky, because the backslash character has special meaning for the Guile reader. For example, if Guile encounters the character sequence ‘\n’ in the middle of a string while processing Scheme code, it replaces those characters with a newline character. Similarly, the character sequence ‘\t’ is replaced by a horizontal tab. Several of these “escape sequences” are processed by the Guile reader before your code is executed. Unrecognized escape sequences are ignored: if the characters ‘\*’ appear in a string, they will be translated to the single character ‘*’. This translation is obviously undesirable for regular expressions, since we want to be able to include backslashes in a string in order to escape regexp metacharacters. Therefore, to make sure that a backslash is preserved in a string in your Guile program, you must use _two_ consecutive backslashes: (define Info-menu-entry-pattern (make-regexp "^\\* [^:]*")) The string in this example is preprocessed by the Guile reader before any code is executed. The resulting argument to ‘make-regexp’ is the string ‘^\* [^:]*’, which is what we really want. This also means that in order to write a regular expression that matches a single backslash character, the regular expression string in the source code must include _four_ backslashes. Each consecutive pair of backslashes gets translated by the Guile reader to a single backslash, and the resulting double-backslash is interpreted by the regexp engine as matching a single backslash character. Hence: (define tex-variable-pattern (make-regexp "\\\\let\\\\=[A-Za-z]*")) The reason for the unwieldiness of this syntax is historical. Both regular expression pattern matchers and Unix string processing systems have traditionally used backslashes with the special meanings described above. The POSIX regular expression specification and ANSI C standard both require these semantics. Attempting to abandon either convention would cause other kinds of compatibility problems, possibly more severe ones. Therefore, without extending the Scheme reader to support strings with different quoting conventions (an ungainly and confusing extension when implemented in other languages), we must adhere to this cumbersome escape syntax. 6.14 LALR(1) Parsing ==================== The ‘(system base lalr)’ module provides the ‘lalr-scm’ LALR(1) parser generator by Dominique Boucher (https://github.com/schemeway/lalr-scm/). ‘lalr-scm’ uses the same algorithm as GNU Bison (*note Introduction to Bison: (bison)Introduction.). Parsers are defined using the ‘lalr-parser’ macro. -- Scheme Syntax: lalr-parser [OPTIONS] TOKENS RULES... Generate an LALR(1) syntax analyzer. TOKENS is a list of symbols representing the terminal symbols of the grammar. RULES are the grammar production rules. Each rule has the form ‘(NON-TERMINAL (RHS ...) : ACTION ...)’, where NON-TERMINAL is the name of the rule, RHS are the right-hand sides, i.e., the production rule, and ACTION is a semantic action associated with the rule. The generated parser is a two-argument procedure that takes a “tokenizer” and a “syntax error procedure”. The tokenizer should be a thunk that returns lexical tokens as produced by ‘make-lexical-token’. The syntax error procedure may be called with at least an error message (a string), and optionally the lexical token that caused the error. Please refer to the ‘lalr-scm’ documentation for details. 6.15 PEG Parsing ================ Parsing Expression Grammars (PEGs) are a way of specifying formal languages for text processing. They can be used either for matching (like regular expressions) or for building recursive descent parsers (like lex/yacc). Guile uses a superset of PEG syntax that allows more control over what information is preserved during parsing. Wikipedia has a clear and concise introduction to PEGs if you want to familiarize yourself with the syntax: . The ‘(ice-9 peg)’ module works by compiling PEGs down to lambda expressions. These can either be stored in variables at compile-time by the define macros (‘define-peg-pattern’ and ‘define-peg-string-patterns’) or calculated explicitly at runtime with the compile functions (‘compile-peg-pattern’ and ‘peg-string-compile’). They can then be used for either parsing (‘match-pattern’) or searching (‘search-for-pattern’). For convenience, ‘search-for-pattern’ also takes pattern literals in case you want to inline a simple search (people often use regular expressions this way). The rest of this documentation consists of a syntax reference, an API reference, and a tutorial. 6.15.1 PEG Syntax Reference --------------------------- Normal PEG Syntax: .................. -- PEG Pattern: sequence a b Parses A. If this succeeds, continues to parse B from the end of the text parsed as A. Succeeds if both A and B succeed. ‘"a b"’ ‘(and a b)’ -- PEG Pattern: ordered choice a b Parses A. If this fails, backtracks and parses B. Succeeds if either A or B succeeds. ‘"a/b"’ ‘(or a b)’ -- PEG Pattern: zero or more a Parses A as many times in a row as it can, starting each A at the end of the text parsed by the previous A. Always succeeds. ‘"a*"’ ‘(* a)’ -- PEG Pattern: one or more a Parses A as many times in a row as it can, starting each A at the end of the text parsed by the previous A. Succeeds if at least one A was parsed. ‘"a+"’ ‘(+ a)’ -- PEG Pattern: optional a Tries to parse A. Succeeds if A succeeds. ‘"a?"’ ‘(? a)’ -- PEG Pattern: followed by a Makes sure it is possible to parse A, but does not actually parse it. Succeeds if A would succeed. ‘"&a"’ ‘(followed-by a)’ -- PEG Pattern: not followed by a Makes sure it is impossible to parse A, but does not actually parse it. Succeeds if A would fail. ‘"!a"’ ‘(not-followed-by a)’ -- PEG Pattern: string literal ``abc'' Parses the string "ABC". Succeeds if that parsing succeeds. ‘"'abc'"’ ‘"abc"’ -- PEG Pattern: any character Parses any single character. Succeeds unless there is no more text to be parsed. ‘"."’ ‘peg-any’ -- PEG Pattern: character class a b Alternative syntax for "Ordered Choice A B" if A and B are characters. ‘"[ab]"’ ‘(or "a" "b")’ -- PEG Pattern: range of characters a z Parses any character falling between A and Z. ‘"[a-z]"’ ‘(range #\a #\z)’ Example: "(a !b / c &d*) 'e'+" Would be: (and (or (and a (not-followed-by b)) (and c (followed-by (* d)))) (+ "e")) Extended Syntax ............... There is some extra syntax for S-expressions. -- PEG Pattern: ignore a Ignore the text matching A -- PEG Pattern: capture a Capture the text matching A. -- PEG Pattern: peg a Embed the PEG pattern A using string syntax. Example: "!a / 'b'" Is equivalent to (or (peg "!a") "b") and (or (not-followed-by a) "b") 6.15.2 PEG API Reference ------------------------ Define Macros ............. The most straightforward way to define a PEG is by using one of the define macros (both of these macroexpand into ‘define’ expressions). These macros bind parsing functions to variables. These parsing functions may be invoked by ‘match-pattern’ or ‘search-for-pattern’, which return a PEG match record. Raw data can be retrieved from this record with the PEG match deconstructor functions. More complicated (and perhaps enlightening) examples can be found in the tutorial. -- Scheme Macro: define-peg-string-patterns peg-string Defines all the nonterminals in the PEG PEG-STRING. More precisely, ‘define-peg-string-patterns’ takes a superset of PEGs. A normal PEG has a ‘<-’ between the nonterminal and the pattern. ‘define-peg-string-patterns’ uses this symbol to determine what information it should propagate up the parse tree. The normal ‘<-’ propagates the matched text up the parse tree, ‘<--’ propagates the matched text up the parse tree tagged with the name of the nonterminal, and ‘<’ discards that matched text and propagates nothing up the parse tree. Also, nonterminals may consist of any alphanumeric character or a "-" character (in normal PEGs nonterminals can only be alphabetic). For example, if we: (define-peg-string-patterns "as <- 'a'+ bs <- 'b'+ as-or-bs <- as/bs") (define-peg-string-patterns "as-tag <-- 'a'+ bs-tag <-- 'b'+ as-or-bs-tag <-- as-tag/bs-tag") Then: (match-pattern as-or-bs "aabbcc") ⇒ # (match-pattern as-or-bs-tag "aabbcc") ⇒ # Note that in doing this, we have bound 6 variables at the toplevel (AS, BS, AS-OR-BS, AS-TAG, BS-TAG, and AS-OR-BS-TAG). -- Scheme Macro: define-peg-pattern name capture-type peg-sexp Defines a single nonterminal NAME. CAPTURE-TYPE determines how much information is passed up the parse tree. PEG-SEXP is a PEG in S-expression form. Possible values for capture-type: ‘all’ passes the matched text up the parse tree tagged with the name of the nonterminal. ‘body’ passes the matched text up the parse tree. ‘none’ passes nothing up the parse tree. For Example, if we: (define-peg-pattern as body (+ "a")) (define-peg-pattern bs body (+ "b")) (define-peg-pattern as-or-bs body (or as bs)) (define-peg-pattern as-tag all (+ "a")) (define-peg-pattern bs-tag all (+ "b")) (define-peg-pattern as-or-bs-tag all (or as-tag bs-tag)) Then: (match-pattern as-or-bs "aabbcc") ⇒ # (match-pattern as-or-bs-tag "aabbcc") ⇒ # Note that in doing this, we have bound 6 variables at the toplevel (AS, BS, AS-OR-BS, AS-TAG, BS-TAG, and AS-OR-BS-TAG). Compile Functions ................. It is sometimes useful to be able to compile anonymous PEG patterns at runtime. These functions let you do that using either syntax. -- Scheme Procedure: peg-string-compile peg-string capture-type Compiles the PEG pattern in PEG-STRING propagating according to CAPTURE-TYPE (capture-type can be any of the values from ‘define-peg-pattern’). -- Scheme Procedure: compile-peg-pattern peg-sexp capture-type Compiles the PEG pattern in PEG-SEXP propagating according to CAPTURE-TYPE (capture-type can be any of the values from ‘define-peg-pattern’). The functions return syntax objects, which can be useful if you want to use them in macros. If all you want is to define a new nonterminal, you can do the following: (define exp '(+ "a")) (define as (compile (compile-peg-pattern exp 'body))) You can use this nonterminal with all of the regular PEG functions: (match-pattern as "aaaaa") ⇒ # Parsing & Matching Functions ............................ For our purposes, "parsing" means parsing a string into a tree starting from the first character, while "matching" means searching through the string for a substring. In practice, the only difference between the two functions is that ‘match-pattern’ gives up if it can't find a valid substring starting at index 0 and ‘search-for-pattern’ keeps looking. They are both equally capable of "parsing" and "matching" given those constraints. -- Scheme Procedure: match-pattern nonterm string Parses STRING using the PEG stored in NONTERM. If no match was found, ‘match-pattern’ returns false. If a match was found, a PEG match record is returned. The ‘capture-type’ argument to ‘define-peg-pattern’ allows you to choose what information to hold on to while parsing. The options are: ‘all’ tag the matched text with the nonterminal ‘body’ just the matched text ‘none’ nothing (define-peg-pattern as all (+ "a")) (match-pattern as "aabbcc") ⇒ # (define-peg-pattern as body (+ "a")) (match-pattern as "aabbcc") ⇒ # (define-peg-pattern as none (+ "a")) (match-pattern as "aabbcc") ⇒ # (define-peg-pattern bs body (+ "b")) (match-pattern bs "aabbcc") ⇒ #f -- Scheme Macro: search-for-pattern nonterm-or-peg string Searches through STRING looking for a matching subexpression. NONTERM-OR-PEG can either be a nonterminal or a literal PEG pattern. When a literal PEG pattern is provided, ‘search-for-pattern’ works very similarly to the regular expression searches many hackers are used to. If no match was found, ‘search-for-pattern’ returns false. If a match was found, a PEG match record is returned. (define-peg-pattern as body (+ "a")) (search-for-pattern as "aabbcc") ⇒ # (search-for-pattern (+ "a") "aabbcc") ⇒ # (search-for-pattern "'a'+" "aabbcc") ⇒ # (define-peg-pattern as all (+ "a")) (search-for-pattern as "aabbcc") ⇒ # (define-peg-pattern bs body (+ "b")) (search-for-pattern bs "aabbcc") ⇒ # (search-for-pattern (+ "b") "aabbcc") ⇒ # (search-for-pattern "'b'+" "aabbcc") ⇒ # (define-peg-pattern zs body (+ "z")) (search-for-pattern zs "aabbcc") ⇒ #f (search-for-pattern (+ "z") "aabbcc") ⇒ #f (search-for-pattern "'z'+" "aabbcc") ⇒ #f PEG Match Records ................. The ‘match-pattern’ and ‘search-for-pattern’ functions both return PEG match records. Actual information can be extracted from these with the following functions. -- Scheme Procedure: peg:string match-record Returns the original string that was parsed in the creation of ‘match-record’. -- Scheme Procedure: peg:start match-record Returns the index of the first parsed character in the original string (from ‘peg:string’). If this is the same as ‘peg:end’, nothing was parsed. -- Scheme Procedure: peg:end match-record Returns one more than the index of the last parsed character in the original string (from ‘peg:string’). If this is the same as ‘peg:start’, nothing was parsed. -- Scheme Procedure: peg:substring match-record Returns the substring parsed by ‘match-record’. This is equivalent to ‘(substring (peg:string match-record) (peg:start match-record) (peg:end match-record))’. -- Scheme Procedure: peg:tree match-record Returns the tree parsed by ‘match-record’. -- Scheme Procedure: peg-record? match-record Returns true if ‘match-record’ is a PEG match record, or false otherwise. Example: (define-peg-pattern bs all (peg "'b'+")) (search-for-pattern bs "aabbcc") ⇒ # (let ((pm (search-for-pattern bs "aabbcc"))) `((string ,(peg:string pm)) (start ,(peg:start pm)) (end ,(peg:end pm)) (substring ,(peg:substring pm)) (tree ,(peg:tree pm)) (record? ,(peg-record? pm)))) ⇒ ((string "aabbcc") (start 2) (end 4) (substring "bb") (tree (bs "bb")) (record? #t)) Miscellaneous ............. -- Scheme Procedure: context-flatten tst lst Takes a predicate TST and a list LST. Flattens LST until all elements are either atoms or satisfy TST. If LST itself satisfies TST, ‘(list lst)’ is returned (this is a flat list whose only element satisfies TST). (context-flatten (lambda (x) (and (number? (car x)) (= (car x) 1))) '(2 2 (1 1 (2 2)) (2 2 (1 1)))) ⇒ (2 2 (1 1 (2 2)) 2 2 (1 1)) (context-flatten (lambda (x) (and (number? (car x)) (= (car x) 1))) '(1 1 (1 1 (2 2)) (2 2 (1 1)))) ⇒ ((1 1 (1 1 (2 2)) (2 2 (1 1)))) If you're wondering why this is here, take a look at the tutorial. -- Scheme Procedure: keyword-flatten terms lst A less general form of ‘context-flatten’. Takes a list of terminal atoms ‘terms’ and flattens LST until all elements are either atoms, or lists which have an atom from ‘terms’ as their first element. (keyword-flatten '(a b) '(c a b (a c) (b c) (c (b a) (c a)))) ⇒ (c a b (a c) (b c) c (b a) c a) If you're wondering why this is here, take a look at the tutorial. 6.15.3 PEG Tutorial ------------------- Parsing /etc/passwd ................... This example will show how to parse /etc/passwd using PEGs. First we define an example /etc/passwd file: (define *etc-passwd* "root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh nobody:x:65534:65534:nobody:/nonexistent:/bin/sh messagebus:x:103:107::/var/run/dbus:/bin/false ") As a first pass at this, we might want to have all the entries in /etc/passwd in a list. Doing this with string-based PEG syntax would look like this: (define-peg-string-patterns "passwd <- entry* !. entry <-- (! NL .)* NL* NL < '\n'") A ‘passwd’ file is 0 or more entries (‘entry*’) until the end of the file (‘!.’ (‘.’ is any character, so ‘!.’ means "not anything")). We want to capture the data in the nonterminal ‘passwd’, but not tag it with the name, so we use ‘<-’. An entry is a series of 0 or more characters that aren't newlines (‘(! NL .)*’) followed by 0 or more newlines (‘NL*’). We want to tag all the entries with ‘entry’, so we use ‘<--’. A newline is just a literal newline (‘'\n'’). We don't want a bunch of newlines cluttering up the output, so we use ‘<’ to throw away the captured data. Here is the same PEG defined using S-expressions: (define-peg-pattern passwd body (and (* entry) (not-followed-by peg-any))) (define-peg-pattern entry all (and (* (and (not-followed-by NL) peg-any)) (* NL))) (define-peg-pattern NL none "\n") Obviously this is much more verbose. On the other hand, it's more explicit, and thus easier to build automatically. However, there are some tricks that make S-expressions easier to use in some cases. One is the ‘ignore’ keyword; the string syntax has no way to say "throw away this text" except breaking it out into a separate nonterminal. For instance, to throw away the newlines we had to define ‘NL’. In the S-expression syntax, we could have simply written ‘(ignore "\n")’. Also, for the cases where string syntax is really much cleaner, the ‘peg’ keyword can be used to embed string syntax in S-expression syntax. For instance, we could have written: (define-peg-pattern passwd body (peg "entry* !.")) However we define it, parsing ‘*etc-passwd*’ with the ‘passwd’ nonterminal yields the same results: (peg:tree (match-pattern passwd *etc-passwd*)) ⇒ ((entry "root:x:0:0:root:/root:/bin/bash") (entry "daemon:x:1:1:daemon:/usr/sbin:/bin/sh") (entry "bin:x:2:2:bin:/bin:/bin/sh") (entry "sys:x:3:3:sys:/dev:/bin/sh") (entry "nobody:x:65534:65534:nobody:/nonexistent:/bin/sh") (entry "messagebus:x:103:107::/var/run/dbus:/bin/false")) However, here is something to be wary of: (peg:tree (match-pattern passwd "one entry")) ⇒ (entry "one entry") By default, the parse trees generated by PEGs are compressed as much as possible without losing information. It may not look like this is what you want at first, but uncompressed parse trees are an enormous headache (there's no easy way to predict how deep particular lists will nest, there are empty lists littered everywhere, etc. etc.). One side-effect of this, however, is that sometimes the compressor is too aggressive. No information is discarded when ‘((entry "one entry"))’ is compressed to ‘(entry "one entry")’, but in this particular case it probably isn't what we want. There are two functions for easily dealing with this: ‘keyword-flatten’ and ‘context-flatten’. The ‘keyword-flatten’ function takes a list of keywords and a list to flatten, then tries to coerce the list such that the first element of all sublists is one of the keywords. The ‘context-flatten’ function is similar, but instead of a list of keywords it takes a predicate that should indicate whether a given sublist is good enough (refer to the API reference for more details). What we want here is ‘keyword-flatten’. (keyword-flatten '(entry) (peg:tree (match-pattern passwd *etc-passwd*))) ⇒ ((entry "root:x:0:0:root:/root:/bin/bash") (entry "daemon:x:1:1:daemon:/usr/sbin:/bin/sh") (entry "bin:x:2:2:bin:/bin:/bin/sh") (entry "sys:x:3:3:sys:/dev:/bin/sh") (entry "nobody:x:65534:65534:nobody:/nonexistent:/bin/sh") (entry "messagebus:x:103:107::/var/run/dbus:/bin/false")) (keyword-flatten '(entry) (peg:tree (match-pattern passwd "one entry"))) ⇒ ((entry "one entry")) Of course, this is a somewhat contrived example. In practice we would probably just tag the ‘passwd’ nonterminal to remove the ambiguity (using either the ‘all’ keyword for S-expressions or the ‘<--’ symbol for strings).. (define-peg-pattern tag-passwd all (peg "entry* !.")) (peg:tree (match-pattern tag-passwd *etc-passwd*)) ⇒ (tag-passwd (entry "root:x:0:0:root:/root:/bin/bash") (entry "daemon:x:1:1:daemon:/usr/sbin:/bin/sh") (entry "bin:x:2:2:bin:/bin:/bin/sh") (entry "sys:x:3:3:sys:/dev:/bin/sh") (entry "nobody:x:65534:65534:nobody:/nonexistent:/bin/sh") (entry "messagebus:x:103:107::/var/run/dbus:/bin/false")) (peg:tree (match-pattern tag-passwd "one entry")) (tag-passwd (entry "one entry")) If you're ever uncertain about the potential results of parsing something, remember the two absolute rules: 1. No parsing information will ever be discarded. 2. There will never be any lists with fewer than 2 elements. For the purposes of (1), "parsing information" means things tagged with the ‘any’ keyword or the ‘<--’ symbol. Plain strings will be concatenated. Let's extend this example a bit more and actually pull some useful information out of the passwd file: (define-peg-string-patterns "passwd <-- entry* !. entry <-- login C pass C uid C gid C nameORcomment C homedir C shell NL* login <-- text pass <-- text uid <-- [0-9]* gid <-- [0-9]* nameORcomment <-- text homedir <-- path shell <-- path path <-- (SLASH pathELEMENT)* pathELEMENT <-- (!NL !C !'/' .)* text <- (!NL !C .)* C < ':' NL < '\n' SLASH < '/'") This produces rather pretty parse trees: (passwd (entry (login "root") (pass "x") (uid "0") (gid "0") (nameORcomment "root") (homedir (path (pathELEMENT "root"))) (shell (path (pathELEMENT "bin") (pathELEMENT "bash")))) (entry (login "daemon") (pass "x") (uid "1") (gid "1") (nameORcomment "daemon") (homedir (path (pathELEMENT "usr") (pathELEMENT "sbin"))) (shell (path (pathELEMENT "bin") (pathELEMENT "sh")))) (entry (login "bin") (pass "x") (uid "2") (gid "2") (nameORcomment "bin") (homedir (path (pathELEMENT "bin"))) (shell (path (pathELEMENT "bin") (pathELEMENT "sh")))) (entry (login "sys") (pass "x") (uid "3") (gid "3") (nameORcomment "sys") (homedir (path (pathELEMENT "dev"))) (shell (path (pathELEMENT "bin") (pathELEMENT "sh")))) (entry (login "nobody") (pass "x") (uid "65534") (gid "65534") (nameORcomment "nobody") (homedir (path (pathELEMENT "nonexistent"))) (shell (path (pathELEMENT "bin") (pathELEMENT "sh")))) (entry (login "messagebus") (pass "x") (uid "103") (gid "107") nameORcomment (homedir (path (pathELEMENT "var") (pathELEMENT "run") (pathELEMENT "dbus"))) (shell (path (pathELEMENT "bin") (pathELEMENT "false"))))) Notice that when there's no entry in a field (e.g. ‘nameORcomment’ for messagebus) the symbol is inserted. This is the "don't throw away any information" rule--we successfully matched a ‘nameORcomment’ of 0 characters (since we used ‘*’ when defining it). This is usually what you want, because it allows you to e.g. use ‘list-ref’ to pull out elements (since they all have known offsets). If you'd prefer not to have symbols for empty matches, you can replace the ‘*’ with a ‘+’ and add a ‘?’ after the ‘nameORcomment’ in ‘entry’. Then it will try to parse 1 or more characters, fail (inserting nothing into the parse tree), but continue because it didn't have to match the nameORcomment to continue. Embedding Arithmetic Expressions ................................ We can parse simple mathematical expressions with the following PEG: (define-peg-string-patterns "expr <- sum sum <-- (product ('+' / '-') sum) / product product <-- (value ('*' / '/') product) / value value <-- number / '(' expr ')' number <-- [0-9]+") Then: (peg:tree (match-pattern expr "1+1/2*3+(1+1)/2")) ⇒ (sum (product (value (number "1"))) "+" (sum (product (value (number "1")) "/" (product (value (number "2")) "*" (product (value (number "3"))))) "+" (sum (product (value "(" (sum (product (value (number "1"))) "+" (sum (product (value (number "1"))))) ")") "/" (product (value (number "2"))))))) There is very little wasted effort in this PEG. The ‘number’ nonterminal has to be tagged because otherwise the numbers might run together with the arithmetic expressions during the string concatenation stage of parse-tree compression (the parser will see "1" followed by "/" and decide to call it "1/"). When in doubt, tag. It is very easy to turn these parse trees into lisp expressions: (define (parse-sum sum left . rest) (if (null? rest) (apply parse-product left) (list (string->symbol (car rest)) (apply parse-product left) (apply parse-sum (cadr rest))))) (define (parse-product product left . rest) (if (null? rest) (apply parse-value left) (list (string->symbol (car rest)) (apply parse-value left) (apply parse-product (cadr rest))))) (define (parse-value value first . rest) (if (null? rest) (string->number (cadr first)) (apply parse-sum (car rest)))) (define parse-expr parse-sum) (Notice all these functions look very similar; for a more complicated PEG, it would be worth abstracting.) Then: (apply parse-expr (peg:tree (match-pattern expr "1+1/2*3+(1+1)/2"))) ⇒ (+ 1 (+ (/ 1 (* 2 3)) (/ (+ 1 1) 2))) But wait! The associativity is wrong! Where it says ‘(/ 1 (* 2 3))’, it should say ‘(* (/ 1 2) 3)’. It's tempting to try replacing e.g. ‘"sum <-- (product ('+' / '-') sum) / product"’ with ‘"sum <-- (sum ('+' / '-') product) / product"’, but this is a Bad Idea. PEGs don't support left recursion. To see why, imagine what the parser will do here. When it tries to parse ‘sum’, it first has to try and parse ‘sum’. But to do that, it first has to try and parse ‘sum’. This will continue until the stack gets blown off. So how does one parse left-associative binary operators with PEGs? Honestly, this is one of their major shortcomings. There's no general-purpose way of doing this, but here the repetition operators are a good choice: (use-modules (srfi srfi-1)) (define-peg-string-patterns "expr <- sum sum <-- (product ('+' / '-'))* product product <-- (value ('*' / '/'))* value value <-- number / '(' expr ')' number <-- [0-9]+") ;; take a deep breath... (define (make-left-parser next-func) (lambda (sum first . rest) ;; general form, comments below assume ;; that we're dealing with a sum expression (if (null? rest) ;; form (sum (product ...)) (apply next-func first) (if (string? (cadr first));; form (sum ((product ...) "+") (product ...)) (list (string->symbol (cadr first)) (apply next-func (car first)) (apply next-func (car rest))) ;; form (sum (((product ...) "+") ((product ...) "+")) (product ...)) (car (reduce ;; walk through the list and build a left-associative tree (lambda (l r) (list (list (cadr r) (car r) (apply next-func (car l))) (string->symbol (cadr l)))) 'ignore (append ;; make a list of all the products ;; the first one should be pre-parsed (list (list (apply next-func (caar first)) (string->symbol (cadar first)))) (cdr first) ;; the last one has to be added in (list (append rest '("done")))))))))) (define (parse-value value first . rest) (if (null? rest) (string->number (cadr first)) (apply parse-sum (car rest)))) (define parse-product (make-left-parser parse-value)) (define parse-sum (make-left-parser parse-product)) (define parse-expr parse-sum) Then: (apply parse-expr (peg:tree (match-pattern expr "1+1/2*3+(1+1)/2"))) ⇒ (+ (+ 1 (* (/ 1 2) 3)) (/ (+ 1 1) 2)) As you can see, this is much uglier (it could be made prettier by using ‘context-flatten’, but the way it's written above makes it clear how we deal with the three ways the zero-or-more ‘*’ expression can parse). Fortunately, most of the time we can get away with only using right-associativity. Simplified Functions .................... For a more tantalizing example, consider the following grammar that parses (highly) simplified C functions: (define-peg-string-patterns "cfunc <-- cSP ctype cSP cname cSP cargs cLB cSP cbody cRB ctype <-- cidentifier cname <-- cidentifier cargs <-- cLP (! (cSP cRP) carg cSP (cCOMMA / cRP) cSP)* cSP carg <-- cSP ctype cSP cname cbody <-- cstatement * cidentifier <- [a-zA-z][a-zA-Z0-9_]* cstatement <-- (!';'.)*cSC cSP cSC < ';' cCOMMA < ',' cLP < '(' cRP < ')' cLB < '{' cRB < '}' cSP < [ \t\n]*") Then: (match-pattern cfunc "int square(int a) { return a*a;}") ⇒ (32 (cfunc (ctype "int") (cname "square") (cargs (carg (ctype "int") (cname "a"))) (cbody (cstatement "return a*a")))) And: (match-pattern cfunc "int mod(int a, int b) { int c = a/b;return a-b*c; }") ⇒ (52 (cfunc (ctype "int") (cname "mod") (cargs (carg (ctype "int") (cname "a")) (carg (ctype "int") (cname "b"))) (cbody (cstatement "int c = a/b") (cstatement "return a- b*c")))) By wrapping all the ‘carg’ nonterminals in a ‘cargs’ nonterminal, we were able to remove any ambiguity in the parsing structure and avoid having to call ‘context-flatten’ on the output of ‘match-pattern’. We used the same trick with the ‘cstatement’ nonterminals, wrapping them in a ‘cbody’ nonterminal. The whitespace nonterminal ‘cSP’ used here is a (very) useful instantiation of a common pattern for matching syntactically irrelevant information. Since it's tagged with ‘<’ and ends with ‘*’ it won't clutter up the parse trees (all the empty lists will be discarded during the compression step) and it will never cause parsing to fail. 6.15.4 PEG Internals -------------------- A PEG parser takes a string as input and attempts to parse it as a given nonterminal. The key idea of the PEG implementation is that every nonterminal is just a function that takes a string as an argument and attempts to parse that string as its nonterminal. The functions always start from the beginning, but a parse is considered successful if there is material left over at the end. This makes it easy to model different PEG parsing operations. For instance, consider the PEG grammar ‘"ab"’, which could also be written ‘(and "a" "b")’. It matches the string "ab". Here's how that might be implemented in the PEG style: (define (match-and-a-b str) (match-a str) (match-b str)) As you can see, the use of functions provides an easy way to model sequencing. In a similar way, one could model ‘(or a b)’ with something like the following: (define (match-or-a-b str) (or (match-a str) (match-b str))) Here the semantics of a PEG ‘or’ expression map naturally onto Scheme's ‘or’ operator. This function will attempt to run ‘(match-a str)’, and return its result if it succeeds. Otherwise it will run ‘(match-b str)’. Of course, the code above wouldn't quite work. We need some way for the parsing functions to communicate. The actual interface used is below. Parsing Function Interface .......................... A parsing function takes three arguments - a string, the length of that string, and the position in that string it should start parsing at. In effect, the parsing functions pass around substrings in pieces - the first argument is a buffer of characters, and the second two give a range within that buffer that the parsing function should look at. Parsing functions return either #f, if they failed to match their nonterminal, or a list whose first element must be an integer representing the final position in the string they matched and whose cdr can be any other data the function wishes to return, or '() if it doesn't have any more data. The one caveat is that if the extra data it returns is a list, any adjacent strings in that list will be appended by ‘match-pattern’. For instance, if a parsing function returns ‘(13 ("a" "b" "c"))’, ‘match-pattern’ will take ‘(13 ("abc"))’ as its value. For example, here is a function to match "ab" using the actual interface. (define (match-a-b str len pos) (and (<= (+ pos 2) len) (string= str "ab" pos (+ pos 2)) (list (+ pos 2) '()))) ; we return no extra information The above function can be used to match a string by running ‘(match-pattern match-a-b "ab")’. Code Generators and Extensible Syntax ..................................... PEG expressions, such as those in a ‘define-peg-pattern’ form, are interpreted internally in two steps. First, any string PEG is expanded into an s-expression PEG by the code in the ‘(ice-9 peg string-peg)’ module. Then, the s-expression PEG that results is compiled into a parsing function by the ‘(ice-9 peg codegen)’ module. In particular, the function ‘compile-peg-pattern’ is called on the s-expression. It then decides what to do based on the form it is passed. The PEG syntax can be expanded by providing ‘compile-peg-pattern’ more options for what to do with its forms. The extended syntax will be associated with a symbol, for instance ‘my-parsing-form’, and will be called on all PEG expressions of the form (my-parsing-form ...) The parsing function should take two arguments. The first will be a syntax object containing a list with all of the arguments to the form (but not the form's name), and the second will be the ‘capture-type’ argument that is passed to ‘define-peg-pattern’. New functions can be registered by calling ‘(add-peg-compiler! symbol function)’, where ‘symbol’ is the symbol that will indicate a form of this type and ‘function’ is the code generating function described above. The function ‘add-peg-compiler!’ is exported from the ‘(ice-9 peg codegen)’ module. 6.16 Reading and Evaluating Scheme Code ======================================= This chapter describes Guile functions that are concerned with reading, loading, evaluating, and compiling Scheme code at run time. 6.16.1 Scheme Syntax: Standard and Guile Extensions --------------------------------------------------- 6.16.1.1 Expression Syntax .......................... An expression to be evaluated takes one of the following forms. SYMBOL A symbol is evaluated by dereferencing. A binding of that symbol is sought and the value there used. For example, (define x 123) x ⇒ 123 (PROC ARGS...) A parenthesized expression is a function call. PROC and each argument are evaluated, then the function (which PROC evaluated to) is called with those arguments. The order in which PROC and the arguments are evaluated is unspecified, so be careful when using expressions with side effects. (max 1 2 3) ⇒ 3 (define (get-some-proc) min) ((get-some-proc) 1 2 3) ⇒ 1 The same sort of parenthesized form is used for a macro invocation, but in that case the arguments are not evaluated. See the descriptions of macros for more on this (*note Macros::, and *note Syntax Rules::). CONSTANT Number, string, character and boolean constants evaluate "to themselves", so can appear as literals. 123 ⇒ 123 99.9 ⇒ 99.9 "hello" ⇒ "hello" #\z ⇒ #\z #t ⇒ #t Note that an application must not attempt to modify literal strings, since they may be in read-only memory. (quote DATA) 'DATA Quoting is used to obtain a literal symbol (instead of a variable reference), a literal list (instead of a function call), or a literal vector. ' is simply a shorthand for a ‘quote’ form. For example, 'x ⇒ x '(1 2 3) ⇒ (1 2 3) '#(1 (2 3) 4) ⇒ #(1 (2 3) 4) (quote x) ⇒ x (quote (1 2 3)) ⇒ (1 2 3) (quote #(1 (2 3) 4)) ⇒ #(1 (2 3) 4) Note that an application must not attempt to modify literal lists or vectors obtained from a ‘quote’ form, since they may be in read-only memory. (quasiquote DATA) 'DATA Backquote quasi-quotation is like ‘quote’, but selected sub-expressions are evaluated. This is a convenient way to construct a list or vector structure most of which is constant, but at certain points should have expressions substituted. The same effect can always be had with suitable ‘list’, ‘cons’ or ‘vector’ calls, but quasi-quoting is often easier. (unquote EXPR) ,EXPR Within the quasiquote DATA, ‘unquote’ or ‘,’ indicates an expression to be evaluated and inserted. The comma syntax ‘,’ is simply a shorthand for an ‘unquote’ form. For example, `(1 2 (* 9 9) 3 4) ⇒ (1 2 (* 9 9) 3 4) `(1 2 ,(* 9 9) 3 4) ⇒ (1 2 81 3 4) `(1 (unquote (+ 1 1)) 3) ⇒ (1 2 3) `#(1 ,(/ 12 2)) ⇒ #(1 6) (unquote-splicing EXPR) ,@EXPR Within the quasiquote DATA, ‘unquote-splicing’ or ‘,@’ indicates an expression to be evaluated and the elements of the returned list inserted. EXPR must evaluate to a list. The "comma-at" syntax ‘,@’ is simply a shorthand for an ‘unquote-splicing’ form. (define x '(2 3)) `(1 ,x 4) ⇒ (1 (2 3) 4) `(1 ,@x 4) ⇒ (1 2 3 4) `(1 (unquote-splicing (map 1+ x))) ⇒ (1 3 4) `#(9 ,@x 9) ⇒ #(9 2 3 9) Notice ‘,@’ differs from plain ‘,’ in the way one level of nesting is stripped. For ‘,@’ the elements of a returned list are inserted, whereas with ‘,’ it would be the list itself inserted. 6.16.1.2 Comments ................. Comments in Scheme source files are written by starting them with a semicolon character (‘;’). The comment then reaches up to the end of the line. Comments can begin at any column, and the may be inserted on the same line as Scheme code. ; Comment ;; Comment too (define x 1) ; Comment after expression (let ((y 1)) ;; Display something. (display y) ;;; Comment at left margin. (display (+ y 1))) It is common to use a single semicolon for comments following expressions on a line, to use two semicolons for comments which are indented like code, and three semicolons for comments which start at column 0, even if they are inside an indented code block. This convention is used when indenting code in Emacs' Scheme mode. 6.16.1.3 Block Comments ....................... In addition to the standard line comments defined by R5RS, Guile has another comment type for multiline comments, called “block comments”. This type of comment begins with the character sequence ‘#!’ and ends with the characters ‘!#’. These comments are compatible with the block comments in the Scheme Shell ‘scsh’ (*note The Scheme shell (scsh)::). The characters ‘#!’ were chosen because they are the magic characters used in shell scripts for indicating that the name of the program for executing the script follows on the same line. Thus a Guile script often starts like this. #! /usr/local/bin/guile -s !# More details on Guile scripting can be found in the scripting section (*note Guile Scripting::). Similarly, Guile (starting from version 2.0) supports nested block comments as specified by R6RS and SRFI-30 (http://srfi.schemers.org/srfi-30/srfi-30.html): (+ 1 #| this is a #| nested |# block comment |# 2) ⇒ 3 For backward compatibility, this syntax can be overridden with ‘read-hash-extend’ (*note ‘read-hash-extend’: Reader Extensions.). There is one special case where the contents of a comment can actually affect the interpretation of code. When a character encoding declaration, such as ‘coding: utf-8’ appears in one of the first few lines of a source file, it indicates to Guile's default reader that this source code file is not ASCII. For details see *note Character Encoding of Source Files::. 6.16.1.4 Case Sensitivity ......................... Scheme as defined in R5RS is not case sensitive when reading symbols. Guile, on the contrary is case sensitive by default, so the identifiers guile-whuzzy Guile-Whuzzy are the same in R5RS Scheme, but are different in Guile. It is possible to turn off case sensitivity in Guile by setting the reader option ‘case-insensitive’. For more information on reader options, *Note Scheme Read::. (read-enable 'case-insensitive) It is also possible to disable (or enable) case sensitivity within a single file by placing the reader directives ‘#!fold-case’ (or ‘#!no-fold-case’) within the file itself. 6.16.1.5 Keyword Syntax ....................... 6.16.1.6 Reader Extensions .......................... -- Scheme Procedure: read-hash-extend chr proc -- C Function: scm_read_hash_extend (chr, proc) Install the procedure PROC for reading expressions starting with the character sequence ‘#’ and CHR. PROC will be called with two arguments: the character CHR and the port to read further data from. The object returned will be the return value of ‘read’. Passing ‘#f’ for PROC will remove a previous setting. 6.16.2 Reading Scheme Code -------------------------- -- Scheme Procedure: read [port] -- C Function: scm_read (port) Read an s-expression from the input port PORT, or from the current input port if PORT is not specified. Any whitespace before the next token is discarded. The behavior of Guile's Scheme reader can be modified by manipulating its read options. -- Scheme Procedure: read-options [setting] Display the current settings of the global read options. If SETTING is omitted, only a short form of the current read options is printed. Otherwise if SETTING is the symbol ‘help’, a complete options description is displayed. The set of available options, and their default values, may be had by invoking ‘read-options’ at the prompt. scheme@(guile-user)> (read-options) (square-brackets keywords #f positions) scheme@(guile-user)> (read-options 'help) positions yes Record positions of source code expressions. case-insensitive no Convert symbols to lower case. keywords #f Style of keyword recognition: #f, 'prefix or 'postfix. r6rs-hex-escapes no Use R6RS variable-length character and string hex escapes. square-brackets yes Treat `[' and `]' as parentheses, for R6RS compatibility. hungry-eol-escapes no In strings, consume leading whitespace after an escaped end-of-line. curly-infix no Support SRFI-105 curly infix expressions. r7rs-symbols no Support R7RS |...| symbol notation. Note that Guile also includes a preliminary mechanism for setting read options on a per-port basis. For instance, the ‘case-insensitive’ read option is set (or unset) on the port when the reader encounters the ‘#!fold-case’ or ‘#!no-fold-case’ reader directives. Similarly, the ‘#!curly-infix’ reader directive sets the ‘curly-infix’ read option on the port, and ‘#!curly-infix-and-bracket-lists’ sets ‘curly-infix’ and unsets ‘square-brackets’ on the port (*note SRFI-105::). There is currently no other way to access or set the per-port read options. The boolean options may be toggled with ‘read-enable’ and ‘read-disable’. The non-boolean ‘keywords’ option must be set using ‘read-set!’. -- Scheme Procedure: read-enable option-name -- Scheme Procedure: read-disable option-name -- Scheme Syntax: read-set! option-name value Modify the read options. ‘read-enable’ should be used with boolean options and switches them on, ‘read-disable’ switches them off. ‘read-set!’ can be used to set an option to a specific value. Due to historical oddities, it is a macro that expects an unquoted option name. For example, to make ‘read’ fold all symbols to their lower case (perhaps for compatibility with older Scheme code), you can enter: (read-enable 'case-insensitive) For more information on the effect of the ‘r6rs-hex-escapes’ and ‘hungry-eol-escapes’ options, see (*note String Syntax::). For more information on the ‘r7rs-symbols’ option, see (*note Symbol Read Syntax::). 6.16.3 Reading Scheme Code, For the Compiler -------------------------------------------- When something goes wrong with a Scheme program, the user will want to know how to fix it. This starts with identifying where the error occurred: we want to associate a source location with each component part of source code, and propagate that source location information through to the compiler or interpreter. For that, Guile provides ‘read-syntax’. -- Scheme Procedure: read-syntax [port] Read an s-expression from the input port PORT, or from the current input port if PORT is not specified. If, after skipping white space and comments, no more bytes are available from PORT, return the end-of-file object. *Note Binary I/O::. Otherwise, return an annotated datum. An annotated datum is a syntax object which associates a source location with a datum. For example: (call-with-input-string " foo" read-syntax) ; ⇒ # (call-with-input-string "(foo)" read-syntax) ; ⇒ ; #)> As the second example shows, all fields of pairs and vectors are also annotated, recursively. Most users are familiar with syntax objects in the context of macros, which use syntax objects to associate scope information with identifiers. *Note Macros::. Here we use syntax objects to associate source location information with any datum, but without attaching scope information. The Scheme compiler (‘compile’) and the interpreter (‘eval’) can accept syntax objects directly as input, allowing them to associate source information with resulting code. *Note Compilation::, and *Note Fly Evaluation::. Note that there is a legacy interface for getting source locations into the Scheme compiler or interpreter, which is to use a side table that associates "source properties" with each subdatum returned by ‘read’, instead of wrapping the datums directly as in ‘read-syntax’. This has the disadvantage of not being able to annotate all kinds of datums. *Note Source Properties::, for more information. 6.16.4 Writing Scheme Values ---------------------------- Any scheme value may be written to a port. Not all values may be read back in (*note Scheme Read::), however. -- Scheme Procedure: write obj [port] Send a representation of OBJ to PORT or to the current output port if not given. The output is designed to be machine readable, and can be read back with ‘read’ (*note Scheme Read::). Strings are printed in double quotes, with escapes if necessary, and characters are printed in ‘#\’ notation. -- Scheme Procedure: display obj [port] Send a representation of OBJ to PORT or to the current output port if not given. The output is designed for human readability, it differs from ‘write’ in that strings are printed without double quotes and escapes, and characters are printed as per ‘write-char’, not in ‘#\’ form. As was the case with the Scheme reader, there are a few options that affect the behavior of the Scheme printer. -- Scheme Procedure: print-options [setting] Display the current settings of the read options. If SETTING is omitted, only a short form of the current read options is printed. Otherwise if SETTING is the symbol ‘help’, a complete options description is displayed. The set of available options, and their default values, may be had by invoking ‘print-options’ at the prompt. scheme@(guile-user)> (print-options) (quote-keywordish-symbols reader highlight-suffix "}" highlight-prefix "{") scheme@(guile-user)> (print-options 'help) highlight-prefix { The string to print before highlighted values. highlight-suffix } The string to print after highlighted values. quote-keywordish-symbols reader How to print symbols that have a colon as their first or last character. The value '#f' does not quote the colons; '#t' quotes them; 'reader' quotes them when the reader option 'keywords' is not '#f'. escape-newlines yes Render newlines as \n when printing using `write'. r7rs-symbols no Escape symbols using R7RS |...| symbol notation. These options may be modified with the print-set! syntax. -- Scheme Syntax: print-set! option-name value Modify the print options. Due to historical oddities, ‘print-set!’ is a macro that expects an unquoted option name. 6.16.5 Procedures for On the Fly Evaluation ------------------------------------------- Scheme has the lovely property that its expressions may be represented as data. The ‘eval’ procedure takes a Scheme datum and evaluates it as code. -- Scheme Procedure: eval exp module_or_state -- C Function: scm_eval (exp, module_or_state) Evaluate EXP, a list representing a Scheme expression, in the top-level environment specified by MODULE_OR_STATE. While EXP is evaluated (using ‘primitive-eval’), MODULE_OR_STATE is made the current module. The current module is reset to its previous value when ‘eval’ returns. XXX - dynamic states. Example: (eval '(+ 1 2) (interaction-environment)) -- Scheme Procedure: interaction-environment -- C Function: scm_interaction_environment () Return a specifier for the environment that contains implementation-defined bindings, typically a superset of those listed in the report. The intent is that this procedure will return the environment in which the implementation would evaluate expressions dynamically typed by the user. *Note Environments::, for other environments. One does not always receive code as Scheme data, of course, and this is especially the case for Guile's other language implementations (*note Other Languages::). For the case in which all you have is a string, we have ‘eval-string’. There is a legacy version of this procedure in the default environment, but you really want the one from ‘(ice-9 eval-string)’, so load it up: (use-modules (ice-9 eval-string)) -- Scheme Procedure: eval-string string [#:module=#f] [#:file=#f] [#:line=#f] [#:column=#f] [#:lang=(current-language)] [#:compile?=#f] Parse STRING according to the current language, normally Scheme. Evaluate or compile the expressions it contains, in order, returning the last expression. If the MODULE keyword argument is set, save a module excursion (*note Module System Reflection::) and set the current module to MODULE before evaluation. The FILE, LINE, and COLUMN keyword arguments can be used to indicate that the source string begins at a particular source location. Finally, LANG is a language, defaulting to the current language, and the expression is compiled if COMPILE? is true or there is no evaluator for the given language. -- C Function: scm_eval_string (string) -- C Function: scm_eval_string_in_module (string, module) These C bindings call ‘eval-string’ from ‘(ice-9 eval-string)’, evaluating within MODULE or the current module. -- C Function: SCM scm_c_eval_string (const char *string) ‘scm_eval_string’, but taking a C string in locale encoding instead of an ‘SCM’. -- Scheme Procedure: apply proc arg ... arglst -- C Function: scm_apply_0 (proc, arglst) -- C Function: scm_apply_1 (proc, arg1, arglst) -- C Function: scm_apply_2 (proc, arg1, arg2, arglst) -- C Function: scm_apply_3 (proc, arg1, arg2, arg3, arglst) -- C Function: scm_apply (proc, arg, rest) Call PROC with arguments ARG ... and the elements of the ARGLST list. ‘scm_apply’ takes parameters corresponding to a Scheme level ‘(lambda (proc arg1 . rest) ...)’. So ARG1 and all but the last element of the REST list make up ARG ..., and the last element of REST is the ARGLST list. Or if REST is the empty list ‘SCM_EOL’ then there's no ARG ..., and (ARG1) is the ARGLST. ARGLST is not modified, but the REST list passed to ‘scm_apply’ is modified. -- C Function: scm_call_0 (proc) -- C Function: scm_call_1 (proc, arg1) -- C Function: scm_call_2 (proc, arg1, arg2) -- C Function: scm_call_3 (proc, arg1, arg2, arg3) -- C Function: scm_call_4 (proc, arg1, arg2, arg3, arg4) -- C Function: scm_call_5 (proc, arg1, arg2, arg3, arg4, arg5) -- C Function: scm_call_6 (proc, arg1, arg2, arg3, arg4, arg5, arg6) -- C Function: scm_call_7 (proc, arg1, arg2, arg3, arg4, arg5, arg6, arg7) -- C Function: scm_call_8 (proc, arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8) -- C Function: scm_call_9 (proc, arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9) Call PROC with the given arguments. -- C Function: scm_call (proc, ...) Call PROC with any number of arguments. The argument list must be terminated by ‘SCM_UNDEFINED’. For example: scm_call (scm_c_public_ref ("guile", "+"), scm_from_int (1), scm_from_int (2), SCM_UNDEFINED); -- C Function: scm_call_n (proc, argv, nargs) Call PROC with the array of arguments ARGV, as a ‘SCM*’. The length of the arguments should be passed in NARGS, as a ‘size_t’. -- Scheme Procedure: primitive-eval exp -- C Function: scm_primitive_eval (exp) Evaluate EXP in the top-level environment specified by the current module. 6.16.6 Compiling Scheme Code ---------------------------- The ‘eval’ procedure directly interprets the S-expression representation of Scheme. An alternate strategy for evaluation is to determine ahead of time what computations will be necessary to evaluate the expression, and then use that recipe to produce the desired results. This is known as “compilation”. While it is possible to compile simple Scheme expressions such as ‘(+ 2 2)’ or even ‘"Hello world!"’, compilation is most interesting in the context of procedures. Compiling a lambda expression produces a compiled procedure, which is just like a normal procedure except typically much faster, because it can bypass the generic interpreter. Functions from system modules in a Guile installation are normally compiled already, so they load and run quickly. Note that well-written Scheme programs will not typically call the procedures in this section, for the same reason that it is often bad taste to use ‘eval’. By default, Guile automatically compiles any files it encounters that have not been compiled yet (*note ‘--auto-compile’: Invoking Guile.). The compiler can also be invoked explicitly from the shell as ‘guild compile foo.scm’. (Why are calls to ‘eval’ and ‘compile’ usually in bad taste? Because they are limited, in that they can only really make sense for top-level expressions. Also, most needs for "compile-time" computation are fulfilled by macros and closures. Of course one good counterexample is the REPL itself, or any code that reads expressions from a port.) Automatic compilation generally works transparently, without any need for user intervention. However Guile does not yet do proper dependency tracking, so that if file ‘A.scm’ uses macros from ‘B.scm’, and B.SCM changes, ‘A.scm’ would not be automatically recompiled. To forcibly invalidate the auto-compilation cache, pass the ‘--fresh-auto-compile’ option to Guile, or set the ‘GUILE_AUTO_COMPILE’ environment variable to ‘fresh’ (instead of to ‘0’ or ‘1’). For more information on the compiler itself, see *note Compiling to the Virtual Machine::. For information on the virtual machine, see *note A Virtual Machine for Guile::. The command-line interface to Guile's compiler is the ‘guild compile’ command: -- Command: guild compile [option...] FILE... Compile FILE, a source file, and store bytecode in the compilation cache or in the file specified by the ‘-o’ option. The following options are available: ‘-L DIR’ ‘--load-path=DIR’ Add DIR to the front of the module load path. ‘-o OFILE’ ‘--output=OFILE’ Write output bytecode to OFILE. By convention, bytecode file names end in ‘.go’. When ‘-o’ is omitted, the output file name is as for ‘compile-file’ (see below). ‘-x EXTENSION’ Recognize EXTENSION as a valid source file name extension. For example, to compile R6RS code, you might want to pass ‘-x .sls’ so that files ending in ‘.sls’ can be found. ‘-W WARNING’ ‘--warn=WARNING’ Enable specific warning passes; use ‘-Whelp’ for a list of available options. The default is ‘-W1’, which enables a number of common warnings. Pass ‘-W0’ to disable all warnings. ‘-O OPT’ ‘--optimize=OPT’ Enable or disable specific compiler optimizations; use ‘-Ohelp’ for a list of available options. The default is ‘-O2’, which enables most optimizations. ‘-O0’ is recommended if compilation speed is more important than the speed of the compiled code. Pass ‘-Ono-OPT’ to disable a specific compiler pass. Any number of ‘-O’ options can be passed to the compiler, with later ones taking precedence. ‘--r6rs’ ‘--r7rs’ Compile in an environment whose default bindings, reader options, and load paths are adapted for specific Scheme standards. *Note R6RS Support::, and *Note R7RS Support::. ‘-f LANG’ ‘--from=LANG’ Use LANG as the source language of FILE. If this option is omitted, ‘scheme’ is assumed. ‘-t LANG’ ‘--to=LANG’ Use LANG as the target language of FILE. If this option is omitted, ‘rtl’ is assumed. ‘-T TARGET’ ‘--target=TARGET’ Produce code for TARGET instead of %HOST-TYPE (*note %host-type: Build Config.). Target must be a valid GNU triplet, such as ‘armv5tel-unknown-linux-gnueabi’ (*note (autoconf)Specifying Target Triplets::). Each FILE is assumed to be UTF-8-encoded, unless it contains a coding declaration as recognized by ‘file-encoding’ (*note Character Encoding of Source Files::). The compiler can also be invoked directly by Scheme code. These interfaces are in their own module: (use-modules (system base compile)) -- Scheme Procedure: compile exp [#:env=#f] [#:from=(current-language)] [#:to=value] [#:opts='()] [#:optimization-level=(default-optimization-level)] [#:warning-level=(default-warning-level)] Compile the expression EXP in the environment ENV. If EXP is a procedure, the result will be a compiled procedure; otherwise ‘compile’ is mostly equivalent to ‘eval’. For a discussion of languages and compiler options, *Note Compiling to the Virtual Machine::. -- Scheme Procedure: compile-file file [#:output-file=#f] [#:from=(current-language)] [#:to='rtl] [#:env=(default-environment from)] [#:opts='()] [#:optimization-level=(default-optimization-level)] [#:warning-level=(default-warning-level)] [#:canonicalization='relative] Compile the file named FILE. Output will be written to a OUTPUT-FILE. If you do not supply an output file name, output is written to a file in the cache directory, as computed by ‘(compiled-file-name FILE)’. FROM and TO specify the source and target languages. *Note Compiling to the Virtual Machine::, for more information on these options, and on ENV and OPTS. As with ‘guild compile’, FILE is assumed to be UTF-8-encoded unless it contains a coding declaration. -- Scheme Parameter: default-optimization-level The default optimization level, as an integer from 0 to 9. The default is 2. -- Scheme Parameter: default-warning-level The default warning level, as an integer from 0 to 9. The default is 1. *Note Parameters::, for more on how to set parameters. -- Scheme Procedure: compiled-file-name file Compute a cached location for a compiled version of a Scheme file named FILE. This file will usually be below the ‘$HOME/.cache/guile/ccache’ directory, depending on the value of the ‘XDG_CACHE_HOME’ environment variable. The intention is that ‘compiled-file-name’ provides a fallback location for caching auto-compiled files. If you want to place a compile file in the ‘%load-compiled-path’, you should pass the OUTPUT-FILE option to ‘compile-file’, explicitly. -- Scheme Variable: %auto-compilation-options This variable contains the options passed to the ‘compile-file’ procedure when auto-compiling source files. By default, it enables useful compilation warnings. It can be customized from ‘~/.guile’. 6.16.7 Loading Scheme Code from File ------------------------------------ -- Scheme Procedure: load filename [reader] Load FILENAME and evaluate its contents in the top-level environment. READER if provided should be either ‘#f’, or a procedure with the signature ‘(lambda (port) ...)’ which reads the next expression from PORT. If READER is ‘#f’ or absent, Guile's built-in ‘read’ procedure is used (*note Scheme Read::). The READER argument takes effect by setting the value of the ‘current-reader’ fluid (see below) before loading the file, and restoring its previous value when loading is complete. The Scheme code inside FILENAME can itself change the current reader procedure on the fly by setting ‘current-reader’ fluid. If the variable ‘%load-hook’ is defined, it should be bound to a procedure that will be called before any code is loaded. See documentation for ‘%load-hook’ later in this section. -- Scheme Procedure: load-compiled filename Load the compiled file named FILENAME. Compiling a source file (*note Read/Load/Eval/Compile::) and then calling ‘load-compiled’ on the resulting file is equivalent to calling ‘load’ on the source file. -- Scheme Procedure: primitive-load filename -- C Function: scm_primitive_load (filename) Load the file named FILENAME and evaluate its contents in the top-level environment. FILENAME must either be a full pathname or be a pathname relative to the current directory. If the variable ‘%load-hook’ is defined, it should be bound to a procedure that will be called before any code is loaded. See the documentation for ‘%load-hook’ later in this section. -- C Function: SCM scm_c_primitive_load (const char *filename) ‘scm_primitive_load’, but taking a C string instead of an ‘SCM’. -- Variable: current-reader ‘current-reader’ holds the read procedure that is currently being used by the above loading procedures to read expressions (from the file that they are loading). ‘current-reader’ is a fluid, so it has an independent value in each dynamic root and should be read and set using ‘fluid-ref’ and ‘fluid-set!’ (*note Fluids and Dynamic States::). Changing ‘current-reader’ is typically useful to introduce local syntactic changes, such that code following the ‘fluid-set!’ call is read using the newly installed reader. The ‘current-reader’ change should take place at evaluation time when the code is evaluated, or at compilation time when the code is compiled: (eval-when (compile eval) (fluid-set! current-reader my-own-reader)) The ‘eval-when’ form above ensures that the ‘current-reader’ change occurs at the right time. -- Variable: %load-hook A procedure to be called ‘(%load-hook FILENAME)’ whenever a file is loaded, or ‘#f’ for no such call. ‘%load-hook’ is used by all of the loading functions (‘load’ and ‘primitive-load’, and ‘load-from-path’ and ‘primitive-load-path’ documented in the next section). For example an application can set this to show what's loaded, (set! %load-hook (lambda (filename) (format #t "Loading ~a ...\n" filename))) (load-from-path "foo.scm") ⊣ Loading /usr/local/share/guile/site/foo.scm ... -- Scheme Procedure: current-load-port -- C Function: scm_current_load_port () Return the current-load-port. The load port is used internally by ‘primitive-load’. 6.16.8 Load Paths ----------------- The procedure in the previous section look for Scheme code in the file system at specific location. Guile also has some procedures to search the load path for code. -- Variable: %load-path List of directories which should be searched for Scheme modules and libraries. When Guile starts up, ‘%load-path’ is initialized to the default load path ‘(list (%library-dir) (%site-dir) (%global-site-dir) (%package-data-dir))’. The ‘GUILE_LOAD_PATH’ environment variable can be used to prepend or append additional directories (*note Environment Variables::). *Note Build Config::, for more on ‘%site-dir’ and related procedures. -- Scheme Procedure: load-from-path filename Similar to ‘load’, but searches for FILENAME in the load paths. Preferentially loads a compiled version of the file, if it is available and up-to-date. A user can extend the load path by calling ‘add-to-load-path’. -- Scheme Syntax: add-to-load-path dir Add DIR to the load path. For example, a script might include this form to add the directory that it is in to the load path: (add-to-load-path (dirname (current-filename))) It's better to use ‘add-to-load-path’ than to modify ‘%load-path’ directly, because ‘add-to-load-path’ takes care of modifying the path both at compile-time and at run-time. -- Scheme Procedure: primitive-load-path filename [exception-on-not-found] -- C Function: scm_primitive_load_path (filename) Search ‘%load-path’ for the file named FILENAME and load it into the top-level environment. If FILENAME is a relative pathname and is not found in the list of search paths, an error is signaled. Preferentially loads a compiled version of the file, if it is available and up-to-date. If FILENAME is a relative pathname and is not found in the list of search paths, one of three things may happen, depending on the optional second argument, EXCEPTION-ON-NOT-FOUND. If it is ‘#f’, ‘#f’ will be returned. If it is a procedure, it will be called with no arguments. (This allows a distinction to be made between exceptions raised by loading a file, and exceptions related to the loader itself.) Otherwise an error is signaled. For compatibility with Guile 1.8 and earlier, the C function takes only one argument, which can be either a string (the file name) or an argument list. -- Scheme Procedure: %search-load-path filename -- C Function: scm_sys_search_load_path (filename) Search ‘%load-path’ for the file named FILENAME, which must be readable by the current user. If FILENAME is found in the list of paths to search or is an absolute pathname, return its full pathname. Otherwise, return ‘#f’. Filenames may have any of the optional extensions in the ‘%load-extensions’ list; ‘%search-load-path’ will try each extension automatically. -- Variable: %load-extensions A list of default file extensions for files containing Scheme code. ‘%search-load-path’ tries each of these extensions when looking for a file to load. By default, ‘%load-extensions’ is bound to the list ‘("" ".scm")’. As mentioned above, when Guile searches the ‘%load-path’ for a source file, it will also search the ‘%load-compiled-path’ for a corresponding compiled file. If the compiled file is as new or newer than the source file, it will be loaded instead of the source file, using ‘load-compiled’. -- Variable: %load-compiled-path Like ‘%load-path’, but for compiled files. By default, this path has two entries: one for compiled files from Guile itself, and one for site packages. The ‘GUILE_LOAD_COMPILED_PATH’ environment variable can be used to prepend or append additional directories (*note Environment Variables::). When ‘primitive-load-path’ searches the ‘%load-compiled-path’ for a corresponding compiled file for a relative path it does so by appending ‘.go’ to the relative path. For example, searching for ‘ice-9/popen’ could find ‘/usr/lib/guile/3.0/ccache/ice-9/popen.go’, and use it instead of ‘/usr/share/guile/3.0/ice-9/popen.scm’. If ‘primitive-load-path’ does not find a corresponding ‘.go’ file in the ‘%load-compiled-path’, or the ‘.go’ file is out of date, it will search for a corresponding auto-compiled file in the fallback path, possibly creating one if one does not exist. *Note Installing Site Packages::, for more on how to correctly install site packages. *Note Modules and the File System::, for more on the relationship between load paths and modules. *Note Compilation::, for more on the fallback path and auto-compilation. Finally, there are a couple of helper procedures for general path manipulation. -- Scheme Procedure: parse-path path [tail] -- C Function: scm_parse_path (path, tail) Parse PATH, which is expected to be a colon-separated string, into a list and return the resulting list with TAIL appended. If PATH is ‘#f’, TAIL is returned. -- Scheme Procedure: parse-path-with-ellipsis path base -- C Function: scm_parse_path_with_ellipsis (path, base) Parse PATH, which is expected to be a colon-separated string, into a list and return the resulting list with BASE (a list) spliced in place of the ‘...’ path component, if present, or else BASE is added to the end. If PATH is ‘#f’, BASE is returned. -- Scheme Procedure: search-path path filename [extensions [require-exts?]] -- C Function: scm_search_path (path, filename, rest) Search PATH for a directory containing a file named FILENAME. The file must be readable, and not a directory. If we find one, return its full filename; otherwise, return ‘#f’. If FILENAME is absolute, return it unchanged. If given, EXTENSIONS is a list of strings; for each directory in PATH, we search for FILENAME concatenated with each EXTENSION. If REQUIRE-EXTS? is true, require that the returned file name have one of the given extensions; if REQUIRE-EXTS? is not given, it defaults to ‘#f’. For compatibility with Guile 1.8 and earlier, the C function takes only three arguments. 6.16.9 Character Encoding of Source Files ----------------------------------------- Scheme source code files are usually encoded in ASCII or UTF-8, but the built-in reader can interpret other character encodings as well. When Guile loads Scheme source code, it uses the ‘file-encoding’ procedure (described below) to try to guess the encoding of the file. In the absence of any hints, UTF-8 is assumed. One way to provide a hint about the encoding of a source file is to place a coding declaration in the top 500 characters of the file. A coding declaration has the form ‘coding: XXXXXX’, where ‘XXXXXX’ is the name of a character encoding in which the source code file has been encoded. The coding declaration must appear in a scheme comment. It can either be a semicolon-initiated comment, or the first block ‘#!’ comment in the file. The name of the character encoding in the coding declaration is typically lower case and containing only letters, numbers, and hyphens, as recognized by ‘set-port-encoding!’ (*note ‘set-port-encoding!’: Ports.). Common examples of character encoding names are ‘utf-8’ and ‘iso-8859-1’, as defined by IANA (http://www.iana.org/assignments/character-sets). Thus, the coding declaration is mostly compatible with Emacs. However, there are some differences in encoding names recognized by Emacs and encoding names defined by IANA, the latter being essentially a subset of the former. For instance, ‘latin-1’ is a valid encoding name for Emacs, but it's not according to the IANA standard, which Guile follows; instead, you should use ‘iso-8859-1’, which is both understood by Emacs and dubbed by IANA (IANA writes it uppercase but Emacs wants it lowercase and Guile is case insensitive.) For source code, only a subset of all possible character encodings can be interpreted by the built-in source code reader. Only those character encodings in which ASCII text appears unmodified can be used. This includes ‘UTF-8’ and ‘ISO-8859-1’ through ‘ISO-8859-15’. The multi-byte character encodings ‘UTF-16’ and ‘UTF-32’ may not be used because they are not compatible with ASCII. There might be a scenario in which one would want to read non-ASCII code from a port, such as with the function ‘read’, instead of with ‘load’. If the port's character encoding is the same as the encoding of the code to be read by the port, not other special handling is necessary. The port will automatically do the character encoding conversion. The functions ‘setlocale’ or by ‘set-port-encoding!’ are used to set port encodings (*note Ports::). If a port is used to read code of unknown character encoding, it can accomplish this in three steps. First, the character encoding of the port should be set to ISO-8859-1 using ‘set-port-encoding!’. Then, the procedure ‘file-encoding’, described below, is used to scan for a coding declaration when reading from the port. As a side effect, it rewinds the port after its scan is complete. After that, the port's character encoding should be set to the encoding returned by ‘file-encoding’, if any, again by using ‘set-port-encoding!’. Then the code can be read as normal. Alternatively, one can use the ‘#:guess-encoding’ keyword argument of ‘open-file’ and related procedures. *Note File Ports::. -- Scheme Procedure: file-encoding port -- C Function: scm_file_encoding (port) Attempt to scan the first few hundred bytes from the PORT for hints about its character encoding. Return a string containing the encoding name or ‘#f’ if the encoding cannot be determined. The port is rewound. Currently, the only supported method is to look for an Emacs-like character coding declaration (*note how Emacs recognizes file encoding: (emacs)Recognize Coding.). The coding declaration is of the form ‘coding: XXXXX’ and must appear in a Scheme comment. Additional heuristics may be added in the future. 6.16.10 Delayed Evaluation -------------------------- Promises are a convenient way to defer a calculation until its result is actually needed, and to run such a calculation only once. Also *note SRFI-45::. -- syntax: delay expr Return a promise object which holds the given EXPR expression, ready to be evaluated by a later ‘force’. -- Scheme Procedure: promise? obj -- C Function: scm_promise_p (obj) Return true if OBJ is a promise. -- Scheme Procedure: force p -- C Function: scm_force (p) Return the value obtained from evaluating the EXPR in the given promise P. If P has previously been forced then its EXPR is not evaluated again, instead the value obtained at that time is simply returned. During a ‘force’, an EXPR can call ‘force’ again on its own promise, resulting in a recursive evaluation of that EXPR. The first evaluation to return gives the value for the promise. Higher evaluations run to completion in the normal way, but their results are ignored, ‘force’ always returns the first value. 6.16.11 Local Evaluation ------------------------ Guile includes a facility to capture a lexical environment, and later evaluate a new expression within that environment. This code is implemented in a module. (use-modules (ice-9 local-eval)) -- syntax: the-environment Captures and returns a lexical environment for use with ‘local-eval’ or ‘local-compile’. -- Scheme Procedure: local-eval exp env -- C Function: scm_local_eval (exp, env) -- Scheme Procedure: local-compile exp env [opts=()] Evaluate or compile the expression EXP in the lexical environment ENV. Here is a simple example, illustrating that it is the variable that gets captured, not just its value at one point in time. (define e (let ((x 100)) (the-environment))) (define fetch-x (local-eval '(lambda () x) e)) (fetch-x) ⇒ 100 (local-eval '(set! x 42) e) (fetch-x) ⇒ 42 While EXP is evaluated within the lexical environment of ‘(the-environment)’, it has the dynamic environment of the call to ‘local-eval’. ‘local-eval’ and ‘local-compile’ can only evaluate expressions, not definitions. (local-eval '(define foo 42) (let ((x 100)) (the-environment))) ⇒ syntax error: definition in expression context Note that the current implementation of ‘(the-environment)’ only captures "normal" lexical bindings, and pattern variables bound by ‘syntax-case’. It does not currently capture local syntax transformers bound by ‘let-syntax’, ‘letrec-syntax’ or non-top-level ‘define-syntax’ forms. Any attempt to reference such captured syntactic keywords via ‘local-eval’ or ‘local-compile’ produces an error. 6.16.12 Local Inclusion ----------------------- This section has discussed various means of linking Scheme code together: fundamentally, loading up files at run-time using ‘load’ and ‘load-compiled’. Guile provides another option to compose parts of programs together at expansion-time instead of at run-time. -- Scheme Syntax: include file-name Open FILE-NAME, at expansion-time, and read the Scheme forms that it contains, splicing them into the location of the ‘include’, within a ‘begin’. If FILE-NAME is a relative path, it is searched for relative to the path that contains the file that the ‘include’ form appears in. If you are a C programmer, if ‘load’ in Scheme is like ‘dlopen’ in C, consider ‘include’ to be like the C preprocessor's ‘#include’. When you use ‘include’, it is as if the contents of the included file were typed in instead of the ‘include’ form. Because the code is included at compile-time, it is available to the macroexpander. Syntax definitions in the included file are available to later code in the form in which the ‘include’ appears, without the need for ‘eval-when’. (*Note Eval When::.) For the same reason, compiling a form that uses ‘include’ results in one compilation unit, composed of multiple files. Loading the compiled file is one ‘stat’ operation for the compilation unit, instead of ‘2*N’ in the case of ‘load’ (once for each loaded source file, and once each corresponding compiled file, in the best case). Unlike ‘load’, ‘include’ also works within nested lexical contexts. It so happens that the optimizer works best within a lexical context, because all of the uses of bindings in a lexical context are visible, so composing files by including them within a ‘(let () ...)’ can sometimes lead to important speed improvements. On the other hand, ‘include’ does have all the disadvantages of early binding: once the code with the ‘include’ is compiled, no change to the included file is reflected in the future behavior of the including form. Also, the particular form of ‘include’, which requires an absolute path, or a path relative to the current directory at compile-time, is not very amenable to compiling the source in one place, but then installing the source to another place. For this reason, Guile provides another form, ‘include-from-path’, which looks for the source file to include within a load path. -- Scheme Syntax: include-from-path file-name Like ‘include’, but instead of expecting ‘file-name’ to be an absolute file name, it is expected to be a relative path to search in the ‘%load-path’. ‘include-from-path’ is more useful when you want to install all of the source files for a package (as you should!). It makes it possible to evaluate an installed file from source, instead of relying on the ‘.go’ file being up to date. 6.16.13 Sandboxed Evaluation ---------------------------- Sometimes you would like to evaluate code that comes from an untrusted party. The safest way to do this is to buy a new computer, evaluate the code on that computer, then throw the machine away. However if you are unwilling to take this simple approach, Guile does include a limited "sandbox" facility that can allow untrusted code to be evaluated with some confidence. To use the sandboxed evaluator, load its module: (use-modules (ice-9 sandbox)) Guile's sandboxing facility starts with the ability to restrict the time and space used by a piece of code. -- Scheme Procedure: call-with-time-limit limit thunk limit-reached Call THUNK, but cancel it if LIMIT seconds of wall-clock time have elapsed. If the computation is canceled, call LIMIT-REACHED in tail position. THUNK must not disable interrupts or prevent an abort via a ‘dynamic-wind’ unwind handler. -- Scheme Procedure: call-with-allocation-limit limit thunk limit-reached Call THUNK, but cancel it if LIMIT bytes have been allocated. If the computation is canceled, call LIMIT-REACHED in tail position. THUNK must not disable interrupts or prevent an abort via a ‘dynamic-wind’ unwind handler. This limit applies to both stack and heap allocation. The computation will not be aborted before LIMIT bytes have been allocated, but for the heap allocation limit, the check may be postponed until the next garbage collection. Note that as a current shortcoming, the heap size limit applies to all threads; concurrent allocation by other unrelated threads counts towards the allocation limit. -- Scheme Procedure: call-with-time-and-allocation-limits time-limit allocation-limit thunk Invoke THUNK in a dynamic extent in which its execution is limited to TIME-LIMIT seconds of wall-clock time, and its allocation to ALLOCATION-LIMIT bytes. THUNK must not disable interrupts or prevent an abort via a ‘dynamic-wind’ unwind handler. If successful, return all values produced by invoking THUNK. Any uncaught exception thrown by the thunk will propagate out. If the time or allocation limit is exceeded, an exception will be thrown to the ‘limit-exceeded’ key. The time limit and stack limit are both very precise, but the heap limit only gets checked asynchronously, after a garbage collection. In particular, if the heap is already very large, the number of allocated bytes between garbage collections will be large, and therefore the precision of the check is reduced. Additionally, due to the mechanism used by the allocation limit (the ‘after-gc-hook’), large single allocations like ‘(make-vector #e1e7)’ are only detected after the allocation completes, even if the allocation itself causes garbage collection. It's possible therefore for user code to not only exceed the allocation limit set, but also to exhaust all available memory, causing out-of-memory conditions at any allocation site. Failure to allocate memory in Guile itself should be safe and cause an exception to be thrown, but most systems are not designed to handle ‘malloc’ failures. An allocation failure may therefore exercise unexpected code paths in your system, so it is a weakness of the sandbox (and therefore an interesting point of attack). The main sandbox interface is ‘eval-in-sandbox’. -- Scheme Procedure: eval-in-sandbox exp [#:time-limit 0.1] [#:allocation-limit #e10e6] [#:bindings all-pure-bindings] [#:module (make-sandbox-module bindings)] [#:sever-module? #t] Evaluate the Scheme expression EXP within an isolated "sandbox". Limit its execution to TIME-LIMIT seconds of wall-clock time, and limit its allocation to ALLOCATION-LIMIT bytes. The evaluation will occur in MODULE, which defaults to the result of calling ‘make-sandbox-module’ on BINDINGS, which itself defaults to ‘all-pure-bindings’. This is the core of the sandbox: creating a scope for the expression that is “safe”. A safe sandbox module has two characteristics. Firstly, it will not allow the expression being evaluated to avoid being canceled due to time or allocation limits. This ensures that the expression terminates in a timely fashion. Secondly, a safe sandbox module will prevent the evaluation from receiving information from previous evaluations, or from affecting future evaluations. All combinations of binding sets exported by ‘(ice-9 sandbox)’ form safe sandbox modules. The BINDINGS should be given as a list of import sets. One import set is a list whose car names an interface, like ‘(ice-9 q)’, and whose cdr is a list of imports. An import is either a bare symbol or a pair of ‘(OUT . IN)’, where OUT and IN are both symbols and denote the name under which a binding is exported from the module, and the name under which to make the binding available, respectively. Note that BINDINGS is only used as an input to the default initializer for the MODULE argument; if you pass ‘#:module’, BINDINGS is unused. If SEVER-MODULE? is true (the default), the module will be unlinked from the global module tree after the evaluation returns, to allow MOD to be garbage-collected. If successful, return all values produced by EXP. Any uncaught exception thrown by the expression will propagate out. If the time or allocation limit is exceeded, an exception will be thrown to the ‘limit-exceeded’ key. Constructing a safe sandbox module is tricky in general. Guile defines an easy way to construct safe modules from predefined sets of bindings. Before getting to that interface, here are some general notes on safety. 1. The time and allocation limits rely on the ability to interrupt and cancel a computation. For this reason, no binding included in a sandbox module should be able to indefinitely postpone interrupt handling, nor should a binding be able to prevent an abort. In practice this second consideration means that ‘dynamic-wind’ should not be included in any binding set. 2. The time and allocation limits apply only to the ‘eval-in-sandbox’ call. If the call returns a procedure which is later called, no limit is "automatically" in place. Users of ‘eval-in-sandbox’ have to be very careful to reimpose limits when calling procedures that escape from sandboxes. 3. Similarly, the dynamic environment of the ‘eval-in-sandbox’ call is not necessarily in place when any procedure that escapes from the sandbox is later called. This detail prevents us from exposing ‘primitive-eval’ to the sandbox, for two reasons. The first is that it's possible for legacy code to forge references to any binding, if the ‘allow-legacy-syntax-objects?’ parameter is true. The default for this parameter is true; *note Syntax Transformer Helpers:: for the details. The parameter is bound to ‘#f’ for the duration of the ‘eval-in-sandbox’ call itself, but that will not be in place during calls to escaped procedures. The second reason we don't expose ‘primitive-eval’ is that ‘primitive-eval’ implicitly works in the current module, which for an escaped procedure will probably be different than the module that is current for the ‘eval-in-sandbox’ call itself. The common denominator here is that if an interface exposed to the sandbox relies on dynamic environments, it is easy to mistakenly grant the sandboxed procedure additional capabilities in the form of bindings that it should not have access to. For this reason, the default sets of predefined bindings do not depend on any dynamically scoped value. 4. Mutation may allow a sandboxed evaluation to break some invariant in users of data supplied to it. A lot of code culturally doesn't expect mutation, but if you hand mutable data to a sandboxed evaluation and you also grant mutating capabilities to that evaluation, then the sandboxed code may indeed mutate that data. The default set of bindings to the sandbox do not include any mutating primitives. Relatedly, ‘set!’ may allow a sandbox to mutate a primitive, invalidating many system-wide invariants. Guile is currently quite permissive when it comes to imported bindings and mutability. Although ‘set!’ to a module-local or lexically bound variable would be fine, we don't currently have an easy way to disallow ‘set!’ to an imported binding, so currently no binding set includes ‘set!’. 5. Mutation may allow a sandboxed evaluation to keep state, or make a communication mechanism with other code. On the one hand this sounds cool, but on the other hand maybe this is part of your threat model. Again, the default set of bindings doesn't include mutating primitives, preventing sandboxed evaluations from keeping state. 6. The sandbox should probably not be able to open a network connection, or write to a file, or open a file from disk. The default binding set includes no interaction with the operating system. If you, dear reader, find the above discussion interesting, you will enjoy Jonathan Rees' dissertation, "A Security Kernel Based on the Lambda Calculus". -- Scheme Variable: all-pure-bindings All "pure" bindings that together form a safe subset of those bindings available by default to Guile user code. -- Scheme Variable: all-pure-and-impure-bindings Like ‘all-pure-bindings’, but additionally including mutating primitives like ‘vector-set!’. This set is still safe in the sense mentioned above, with the caveats about mutation. The components of these composite sets are as follows: -- Scheme Variable: alist-bindings -- Scheme Variable: array-bindings -- Scheme Variable: bit-bindings -- Scheme Variable: bitvector-bindings -- Scheme Variable: char-bindings -- Scheme Variable: char-set-bindings -- Scheme Variable: clock-bindings -- Scheme Variable: core-bindings -- Scheme Variable: error-bindings -- Scheme Variable: fluid-bindings -- Scheme Variable: hash-bindings -- Scheme Variable: iteration-bindings -- Scheme Variable: keyword-bindings -- Scheme Variable: list-bindings -- Scheme Variable: macro-bindings -- Scheme Variable: nil-bindings -- Scheme Variable: number-bindings -- Scheme Variable: pair-bindings -- Scheme Variable: predicate-bindings -- Scheme Variable: procedure-bindings -- Scheme Variable: promise-bindings -- Scheme Variable: prompt-bindings -- Scheme Variable: regexp-bindings -- Scheme Variable: sort-bindings -- Scheme Variable: srfi-4-bindings -- Scheme Variable: string-bindings -- Scheme Variable: symbol-bindings -- Scheme Variable: unspecified-bindings -- Scheme Variable: variable-bindings -- Scheme Variable: vector-bindings -- Scheme Variable: version-bindings The components of ‘all-pure-bindings’. -- Scheme Variable: mutating-alist-bindings -- Scheme Variable: mutating-array-bindings -- Scheme Variable: mutating-bitvector-bindings -- Scheme Variable: mutating-fluid-bindings -- Scheme Variable: mutating-hash-bindings -- Scheme Variable: mutating-list-bindings -- Scheme Variable: mutating-pair-bindings -- Scheme Variable: mutating-sort-bindings -- Scheme Variable: mutating-srfi-4-bindings -- Scheme Variable: mutating-string-bindings -- Scheme Variable: mutating-variable-bindings -- Scheme Variable: mutating-vector-bindings The additional components of ‘all-pure-and-impure-bindings’. Finally, what do you do with a binding set? What is a binding set anyway? ‘make-sandbox-module’ is here for you. -- Scheme Procedure: make-sandbox-module bindings Return a fresh module that only contains BINDINGS. The BINDINGS should be given as a list of import sets. One import set is a list whose car names an interface, like ‘(ice-9 q)’, and whose cdr is a list of imports. An import is either a bare symbol or a pair of ‘(OUT . IN)’, where OUT and IN are both symbols and denote the name under which a binding is exported from the module, and the name under which to make the binding available, respectively. So you see that binding sets are just lists, and ‘all-pure-and-impure-bindings’ is really just the result of appending all of the component binding sets. 6.16.14 REPL Servers -------------------- The procedures in this section are provided by (use-modules (system repl server)) When an application is written in Guile, it is often convenient to allow the user to be able to interact with it by evaluating Scheme expressions in a REPL. The procedures of this module allow you to spawn a “REPL server”, which permits interaction over a local or TCP connection. Guile itself uses them internally to implement the ‘--listen’ switch, *note Command-line Options::. -- Scheme Procedure: make-tcp-server-socket [#:host=#f] [#:addr] [#:port=37146] Return a stream socket bound to a given address ADDR and port number PORT. If the HOST is given, and ADDR is not, then the HOST string is converted to an address. If neither is given, we use the loopback address. -- Scheme Procedure: make-unix-domain-server-socket [#:path="/tmp/guile-socket"] Return a UNIX domain socket, bound to a given PATH. -- Scheme Procedure: run-server [server-socket] -- Scheme Procedure: spawn-server [server-socket] Create and run a REPL, making it available over the given SERVER-SOCKET. If SERVER-SOCKET is not provided, it defaults to the socket created by calling ‘make-tcp-server-socket’ with no arguments. ‘run-server’ runs the server in the current thread, whereas ‘spawn-server’ runs the server in a new thread. -- Scheme Procedure: stop-server-and-clients! Closes the connection on all running server sockets. Please note that in the current implementation, the REPL threads are canceled without unwinding their stacks. If any of them are holding mutexes or are within a critical section, the results are unspecified. 6.16.15 Cooperative REPL Servers -------------------------------- The procedures in this section are provided by (use-modules (system repl coop-server)) Whereas ordinary REPL servers run in their own threads (*note REPL Servers::), sometimes it is more convenient to provide REPLs that run at specified times within an existing thread, for example in programs utilizing an event loop or in single-threaded programs. This allows for safe access and mutation of a program's data structures from the REPL, without concern for thread synchronization. Although the REPLs are run in the thread that calls ‘spawn-coop-repl-server’ and ‘poll-coop-repl-server’, dedicated threads are spawned so that the calling thread is not blocked. The spawned threads read input for the REPLs and to listen for new connections. Cooperative REPL servers must be polled periodically to evaluate any pending expressions by calling ‘poll-coop-repl-server’ with the object returned from ‘spawn-coop-repl-server’. The thread that calls ‘poll-coop-repl-server’ will be blocked for as long as the expression takes to be evaluated or if the debugger is entered. -- Scheme Procedure: spawn-coop-repl-server [server-socket] Create and return a new cooperative REPL server object, and spawn a new thread to listen for connections on SERVER-SOCKET. Proper functioning of the REPL server requires that ‘poll-coop-repl-server’ be called periodically on the returned server object. -- Scheme Procedure: poll-coop-repl-server coop-server Poll the cooperative REPL server COOP-SERVER and apply a pending operation if there is one, such as evaluating an expression typed at the REPL prompt. This procedure must be called from the same thread that called ‘spawn-coop-repl-server’. 6.17 Memory Management and Garbage Collection ============================================= Guile uses a _garbage collector_ to manage most of its objects. While the garbage collector is designed to be mostly invisible, you sometimes need to interact with it explicitly. See *note Garbage Collection:: for a general discussion of how garbage collection relates to using Guile from C. 6.17.1 Function related to Garbage Collection --------------------------------------------- -- Scheme Procedure: gc -- C Function: scm_gc () Finds all of the "live" ‘SCM’ objects and reclaims for further use those that are no longer accessible. You normally don't need to call this function explicitly. Its functionality is invoked automatically as needed. -- C Function: SCM scm_gc_protect_object (SCM OBJ) Protects OBJ from being freed by the garbage collector, when it otherwise might be. When you are done with the object, call ‘scm_gc_unprotect_object’ on the object. Calls to ‘scm_gc_protect_object’/‘scm_gc_unprotect_object’ can be nested, and the object remains protected until it has been unprotected as many times as it was protected. It is an error to unprotect an object more times than it has been protected. Returns the SCM object it was passed. Note that storing OBJ in a C global variable has the same effect(1). -- C Function: SCM scm_gc_unprotect_object (SCM OBJ) Unprotects an object from the garbage collector which was protected by ‘scm_gc_unprotect_object’. Returns the SCM object it was passed. -- C Function: SCM scm_permanent_object (SCM OBJ) Similar to ‘scm_gc_protect_object’ in that it causes the collector to always mark the object, except that it should not be nested (only call ‘scm_permanent_object’ on an object once), and it has no corresponding unpermanent function. Once an object is declared permanent, it will never be freed. Returns the SCM object it was passed. -- C Macro: void scm_remember_upto_here_1 (SCM obj) -- C Macro: void scm_remember_upto_here_2 (SCM obj1, SCM obj2) Create a reference to the given object or objects, so they're certain to be present on the stack or in a register and hence will not be freed by the garbage collector before this point. Note that these functions can only be applied to ordinary C local variables (ie. "automatics"). Objects held in global or static variables or some malloced block or the like cannot be protected with this mechanism. -- Scheme Procedure: gc-stats -- C Function: scm_gc_stats () Return an association list of statistics about Guile's current use of storage. -- Scheme Procedure: gc-live-object-stats -- C Function: scm_gc_live_object_stats () Return an alist of statistics of the current live objects. -- Function: void scm_gc_mark (SCM X) Mark the object X, and recurse on any objects X refers to. If X's mark bit is already set, return immediately. This function must only be called during the mark-phase of garbage collection, typically from a smob _mark_ function. ---------- Footnotes ---------- (1) In Guile up to version 1.8, C global variables were not visited by the garbage collector in the mark phase; hence, ‘scm_gc_protect_object’ was the only way in C to prevent a Scheme object from being freed. 6.17.2 Memory Blocks -------------------- In C programs, dynamic management of memory blocks is normally done with the functions malloc, realloc, and free. Guile has additional functions for dynamic memory allocation that are integrated into the garbage collector and the error reporting system. Memory blocks that are associated with Scheme objects (for example a foreign object) should be allocated with ‘scm_gc_malloc’ or ‘scm_gc_malloc_pointerless’. These two functions will either return a valid pointer or signal an error. Memory blocks allocated this way may be released explicitly; however, this is not strictly needed, and we recommend _not_ calling ‘scm_gc_free’. All memory allocated with ‘scm_gc_malloc’ or ‘scm_gc_malloc_pointerless’ is automatically reclaimed when the garbage collector no longer sees any live reference to it(1). When garbage collection occurs, Guile will visit the words in memory allocated with ‘scm_gc_malloc’, looking for live pointers. This means that if ‘scm_gc_malloc’-allocated memory contains a pointer to some other part of the memory, the garbage collector notices it and prevents it from being reclaimed(2). Conversely, memory allocated with ‘scm_gc_malloc_pointerless’ is assumed to be "pointer-less" and is not scanned for pointers. For memory that is not associated with a Scheme object, you can use ‘scm_malloc’ instead of ‘malloc’. Like ‘scm_gc_malloc’, it will either return a valid pointer or signal an error. However, it will not assume that the new memory block can be freed by a garbage collection. The memory must be explicitly freed with ‘free’. There is also ‘scm_gc_realloc’ and ‘scm_realloc’, to be used in place of ‘realloc’ when appropriate, and ‘scm_gc_calloc’ and ‘scm_calloc’, to be used in place of ‘calloc’ when appropriate. The function ‘scm_dynwind_free’ can be useful when memory should be freed with libc's ‘free’ when leaving a dynwind context, *Note Dynamic Wind::. -- C Function: void * scm_malloc (size_t SIZE) -- C Function: void * scm_calloc (size_t SIZE) Allocate SIZE bytes of memory and return a pointer to it. When SIZE is 0, return ‘NULL’. When not enough memory is available, signal an error. This function runs the GC to free up some memory when it deems it appropriate. The memory is allocated by the libc ‘malloc’ function and can be freed with ‘free’. There is no ‘scm_free’ function to go with ‘scm_malloc’ to make it easier to pass memory back and forth between different modules. The function ‘scm_calloc’ is similar to ‘scm_malloc’, but initializes the block of memory to zero as well. These functions will (indirectly) call ‘scm_gc_register_allocation’. -- C Function: void * scm_realloc (void *MEM, size_t NEW_SIZE) Change the size of the memory block at MEM to NEW_SIZE and return its new location. When NEW_SIZE is 0, this is the same as calling ‘free’ on MEM and ‘NULL’ is returned. When MEM is ‘NULL’, this function behaves like ‘scm_malloc’ and allocates a new block of size NEW_SIZE. When not enough memory is available, signal an error. This function runs the GC to free up some memory when it deems it appropriate. This function will call ‘scm_gc_register_allocation’. -- C Function: void * scm_gc_malloc (size_t SIZE, const char *WHAT) -- C Function: void * scm_gc_malloc_pointerless (size_t SIZE, const char *WHAT) -- C Function: void * scm_gc_realloc (void *MEM, size_t OLD_SIZE, size_t NEW_SIZE, const char *WHAT); -- C Function: void * scm_gc_calloc (size_t SIZE, const char *WHAT) Allocate SIZE bytes of automatically-managed memory. The memory is automatically freed when no longer referenced from any live memory block. When garbage collection occurs, Guile will visit the words in memory allocated with ‘scm_gc_malloc’ or ‘scm_gc_calloc’, looking for pointers to other memory allocations that are managed by the GC. In contrast, memory allocated by ‘scm_gc_malloc_pointerless’ is not scanned for pointers. The ‘scm_gc_realloc’ call preserves the "pointerlessness" of the memory area pointed to by MEM. Note that you need to pass the old size of a reallocated memory block as well. See below for a motivation. -- C Function: void scm_gc_free (void *MEM, size_t SIZE, const char *WHAT) Explicitly free the memory block pointed to by MEM, which was previously allocated by one of the above ‘scm_gc’ functions. This function is almost always unnecessary, except for codebases that still need to compile on Guile 1.8. Note that you need to explicitly pass the SIZE parameter. This is done since it should normally be easy to provide this parameter (for memory that is associated with GC controlled objects) and help keep the memory management overhead very low. However, in Guile 2.x, SIZE is always ignored. -- C Function: void scm_gc_register_allocation (size_t SIZE) Informs the garbage collector that SIZE bytes have been allocated, which the collector would otherwise not have known about. In general, Scheme will decide to collect garbage only after some amount of memory has been allocated. Calling this function will make the Scheme garbage collector know about more allocation, and thus run more often (as appropriate). It is especially important to call this function when large unmanaged allocations, like images, may be freed by small Scheme allocations, like foreign objects. -- C Function: void scm_dynwind_free (void *mem) Equivalent to ‘scm_dynwind_unwind_handler (free, MEM, SCM_F_WIND_EXPLICITLY)’. That is, the memory block at MEM will be freed (using ‘free’ from the C library) when the current dynwind is left. -- Scheme Procedure: malloc-stats Return an alist ((WHAT . N) ...) describing number of malloced objects. WHAT is the second argument to ‘scm_gc_malloc’, N is the number of objects of that type currently allocated. This function is only available if the ‘GUILE_DEBUG_MALLOC’ preprocessor macro was defined when Guile was compiled. ---------- Footnotes ---------- (1) In Guile up to version 1.8, memory allocated with ‘scm_gc_malloc’ _had_ to be freed with ‘scm_gc_free’. (2) In Guile up to 1.8, memory allocated with ‘scm_gc_malloc’ was _not_ visited by the collector in the mark phase. Consequently, the GC had to be told explicitly about pointers to live objects contained in the memory block, e.g., via SMOB mark functions (*note ‘scm_set_smob_mark’: Smobs.) 6.17.3 Weak References ---------------------- [FIXME: This chapter is based on Mikael Djurfeldt's answer to a question by Michael Livshin. Any mistakes are not theirs, of course. ] Weak references let you attach bookkeeping information to data so that the additional information automatically disappears when the original data is no longer in use and gets garbage collected. In a weak key hash, the hash entry for that key disappears as soon as the key is no longer referenced from anywhere else. For weak value hashes, the same happens as soon as the value is no longer in use. Entries in a doubly weak hash disappear when either the key or the value are not used anywhere else anymore. Object properties offer the same kind of functionality as weak key hashes in many situations. (*note Object Properties::) Here's an example (a little bit strained perhaps, but one of the examples is actually used in Guile): Assume that you're implementing a debugging system where you want to associate information about filename and position of source code expressions with the expressions themselves. Hashtables can be used for that, but if you use ordinary hash tables it will be impossible for the scheme interpreter to "forget" old source when, for example, a file is reloaded. To implement the mapping from source code expressions to positional information it is necessary to use weak-key tables since we don't want the expressions to be remembered just because they are in our table. To implement a mapping from source file line numbers to source code expressions you would use a weak-value table. To implement a mapping from source code expressions to the procedures they constitute a doubly-weak table has to be used. 6.17.3.1 Weak hash tables ......................... -- Scheme Procedure: make-weak-key-hash-table [size] -- Scheme Procedure: make-weak-value-hash-table [size] -- Scheme Procedure: make-doubly-weak-hash-table [size] -- C Function: scm_make_weak_key_hash_table (size) -- C Function: scm_make_weak_value_hash_table (size) -- C Function: scm_make_doubly_weak_hash_table (size) Return a weak hash table with SIZE buckets. As with any hash table, choosing a good size for the table requires some caution. You can modify weak hash tables in exactly the same way you would modify regular hash tables, with the exception of the routines that act on handles. Weak tables have a different implementation behind the scenes that doesn't have handles. *note Hash Tables::, for more on ‘hashq-ref’ et al. Note that in a weak-key hash table, the reference to the value is strong. This means that if the value references the key, even indirectly, the key will never be collected, which can lead to a memory leak. The reverse is true for weak value tables. -- Scheme Procedure: weak-key-hash-table? obj -- Scheme Procedure: weak-value-hash-table? obj -- Scheme Procedure: doubly-weak-hash-table? obj -- C Function: scm_weak_key_hash_table_p (obj) -- C Function: scm_weak_value_hash_table_p (obj) -- C Function: scm_doubly_weak_hash_table_p (obj) Return ‘#t’ if OBJ is the specified weak hash table. Note that a doubly weak hash table is neither a weak key nor a weak value hash table. 6.17.3.2 Weak vectors ..................... -- Scheme Procedure: make-weak-vector size [fill] -- C Function: scm_make_weak_vector (size, fill) Return a weak vector with SIZE elements. If the optional argument FILL is given, all entries in the vector will be set to FILL. The default value for FILL is the empty list. -- Scheme Procedure: weak-vector elem ... -- Scheme Procedure: list->weak-vector l -- C Function: scm_weak_vector (l) Construct a weak vector from a list: ‘weak-vector’ uses the list of its arguments while ‘list->weak-vector’ uses its only argument L (a list) to construct a weak vector the same way ‘list->vector’ would. -- Scheme Procedure: weak-vector? obj -- C Function: scm_weak_vector_p (obj) Return ‘#t’ if OBJ is a weak vector. -- Scheme Procedure: weak-vector-ref wvect k -- C Function: scm_weak_vector_ref (wvect, k) Return the Kth element of the weak vector WVECT, or ‘#f’ if that element has been collected. -- Scheme Procedure: weak-vector-set! wvect k elt -- C Function: scm_weak_vector_set_x (wvect, k, elt) Set the Kth element of the weak vector WVECT to ELT. 6.17.4 Guardians ---------------- Guardians provide a way to be notified about objects that would otherwise be collected as garbage. Guarding them prevents the objects from being collected and cleanup actions can be performed on them, for example. See R. Kent Dybvig, Carl Bruggeman, and David Eby (1993) "Guardians in a Generation-Based Garbage Collector". ACM SIGPLAN Conference on Programming Language Design and Implementation, June 1993. -- Scheme Procedure: make-guardian -- C Function: scm_make_guardian () Create a new guardian. A guardian protects a set of objects from garbage collection, allowing a program to apply cleanup or other actions. ‘make-guardian’ returns a procedure representing the guardian. Calling the guardian procedure with an argument adds the argument to the guardian's set of protected objects. Calling the guardian procedure without an argument returns one of the protected objects which are ready for garbage collection, or ‘#f’ if no such object is available. Objects which are returned in this way are removed from the guardian. You can put a single object into a guardian more than once and you can put a single object into more than one guardian. The object will then be returned multiple times by the guardian procedures. An object is eligible to be returned from a guardian when it is no longer referenced from outside any guardian. There is no guarantee about the order in which objects are returned from a guardian. If you want to impose an order on finalization actions, for example, you can do that by keeping objects alive in some global data structure until they are no longer needed for finalizing other objects. Being an element in a weak vector, a key in a hash table with weak keys, or a value in a hash table with weak values does not prevent an object from being returned by a guardian. But as long as an object can be returned from a guardian it will not be removed from such a weak vector or hash table. In other words, a weak link does not prevent an object from being considered collectible, but being inside a guardian prevents a weak link from being broken. A key in a weak key hash table can be thought of as having a strong reference to its associated value as long as the key is accessible. Consequently, when the key is only accessible from within a guardian, the reference from the key to the value is also considered to be coming from within a guardian. Thus, if there is no other reference to the value, it is eligible to be returned from a guardian. 6.18 Modules ============ When programs become large, naming conflicts can occur when a function or global variable defined in one file has the same name as a function or global variable in another file. Even just a _similarity_ between function names can cause hard-to-find bugs, since a programmer might type the wrong function name. The approach used to tackle this problem is called _information encapsulation_, which consists of packaging functional units into a given name space that is clearly separated from other name spaces. The language features that allow this are usually called _the module system_ because programs are broken up into modules that are compiled separately (or loaded separately in an interpreter). Older languages, like C, have limited support for name space manipulation and protection. In C a variable or function is public by default, and can be made local to a module with the ‘static’ keyword. But you cannot reference public variables and functions from another module with different names. More advanced module systems have become a common feature in recently designed languages: ML, Python, Perl, and Modula 3 all allow the _renaming_ of objects from a foreign module, so they will not clutter the global name space. In addition, Guile offers variables as first-class objects. They can be used for interacting with the module system. 6.18.1 General Information about Modules ---------------------------------------- A Guile module can be thought of as a collection of named procedures, variables and macros. More precisely, it is a set of “bindings” of symbols (names) to Scheme objects. Within a module, all bindings are visible. Certain bindings can be declared “public”, in which case they are added to the module's so-called “export list”; this set of public bindings is called the module's “public interface” (*note Creating Guile Modules::). A client module “uses” a providing module's bindings by either accessing the providing module's public interface, or by building a custom interface (and then accessing that). In a custom interface, the client module can “select” which bindings to access and can also algorithmically “rename” bindings. In contrast, when using the providing module's public interface, the entire export list is available without renaming (*note Using Guile Modules::). All Guile modules have a unique “module name”, for example ‘(ice-9 popen)’ or ‘(srfi srfi-11)’. Module names are lists of one or more symbols. When Guile goes to use an interface from a module, for example ‘(ice-9 popen)’, Guile first looks to see if it has loaded ‘(ice-9 popen)’ for any reason. If the module has not been loaded yet, Guile searches a “load path” for a file that might define it, and loads that file. The following subsections go into more detail on using, creating, installing, and otherwise manipulating modules and the module system. 6.18.2 Using Guile Modules -------------------------- To use a Guile module is to access either its public interface or a custom interface (*note General Information about Modules::). Both types of access are handled by the syntactic form ‘use-modules’, which accepts one or more interface specifications and, upon evaluation, arranges for those interfaces to be available to the current module. This process may include locating and loading code for a given module if that code has not yet been loaded, following ‘%load-path’ (*note Modules and the File System::). An “interface specification” has one of two forms. The first variation is simply to name the module, in which case its public interface is the one accessed. For example: (use-modules (ice-9 popen)) Here, the interface specification is ‘(ice-9 popen)’, and the result is that the current module now has access to ‘open-pipe’, ‘close-pipe’, ‘open-input-pipe’, and so on (*note Pipes::). Note in the previous example that if the current module had already defined ‘open-pipe’, that definition would be overwritten by the definition in ‘(ice-9 popen)’. For this reason (and others), there is a second variation of interface specification that not only names a module to be accessed, but also selects bindings from it and renames them to suit the current module's needs. For example: (use-modules ((ice-9 popen) #:select ((open-pipe . pipe-open) close-pipe) #:renamer (symbol-prefix-proc 'unixy:))) or more simply: (use-modules ((ice-9 popen) #:select ((open-pipe . pipe-open) close-pipe) #:prefix unixy:)) Here, the interface specification is more complex than before, and the result is that a custom interface with only two bindings is created and subsequently accessed by the current module. The mapping of old to new names is as follows: (ice-9 popen) sees: current module sees: open-pipe unixy:pipe-open close-pipe unixy:close-pipe This example also shows how to use the convenience procedure ‘symbol-prefix-proc’. You can also directly refer to bindings in a module by using the ‘@’ syntax. For example, instead of using the ‘use-modules’ statement from above and writing ‘unixy:pipe-open’ to refer to the ‘pipe-open’ from the ‘(ice-9 popen)’, you could also write ‘(@ (ice-9 popen) open-pipe)’. Thus an alternative to the complete ‘use-modules’ statement would be (define unixy:pipe-open (@ (ice-9 popen) open-pipe)) (define unixy:close-pipe (@ (ice-9 popen) close-pipe)) There is also ‘@@’, which can be used like ‘@’, but does not check whether the variable that is being accessed is actually exported. Thus, ‘@@’ can be thought of as the impolite version of ‘@’ and should only be used as a last resort or for debugging, for example. Note that just as with a ‘use-modules’ statement, any module that has not yet been loaded will be loaded when referenced by a ‘@’ or ‘@@’ form. You can also use the ‘@’ and ‘@@’ syntaxes as the target of a ‘set!’ when the binding refers to a variable. -- Scheme Procedure: symbol-prefix-proc prefix-sym Return a procedure that prefixes its arg (a symbol) with PREFIX-SYM. -- syntax: use-modules spec ... Resolve each interface specification SPEC into an interface and arrange for these to be accessible by the current module. The return value is unspecified. SPEC can be a list of symbols, in which case it names a module whose public interface is found and used. SPEC can also be of the form: (MODULE-NAME [#:select SELECTION] [#:prefix PREFIX] [#:renamer RENAMER]) in which case a custom interface is newly created and used. MODULE-NAME is a list of symbols, as above; SELECTION is a list of selection-specs; PREFIX is a symbol that is prepended to imported names; and RENAMER is a procedure that takes a symbol and returns its new name. A selection-spec is either a symbol or a pair of symbols ‘(ORIG . SEEN)’, where ORIG is the name in the used module and SEEN is the name in the using module. Note that SEEN is also modified by PREFIX and RENAMER. The ‘#:select’, ‘#:prefix’, and ‘#:renamer’ clauses are optional. If all are omitted, the returned interface has no bindings. If the ‘#:select’ clause is omitted, PREFIX and RENAMER operate on the used module's public interface. In addition to the above, SPEC can also include a ‘#:version’ clause, of the form: #:version VERSION-SPEC where VERSION-SPEC is an R6RS-compatible version reference. An error will be signaled in the case in which a module with the same name has already been loaded, if that module specifies a version and that version is not compatible with VERSION-SPEC. *Note R6RS Version References::, for more on version references. If the module name is not resolvable, ‘use-modules’ will signal an error. -- syntax: @ module-name binding-name Refer to the binding named BINDING-NAME in module MODULE-NAME. The binding must have been exported by the module. -- syntax: @@ module-name binding-name Refer to the binding named BINDING-NAME in module MODULE-NAME. The binding must not have been exported by the module. This syntax is only intended for debugging purposes or as a last resort. *Note Declarative Modules::, for some limitations on the use of ‘@@’. 6.18.3 Creating Guile Modules ----------------------------- When you want to create your own modules, you have to take the following steps: • Create a Scheme source file and add all variables and procedures you wish to export, or which are required by the exported procedures. • Add a ‘define-module’ form at the beginning. • Export all bindings which should be in the public interface, either by using ‘define-public’ or ‘export’ (both documented below). -- syntax: define-module module-name option ... MODULE-NAME is a list of one or more symbols. (define-module (ice-9 popen)) ‘define-module’ makes this module available to Guile programs under the given MODULE-NAME. OPTION ... are keyword/value pairs which specify more about the defined module. The recognized options and their meaning are shown in the following table. ‘#:use-module INTERFACE-SPECIFICATION’ Equivalent to a ‘(use-modules INTERFACE-SPECIFICATION)’ (*note Using Guile Modules::). ‘#:autoload MODULE SYMBOL-LIST’ Load MODULE when any of SYMBOL-LIST are accessed. For example, (define-module (my mod) #:autoload (srfi srfi-1) (partition delete-duplicates)) ... (when something (set! foo (delete-duplicates ...))) When a module is autoloaded, only the bindings in SYMBOL-LIST become available(1). An autoload is a good way to put off loading a big module until it's really needed, for instance for faster startup or if it will only be needed in certain circumstances. ‘#:export LIST’ Export all identifiers in LIST which must be a list of symbols or pairs of symbols. This is equivalent to ‘(export LIST)’ in the module body. ‘#:re-export LIST’ Re-export all identifiers in LIST which must be a list of symbols or pairs of symbols. The symbols in LIST must be imported by the current module from other modules. This is equivalent to ‘re-export’ below. ‘#:replace LIST’ Export all identifiers in LIST (a list of symbols or pairs of symbols) and mark them as “replacing bindings”. In the module user's name space, this will have the effect of replacing any binding with the same name that is not also "replacing". Normally a replacement results in an "override" warning message, ‘#:replace’ avoids that. In general, a module that exports a binding for which the ‘(guile)’ module already has a definition should use ‘#:replace’ instead of ‘#:export’. ‘#:replace’, in a sense, lets Guile know that the module _purposefully_ replaces a core binding. It is important to note, however, that this binding replacement is confined to the name space of the module user. In other words, the value of the core binding in question remains unchanged for other modules. Note that although it is often a good idea for the replaced binding to remain compatible with a binding in ‘(guile)’, to avoid surprising the user, sometimes the bindings will be incompatible. For example, SRFI-19 exports its own version of ‘current-time’ (*note SRFI-19 Time::) which is not compatible with the core ‘current-time’ function (*note Time::). Guile assumes that a user importing a module knows what she is doing, and uses ‘#:replace’ for this binding rather than ‘#:export’. A ‘#:replace’ clause is equivalent to ‘(export! LIST)’ in the module body. The ‘#:duplicates’ (see below) provides fine-grain control about duplicate binding handling on the module-user side. ‘#:re-export-and-replace LIST’ Like ‘#:re-export’, but also marking the bindings as replacements in the sense of ‘#:replace’. ‘#:version LIST’ Specify a version for the module in the form of LIST, a list of zero or more exact, non-negative integers. The corresponding ‘#:version’ option in the ‘use-modules’ form allows callers to restrict the value of this option in various ways. ‘#:duplicates LIST’ Tell Guile to handle duplicate bindings for the bindings imported by the current module according to the policy defined by LIST, a list of symbols. LIST must contain symbols representing a duplicate binding handling policy chosen among the following: ‘check’ Raises an error when a binding is imported from more than one place. ‘warn’ Issue a warning when a binding is imported from more than one place and leave the responsibility of actually handling the duplication to the next duplicate binding handler. ‘replace’ When a new binding is imported that has the same name as a previously imported binding, then do the following: 1. If the old binding was said to be “replacing” (via the ‘#:replace’ option above) and the new binding is not replacing, the keep the old binding. 2. If the old binding was not said to be replacing and the new binding is replacing, then replace the old binding with the new one. 3. If neither the old nor the new binding is replacing, then keep the old one. ‘warn-override-core’ Issue a warning when a core binding is being overwritten and actually override the core binding with the new one. ‘first’ In case of duplicate bindings, the firstly imported binding is always the one which is kept. ‘last’ In case of duplicate bindings, the lastly imported binding is always the one which is kept. ‘noop’ In case of duplicate bindings, leave the responsibility to the next duplicate handler. If LIST contains more than one symbol, then the duplicate binding handlers which appear first will be used first when resolving a duplicate binding situation. As mentioned above, some resolution policies may explicitly leave the responsibility of handling the duplication to the next handler in LIST. If GOOPS has been loaded before the ‘#:duplicates’ clause is processed, there are additional strategies available for dealing with generic functions. *Note Merging Generics::, for more information. The default duplicate binding resolution policy is given by the ‘default-duplicate-binding-handler’ procedure, and is (replace warn-override-core warn last) ‘#:pure’ Create a “pure” module, that is a module which does not contain any of the standard procedure bindings except for the syntax forms. This is useful if you want to create “safe” modules, that is modules which do not know anything about dangerous procedures. -- syntax: export variable ... Add all VARIABLEs (which must be symbols or pairs of symbols) to the list of exported bindings of the current module. If VARIABLE is a pair, its ‘car’ gives the name of the variable as seen by the current module and its ‘cdr’ specifies a name for the binding in the current module's public interface. -- syntax: define-public ... Equivalent to ‘(begin (define foo ...) (export foo))’. -- syntax: re-export variable ... Add all VARIABLEs (which must be symbols or pairs of symbols) to the list of re-exported bindings of the current module. Pairs of symbols are handled as in ‘export’. Re-exported bindings must be imported by the current module from some other module. -- syntax: export! variable ... Like ‘export’, but marking the exported variables as replacing. Using a module with replacing bindings will cause any existing bindings to be replaced without issuing any warnings. See the discussion of ‘#:replace’ above. ---------- Footnotes ---------- (1) In Guile 2.2 and earlier, _all_ the module bindings would become available; SYMBOL-LIST was just the list of bindings that will first trigger the load. 6.18.4 Modules and the File System ---------------------------------- Typical programs only use a small subset of modules installed on a Guile system. In order to keep startup time down, Guile only loads modules when a program uses them, on demand. When a program evaluates ‘(use-modules (ice-9 popen))’, and the module is not loaded, Guile searches for a conventionally-named file in the “load path”. In this case, loading ‘(ice-9 popen)’ will eventually cause Guile to run ‘(primitive-load-path "ice-9/popen")’. ‘primitive-load-path’ will search for a file ‘ice-9/popen’ in the ‘%load-path’ (*note Load Paths::). For each directory in ‘%load-path’, Guile will try to find the file name, concatenated with the extensions from ‘%load-extensions’. By default, this will cause Guile to ‘stat’ ‘ice-9/popen.scm’, and then ‘ice-9/popen’. *Note Load Paths::, for more on ‘primitive-load-path’. If a corresponding compiled ‘.go’ file is found in the ‘%load-compiled-path’ or in the fallback path, and is as fresh as the source file, it will be loaded instead of the source file. If no compiled file is found, Guile may try to compile the source file and cache away the resulting ‘.go’ file. *Note Compilation::, for more on compilation. Once Guile finds a suitable source or compiled file is found, the file will be loaded. If, after loading the file, the module under consideration is still not defined, Guile will signal an error. For more information on where and how to install Scheme modules, *Note Installing Site Packages::. 6.18.5 R6RS Version References ------------------------------ Guile's module system includes support for locating modules based on a declared version specifier of the same form as the one described in R6RS (*note R6RS Library Form: (r6rs)Library form.). By using the ‘#:version’ keyword in a ‘define-module’ form, a module may specify a version as a list of zero or more exact, non-negative integers. This version can then be used to locate the module during the module search process. Client modules and callers of the ‘use-modules’ function may specify constraints on the versions of target modules by providing a “version reference”, which has one of the following forms: (SUB-VERSION-REFERENCE ...) (and VERSION-REFERENCE ...) (or VERSION-REFERENCE ...) (not VERSION-REFERENCE) in which SUB-VERSION-REFERENCE is in turn one of: (SUB-VERSION) (>= SUB-VERSION) (<= SUB-VERSION) (and SUB-VERSION-REFERENCE ...) (or SUB-VERSION-REFERENCE ...) (not SUB-VERSION-REFERENCE) in which SUB-VERSION is an exact, non-negative integer as above. A version reference matches a declared module version if each element of the version reference matches a corresponding element of the module version, according to the following rules: • The ‘and’ sub-form matches a version or version element if every element in the tail of the sub-form matches the specified version or version element. • The ‘or’ sub-form matches a version or version element if any element in the tail of the sub-form matches the specified version or version element. • The ‘not’ sub-form matches a version or version element if the tail of the sub-form does not match the version or version element. • The ‘>=’ sub-form matches a version element if the element is greater than or equal to the SUB-VERSION in the tail of the sub-form. • The ‘<=’ sub-form matches a version element if the version is less than or equal to the SUB-VERSION in the tail of the sub-form. • A SUB-VERSION matches a version element if one is EQV? to the other. For example, a module declared as: (define-module (mylib mymodule) #:version (1 2 0)) would be successfully loaded by any of the following ‘use-modules’ expressions: (use-modules ((mylib mymodule) #:version (1 2 (>= 0)))) (use-modules ((mylib mymodule) #:version (or (1 2 0) (1 2 1)))) (use-modules ((mylib mymodule) #:version ((and (>= 1) (not 2)) 2 0))) 6.18.6 R6RS Libraries --------------------- In addition to the API described in the previous sections, you also have the option to create modules using the portable ‘library’ form described in R6RS (*note R6RS Library Form: (r6rs)Library form.), and to import libraries created in this format by other programmers. Guile's R6RS library implementation takes advantage of the flexibility built into the module system by expanding the R6RS library form into a corresponding Guile ‘define-module’ form that specifies equivalent import and export requirements and includes the same body expressions. The library expression: (library (mylib (1 2)) (export mybinding) (import (otherlib (3)))) is equivalent to the module definition: (define-module (mylib) #:version (1 2) #:use-module ((otherlib) #:version (3)) #:export (mybinding)) Central to the mechanics of R6RS libraries is the concept of import and export “levels”, which control the visibility of bindings at various phases of a library's lifecycle -- macros necessary to expand forms in the library's body need to be available at expand time; variables used in the body of a procedure exported by the library must be available at runtime. R6RS specifies the optional ‘for’ sub-form of an _import set_ specification (see below) as a mechanism by which a library author can indicate that a particular library import should take place at a particular phase with respect to the lifecycle of the importing library. Guile's library implementation uses a technique called “implicit phasing” (first described by Abdulaziz Ghuloum and R. Kent Dybvig), which allows the expander and compiler to automatically determine the necessary visibility of a binding imported from another library. As such, the ‘for’ sub-form described below is ignored by Guile (but may be required by Schemes in which phasing is explicit). -- Scheme Syntax: library name (export export-spec ...) (import import-spec ...) body ... Defines a new library with the specified name, exports, and imports, and evaluates the specified body expressions in this library's environment. The library NAME is a non-empty list of identifiers, optionally ending with a version specification of the form described above (*note Creating Guile Modules::). Each EXPORT-SPEC is the name of a variable defined or imported by the library, or must take the form ‘(rename (internal-name external-name) ...)’, where the identifier INTERNAL-NAME names a variable defined or imported by the library and EXTERNAL-NAME is the name by which the variable is seen by importing libraries. Each IMPORT-SPEC must be either an “import set” (see below) or must be of the form ‘(for import-set import-level ...)’, where each IMPORT-LEVEL is one of: run expand (meta LEVEL) where LEVEL is an integer. Note that since Guile does not require explicit phase specification, any IMPORT-SETs found inside of ‘for’ sub-forms will be "unwrapped" during expansion and processed as if they had been specified directly. Import sets in turn take one of the following forms: LIBRARY-REFERENCE (library LIBRARY-REFERENCE) (only IMPORT-SET IDENTIFIER ...) (except IMPORT-SET IDENTIFIER ...) (prefix IMPORT-SET IDENTIFIER) (rename IMPORT-SET (INTERNAL-IDENTIFIER EXTERNAL-IDENTIFIER) ...) where LIBRARY-REFERENCE is a non-empty list of identifiers ending with an optional version reference (*note R6RS Version References::), and the other sub-forms have the following semantics, defined recursively on nested IMPORT-SETs: • The ‘library’ sub-form is used to specify libraries for import whose names begin with the identifier "library." • The ‘only’ sub-form imports only the specified IDENTIFIERs from the given IMPORT-SET. • The ‘except’ sub-form imports all of the bindings exported by IMPORT-SET except for those that appear in the specified list of IDENTIFIERs. • The ‘prefix’ sub-form imports all of the bindings exported by IMPORT-SET, first prefixing them with the specified IDENTIFIER. • The ‘rename’ sub-form imports all of the identifiers exported by IMPORT-SET. The binding for each INTERNAL-IDENTIFIER among these identifiers is made visible to the importing library as the corresponding EXTERNAL-IDENTIFIER; all other bindings are imported using the names provided by IMPORT-SET. Note that because Guile translates R6RS libraries into module definitions, an import specification may be used to declare a dependency on a native Guile module -- although doing so may make your libraries less portable to other Schemes. -- Scheme Syntax: import import-spec ... Import into the current environment the libraries specified by the given import specifications, where each IMPORT-SPEC takes the same form as in the ‘library’ form described above. 6.18.7 Variables ---------------- Each module has its own hash table, sometimes known as an “obarray”, that maps the names defined in that module to their corresponding variable objects. A variable is a box-like object that can hold any Scheme value. It is said to be “undefined” if its box holds a special Scheme value that denotes undefined-ness (which is different from all other Scheme values, including for example ‘#f’); otherwise the variable is “defined”. On its own, a variable object is anonymous. A variable is said to be “bound” when it is associated with a name in some way, usually a symbol in a module obarray. When this happens, the name is said to be bound to the variable, in that module. (That's the theory, anyway. In practice, defined-ness and bound-ness sometimes get confused, because Lisp and Scheme implementations have often conflated -- or deliberately drawn no distinction between -- a name that is unbound and a name that is bound to a variable whose value is undefined. We will try to be clear about the difference and explain any confusion where it is unavoidable.) Variables do not have a read syntax. Most commonly they are created and bound implicitly by ‘define’ expressions: a top-level ‘define’ expression of the form (define NAME VALUE) creates a variable with initial value VALUE and binds it to the name NAME in the current module. But they can also be created dynamically by calling one of the constructor procedures ‘make-variable’ and ‘make-undefined-variable’. -- Scheme Procedure: make-undefined-variable -- C Function: scm_make_undefined_variable () Return a variable that is initially unbound. -- Scheme Procedure: make-variable init -- C Function: scm_make_variable (init) Return a variable initialized to value INIT. -- Scheme Procedure: variable-bound? var -- C Function: scm_variable_bound_p (var) Return ‘#t’ if VAR is bound to a value, or ‘#f’ otherwise. Throws an error if VAR is not a variable object. -- Scheme Procedure: variable-ref var -- C Function: scm_variable_ref (var) Dereference VAR and return its value. VAR must be a variable object; see ‘make-variable’ and ‘make-undefined-variable’. -- Scheme Procedure: variable-set! var val -- C Function: scm_variable_set_x (var, val) Set the value of the variable VAR to VAL. VAR must be a variable object, VAL can be any value. Return an unspecified value. -- Scheme Procedure: variable-unset! var -- C Function: scm_variable_unset_x (var) Unset the value of the variable VAR, leaving VAR unbound. -- Scheme Procedure: variable? obj -- C Function: scm_variable_p (obj) Return ‘#t’ if OBJ is a variable object, else return ‘#f’. 6.18.8 Module System Reflection ------------------------------- The previous sections have described a declarative view of the module system. You can also work with it programmatically by accessing and modifying various parts of the Scheme objects that Guile uses to implement the module system. At any time, there is a “current module”. This module is the one where a top-level ‘define’ and similar syntax will add new bindings. You can find other module objects with ‘resolve-module’, for example. These module objects can be used as the second argument to ‘eval’. -- Scheme Procedure: current-module -- C Function: scm_current_module () Return the current module object. -- Scheme Procedure: set-current-module module -- C Function: scm_set_current_module (module) Set the current module to MODULE and return the previous current module. -- Scheme Procedure: save-module-excursion thunk Call THUNK within a ‘dynamic-wind’ such that the module that is current at invocation time is restored when THUNK's dynamic extent is left (*note Dynamic Wind::). More precisely, if THUNK escapes non-locally, the current module (at the time of escape) is saved, and the original current module (at the time THUNK's dynamic extent was last entered) is restored. If THUNK's dynamic extent is re-entered, then the current module is saved, and the previously saved inner module is set current again. -- Scheme Procedure: resolve-module name [autoload=#t] [version=#f] [#:ensure=#t] -- C Function: scm_resolve_module (name) Find the module named NAME and return it. When it has not already been defined and AUTOLOAD is true, try to auto-load it. When it can't be found that way either, create an empty module if ENSURE is true, otherwise return ‘#f’. If VERSION is true, ensure that the resulting module is compatible with the given version reference (*note R6RS Version References::). The name is a list of symbols. -- Scheme Procedure: resolve-interface name [#:select=#f] [#:hide='()] [#:prefix=#f] [#:renamer=#f] [#:version=#f] Find the module named NAME as with ‘resolve-module’ and return its interface. The interface of a module is also a module object, but it contains only the exported bindings. -- Scheme Procedure: module-uses module Return a list of the interfaces used by MODULE. -- Scheme Procedure: module-use! module interface Add INTERFACE to the front of the use-list of MODULE. Both arguments should be module objects, and INTERFACE should very likely be a module returned by ‘resolve-interface’. -- Scheme Procedure: reload-module module Revisit the source file that corresponds to MODULE. Raises an error if no source file is associated with the given module. As mentioned in the previous section, modules contain a mapping between identifiers (as symbols) and storage locations (as variables). Guile defines a number of procedures to allow access to this mapping. If you are programming in C, *note Accessing Modules from C::. -- Scheme Procedure: module-variable module name Return the variable bound to NAME (a symbol) in MODULE, or ‘#f’ if NAME is unbound. -- Scheme Procedure: module-add! module name var Define a new binding between NAME (a symbol) and VAR (a variable) in MODULE. -- Scheme Procedure: module-ref module name Look up the value bound to NAME in MODULE. Like ‘module-variable’, but also does a ‘variable-ref’ on the resulting variable, raising an error if NAME is unbound. -- Scheme Procedure: module-define! module name value Locally bind NAME to VALUE in MODULE. If NAME was already locally bound in MODULE, i.e., defined locally and not by an imported module, the value stored in the existing variable will be updated. Otherwise, a new variable will be added to the module, via ‘module-add!’. -- Scheme Procedure: module-set! module name value Update the binding of NAME in MODULE to VALUE, raising an error if NAME is not already bound in MODULE. There are many other reflective procedures available in the default environment. If you find yourself using one of them, please contact the Guile developers so that we can commit to stability for that interface. 6.18.9 Declarative Modules -------------------------- The first-class access to modules and module variables described in the previous subsection is very powerful and allows Guile users to build many tools to dynamically learn things about their Guile systems. However, as Scheme godparent Mathias Felleisen wrote in "On the Expressive Power of Programming Languages", a more expressive language is necessarily harder to reason about. There are transformations that Guile's compiler would like to make which can't be done if every top-level definition is subject to mutation at any time. Consider this module: (define-module (boxes) #:export (make-box box-ref box-set! box-swap!)) (define (make-box x) (list x)) (define (box-ref box) (car box)) (define (box-set! box x) (set-car! box x)) (define (box-swap! box x) (let ((y (box-ref box))) (box-set! box x) y)) Ideally you'd like for the ‘box-ref’ in ‘box-swap!’ to be inlined to ‘car’. Guile's compiler can do this, but only if it knows that ‘box-ref’'s definition is what it appears to be in the text. However, in the general case it could be that a programmer could reach into the ‘(boxes)’ module at any time and change the value of ‘box-ref’. To allow Guile to reason about the values of top-levels from a module, a module can be marked as “declarative”. This flag applies only to the subset of top-level definitions that are themselves declarative: those that are defined within the compilation unit, and not assigned (‘set!’) or redefined within the compilation unit. To explicitly mark a module as being declarative, pass the ‘#:declarative?’ keyword argument when declaring a module: (define-module (boxes) #:export (make-box box-ref box-set! box-swap!) #:declarative? #t) By default, modules are compiled declaratively if the ‘user-modules-declarative?’ parameter is true when the module is compiled. -- Scheme Parameter: user-modules-declarative? A boolean indicating whether definitions in modules created by ‘define-module’ or implicitly as part of a compilation unit without an explicit module can be treated as declarative. Because it's usually what you want, the default value of ‘user-modules-declarative?’ is ‘#t’. Should I Mark My Module As Declarative? ....................................... In the vast majority of use cases, declarative modules are what you want. However, there are exceptions. Consider the ‘(boxes)’ module above. Let's say you want to be able to go in and change the definition of ‘box-set!’ at run-time: scheme@(guile-user)> (use-modules (boxes)) scheme@(guile-user)> ,module boxes scheme@(boxes)> (define (box-set! x y) (set-car! x (pk y))) However, considering that ‘(boxes)’ is a declarative module, it could be that ‘box-swap!’ inlined the call to ‘box-set!’ - so it may be that you are surprised if you call ‘(box-swap! x y)’ and you don't see the new definition being used. (Note, however, that Guile has no guarantees about what definitions its compiler will or will not inline.) If you want to allow the definition of ‘box-set!’ to be changed and to have all of its uses updated, then probably the best option is to edit the module and reload the whole thing: scheme@(guile-user)> ,reload (boxes) The advantage of the reloading approach is that you maintain the optimizations that declarative modules enable, while also being able to live-update the code. If the module keeps precious program state, those definitions can be marked as ‘define-once’ to prevent reloads from overwriting them. *Note Top Level::, for more on ‘define-once’. Incidentally, ‘define-once’ also prevents declarative-definition optimizations, so if there's a limited subset of redefinable bindings, ‘define-once’ could be an interesting tool to mark those definitions as works-in-progress for interactive program development. To users, whether a module is declarative or not is mostly immaterial: besides normal use via ‘use-modules’, users can reference and redefine public or private bindings programmatically or interactively. The only difference is that changing a declarative definition may not change all of its uses. If this use-case is important to you, and if reloading whole modules is insufficient, then you can mark all definitions in a module as non-declarative by adding ‘#:declarative? #f’ to the module definition. The default of whether modules are declarative or not can be controlled via the ‘(user-modules-declarative?)’ parameter mentioned above, but care should be taken to set this parameter when the modules are compiled, e.g. via ‘(eval-when (expand) (user-modules-declarative? #f))’. *Note Eval When::. Alternately you can prevent declarative-definition optimizations by compiling at the ‘-O1’ optimization level instead of the default ‘-O2’, or via explicitly passing ‘-Ono-letrectify’ to the ‘guild compile’ invocation. *Note Compilation::, for more on compiler options. One final note. Currently, definitions from declarative modules can only be inlined within the module they are defined in, and within a compilation unit. This may change in the future to allow Guile to inline imported declarative definitions as well (cross-module inlining). To Guile, whether a definition is inlinable or not is a property of the definition, not its use. We hope to improve compiler tooling in the future to allow the user to identify definitions that are out of date when a declarative binding is redefined. 6.18.10 Accessing Modules from C -------------------------------- The last sections have described how modules are used in Scheme code, which is the recommended way of creating and accessing modules. You can also work with modules from C, but it is more cumbersome. The following procedures are available. -- C Function: SCM scm_c_call_with_current_module (SCM MODULE, SCM (*FUNC)(void *), void *DATA) Call FUNC and make MODULE the current module during the call. The argument DATA is passed to FUNC. The return value of ‘scm_c_call_with_current_module’ is the return value of FUNC. -- C Function: SCM scm_public_variable (SCM MODULE_NAME, SCM NAME) -- C Function: SCM scm_c_public_variable (const char *MODULE_NAME, const char *NAME) Find a the variable bound to the symbol NAME in the public interface of the module named MODULE_NAME. MODULE_NAME should be a list of symbols, when represented as a Scheme object, or a space-separated string, in the ‘const char *’ case. See ‘scm_c_define_module’ below, for more examples. Signals an error if no module was found with the given name. If NAME is not bound in the module, just returns ‘#f’. -- C Function: SCM scm_private_variable (SCM MODULE_NAME, SCM NAME) -- C Function: SCM scm_c_private_variable (const char *MODULE_NAME, const char *NAME) Like ‘scm_public_variable’, but looks in the internals of the module named MODULE_NAME instead of the public interface. Logically, these procedures should only be called on modules you write. -- C Function: SCM scm_public_lookup (SCM MODULE_NAME, SCM NAME) -- C Function: SCM scm_c_public_lookup (const char *MODULE_NAME, const char *NAME) -- C Function: SCM scm_private_lookup (SCM MODULE_NAME, SCM NAME) -- C Function: SCM scm_c_private_lookup (const char *MODULE_NAME, const char *NAME) Like ‘scm_public_variable’ or ‘scm_private_variable’, but if the NAME is not bound in the module, signals an error. Returns a variable, always. static SCM eval_string_var; /* NOTE: It is important that the call to 'my_init' happens-before all calls to 'my_eval_string'. */ void my_init (void) { eval_string_var = scm_c_public_lookup ("ice-9 eval-string", "eval-string"); } SCM my_eval_string (SCM str) { return scm_call_1 (scm_variable_ref (eval_string_var), str); } -- C Function: SCM scm_public_ref (SCM MODULE_NAME, SCM NAME) -- C Function: SCM scm_c_public_ref (const char *MODULE_NAME, const char *NAME) -- C Function: SCM scm_private_ref (SCM MODULE_NAME, SCM NAME) -- C Function: SCM scm_c_private_ref (const char *MODULE_NAME, const char *NAME) Like ‘scm_public_lookup’ or ‘scm_private_lookup’, but additionally dereferences the variable. If the variable object is unbound, signals an error. Returns the value bound to NAME in MODULE_NAME. In addition, there are a number of other lookup-related procedures. We suggest that you use the ‘scm_public_’ and ‘scm_private_’ family of procedures instead, if possible. -- C Function: SCM scm_c_lookup (const char *NAME) Return the variable bound to the symbol indicated by NAME in the current module. If there is no such binding or the symbol is not bound to a variable, signal an error. -- C Function: SCM scm_lookup (SCM NAME) Like ‘scm_c_lookup’, but the symbol is specified directly. -- C Function: SCM scm_c_module_lookup (SCM MODULE, const char *NAME) -- C Function: SCM scm_module_lookup (SCM MODULE, SCM NAME) Like ‘scm_c_lookup’ and ‘scm_lookup’, but the specified module is used instead of the current one. -- C Function: SCM scm_module_variable (SCM MODULE, SCM NAME) Like ‘scm_module_lookup’, but if the binding does not exist, just returns ‘#f’ instead of raising an error. To define a value, use ‘scm_define’: -- C Function: SCM scm_c_define (const char *NAME, SCM VAL) Bind the symbol indicated by NAME to a variable in the current module and set that variable to VAL. When NAME is already bound to a variable, use that. Else create a new variable. -- C Function: SCM scm_define (SCM NAME, SCM VAL) Like ‘scm_c_define’, but the symbol is specified directly. -- C Function: SCM scm_c_module_define (SCM MODULE, const char *NAME, SCM VAL) -- C Function: SCM scm_module_define (SCM MODULE, SCM NAME, SCM VAL) Like ‘scm_c_define’ and ‘scm_define’, but the specified module is used instead of the current one. In some rare cases, you may need to access the variable that ‘scm_module_define’ would have accessed, without changing the binding of the existing variable, if one is present. In that case, use ‘scm_module_ensure_local_variable’: -- C Function: SCM scm_module_ensure_local_variable (SCM MODULE, SCM SYM) Like ‘scm_module_define’, but if the SYM is already locally bound in that module, the variable's existing binding is not reset. Returns a variable. -- C Function: SCM scm_module_reverse_lookup (SCM MODULE, SCM VARIABLE) Find the symbol that is bound to VARIABLE in MODULE. When no such binding is found, return ‘#f’. -- C Function: SCM scm_c_define_module (const char *NAME, void (*INIT)(void *), void *DATA) Define a new module named NAME and make it current while INIT is called, passing it DATA. Return the module. The parameter NAME is a string with the symbols that make up the module name, separated by spaces. For example, ‘"foo bar"’ names the module ‘(foo bar)’. When there already exists a module named NAME, it is used unchanged, otherwise, an empty module is created. -- C Function: SCM scm_c_resolve_module (const char *NAME) Find the module name NAME and return it. When it has not already been defined, try to auto-load it. When it can't be found that way either, create an empty module. The name is interpreted as for ‘scm_c_define_module’. -- C Function: SCM scm_c_use_module (const char *NAME) Add the module named NAME to the uses list of the current module, as with ‘(use-modules NAME)’. The name is interpreted as for ‘scm_c_define_module’. -- C Function: void scm_c_export (const char *NAME, ...) Add the bindings designated by NAME, ... to the public interface of the current module. The list of names is terminated by ‘NULL’. 6.18.11 provide and require --------------------------- Aubrey Jaffer, mostly to support his portable Scheme library SLIB, implemented a provide/require mechanism for many Scheme implementations. Library files in SLIB _provide_ a feature, and when user programs _require_ that feature, the library file is loaded in. For example, the file ‘random.scm’ in the SLIB package contains the line (provide 'random) so to use its procedures, a user would type (require 'random) and they would magically become available, _but still have the same names!_ So this method is nice, but not as good as a full-featured module system. When SLIB is used with Guile, provide and require can be used to access its facilities. 6.18.12 Environments -------------------- Scheme, as defined in R5RS, does _not_ have a full module system. However it does define the concept of a top-level “environment”. Such an environment maps identifiers (symbols) to Scheme objects such as procedures and lists: *note About Closure::. In other words, it implements a set of “bindings”. Environments in R5RS can be passed as the second argument to ‘eval’ (*note Fly Evaluation::). Three procedures are defined to return environments: ‘scheme-report-environment’, ‘null-environment’ and ‘interaction-environment’ (*note Fly Evaluation::). In addition, in Guile any module can be used as an R5RS environment, i.e., passed as the second argument to ‘eval’. Note: the following two procedures are available only when the ‘(ice-9 r5rs)’ module is loaded: (use-modules (ice-9 r5rs)) -- Scheme Procedure: scheme-report-environment version -- Scheme Procedure: null-environment version VERSION must be the exact integer '5', corresponding to revision 5 of the Scheme report (the Revised^5 Report on Scheme). ‘scheme-report-environment’ returns a specifier for an environment that is empty except for all bindings defined in the report that are either required or both optional and supported by the implementation. ‘null-environment’ returns a specifier for an environment that is empty except for the (syntactic) bindings for all syntactic keywords defined in the report that are either required or both optional and supported by the implementation. Currently Guile does not support values of VERSION for other revisions of the report. The effect of assigning (through the use of ‘eval’) a variable bound in a ‘scheme-report-environment’ (for example ‘car’) is unspecified. Currently the environments specified by ‘scheme-report-environment’ are not immutable in Guile. 6.19 Foreign Function Interface =============================== Sometimes you need to use libraries written in C or Rust or some other non-Scheme language. More rarely, you might need to write some C to extend Guile. This section describes how to load these "foreign libraries", look up data and functions inside them, and so on. 6.19.1 Foreign Libraries ------------------------ Just as Guile can load up Scheme libraries at run-time, Guile can also load some system libraries written in C or other low-level languages. We refer to these as dynamically-loadable modules as “foreign libraries”, to distinguish them from native libraries written in Scheme or other languages implemented by Guile. Foreign libraries usually come in two forms. Some foreign libraries are part of the operating system, such as the compression library ‘libz’. These shared libraries are built in such a way that many programs can use their functionality without duplicating their code. When a program written in C is built, it can declare that it uses a specific set of shared libraries. When the program is run, the operating system takes care of locating and loading the shared libraries. The operating system components that can dynamically load and link shared libraries when a program is run are also available programmatically during a program's execution. This is the interface that's most useful for Guile, and this is what we mean in Guile when we refer to “dynamic linking”. Dynamic linking at run-time is sometimes called “dlopening”, to distinguish it from the dynamic linking that happens at program start-up. The other kind of foreign library is sometimes known as a module, plug-in, bundle, or an extension. These foreign libraries aren't meant to be linked to by C programs, but rather only to be dynamically loaded at run-time - they extend some main program with functionality, but don't stand on their own. Sometimes a Guile library will implement some of its functionality in a loadable module. In either case, the interface on the Guile side is the same. You load the interface using ‘load-foreign-library’. The resulting foreign library object implements a simple lookup interface whereby the user can get addresses of data or code exported by the library. There is no facility to inspect foreign libraries; you have to know what's in there already before you look. Routines for loading foreign libraries and accessing their contents are implemented in the ‘(system foreign-library)’ module. (use-modules (system foreign-library)) -- Scheme Procedure: load-foreign-library [library] [#:extensions=system-library-extensions] [#:search-ltdl-library-path?=#t] [#:search-path=search-path] [#:search-system-paths?=#t] [#:lazy?=#t] [#:global=#f] [#:rename-on-cygwin?=#t] Find the shared library denoted by LIBRARY (a string or ‘#f’) and link it into the running Guile application. When everything works out, return a Scheme object suitable for representing the linked object file. Otherwise an error is thrown. If LIBRARY argument is omitted, it defaults to ‘#f’. If ‘library’ is false, the resulting foreign library gives access to all symbols available for dynamic linking in the main binary. It is not necessary to include any extension such as ‘.so’ in LIBRARY. For each system, Guile has a default set of extensions that it will try. On GNU systems, the default extension set is just ‘.so’; on Windows, just ‘.dll’; and on Darwin (Mac OS), it is ‘.bundle’, ‘.so’, and ‘.dylib’. Pass ‘#:extensions EXTENSIONS’ to override the default extensions list. If LIBRARY contains one of the extensions, no extensions are tried, so it is possible to specify the extension if you know exactly what file to load. Unless LIBRARY denotes an absolute file name or otherwise contains a directory separator (‘/’, and also ‘\’ on Windows), Guile will search for the library in the directories listed in SEARCH-PATHS. The default search path has three components, which can all be overridden by colon-delimited (semicolon on Windows) environment variables: ‘GUILE_EXTENSIONS_PATH’ This is the main environment variable for users to add directories containing Guile extensions. The default value has no entries. This environment variable was added in Guile 3.0.6. ‘LTDL_LIBRARY_PATH’ Before Guile 3.0.6, Guile loaded foreign libraries using ‘libltdl’, the dynamic library loader provided by libtool. This loader used ‘LTDL_LIBRARY_PATH’, and for backwards compatibility we still support that path. However, ‘libltdl’ would not only open ‘.so’ (or ‘.dll’ and so on) files, but also the ‘.la’ files created by libtool. In installed libraries - libraries that are in the target directories of ‘make install’ - ‘.la’ files are never needed, to the extent that most GNU/Linux distributions remove them entirely. It is sufficient to just load the ‘.so’ (or ‘.dll’ and so on) files, which are always located in the same directory as the ‘.la’ files. But for uninstalled dynamic libraries, like those in a build tree, the situation is a bit of a mess. If you have a project that uses libtool to build libraries - which is the case for Guile, and for most projects using autotools - and you build ‘foo.so’ in directory ‘D’, libtool will put ‘foo.la’ in ‘D’, but ‘foo.so’ gets put into ‘D/.libs’. Users were mostly oblivious to this situation, as ‘libltdl’ had special logic to be able to read the ‘.la’ file to know where to find the ‘.so’, even from an uninstalled build tree, preventing the existence of ‘.libs’ from leaking out to the user. We don't use libltdl now, essentially for flexibility and error-reporting reasons. But, to keep this old use-case working, if SEARCH-LTDL-LIBRARY-PATH? is true, we add each entry of ‘LTDL_LIBRARY_PATH’ to the default extensions load path, additionally adding the ‘.libs’ subdirectories for each entry, in case there are ‘.so’ files there instead of alongside the ‘.la’ files. ‘GUILE_SYSTEM_EXTENSIONS_PATH’ The last path in Guile's search path belongs to Guile itself, and defaults to the libdir and the extensiondir, in that order. For example, if you install to ‘/opt/guile’, these would probably be ‘/opt/guile/lib’ and ‘/opt/guile/lib/guile/3.0/extensions’, respectively. *Note Parallel Installations::, for more details on ‘extensionsdir’. Finally, if no library is found in the search path, and if LIBRARY is not absolute and does not include directory separators, and if SEARCH-SYSTEM-PATHS? is true, the operating system may have its own logic for where to locate LIBRARY. For example, on GNU, there will be a default set of paths (often ‘/usr/lib’ and ‘/lib’, though it depends on the system), and the ‘LD_LIBRARY_PATH’ environment variable can add additional paths. Other operating systems have other conventions. Falling back to the operating system for search is usually not a great thing; it is a recipe for making programs that work on one machine but not on others. Still, when wrapping system libraries, it can be the only way to get things working at all. If LAZY? is true (the default), Guile will request the operating system to resolve symbols used by the loaded library as they are first used. If GLOBAL? is true, symbols defined by the loaded library will be available when other modules need to resolve symbols; the default is ‘#f’, which keeps symbols local. If RENAME-ON-CYGWIN? is true (the default) - on Cygwin hosts only - the search behavior is modified such that a filename that starts with "lib" will be searched for under the name "cyg", as is customary for Cygwin. The environment variables mentioned above are parsed when the foreign-library module is first loaded and bound to parameters. Null path components, for example the three components of ‘GUILE_SYSTEM_EXTENSIONS_PATH="::"’, are ignored. -- Scheme Parameter: guile-extensions-path -- Scheme Parameter: ltdl-library-path -- Scheme Parameter: guile-system-extensions-path Parameters whose initial values are taken from ‘GUILE_EXTENSIONS_PATH’, ‘LTDL_LIBRARY_PATH’, and ‘GUILE_SYSTEM_EXTENSIONS_PATH’, respectively. *Note Parameters::. The current values of these parameters are used when building the search path when ‘load-foreign-library’ is called, unless the caller explicitly passes a ‘#:search-path’ argument. -- Scheme Procedure: foreign-library? obj Return ‘#t’ if OBJ is a foreign library, or ‘#f’ otherwise. 6.19.2 Foreign Extensions ------------------------- One way to use shared libraries is to extend Guile. Such loadable modules generally define one distinguished initialization function that, when called, will use the ‘libguile’ API to define procedures in the current module. Concretely, you might extend Guile with an implementation of the Bessel function, ‘j0’: #include #include SCM j0_wrapper (SCM x) { return scm_from_double (j0 (scm_to_double (x, "j0"))); } void init_math_bessel (void) { scm_c_define_gsubr ("j0", 1, 0, 0, j0_wrapper); } The C source file would then need to be compiled into a shared library. On GNU/Linux, the compiler invocation might look like this: gcc -shared -o bessel.so -fPIC bessel.c A good default place to put shared libraries that extend Guile is into the extensions dir. From the command line or a build script, invoke ‘pkg-config --variable=extensionsdir guile-3.0’ to print the extensions dir. *Note Parallel Installations::, for more details. Guile can load up ‘bessel.so’ via ‘load-extension’. -- Scheme Procedure: load-extension lib init -- C Function: scm_load_extension (lib, init) Load and initialize the extension designated by LIB and INIT. The normal way for a extension to be used is to write a small Scheme file that defines a module, and to load the extension into this module. When the module is auto-loaded, the extension is loaded as well. For example: (define-module (math bessel) #:export (j0)) (load-extension "bessel" "init_math_bessel") This ‘load-extension’ invocation loads the ‘bessel’ library via ‘(load-foreign-library "bessel")’, then looks up the ‘init_math_bessel’ symbol in the library, treating it as a function of no arguments, and calls that function. If you decide to put your extension outside the default search path for ‘load-foreign-library’, probably you should adapt the Scheme module to specify its absolute path. For example, if you use ‘automake’ to build your extension and place it in ‘$(pkglibdir)’, you might define a build-parameters module that gets created by the build system: (define-module (math config) #:export (extensiondir)) (define extensiondir "PKGLIBDIR") This file would be ‘config.scm.in’. You would define a ‘make’ rule to substitute in the absolute installed file name: config.scm: config.scm.in sed 's|PKGLIBDIR|$(pkglibdir)|' <$< >$ Then your ‘(math bessel)’ would import ‘(math config)’, then ‘(load-extension (in-vicinity extensiondir "bessel") "init_math_bessel")’. An alternate approach would be to rebind the ‘guile-extensions-path’ parameter, or its corresponding environment variable, but note that changing those parameters applies to other users of ‘load-foreign-library’ as well. Note that the new primitives that the extension adds to Guile with ‘scm_c_define_gsubr’ (*note Primitive Procedures::) or with any of the other mechanisms are placed into the module that is current when the ‘scm_c_define_gsubr’ is executed, so to be clear about what goes where it's best to include the ‘load-extension’ in a module, as above. Alternately, the C code can use ‘scm_c_define_module’ to specify which module is being created: static void do_init (void *unused) { scm_c_define_gsubr ("j0", 1, 0, 0, j0_wrapper); scm_c_export ("j0", NULL); } void init_math_bessel () { scm_c_define_module ("math bessel", do_init, NULL); } And yet... if what we want is just the ‘j0’ function, it seems like a lot of ceremony to have to compile a Guile-specific wrapper library complete with an initialization function and wrapper module to allow Guile users to call it. There is another way, but to get there, we have to talk about function pointers and function types first. *Note Foreign Functions::, to skip to the good parts. 6.19.3 Foreign Pointers ----------------------- Foreign libraries are essentially key-value mappings, where the keys are names of definitions and the values are the addresses of those definitions. To look up the address of a definition, use ‘foreign-library-pointer’ from the ‘(system foreign-library)’ module. -- Scheme Procedure: foreign-library-pointer lib name Return a "wrapped pointer" for the symbol NAME in the shared object referred to by LIB. The returned pointer points to a C object. As a convenience, if LIB is not a foreign library, it will be passed to ‘load-foreign-library’. If we continue with the ‘bessel.so’ example from before, we can get the address of the ‘init_math_bessel’ function via: (use-modules (system foreign-library)) (define init (foreign-library-pointer "bessel" "init_math_bessel")) init ⇒ # A value returned by ‘foreign-library-pointer’ is a Scheme wrapper for a C pointer. Pointers are a data type in Guile that is disjoint from all other types. The next section discusses ways to dereference pointers, but before then we describe the usual type predicates and so on. Note that the rest of the interfaces in this section are part of the ‘(system foreign)’ library: (use-modules (system foreign)) -- Scheme Procedure: pointer-address pointer -- C Function: scm_pointer_address (pointer) Return the numerical value of POINTER. (pointer-address init) ⇒ 139984413364296 ; YMMV -- Scheme Procedure: make-pointer address [finalizer] Return a foreign pointer object pointing to ADDRESS. If FINALIZER is passed, it should be a pointer to a one-argument C function that will be called when the pointer object becomes unreachable. -- Scheme Procedure: pointer? obj Return ‘#t’ if OBJ is a pointer object, or ‘#f’ otherwise. -- Scheme Variable: %null-pointer A foreign pointer whose value is 0. -- Scheme Procedure: null-pointer? pointer Return ‘#t’ if POINTER is the null pointer, ‘#f’ otherwise. For the purpose of passing SCM values directly to foreign functions, and allowing them to return SCM values, Guile also supports some unsafe casting operators. -- Scheme Procedure: scm->pointer scm Return a foreign pointer object with the ‘object-address’ of SCM. -- Scheme Procedure: pointer->scm pointer Unsafely cast POINTER to a Scheme object. Cross your fingers! Sometimes you want to give C extensions access to the dynamic FFI. At that point, the names get confusing, because "pointer" can refer to a ‘SCM’ object that wraps a pointer, or to a ‘void*’ value. We will try to use "pointer object" to refer to Scheme objects, and "pointer value" to refer to ‘void *’ values. -- C Function: SCM scm_from_pointer (void *ptr, void (*finalizer) (void*)) Create a pointer object from a pointer value. If FINALIZER is non-null, Guile arranges to call it on the pointer value at some point after the pointer object becomes collectible. -- C Function: void* scm_to_pointer (SCM obj) Unpack the pointer value from a pointer object. 6.19.4 Foreign Types -------------------- From Scheme's perspective, foreign pointers are shards of chaos. The user can create a foreign pointer for any address, and do with it what they will. The only thing that lends a sense of order to the whole is a shared hallucination that certain storage locations have certain types. When making Scheme wrappers for foreign interfaces, we hide the madness by explicitly representing the the data types of parameters and fields. These "foreign type values" may be constructed using the constants and procedures from the ‘(system foreign)’ module, which may be loaded like this: (use-modules (system foreign)) ‘(system foreign)’ exports a number of values expressing the basic C types. -- Scheme Variable: int8 -- Scheme Variable: uint8 -- Scheme Variable: uint16 -- Scheme Variable: int16 -- Scheme Variable: uint32 -- Scheme Variable: int32 -- Scheme Variable: uint64 -- Scheme Variable: int64 -- Scheme Variable: float -- Scheme Variable: double -- Scheme Variable: complex-double -- Scheme Variable: complex-float These values represent the C numeric types of the specified sizes and signednesses. ‘complex-float’ and ‘complex-double’ stand for C99 ‘float _Complex’ and ‘double _Complex’ respectively. In addition there are some convenience bindings for indicating types of platform-dependent size. -- Scheme Variable: int -- Scheme Variable: unsigned-int -- Scheme Variable: long -- Scheme Variable: unsigned-long -- Scheme Variable: short -- Scheme Variable: unsigned-short -- Scheme Variable: size_t -- Scheme Variable: ssize_t -- Scheme Variable: ptrdiff_t -- Scheme Variable: intptr_t -- Scheme Variable: uintptr_t Values exported by the ‘(system foreign)’ module, representing C numeric types. For example, ‘long’ may be ‘equal?’ to ‘int64’ on a 64-bit platform. -- Scheme Variable: void The ‘void’ type. It can be used as the first argument to ‘pointer->procedure’ to wrap a C function that returns nothing. In addition, the symbol ‘*’ is used by convention to denote pointer types. Procedures detailed in the following sections, such as ‘pointer->procedure’, accept it as a type descriptor. 6.19.5 Foreign Functions ------------------------ The most natural thing to do with a dynamic library is to grovel around in it for a function pointer: a “foreign function”. Load the ‘(system foreign)’ module to use these Scheme interfaces. (use-modules (system foreign)) -- Scheme Procedure: pointer->procedure return_type func_ptr arg_types [#:return-errno?=#f] -- C Function: scm_pointer_to_procedure (return_type, func_ptr, arg_types) -- C Function: scm_pointer_to_procedure_with_errno (return_type, func_ptr, arg_types) Make a foreign function. Given the foreign void pointer FUNC_PTR, its argument and return types ARG_TYPES and RETURN_TYPE, return a procedure that will pass arguments to the foreign function and return appropriate values. ARG_TYPES should be a list of foreign types. ‘return_type’ should be a foreign type. *Note Foreign Types::, for more information on foreign types. If RETURN-ERRNO? is true, or when calling ‘scm_pointer_to_procedure_with_errno’, the returned procedure will return two values, with ‘errno’ as the second value. Finally, in ‘(system foreign-library)’ there is a convenient wrapper function, joining together ‘foreign-library-pointer’ and ‘procedure->pointer’: -- Scheme Procedure: foreign-library-function lib name [#:return-type=void] [#:arg-types='()] [#:return-errno?=#f] Load the address of NAME from LIB, and treat it as a function taking arguments ARG-TYPES and returning RETURN-TYPE, optionally also with errno. An invocation of ‘foreign-library-function’ is entirely equivalent to: (pointer->procedure RETURN-TYPE (foreign-library-pointer LIB NAME) ARG-TYPES #:return-errno? RETURN-ERRNO?). Pulling all this together, here is a better definition of ‘(math bessel)’: (define-module (math bessel) #:use-module (system foreign) #:use-module (system foreign-library) #:export (j0)) (define j0 (foreign-library-function "libm" "j0" #:return-type double #:arg-types (list double))) That's it! No C at all. Before going on to more detailed examples, the next two sections discuss how to deal with data that is more complex than, say, ‘int8’. *Note More Foreign Functions::, to continue with foreign function examples. 6.19.6 Void Pointers and Byte Access ------------------------------------ Wrapped pointers are untyped, so they are essentially equivalent to C ‘void’ pointers. As in C, the memory region pointed to by a pointer can be accessed at the byte level. This is achieved using _bytevectors_ (*note Bytevectors::). The ‘(rnrs bytevectors)’ module contains procedures that can be used to convert byte sequences to Scheme objects such as strings, floating point numbers, or integers. Load the ‘(system foreign)’ module to use these Scheme interfaces. (use-modules (system foreign)) -- Scheme Procedure: pointer->bytevector pointer len [offset [uvec_type]] -- C Function: scm_pointer_to_bytevector (pointer, len, offset, uvec_type) Return a bytevector aliasing the LEN bytes pointed to by POINTER. The user may specify an alternate default interpretation for the memory by passing the UVEC_TYPE argument, to indicate that the memory is an array of elements of that type. UVEC_TYPE should be something that ‘array-type’ would return, like ‘f32’ or ‘s16’. When OFFSET is passed, it specifies the offset in bytes relative to POINTER of the memory region aliased by the returned bytevector. Mutating the returned bytevector mutates the memory pointed to by POINTER, so buckle your seatbelts. -- Scheme Procedure: bytevector->pointer bv [offset] -- C Function: scm_bytevector_to_pointer (bv, offset) Return a pointer aliasing the memory pointed to by BV or OFFSET bytes after BV when OFFSET is passed. In addition to these primitives, convenience procedures are available: -- Scheme Procedure: dereference-pointer pointer Assuming POINTER points to a memory region that holds a pointer, return this pointer. -- Scheme Procedure: string->pointer string [encoding] Return a foreign pointer to a nul-terminated copy of STRING in the given ENCODING, defaulting to the current locale encoding. The C string is freed when the returned foreign pointer becomes unreachable. This is the Scheme equivalent of ‘scm_to_stringn’. -- Scheme Procedure: pointer->string pointer [length] [encoding] Return the string representing the C string pointed to by POINTER. If LENGTH is omitted or ‘-1’, the string is assumed to be nul-terminated. Otherwise LENGTH is the number of bytes in memory pointed to by POINTER. The C string is assumed to be in the given ENCODING, defaulting to the current locale encoding. This is the Scheme equivalent of ‘scm_from_stringn’. Most object-oriented C libraries use pointers to specific data structures to identify objects. It is useful in such cases to reify the different pointer types as disjoint Scheme types. The ‘define-wrapped-pointer-type’ macro simplifies this. -- Scheme Syntax: define-wrapped-pointer-type type-name pred wrap unwrap print Define helper procedures to wrap pointer objects into Scheme objects with a disjoint type. Specifically, this macro defines: • PRED, a predicate for the new Scheme type; • WRAP, a procedure that takes a pointer object and returns an object that satisfies PRED; • UNWRAP, which does the reverse. WRAP preserves pointer identity, for two pointer objects P1 and P2 that are ‘equal?’, ‘(eq? (WRAP P1) (WRAP P2)) ⇒ #t’. Finally, PRINT should name a user-defined procedure to print such objects. The procedure is passed the wrapped object and a port to write to. For example, assume we are wrapping a C library that defines a type, ‘bottle_t’, and functions that can be passed ‘bottle_t *’ pointers to manipulate them. We could write: (define-wrapped-pointer-type bottle bottle? wrap-bottle unwrap-bottle (lambda (b p) (format p "#" (bottle-contents b) (pointer-address (unwrap-bottle b))))) (define grab-bottle ;; Wrapper for `bottle_t *grab (void)'. (let ((grab (foreign-library-function libbottle "grab_bottle" #:return-type '*))) (lambda () "Return a new bottle." (wrap-bottle (grab))))) (define bottle-contents ;; Wrapper for `const char *bottle_contents (bottle_t *)'. (let ((contents (foreign-library-function libbottle "bottle_contents" #:return-type '* #:arg-types '(*)))) (lambda (b) "Return the contents of B." (pointer->string (contents (unwrap-bottle b)))))) (write (grab-bottle)) ⇒ # In this example, ‘grab-bottle’ is guaranteed to return a genuine ‘bottle’ object satisfying ‘bottle?’. Likewise, ‘bottle-contents’ errors out when its argument is not a genuine ‘bottle’ object. As another example, currently Guile has a variable, ‘scm_numptob’, as part of its API. It is declared as a C ‘long’. So, to read its value, we can do: (use-modules (system foreign)) (use-modules (rnrs bytevectors)) (define numptob (foreign-library-pointer #f "scm_numptob")) numptob (bytevector-uint-ref (pointer->bytevector numptob (sizeof long)) 0 (native-endianness) (sizeof long)) ⇒ 8 If we wanted to corrupt Guile's internal state, we could set ‘scm_numptob’ to another value; but we shouldn't, because that variable is not meant to be set. Indeed this point applies more widely: the C API is a dangerous place to be. Not only might setting a value crash your program, simply accessing the data pointed to by a dangling pointer or similar can prove equally disastrous. 6.19.7 Foreign Structs ---------------------- Finally, one last note on foreign values before moving on to actually calling foreign functions. Sometimes you need to deal with C structs, which requires interpreting each element of the struct according to the its type, offset, and alignment. The ‘(system foreign)’ module has some primitives to support this. (use-modules (system foreign)) -- Scheme Procedure: sizeof type -- C Function: scm_sizeof (type) Return the size of TYPE, in bytes. TYPE should be a valid C type, like ‘int’. Alternately TYPE may be the symbol ‘*’, in which case the size of a pointer is returned. TYPE may also be a list of types, in which case the size of a ‘struct’ with ABI-conventional packing is returned. -- Scheme Procedure: alignof type -- C Function: scm_alignof (type) Return the alignment of TYPE, in bytes. TYPE should be a valid C type, like ‘int’. Alternately TYPE may be the symbol ‘*’, in which case the alignment of a pointer is returned. TYPE may also be a list of types, in which case the alignment of a ‘struct’ with ABI-conventional packing is returned. Guile also provides some convenience syntax to efficiently read and write C structs to and from bytevectors. -- Scheme Syntax: read-c-struct bv offset ((field type) ...) k Read a C struct with fields of type TYPE... from the bytevector BV, at offset OFFSET. Bind the fields to the identifiers FIELD..., and return ‘(K FIELD ...)’. Unless cross-compiling, the field types are evaluated at macro-expansion time. This allows the resulting bytevector accessors and size/alignment computations to be completely inlined. -- Scheme Syntax: write-c-struct bv offset ((field type) ...) Write a C struct with fields FIELD... of type TYPE... to the bytevector BV, at offset OFFSET. Return zero values. Like ‘write-c-struct’ above, unless cross-compiling, the field types are evaluated at macro-expansion time. For example, to define a parser and serializer for the equivalent of a ‘struct { int64_t a; uint8_t b; }’, one might do this: (use-modules (system foreign) (rnrs bytevectors)) (define-syntax-rule (define-serialization (reader writer) (field type) ...) (begin (define (reader bv offset) (read-c-struct bv offset ((field type) ...) values)) (define (writer bv offset field ...) (write-c-struct bv offset ((field type) ...))))) (define-serialization (read-struct write-struct) (a int64) (b uint8)) (define bv (make-bytevector (sizeof (list int64 uint8)))) (write-struct bv 0 300 43) (call-with-values (lambda () (read-struct bv 0)) list) ⇒ (300 43) There is also an older interface that is mostly equivalent to ‘read-c-struct’ and ‘write-c-struct’, but which uses run-time dispatch, and operates on foreign pointers instead of bytevectors. -- Scheme Procedure: parse-c-struct foreign types Parse a foreign pointer to a C struct, returning a list of values. ‘types’ should be a list of C types. Our parser and serializer example for ‘struct { int64_t a; uint8_t b; }’ looks more like this: (parse-c-struct (make-c-struct (list int64 uint8) (list 300 43)) (list int64 uint8)) ⇒ (300 43) As yet, Guile only has convenience routines to support conventionally-packed structs. But given the ‘bytevector->pointer’ and ‘pointer->bytevector’ routines, one can create and parse tightly packed structs and unions by hand. See the code for ‘(system foreign)’ for details. 6.19.8 More Foreign Functions ----------------------------- It is possible to pass pointers to foreign functions, and to return them as well. In that case the type of the argument or return value should be the symbol ‘*’, indicating a pointer. For example, the following code makes ‘memcpy’ available to Scheme: (use-modules (system foreign)) (define memcpy (foreign-library-function #f "memcpy" #:return-type '* #:arg-types (list '* '* size_t))) To invoke ‘memcpy’, one must pass it foreign pointers: (use-modules (rnrs bytevectors)) (define src-bits (u8-list->bytevector '(0 1 2 3 4 5 6 7))) (define src (bytevector->pointer src-bits)) (define dest (bytevector->pointer (make-bytevector 16 0))) (memcpy dest src (bytevector-length src-bits)) (bytevector->u8-list (pointer->bytevector dest 16)) ⇒ (0 1 2 3 4 5 6 7 0 0 0 0 0 0 0 0) One may also pass structs as values, passing structs as foreign pointers. *Note Foreign Structs::, for more information on how to express struct types and struct values. "Out" arguments are passed as foreign pointers. The memory pointed to by the foreign pointer is mutated in place. ;; struct timeval { ;; time_t tv_sec; /* seconds */ ;; suseconds_t tv_usec; /* microseconds */ ;; }; ;; assuming fields are of type "long" (define gettimeofday (let ((f (foreign-library-function #f "gettimeofday" #:return-type int #:arg-types (list '* '*))) (tv-type (list long long))) (lambda () (let* ((timeval (make-c-struct tv-type (list 0 0))) (ret (f timeval %null-pointer))) (if (zero? ret) (apply values (parse-c-struct timeval tv-type)) (error "gettimeofday returned an error" ret)))))) (gettimeofday) ⇒ 1270587589 ⇒ 499553 As you can see, this interface to foreign functions is at a very low, somewhat dangerous level(1). The FFI can also work in the opposite direction: making Scheme procedures callable from C. This makes it possible to use Scheme procedures as "callbacks" expected by C function. -- Scheme Procedure: procedure->pointer return-type proc arg-types -- C Function: scm_procedure_to_pointer (return_type, proc, arg_types) Return a pointer to a C function of type RETURN-TYPE taking arguments of types ARG-TYPES (a list) and behaving as a proxy to procedure PROC. Thus PROC's arity, supported argument types, and return type should match RETURN-TYPE and ARG-TYPES. As an example, here's how the C library's ‘qsort’ array sorting function can be made accessible to Scheme (*note ‘qsort’: (libc)Array Sort Function.): (define qsort! (let ((qsort (foreign-library-function #f "qsort" #:arg-types (list '* size_t size_t '*)))) (lambda (bv compare) ;; Sort bytevector BV in-place according to comparison ;; procedure COMPARE. (let ((ptr (procedure->pointer int (lambda (x y) ;; X and Y are pointers so, ;; for convenience, dereference ;; them before calling COMPARE. (compare (dereference-uint8* x) (dereference-uint8* y))) (list '* '*)))) (qsort (bytevector->pointer bv) (bytevector-length bv) 1 ;; we're sorting bytes ptr))))) (define (dereference-uint8* ptr) ;; Helper function: dereference the byte pointed to by PTR. (let ((b (pointer->bytevector ptr 1))) (bytevector-u8-ref b 0))) (define bv ;; An unsorted array of bytes. (u8-list->bytevector '(7 1 127 3 5 4 77 2 9 0))) ;; Sort BV. (qsort! bv (lambda (x y) (- x y))) ;; Let's see what the sorted array looks like: (bytevector->u8-list bv) ⇒ (0 1 2 3 4 5 7 9 77 127) And voilà! Note that ‘procedure->pointer’ is not supported (and not defined) on a few exotic architectures. Thus, user code may need to check ‘(defined? 'procedure->pointer)’. Nevertheless, it is available on many architectures, including (as of libffi 3.0.9) x86, ia64, SPARC, PowerPC, ARM, and MIPS, to name a few. ---------- Footnotes ---------- (1) A contribution to Guile in the form of a high-level FFI would be most welcome. 6.20 Foreign Objects ==================== This chapter contains reference information related to defining and working with foreign objects. *Note Defining New Foreign Object Types::, for a tutorial-like introduction to foreign objects. -- C Type: scm_t_struct_finalize This function type returns ‘void’ and takes one ‘SCM’ argument. -- C Function: SCM scm_make_foreign_object_type (SCM name, SCM slots, scm_t_struct_finalize finalizer) Create a fresh foreign object type. NAME is a symbol naming the type. SLOTS is a list of symbols, each one naming a field in the foreign object type. FINALIZER indicates the finalizer, and may be ‘NULL’. We recommend that finalizers be avoided if possible. *Note Foreign Object Memory Management::. Finalizers must be async-safe and thread-safe. Again, *note Foreign Object Memory Management::. If you are embedding Guile in an application that is not thread-safe, and you define foreign object types that need finalization, you might want to disable automatic finalization, and arrange to call ‘scm_manually_run_finalizers ()’ yourself. -- C Function: int scm_set_automatic_finalization_enabled (int enabled_p) Enable or disable automatic finalization. By default, Guile arranges to invoke object finalizers automatically, in a separate thread if possible. Passing a zero value for ENABLED_P will disable automatic finalization for Guile as a whole. If you disable automatic finalization, you will have to call ‘scm_run_finalizers ()’ periodically. Unlike most other Guile functions, you can call ‘scm_set_automatic_finalization_enabled’ before Guile has been initialized. Return the previous status of automatic finalization. -- C Function: int scm_run_finalizers (void) Invoke any pending finalizers. Returns the number of finalizers that were invoked. This function should be called when automatic finalization is disabled, though it may be called if it is enabled as well. -- C Function: void scm_assert_foreign_object_type (SCM type, SCM val) When VAL is a foreign object of the given TYPE, do nothing. Otherwise, signal an error. -- C Function: SCM scm_make_foreign_object_0 (SCM type) -- C Function: SCM scm_make_foreign_object_1 (SCM type, void *val0) -- C Function: SCM scm_make_foreign_object_2 (SCM type, void *val0, void *val1) -- C Function: SCM scm_make_foreign_object_3 (SCM type, void *val0, void *val1, void *val2) -- C Function: SCM scm_make_foreign_object_n (SCM type, size_t n, void *vals[]) Make a new foreign object of the type with type TYPE and initialize the first N fields to the given values, as appropriate. The number of fields for objects of a given type is fixed when the type is created. It is an error to give more initializers than there are fields in the value. It is perfectly fine to give fewer initializers than needed; this is convenient when some fields are of non-pointer types, and would be easier to initialize with the setters described below. -- C Function: void* scm_foreign_object_ref (SCM obj, size_t n); -- C Function: scm_t_bits scm_foreign_object_unsigned_ref (SCM obj, size_t n); -- C Function: scm_t_signed_bits scm_foreign_object_signed_ref (SCM obj, size_t n); Return the value of the Nth field of the foreign object OBJ. The backing store for the fields is as wide as a ‘scm_t_bits’ value, which is at least as wide as a pointer. The different variants handle casting in a portable way. -- C Function: void scm_foreign_object_set_x (SCM obj, size_t n, void *val); -- C Function: void scm_foreign_object_unsigned_set_x (SCM obj, size_t n, scm_t_bits val); -- C Function: void scm_foreign_object_signed_set_x (SCM obj, size_t n, scm_t_signed_bits val); Set the value of the Nth field of the foreign object OBJ to VAL, after portably converting to a ‘scm_t_bits’ value, if needed. One can also access foreign objects from Scheme. *Note Foreign Objects and Scheme::, for some examples. (use-modules (system foreign-object)) -- Scheme Procedure: make-foreign-object-type name slots [#:finalizer=#f] [#:supers='()] Make a new foreign object type. See the above documentation for ‘scm_make_foreign_object_type’; these functions are exactly equivalent, except for the way in which the finalizer gets attached to instances (an internal detail), and the fact that this function accepts an optional list of superclasses, which will be paseed to ‘make-class’. The resulting value is a GOOPS class. *Note GOOPS::, for more on classes in Guile. -- Scheme Syntax: define-foreign-object-type name constructor (slot ...) [#:finalizer=#f] A convenience macro to define a type, using ‘make-foreign-object-type’, and bind it to NAME. A constructor will be bound to CONSTRUCTOR, and getters will be bound to each of SLOT.... 6.21 Smobs ========== A “smob” is a "small object". Before foreign objects were introduced in Guile 2.0.12 (*note Foreign Objects::), smobs were the preferred way to for C code to define new kinds of Scheme objects. With the exception of the so-called "applicable SMOBs" discussed below, smobs are now a legacy interface and are headed for eventual deprecation. *Note Deprecation::. New code should use the foreign object interface. This section contains reference information related to defining and working with smobs. For a tutorial-like introduction to smobs, see "Defining New Types (Smobs)" in previous versions of this manual. -- Function: scm_t_bits scm_make_smob_type (const char *name, size_t size) This function adds a new smob type, named NAME, with instance size SIZE, to the system. The return value is a tag that is used in creating instances of the type. If SIZE is 0, the default _free_ function will do nothing. If SIZE is not 0, the default _free_ function will deallocate the memory block pointed to by ‘SCM_SMOB_DATA’ with ‘scm_gc_free’. The WHAT parameter in the call to ‘scm_gc_free’ will be NAME. Default values are provided for the _mark_, _free_, _print_, and _equalp_ functions. If you want to customize any of these functions, the call to ‘scm_make_smob_type’ should be immediately followed by calls to one or several of ‘scm_set_smob_mark’, ‘scm_set_smob_free’, ‘scm_set_smob_print’, and/or ‘scm_set_smob_equalp’. -- C Function: void scm_set_smob_free (scm_t_bits tc, size_t (*free) (SCM obj)) This function sets the smob freeing procedure (sometimes referred to as a “finalizer”) for the smob type specified by the tag TC. TC is the tag returned by ‘scm_make_smob_type’. The FREE procedure must deallocate all resources that are directly associated with the smob instance OBJ. It must assume that all ‘SCM’ values that it references have already been freed and are thus invalid. It must also not call any libguile function or macro except ‘scm_gc_free’, ‘SCM_SMOB_FLAGS’, ‘SCM_SMOB_DATA’, ‘SCM_SMOB_DATA_2’, and ‘SCM_SMOB_DATA_3’. The FREE procedure must return 0. Note that defining a freeing procedure is not necessary if the resources associated with OBJ consists only of memory allocated with ‘scm_gc_malloc’ or ‘scm_gc_malloc_pointerless’ because this memory is automatically reclaimed by the garbage collector when it is no longer needed (*note ‘scm_gc_malloc’: Memory Blocks.). Smob free functions must be thread-safe. *Note Foreign Object Memory Management::, for a discussion on finalizers and concurrency. If you are embedding Guile in an application that is not thread-safe, and you define smob types that need finalization, you might want to disable automatic finalization, and arrange to call ‘scm_manually_run_finalizers ()’ yourself. *Note Foreign Objects::. -- C Function: void scm_set_smob_mark (scm_t_bits tc, SCM (*mark) (SCM obj)) This function sets the smob marking procedure for the smob type specified by the tag TC. TC is the tag returned by ‘scm_make_smob_type’. Defining a marking procedure is almost always the wrong thing to do. It is much, much preferable to allocate smob data with the ‘scm_gc_malloc’ and ‘scm_gc_malloc_pointerless’ functions, and allow the GC to trace pointers automatically. Any mark procedures you see currently almost surely date from the time of Guile 1.8, before the switch to the Boehm-Demers-Weiser collector. Such smob implementations should be changed to just use ‘scm_gc_malloc’ and friends, and to lose their mark function. If you decide to keep the mark function, note that it may be called on objects that are on the free list. Please read and digest the comments from the BDW GC's ‘gc/gc_mark.h’ header. The MARK procedure must cause ‘scm_gc_mark’ to be called for every ‘SCM’ value that is directly referenced by the smob instance OBJ. One of these ‘SCM’ values can be returned from the procedure and Guile will call ‘scm_gc_mark’ for it. This can be used to avoid deep recursions for smob instances that form a list. It must not call any libguile function or macro except ‘scm_gc_mark’, ‘SCM_SMOB_FLAGS’, ‘SCM_SMOB_DATA’, ‘SCM_SMOB_DATA_2’, and ‘SCM_SMOB_DATA_3’. -- C Function: void scm_set_smob_print (scm_t_bits tc, int (*print) (SCM obj, SCM port, scm_print_state* pstate)) This function sets the smob printing procedure for the smob type specified by the tag TC. TC is the tag returned by ‘scm_make_smob_type’. The PRINT procedure should output a textual representation of the smob instance OBJ to PORT, using information in PSTATE. The textual representation should be of the form ‘#’. This ensures that ‘read’ will not interpret it as some other Scheme value. It is often best to ignore PSTATE and just print to PORT with ‘scm_display’, ‘scm_write’, ‘scm_simple_format’, and ‘scm_puts’. -- C Function: void scm_set_smob_equalp (scm_t_bits tc, SCM (*equalp) (SCM obj1, SCM obj2)) This function sets the smob equality-testing predicate for the smob type specified by the tag TC. TC is the tag returned by ‘scm_make_smob_type’. The EQUALP procedure should return ‘SCM_BOOL_T’ when OBJ1 is ‘equal?’ to OBJ2. Else it should return ‘SCM_BOOL_F’. Both OBJ1 and OBJ2 are instances of the smob type TC. -- C Function: void scm_assert_smob_type (scm_t_bits tag, SCM val) When VAL is a smob of the type indicated by TAG, do nothing. Else, signal an error. -- C Macro: int SCM_SMOB_PREDICATE (scm_t_bits tag, SCM exp) Return true if EXP is a smob instance of the type indicated by TAG, or false otherwise. The expression EXP can be evaluated more than once, so it shouldn't contain any side effects. -- C Function: SCM scm_new_smob (scm_t_bits tag, void *data) -- C Function: SCM scm_new_double_smob (scm_t_bits tag, void *data, void *data2, void *data3) Make a new smob of the type with tag TAG and smob data DATA, DATA2, and DATA3, as appropriate. The TAG is what has been returned by ‘scm_make_smob_type’. The initial values DATA, DATA2, and DATA3 are of type ‘scm_t_bits’; when you want to use them for ‘SCM’ values, these values need to be converted to a ‘scm_t_bits’ first by using ‘SCM_UNPACK’. The flags of the smob instance start out as zero. -- C Macro: scm_t_bits SCM_SMOB_FLAGS (SCM obj) Return the 16 extra bits of the smob OBJ. No meaning is predefined for these bits, you can use them freely. -- C Macro: scm_t_bits SCM_SET_SMOB_FLAGS (SCM obj, scm_t_bits flags) Set the 16 extra bits of the smob OBJ to FLAGS. No meaning is predefined for these bits, you can use them freely. -- C Macro: scm_t_bits SCM_SMOB_DATA (SCM obj) -- C Macro: scm_t_bits SCM_SMOB_DATA_2 (SCM obj) -- C Macro: scm_t_bits SCM_SMOB_DATA_3 (SCM obj) Return the first (second, third) immediate word of the smob OBJ as a ‘scm_t_bits’ value. When the word contains a ‘SCM’ value, use ‘SCM_SMOB_OBJECT’ (etc.) instead. -- C Macro: void SCM_SET_SMOB_DATA (SCM obj, scm_t_bits val) -- C Macro: void SCM_SET_SMOB_DATA_2 (SCM obj, scm_t_bits val) -- C Macro: void SCM_SET_SMOB_DATA_3 (SCM obj, scm_t_bits val) Set the first (second, third) immediate word of the smob OBJ to VAL. When the word should be set to a ‘SCM’ value, use ‘SCM_SMOB_SET_OBJECT’ (etc.) instead. -- C Macro: SCM SCM_SMOB_OBJECT (SCM obj) -- C Macro: SCM SCM_SMOB_OBJECT_2 (SCM obj) -- C Macro: SCM SCM_SMOB_OBJECT_3 (SCM obj) Return the first (second, third) immediate word of the smob OBJ as a ‘SCM’ value. When the word contains a ‘scm_t_bits’ value, use ‘SCM_SMOB_DATA’ (etc.) instead. -- C Macro: void SCM_SET_SMOB_OBJECT (SCM obj, SCM val) -- C Macro: void SCM_SET_SMOB_OBJECT_2 (SCM obj, SCM val) -- C Macro: void SCM_SET_SMOB_OBJECT_3 (SCM obj, SCM val) Set the first (second, third) immediate word of the smob OBJ to VAL. When the word should be set to a ‘scm_t_bits’ value, use ‘SCM_SMOB_SET_DATA’ (etc.) instead. -- C Macro: SCM * SCM_SMOB_OBJECT_LOC (SCM obj) -- C Macro: SCM * SCM_SMOB_OBJECT_2_LOC (SCM obj) -- C Macro: SCM * SCM_SMOB_OBJECT_3_LOC (SCM obj) Return a pointer to the first (second, third) immediate word of the smob OBJ. Note that this is a pointer to ‘SCM’. If you need to work with ‘scm_t_bits’ values, use ‘SCM_PACK’ and ‘SCM_UNPACK’, as appropriate. -- Function: SCM scm_markcdr (SCM X) Mark the references in the smob X, assuming that X's first data word contains an ordinary Scheme object, and X refers to no other objects. This function simply returns X's first data word. 6.22 Threads, Mutexes, Asyncs and Dynamic Roots =============================================== 6.22.1 Threads -------------- Guile supports POSIX threads, unless it was configured with ‘--without-threads’ or the host lacks POSIX thread support. When thread support is available, the ‘threads’ feature is provided (*note ‘provided?’: Feature Manipulation.). The procedures below manipulate Guile threads, which are wrappers around the system's POSIX threads. For application-level parallelism, using higher-level constructs, such as futures, is recommended (*note Futures::). To use these facilities, load the ‘(ice-9 threads)’ module. (use-modules (ice-9 threads)) -- Scheme Procedure: all-threads -- C Function: scm_all_threads () Return a list of all threads. -- Scheme Procedure: current-thread -- C Function: scm_current_thread () Return the thread that called this function. -- Scheme Procedure: call-with-new-thread thunk [handler] Call ‘thunk’ in a new thread and with a new dynamic state, returning the new thread. The procedure THUNK is called via ‘with-continuation-barrier’. When HANDLER is specified, then THUNK is called from within a ‘catch’ with tag ‘#t’ that has HANDLER as its handler. This catch is established inside the continuation barrier. Once THUNK or HANDLER returns, the return value is made the _exit value_ of the thread and the thread is terminated. -- C Function: SCM scm_spawn_thread (scm_t_catch_body body, void *body_data, scm_t_catch_handler handler, void *handler_data) Call BODY in a new thread, passing it BODY_DATA, returning the new thread. The function BODY is called via ‘scm_c_with_continuation_barrier’. When HANDLER is non-‘NULL’, BODY is called via ‘scm_internal_catch’ with tag ‘SCM_BOOL_T’ that has HANDLER and HANDLER_DATA as the handler and its data. This catch is established inside the continuation barrier. Once BODY or HANDLER returns, the return value is made the _exit value_ of the thread and the thread is terminated. -- Scheme Procedure: thread? obj -- C Function: scm_thread_p (obj) Return ‘#t’ ff OBJ is a thread; otherwise, return ‘#f’. -- Scheme Procedure: join-thread thread [timeout [timeoutval]] -- C Function: scm_join_thread (thread) -- C Function: scm_join_thread_timed (thread, timeout, timeoutval) Wait for THREAD to terminate and return its exit value. Only threads that were created with ‘call-with-new-thread’ or ‘scm_spawn_thread’ can be joinable; attempting to join a foreign thread will raise an error. When TIMEOUT is given, it specifies a point in time where the waiting should be aborted. It can be either an integer as returned by ‘current-time’ or a pair as returned by ‘gettimeofday’. When the waiting is aborted, TIMEOUTVAL is returned (if it is specified; ‘#f’ is returned otherwise). -- Scheme Procedure: thread-exited? thread -- C Function: scm_thread_exited_p (thread) Return ‘#t’ if THREAD has exited, or ‘#f’ otherwise. -- Scheme Procedure: yield -- C Function: scm_yield (thread) If one or more threads are waiting to execute, calling yield forces an immediate context switch to one of them. Otherwise, yield has no effect. -- Scheme Procedure: cancel-thread thread . values -- C Function: scm_cancel_thread (thread) Asynchronously interrupt THREAD and ask it to terminate. ‘dynamic-wind’ post thunks will run, but throw handlers will not. If THREAD has already terminated or been signaled to terminate, this function is a no-op. Calling ‘join-thread’ on the thread will return the given VALUES, if the cancel succeeded. Under the hood, thread cancellation uses ‘system-async-mark’ and ‘abort-to-prompt’. *Note Asyncs:: for more on asynchronous interrupts. -- macro: make-thread proc arg ... Apply PROC to ARG ... in a new thread formed by ‘call-with-new-thread’ using a default error handler that displays the error to the current error port. The ARG ... expressions are evaluated in the new thread. -- macro: begin-thread expr1 expr2 ... Evaluate forms EXPR1 EXPR2 ... in a new thread formed by ‘call-with-new-thread’ using a default error handler that displays the error to the current error port. One often wants to limit the number of threads running to be proportional to the number of available processors. These interfaces are therefore exported by (ice-9 threads) as well. -- Scheme Procedure: total-processor-count -- C Function: scm_total_processor_count () Return the total number of processors of the machine, which is guaranteed to be at least 1. A "processor" here is a thread execution unit, which can be either: • an execution core in a (possibly multi-core) chip, in a (possibly multi- chip) module, in a single computer, or • a thread execution unit inside a core in the case of “hyper-threaded” CPUs. Which of the two definitions is used, is unspecified. -- Scheme Procedure: current-processor-count -- C Function: scm_current_processor_count () Like ‘total-processor-count’, but return the number of processors available to the current process. See ‘setaffinity’ and ‘getaffinity’ for more information. 6.22.2 Thread-Local Variables ----------------------------- Sometimes you want to establish a variable binding that is only valid for a given thread: a "thread-local variable". You would think that fluids or parameters would be Guile's answer for thread-local variables, since establishing a new fluid binding doesn't affect bindings in other threads. *Note Fluids and Dynamic States::, or *Note Parameters::. However, new threads inherit the fluid bindings that were in place in their creator threads. In this way, a binding established using a fluid (or a parameter) in a thread can escape to other threads, which might not be what you want. Or, it might escape via explicit reification via ‘current-dynamic-state’. Of course, this dynamic scoping might be exactly what you want; that's why fluids and parameters work this way, and is what you want for many common parameters such as the current input and output ports, the current locale conversion parameters, and the like. Perhaps this is the case for most parameters, even. If your use case for thread-local bindings comes from a desire to isolate a binding from its setting in unrelated threads, then fluids and parameters apply nicely. On the other hand, if your use case is to prevent concurrent access to a value from multiple threads, then using vanilla fluids or parameters is not appropriate. For this purpose, Guile has “thread-local fluids”. A fluid created with ‘make-thread-local-fluid’ won't be captured by ‘current-dynamic-state’ and won't be propagated to new threads. -- Scheme Procedure: make-thread-local-fluid [dflt] -- C Function: scm_make_thread_local_fluid (dflt) Return a newly created fluid, whose initial value is DFLT, or ‘#f’ if DFLT is not given. Unlike fluids made with ‘make-fluid’, thread local fluids are not captured by ‘make-dynamic-state’. Similarly, a newly spawned child thread does not inherit thread-local fluid values from the parent thread. -- Scheme Procedure: fluid-thread-local? fluid -- C Function: scm_fluid_thread_local_p (fluid) Return ‘#t’ if the fluid FLUID is thread-local, or ‘#f’ otherwise. For example: (define %thread-local (make-thread-local-fluid)) (with-fluids ((%thread-local (compute-data))) ... (fluid-ref %thread-local) ...) You can also make a thread-local parameter out of a thread-local fluid using the normal ‘fluid->parameter’: (define param (fluid->parameter (make-thread-local-fluid))) (parameterize ((param (compute-data))) ... (param) ...) 6.22.3 Asynchronous Interrupts ------------------------------ Every Guile thread can be interrupted. Threads running Guile code will periodically check if there are pending interrupts and run them if necessary. To interrupt a thread, call ‘system-async-mark’ on that thread. -- Scheme Procedure: system-async-mark proc [thread] -- C Function: scm_system_async_mark (proc) -- C Function: scm_system_async_mark_for_thread (proc, thread) Enqueue PROC (a procedure with zero arguments) for future execution in THREAD. When PROC has already been enqueued for THREAD but has not been executed yet, this call has no effect. When THREAD is omitted, the thread that called ‘system-async-mark’ is used. Note that ‘scm_system_async_mark_for_thread’ is not "async-signal-safe" and so cannot be called from a C signal handler. (Indeed in general, ‘libguile’ functions are not safe to call from C signal handlers.) Though an interrupt procedure can have any side effect permitted to Guile code, asynchronous interrupts are generally used either for profiling or for prematurely canceling a computation. The former case is mostly transparent to the program being run, by design, but the latter case can introduce bugs. Like finalizers (*note Foreign Object Memory Management::), asynchronous interrupts introduce concurrency in a program. An asynchronous interrupt can run in the middle of some mutex-protected operation, for example, and potentially corrupt the program's state. If some bit of Guile code needs to temporarily inhibit interrupts, it can use ‘call-with-blocked-asyncs’. This function works by temporarily increasing the _async blocking level_ of the current thread while a given procedure is running. The blocking level starts out at zero, and whenever a safe point is reached, a blocking level greater than zero will prevent the execution of queued asyncs. Analogously, the procedure ‘call-with-unblocked-asyncs’ will temporarily decrease the blocking level of the current thread. You can use it when you want to disable asyncs by default and only allow them temporarily. In addition to the C versions of ‘call-with-blocked-asyncs’ and ‘call-with-unblocked-asyncs’, C code can use ‘scm_dynwind_block_asyncs’ and ‘scm_dynwind_unblock_asyncs’ inside a “dynamic context” (*note Dynamic Wind::) to block or unblock asyncs temporarily. -- Scheme Procedure: call-with-blocked-asyncs proc -- C Function: scm_call_with_blocked_asyncs (proc) Call PROC and block the execution of asyncs by one level for the current thread while it is running. Return the value returned by PROC. For the first two variants, call PROC with no arguments; for the third, call it with DATA. -- C Function: void * scm_c_call_with_blocked_asyncs (void * (*proc) (void *data), void *data) The same but with a C function PROC instead of a Scheme thunk. -- Scheme Procedure: call-with-unblocked-asyncs proc -- C Function: scm_call_with_unblocked_asyncs (proc) Call PROC and unblock the execution of asyncs by one level for the current thread while it is running. Return the value returned by PROC. For the first two variants, call PROC with no arguments; for the third, call it with DATA. -- C Function: void * scm_c_call_with_unblocked_asyncs (void *(*proc) (void *data), void *data) The same but with a C function PROC instead of a Scheme thunk. -- C Function: void scm_dynwind_block_asyncs () During the current dynwind context, increase the blocking of asyncs by one level. This function must be used inside a pair of calls to ‘scm_dynwind_begin’ and ‘scm_dynwind_end’ (*note Dynamic Wind::). -- C Function: void scm_dynwind_unblock_asyncs () During the current dynwind context, decrease the blocking of asyncs by one level. This function must be used inside a pair of calls to ‘scm_dynwind_begin’ and ‘scm_dynwind_end’ (*note Dynamic Wind::). Sometimes you want to interrupt a thread that might be waiting for something to happen, for example on a file descriptor or a condition variable. In that case you can inform Guile of how to interrupt that wait using the following procedures: -- C Function: int scm_c_prepare_to_wait_on_fd (int fd) Inform Guile that the current thread is about to sleep, and that if an asynchronous interrupt is signaled on this thread, Guile should wake up the thread by writing a zero byte to FD. Returns zero if the prepare succeeded, or nonzero if the thread already has a pending async and that it should avoid waiting. -- C Function: int scm_c_prepare_to_wait_on_cond (scm_i_pthread_mutex_t *mutex, scm_i_pthread_cond_t *cond) Inform Guile that the current thread is about to sleep, and that if an asynchronous interrupt is signaled on this thread, Guile should wake up the thread by acquiring MUTEX and signaling COND. The caller must already hold MUTEX and only drop it as part of the ‘pthread_cond_wait’ call. Returns zero if the prepare succeeded, or nonzero if the thread already has a pending async and that it should avoid waiting. -- C Function: void scm_c_wait_finished (void) Inform Guile that the current thread has finished waiting, and that asynchronous interrupts no longer need any special wakeup action; the current thread will periodically poll its internal queue instead. Guile's own interface to ‘sleep’, ‘wait-condition-variable’, ‘select’, and so on all call the above routines as appropriate. Finally, note that threads can also be interrupted via POSIX signals. *Note Signals::. As an implementation detail, signal handlers will effectively call ‘system-async-mark’ in a signal-safe way, eventually running the signal handler using the same async mechanism. In this way you can temporarily inhibit signal handlers from running using the above interfaces. 6.22.4 Atomics -------------- When accessing data in parallel from multiple threads, updates made by one thread are not generally guaranteed to be visible by another thread. It could be that your hardware requires special instructions to be emitted to propagate a change from one CPU core to another. Or, it could be that your hardware updates values with a sequence of instructions, and a parallel thread could see a value that is in the process of being updated but not fully updated. Atomic references solve this problem. Atomics are a standard, primitive facility to allow for concurrent access and update of mutable variables from multiple threads with guaranteed forward-progress and well-defined intermediate states. Atomic references serve not only as a hardware memory barrier but also as a compiler barrier. Normally a compiler might choose to reorder or elide certain memory accesses due to optimizations like common subexpression elimination. Atomic accesses however will not be reordered relative to each other, and normal memory accesses will not be reordered across atomic accesses. As an implementation detail, currently all atomic accesses and updates use the sequential consistency memory model from C11. We may relax this in the future to the acquire/release semantics, which still issues a memory barrier so that non-atomic updates are not reordered across atomic accesses or updates. To use Guile's atomic operations, load the ‘(ice-9 atomic)’ module: (use-modules (ice-9 atomic)) -- Scheme Procedure: make-atomic-box init Return an atomic box initialized to value INIT. -- Scheme Procedure: atomic-box? obj Return ‘#t’ if OBJ is an atomic-box object, else return ‘#f’. -- Scheme Procedure: atomic-box-ref box Fetch the value stored in the atomic box BOX and return it. -- Scheme Procedure: atomic-box-set! box val Store VAL into the atomic box BOX. -- Scheme Procedure: atomic-box-swap! box val Store VAL into the atomic box BOX, and return the value that was previously stored in the box. -- Scheme Procedure: atomic-box-compare-and-swap! box expected desired If the value of the atomic box BOX is the same as, EXPECTED (in the sense of ‘eq?’), replace the contents of the box with DESIRED. Otherwise does not update the box. Returns the previous value of the box in either case, so you can know if the swap worked by checking if the return value is ‘eq?’ to EXPECTED. 6.22.5 Mutexes and Condition Variables -------------------------------------- Mutexes are low-level primitives used to coordinate concurrent access to mutable data. Short for "mutual exclusion", the name "mutex" indicates that only one thread at a time can acquire access to data that is protected by a mutex - threads are excluded from accessing data at the same time. If one thread has locked a mutex, then another thread attempting to lock that same mutex will wait until the first thread is done. Mutexes can be used to build robust multi-threaded programs that take advantage of multiple cores. However, they provide very low-level functionality and are somewhat dangerous; usually you end up wanting to acquire multiple mutexes at the same time to perform a multi-object access, but this can easily lead to deadlocks if the program is not carefully written. For example, if objects A and B are protected by associated mutexes M and N, respectively, then to access both of them then you need to acquire both mutexes. But what if one thread acquires M first and then N, at the same time that another thread acquires N them M? You can easily end up in a situation where one is waiting for the other. There's no easy way around this problem on the language level. A function A that uses mutexes does not necessarily compose nicely with a function B that uses mutexes. For this reason we suggest using atomic variables when you can (*note Atomics::), as they do not have this problem. Still, if you as a programmer are responsible for a whole system, then you can use mutexes as a primitive to provide safe concurrent abstractions to your users. (For example, given all locks in a system, if you establish an order such that M is consistently acquired before N, you can avoid the "deadly-embrace" deadlock described above. The problem is enumerating all mutexes and establishing this order from a system perspective.) Guile gives you the low-level facilities to build such systems. In Guile there are additional considerations beyond the usual ones in other programming languages: non-local control flow and asynchronous interrupts. What happens if you hold a mutex, but somehow you cause an exception to be thrown? There is no one right answer. You might want to keep the mutex locked to prevent any other code from ever entering that critical section again. Or, your critical section might be fine if you unlock the mutex "on the way out", via an exception handler or ‘dynamic-wind’. *Note Exceptions::, and *Note Dynamic Wind::. But if you arrange to unlock the mutex when leaving a dynamic extent via ‘dynamic-wind’, what to do if control re-enters that dynamic extent via a continuation invocation? Surely re-entering the dynamic extent without the lock is a bad idea, so there are two options on the table: either prevent re-entry via ‘with-continuation-barrier’ or similar, or reacquire the lock in the entry thunk of a ‘dynamic-wind’. You might think that because you don't use continuations, that you don't have to think about this, and you might be right. If you control the whole system, you can reason about continuation use globally. Or, if you know all code that can be called in a dynamic extent, and none of that code can call continuations, then you don't have to worry about re-entry, and you might not have to worry about early exit either. However, do consider the possibility of asynchronous interrupts (*note Asyncs::). If the user interrupts your code interactively, that can cause an exception; or your thread might be canceled, which does the same; or the user could be running your code under some pre-emptive system that periodically causes lightweight task switching. (Guile does not currently include such a system, but it's possible to implement as a library.) Probably you also want to defer asynchronous interrupt processing while you hold the mutex, and probably that also means that you should not hold the mutex for very long. All of these additional Guile-specific considerations mean that from a system perspective, you would do well to avoid these hazards if you can by not requiring mutexes. Instead, work with immutable data that can be shared between threads without hazards, or use persistent data structures with atomic updates based on the atomic variable library (*note Atomics::). There are three types of mutexes in Guile: "standard", "recursive", and "unowned". Calling ‘make-mutex’ with no arguments makes a standard mutex. A standard mutex can only be locked once. If you try to lock it again from the thread that locked it to begin with (the "owner" thread), it throws an error. It can only be unlocked from the thread that locked it in the first place. Calling ‘make-mutex’ with the symbol ‘recursive’ as the argument, or calling ‘make-recursive-mutex’, will give you a recursive mutex. A recursive mutex can be locked multiple times by its owner. It then has to be unlocked the corresponding number of times, and like standard mutexes can only be unlocked by the owner thread. Finally, calling ‘make-mutex’ with the symbol ‘allow-external-unlock’ creates an unowned mutex. An unowned mutex is like a standard mutex, except that it can be unlocked by any thread. A corollary of this behavior is that a thread's attempt to lock a mutex that it already owns will block instead of signaling an error, as it could be that some other thread unlocks the mutex, allowing the owner thread to proceed. This kind of mutex is a bit strange and is here for use by SRFI-18. The mutex procedures in Guile can operate on all three kinds of mutexes. To use these facilities, load the ‘(ice-9 threads)’ module. (use-modules (ice-9 threads)) -- Scheme Procedure: make-mutex [kind] -- C Function: scm_make_mutex () -- C Function: scm_make_mutex_with_kind (SCM kind) Return a new mutex. It will be a standard non-recursive mutex, unless the ‘recursive’ symbol is passed as the optional KIND argument, in which case it will be recursive. It's also possible to pass ‘unowned’ for semantics tailored to SRFI-18's use case; see above for details. -- Scheme Procedure: mutex? obj -- C Function: scm_mutex_p (obj) Return ‘#t’ if OBJ is a mutex; otherwise, return ‘#f’. -- Scheme Procedure: make-recursive-mutex -- C Function: scm_make_recursive_mutex () Create a new recursive mutex. It is initially unlocked. Calling this function is equivalent to calling ‘make-mutex’ with the ‘recursive’ kind. -- Scheme Procedure: lock-mutex mutex [timeout] -- C Function: scm_lock_mutex (mutex) -- C Function: scm_timed_lock_mutex (mutex, timeout) Lock MUTEX and return ‘#t’. If the mutex is already locked, then block and return only when MUTEX has been acquired. When TIMEOUT is given, it specifies a point in time where the waiting should be aborted. It can be either an integer as returned by ‘current-time’ or a pair as returned by ‘gettimeofday’. When the waiting is aborted, ‘#f’ is returned. For standard mutexes (‘make-mutex’), an error is signaled if the thread has itself already locked MUTEX. For a recursive mutex (‘make-recursive-mutex’), if the thread has itself already locked MUTEX, then a further ‘lock-mutex’ call increments the lock count. An additional ‘unlock-mutex’ will be required to finally release. When an asynchronous interrupt (*note Asyncs::) is scheduled for a thread blocked in ‘lock-mutex’, Guile will interrupt the wait, run the interrupts, and then resume the wait. -- C Function: void scm_dynwind_lock_mutex (SCM mutex) Arrange for MUTEX to be locked whenever the current dynwind context is entered and to be unlocked when it is exited. -- Scheme Procedure: try-mutex mx -- C Function: scm_try_mutex (mx) Try to lock MUTEX and return ‘#t’ if successful, or ‘#f’ otherwise. This is like calling ‘lock-mutex’ with an expired timeout. -- Scheme Procedure: unlock-mutex mutex -- C Function: scm_unlock_mutex (mutex) Unlock MUTEX. An error is signaled if MUTEX is not locked. "Standard" and "recursive" mutexes can only be unlocked by the thread that locked them; Guile detects this situation and signals an error. "Unowned" mutexes can be unlocked by any thread. -- Scheme Procedure: mutex-owner mutex -- C Function: scm_mutex_owner (mutex) Return the current owner of MUTEX, in the form of a thread or ‘#f’ (indicating no owner). Note that a mutex may be unowned but still locked. -- Scheme Procedure: mutex-level mutex -- C Function: scm_mutex_level (mutex) Return the current lock level of MUTEX. If MUTEX is currently unlocked, this value will be 0; otherwise, it will be the number of times MUTEX has been recursively locked by its current owner. -- Scheme Procedure: mutex-locked? mutex -- C Function: scm_mutex_locked_p (mutex) Return ‘#t’ if MUTEX is locked, regardless of ownership; otherwise, return ‘#f’. -- Scheme Procedure: make-condition-variable -- C Function: scm_make_condition_variable () Return a new condition variable. -- Scheme Procedure: condition-variable? obj -- C Function: scm_condition_variable_p (obj) Return ‘#t’ if OBJ is a condition variable; otherwise, return ‘#f’. -- Scheme Procedure: wait-condition-variable condvar mutex [time] -- C Function: scm_wait_condition_variable (condvar, mutex, time) Wait until CONDVAR has been signaled. While waiting, MUTEX is atomically unlocked (as with ‘unlock-mutex’) and is locked again when this function returns. When TIME is given, it specifies a point in time where the waiting should be aborted. It can be either a integer as returned by ‘current-time’ or a pair as returned by ‘gettimeofday’. When the waiting is aborted, ‘#f’ is returned. When the condition variable has in fact been signaled, ‘#t’ is returned. The mutex is re-locked in any case before ‘wait-condition-variable’ returns. When an async is activated for a thread that is blocked in a call to ‘wait-condition-variable’, the waiting is interrupted, the mutex is locked, and the async is executed. When the async returns, the mutex is unlocked again and the waiting is resumed. When the thread block while re-acquiring the mutex, execution of asyncs is blocked. -- Scheme Procedure: signal-condition-variable condvar -- C Function: scm_signal_condition_variable (condvar) Wake up one thread that is waiting for CONDVAR. -- Scheme Procedure: broadcast-condition-variable condvar -- C Function: scm_broadcast_condition_variable (condvar) Wake up all threads that are waiting for CONDVAR. Guile also includes some higher-level abstractions for working with mutexes. -- macro: with-mutex mutex body1 body2 ... Lock MUTEX, evaluate the body BODY1 BODY2 ..., then unlock MUTEX. The return value is that returned by the last body form. The lock, body and unlock form the branches of a ‘dynamic-wind’ (*note Dynamic Wind::), so MUTEX is automatically unlocked if an error or new continuation exits the body, and is re-locked if the body is re-entered by a captured continuation. -- macro: monitor body1 body2 ... Evaluate the body form BODY1 BODY2 ... with a mutex locked so only one thread can execute that code at any one time. The return value is the return from the last body form. Each ‘monitor’ form has its own private mutex and the locking and evaluation is as per ‘with-mutex’ above. A standard mutex (‘make-mutex’) is used, which means the body must not recursively re-enter the ‘monitor’ form. The term "monitor" comes from operating system theory, where it means a particular bit of code managing access to some resource and which only ever executes on behalf of one process at any one time. 6.22.6 Blocking in Guile Mode ----------------------------- Up to Guile version 1.8, a thread blocked in guile mode would prevent the garbage collector from running. Thus threads had to explicitly leave guile mode with ‘scm_without_guile ()’ before making a potentially blocking call such as a mutex lock, a ‘select ()’ system call, etc. The following functions could be used to temporarily leave guile mode or to perform some common blocking operations in a supported way. Starting from Guile 2.0, blocked threads no longer hinder garbage collection. Thus, the functions below are not needed anymore. They can still be used to inform the GC that a thread is about to block, giving it a (small) optimization opportunity for "stop the world" garbage collections, should they occur while the thread is blocked. -- C Function: void * scm_without_guile (void *(*func) (void *), void *data) Leave guile mode, call FUNC on DATA, enter guile mode and return the result of calling FUNC. While a thread has left guile mode, it must not call any libguile functions except ‘scm_with_guile’ or ‘scm_without_guile’ and must not use any libguile macros. Also, local variables of type ‘SCM’ that are allocated while not in guile mode are not protected from the garbage collector. When used from non-guile mode, calling ‘scm_without_guile’ is still allowed: it simply calls FUNC. In that way, you can leave guile mode without having to know whether the current thread is in guile mode or not. -- C Function: int scm_pthread_mutex_lock (pthread_mutex_t *mutex) Like ‘pthread_mutex_lock’, but leaves guile mode while waiting for the mutex. -- C Function: int scm_pthread_cond_wait (pthread_cond_t *cond, pthread_mutex_t *mutex) -- C Function: int scm_pthread_cond_timedwait (pthread_cond_t *cond, pthread_mutex_t *mutex, struct timespec *abstime) Like ‘pthread_cond_wait’ and ‘pthread_cond_timedwait’, but leaves guile mode while waiting for the condition variable. -- C Function: int scm_std_select (int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout) Like ‘select’ but leaves guile mode while waiting. Also, the delivery of an async causes this function to be interrupted with error code ‘EINTR’. -- C Function: unsigned int scm_std_sleep (unsigned int seconds) Like ‘sleep’, but leaves guile mode while sleeping. Also, the delivery of an async causes this function to be interrupted. -- C Function: unsigned long scm_std_usleep (unsigned long usecs) Like ‘usleep’, but leaves guile mode while sleeping. Also, the delivery of an async causes this function to be interrupted. 6.22.7 Futures -------------- The ‘(ice-9 futures)’ module provides “futures”, a construct for fine-grain parallelism. A future is a wrapper around an expression whose computation may occur in parallel with the code of the calling thread, and possibly in parallel with other futures. Like promises, futures are essentially proxies that can be queried to obtain the value of the enclosed expression: (touch (future (+ 2 3))) ⇒ 5 However, unlike promises, the expression associated with a future may be evaluated on another CPU core, should one be available. This supports “fine-grain parallelism”, because even relatively small computations can be embedded in futures. Consider this sequential code: (define (find-prime lst1 lst2) (or (find prime? lst1) (find prime? lst2))) The two arms of ‘or’ are potentially computation-intensive. They are independent of one another, yet, they are evaluated sequentially when the first one returns ‘#f’. Using futures, one could rewrite it like this: (define (find-prime lst1 lst2) (let ((f (future (find prime? lst2)))) (or (find prime? lst1) (touch f)))) This preserves the semantics of ‘find-prime’. On a multi-core machine, though, the computation of ‘(find prime? lst2)’ may be done in parallel with that of the other ‘find’ call, which can reduce the execution time of ‘find-prime’. Futures may be nested: a future can itself spawn and then ‘touch’ other futures, leading to a directed acyclic graph of futures. Using this facility, a parallel ‘map’ procedure can be defined along these lines: (use-modules (ice-9 futures) (ice-9 match)) (define (par-map proc lst) (match lst (() '()) ((head tail ...) (let ((tail (future (par-map proc tail))) (head (proc head))) (cons head (touch tail)))))) Note that futures are intended for the evaluation of purely functional expressions. Expressions that have side-effects or rely on I/O may require additional care, such as explicit synchronization (*note Mutexes and Condition Variables::). Guile's futures are implemented on top of POSIX threads (*note Threads::). Internally, a fixed-size pool of threads is used to evaluate futures, such that offloading the evaluation of an expression to another thread doesn't incur thread creation costs. By default, the pool contains one thread per available CPU core, minus one, to account for the main thread. The number of available CPU cores is determined using ‘current-processor-count’ (*note Processes::). When a thread touches a future that has not completed yet, it processes any pending future while waiting for it to complete, or just waits if there are no pending futures. When ‘touch’ is called from within a future, the execution of the calling future is suspended, allowing its host thread to process other futures, and resumed when the touched future has completed. This suspend/resume is achieved by capturing the calling future's continuation, and later reinstating it (*note delimited continuations: Prompts.). -- Scheme Syntax: future exp Return a future for expression EXP. This is equivalent to: (make-future (lambda () exp)) -- Scheme Procedure: make-future thunk Return a future for THUNK, a zero-argument procedure. This procedure returns immediately. Execution of THUNK may begin in parallel with the calling thread's computations, if idle CPU cores are available, or it may start when ‘touch’ is invoked on the returned future. If the execution of THUNK throws an exception, that exception will be re-thrown when ‘touch’ is invoked on the returned future. -- Scheme Procedure: future? obj Return ‘#t’ if OBJ is a future. -- Scheme Procedure: touch f Return the result of the expression embedded in future F. If the result was already computed in parallel, ‘touch’ returns instantaneously. Otherwise, it waits for the computation to complete, if it already started, or initiates it. In the former case, the calling thread may process other futures in the meantime. 6.22.8 Parallel forms --------------------- The functions described in this section are available from (use-modules (ice-9 threads)) They provide high-level parallel constructs. The following functions are implemented in terms of futures (*note Futures::). Thus they are relatively cheap as they re-use existing threads, and portable, since they automatically use one thread per available CPU core. -- syntax: parallel expr ... Evaluate each EXPR expression in parallel, each in its own thread. Return the results of N expressions as a set of N multiple values (*note Multiple Values::). -- syntax: letpar ((var expr) ...) body1 body2 ... Evaluate each EXPR in parallel, each in its own thread, then bind the results to the corresponding VAR variables, and then evaluate BODY1 BODY2 ... ‘letpar’ is like ‘let’ (*note Local Bindings::), but all the expressions for the bindings are evaluated in parallel. -- Scheme Procedure: par-map proc lst1 lst2 ... -- Scheme Procedure: par-for-each proc lst1 lst2 ... Call PROC on the elements of the given lists. ‘par-map’ returns a list comprising the return values from PROC. ‘par-for-each’ returns an unspecified value, but waits for all calls to complete. The PROC calls are ‘(PROC ELEM1 ELEM2 ...)’, where each ELEM is from the corresponding LST . Each LST must be the same length. The calls are potentially made in parallel, depending on the number of CPU cores available. These functions are like ‘map’ and ‘for-each’ (*note List Mapping::), but make their PROC calls in parallel. Unlike those above, the functions described below take a number of threads as an argument. This makes them inherently non-portable since the specified number of threads may differ from the number of available CPU cores as returned by ‘current-processor-count’ (*note Processes::). In addition, these functions create the specified number of threads when they are called and terminate them upon completion, which makes them quite expensive. Therefore, they should be avoided. -- Scheme Procedure: n-par-map n proc lst1 lst2 ... -- Scheme Procedure: n-par-for-each n proc lst1 lst2 ... Call PROC on the elements of the given lists, in the same way as ‘par-map’ and ‘par-for-each’ above, but use no more than N threads at any one time. The order in which calls are initiated within that threads limit is unspecified. These functions are good for controlling resource consumption if PROC calls might be costly, or if there are many to be made. On a dual-CPU system for instance N=4 might be enough to keep the CPUs utilized, and not consume too much memory. -- Scheme Procedure: n-for-each-par-map n sproc pproc lst1 lst2 ... Apply PPROC to the elements of the given lists, and apply SPROC to each result returned by PPROC. The final return value is unspecified, but all calls will have been completed before returning. The calls made are ‘(SPROC (PPROC ELEM1 ... ELEMN))’, where each ELEM is from the corresponding LST. Each LST must have the same number of elements. The PPROC calls are made in parallel, in separate threads. No more than N threads are used at any one time. The order in which PPROC calls are initiated within that limit is unspecified. The SPROC calls are made serially, in list element order, one at a time. PPROC calls on later elements may execute in parallel with the SPROC calls. Exactly which thread makes each SPROC call is unspecified. This function is designed for individual calculations that can be done in parallel, but with results needing to be handled serially, for instance to write them to a file. The N limit on threads controls system resource usage when there are many calculations or when they might be costly. It will be seen that ‘n-for-each-par-map’ is like a combination of ‘n-par-map’ and ‘for-each’, (for-each sproc (n-par-map n pproc lst1 ... lstN)) But the actual implementation is more efficient since each SPROC call, in turn, can be initiated once the relevant PPROC call has completed, it doesn't need to wait for all to finish. 6.23 Configuration, Features and Runtime Options ================================================ Why is my Guile different from your Guile? There are three kinds of possible variation: • build differences -- different versions of the Guile source code, installation directories, configuration flags that control pieces of functionality being included or left out, etc. • differences in dynamically loaded code -- behavior and features provided by modules that can be dynamically loaded into a running Guile • different runtime options -- some of the options that are provided for controlling Guile's behavior may be set differently. Guile provides "introspective" variables and procedures to query all of these possible variations at runtime. For runtime options, it also provides procedures to change the settings of options and to obtain documentation on what the options mean. 6.23.1 Configuration, Build and Installation -------------------------------------------- The following procedures and variables provide information about how Guile was configured, built and installed on your system. -- Scheme Procedure: version -- Scheme Procedure: effective-version -- Scheme Procedure: major-version -- Scheme Procedure: minor-version -- Scheme Procedure: micro-version -- C Function: scm_version () -- C Function: scm_effective_version () -- C Function: scm_major_version () -- C Function: scm_minor_version () -- C Function: scm_micro_version () Return a string describing Guile's full version number, effective version number, major, minor or micro version number, respectively. The ‘effective-version’ function returns the version name that should remain unchanged during a stable series. Currently that means that it omits the micro version. The effective version should be used for items like the versioned share directory name i.e. ‘/usr/share/guile/3.0/’ (version) ⇒ "3.0.0" (effective-version) ⇒ "3.0" (major-version) ⇒ "3" (minor-version) ⇒ "0" (micro-version) ⇒ "0" -- Scheme Procedure: %package-data-dir -- C Function: scm_sys_package_data_dir () Return the name of the directory under which Guile Scheme files in general are stored. On Unix-like systems, this is usually ‘/usr/local/share/guile’ or ‘/usr/share/guile’. -- Scheme Procedure: %library-dir -- C Function: scm_sys_library_dir () Return the name of the directory where the Guile Scheme files that belong to the core Guile installation (as opposed to files from a 3rd party package) are installed. On Unix-like systems this is usually ‘/usr/local/share/guile/GUILE_EFFECTIVE_VERSION’ or ‘/usr/share/guile/GUILE_EFFECTIVE_VERSION’; for example ‘/usr/local/share/guile/3.0’. -- Scheme Procedure: %site-dir -- C Function: scm_sys_site_dir () Return the name of the directory where Guile Scheme files specific to your site should be installed. On Unix-like systems, this is usually ‘/usr/local/share/guile/site’ or ‘/usr/share/guile/site’. -- Scheme Procedure: %site-ccache-dir -- C Function: scm_sys_site_ccache_dir () Return the directory where users should install compiled ‘.go’ files for use with this version of Guile. Might look something like ‘/usr/lib/guile/3.0/site-ccache’. -- Variable: %guile-build-info Alist of information collected during the building of a particular Guile. Entries can be grouped into one of several categories: directories, env vars, and versioning info. Briefly, here are the keys in ‘%guile-build-info’, by group: directories srcdir, top_srcdir, prefix, exec_prefix, bindir, sbindir, libexecdir, datadir, sysconfdir, sharedstatedir, localstatedir, libdir, infodir, mandir, includedir, pkgdatadir, pkglibdir, pkgincludedir env vars LIBS versioning info guileversion, libguileinterface, buildstamp Values are all strings. The value for ‘LIBS’ is typically found also as a part of ‘pkg-config --libs guile-3.0’ output. The value for ‘guileversion’ has form X.Y.Z, and should be the same as returned by ‘(version)’. The value for ‘libguileinterface’ is libtool compatible and has form CURRENT:REVISION:AGE (*note Library interface versions: (libtool)Versioning.). The value for ‘buildstamp’ is the output of the command ‘date -u +'%Y-%m-%d %T'’ (UTC). In the source, ‘%guile-build-info’ is initialized from libguile/libpath.h, which is completely generated, so deleting this file before a build guarantees up-to-date values for that build. -- Variable: %host-type The canonical host type (GNU triplet) of the host Guile was configured for, e.g., ‘"x86_64-unknown-linux-gnu"’ (*note (autoconf)Canonicalizing::). 6.23.2 Feature Tracking ----------------------- Guile has a Scheme level variable ‘*features*’ that keeps track to some extent of the features that are available in a running Guile. ‘*features*’ is a list of symbols, for example ‘threads’, each of which describes a feature of the running Guile process. -- Variable: *features* A list of symbols describing available features of the Guile process. You shouldn't modify the ‘*features*’ variable directly using ‘set!’. Instead, see the procedures that are provided for this purpose in the following subsection. 6.23.2.1 Feature Manipulation ............................. To check whether a particular feature is available, use the ‘provided?’ procedure: -- Scheme Procedure: provided? feature -- Deprecated Scheme Procedure: feature? feature Return ‘#t’ if the specified FEATURE is available, otherwise ‘#f’. To advertise a feature from your own Scheme code, you can use the ‘provide’ procedure: -- Scheme Procedure: provide feature Add FEATURE to the list of available features in this Guile process. For C code, the equivalent function takes its feature name as a ‘char *’ argument for convenience: -- C Function: void scm_add_feature (const char *str) Add a symbol with name STR to the list of available features in this Guile process. 6.23.2.2 Common Feature Symbols ............................... In general, a particular feature may be available for one of two reasons. Either because the Guile library was configured and compiled with that feature enabled -- i.e. the feature is built into the library on your system. Or because some C or Scheme code that was dynamically loaded by Guile has added that feature to the list. In the first category, here are the features that the current version of Guile may define (depending on how it is built), and what they mean. ‘array’ Indicates support for arrays (*note Arrays::). ‘array-for-each’ Indicates availability of ‘array-for-each’ and other array mapping procedures (*note Arrays::). ‘char-ready?’ Indicates that the ‘char-ready?’ function is available (*note Venerable Port Interfaces::). ‘complex’ Indicates support for complex numbers. ‘current-time’ Indicates availability of time-related functions: ‘times’, ‘get-internal-run-time’ and so on (*note Time::). ‘debug-extensions’ Indicates that the debugging evaluator is available, together with the options for controlling it. ‘delay’ Indicates support for promises (*note Delayed Evaluation::). ‘EIDs’ Indicates that the ‘geteuid’ and ‘getegid’ really return effective user and group IDs (*note Processes::). ‘inexact’ Indicates support for inexact numbers. ‘i/o-extensions’ Indicates availability of the following extended I/O procedures: ‘ftell’, ‘redirect-port’, ‘dup->fdes’, ‘dup2’, ‘fileno’, ‘isatty?’, ‘fdopen’, ‘primitive-move->fdes’ and ‘fdes->ports’ (*note Ports and File Descriptors::). ‘net-db’ Indicates availability of network database functions: ‘scm_gethost’, ‘scm_getnet’, ‘scm_getproto’, ‘scm_getserv’, ‘scm_sethost’, ‘scm_setnet’, ‘scm_setproto’, ‘scm_setserv’, and their 'byXXX' variants (*note Network Databases::). ‘posix’ Indicates support for POSIX functions: ‘pipe’, ‘getgroups’, ‘kill’, ‘execl’ and so on (*note POSIX::). ‘fork’ Indicates support for the POSIX ‘fork’ function (*note ‘primitive-fork’: Processes.). ‘popen’ Indicates support for ‘open-pipe’ in the ‘(ice-9 popen)’ module (*note Pipes::). ‘random’ Indicates availability of random number generation functions: ‘random’, ‘copy-random-state’, ‘random-uniform’ and so on (*note Random::). ‘reckless’ Indicates that Guile was built with important checks omitted -- you should never see this! ‘regex’ Indicates support for POSIX regular expressions using ‘make-regexp’, ‘regexp-exec’ and friends (*note Regexp Functions::). ‘socket’ Indicates availability of socket-related functions: ‘socket’, ‘bind’, ‘connect’ and so on (*note Network Sockets and Communication::). ‘sort’ Indicates availability of sorting and merging functions (*note Sorting::). ‘system’ Indicates that the ‘system’ function is available (*note Processes::). ‘threads’ Indicates support for multithreading (*note Threads::). ‘values’ Indicates support for multiple return values using ‘values’ and ‘call-with-values’ (*note Multiple Values::). Available features in the second category depend, by definition, on what additional code your Guile process has loaded in. The following table lists features that you might encounter for this reason. ‘defmacro’ Indicates that the ‘defmacro’ macro is available (*note Macros::). ‘describe’ Indicates that the ‘(oop goops describe)’ module has been loaded, which provides a procedure for describing the contents of GOOPS instances. ‘readline’ Indicates that Guile has loaded in Readline support, for command line editing (*note Readline Support::). ‘record’ Indicates support for record definition using ‘make-record-type’ and friends (*note Records::). Although these tables may seem exhaustive, it is probably unwise in practice to rely on them, as the correspondences between feature symbols and available procedures/behavior are not strictly defined. If you are writing code that needs to check for the existence of some procedure, it is probably safer to do so directly using the ‘defined?’ procedure than to test for the corresponding feature using ‘provided?’. 6.23.3 Runtime Options ---------------------- There are a number of runtime options available for parameterizing built-in procedures, like ‘read’, and built-in behavior, like what happens on an uncaught error. For more information on reader options, *Note Scheme Read::. For more information on print options, *Note Scheme Write::. Finally, for more information on debugger options, *Note Debug Options::. 6.23.3.1 Examples of option use ............................... Here is an example of a session in which some read and debug option handling procedures are used. In this example, the user 1. Notices that the symbols ‘abc’ and ‘aBc’ are not the same 2. Examines the ‘read-options’, and sees that ‘case-insensitive’ is set to "no". 3. Enables ‘case-insensitive’ 4. Quits the recursive prompt 5. Verifies that now ‘aBc’ and ‘abc’ are the same scheme@(guile-user)> (define abc "hello") scheme@(guile-user)> abc $1 = "hello" scheme@(guile-user)> aBc : warning: possibly unbound variable `aBc' ERROR: In procedure module-lookup: ERROR: Unbound variable: aBc Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. scheme@(guile-user) [1]> (read-options 'help) copy no Copy source code expressions. positions yes Record positions of source code expressions. case-insensitive no Convert symbols to lower case. keywords #f Style of keyword recognition: #f, 'prefix or 'postfix. r6rs-hex-escapes no Use R6RS variable-length character and string hex escapes. square-brackets yes Treat `[' and `]' as parentheses, for R6RS compatibility. hungry-eol-escapes no In strings, consume leading whitespace after an escaped end-of-line. curly-infix no Support SRFI-105 curly infix expressions. scheme@(guile-user) [1]> (read-enable 'case-insensitive) $2 = (square-brackets keywords #f case-insensitive positions) scheme@(guile-user) [1]> ,q scheme@(guile-user)> aBc $3 = "hello" 6.24 Support for Other Languages ================================ In addition to Scheme, a user may write a Guile program in an increasing number of other languages. Currently supported languages include Emacs Lisp and ECMAScript. Guile is still fundamentally a Scheme, but it tries to support a wide variety of language building-blocks, so that other languages can be implemented on top of Guile. This allows users to write or extend applications in languages other than Scheme, too. This section describes the languages that have been implemented. (For details on how to implement a language, *Note Compiling to the Virtual Machine::.) 6.24.1 Using Other Languages ---------------------------- There are currently only two ways to access other languages from within Guile: at the REPL, and programmatically, via ‘compile’, ‘read-and-compile’, and ‘compile-file’. The REPL is Guile's command prompt (*note Using Guile Interactively::). The REPL has a concept of the "current language", which defaults to Scheme. The user may change that language, via the meta-command ‘,language’. For example, the following meta-command enables Emacs Lisp input: scheme@(guile-user)> ,language elisp Happy hacking with Emacs Lisp! To switch back, type `,L scheme'. elisp@(guile-user)> (eq 1 2) $1 = #nil Each language has its short name: for example, ‘elisp’, for Elisp. The same short name may be used to compile source code programmatically, via ‘compile’: elisp@(guile-user)> ,L scheme Happy hacking with Guile Scheme! To switch back, type `,L elisp'. scheme@(guile-user)> (compile '(eq 1 2) #:from 'elisp) $2 = #nil Granted, as the input to ‘compile’ is a datum, this works best for Lispy languages, which have a straightforward datum representation. Other languages that need more parsing are better dealt with as strings. The easiest way to deal with syntax-heavy language is with files, via ‘compile-file’ and friends. However it is possible to invoke a language's reader on a port, and then compile the resulting expression (which is a datum at that point). For more information, *Note Compilation::. For more details on introspecting aspects of different languages, *Note Compiler Tower::. 6.24.2 Emacs Lisp ----------------- Emacs Lisp (Elisp) is a dynamically-scoped Lisp dialect used in the Emacs editor. *Note Overview: (elisp)top, for more information on Emacs Lisp. We hope that eventually Guile's implementation of Elisp will be good enough to replace Emacs' own implementation of Elisp. For that reason, we have thought long and hard about how to support the various features of Elisp in a performant and compatible manner. Readers familiar with Emacs Lisp might be curious about how exactly these various Elisp features are supported in Guile. The rest of this section focuses on addressing these concerns of the Elisp elect. 6.24.2.1 Nil ............ ‘nil’ in ELisp is an amalgam of Scheme's ‘#f’ and ‘'()’. It is false, and it is the end-of-list; thus it is a boolean, and a list as well. Guile has chosen to support ‘nil’ as a separate value, distinct from ‘#f’ and ‘'()’. This allows existing Scheme and Elisp code to maintain their current semantics. ‘nil’, which in Elisp would just be written and read as ‘nil’, in Scheme has the external representation ‘#nil’. In Elisp code, ‘#nil’, ‘#f’, and ‘'()’ behave like ‘nil’, in the sense that they are all interpreted as ‘nil’ by Elisp ‘if’, ‘cond’, ‘when’, ‘not’, ‘null’, etc. To test whether Elisp would interpret an object as ‘nil’ from within Scheme code, use ‘nil?’: -- Scheme Procedure: nil? obj Return ‘#t’ if OBJ would be interpreted as ‘nil’ by Emacs Lisp code, else return ‘#f’. (nil? #nil) ⇒ #t (nil? #f) ⇒ #t (nil? '()) ⇒ #t (nil? 3) ⇒ #f This decision to have ‘nil’ as a low-level distinct value facilitates interoperability between the two languages. Guile has chosen to have Scheme deal with ‘nil’ as follows: (boolean? #nil) ⇒ #t (not #nil) ⇒ #t (null? #nil) ⇒ #t And in C, one has: scm_is_bool (SCM_ELISP_NIL) ⇒ 1 scm_is_false (SCM_ELISP_NIL) ⇒ 1 scm_is_null (SCM_ELISP_NIL) ⇒ 1 In this way, a version of ‘fold’ written in Scheme can correctly fold a function written in Elisp (or in fact any other language) over a nil-terminated list, as Elisp makes. The converse holds as well; a version of ‘fold’ written in Elisp can fold over a ‘'()’-terminated list, as made by Scheme. On a low level, the bit representations for ‘#f’, ‘#t’, ‘nil’, and ‘'()’ are made in such a way that they differ by only one bit, and so a test for, for example, ‘#f’-or-‘nil’ may be made very efficiently. See ‘libguile/boolean.h’, for more information. Equality ........ Since Scheme's ‘equal?’ must be transitive, and ‘'()’ is not ‘equal?’ to ‘#f’, to Scheme ‘nil’ is not ‘equal?’ to ‘#f’ or ‘'()’. (eq? #f '()) ⇒ #f (eq? #nil '()) ⇒ #f (eq? #nil #f) ⇒ #f (eqv? #f '()) ⇒ #f (eqv? #nil '()) ⇒ #f (eqv? #nil #f) ⇒ #f (equal? #f '()) ⇒ #f (equal? #nil '()) ⇒ #f (equal? #nil #f) ⇒ #f However, in Elisp, ‘'()’, ‘#f’, and ‘nil’ are all ‘equal’ (though not ‘eq’). (defvar f (make-scheme-false)) (defvar eol (make-scheme-null)) (eq f eol) ⇒ nil (eq nil eol) ⇒ nil (eq nil f) ⇒ nil (equal f eol) ⇒ t (equal nil eol) ⇒ t (equal nil f) ⇒ t These choices facilitate interoperability between Elisp and Scheme code, but they are not perfect. Some code that is correct standard Scheme is not correct in the presence of a second false and null value. For example: (define (truthiness x) (if (eq? x #f) #f #t)) This code seems to be meant to test a value for truth, but now that there are two false values, ‘#f’ and ‘nil’, it is no longer correct. Similarly, there is the loop: (define (my-length l) (let lp ((l l) (len 0)) (if (eq? l '()) len (lp (cdr l) (1+ len))))) Here, ‘my-length’ will raise an error if L is a ‘nil’-terminated list. Both of these examples are correct standard Scheme, but, depending on what they really want to do, they are not correct Guile Scheme. Correctly written, they would test the _properties_ of falsehood or nullity, not the individual members of that set. That is to say, they should use ‘not’ or ‘null?’ to test for falsehood or nullity, not ‘eq?’ or ‘memv’ or the like. Fortunately, using ‘not’ and ‘null?’ is in good style, so all well-written standard Scheme programs are correct, in Guile Scheme. Here are correct versions of the above examples: (define (truthiness* x) (if (not x) #f #t)) ;; or: (define (t* x) (not (not x))) ;; or: (define (t** x) x) (define (my-length* l) (let lp ((l l) (len 0)) (if (null? l) len (lp (cdr l) (1+ len))))) This problem has a mirror-image case in Elisp: (defun my-falsep (x) (if (eq x nil) t nil)) Guile can warn when compiling code that has equality comparisons with ‘#f’, ‘'()’, or ‘nil’. *Note Compilation::, for details. 6.24.2.2 Dynamic Binding ........................ In contrast to Scheme, which uses "lexical scoping", Emacs Lisp scopes its variables dynamically. Guile supports dynamic scoping with its "fluids" facility. *Note Fluids and Dynamic States::, for more information. 6.24.2.3 Other Elisp Features ............................. Buffer-local and mode-local variables should be mentioned here, along with buckybits on characters, Emacs primitive data types, the Lisp-2-ness of Elisp, and other things. Contributions to the documentation are most welcome! 6.24.3 ECMAScript ----------------- ECMAScript (http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf) was not the first non-Schemey language implemented by Guile, but it was the first implemented for Guile's bytecode compiler. The goal was to support ECMAScript version 3.1, a relatively small language, but the implementer was completely irresponsible and got distracted by other things before finishing the standard library, and even some bits of the syntax. So, ECMAScript does deserve a mention in the manual, but it doesn't deserve an endorsement until its implementation is completed, perhaps by some more responsible hacker. In the meantime, the charitable user might investigate such invocations as ‘,L ecmascript’ and ‘cat test-suite/tests/ecmascript.test’. 6.25 Support for Internationalization ===================================== Guile provides internationalization(1) support for Scheme programs in two ways. First, procedures to manipulate text and data in a way that conforms to particular cultural conventions (i.e., in a "locale-dependent" way) are provided in the ‘(ice-9 i18n)’. Second, Guile allows the use of GNU ‘gettext’ to translate program message strings. ---------- Footnotes ---------- (1) For concision and style, programmers often like to refer to internationalization as "i18n". 6.25.1 Internationalization with Guile -------------------------------------- In order to make use of the functions described thereafter, the ‘(ice-9 i18n)’ module must be imported in the usual way: (use-modules (ice-9 i18n)) The ‘(ice-9 i18n)’ module provides procedures to manipulate text and other data in a way that conforms to the cultural conventions chosen by the user. Each region of the world or language has its own customs to, for instance, represent real numbers, classify characters, collate text, etc. All these aspects comprise the so-called "cultural conventions" of that region or language. Computer systems typically refer to a set of cultural conventions as a “locale”. For each particular aspect that comprise those cultural conventions, a “locale category” is defined. For instance, the way characters are classified is defined by the ‘LC_CTYPE’ category, while the language in which program messages are issued to the user is defined by the ‘LC_MESSAGES’ category (*note General Locale Information: Locales. for details). The procedures provided by this module allow the development of programs that adapt automatically to any locale setting. As we will see later, many of these procedures can optionally take a “locale object” argument. This additional argument defines the locale settings that must be followed by the invoked procedure. When it is omitted, then the current locale settings of the process are followed (*note ‘setlocale’: Locales.). The following procedures allow the manipulation of such locale objects. -- Scheme Procedure: make-locale category-list locale-name [base-locale] -- C Function: scm_make_locale (category_list, locale_name, base_locale) Return a reference to a data structure representing a set of locale datasets. LOCALE-NAME should be a string denoting a particular locale (e.g., ‘"aa_DJ"’) and CATEGORY-LIST should be either a list of locale categories or a single category as used with ‘setlocale’ (*note ‘setlocale’: Locales.). Optionally, if ‘base-locale’ is passed, it should be a locale object denoting settings for categories not listed in CATEGORY-LIST. The following invocation creates a locale object that combines the use of Swedish for messages and character classification with the default settings for the other categories (i.e., the settings of the default ‘C’ locale which usually represents conventions in use in the USA): (make-locale (list LC_MESSAGES LC_CTYPE) "sv_SE") The following example combines the use of Esperanto messages and conventions with monetary conventions from Croatia: (make-locale LC_MONETARY "hr_HR" (make-locale LC_ALL "eo_EO")) A ‘system-error’ exception (*note Handling Errors::) is raised by ‘make-locale’ when LOCALE-NAME does not match any of the locales compiled on the system. Note that on non-GNU systems, this error may be raised later, when the locale object is actually used. -- Scheme Procedure: locale? obj -- C Function: scm_locale_p (obj) Return true if OBJ is a locale object. -- Scheme Variable: %global-locale -- C Variable: scm_global_locale This variable is bound to a locale object denoting the current process locale as installed using ‘setlocale ()’ (*note Locales::). It may be used like any other locale object, including as a third argument to ‘make-locale’, for instance. 6.25.2 Text Collation --------------------- The following procedures provide support for text collation, i.e., locale-dependent string and character sorting. -- Scheme Procedure: string-locale? s1 s2 [locale] -- C Function: scm_string_locale_gt (s1, s2, locale) -- Scheme Procedure: string-locale-ci? s1 s2 [locale] -- C Function: scm_string_locale_ci_gt (s1, s2, locale) Compare strings S1 and S2 in a locale-dependent way. If LOCALE is provided, it should be locale object (as returned by ‘make-locale’) and will be used to perform the comparison; otherwise, the current system locale is used. For the ‘-ci’ variants, the comparison is made in a case-insensitive way. -- Scheme Procedure: string-locale-ci=? s1 s2 [locale] -- C Function: scm_string_locale_ci_eq (s1, s2, locale) Compare strings S1 and S2 in a case-insensitive, and locale-dependent way. If LOCALE is provided, it should be a locale object (as returned by ‘make-locale’) and will be used to perform the comparison; otherwise, the current system locale is used. -- Scheme Procedure: char-locale? c1 c2 [locale] -- C Function: scm_char_locale_gt (c1, c2, locale) -- Scheme Procedure: char-locale-ci? c1 c2 [locale] -- C Function: scm_char_locale_ci_gt (c1, c2, locale) Compare characters C1 and C2 according to either LOCALE (a locale object as returned by ‘make-locale’) or the current locale. For the ‘-ci’ variants, the comparison is made in a case-insensitive way. -- Scheme Procedure: char-locale-ci=? c1 c2 [locale] -- C Function: scm_char_locale_ci_eq (c1, c2, locale) Return true if character C1 is equal to C2, in a case insensitive way according to LOCALE or to the current locale. 6.25.3 Character Case Mapping ----------------------------- The procedures below provide support for "character case mapping", i.e., to convert characters or strings to their upper-case or lower-case equivalent. Note that SRFI-13 provides procedures that look similar (*note Alphabetic Case Mapping::). However, the SRFI-13 procedures are locale-independent. Therefore, they do not take into account specificities of the customs in use in a particular language or region of the world. For instance, while most languages using the Latin alphabet map lower-case letter "i" to upper-case letter "I", Turkish maps lower-case "i" to "Latin capital letter I with dot above". The following procedures allow programmers to provide idiomatic character mapping. -- Scheme Procedure: char-locale-downcase chr [locale] -- C Function: scm_char_locale_upcase (chr, locale) Return the lowercase character that corresponds to CHR according to either LOCALE or the current locale. -- Scheme Procedure: char-locale-upcase chr [locale] -- C Function: scm_char_locale_downcase (chr, locale) Return the uppercase character that corresponds to CHR according to either LOCALE or the current locale. -- Scheme Procedure: char-locale-titlecase chr [locale] -- C Function: scm_char_locale_titlecase (chr, locale) Return the titlecase character that corresponds to CHR according to either LOCALE or the current locale. -- Scheme Procedure: string-locale-upcase str [locale] -- C Function: scm_string_locale_upcase (str, locale) Return a new string that is the uppercase version of STR according to either LOCALE or the current locale. -- Scheme Procedure: string-locale-downcase str [locale] -- C Function: scm_string_locale_downcase (str, locale) Return a new string that is the down-case version of STR according to either LOCALE or the current locale. -- Scheme Procedure: string-locale-titlecase str [locale] -- C Function: scm_string_locale_titlecase (str, locale) Return a new string that is the titlecase version of STR according to either LOCALE or the current locale. 6.25.4 Number Input and Output ------------------------------ The following procedures allow programs to read and write numbers written according to a particular locale. As an example, in English, "ten thousand and a half" is usually written ‘10,000.5’ while in French it is written ‘10 000,5’. These procedures allow such differences to be taken into account. -- Scheme Procedure: locale-string->integer str [base [locale]] -- C Function: scm_locale_string_to_integer (str, base, locale) Convert string STR into an integer according to either LOCALE (a locale object as returned by ‘make-locale’) or the current process locale. If BASE is specified, then it determines the base of the integer being read (e.g., ‘16’ for an hexadecimal number, ‘10’ for a decimal number); by default, decimal numbers are read. Return two values (*note Multiple Values::): an integer (on success) or ‘#f’, and the number of characters read from STR (‘0’ on failure). This function is based on the C library's ‘strtol’ function (*note ‘strtol’: (libc)Parsing of Integers.). -- Scheme Procedure: locale-string->inexact str [locale] -- C Function: scm_locale_string_to_inexact (str, locale) Convert string STR into an inexact number according to either LOCALE (a locale object as returned by ‘make-locale’) or the current process locale. Return two values (*note Multiple Values::): an inexact number (on success) or ‘#f’, and the number of characters read from STR (‘0’ on failure). This function is based on the C library's ‘strtod’ function (*note ‘strtod’: (libc)Parsing of Floats.). -- Scheme Procedure: number->locale-string number [fraction-digits [locale]] Convert NUMBER (an inexact) into a string according to the cultural conventions of either LOCALE (a locale object) or the current locale. By default, print as many fractional digits as necessary, up to an upper bound. Optionally, FRACTION-DIGITS may be bound to an integer specifying the number of fractional digits to be displayed. -- Scheme Procedure: monetary-amount->locale-string amount intl? [locale] Convert AMOUNT (an inexact denoting a monetary amount) into a string according to the cultural conventions of either LOCALE (a locale object) or the current locale. If INTL? is true, then the international monetary format for the given locale is used (*note international and locale monetary formats: (libc)Currency Symbol.). 6.25.5 Accessing Locale Information ----------------------------------- It is sometimes useful to obtain very specific information about a locale such as the word it uses for days or months, its format for representing floating-point figures, etc. The ‘(ice-9 i18n)’ module provides support for this in a way that is similar to the libc functions ‘nl_langinfo ()’ and ‘localeconv ()’ (*note accessing locale information from C: (libc)Locale Information.). The available functions are listed below. -- Scheme Procedure: locale-encoding [locale] Return the name of the encoding (a string whose interpretation is system-dependent) of either LOCALE or the current locale. The following functions deal with dates and times. -- Scheme Procedure: locale-day day [locale] -- Scheme Procedure: locale-day-short day [locale] -- Scheme Procedure: locale-month month [locale] -- Scheme Procedure: locale-month-short month [locale] Return the word (a string) used in either LOCALE or the current locale to name the day (or month) denoted by DAY (or MONTH), an integer between 1 and 7 (or 1 and 12). The ‘-short’ variants provide an abbreviation instead of a full name. -- Scheme Procedure: locale-am-string [locale] -- Scheme Procedure: locale-pm-string [locale] Return a (potentially empty) string that is used to denote ante meridiem (or post meridiem) hours in 12-hour format. -- Scheme Procedure: locale-date+time-format [locale] -- Scheme Procedure: locale-date-format [locale] -- Scheme Procedure: locale-time-format [locale] -- Scheme Procedure: locale-time+am/pm-format [locale] -- Scheme Procedure: locale-era-date-format [locale] -- Scheme Procedure: locale-era-date+time-format [locale] -- Scheme Procedure: locale-era-time-format [locale] These procedures return format strings suitable to ‘strftime’ (*note Time::) that may be used to display (part of) a date/time according to certain constraints and to the conventions of either LOCALE or the current locale (*note the ‘nl_langinfo ()’ items: (libc)The Elegant and Fast Way.). -- Scheme Procedure: locale-era [locale] -- Scheme Procedure: locale-era-year [locale] These functions return, respectively, the era and the year of the relevant era used in LOCALE or the current locale. Most locales do not define this value. In this case, the empty string is returned. An example of a locale that does define this value is the Japanese one. The following procedures give information about number representation. -- Scheme Procedure: locale-decimal-point [locale] -- Scheme Procedure: locale-thousands-separator [locale] These functions return a string denoting the representation of the decimal point or that of the thousand separator (respectively) for either LOCALE or the current locale. -- Scheme Procedure: locale-digit-grouping [locale] Return a (potentially circular) list of integers denoting how digits of the integer part of a number are to be grouped, starting at the decimal point and going to the left. The list contains integers indicating the size of the successive groups, from right to left. If the list is non-circular, then no grouping occurs for digits beyond the last group. For instance, if the returned list is a circular list that contains only ‘3’ and the thousand separator is ‘","’ (as is the case with English locales), then the number ‘12345678’ should be printed ‘12,345,678’. The following procedures deal with the representation of monetary amounts. Some of them take an additional INTL? argument (a boolean) that tells whether the international or local monetary conventions for the given locale are to be used. -- Scheme Procedure: locale-monetary-decimal-point [locale] -- Scheme Procedure: locale-monetary-thousands-separator [locale] -- Scheme Procedure: locale-monetary-grouping [locale] These are the monetary counterparts of the above procedures. These procedures apply to monetary amounts. -- Scheme Procedure: locale-currency-symbol intl? [locale] Return the currency symbol (a string) of either LOCALE or the current locale. The following example illustrates the difference between the local and international monetary formats: (define us (make-locale LC_MONETARY "en_US")) (locale-currency-symbol #f us) ⇒ "-$" (locale-currency-symbol #t us) ⇒ "USD " -- Scheme Procedure: locale-monetary-fractional-digits intl? [locale] Return the number of fractional digits to be used when printing monetary amounts according to either LOCALE or the current locale. If the locale does not specify it, then ‘#f’ is returned. -- Scheme Procedure: locale-currency-symbol-precedes-positive? intl? [locale] -- Scheme Procedure: locale-currency-symbol-precedes-negative? intl? [locale] -- Scheme Procedure: locale-positive-separated-by-space? intl? [locale] -- Scheme Procedure: locale-negative-separated-by-space? intl? [locale] These procedures return a boolean indicating whether the currency symbol should precede a positive/negative number, and whether a whitespace should be inserted between the currency symbol and a positive/negative amount. -- Scheme Procedure: locale-monetary-positive-sign [locale] -- Scheme Procedure: locale-monetary-negative-sign [locale] Return a string denoting the positive (respectively negative) sign that should be used when printing a monetary amount. -- Scheme Procedure: locale-positive-sign-position -- Scheme Procedure: locale-negative-sign-position These functions return a symbol telling where a sign of a positive/negative monetary amount is to appear when printing it. The possible values are: ‘parenthesize’ The currency symbol and quantity should be surrounded by parentheses. ‘sign-before’ Print the sign string before the quantity and currency symbol. ‘sign-after’ Print the sign string after the quantity and currency symbol. ‘sign-before-currency-symbol’ Print the sign string right before the currency symbol. ‘sign-after-currency-symbol’ Print the sign string right after the currency symbol. ‘unspecified’ Unspecified. We recommend you print the sign after the currency symbol. Finally, the two following procedures may be helpful when programming user interfaces: -- Scheme Procedure: locale-yes-regexp [locale] -- Scheme Procedure: locale-no-regexp [locale] Return a string that can be used as a regular expression to recognize a positive (respectively, negative) response to a yes/no question. For the C locale, the default values are typically ‘"^[yY]"’ and ‘"^[nN]"’, respectively. Here is an example: (use-modules (ice-9 rdelim)) (format #t "Does Guile rock?~%") (let lp ((answer (read-line))) (cond ((string-match (locale-yes-regexp) answer) (format #t "High fives!~%")) ((string-match (locale-no-regexp) answer) (format #t "How about now? Does it rock yet?~%") (lp (read-line))) (else (format #t "What do you mean?~%") (lp (read-line))))) For an internationalized yes/no string output, ‘gettext’ should be used (*note Gettext Support::). Example uses of some of these functions are the implementation of the ‘number->locale-string’ and ‘monetary-amount->locale-string’ procedures (*note Number Input and Output::), as well as that the SRFI-19 date and time conversion to/from strings (*note SRFI-19::). 6.25.6 Gettext Support ---------------------- Guile provides an interface to GNU ‘gettext’ for translating message strings (*note (gettext)Introduction::). Messages are collected in domains, so different libraries and programs maintain different message catalogs. The DOMAIN parameter in the functions below is a string (it becomes part of the message catalog filename). When ‘gettext’ is not available, or if Guile was configured ‘--without-nls’, dummy functions doing no translation are provided. When ‘gettext’ support is available in Guile, the ‘i18n’ feature is provided (*note Feature Tracking::). -- Scheme Procedure: gettext msg [domain [category]] -- C Function: scm_gettext (msg, domain, category) Return the translation of MSG in DOMAIN. DOMAIN is optional and defaults to the domain set through ‘textdomain’ below. CATEGORY is optional and defaults to ‘LC_MESSAGES’ (*note Locales::). Normal usage is for MSG to be a literal string. ‘xgettext’ can extract those from the source to form a message catalog ready for translators (*note Invoking the ‘xgettext’ Program: (gettext)xgettext Invocation.). (display (gettext "You are in a maze of twisty passages.")) It is conventional to use ‘G_’ as a shorthand for ‘gettext’.(1) Libraries can define ‘G_’ in such a way to look up translations using its specific DOMAIN, allowing different parts of a program to have different translation sources. (define (G_ msg) (gettext msg "mylibrary")) (display (G_ "File not found.")) ‘G_’ is also a good place to perhaps strip disambiguating extra text from the message string, as for instance in *note How to use ‘gettext’ in GUI programs: (gettext)GUI program problems. -- Scheme Procedure: ngettext msg msgplural n [domain [category]] -- C Function: scm_ngettext (msg, msgplural, n, domain, category) Return the translation of MSG/MSGPLURAL in DOMAIN, with a plural form chosen appropriately for the number N. DOMAIN is optional and defaults to the domain set through ‘textdomain’ below. CATEGORY is optional and defaults to ‘LC_MESSAGES’ (*note Locales::). MSG is the singular form, and MSGPLURAL the plural. When no translation is available, MSG is used if N = 1, or MSGPLURAL otherwise. When translated, the message catalog can have a different rule, and can have more than two possible forms. As per ‘gettext’ above, normal usage is for MSG and MSGPLURAL to be literal strings, since ‘xgettext’ can extract them from the source to build a message catalog. For example, (define (done n) (format #t (ngettext "~a file processed\n" "~a files processed\n" n) n)) (done 1) ⊣ 1 file processed (done 3) ⊣ 3 files processed It's important to use ‘ngettext’ rather than plain ‘gettext’ for plurals, since the rules for singular and plural forms in English are not the same in other languages. Only ‘ngettext’ will allow translators to give correct forms (*note Additional functions for plural forms: (gettext)Plural forms.). -- Scheme Procedure: textdomain [domain] -- C Function: scm_textdomain (domain) Get or set the default gettext domain. When called with no parameter the current domain is returned. When called with a parameter, DOMAIN is set as the current domain, and that new value returned. For example, (textdomain "myprog") ⇒ "myprog" -- Scheme Procedure: bindtextdomain domain [directory] -- C Function: scm_bindtextdomain (domain, directory) Get or set the directory under which to find message files for DOMAIN. When called without a DIRECTORY the current setting is returned. When called with a DIRECTORY, DIRECTORY is set for DOMAIN and that new setting returned. For example, (bindtextdomain "myprog" "/my/tree/share/locale") ⇒ "/my/tree/share/locale" When using Autoconf/Automake, an application should arrange for the configured ‘localedir’ to get into the program (by substituting, or by generating a config file) and set that for its domain. This ensures the catalog can be found even when installed in a non-standard location. -- Scheme Procedure: bind-textdomain-codeset domain [encoding] -- C Function: scm_bind_textdomain_codeset (domain, encoding) Get or set the text encoding to be used by ‘gettext’ for messages from DOMAIN. ENCODING is a string, the name of a coding system, for instance "8859_1". (On a Unix/POSIX system the ‘iconv’ program can list all available encodings.) When called without an ENCODING the current setting is returned, or ‘#f’ if none yet set. When called with an ENCODING, it is set for DOMAIN and that new setting returned. For example, (bind-textdomain-codeset "myprog") ⇒ #f (bind-textdomain-codeset "myprog" "latin-9") ⇒ "latin-9" The encoding requested can be different from the translated data file, messages will be recoded as necessary. But note that when there is no translation, ‘gettext’ returns its MSG unchanged, ie. without any recoding. For that reason source message strings are best as plain ASCII. Currently Guile has no understanding of multi-byte characters, and string functions won't recognize character boundaries in multi-byte strings. An application will at least be able to pass such strings through to some output though. Perhaps this will change in the future. ---------- Footnotes ---------- (1) Users of ‘gettext’ might be a bit surprised that ‘G_’ is the conventional abbreviation for ‘gettext’. In most other languages, the conventional shorthand is ‘_’. Guile uses ‘G_’ because ‘_’ is already taken, as it is bound to a syntactic keyword used by ‘syntax-rules’, ‘match’, and other macros. 6.26 Debugging Infrastructure ============================= In order to understand Guile's debugging facilities, you first need to understand a little about how Guile represents the Scheme control stack. With that in place we explain the low level trap calls that the virtual machine can be configured to make, and the trap and breakpoint infrastructure that builds on top of those calls. 6.26.1 Evaluation and the Scheme Stack -------------------------------------- The idea of the Scheme stack is central to a lot of debugging. The Scheme stack is a reified representation of the pending function returns in an expression's continuation. As Guile implements function calls using a stack, this reification takes the form of a number of nested stack frames, each of which corresponds to the application of a procedure to a set of arguments. A Scheme stack always exists implicitly, and can be summoned into concrete existence as a first-class Scheme value by the ‘make-stack’ call, so that an introspective Scheme program - such as a debugger - can present it in some way and allow the user to query its details. The first thing to understand, therefore, is how Guile's function call convention creates the stack. Broadly speaking, Guile represents all control flow on a stack. Calling a function involves pushing an empty frame on the stack, then evaluating the procedure and its arguments, then fixing up the new frame so that it points to the old one. Frames on the stack are thus linked together. A tail call is the same, except it reuses the existing frame instead of pushing on a new one. In this way, the only frames that are on the stack are "active" frames, frames which need to do some work before the computation is complete. On the other hand, a function that has tail-called another function will not be on the stack, as it has no work left to do. Therefore, when an error occurs in a running program, or the program hits a breakpoint, or in fact at any point that the programmer chooses, its state at that point can be represented by a “stack” of all the procedure applications that are logically in progress at that time, each of which is known as a “frame”. The programmer can learn more about the program's state at that point by inspecting the stack and its frames. 6.26.1.1 Stack Capture ...................... A Scheme program can use the ‘make-stack’ primitive anywhere in its code, with first arg ‘#t’, to construct a Scheme value that describes the Scheme stack at that point. (make-stack #t) ⇒ # Use ‘start-stack’ to limit the stack extent captured by future ‘make-stack’ calls. -- Scheme Procedure: make-stack obj arg ... -- C Function: scm_make_stack (obj, args) Create a new stack. If OBJ is ‘#t’, the current evaluation stack is used for creating the stack frames, otherwise the frames are taken from OBJ (which must be a continuation or a frame object). ARG ... can be any combination of integer, procedure, address range, and prompt tag values. These values specify various ways of cutting away uninteresting stack frames from the top and bottom of the stack that ‘make-stack’ returns. They come in pairs like this: ‘(INNER_CUT_1 OUTER_CUT_1 INNER_CUT_2 OUTER_CUT_2 ...)’. Each INNER_CUT_I can be an integer, a procedure, an address range, or a prompt tag. An integer means to cut away exactly that number of frames. A procedure means to cut away all frames up to but excluding the frame whose procedure matches the specified one. An address range is a pair of integers indicating the low and high addresses of a procedure's code, and is the same as cutting away to a procedure (though with less work). Anything else is interpreted as a prompt tag which cuts away all frames that are inside a prompt with the given tag. Each OUTER_CUT_I can likewise be an integer, a procedure, an address range, or a prompt tag. An integer means to cut away that number of frames. A procedure means to cut away frames down to but excluding the frame whose procedure matches the specified one. An address range is the same, but with the procedure's code specified as an address range. Anything else is taken to be a prompt tag, which cuts away all frames that are outside a prompt with the given tag. If the OUTER_CUT_I of the last pair is missing, it is taken as 0. -- Scheme Syntax: start-stack id exp Evaluate EXP on a new calling stack with identity ID. If EXP is interrupted during evaluation, backtraces will not display frames farther back than EXP's top-level form. This macro is a way of artificially limiting backtraces and stack procedures, largely as a convenience to the user. 6.26.1.2 Stacks ............... -- Scheme Procedure: stack? obj -- C Function: scm_stack_p (obj) Return ‘#t’ if OBJ is a calling stack. -- Scheme Procedure: stack-id stack -- C Function: scm_stack_id (stack) Return the identifier given to STACK by ‘start-stack’. -- Scheme Procedure: stack-length stack -- C Function: scm_stack_length (stack) Return the length of STACK. -- Scheme Procedure: stack-ref stack index -- C Function: scm_stack_ref (stack, index) Return the INDEX'th frame from STACK. -- Scheme Procedure: display-backtrace stack port [first [depth [highlights]]] -- C Function: scm_display_backtrace_with_highlights (stack, port, first, depth, highlights) -- C Function: scm_display_backtrace (stack, port, first, depth) Display a backtrace to the output port PORT. STACK is the stack to take the backtrace from, FIRST specifies where in the stack to start and DEPTH how many frames to display. FIRST and DEPTH can be ‘#f’, which means that default values will be used. If HIGHLIGHTS is given it should be a list; the elements of this list will be highlighted wherever they appear in the backtrace. 6.26.1.3 Frames ............... -- Scheme Procedure: frame? obj -- C Function: scm_frame_p (obj) Return ‘#t’ if OBJ is a stack frame. -- Scheme Procedure: frame-previous frame -- C Function: scm_frame_previous (frame) Return the previous frame of FRAME, or ‘#f’ if FRAME is the first frame in its stack. -- Scheme Procedure: frame-procedure-name frame -- C Function: scm_frame_procedure_name (frame) Return the name of the procedure being applied in FRAME, as a symbol, or ‘#f’ if the procedure has no name. -- Scheme Procedure: frame-arguments frame -- C Function: scm_frame_arguments (frame) Return the arguments of FRAME. -- Scheme Procedure: frame-address frame -- Scheme Procedure: frame-instruction-pointer frame -- Scheme Procedure: frame-stack-pointer frame Accessors for the three VM registers associated with this frame: the frame pointer (fp), instruction pointer (ip), and stack pointer (sp), respectively. *Note VM Concepts::, for more information. -- Scheme Procedure: frame-dynamic-link frame -- Scheme Procedure: frame-return-address frame -- Scheme Procedure: frame-mv-return-address frame Accessors for the three saved VM registers in a frame: the previous frame pointer, the single-value return address, and the multiple-value return address. *Note Stack Layout::, for more information. -- Scheme Procedure: frame-bindings frame Return a list of binding records indicating the local variables that are live in a frame. -- Scheme Procedure: frame-lookup-binding frame var Fetch the bindings in FRAME, and return the first one whose name is VAR, or ‘#f’ otherwise. -- Scheme Procedure: binding-index binding -- Scheme Procedure: binding-name binding -- Scheme Procedure: binding-slot binding -- Scheme Procedure: binding-representation binding Accessors for the various fields in a binding. The implicit "callee" argument is index 0, the first argument is index 1, and so on to the end of the arguments. After that are temporary variables. Note that if a variable is dead, it might not be available. -- Scheme Procedure: binding-ref binding -- Scheme Procedure: binding-set! binding val Accessors for the values of local variables in a frame. -- Scheme Procedure: display-application frame [port [indent]] -- C Function: scm_display_application (frame, port, indent) Display a procedure application FRAME to the output port PORT. INDENT specifies the indentation of the output. Additionally, the ‘(system vm frame)’ module defines a number of higher-level introspective procedures, for example to retrieve the names of local variables, and the source location to correspond to a frame. See its source code for more details. 6.26.2 Source Properties ------------------------ How best to associate source locations with datums parsed from a port? The right way to do this is to annotate all components of each parsed datum. *Note Annotated Scheme Read::, for more on ‘read-syntax’. Guile only switched to use ‘read-syntax’ in 2021, however. For the previous thirty years, it used a mechanism known as “source properties”. As Guile reads in Scheme code from file or from standard input, it can record the file name, line number and column number where each expression begins in a side table. The way that this side table associates datums with source properties has a limitation, however: Guile can only associate source properties with freshly allocated objects. This notably excludes individual symbols, keywords, characters, booleans, or small integers. This limitation finally motivated the switch to ‘read-syntax’. -- Scheme Procedure: supports-source-properties? obj -- C Function: scm_supports_source_properties_p (obj) Return #t if source properties can be associated with OBJ, otherwise return #f. The recording of source properties is controlled by the read option named "positions" (*note Scheme Read::). This option is switched _on_ by default. Now that ‘read-syntax’ is available, however, Guile may change the default for this flag to off in the future. The following procedures can be used to access and set the source properties of read expressions. -- Scheme Procedure: set-source-properties! obj alist -- C Function: scm_set_source_properties_x (obj, alist) Install the association list ALIST as the source property list for OBJ. -- Scheme Procedure: set-source-property! obj key datum -- C Function: scm_set_source_property_x (obj, key, datum) Set the source property of object OBJ, which is specified by KEY to DATUM. Normally, the key will be a symbol. -- Scheme Procedure: source-properties obj -- C Function: scm_source_properties (obj) Return the source property association list of OBJ. -- Scheme Procedure: source-property obj key -- C Function: scm_source_property (obj, key) Return the property specified by KEY from OBJ's source properties. If the ‘positions’ reader option is enabled, supported expressions will have values set for the ‘filename’, ‘line’ and ‘column’ properties. Source properties are also associated with syntax objects. Procedural macros can get at the source location of their input using the ‘syntax-source’ accessor. *Note Syntax Transformer Helpers::, for more. Guile also defines a couple of convenience macros built on ‘syntax-source’: -- Scheme Syntax: current-source-location Expands to the source properties corresponding to the location of the ‘(current-source-location)’ form. -- Scheme Syntax: current-filename Expands to the current filename: the filename that the ‘(current-filename)’ form appears in. Expands to ‘#f’ if this information is unavailable. If you're stuck with defmacros (*note Defmacros::), and want to preserve source information, the following helper function might be useful to you: -- Scheme Procedure: cons-source xorig x y -- C Function: scm_cons_source (xorig, x, y) Create and return a new pair whose car and cdr are X and Y. Any source properties associated with XORIG are also associated with the new pair. 6.26.3 Programmatic Error Handling ---------------------------------- For better or for worse, all programs have bugs, and dealing with bugs is part of programming. This section deals with that class of bugs that causes an exception to be raised - from your own code, from within a library, or from Guile itself. 6.26.3.1 Catching Exceptions ............................ A common requirement is to be able to show as much useful context as possible when a Scheme program hits an error. The most immediate information about an error is the kind of error that it is - such as "division by zero" - and any parameters that the code which signaled the error chose explicitly to provide. This information originates with the ‘error’ or ‘raise-exception’ call (or their C code equivalents, if the error is detected by C code) that signals the error, and is passed automatically to the handler procedure of the innermost applicable exception handler. Therefore, to catch errors that occur within a chunk of Scheme code, and to intercept basic information about those errors, you need to execute that code inside the dynamic context of a ‘with-exception-handler’, or the equivalent in C. For example, to print out a message and return #f when an error occurs, you might use: (define (catch-all thunk) (with-exception-handler (lambda (exn) (format (current-error-port) "Uncaught exception: ~s\n" exn) #f) thunk #:unwind? #t)) (catch-all (lambda () (error "Not a vegetable: tomato"))) ⊣ Uncaught exception: #<&exception-with-kind-and-args ...> ⇒ #f *Note Exceptions::, for full details. 6.26.3.2 Pre-Unwind Debugging ............................. Sometimes when something goes wrong, what you want is not just a representation of the exceptional situation, but the context that brought about that situation. The example in the previous section passed ‘#:unwind #t’ to ‘with-exception-handler’, indicating that ‘raise-exception’ should unwind the stack before invoking the exception handler. However if you don't take this approach and instead let the exception handler be invoked in the context of the ‘raise-exception’, you can print a backtrace, launch a recursive debugger, or take other "pre-unwind" actions. The most basic idea would be to simply print a backtrace: (define (call-with-backtrace thunk) (with-exception-handler (lambda (exn) (backtrace) (raise-exception exn)) thunk)) Here we use the built-in ‘backtrace’ procedure to print the backtrace. -- Scheme Procedure: backtrace [highlights] -- C Function: scm_backtrace_with_highlights (highlights) -- C Function: scm_backtrace () Display a backtrace of the current stack to the current output port. If HIGHLIGHTS is given it should be a list; the elements of this list will be highlighted wherever they appear in the backtrace. By re-raising the exception, ‘call-with-backtrace’ doesn't actually handle the error. We could define a version that instead aborts the computation: (use-modules (ice-9 control)) (define (call-with-backtrace thunk) (let/ec cancel (with-exception-handler (lambda (exn) (backtrace) (cancel #f)) thunk))) In this second example, we use an escape continuation to abort the computation after printing the backtrace, returning ‘#f’ instead. It could be that you want to only print a limited backtrace. In that case, use ‘start-stack’: (use-modules (ice-9 control)) (define (call-with-backtrace thunk) (let/ec cancel (start-stack 'stack-with-backtrace (with-exception-handler (lambda (exn) (backtrace) (cancel #f)) thunk)))) There are also more powerful, programmatic ways to walk the stack using ‘make-stack’ and friends; see the API described in *note Stacks:: and *note Frames::. 6.26.3.3 call-with-error-handling ................................. The Guile REPL code (in ‘system/repl/repl.scm’ and related files) uses a ‘catch’ with a pre-unwind handler to capture the stack when an error occurs in an expression that was typed into the REPL, and debug that stack interactively in the context of the error. These procedures are available for use by user programs, in the ‘(system repl error-handling)’ module. (use-modules (system repl error-handling)) -- Scheme Procedure: call-with-error-handling thunk [#:on-error on-error='debug] [#:post-error post-error='catch] [#:pass-keys pass-keys='(quit)] [#:report-keys report-keys='(stack-overflow)] [#:trap-handler trap-handler='debug] Call a thunk in a context in which errors are handled. Note that this function was written when ‘throw’/‘catch’ were the fundamental exception handling primitives in Guile, and so exposes some aspects of that interface (notably in the form of the procedural handlers). Guile will probably replace this function with a ‘call-with-standard-exception-handling’ in the future. There are five keyword arguments: ON-ERROR Specifies what to do before the stack is unwound. Valid options are ‘debug’ (the default), which will enter a debugger; ‘pass’, in which case nothing is done, and the exception is rethrown; or a procedure, which will be the pre-unwind handler. POST-ERROR Specifies what to do after the stack is unwound. Valid options are ‘catch’ (the default), which will silently catch errors, returning the unspecified value; ‘report’, which prints out a description of the error (via ‘display-error’), and then returns the unspecified value; or a procedure, which will be the catch handler. TRAP-HANDLER Specifies a trap handler: what to do when a breakpoint is hit. Valid options are ‘debug’, which will enter the debugger; ‘pass’, which does nothing; or ‘disabled’, which disables traps entirely. *Note Traps::, for more information. PASS-KEYS A set of keys to ignore, as a list. REPORT-KEYS A set of keys to always report even if the post-error handler is ‘catch’, as a list. 6.26.3.4 Stack Overflow ....................... Every time a Scheme program makes a call that is not in tail position, it pushes a new frame onto the stack. Returning a value from a function pops the top frame off the stack. Stack frames take up memory, and as nobody has an infinite amount of memory, deep recursion could cause Guile to run out of memory. Running out of stack memory is called “stack overflow”. Stack Limits ............ Most languages have a terrible stack overflow story. For example, in C, if you use too much stack, your program will exhibit "undefined behavior", which if you are lucky means that it will crash. It's especially bad in C, as you neither know ahead of time how much stack your functions use, nor the stack limit imposed by the user's system, and the stack limit is often quite small relative to the total memory size. Managed languages like Python have a better error story, as they are defined to raise an exception on stack overflow - but like C, Python and most dynamic languages still have a fixed stack size limit that is usually much smaller than the heap. Arbitrary stack limits would have an unfortunate effect on Guile programs. For example, the following implementation of the inner loop of ‘map’ is clean and elegant: (define (map f l) (if (pair? l) (cons (f (car l)) (map f (cdr l))) '())) However, if there were a stack limit, that would limit the size of lists that can be processed with this ‘map’. Eventually, you would have to rewrite it to use iteration with an accumulator: (define (map f l) (let lp ((l l) (out '())) (if (pair? l) (lp (cdr l) (cons (f (car l)) out)) (reverse out)))) This second version is sadly not as clear, and it also allocates more heap memory (once to build the list in reverse, and then again to reverse the list). You would be tempted to use the destructive ‘reverse!’ to save memory and time, but then your code would not be continuation-safe - if F returned again after the map had finished, it would see an OUT list that had already been reversed. The recursive ‘map’ has none of these problems. Guile has no stack limit for Scheme code. When a thread makes its first Guile call, a small stack is allocated - just one page of memory. Whenever that memory limit would be reached, Guile arranges to grow the stack by a factor of two. When garbage collection happens, Guile arranges to return the unused part of the stack to the operating system, but without causing the stack to shrink. In this way, the stack can grow to consume up to all memory available to the Guile process, and when the recursive computation eventually finishes, that stack memory is returned to the system. Exceptional Situations ...................... Of course, it's still possible to run out of stack memory. The most common cause of this is program bugs that cause unbounded recursion, as in: (define (faulty-map f l) (if (pair? l) (cons (f (car l)) (faulty-map f l)) '())) Did you spot the bug? The recursive call to ‘faulty-map’ recursed on L, not ‘(cdr L)’. Running this program would cause Guile to use up all memory in your system, and eventually Guile would fail to grow the stack. At that point you have a problem: Guile needs to raise an exception to unwind the stack and return memory to the system, but the user might have exception handlers in place (*note Raising and Handling Exceptions::) that want to run before the stack is unwound, and we don't have any stack in which to run them. Therefore in this case, Guile raises an unwind-only exception that does not run pre-unwind handlers. Because this is such an odd case, Guile prints out a message on the console, in case the user was expecting to be able to get a backtrace from any pre-unwind handler. Runaway Recursion ................. Still, this failure mode is not so nice. If you are running an environment in which you are interactively building a program while it is running, such as at a REPL, you might want to impose an artificial stack limit on the part of your program that you are building to detect accidental runaway recursion. For that purpose, there is ‘call-with-stack-overflow-handler’, from ‘(system vm vm)’. (use-module (system vm vm)) -- Scheme Procedure: call-with-stack-overflow-handler limit thunk handler Call THUNK in an environment in which the stack limit has been reduced to LIMIT additional words. If the limit is reached, HANDLER (a thunk) will be invoked in the dynamic environment of the error. For the extent of the call to HANDLER, the stack limit and handler are restored to the values that were in place when ‘call-with-stack-overflow-handler’ was called. Usually, HANDLER should raise an exception or abort to an outer prompt. However if HANDLER does return, it should return a number of additional words of stack space to allow to the inner environment. A stack overflow handler may only ever "credit" the inner thunk with stack space that was available when the handler was instated. When Guile first starts, there is no stack limit in place, so the outer handler may allow the inner thunk an arbitrary amount of space, but any nested stack overflow handler will not be able to consume more than its limit. Unlike the unwind-only exception that is thrown if Guile is unable to grow its stack, any exception thrown by a stack overflow handler might invoke pre-unwind handlers. Indeed, the stack overflow handler is itself a pre-unwind handler of sorts. If the code imposing the stack limit wants to protect itself against malicious pre-unwind handlers from the inner thunk, it should abort to a prompt of its own making instead of throwing an exception that might be caught by the inner thunk. C Stack Usage ............. It is also possible for Guile to run out of space on the C stack. If you call a primitive procedure which then calls a Scheme procedure in a loop, you will consume C stack space. Guile tries to detect excessive consumption of C stack space, throwing an error when you have hit 80% of the process' available stack (as allocated by the operating system), or 160 kilowords in the absence of a strict limit. For example, looping through ‘call-with-vm’, a primitive that calls a thunk, gives us the following: scheme@(guile-user)> (use-modules (system vm vm)) scheme@(guile-user)> (let lp () (call-with-vm lp)) ERROR: Stack overflow Unfortunately, that's all the information we get. Overrunning the C stack will throw an unwind-only exception, because it's not safe to do very much when you are close to the C stack limit. If you get an error like this, you can either try rewriting your code to use less stack space, or increase the maximum stack size. To increase the maximum stack size, use ‘debug-set!’, for example: (debug-set! stack 200000) The next section describes ‘debug-set!’ more thoroughly. Of course the best thing is to have your code operate without so much resource consumption by avoiding loops through C trampolines. 6.26.3.5 Debug options ...................... The behavior of the ‘backtrace’ procedure and of the default error handler can be parameterized via the debug options. -- Scheme Procedure: debug-options [setting] Display the current settings of the debug options. If SETTING is omitted, only a short form of the current read options is printed. Otherwise if SETTING is the symbol ‘help’, a complete options description is displayed. The set of available options, and their default values, may be had by invoking ‘debug-options’ at the prompt. scheme@(guile-user)> backwards no Display backtrace in anti-chronological order. width 79 Maximal width of backtrace. depth 20 Maximal length of printed backtrace. backtrace yes Show backtrace on error. stack 1048576 Stack size limit (measured in words; 0 = no check). show-file-name #t Show file names and line numbers in backtraces when not `#f'. A value of `base' displays only base names, while `#t' displays full names. warn-deprecated no Warn when deprecated features are used. The boolean options may be toggled with ‘debug-enable’ and ‘debug-disable’. The non-boolean options must be set using ‘debug-set!’. -- Scheme Procedure: debug-enable option-name -- Scheme Procedure: debug-disable option-name -- Scheme Syntax: debug-set! option-name value Modify the debug options. ‘debug-enable’ should be used with boolean options and switches them on, ‘debug-disable’ switches them off. ‘debug-set!’ can be used to set an option to a specific value. Due to historical oddities, it is a macro that expects an unquoted option name. 6.26.4 Traps ------------ Guile's virtual machine can be configured to call out at key points to arbitrary user-specified procedures. In principle, these “hooks” allow Scheme code to implement any model it chooses for examining the evaluation stack as program execution proceeds, and for suspending execution to be resumed later. VM hooks are very low-level, though, and so Guile also has a library of higher-level “traps” on top of the VM hooks. A trap is an execution condition that, when fulfilled, will fire a handler. For example, Guile defines a trap that fires when control reaches a certain source location. Finally, Guile also defines a third level of abstractions: per-thread “trap states”. A trap state exists to give names to traps, and to hold on to the set of traps so that they can be enabled, disabled, or removed. The trap state infrastructure defines the most useful abstractions for most cases. For example, Guile's REPL uses trap state functions to set breakpoints and tracepoints. The following subsections describe all this in detail, for both the user wanting to use traps, and the developer interested in understanding how the interface hangs together. 6.26.4.1 VM Hooks ................. Everything that runs in Guile runs on its virtual machine, a C program that defines a number of operations that Scheme programs can perform. Note that there are multiple VM "engines" for Guile. Only some of them have support for hooks compiled in. Normally the deal is that you get hooks if you are running interactively, and otherwise they are disabled, as they do have some overhead (about 10 or 20 percent). To ensure that you are running with hooks, pass ‘--debug’ to Guile when running your program, or otherwise use the ‘call-with-vm’ and ‘set-vm-engine!’ procedures to ensure that you are running in a VM with the ‘debug’ engine. To digress, Guile's VM has 4 different hooks that can be fired at different times. For implementation reasons, these hooks are not actually implemented with first-class Scheme hooks (*note Hooks::); they are managed using an ad-hoc interface. VM hooks are called with one argument: the current frame. *Note Frames::. Since these hooks may be fired very frequently, Guile does a terrible thing: it allocates the frames on the C stack instead of the garbage-collected heap. The upshot here is that the frames are only valid within the dynamic extent of the call to the hook. If a hook procedure keeps a reference to the frame outside the extent of the hook, bad things will happen. The interface to hooks is provided by the ‘(system vm vm)’ module: (use-modules (system vm vm)) All of these functions implicitly act on the VM for the current thread only. -- Scheme Procedure: vm-add-next-hook! f Arrange to call F when before an instruction is retired (and executed). -- Scheme Procedure: vm-add-apply-hook! f Arrange to call F whenever a procedure is applied. The frame locals will be the callee, followed by the arguments to the call. Note that procedure application is somewhat orthogonal to continuation pushes and pops. To know whether a call is a tail call or not, with respect to the frame previously in place, check the value of the frame pointer compared the previous frame pointer. -- Scheme Procedure: vm-add-return-hook! f Arrange to call F before returning from a frame. The values in the frame will be the frame's return values. Note that it's possible to return from an "inner" frame: one that was not immediately proceeded by a call with that frame pointer. In that case, it corresponds to a non-local control flow jump, either because of applying a composable continuation or because of restoring a saved undelimited continuation. -- Scheme Procedure: vm-add-abort-hook! Arrange to call F after aborting to a prompt. *Note Prompts::. Unfortunately, the values passed to the prompt handler are not easily available to F. -- Scheme Procedure: vm-remove-next-hook! f -- Scheme Procedure: vm-remove-apply-hook! f -- Scheme Procedure: vm-remove-return-hook! f -- Scheme Procedure: vm-remove-abort-hook! f Remove F from the corresponding VM hook for the current thread. These hooks do impose a performance penalty, if they are on. Obviously, the ‘vm-next-hook’ has quite an impact, performance-wise. Therefore Guile exposes a single, heavy-handed knob to turn hooks on or off, the “VM trace level”. If the trace level is positive, hooks run; otherwise they don't. For convenience, when the VM fires a hook, it does so with the trap level temporarily set to 0. That way the hooks don't fire while you're handling a hook. The trace level is restored to whatever it was once the hook procedure finishes. -- Scheme Procedure: vm-trace-level Retrieve the "trace level" of the VM. If positive, the trace hooks associated with VM will be run. The initial trace level is 0. -- Scheme Procedure: set-vm-trace-level! level Set the "trace level" of the VM. *Note A Virtual Machine for Guile::, for more information on Guile's virtual machine. 6.26.4.2 Trap Interface ....................... The capabilities provided by hooks are great, but hooks alone rarely correspond to what users want to do. For example, if a user wants to break when and if control reaches a certain source location, how do you do it? If you install a "next" hook, you get unacceptable overhead for the execution of the entire program. It would be possible to install an "apply" hook, then if the procedure encompasses those source locations, install a "next" hook, but already you're talking about one concept that might be implemented by a varying number of lower-level concepts. It's best to be clear about things and define one abstraction for all such conditions: the “trap”. Considering the myriad capabilities offered by the hooks though, there is only a minimum of functionality shared by all traps. Guile's current take is to reduce this to the absolute minimum, and have the only standard interface of a trap be "turn yourself on" or "turn yourself off". This interface sounds a bit strange, but it is useful to procedurally compose higher-level traps from lower-level building blocks. For example, Guile defines a trap that calls one handler when control enters a procedure, and another when control leaves the procedure. Given that trap, one can define a trap that adds to the next-hook only when within a given procedure. Building further, one can define a trap that fires when control reaches particular instructions within a procedure. Or of course you can stop at any of these intermediate levels. For example, one might only be interested in calls to a given procedure. But the point is that a simple enable/disable interface is all the commonality that exists between the various kinds of traps, and furthermore that such an interface serves to allow "higher-level" traps to be composed from more primitive ones. Specifically, a trap, in Guile, is a procedure. When a trap is created, by convention the trap is enabled; therefore, the procedure that is the trap will, when called, disable the trap, and return a procedure that will enable the trap, and so on. Trap procedures take one optional argument: the current frame. (A trap may want to add to different sets of hooks depending on the frame that is current at enable-time.) If this all sounds very complicated, it's because it is. Some of it is essential, but probably most of it is not. The advantage of using this minimal interface is that composability is more lexically apparent than when, for example, using a stateful interface based on GOOPS. But perhaps this reflects the cognitive limitations of the programmer who made the current interface more than anything else. 6.26.4.3 Low-Level Traps ........................ To summarize the last sections, traps are enabled or disabled, and when they are enabled, they add to various VM hooks. Note, however, that _traps do not increase the VM trace level_. So if you create a trap, it will be enabled, but unless something else increases the VM's trace level (*note VM Hooks::), the trap will not fire. It turns out that getting the VM trace level right is tricky without a global view of what traps are enabled. *Note Trap States::, for Guile's answer to this problem. Traps are created by calling procedures. Most of these procedures share a set of common keyword arguments, so rather than document them separately, we discuss them all together here: ‘#:vm’ The VM to instrument. Defaults to the current thread's VM. ‘#:current-frame’ For traps that enable more hooks depending on their dynamic context, this argument gives the current frame that the trap is running in. Defaults to ‘#f’. To have access to these procedures, you'll need to have imported the ‘(system vm traps)’ module: (use-modules (system vm traps)) -- Scheme Procedure: trap-at-procedure-call proc handler [#:vm] A trap that calls HANDLER when PROC is applied. -- Scheme Procedure: trap-in-procedure proc enter-handler exit-handler [#:current-frame] [#:vm] A trap that calls ENTER-HANDLER when control enters PROC, and EXIT-HANDLER when control leaves PROC. Control can enter a procedure via: • A procedure call. • A return to a procedure's frame on the stack. • A continuation returning directly to an application of this procedure. Control can leave a procedure via: • A normal return from the procedure. • An application of another procedure. • An invocation of a continuation. • An abort. -- Scheme Procedure: trap-instructions-in-procedure proc next-handler exit-handler [#:current-frame] [#:vm] A trap that calls NEXT-HANDLER for every instruction executed in PROC, and EXIT-HANDLER when execution leaves PROC. -- Scheme Procedure: trap-at-procedure-ip-in-range proc range handler [#:current-frame] [#:vm] A trap that calls HANDLER when execution enters a range of instructions in PROC. RANGE is a simple of pairs, ‘((START . END) ...)’. The START addresses are inclusive, and END addresses are exclusive. -- Scheme Procedure: trap-at-source-location file user-line handler [#:current-frame] [#:vm] A trap that fires when control reaches a given source location. The USER-LINE parameter is one-indexed, as a user counts lines, instead of zero-indexed, as Guile counts lines. -- Scheme Procedure: trap-frame-finish frame return-handler abort-handler [#:vm] A trap that fires when control leaves the given frame. FRAME should be a live frame in the current continuation. RETURN-HANDLER will be called on a normal return, and ABORT-HANDLER on a nonlocal exit. -- Scheme Procedure: trap-in-dynamic-extent proc enter-handler return-handler abort-handler [#:vm] A more traditional dynamic-wind trap, which fires ENTER-HANDLER when control enters PROC, RETURN-HANDLER on a normal return, and ABORT-HANDLER on a nonlocal exit. Note that rewinds are not handled, so there is no rewind handler. -- Scheme Procedure: trap-calls-in-dynamic-extent proc apply-handler return-handler [#:current-frame] [#:vm] A trap that calls APPLY-HANDLER every time a procedure is applied, and RETURN-HANDLER for returns, but only during the dynamic extent of an application of PROC. -- Scheme Procedure: trap-instructions-in-dynamic-extent proc next-handler [#:current-frame] [#:vm] A trap that calls NEXT-HANDLER for all retired instructions within the dynamic extent of a call to PROC. -- Scheme Procedure: trap-calls-to-procedure proc apply-handler return-handler [#:vm] A trap that calls APPLY-HANDLER whenever PROC is applied, and RETURN-HANDLER when it returns, but with an additional argument, the call depth. That is to say, the handlers will get two arguments: the frame in question, and the call depth (a non-negative integer). -- Scheme Procedure: trap-matching-instructions frame-pred handler [#:vm] A trap that calls FRAME-PRED at every instruction, and if FRAME-PRED returns a true value, calls HANDLER on the frame. 6.26.4.4 Tracing Traps ...................... The ‘(system vm trace)’ module defines a number of traps for tracing of procedure applications. When a procedure is “traced”, it means that every call to that procedure is reported to the user during a program run. The idea is that you can mark a collection of procedures for tracing, and Guile will subsequently print out a line of the form | | (PROCEDURE ARGS ...) whenever a marked procedure is about to be applied to its arguments. This can help a programmer determine whether a function is being called at the wrong time or with the wrong set of arguments. In addition, the indentation of the output is useful for demonstrating how the traced applications are or are not tail recursive with respect to each other. Thus, a trace of a non-tail recursive factorial implementation looks like this: scheme@(guile-user)> (define (fact1 n) (if (zero? n) 1 (* n (fact1 (1- n))))) scheme@(guile-user)> ,trace (fact1 4) trace: (fact1 4) trace: | (fact1 3) trace: | | (fact1 2) trace: | | | (fact1 1) trace: | | | | (fact1 0) trace: | | | | 1 trace: | | | 1 trace: | | 2 trace: | 6 trace: 24 While a typical tail recursive implementation would look more like this: scheme@(guile-user)> (define (facti acc n) (if (zero? n) acc (facti (* n acc) (1- n)))) scheme@(guile-user)> (define (fact2 n) (facti 1 n)) scheme@(guile-user)> ,trace (fact2 4) trace: (fact2 4) trace: (facti 1 4) trace: (facti 4 3) trace: (facti 12 2) trace: (facti 24 1) trace: (facti 24 0) trace: 24 The low-level traps below (*note Low-Level Traps::) share some common options: ‘#:width’ The maximum width of trace output. Trace printouts will try not to exceed this column, but for highly nested procedure calls, it may be unavoidable. Defaults to 80. ‘#:vm’ The VM on which to add the traps. Defaults to the current thread's VM. ‘#:prefix’ A string to print out before each trace line. As seen above in the examples, defaults to ‘"trace: "’. To have access to these procedures, you'll need to have imported the ‘(system vm trace)’ module: (use-modules (system vm trace)) -- Scheme Procedure: trace-calls-to-procedure proc [#:width] [#:vm] [#:prefix] Print a trace at applications of and returns from PROC. -- Scheme Procedure: trace-calls-in-procedure proc [#:width] [#:vm] [#:prefix] Print a trace at all applications and returns within the dynamic extent of calls to PROC. -- Scheme Procedure: trace-instructions-in-procedure proc [#:width] [#:vm] Print a trace at all instructions executed in the dynamic extent of calls to PROC. In addition, Guile defines a procedure to call a thunk, tracing all procedure calls and returns within the thunk. -- Scheme Procedure: call-with-trace thunk [#:calls?=#t] [#:instructions?=#f] [#:width=80] Call THUNK, tracing all execution within its dynamic extent. If CALLS? is true, Guile will print a brief report at each procedure call and return, as given above. If INSTRUCTIONS? is true, Guile will also print a message each time an instruction is executed. This is a lot of output, but it is sometimes useful when doing low-level optimization. Note that because this procedure manipulates the VM trace level directly, it doesn't compose well with traps at the REPL. *Note Profile Commands::, for more information on tracing at the REPL. 6.26.4.5 Trap States .................... When multiple traps are present in a system, we begin to have a bookkeeping problem. How are they named? How does one disable, enable, or delete them? Guile's answer to this is to keep an implicit per-thread “trap state”. The trap state object is not exposed to the user; rather, API that works on trap states fetches the current trap state from the dynamic environment. Traps are identified by integers. A trap can be enabled, disabled, or removed, and can have an associated user-visible name. These procedures have their own module: (use-modules (system vm trap-state)) -- Scheme Procedure: add-trap! trap name Add a trap to the current trap state, associating the given NAME with it. Returns a fresh trap identifier (an integer). Note that usually the more specific functions detailed in *note High-Level Traps:: are used in preference to this one. -- Scheme Procedure: list-traps List the current set of traps, both enabled and disabled. Returns a list of integers. -- Scheme Procedure: trap-name idx Returns the name associated with trap IDX, or ‘#f’ if there is no such trap. -- Scheme Procedure: trap-enabled? idx Returns ‘#t’ if trap IDX is present and enabled, or ‘#f’ otherwise. -- Scheme Procedure: enable-trap! idx Enables trap IDX. -- Scheme Procedure: disable-trap! idx Disables trap IDX. -- Scheme Procedure: delete-trap! idx Removes trap IDX, disabling it first, if necessary. 6.26.4.6 High-Level Traps ......................... The low-level trap API allows one to make traps that call procedures, and the trap state API allows one to keep track of what traps are there. But neither of these APIs directly helps you when you want to set a breakpoint, because it's unclear what to do when the trap fires. Do you enter a debugger, or mail a summary of the situation to your great-aunt, or what? So for the common case in which you just want to install breakpoints, and then have them all result in calls to one parameterizable procedure, we have the high-level trap interface. Perhaps we should have started this section with this interface, as it's clearly the one most people should use. But as its capabilities and limitations proceed from the lower layers, we felt that the character-building exercise of building a mental model might be helpful. These procedures share a module with trap states: (use-modules (system vm trap-state)) -- Scheme Procedure: with-default-trap-handler handler thunk Call THUNK in a dynamic context in which HANDLER is the current trap handler. Additionally, during the execution of THUNK, the VM trace level (*note VM Hooks::) is set to the number of enabled traps. This ensures that traps will in fact fire. HANDLER may be ‘#f’, in which case VM hooks are not enabled as they otherwise would be, as there is nothing to handle the traps. The trace-level-setting behavior of ‘with-default-trap-handler’ is one of its more useful aspects, but if you are willing to forgo that, and just want to install a global trap handler, there's a function for that too: -- Scheme Procedure: install-trap-handler! handler Set the current thread's trap handler to HANDLER. Trap handlers are called when traps installed by procedures from this module fire. The current "consumer" of this API is Guile's REPL, but one might easily imagine other trap handlers being used to integrate with other debugging tools. -- Scheme Procedure: add-trap-at-procedure-call! proc Install a trap that will fire when PROC is called. This is a breakpoint. -- Scheme Procedure: add-trace-at-procedure-call! proc Install a trap that will print a tracing message when PROC is called. *Note Tracing Traps::, for more information. This is a tracepoint. -- Scheme Procedure: add-trap-at-source-location! file user-line Install a trap that will fire when control reaches the given source location. USER-LINE is one-indexed, as users count lines, instead of zero-indexed, as Guile counts lines. This is a source breakpoint. -- Scheme Procedure: add-ephemeral-trap-at-frame-finish! frame handler Install a trap that will call HANDLER when FRAME finishes executing. The trap will be removed from the trap state after firing, or on nonlocal exit. This is a finish trap, used to implement the "finish" REPL command. -- Scheme Procedure: add-ephemeral-stepping-trap! frame handler [#:into?] [#:instruction?] Install a trap that will call HANDLER after stepping to a different source line or instruction. The trap will be removed from the trap state after firing, or on nonlocal exit. If INSTRUCTION? is false (the default), the trap will fire when control reaches a new source line. Otherwise it will fire when control reaches a new instruction. Additionally, if INTO? is false (not the default), the trap will only fire for frames at or prior to the given frame. If INTO? is true (the default), the trap may step into nested procedure invocations. This is a stepping trap, used to implement the "step", "next", "step-instruction", and "next-instruction" REPL commands. 6.26.5 GDB Support ------------------ Sometimes, you may find it necessary to debug Guile applications at the C level. Doing so can be tedious, in particular because the debugger is oblivious to Guile's ‘SCM’ type, and thus unable to display ‘SCM’ values in any meaningful way: (gdb) frame #0 scm_display (obj=0xf04310, port=0x6f9f30) at print.c:1437 To address that, Guile comes with an extension of the GNU Debugger (GDB) that contains a "pretty-printer" for ‘SCM’ values. With this GDB extension, the C frame in the example above shows up like this: (gdb) frame #0 scm_display (obj=("hello" GDB!), port=#) at print.c:1437 Here GDB was able to decode the list pointed to by OBJ, and to print it using Scheme's read syntax. That extension is a ‘.scm’ file installed alongside the ‘libguile’ shared library. When GDB 7.8 or later is installed and compiled with support for extensions written in Guile, the extension is automatically loaded when debugging a program linked against ‘libguile’ (*note (gdb)Auto-loading::). Note that the directory where ‘libguile’ is installed must be among GDB's auto-loading "safe directories" (*note (gdb)Auto-loading safe path::). 6.27 Code Coverage Reports ========================== When writing a test suite for a program or library, it is desirable to know what part of the code is “covered” by the test suite. The ‘(system vm coverage)’ module provides tools to gather code coverage data and to present them, as detailed below. -- Scheme Procedure: with-code-coverage thunk Run THUNK, a zero-argument procedure, while instrumenting Guile's virtual machine to collect code coverage data. Return code coverage data and the values returned by THUNK. -- Scheme Procedure: coverage-data? obj Return ‘#t’ if OBJ is a “coverage data” object as returned by ‘with-code-coverage’. -- Scheme Procedure: coverage-data->lcov data port #:key modules Traverse code coverage information DATA, as obtained with ‘with-code-coverage’, and write coverage information to port in the ‘.info’ format used by LCOV (http://ltp.sourceforge.net/coverage/lcov.php). The report will include all of MODULES (or, by default, all the currently loaded modules) even if their code was not executed. The generated data can be fed to LCOV's ‘genhtml’ command to produce an HTML report, which aids coverage data visualization. Here's an example use: (use-modules (system vm coverage) (system vm vm)) (call-with-values (lambda () (with-code-coverage (lambda () (do-something-tricky)))) (lambda (data result) (let ((port (open-output-file "lcov.info"))) (coverage-data->lcov data port) (close port)))) In addition, the module provides low-level procedures that would make it possible to write other user interfaces to the coverage data. -- Scheme Procedures: instrumented-source-files data Return the list of "instrumented" source files, i.e., source files whose code was loaded at the time DATA was collected. -- Scheme Procedures: line-execution-counts data file Return a list of line number/execution count pairs for FILE, or ‘#f’ if FILE is not among the files covered by DATA. This includes lines with zero count. -- Scheme Procedures: instrumented/executed-lines data file Return the number of instrumented and the number of executed source lines in FILE according to DATA. -- Scheme Procedures: procedure-execution-count data proc Return the number of times PROC's code was executed, according to DATA, or ‘#f’ if PROC was not executed. When PROC is a closure, the number of times its code was executed is returned, not the number of times this code associated with this particular closure was executed. 7 Guile Modules *************** 7.1 SLIB ======== SLIB is a portable library of Scheme packages which can be used with Guile and other Scheme implementations. SLIB is not included in the Guile distribution, but can be installed separately (*note SLIB installation::). It is available from . After SLIB is installed, the following Scheme expression must be executed before the SLIB facilities can be used: (use-modules (ice-9 slib)) ‘require’ can then be used in the usual way (*note (slib)Require::). For example, (use-modules (ice-9 slib)) (require 'primes) (prime? 13) ⇒ #t A few Guile core functions are overridden by the SLIB setups; for example the SLIB version of ‘delete-file’ returns a boolean indicating success or failure, whereas the Guile core version throws an error for failure. In general (and as might be expected) when SLIB is loaded it's the SLIB specifications that are followed. 7.1.1 SLIB installation ----------------------- The following procedure works, e.g., with SLIB version 3a3 (*note SLIB installation: (slib)Installation.): 1. Unpack SLIB and install it using ‘make install’ from its directory. By default, this will install SLIB in ‘/usr/local/lib/slib/’. Running ‘make install-info’ installs its documentation, by default under ‘/usr/local/info/’. 2. Define the ‘SCHEME_LIBRARY_PATH’ environment variable: $ SCHEME_LIBRARY_PATH=/usr/local/lib/slib/ $ export SCHEME_LIBRARY_PATH Alternatively, you can create a symlink in the Guile directory to SLIB, e.g.: ln -s /usr/local/lib/slib /usr/local/share/guile/3.0/slib 3. Use Guile to create the catalog file, e.g.,: # guile guile> (use-modules (ice-9 slib)) guile> (require 'new-catalog) guile> (quit) The catalog data should now be in ‘/usr/local/share/guile/3.0/slibcat’. If instead you get an error such as: Unbound variable: scheme-implementation-type then a solution is to get a newer version of Guile, or to modify ‘ice-9/slib.scm’ to use ‘define-public’ for the offending variables. 7.1.2 JACAL ----------- Jacal is a symbolic math package written in Scheme by Aubrey Jaffer. It is usually installed as an extra package in SLIB. You can use Guile's interface to SLIB to invoke Jacal: (use-modules (ice-9 slib)) (slib:load "math") (math) For complete documentation on Jacal, please read the Jacal manual. If it has been installed on line, you can look at *note Jacal: (jacal)Top. Otherwise you can find it on the web at 7.2 POSIX System Calls and Networking ===================================== 7.2.1 POSIX Interface Conventions --------------------------------- These interfaces provide access to operating system facilities. They provide a simple wrapping around the underlying C interfaces to make usage from Scheme more convenient. They are also used to implement the Guile port of scsh (*note The Scheme shell (scsh)::). Generally there is a single procedure for each corresponding Unix facility. There are some exceptions, such as procedures implemented for speed and convenience in Scheme with no primitive Unix equivalent, e.g. ‘copy-file’. The interfaces are intended as far as possible to be portable across different versions of Unix. In some cases procedures which can't be implemented on particular systems may become no-ops, or perform limited actions. In other cases they may throw errors. General naming conventions are as follows: • The Scheme name is often identical to the name of the underlying Unix facility. • Underscores in Unix procedure names are converted to hyphens. • Procedures which destructively modify Scheme data have exclamation marks appended, e.g., ‘recv!’. • Predicates (returning only ‘#t’ or ‘#f’) have question marks appended, e.g., ‘access?’. • Some names are changed to avoid conflict with dissimilar interfaces defined by scsh, e.g., ‘primitive-fork’. • Unix preprocessor names such as ‘EPERM’ or ‘R_OK’ are converted to Scheme variables of the same name (underscores are not replaced with hyphens). Unexpected conditions are generally handled by raising exceptions. There are a few procedures which return a special value if they don't succeed, e.g., ‘getenv’ returns ‘#f’ if it the requested string is not found in the environment. These cases are noted in the documentation. For ways to deal with exceptions, see *note Exceptions::. Errors which the C library would report by returning a null pointer or through some other means are reported by raising a ‘system-error’ exception with ‘scm-error’ (*note Error Reporting::). The DATA parameter is a list containing the Unix ‘errno’ value (an integer). For example, (define (my-handler key func fmt fmtargs data) (display key) (newline) (display func) (newline) (apply format #t fmt fmtargs) (newline) (display data) (newline)) (catch 'system-error (lambda () (dup2 -123 -456)) my-handler) ⊣ system-error dup2 Bad file descriptor (9) -- Function: system-error-errno arglist Return the ‘errno’ value from a list which is the arguments to an exception handler. If the exception is not a ‘system-error’, then the return is ‘#f’. For example, (catch 'system-error (lambda () (mkdir "/this-ought-to-fail-if-I'm-not-root")) (lambda stuff (let ((errno (system-error-errno stuff))) (cond ((= errno EACCES) (display "You're not allowed to do that.")) ((= errno EEXIST) (display "Already exists.")) (#t (display (strerror errno)))) (newline)))) 7.2.2 Ports and File Descriptors -------------------------------- Conventions generally follow those of scsh, *note The Scheme shell (scsh)::. Each open file port has an associated operating system file descriptor. File descriptors are generally not useful in Scheme programs; however they may be needed when interfacing with foreign code and the Unix environment. A file descriptor can be extracted from a port and a new port can be created from a file descriptor. However a file descriptor is just an integer and the garbage collector doesn't recognize it as a reference to the port. If all other references to the port were dropped, then it's likely that the garbage collector would free the port, with the side-effect of closing the file descriptor prematurely. To assist the programmer in avoiding this problem, each port has an associated “revealed count” which can be used to keep track of how many times the underlying file descriptor has been stored in other places. If a port's revealed count is greater than zero, the file descriptor will not be closed when the port is garbage collected. A programmer can therefore ensure that the revealed count will be greater than zero if the file descriptor is needed elsewhere. For the simple case where a file descriptor is "imported" once to become a port, it does not matter if the file descriptor is closed when the port is garbage collected. There is no need to maintain a revealed count. Likewise when "exporting" a file descriptor to the external environment, setting the revealed count is not required provided the port is kept open (i.e., is pointed to by a live Scheme binding) while the file descriptor is in use. To correspond with traditional Unix behavior, three file descriptors (0, 1, and 2) are automatically imported when a program starts up and assigned to the initial values of the current/standard input, output, and error ports, respectively. The revealed count for each is initially set to one, so that dropping references to one of these ports will not result in its garbage collection: it could be retrieved with ‘fdopen’ or ‘fdes->ports’. Guile's ports can be buffered. This means that writing a byte to a file port goes to the internal buffer first, and only when the buffer is full (or the user invokes ‘force-output’ on the port) is the data actually written to the file descriptor. Likewise on input, bytes are read in from the file descriptor in blocks and placed in a buffer. Reading a character via ‘read-char’ first goes to the buffer, filling it as needed. Usually read buffering is more or less transparent, but write buffering can sometimes cause writes to be delayed unexpectedly, if you forget to call ‘force-output’. *Note Buffering::, for more on how to control port buffers. Note however that some procedures (e.g., ‘recv!’) will accept ports as arguments, but will actually operate directly on the file descriptor underlying the port. Any port buffering is ignored, including the buffer which implements ‘peek-char’ and ‘unread-char’. -- Scheme Procedure: port-revealed port -- C Function: scm_port_revealed (port) Return the revealed count for PORT. -- Scheme Procedure: set-port-revealed! port rcount -- C Function: scm_set_port_revealed_x (port, rcount) Sets the revealed count for a PORT to RCOUNT. The return value is unspecified. -- Scheme Procedure: fileno port -- C Function: scm_fileno (port) Return the integer file descriptor underlying PORT. Does not change its revealed count. -- Scheme Procedure: port->fdes port Returns the integer file descriptor underlying PORT. As a side effect the revealed count of PORT is incremented. -- Scheme Procedure: fdopen fdes modes -- C Function: scm_fdopen (fdes, modes) Return a new port based on the file descriptor FDES. Modes are given by the string MODES. The revealed count of the port is initialized to zero. The MODES string is the same as that accepted by ‘open-file’ (*note open-file: File Ports.). -- Scheme Procedure: fdes->ports fdes -- C Function: scm_fdes_to_ports (fdes) Return a list of existing ports which have FDES as an underlying file descriptor, without changing their revealed counts. -- Scheme Procedure: fdes->inport fdes Returns an existing input port which has FDES as its underlying file descriptor, if one exists, and increments its revealed count. Otherwise, returns a new input port with a revealed count of 1. -- Scheme Procedure: fdes->outport fdes Returns an existing output port which has FDES as its underlying file descriptor, if one exists, and increments its revealed count. Otherwise, returns a new output port with a revealed count of 1. -- Scheme Procedure: primitive-move->fdes port fdes -- C Function: scm_primitive_move_to_fdes (port, fdes) Moves the underlying file descriptor for PORT to the integer value FDES without changing the revealed count of PORT. Any other ports already using this descriptor will be automatically shifted to new descriptors and their revealed counts reset to zero. The return value is ‘#f’ if the file descriptor already had the required value or ‘#t’ if it was moved. -- Scheme Procedure: move->fdes port fdes Moves the underlying file descriptor for PORT to the integer value FDES and sets its revealed count to one. Any other ports already using this descriptor will be automatically shifted to new descriptors and their revealed counts reset to zero. The return value is unspecified. -- Scheme Procedure: release-port-handle port Decrements the revealed count for a port. -- Scheme Procedure: fsync port_or_fd -- C Function: scm_fsync (port_or_fd) Copies any unwritten data for the specified output file descriptor to disk. If PORT_OR_FD is a port, its buffer is flushed before the underlying file descriptor is fsync'd. The return value is unspecified. -- Scheme Procedure: open path flags [mode] -- C Function: scm_open (path, flags, mode) Open the file named by PATH for reading and/or writing. FLAGS is an integer specifying how the file should be opened. MODE is an integer specifying the permission bits of the file, if it needs to be created, before the umask (*note Processes::) is applied. The default is 666 (Unix itself has no default). FLAGS can be constructed by combining variables using ‘logior’. Basic flags are: -- Variable: O_RDONLY Open the file read-only. -- Variable: O_WRONLY Open the file write-only. -- Variable: O_RDWR Open the file read/write. -- Variable: O_APPEND Append to the file instead of truncating. -- Variable: O_CREAT Create the file if it does not already exist. *Note (libc)File Status Flags::, for additional flags. -- Scheme Procedure: openat dir path flags [mode] -- C Function: scm_openat (dir, path, flags, mode) Similar to ‘open’, but resolve the file name PATH relative to the directory referred to by the file port DIR instead. -- Scheme Procedure: open-fdes path flags [mode] -- C Function: scm_open_fdes (path, flags, mode) Similar to ‘open’ but return a file descriptor instead of a port. -- Scheme Procedure: open-fdes-at dir path flags [mode] -- C Function: scm_open_fdes_at (dir, path, flags, mode) Similar to ‘openat’, but return a file descriptor instead of a port. -- Scheme Procedure: close fd_or_port -- C Function: scm_close (fd_or_port) Similar to ‘close-port’ (*note close-port: Ports.), but also works on file descriptors. A side effect of closing a file descriptor is that any ports using that file descriptor are moved to a different file descriptor and have their revealed counts set to zero. -- Scheme Procedure: close-fdes fd -- C Function: scm_close_fdes (fd) A simple wrapper for the ‘close’ system call. Close file descriptor FD, which must be an integer. Unlike ‘close’, the file descriptor will be closed even if a port is using it. The return value is unspecified. -- Scheme Procedure: pipe [flags] -- C Function: scm_pipe () Return a newly created pipe: a pair of ports which are linked together on the local machine. The CAR is the input port and the CDR is the output port. Data written (and flushed) to the output port can be read from the input port. Pipes are commonly used for communication with a newly forked child process. The need to flush the output port can be avoided by making it unbuffered using ‘setvbuf’ (*note Buffering::). Optionally, on systems that support it such as GNU/Linux and GNU/Hurd, FLAGS can specify a bitwise-or of the following constants: ‘O_CLOEXEC’ Mark the returned file descriptors as close-on-exec; ‘O_DIRECT’ Create a pipe that performs input/output in "packet" mode--see ‘man 2 pipe’ for details; ‘O_NONBLOCK’ Set the ‘O_NONBLOCK’ status flag (non-blocking input and output) on the file descriptors. On systems that do _not_ support it, passing a non-zero FLAGS value triggers a ‘system-error’ exception. -- Variable: PIPE_BUF A write of up to ‘PIPE_BUF’ many bytes to a pipe is atomic, meaning when done it goes into the pipe instantaneously and as a contiguous block (*note Atomicity of Pipe I/O: (libc)Pipe Atomicity.). Note that the output port is likely to block if too much data has been written but not yet read from the input port. Typically the capacity is ‘PIPE_BUF’ bytes. The next group of procedures perform a ‘dup2’ system call, if NEWFD (an integer) is supplied, otherwise a ‘dup’. The file descriptor to be duplicated can be supplied as an integer or contained in a port. The type of value returned varies depending on which procedure is used. All procedures also have the side effect when performing ‘dup2’ that any ports using NEWFD are moved to a different file descriptor and have their revealed counts set to zero. -- Scheme Procedure: dup->fdes fd_or_port [fd] -- C Function: scm_dup_to_fdes (fd_or_port, fd) Return a new integer file descriptor referring to the open file designated by FD_OR_PORT, which must be either an open file port or a file descriptor. -- Scheme Procedure: dup->inport port/fd [newfd] Returns a new input port using the new file descriptor. -- Scheme Procedure: dup->outport port/fd [newfd] Returns a new output port using the new file descriptor. -- Scheme Procedure: dup port/fd [newfd] Returns a new port if PORT/FD is a port, with the same mode as the supplied port, otherwise returns an integer file descriptor. -- Scheme Procedure: dup->port port/fd mode [newfd] Returns a new port using the new file descriptor. MODE supplies a mode string for the port (*note open-file: File Ports.). -- Scheme Procedure: duplicate-port port modes Returns a new port which is opened on a duplicate of the file descriptor underlying PORT, with mode string MODES as for *note open-file: File Ports. The two ports will share a file position and file status flags. Unexpected behavior can result if both ports are subsequently used and the original and/or duplicate ports are buffered. The mode string can include ‘0’ to obtain an unbuffered duplicate port. This procedure is equivalent to ‘(dup->port PORT MODES)’. -- Scheme Procedure: redirect-port old_port new_port -- C Function: scm_redirect_port (old_port, new_port) This procedure takes two ports and duplicates the underlying file descriptor from OLD_PORT into NEW_PORT. The current file descriptor in NEW_PORT will be closed. After the redirection the two ports will share a file position and file status flags. The return value is unspecified. Unexpected behavior can result if both ports are subsequently used and the original and/or duplicate ports are buffered. This procedure does not have any side effects on other ports or revealed counts. -- Scheme Procedure: dup2 oldfd newfd -- C Function: scm_dup2 (oldfd, newfd) A simple wrapper for the ‘dup2’ system call. Copies the file descriptor OLDFD to descriptor number NEWFD, replacing the previous meaning of NEWFD. Both OLDFD and NEWFD must be integers. Unlike for ‘dup->fdes’ or ‘primitive-move->fdes’, no attempt is made to move away ports which are using NEWFD. The return value is unspecified. -- Scheme Procedure: port-for-each proc -- C Function: scm_port_for_each (SCM proc) -- C Function: scm_c_port_for_each (void (*proc)(void *, SCM), void *data) Apply PROC to each port in the Guile port table (FIXME: what is the Guile port table?) in turn. The return value is unspecified. More specifically, PROC is applied exactly once to every port that exists in the system at the time ‘port-for-each’ is invoked. Changes to the port table while ‘port-for-each’ is running have no effect as far as ‘port-for-each’ is concerned. The C function ‘scm_port_for_each’ takes a Scheme procedure encoded as a ‘SCM’ value, while ‘scm_c_port_for_each’ takes a pointer to a C function and passes along a arbitrary DATA cookie. -- Scheme Procedure: fcntl port/fd cmd [value] -- C Function: scm_fcntl (object, cmd, value) Apply CMD on PORT/FD, either a port or file descriptor. The VALUE argument is used by the ‘SET’ commands described below, it's an integer value. Values for CMD are: -- Variable: F_DUPFD Duplicate the file descriptor, the same as ‘dup->fdes’ above does. -- Variable: F_GETFD -- Variable: F_SETFD Get or set flags associated with the file descriptor. The only flag is the following, -- Variable: FD_CLOEXEC "Close on exec", meaning the file descriptor will be closed on an ‘exec’ call (a successful such call). For example to set that flag, (fcntl port F_SETFD FD_CLOEXEC) Or better, set it but leave any other possible future flags unchanged, (fcntl port F_SETFD (logior FD_CLOEXEC (fcntl port F_GETFD))) -- Variable: F_GETFL -- Variable: F_SETFL Get or set flags associated with the open file. These flags are ‘O_RDONLY’ etc described under ‘open’ above. A common use is to set ‘O_NONBLOCK’ on a network socket. The following sets that flag, and leaves other flags unchanged. (fcntl sock F_SETFL (logior O_NONBLOCK (fcntl sock F_GETFL))) -- Variable: F_GETOWN -- Variable: F_SETOWN Get or set the process ID of a socket's owner, for ‘SIGIO’ signals. -- Scheme Procedure: flock file operation -- C Function: scm_flock (file, operation) Apply or remove an advisory lock on an open file. OPERATION specifies the action to be done: -- Variable: LOCK_SH Shared lock. More than one process may hold a shared lock for a given file at a given time. -- Variable: LOCK_EX Exclusive lock. Only one process may hold an exclusive lock for a given file at a given time. -- Variable: LOCK_UN Unlock the file. -- Variable: LOCK_NB Don't block when locking. This is combined with one of the other operations using ‘logior’ (*note Bitwise Operations::). If ‘flock’ would block an ‘EWOULDBLOCK’ error is thrown (*note Conventions::). The return value is not specified. FILE may be an open file descriptor or an open file descriptor port. Note that ‘flock’ does not lock files across NFS. -- Scheme Procedure: select reads writes excepts [secs [usecs]] -- C Function: scm_select (reads, writes, excepts, secs, usecs) This procedure has a variety of uses: waiting for the ability to provide input, accept output, or the existence of exceptional conditions on a collection of ports or file descriptors, or waiting for a timeout to occur. When an error occurs, this procedure throws a ‘system-error’ exception (*note ‘system-error’: Conventions.). Note that ‘select’ may return early for other reasons, for example due to pending interrupts. *Note Asyncs::, for more on interrupts. READS, WRITES and EXCEPTS can be lists or vectors, with each member a port or a file descriptor. The value returned is a list of three corresponding lists or vectors containing only the members which meet the specified requirement. The ability of port buffers to provide input or accept output is taken into account. Ordering of the input lists or vectors is not preserved. The optional arguments SECS and USECS specify the timeout. Either SECS can be specified alone, as either an integer or a real number, or both SECS and USECS can be specified as integers, in which case USECS is an additional timeout expressed in microseconds. If SECS is omitted or is ‘#f’ then select will wait for as long as it takes for one of the other conditions to be satisfied. The scsh version of ‘select’ differs as follows: Only vectors are accepted for the first three arguments. The USECS argument is not supported. Multiple values are returned instead of a list. Duplicates in the input vectors appear only once in output. An additional ‘select!’ interface is provided. While it is sometimes necessary to operate at the level of file descriptors, this is an operation whose correctness can only be considered as part of a whole program. So for example while the effects of ‘(string-set! x 34 #\y)’ are limited to the bits of code that can access X, ‘(close-fdes 34)’ mutates the state of the entire process. In particular if another thread is using file descriptor 34 then their state might be corrupted; and another thread which opens a file might cause file descriptor 34 to be re-used, so that corruption could manifest itself in a strange way. However when working with file descriptors, it's common to want to associate information with the file descriptor, perhaps in a side table. To support this use case and to allow user code to remove an association when a file descriptor is closed, Guile offers “fdes finalizers”. As the name indicates, fdes finalizers are finalizers - they can run in response to garbage collection, and they can also run in response to explicit calls to ‘close-port’, ‘close-fdes’, or the like. As such they inherit many of the pitfalls of finalizers: they may be invoked from concurrent threads, or not at all. *Note Foreign Object Memory Management::, for more on finalizers. To use fdes finalizers, import their module; (use-modules (ice-9 fdes-finalizers)) -- Scheme Procedure: add-fdes-finalizer! fdes finalizer -- Scheme Procedure: remove-fdes-finalizer! fdes finalizer Add or remove a finalizer for FDES. A finalizer is a procedure that is called by Guile when a file descriptor is closed. The file descriptor being closed is passed as the one argument to the finalizer. If a finalizer has been added multiple times to a file descriptor, to remove it would require that number of calls to ‘remove-fdes-finalizer!’. The finalizers added to a file descriptor are called by Guile in an unspecified order, and their return values are ignored. 7.2.3 File System ----------------- These procedures allow querying and setting file system attributes (such as owner, permissions, sizes and types of files); deleting, copying, renaming and linking files; creating and removing directories and querying their contents; syncing the file system and creating special files. -- Scheme Procedure: access? path how -- C Function: scm_access (path, how) Test accessibility of a file under the real UID and GID of the calling process. The return is ‘#t’ if PATH exists and the permissions requested by HOW are all allowed, or ‘#f’ if not. HOW is an integer which is one of the following values, or a bitwise-OR (‘logior’) of multiple values. -- Variable: R_OK Test for read permission. -- Variable: W_OK Test for write permission. -- Variable: X_OK Test for execute permission. -- Variable: F_OK Test for existence of the file. This is implied by each of the other tests, so there's no need to combine it with them. It's important to note that ‘access?’ does not simply indicate what will happen on attempting to read or write a file. In normal circumstances it does, but in a set-UID or set-GID program it doesn't because ‘access?’ tests the real ID, whereas an open or execute attempt uses the effective ID. A program which will never run set-UID/GID can ignore the difference between real and effective IDs, but for maximum generality, especially in library functions, it's best not to use ‘access?’ to predict the result of an open or execute, instead simply attempt that and catch any exception. The main use for ‘access?’ is to let a set-UID/GID program determine what the invoking user would have been allowed to do, without the greater (or perhaps lesser) privileges afforded by the effective ID. For more on this, see *note (libc)Testing File Access::. -- Scheme Procedure: stat object [exception-on-error?] -- C Function: scm_stat (object, exception_on_error) Return an object containing various information about the file determined by OBJECT. OBJECT can be a string containing a file name or a port or integer file descriptor which is open on a file (in which case ‘fstat’ is used as the underlying system call). If the optional EXCEPTION_ON_ERROR argument is true, which is the default, an exception will be raised if the underlying system call returns an error, for example if the file is not found or is not readable. Otherwise, an error will cause ‘stat’ to return ‘#f’. The object returned by ‘stat’ can be passed as a single parameter to the following procedures, all of which return integers: -- Scheme Procedure: stat:dev st The device number containing the file. -- Scheme Procedure: stat:ino st The file serial number, which distinguishes this file from all other files on the same device. -- Scheme Procedure: stat:mode st The mode of the file. This is an integer which incorporates file type information and file permission bits. See also ‘stat:type’ and ‘stat:perms’ below. -- Scheme Procedure: stat:nlink st The number of hard links to the file. -- Scheme Procedure: stat:uid st The user ID of the file's owner. -- Scheme Procedure: stat:gid st The group ID of the file. -- Scheme Procedure: stat:rdev st Device ID; this entry is defined only for character or block special files. On some systems this field is not available at all, in which case ‘stat:rdev’ returns ‘#f’. -- Scheme Procedure: stat:size st The size of a regular file in bytes. -- Scheme Procedure: stat:atime st The last access time for the file, in seconds. -- Scheme Procedure: stat:mtime st The last modification time for the file, in seconds. -- Scheme Procedure: stat:ctime st The last modification time for the attributes of the file, in seconds. -- Scheme Procedure: stat:atimensec st -- Scheme Procedure: stat:mtimensec st -- Scheme Procedure: stat:ctimensec st The fractional part of a file's access, modification, or attribute modification time, in nanoseconds. Nanosecond timestamps are only available on some operating systems and file systems. If Guile cannot retrieve nanosecond-level timestamps for a file, these fields will be set to 0. -- Scheme Procedure: stat:blksize st The optimal block size for reading or writing the file, in bytes. On some systems this field is not available, in which case ‘stat:blksize’ returns a sensible suggested block size. -- Scheme Procedure: stat:blocks st The amount of disk space that the file occupies measured in units of 512 byte blocks. On some systems this field is not available, in which case ‘stat:blocks’ returns ‘#f’. In addition, the following procedures return the information from ‘stat:mode’ in a more convenient form: -- Scheme Procedure: stat:type st A symbol representing the type of file. Possible values are ‘regular’, ‘directory’, ‘symlink’, ‘block-special’, ‘char-special’, ‘fifo’, ‘socket’, and ‘unknown’. -- Scheme Procedure: stat:perms st An integer representing the access permission bits. -- Scheme Procedure: lstat path -- C Function: scm_lstat (path) Similar to ‘stat’, but does not follow symbolic links, i.e., it will return information about a symbolic link itself, not the file it points to. PATH must be a string. -- Scheme Procedure: statat dir filename [flags] -- C Function: scm_statat dir filename flags Like ‘stat’, but resolve FILENAME relative to the directory referred to by the file port DIR instead. The optional argument FLAGS argument can be ‘AT_SYMLINK_NOFOLLOW’, in which case FILENAME will not be dereferenced even if it is a symbolic link. -- Scheme Procedure: readlink path -- C Function: scm_readlink (path) Return the value of the symbolic link named by PATH (a string, or a port if supported by the system), i.e., the file that the link points to. To read a symbolic link represented by a port, the symbolic link must have been opened with the ‘O_NOFOLLOW’ and ‘O_PATH’ flags. ‘(provided? 'readlink-port)’ reports whether ports are supported. -- Scheme Procedure: chown object owner group -- C Function: scm_chown (object, owner, group) Change the ownership and group of the file referred to by OBJECT to the integer values OWNER and GROUP. OBJECT can be a string containing a file name or, if the platform supports ‘fchown’ (*note (libc)File Owner::), a port or integer file descriptor which is open on the file. The return value is unspecified. If OBJECT is a symbolic link, either the ownership of the link or the ownership of the referenced file will be changed depending on the operating system (lchown is unsupported at present). If OWNER or GROUP is specified as ‘-1’, then that ID is not changed. -- Scheme Procedure: chownat dir name owner group [flags] -- C Function: scm_chownat (dir, name, owner, group, flags) Like ‘chown’, but modify the owner and/or group of the file named NAME in the directory referred to by the file port DIR instead. The optional argument FLAGS is a bitmask. If ‘AT_SYMLINK_NOFOLLOW’ is present, then NAME will not be dereferenced if it is a symbolic link. -- Scheme Procedure: chmod object mode -- C Function: scm_chmod (object, mode) Changes the permissions of the file referred to by OBJECT. OBJECT can be a string containing a file name or a port or integer file descriptor which is open on a file (in which case ‘fchmod’ is used as the underlying system call). MODE specifies the new permissions as a decimal number, e.g., ‘(chmod "foo" #o755)’. The return value is unspecified. -- Scheme Procedure: utime object [actime [modtime [actimens [modtimens [flags]]]]] -- C Function: scm_utime (object, actime, modtime, actimens, modtimens, flags) ‘utime’ sets the access and modification times for the file named by OBJECT. If ACTIME or MODTIME is not supplied, then the current time is used. ACTIME and MODTIME must be integer time values as returned by the ‘current-time’ procedure. OBJECT must be a file name or a port (if supported by the system). The optional ACTIMENS and MODTIMENS are nanoseconds to add ACTIME and MODTIME. Nanosecond precision is only supported on some combinations of file systems and operating systems. (utime "foo" (- (current-time) 3600)) will set the access time to one hour in the past and the modification time to the current time. Last, FLAGS may be either ‘0’ or the ‘AT_SYMLINK_NOFOLLOW’ constant, to set the time of OBJECT even if it is a symbolic link. On GNU/Linux systems, at least when using the Linux kernel 5.10.46, if OBJECT is a port, it may not be a symbolic link, even if ‘AT_SYMLINK_NOFOLLOW’ is set. This is either a bug in Linux or Guile's wrappers. The exact cause is unclear. -- Scheme Procedure: delete-file str -- C Function: scm_delete_file (str) Deletes (or "unlinks") the file whose path is specified by STR. -- Scheme Procedure: delete-file-at dir str [flags] -- C Function: scm_delete_file_at (dir, str, flags) Like ‘unlink’, but resolve STR relative to the directory referred to by the file port DIR instead. The optional FLAGS argument can be ‘AT_REMOVEDIR’, in which case ‘delete-file-at’ will act like ‘rmdir’ instead of ‘delete-file’. Why doesn't POSIX have a ‘rmdirat’ function for this instead? No idea! -- Scheme Procedure: copy-file OLDFILE NEWFILE [#:copy-on-write='auto] -- C Function: scm_copy_file (oldfile, newfile) Copy the file specified by OLDFILE to NEWFILE. The return value is unspecified. ‘#:copy-on-write’ keyword argument determines whether copy-on-write copy should be attempted and the behavior in case of failure. Possible values are ‘'always’ (attempt the copy-on-write, return error if it fails), ‘'auto’ (attempt the copy-on-write, fallback to regular copy if it fails) and ‘'never’ (perform the regular copy). -- Scheme Procedure: sendfile out in count [offset] -- C Function: scm_sendfile (out, in, count, offset) Send COUNT bytes from IN to OUT, both of which must be either open file ports or file descriptors. When OFFSET is omitted, start reading from IN's current position; otherwise, start reading at OFFSET. Return the number of bytes actually sent. When IN is a port, it is often preferable to specify OFFSET, because IN's offset as a port may be different from the offset of its underlying file descriptor. On systems that support it, such as GNU/Linux, this procedure uses the ‘sendfile’ libc function, which usually corresponds to a system call. This is faster than doing a series of ‘read’ and ‘write’ system calls. A typical application is to send a file over a socket. In some cases, the ‘sendfile’ libc function may return ‘EINVAL’ or ‘ENOSYS’. In that case, Guile's ‘sendfile’ procedure automatically falls back to doing a series of ‘read’ and ‘write’ calls. In other cases, the libc function may send fewer bytes than COUNT--for instance because OUT is a slow or limited device, such as a pipe. When that happens, Guile's ‘sendfile’ automatically retries until exactly COUNT bytes were sent or an error occurs. -- Scheme Procedure: rename-file oldname newname -- C Function: scm_rename (oldname, newname) Renames the file specified by OLDNAME to NEWNAME. The return value is unspecified. -- Scheme Procedure: rename-file-at olddir oldname newdir newname -- C Function: scm_renameat (olddir, oldname, newdir, newname) Like ‘rename-file’, but when OLDDIR or NEWDIR is true, resolve OLDNAME or NEWNAME relative to the directory specified by the file port OLDDIR or NEWDIR instead of the current working directory. -- Scheme Procedure: link oldpath newpath -- C Function: scm_link (oldpath, newpath) Creates a new name NEWPATH in the file system for the file named by OLDPATH. If OLDPATH is a symbolic link, the link may or may not be followed depending on the system. -- Scheme Procedure: symlink oldpath newpath -- C Function: scm_symlink (oldpath, newpath) Create a symbolic link named NEWPATH with the value (i.e., pointing to) OLDPATH. The return value is unspecified. -- Scheme Procedure: symlinkat dir oldpath newpath -- C Function: scm_symlinkat (dir, oldpath, newpath) Like ‘symlink’, but resolve NEWPATH relative to the directory referred to by the file port DIR. -- Scheme Procedure: mkdir path [mode] -- C Function: scm_mkdir (path, mode) Create a new directory named by PATH. If MODE is omitted then the permissions of the directory are set to ‘#o777’ masked with the current umask (*note ‘umask’: Processes.). Otherwise they are set to the value specified with MODE masked with the current umask. The return value is unspecified. -- Scheme Procedure: mkdirat dir path [mode] -- C Function: scm_mkdirat (dir, path, mode) Like ‘mkdir’, but resolve PATH relative to the directory referred to by the file port DIR instead. -- Scheme Procedure: rmdir path -- C Function: scm_rmdir (path) Remove the existing directory named by PATH. The directory must be empty for this to succeed. The return value is unspecified. -- Scheme Procedure: opendir dirname -- C Function: scm_opendir (dirname) Open the directory specified by DIRNAME and return a directory stream. Before using this and the procedures below, make sure to see the higher-level procedures for directory traversal that are available (*note File Tree Walk::). -- Scheme Procedure: directory-stream? object -- C Function: scm_directory_stream_p (object) Return a boolean indicating whether OBJECT is a directory stream as returned by ‘opendir’. -- Scheme Procedure: readdir stream -- C Function: scm_readdir (stream) Return (as a string) the next directory entry from the directory stream STREAM. If there is no remaining entry to be read then the end of file object is returned. -- Scheme Procedure: rewinddir stream -- C Function: scm_rewinddir (stream) Reset the directory port STREAM so that the next call to ‘readdir’ will return the first directory entry. -- Scheme Procedure: closedir stream -- C Function: scm_closedir (stream) Close the directory stream STREAM. The return value is unspecified. Here is an example showing how to display all the entries in a directory: (define dir (opendir "/usr/lib")) (do ((entry (readdir dir) (readdir dir))) ((eof-object? entry)) (display entry)(newline)) (closedir dir) -- Scheme Procedure: sync -- C Function: scm_sync () Flush the operating system disk buffers. The return value is unspecified. -- Scheme Procedure: mknod path type perms dev -- C Function: scm_mknod (path, type, perms, dev) Creates a new special file, such as a file corresponding to a device. PATH specifies the name of the file. TYPE should be one of the following symbols: ‘regular’, ‘directory’, ‘symlink’, ‘block-special’, ‘char-special’, ‘fifo’, or ‘socket’. PERMS (an integer) specifies the file permissions. DEV (an integer) specifies which device the special file refers to. Its exact interpretation depends on the kind of special file being created. E.g., (mknod "/dev/fd0" 'block-special #o660 (+ (* 2 256) 2)) The return value is unspecified. -- Scheme Procedure: tmpnam -- C Function: scm_tmpnam () Return an auto-generated name of a temporary file, a file which doesn't already exist. The name includes a path, it's usually in ‘/tmp’ but that's system dependent. Care must be taken when using ‘tmpnam’. In between choosing the name and creating the file another program might use that name, or an attacker might even make it a symlink pointing at something important and causing you to overwrite that. The safe way is to create the file using ‘open’ with ‘O_EXCL’ to avoid any overwriting. A loop can try again with another name if the file exists (error ‘EEXIST’). ‘mkstemp’ below does that. -- Scheme Procedure: mkstemp tmpl [mode] Create a new unique file in the file system and return a new buffered port open for reading and writing to the file. TMPL is a string specifying where the file should be created: it must end with ‘XXXXXX’. The name of the newly created file will be the same as TMPL, but with those ‘X’s changed, and can be determined by calling ‘port-filename’ on the returned port. Note that the newly created file is not deleted automatically by Guile; probably the caller should arrange to call ‘delete-file’ when the file is no longer needed. POSIX doesn't specify the permissions mode of the file. On GNU and most systems it's ‘#o600’; an application can use ‘chmod’ to relax that if desired. For example ‘#o666’ less ‘umask’, which is usual for ordinary file creation, (let ((port (mkstemp "/tmp/myfile-XXXXXX"))) (chmod port (logand #o666 (lognot (umask)))) ...) The optional MODE argument specifies a mode with which to open the new file, as a string in the same format that ‘open-file’ takes. It defaults to ‘"w+"’. -- Scheme Procedure: tmpfile -- C Function: scm_tmpfile () Return an input/output port to a unique temporary file named using the path prefix ‘P_tmpdir’ defined in ‘stdio.h’. The file is automatically deleted when the port is closed or the program terminates. -- Scheme Procedure: mkdtemp tmpl -- C Function: scm_mkdtemp (tmpl) Create a new directory named in accordance with the template string TMPL. TMPL is a string specifying the directory's name. The last six characters of TMPL must be ‘XXXXXX’. Upon successful execution, the name of the new directory is returned which has the same form as TMPL but with the ‘XXXXXX’ characters modified to ensure the directory name is unique. The permissions of the directory created are OS dependent, but, are usually ‘#o700’. An error may be thrown if the template has the wrong format or if the directory cannot be created. -- Scheme Procedure: dirname filename -- C Function: scm_dirname (filename) Return the directory name component of the file name FILENAME. If FILENAME does not contain a directory component, ‘.’ is returned. -- Scheme Procedure: basename filename [suffix] -- C Function: scm_basename (filename, suffix) Return the base name of the file name FILENAME. The base name is the file name without any directory components. If SUFFIX is provided, and is equal to the end of BASENAME, it is removed also. (basename "/tmp/test.xml" ".xml") ⇒ "test" -- Scheme Procedure: canonicalize-path path -- C Function: scm_canonicalize_path (path) Return the canonical (absolute) path of PATH. A canonical path has no ‘.’ or ‘..’ components, nor any repeated path separators (‘/’) nor symlinks. Raises an error if any component of PATH does not exist. (canonicalize-path "test.xml") ⇒ "/tmp/test.xml" -- Scheme Procedure: file-exists? filename Return ‘#t’ if the file named FILENAME exists, ‘#f’ if not. Many operating systems, such as GNU, use ‘/’ (forward slash) to separate the components of a file name; any file name starting with ‘/’ is considered an “absolute file name”. These conventions are specified by the POSIX Base Definitions, which refer to conforming file names as "pathnames". Some operating systems use a different convention; in particular, Windows uses ‘\’ (backslash) as the file name separator, and also has the notion of “volume names” like ‘C:\’ for absolute file names. The following procedures and variables provide support for portable file name manipulations. -- Scheme Procedure: system-file-name-convention Return either ‘posix’ or ‘windows’, depending on what kind of system this Guile is running on. -- Scheme Procedure: file-name-separator? c Return true if character C is a file name separator on the host platform. -- Scheme Procedure: absolute-file-name? file-name Return true if FILE-NAME denotes an absolute file name on the host platform. -- Scheme Variable: file-name-separator-string The preferred file name separator. Note that on MinGW builds for Windows, both ‘/’ and ‘\’ are valid separators. Thus, programs should not assume that ‘file-name-separator-string’ is the _only_ file name separator--e.g., when extracting the components of a file name. 7.2.4 User Information ---------------------- The facilities in this section provide an interface to the user and group database. They should be used with care since they are not reentrant. The following functions accept an object representing user information and return a selected component: -- Scheme Procedure: passwd:name pw The name of the userid. -- Scheme Procedure: passwd:passwd pw The encrypted passwd. -- Scheme Procedure: passwd:uid pw The user id number. -- Scheme Procedure: passwd:gid pw The group id number. -- Scheme Procedure: passwd:gecos pw The full name. -- Scheme Procedure: passwd:dir pw The home directory. -- Scheme Procedure: passwd:shell pw The login shell. -- Scheme Procedure: getpwuid uid Look up an integer userid in the user database. -- Scheme Procedure: getpwnam name Look up a user name string in the user database. -- Scheme Procedure: setpwent Initializes a stream used by ‘getpwent’ to read from the user database. The next use of ‘getpwent’ will return the first entry. The return value is unspecified. -- Scheme Procedure: getpwent Read the next entry in the user database stream. The return is a passwd user object as above, or ‘#f’ when no more entries. -- Scheme Procedure: endpwent Closes the stream used by ‘getpwent’. The return value is unspecified. -- Scheme Procedure: setpw [arg] -- C Function: scm_setpwent (arg) If called with a true argument, initialize or reset the password data stream. Otherwise, close the stream. The ‘setpwent’ and ‘endpwent’ procedures are implemented on top of this. -- Scheme Procedure: getpw [user] -- C Function: scm_getpwuid (user) Look up an entry in the user database. USER can be an integer, a string, or omitted, giving the behavior of getpwuid, getpwnam or getpwent respectively. The following functions accept an object representing group information and return a selected component: -- Scheme Procedure: group:name gr The group name. -- Scheme Procedure: group:passwd gr The encrypted group password. -- Scheme Procedure: group:gid gr The group id number. -- Scheme Procedure: group:mem gr A list of userids which have this group as a supplementary group. -- Scheme Procedure: getgrgid gid Look up an integer group id in the group database. -- Scheme Procedure: getgrnam name Look up a group name in the group database. -- Scheme Procedure: setgrent Initializes a stream used by ‘getgrent’ to read from the group database. The next use of ‘getgrent’ will return the first entry. The return value is unspecified. -- Scheme Procedure: getgrent Return the next entry in the group database, using the stream set by ‘setgrent’. -- Scheme Procedure: endgrent Closes the stream used by ‘getgrent’. The return value is unspecified. -- Scheme Procedure: setgr [arg] -- C Function: scm_setgrent (arg) If called with a true argument, initialize or reset the group data stream. Otherwise, close the stream. The ‘setgrent’ and ‘endgrent’ procedures are implemented on top of this. -- Scheme Procedure: getgr [group] -- C Function: scm_getgrgid (group) Look up an entry in the group database. GROUP can be an integer, a string, or omitted, giving the behavior of getgrgid, getgrnam or getgrent respectively. In addition to the accessor procedures for the user database, the following shortcut procedure is also available. -- Scheme Procedure: getlogin -- C Function: scm_getlogin () Return a string containing the name of the user logged in on the controlling terminal of the process, or ‘#f’ if this information cannot be obtained. 7.2.5 Time ---------- -- Scheme Procedure: current-time -- C Function: scm_current_time () Return the number of seconds since 1970-01-01 00:00:00 UTC, excluding leap seconds. -- Scheme Procedure: gettimeofday -- C Function: scm_gettimeofday () Return a pair containing the number of seconds and microseconds since 1970-01-01 00:00:00 UTC, excluding leap seconds. Note: whether true microsecond resolution is available depends on the operating system. The following procedures either accept an object representing a broken down time and return a selected component, or accept an object representing a broken down time and a value and set the component to the value. The numbers in parentheses give the usual range. -- Scheme Procedure: tm:sec tm -- Scheme Procedure: set-tm:sec tm val Seconds (0-59). -- Scheme Procedure: tm:min tm -- Scheme Procedure: set-tm:min tm val Minutes (0-59). -- Scheme Procedure: tm:hour tm -- Scheme Procedure: set-tm:hour tm val Hours (0-23). -- Scheme Procedure: tm:mday tm -- Scheme Procedure: set-tm:mday tm val Day of the month (1-31). -- Scheme Procedure: tm:mon tm -- Scheme Procedure: set-tm:mon tm val Month (0-11). -- Scheme Procedure: tm:year tm -- Scheme Procedure: set-tm:year tm val Year (70-), the year minus 1900. -- Scheme Procedure: tm:wday tm -- Scheme Procedure: set-tm:wday tm val Day of the week (0-6) with Sunday represented as 0. -- Scheme Procedure: tm:yday tm -- Scheme Procedure: set-tm:yday tm val Day of the year (0-364, 365 in leap years). -- Scheme Procedure: tm:isdst tm -- Scheme Procedure: set-tm:isdst tm val Daylight saving indicator (0 for "no", greater than 0 for "yes", less than 0 for "unknown"). -- Scheme Procedure: tm:gmtoff tm -- Scheme Procedure: set-tm:gmtoff tm val Time zone offset in seconds west of UTC (-46800 to 43200). For example on East coast USA (zone ‘EST+5’) this would be 18000 (ie. 5*60*60) in winter, or 14400 (ie. 4*60*60) during daylight savings. Note ‘tm:gmtoff’ is not the same as ‘tm_gmtoff’ in the C ‘tm’ structure. ‘tm_gmtoff’ is seconds east and hence the negative of the value here. -- Scheme Procedure: tm:zone tm -- Scheme Procedure: set-tm:zone tm val Time zone label (a string), not necessarily unique. -- Scheme Procedure: localtime time [zone] -- C Function: scm_localtime (time, zone) Return an object representing the broken down components of TIME, an integer like the one returned by ‘current-time’. The time zone for the calculation is optionally specified by ZONE (a string), otherwise the ‘TZ’ environment variable or the system default is used. -- Scheme Procedure: gmtime time -- C Function: scm_gmtime (time) Return an object representing the broken down components of TIME, an integer like the one returned by ‘current-time’. The values are calculated for UTC. -- Scheme Procedure: mktime sbd-time [zone] -- C Function: scm_mktime (sbd_time, zone) For a broken down time object SBD-TIME, return a pair the ‘car’ of which is an integer time like ‘current-time’, and the ‘cdr’ of which is a new broken down time with normalized fields. ZONE is a timezone string, or the default is the ‘TZ’ environment variable or the system default (*note Specifying the Time Zone with ‘TZ’: (libc)TZ Variable.). SBD-TIME is taken to be in that ZONE. The following fields of SBD-TIME are used: ‘tm:year’, ‘tm:mon’, ‘tm:mday’, ‘tm:hour’, ‘tm:min’, ‘tm:sec’, ‘tm:isdst’. The values can be outside their usual ranges. For example ‘tm:hour’ normally goes up to 23, but a value say 33 would mean 9 the following day. ‘tm:isdst’ in SBD-TIME says whether the time given is with daylight savings or not. This is ignored if ZONE doesn't have any daylight savings adjustment amount. The broken down time in the return normalizes the values of SBD-TIME by bringing them into their usual ranges, and using the actual daylight savings rule for that time in ZONE (which may differ from what SBD-TIME had). The easiest way to think of this is that SBD-TIME plus ZONE converts to the integer UTC time, then a ‘localtime’ is applied to get the normal presentation of that time, in ZONE. -- Scheme Procedure: tzset -- C Function: scm_tzset () Initialize the timezone from the ‘TZ’ environment variable or the system default. It's not usually necessary to call this procedure since it's done automatically by other procedures that depend on the timezone. -- Scheme Procedure: strftime format tm -- C Function: scm_strftime (format, tm) Return a string which is broken-down time structure TM formatted according to the given FORMAT string. FORMAT contains field specifications introduced by a ‘%’ character. See *note (libc)Formatting Calendar Time::, or ‘man 3 strftime’, for the available formatting. (strftime "%c" (localtime (current-time))) ⇒ "Mon Mar 11 20:17:43 2002" If ‘setlocale’ has been called (*note Locales::), month and day names are from the current locale and in the locale character set. -- Scheme Procedure: strptime format string -- C Function: scm_strptime (format, string) Performs the reverse action to ‘strftime’, parsing STRING according to the specification supplied in FORMAT. The interpretation of month and day names is dependent on the current locale. The value returned is a pair. The CAR has an object with time components in the form returned by ‘localtime’ or ‘gmtime’, but the time zone components are not usefully set. The CDR reports the number of characters from STRING which were used for the conversion. -- Variable: internal-time-units-per-second The value of this variable is the number of time units per second reported by the following procedures. -- Scheme Procedure: times -- C Function: scm_times () Return an object with information about real and processor time. The following procedures accept such an object as an argument and return a selected component: -- Scheme Procedure: tms:clock tms The current real time, expressed as time units relative to an arbitrary base. -- Scheme Procedure: tms:utime tms The CPU time units used by the calling process. -- Scheme Procedure: tms:stime tms The CPU time units used by the system on behalf of the calling process. -- Scheme Procedure: tms:cutime tms The CPU time units used by terminated child processes of the calling process, whose status has been collected (e.g., using ‘waitpid’). -- Scheme Procedure: tms:cstime tms Similarly, the CPU times units used by the system on behalf of terminated child processes. -- Scheme Procedure: get-internal-real-time -- C Function: scm_get_internal_real_time () Return the number of time units since the interpreter was started. -- Scheme Procedure: get-internal-run-time -- C Function: scm_get_internal_run_time () Return the number of time units of processor time used by the interpreter. Both _system_ and _user_ time are included but subprocesses are not. 7.2.6 Runtime Environment ------------------------- -- Scheme Procedure: program-arguments -- Scheme Procedure: command-line -- Scheme Procedure: set-program-arguments -- C Function: scm_program_arguments () -- C Function: scm_set_program_arguments_scm (lst) Get the command line arguments passed to Guile, or set new arguments. The arguments are a list of strings, the first of which is the invoked program name. This is just "guile" (or the executable path) when run interactively, or it's the script name when running a script with ‘-s’ (*note Invoking Guile::). guile -L /my/extra/dir -s foo.scm abc def (program-arguments) ⇒ ("foo.scm" "abc" "def") ‘set-program-arguments’ allows a library module or similar to modify the arguments, for example to strip options it recognises, leaving the rest for the mainline. The argument list is held in a fluid, which means it's separate for each thread. Neither the list nor the strings within it are copied at any point and normally should not be mutated. The two names ‘program-arguments’ and ‘command-line’ are an historical accident, they both do exactly the same thing. The name ‘scm_set_program_arguments_scm’ has an extra ‘_scm’ on the end to avoid clashing with the C function below. -- C Function: void scm_set_program_arguments (int argc, char **argv, char *first) Set the list of command line arguments for ‘program-arguments’ and ‘command-line’ above. ARGV is an array of null-terminated strings, as in a C ‘main’ function. ARGC is the number of strings in ARGV, or if it's negative then a ‘NULL’ in ARGV marks its end. FIRST is an extra string put at the start of the arguments, or ‘NULL’ for no such extra. This is a convenient way to pass the program name after advancing ARGV to strip option arguments. Eg. { char *progname = argv[0]; for (argv++; argv[0] != NULL && argv[0][0] == '-'; argv++) { /* munch option ... */ } /* remaining args for scheme level use */ scm_set_program_arguments (-1, argv, progname); } This sort of thing is often done at startup under ‘scm_boot_guile’ with options handled at the C level removed. The given strings are all copied, so the C data is not accessed again once ‘scm_set_program_arguments’ returns. -- Scheme Procedure: getenv name -- C Function: scm_getenv (name) Looks up the string NAME in the current environment. The return value is ‘#f’ unless a string of the form ‘NAME=VALUE’ is found, in which case the string ‘VALUE’ is returned. -- Scheme Procedure: setenv name value Modifies the environment of the current process, which is also the default environment inherited by child processes. If VALUE is ‘#f’, then NAME is removed from the environment. Otherwise, the string NAME=VALUE is added to the environment, replacing any existing string with name matching NAME. The return value is unspecified. -- Scheme Procedure: unsetenv name Remove variable NAME from the environment. The name can not contain a ‘=’ character. -- Scheme Procedure: environ [env] -- C Function: scm_environ (env) If ENV is omitted, return the current environment (in the Unix sense) as a list of strings. Otherwise set the current environment, which is also the default environment for child processes, to the supplied list of strings. Each member of ENV should be of the form NAME=VALUE and values of NAME should not be duplicated. If ENV is supplied then the return value is unspecified. -- Scheme Procedure: putenv str -- C Function: scm_putenv (str) Modifies the environment of the current process, which is also the default environment inherited by child processes. If STR is of the form ‘NAME=VALUE’ then it will be written directly into the environment, replacing any existing environment string with name matching ‘NAME’. If STR does not contain an equal sign, then any existing string with name matching STR will be removed. The return value is unspecified. 7.2.7 Processes --------------- -- Scheme Procedure: chdir str -- C Function: scm_chdir (str) Change the current working directory to STR. STR can be a string containing a file name, or a port if supported by the system. ‘(provided? 'chdir-port)’ reports whether ports are supported. The return value is unspecified. -- Scheme Procedure: getcwd -- C Function: scm_getcwd () Return the name of the current working directory. -- Scheme Procedure: umask [mode] -- C Function: scm_umask (mode) If MODE is omitted, returns a decimal number representing the current file creation mask. Otherwise the file creation mask is set to MODE and the previous value is returned. *Note Assigning File Permissions: (libc)Setting Permissions, for more on how to use umasks. E.g., ‘(umask #o022)’ sets the mask to octal 22/decimal 18. -- Scheme Procedure: chroot path -- C Function: scm_chroot (path) Change the root directory to that specified in PATH. This directory will be used for path names beginning with ‘/’. The root directory is inherited by all children of the current process. Only the superuser may change the root directory. -- Scheme Procedure: getpid -- C Function: scm_getpid () Return an integer representing the current process ID. -- Scheme Procedure: getgroups -- C Function: scm_getgroups () Return a vector of integers representing the current supplementary group IDs. -- Scheme Procedure: getppid -- C Function: scm_getppid () Return an integer representing the process ID of the parent process. -- Scheme Procedure: getuid -- C Function: scm_getuid () Return an integer representing the current real user ID. -- Scheme Procedure: getgid -- C Function: scm_getgid () Return an integer representing the current real group ID. -- Scheme Procedure: geteuid -- C Function: scm_geteuid () Return an integer representing the current effective user ID. If the system does not support effective IDs, then the real ID is returned. ‘(provided? 'EIDs)’ reports whether the system supports effective IDs. -- Scheme Procedure: getegid -- C Function: scm_getegid () Return an integer representing the current effective group ID. If the system does not support effective IDs, then the real ID is returned. ‘(provided? 'EIDs)’ reports whether the system supports effective IDs. -- Scheme Procedure: setgroups vec -- C Function: scm_setgroups (vec) Set the current set of supplementary group IDs to the integers in the given vector VEC. The return value is unspecified. Generally only the superuser can set the process group IDs (*note Setting the Group IDs: (libc)Setting Groups.). -- Scheme Procedure: setuid id -- C Function: scm_setuid (id) Sets both the real and effective user IDs to the integer ID, provided the process has appropriate privileges. The return value is unspecified. -- Scheme Procedure: setgid id -- C Function: scm_setgid (id) Sets both the real and effective group IDs to the integer ID, provided the process has appropriate privileges. The return value is unspecified. -- Scheme Procedure: seteuid id -- C Function: scm_seteuid (id) Sets the effective user ID to the integer ID, provided the process has appropriate privileges. If effective IDs are not supported, the real ID is set instead--‘(provided? 'EIDs)’ reports whether the system supports effective IDs. The return value is unspecified. -- Scheme Procedure: setegid id -- C Function: scm_setegid (id) Sets the effective group ID to the integer ID, provided the process has appropriate privileges. If effective IDs are not supported, the real ID is set instead--‘(provided? 'EIDs)’ reports whether the system supports effective IDs. The return value is unspecified. -- Scheme Procedure: getpgrp -- C Function: scm_getpgrp () Return an integer representing the current process group ID. This is the POSIX definition, not BSD. -- Scheme Procedure: setpgid pid pgid -- C Function: scm_setpgid (pid, pgid) Move the process PID into the process group PGID. PID or PGID must be integers: they can be zero to indicate the ID of the current process. Fails on systems that do not support job control. The return value is unspecified. -- Scheme Procedure: setsid -- C Function: scm_setsid () Creates a new session. The current process becomes the session leader and is put in a new process group. The process will be detached from its controlling terminal if it has one. The return value is an integer representing the new process group ID. -- Scheme Procedure: getsid pid -- C Function: scm_getsid (pid) Returns the session ID of process PID. (The session ID of a process is the process group ID of its session leader.) -- Scheme Procedure: waitpid pid [options] -- C Function: scm_waitpid (pid, options) This procedure collects status information from a child process which has terminated or (optionally) stopped. Normally it will suspend the calling process until this can be done. If more than one child process is eligible then one will be chosen by the operating system. The value of PID determines the behavior: PID greater than 0 Request status information from the specified child process. PID equal to -1 or ‘WAIT_ANY’ Request status information for any child process. PID equal to 0 or ‘WAIT_MYPGRP’ Request status information for any child process in the current process group. PID less than -1 Request status information for any child process whose process group ID is −PID. The OPTIONS argument, if supplied, should be the bitwise OR of the values of zero or more of the following variables: -- Variable: WNOHANG Return immediately even if there are no child processes to be collected. -- Variable: WUNTRACED Report status information for stopped processes as well as terminated processes. The return value is a pair containing: 1. The process ID of the child process, or 0 if ‘WNOHANG’ was specified and no process was collected. 2. The integer status value (*note (libc)Process Completion Status::). The following three functions can be used to decode the integer status value returned by ‘waitpid’. -- Scheme Procedure: status:exit-val status -- C Function: scm_status_exit_val (status) Return the exit status value, as would be set if a process ended normally through a call to ‘exit’ or ‘_exit’, if any, otherwise ‘#f’. -- Scheme Procedure: status:term-sig status -- C Function: scm_status_term_sig (status) Return the signal number which terminated the process, if any, otherwise ‘#f’. -- Scheme Procedure: status:stop-sig status -- C Function: scm_status_stop_sig (status) Return the signal number which stopped the process, if any, otherwise ‘#f’. -- Scheme Procedure: system [cmd] -- C Function: scm_system (cmd) Execute CMD using the operating system's "command processor". Under Unix this is usually the default shell ‘sh’. The value returned is CMD's exit status as returned by ‘waitpid’, which can be interpreted using the functions above. If ‘system’ is called without arguments, return a boolean indicating whether the command processor is available. -- Scheme Procedure: system* arg1 arg2 ... -- C Function: scm_system_star (args) Execute the command indicated by ARG1 ARG2 .... The first element must be a string indicating the command to be executed, and the remaining items must be strings representing each of the arguments to that command. This function returns the exit status of the command as provided by ‘waitpid’. This value can be handled with ‘status:exit-val’ and the related functions. ‘system*’ is similar to ‘system’, but accepts only one string per-argument, and performs no shell interpretation. The command is executed using fork and execlp. Accordingly this function may be safer than ‘system’ in situations where shell interpretation is not required. Example: (system* "echo" "foo" "bar") -- Scheme Procedure: quit [status] -- Scheme Procedure: exit [status] Terminate the current process with proper unwinding of the Scheme stack. The exit status zero if STATUS is not supplied. If STATUS is supplied, and it is an integer, that integer is used as the exit status. If STATUS is ‘#t’ or ‘#f’, the exit status is EXIT_SUCCESS or EXIT_FAILURE, respectively. The procedure ‘exit’ is an alias of ‘quit’. They have the same functionality. -- Scheme Variable: EXIT_SUCCESS -- Scheme Variable: EXIT_FAILURE These constants represent the standard exit codes for success (zero) or failure (one.) -- Scheme Procedure: primitive-exit [status] -- Scheme Procedure: primitive-_exit [status] -- C Function: scm_primitive_exit (status) -- C Function: scm_primitive__exit (status) Terminate the current process without unwinding the Scheme stack. The exit status is STATUS if supplied, otherwise zero. ‘primitive-exit’ uses the C ‘exit’ function and hence runs usual C level cleanups (flush output streams, call ‘atexit’ functions, etc, see *note (libc)Normal Termination::)). ‘primitive-_exit’ is the ‘_exit’ system call (*note (libc)Termination Internals::). This terminates the program immediately, with neither Scheme-level nor C-level cleanups. The typical use for ‘primitive-_exit’ is from a child process created with ‘primitive-fork’. For example in a Gdk program the child process inherits the X server connection and a C-level ‘atexit’ cleanup which will close that connection. But closing in the child would upset the protocol in the parent, so ‘primitive-_exit’ should be used to exit without that. -- Scheme Procedure: execl filename arg ... -- C Function: scm_execl (filename, args) Executes the file named by FILENAME as a new process image. The remaining arguments are supplied to the process; from a C program they are accessible as the ‘argv’ argument to ‘main’. Conventionally the first ARG is the same as FILENAME. All arguments must be strings. If ARG is missing, FILENAME is executed with a null argument list, which may have system-dependent side-effects. This procedure is currently implemented using the ‘execv’ system call, but we call it ‘execl’ because of its Scheme calling interface. -- Scheme Procedure: execlp filename arg ... -- C Function: scm_execlp (filename, args) Similar to ‘execl’, however if FILENAME does not contain a slash then the file to execute will be located by searching the directories listed in the ‘PATH’ environment variable. This procedure is currently implemented using the ‘execvp’ system call, but we call it ‘execlp’ because of its Scheme calling interface. -- Scheme Procedure: execle filename env arg ... -- C Function: scm_execle (filename, env, args) Similar to ‘execl’, but the environment of the new process is specified by ENV, which must be a list of strings as returned by the ‘environ’ procedure. This procedure is currently implemented using the ‘execve’ system call, but we call it ‘execle’ because of its Scheme calling interface. -- Scheme Procedure: primitive-fork -- C Function: scm_fork () Creates a new "child" process by duplicating the current "parent" process. In the child the return value is 0. In the parent the return value is the integer process ID of the child. Note that it is unsafe to fork a process that has multiple threads running, as only the thread that calls ‘primitive-fork’ will persist in the child. Any resources that other threads held, such as locked mutexes or open file descriptors, are lost. Indeed, POSIX specifies that only async-signal-safe procedures are safe to call after a multithreaded fork, which is a very limited set. Guile issues a warning if it detects a fork from a multi-threaded program. Note: If you are looking to spawn a process with some pipes set up, using the ‘spawn’ procedure described below will be more robust (in particular in multi-threaded contexts), more portable, and usually more efficient than the combination of ‘primitive-fork’ and ‘execl’. This procedure has been renamed from ‘fork’ to avoid a naming conflict with the scsh fork. -- Scheme Procedure: spawn PROGRAM ARGUMENTS [#:environment=(environ)] [#:input=(current-input-port)] [#:output=(current-output-port)] [#:error=(current-error-port)] [#:search-path?=#t] Spawn a new child process executing PROGRAM with the given ARGUMENTS, a list of one or more strings (by convention, the first argument is typically PROGRAM), and return its PID. Raise a ‘system-error’ exception if PROGRAM could not be found or could not be executed. If the keyword argument ‘#:search-path?’ is true, it selects whether the ‘PATH’ environment variable should be inspected to find PROGRAM. It is true by default. The ‘#:environment’ keyword parameter specifies the list of environment variables of the child process. It defaults to ‘(environ)’. The keyword arguments ‘#:input’, ‘#:output’, and ‘#:error’ specify the port or file descriptor for the child process to use as standard input, standard output, and standard error. No other file descriptors are inherited from the parent process. The example below shows how to spawn the ‘uname’ program with the ‘-o’ option (*note (coreutils)uname invocation::), redirect its standard output to a pipe, and read from it: (use-modules (rnrs io ports)) (let* ((input+output (pipe)) (pid (spawn "uname" '("uname" "-o") #:output (cdr input+output)))) (close-port (cdr input+output)) (format #t "read ~s~%" (get-string-all (car input+output))) (close-port (car input+output)) (waitpid pid)) ⊣ read "GNU/Linux\n" ⇒ (1234 . 0) -- Scheme Procedure: nice incr -- C Function: scm_nice (incr) Increment the priority of the current process by INCR. A higher priority value means that the process runs less often. The return value is unspecified. -- Scheme Procedure: setpriority which who prio -- C Function: scm_setpriority (which, who, prio) Set the scheduling priority of the process, process group or user, as indicated by WHICH and WHO. WHICH is one of the variables ‘PRIO_PROCESS’, ‘PRIO_PGRP’ or ‘PRIO_USER’, and WHO is interpreted relative to WHICH (a process identifier for ‘PRIO_PROCESS’, process group identifier for ‘PRIO_PGRP’, and a user identifier for ‘PRIO_USER’. A zero value of WHO denotes the current process, process group, or user. PRIO is a value in the range [−20,20]. The default priority is 0; lower priorities (in numerical terms) cause more favorable scheduling. Sets the priority of all of the specified processes. Only the super-user may lower priorities. The return value is not specified. -- Scheme Procedure: getpriority which who -- C Function: scm_getpriority (which, who) Return the scheduling priority of the process, process group or user, as indicated by WHICH and WHO. WHICH is one of the variables ‘PRIO_PROCESS’, ‘PRIO_PGRP’ or ‘PRIO_USER’, and WHO should be interpreted depending on WHICH (a process identifier for ‘PRIO_PROCESS’, process group identifier for ‘PRIO_PGRP’, and a user identifier for ‘PRIO_USER’). A zero value of WHO denotes the current process, process group, or user. Return the highest priority (lowest numerical value) of any of the specified processes. -- Scheme Procedure: getaffinity pid -- C Function: scm_getaffinity (pid) Return a bitvector representing the CPU affinity mask for process PID. Each CPU the process has affinity with has its corresponding bit set in the returned bitvector. The number of bits set is a good estimate of how many CPUs Guile can use without stepping on other processes' toes. Currently this procedure is only defined on GNU variants (*note ‘sched_getaffinity’: (libc)CPU Affinity.). -- Scheme Procedure: setaffinity pid mask -- C Function: scm_setaffinity (pid, mask) Install the CPU affinity mask MASK, a bitvector, for the process or thread with ID PID. The return value is unspecified. Currently this procedure is only defined on GNU variants (*note ‘sched_setaffinity’: (libc)CPU Affinity.). *Note Threads::, for information on how get the number of processors available on a system. 7.2.8 Signals ------------- The following procedures raise, handle and wait for signals. Scheme code signal handlers are run via an async (*note Asyncs::), so they're called in the handler's thread at the next safe opportunity. Generally this is after any currently executing primitive procedure finishes (which could be a long time for primitives that wait for an external event). -- Scheme Procedure: kill pid sig -- C Function: scm_kill (pid, sig) Sends a signal to the specified process or group of processes. PID specifies the processes to which the signal is sent: PID greater than 0 The process whose identifier is PID. PID equal to 0 All processes in the current process group. PID less than -1 The process group whose identifier is -PID PID equal to -1 If the process is privileged, all processes except for some special system processes. Otherwise, all processes with the current effective user ID. SIG should be specified using a variable corresponding to the Unix symbolic name, e.g., -- Variable: SIGHUP Hang-up signal. -- Variable: SIGINT Interrupt signal. A full list of signals on the GNU system may be found in *note (libc)Standard Signals::. -- Scheme Procedure: raise sig -- C Function: scm_raise (sig) Sends a specified signal SIG to the current process, where SIG is as described for the ‘kill’ procedure. -- Scheme Procedure: sigaction signum [handler [flags [thread]]] -- C Function: scm_sigaction (signum, handler, flags) -- C Function: scm_sigaction_for_thread (signum, handler, flags, thread) Install or report the signal handler for a specified signal. SIGNUM is the signal number, which can be specified using the value of variables such as ‘SIGINT’. If HANDLER is omitted, ‘sigaction’ returns a pair: the CAR is the current signal handler, which will be either an integer with the value ‘SIG_DFL’ (default action) or ‘SIG_IGN’ (ignore), or the Scheme procedure which handles the signal, or ‘#f’ if a non-Scheme procedure handles the signal. The CDR contains the current ‘sigaction’ flags for the handler. If HANDLER is provided, it is installed as the new handler for SIGNUM. HANDLER can be a Scheme procedure taking one argument, or the value of ‘SIG_DFL’ (default action) or ‘SIG_IGN’ (ignore), or ‘#f’ to restore whatever signal handler was installed before ‘sigaction’ was first used. When a scheme procedure has been specified, that procedure will run in the given THREAD. When no thread has been given, the thread that made this call to ‘sigaction’ is used. FLAGS is a ‘logior’ (*note Bitwise Operations::) of the following (where provided by the system), or ‘0’ for none. -- Variable: SA_NOCLDSTOP By default, ‘SIGCHLD’ is signaled when a child process stops (ie. receives ‘SIGSTOP’), and when a child process terminates. With the ‘SA_NOCLDSTOP’ flag, ‘SIGCHLD’ is only signaled for termination, not stopping. ‘SA_NOCLDSTOP’ has no effect on signals other than ‘SIGCHLD’. -- Variable: SA_RESTART If a signal occurs while in a system call, deliver the signal then restart the system call (as opposed to returning an ‘EINTR’ error from that call). Guile handles signals asynchronously. When it receives a signal, the synchronous signal handler just records the fact that a signal was received and sets a flag to tell the relevant Guile thread that it has a pending signal. When the Guile thread checks the pending-interrupt flag, it will arrange to run the asynchronous part of the signal handler, which is the handler attached by ‘sigaction’. This strategy has some perhaps-unexpected interactions with the ‘SA_RESTART’ flag, though: because the synchronous handler doesn't do very much, and notably it doesn't run the Guile handler, it's impossible to interrupt a thread stuck in a long-running system call via a signal handler that is installed with ‘SA_RESTART’: the synchronous handler just records the pending interrupt, but then the system call resumes and Guile doesn't have a chance to actually check the flag and run the asynchronous handler. That's just how it is. The return value is a pair with information about the old handler as described above. This interface does not provide access to the "signal blocking" facility. Maybe this is not needed, since the thread support may provide solutions to the problem of consistent access to data structures. -- Scheme Procedure: restore-signals -- C Function: scm_restore_signals () Return all signal handlers to the values they had before any call to ‘sigaction’ was made. The return value is unspecified. -- Scheme Procedure: alarm i -- C Function: scm_alarm (i) Set a timer to raise a ‘SIGALRM’ signal after the specified number of seconds (an integer). It's advisable to install a signal handler for ‘SIGALRM’ beforehand, since the default action is to terminate the process. The return value indicates the time remaining for the previous alarm, if any. The new value replaces the previous alarm. If there was no previous alarm, the return value is zero. -- Scheme Procedure: pause -- C Function: scm_pause () Pause the current process (thread?) until a signal arrives whose action is to either terminate the current process or invoke a handler procedure. The return value is unspecified. -- Scheme Procedure: sleep secs -- Scheme Procedure: usleep usecs -- C Function: scm_sleep (secs) -- C Function: scm_usleep (usecs) Wait the given period SECS seconds or USECS microseconds (both integers). If a signal arrives the wait stops and the return value is the time remaining, in seconds or microseconds respectively. If the period elapses with no signal the return is zero. On most systems the process scheduler is not microsecond accurate and the actual period slept by ‘usleep’ might be rounded to a system clock tick boundary, which might be 10 milliseconds for instance. See ‘scm_std_sleep’ and ‘scm_std_usleep’ for equivalents at the C level (*note Blocking::). -- Scheme Procedure: getitimer which_timer -- Scheme Procedure: setitimer which_timer interval_seconds interval_microseconds value_seconds value_microseconds -- C Function: scm_getitimer (which_timer) -- C Function: scm_setitimer (which_timer, interval_seconds, interval_microseconds, value_seconds, value_microseconds) Get or set the periods programmed in certain system timers. These timers have two settings. The first setting, the interval, is the value at which the timer will be reset when the current timer expires. The second is the current value of the timer, indicating when the next expiry will be signaled. WHICH_TIMER is one of the following values: -- Variable: ITIMER_REAL A real-time timer, counting down elapsed real time. At zero it raises ‘SIGALRM’. This is like ‘alarm’ above, but with a higher resolution period. -- Variable: ITIMER_VIRTUAL A virtual-time timer, counting down while the current process is actually using CPU. At zero it raises ‘SIGVTALRM’. -- Variable: ITIMER_PROF A profiling timer, counting down while the process is running (like ‘ITIMER_VIRTUAL’) and also while system calls are running on the process's behalf. At zero it raises a ‘SIGPROF’. This timer is intended for profiling where a program is spending its time (by looking where it is when the timer goes off). ‘getitimer’ returns the restart timer value and its current value, as a list containing two pairs. Each pair is a time in seconds and microseconds: ‘((INTERVAL_SECS . INTERVAL_USECS) (VALUE_SECS . VALUE_USECS))’. ‘setitimer’ sets the timer values similarly, in seconds and microseconds (which must be integers). The interval value can be zero to have the timer run down just once. The return value is the timer's previous setting, in the same form as ‘getitimer’ returns. (setitimer ITIMER_REAL 5 500000 ;; Raise SIGALRM every 5.5 seconds 2 0) ;; with the first SIGALRM in 2 seconds Although the timers are programmed in microseconds, the actual accuracy might not be that high. Note that ‘ITIMER_PROF’ and ‘ITIMER_VIRTUAL’ are not functional on all platforms and may always error when called. ‘(provided? 'ITIMER_PROF)’ and ‘(provided? 'ITIMER_VIRTUAL)’ can be used to test if the those itimers are supported on the given host. ‘ITIMER_REAL’ is supported on all platforms that support ‘setitimer’. 7.2.9 Terminals and Ptys ------------------------ -- Scheme Procedure: isatty? port -- C Function: scm_isatty_p (port) Return ‘#t’ if PORT is using a serial non-file device, otherwise ‘#f’. -- Scheme Procedure: ttyname port -- C Function: scm_ttyname (port) Return a string with the name of the serial terminal device underlying PORT. -- Scheme Procedure: ctermid -- C Function: scm_ctermid () Return a string containing the file name of the controlling terminal for the current process. -- Scheme Procedure: tcgetpgrp port -- C Function: scm_tcgetpgrp (port) Return the process group ID of the foreground process group associated with the terminal open on the file descriptor underlying PORT. If there is no foreground process group, the return value is a number greater than 1 that does not match the process group ID of any existing process group. This can happen if all of the processes in the job that was formerly the foreground job have terminated, and no other job has yet been moved into the foreground. -- Scheme Procedure: tcsetpgrp port pgid -- C Function: scm_tcsetpgrp (port, pgid) Set the foreground process group ID for the terminal used by the file descriptor underlying PORT to the integer PGID. The calling process must be a member of the same session as PGID and must have the same controlling terminal. The return value is unspecified. 7.2.10 Pipes ------------ The following procedures are similar to the ‘popen’ and ‘pclose’ system routines. The code is in a separate "popen" module(1): (use-modules (ice-9 popen)) -- Scheme Procedure: open-pipe command mode -- Scheme Procedure: open-pipe* mode prog [args...] Execute a command in a subprocess, with a pipe to it or from it, or with pipes in both directions. ‘open-pipe’ runs the shell COMMAND using ‘/bin/sh -c’. ‘open-pipe*’ executes PROG directly, with the optional ARGS arguments (all strings). MODE should be one of the following values. ‘OPEN_READ’ is an input pipe, ie. to read from the subprocess. ‘OPEN_WRITE’ is an output pipe, ie. to write to it. -- Variable: OPEN_READ -- Variable: OPEN_WRITE -- Variable: OPEN_BOTH For an input pipe, the child's standard output is the pipe and standard input is inherited from ‘current-input-port’. For an output pipe, the child's standard input is the pipe and standard output is inherited from ‘current-output-port’. In all cases the child's standard error is inherited from ‘current-error-port’ (*note Default Ports::). If those ‘current-X-ports’ are not files of some kind, and hence don't have file descriptors for the child, then ‘/dev/null’ is used instead. Care should be taken with ‘OPEN_BOTH’, a deadlock will occur if both parent and child are writing, and waiting until the write completes before doing any reading. Each direction has ‘PIPE_BUF’ bytes of buffering (*note Buffering::), which will be enough for small writes, but not for say putting a big file through a filter. -- Scheme Procedure: open-input-pipe command Equivalent to ‘open-pipe’ with mode ‘OPEN_READ’. (let* ((port (open-input-pipe "date --utc")) (str (read-line port))) ; from (ice-9 rdelim) (close-pipe port) str) ⇒ "Mon Mar 11 20:10:44 UTC 2002" -- Scheme Procedure: open-output-pipe command Equivalent to ‘open-pipe’ with mode ‘OPEN_WRITE’. (let ((port (open-output-pipe "lpr"))) (display "Something for the line printer.\n" port) (if (not (eqv? 0 (status:exit-val (close-pipe port)))) (error "Cannot print"))) -- Scheme Procedure: open-input-output-pipe command Equivalent to ‘open-pipe’ with mode ‘OPEN_BOTH’. -- Scheme Procedure: close-pipe port Close a pipe created by ‘open-pipe’, wait for the process to terminate, and return the wait status code. The status is as per ‘waitpid’ and can be decoded with ‘status:exit-val’ etc (*note Processes::) ‘waitpid WAIT_ANY’ should not be used when pipes are open, since it can reap a pipe's child process, causing an error from a subsequent ‘close-pipe’. ‘close-port’ (*note Ports::) can close a pipe, but it doesn't reap the child process. The garbage collector will close a pipe no longer in use, and reap the child process with ‘waitpid’. If the child hasn't yet terminated the garbage collector doesn't block, but instead checks again in the next GC. Many systems have per-user and system-wide limits on the number of processes, and a system-wide limit on the number of pipes, so pipes should be closed explicitly when no longer needed, rather than letting the garbage collector pick them up at some later time. -- Scheme Procedure: pipeline COMMANDS Execute a pipeline of COMMANDS, where each command is a list of a program and its arguments as strings, returning an input port to the end of the pipeline, an output port to the beginning of the pipeline and a list of PIDs of the processes executing the COMMANDS. (let ((commands '(("git" "ls-files") ("tar" "-cf-" "-T-") ("sha1sum" "-"))) (success? (lambda (pid) (zero? (status:exit-val (cdr (waitpid pid))))))) (receive (from to pids) (pipeline commands) (let* ((sha1 (read-delimited " " from)) (index (list-index (negate success?) (reverse pids)))) (close to) (close from) (if (not index) sha1 (string-append "pipeline failed in command: " (string-join (list-ref commands index))))))) ⇒ "52f99d234503fca8c84ef94b1005a3a28d8b3bc1" ---------- Footnotes ---------- (1) This module is only available on systems where the ‘popen’ feature is provided (*note Common Feature Symbols::). 7.2.11 Networking ----------------- 7.2.11.1 Network Address Conversion ................................... This section describes procedures which convert internet addresses between numeric and string formats. IPv4 Address Conversion ....................... An IPv4 Internet address is a 4-byte value, represented in Guile as an integer in host byte order, so that say "0.0.0.1" is 1, or "1.0.0.0" is 16777216. Some underlying C functions use network byte order for addresses, Guile converts as necessary so that at the Scheme level its host byte order everywhere. -- Variable: INADDR_ANY For a server, this can be used with ‘bind’ (*note Network Sockets and Communication::) to allow connections from any interface on the machine. -- Variable: INADDR_BROADCAST The broadcast address on the local network. -- Variable: INADDR_LOOPBACK The address of the local host using the loopback device, ie. ‘127.0.0.1’. -- Scheme Procedure: inet-netof address -- C Function: scm_inet_netof (address) Return the network number part of the given IPv4 Internet address. E.g., (inet-netof 2130706433) ⇒ 127 -- Scheme Procedure: inet-lnaof address -- C Function: scm_lnaof (address) Return the local-address-with-network part of the given IPv4 Internet address, using the obsolete class A/B/C system. E.g., (inet-lnaof 2130706433) ⇒ 1 -- Scheme Procedure: inet-makeaddr net lna -- C Function: scm_inet_makeaddr (net, lna) Make an IPv4 Internet address by combining the network number NET with the local-address-within-network number LNA. E.g., (inet-makeaddr 127 1) ⇒ 2130706433 IPv6 Address Conversion ....................... An IPv6 Internet address is a 16-byte value, represented in Guile as an integer in host byte order, so that say "::1" is 1. The following constants are defined for convenience. -- Variable: IN6ADDR_ANY For a server, this can be used with ‘bind’ (*note Network Sockets and Communication::) to allow connections from any IPv6 interface on the machine. -- Variable: IN6ADDR_LOOPBACK The address of the local host using the loopback device, ie. ‘::1’. The procedures below convert an IPv6 _or_ an IPv4 address to and from its textual representation. -- Scheme Procedure: inet-ntop family address -- C Function: scm_inet_ntop (family, address) Convert a network address from an integer to a printable string. FAMILY can be ‘AF_INET’ or ‘AF_INET6’. E.g., (inet-ntop AF_INET 2130706433) ⇒ "127.0.0.1" (inet-ntop AF_INET6 (- (expt 2 128) 1)) ⇒ "ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff" -- Scheme Procedure: inet-pton family address -- C Function: scm_inet_pton (family, address) Convert a string containing a printable network address to an integer address. FAMILY can be ‘AF_INET’ or ‘AF_INET6’. E.g., (inet-pton AF_INET "127.0.0.1") ⇒ 2130706433 (inet-pton AF_INET6 "::1") ⇒ 1 7.2.11.2 Network Databases .......................... This section describes procedures which query various network databases. Care should be taken when using the database routines since they are not reentrant. ‘getaddrinfo’ ............. The ‘getaddrinfo’ procedure maps host and service names to socket addresses and associated information in a protocol-independent way. -- Scheme Procedure: getaddrinfo name service [hint_flags [hint_family [hint_socktype [hint_protocol]]]] -- C Function: scm_getaddrinfo (name, service, hint_flags, hint_family, hint_socktype, hint_protocol) Return a list of ‘addrinfo’ structures containing a socket address and associated information for host NAME and/or SERVICE to be used in creating a socket with which to address the specified service. (let* ((ai (car (getaddrinfo "www.gnu.org" "http"))) (s (socket (addrinfo:fam ai) (addrinfo:socktype ai) (addrinfo:protocol ai)))) (connect s (addrinfo:addr ai)) s) When SERVICE is omitted or is ‘#f’, return network-level addresses for NAME. When NAME is ‘#f’ SERVICE must be provided and service locations local to the caller are returned. Additional hints can be provided. When specified, HINT_FLAGS should be a bitwise-or of zero or more constants among the following: ‘AI_PASSIVE’ Socket address is intended for ‘bind’. ‘AI_CANONNAME’ Request for canonical host name, available via ‘addrinfo:canonname’. This makes sense mainly when DNS lookups are involved. ‘AI_NUMERICHOST’ Specifies that NAME is a numeric host address string (e.g., ‘"127.0.0.1"’), meaning that name resolution will not be used. ‘AI_NUMERICSERV’ Likewise, specifies that SERVICE is a numeric port string (e.g., ‘"80"’). ‘AI_ADDRCONFIG’ Return only addresses configured on the local system It is highly recommended to provide this flag when the returned socket addresses are to be used to make connections; otherwise, some of the returned addresses could be unreachable or use a protocol that is not supported. ‘AI_V4MAPPED’ When looking up IPv6 addresses, return mapped IPv4 addresses if there is no IPv6 address available at all. ‘AI_ALL’ If this flag is set along with ‘AI_V4MAPPED’ when looking up IPv6 addresses, return all IPv6 addresses as well as all IPv4 addresses, the latter mapped to IPv6 format. When given, HINT_FAMILY should specify the requested address family, e.g., ‘AF_INET6’. Similarly, HINT_SOCKTYPE should specify the requested socket type (e.g., ‘SOCK_DGRAM’), and HINT_PROTOCOL should specify the requested protocol (its value is interpreted as in calls to ‘socket’). On error, an exception with key ‘getaddrinfo-error’ is thrown, with an error code (an integer) as its argument: (catch 'getaddrinfo-error (lambda () (getaddrinfo "www.gnu.org" "gopher")) (lambda (key errcode) (cond ((= errcode EAI_SERVICE) (display "doesn't know about Gopher!\n")) ((= errcode EAI_NONAME) (display "www.gnu.org not found\\n")) (else (format #t "something wrong: ~a\n" (gai-strerror errcode)))))) Error codes are: ‘EAI_AGAIN’ The name or service could not be resolved at this time. Future attempts may succeed. ‘EAI_BADFLAGS’ HINT_FLAGS contains an invalid value. ‘EAI_FAIL’ A non-recoverable error occurred when attempting to resolve the name. ‘EAI_FAMILY’ HINT_FAMILY was not recognized. ‘EAI_NONAME’ Either NAME does not resolve for the supplied parameters, or neither NAME nor SERVICE were supplied. ‘EAI_NODATA’ This non-POSIX error code can be returned on some systems (GNU and Darwin, at least), for example when NAME is known but requests that were made turned out no data. Error handling code should be prepared to handle it when it is defined. ‘EAI_SERVICE’ SERVICE was not recognized for the specified socket type. ‘EAI_SOCKTYPE’ HINT_SOCKTYPE was not recognized. ‘EAI_SYSTEM’ A system error occurred. In C, the error code can be found in ‘errno’; this value is not accessible from Scheme, but in practice it provides little information about the actual error cause. Users are encouraged to read the "POSIX specification (http://www.opengroup.org/onlinepubs/9699919799/functions/getaddrinfo.html) for more details. The following procedures take an ‘addrinfo’ object as returned by ‘getaddrinfo’: -- Scheme Procedure: addrinfo:flags ai Return flags for AI as a bitwise or of ‘AI_’ values (see above). -- Scheme Procedure: addrinfo:fam ai Return the address family of AI (a ‘AF_’ value). -- Scheme Procedure: addrinfo:socktype ai Return the socket type for AI (a ‘SOCK_’ value). -- Scheme Procedure: addrinfo:protocol ai Return the protocol of AI. -- Scheme Procedure: addrinfo:addr ai Return the socket address associated with AI as a ‘sockaddr’ object (*note Network Socket Address::). -- Scheme Procedure: addrinfo:canonname ai Return a string for the canonical name associated with AI if the ‘AI_CANONNAME’ flag was supplied. The Host Database ................. A “host object” is a structure that represents what is known about a network host, and is the usual way of representing a system's network identity inside software. The following functions accept a host object and return a selected component: -- Scheme Procedure: hostent:name host The "official" hostname for HOST. -- Scheme Procedure: hostent:aliases host A list of aliases for HOST. -- Scheme Procedure: hostent:addrtype host The host address type, one of the ‘AF’ constants, such as ‘AF_INET’ or ‘AF_INET6’. -- Scheme Procedure: hostent:length host The length of each address for HOST, in bytes. -- Scheme Procedure: hostent:addr-list host The list of network addresses associated with HOST. For ‘AF_INET’ these are integer IPv4 address (*note Network Address Conversion::). The following procedures can be used to search the host database. However, ‘getaddrinfo’ should be preferred over them since it's more generic and thread-safe. -- Scheme Procedure: gethost [host] -- Scheme Procedure: gethostbyname hostname -- Scheme Procedure: gethostbyaddr address -- C Function: scm_gethost (host) Look up a host by name or address, returning a host object. The ‘gethost’ procedure will accept either a string name or an integer address; if given no arguments, it behaves like ‘gethostent’ (see below). If a name or address is supplied but the address can not be found, an error will be thrown to one of the keys: ‘host-not-found’, ‘try-again’, ‘no-recovery’ or ‘no-data’, corresponding to the equivalent ‘h_error’ values. Unusual conditions may result in errors thrown to the ‘system-error’ or ‘misc_error’ keys. (gethost "www.gnu.org") ⇒ #("www.gnu.org" () 2 4 (3353880842)) (gethostbyname "www.emacs.org") ⇒ #("emacs.org" ("www.emacs.org") 2 4 (1073448978)) The following procedures may be used to step through the host database from beginning to end. -- Scheme Procedure: sethostent [stayopen] Initialize an internal stream from which host objects may be read. This procedure must be called before any calls to ‘gethostent’, and may also be called afterward to reset the host entry stream. If STAYOPEN is supplied and is not ‘#f’, the database is not closed by subsequent ‘gethostbyname’ or ‘gethostbyaddr’ calls, possibly giving an efficiency gain. -- Scheme Procedure: gethostent Return the next host object from the host database, or ‘#f’ if there are no more hosts to be found (or an error has been encountered). This procedure may not be used before ‘sethostent’ has been called. -- Scheme Procedure: endhostent Close the stream used by ‘gethostent’. The return value is unspecified. -- Scheme Procedure: sethost [stayopen] -- C Function: scm_sethost (stayopen) If STAYOPEN is omitted, this is equivalent to ‘endhostent’. Otherwise it is equivalent to ‘sethostent stayopen’. The Network Database .................... The following functions accept an object representing a network and return a selected component: -- Scheme Procedure: netent:name net The "official" network name. -- Scheme Procedure: netent:aliases net A list of aliases for the network. -- Scheme Procedure: netent:addrtype net The type of the network number. Currently, this returns only ‘AF_INET’. -- Scheme Procedure: netent:net net The network number. The following procedures are used to search the network database: -- Scheme Procedure: getnet [net] -- Scheme Procedure: getnetbyname net-name -- Scheme Procedure: getnetbyaddr net-number -- C Function: scm_getnet (net) Look up a network by name or net number in the network database. The NET-NAME argument must be a string, and the NET-NUMBER argument must be an integer. ‘getnet’ will accept either type of argument, behaving like ‘getnetent’ (see below) if no arguments are given. The following procedures may be used to step through the network database from beginning to end. -- Scheme Procedure: setnetent [stayopen] Initialize an internal stream from which network objects may be read. This procedure must be called before any calls to ‘getnetent’, and may also be called afterward to reset the net entry stream. If STAYOPEN is supplied and is not ‘#f’, the database is not closed by subsequent ‘getnetbyname’ or ‘getnetbyaddr’ calls, possibly giving an efficiency gain. -- Scheme Procedure: getnetent Return the next entry from the network database. -- Scheme Procedure: endnetent Close the stream used by ‘getnetent’. The return value is unspecified. -- Scheme Procedure: setnet [stayopen] -- C Function: scm_setnet (stayopen) If STAYOPEN is omitted, this is equivalent to ‘endnetent’. Otherwise it is equivalent to ‘setnetent stayopen’. The Protocol Database ..................... The following functions accept an object representing a protocol and return a selected component: -- Scheme Procedure: protoent:name protocol The "official" protocol name. -- Scheme Procedure: protoent:aliases protocol A list of aliases for the protocol. -- Scheme Procedure: protoent:proto protocol The protocol number. The following procedures are used to search the protocol database: -- Scheme Procedure: getproto [protocol] -- Scheme Procedure: getprotobyname name -- Scheme Procedure: getprotobynumber number -- C Function: scm_getproto (protocol) Look up a network protocol by name or by number. ‘getprotobyname’ takes a string argument, and ‘getprotobynumber’ takes an integer argument. ‘getproto’ will accept either type, behaving like ‘getprotoent’ (see below) if no arguments are supplied. The following procedures may be used to step through the protocol database from beginning to end. -- Scheme Procedure: setprotoent [stayopen] Initialize an internal stream from which protocol objects may be read. This procedure must be called before any calls to ‘getprotoent’, and may also be called afterward to reset the protocol entry stream. If STAYOPEN is supplied and is not ‘#f’, the database is not closed by subsequent ‘getprotobyname’ or ‘getprotobynumber’ calls, possibly giving an efficiency gain. -- Scheme Procedure: getprotoent Return the next entry from the protocol database. -- Scheme Procedure: endprotoent Close the stream used by ‘getprotoent’. The return value is unspecified. -- Scheme Procedure: setproto [stayopen] -- C Function: scm_setproto (stayopen) If STAYOPEN is omitted, this is equivalent to ‘endprotoent’. Otherwise it is equivalent to ‘setprotoent stayopen’. The Service Database .................... The following functions accept an object representing a service and return a selected component: -- Scheme Procedure: servent:name serv The "official" name of the network service. -- Scheme Procedure: servent:aliases serv A list of aliases for the network service. -- Scheme Procedure: servent:port serv The Internet port used by the service. -- Scheme Procedure: servent:proto serv The protocol used by the service. A service may be listed many times in the database under different protocol names. The following procedures are used to search the service database: -- Scheme Procedure: getserv [name [protocol]] -- Scheme Procedure: getservbyname name protocol -- Scheme Procedure: getservbyport port protocol -- C Function: scm_getserv (name, protocol) Look up a network service by name or by service number, and return a network service object. The PROTOCOL argument specifies the name of the desired protocol; if the protocol found in the network service database does not match this name, a system error is signaled. The ‘getserv’ procedure will take either a service name or number as its first argument; if given no arguments, it behaves like ‘getservent’ (see below). (getserv "imap" "tcp") ⇒ #("imap2" ("imap") 143 "tcp") (getservbyport 88 "udp") ⇒ #("kerberos" ("kerberos5" "krb5") 88 "udp") The following procedures may be used to step through the service database from beginning to end. -- Scheme Procedure: setservent [stayopen] Initialize an internal stream from which service objects may be read. This procedure must be called before any calls to ‘getservent’, and may also be called afterward to reset the service entry stream. If STAYOPEN is supplied and is not ‘#f’, the database is not closed by subsequent ‘getservbyname’ or ‘getservbyport’ calls, possibly giving an efficiency gain. -- Scheme Procedure: getservent Return the next entry from the services database. -- Scheme Procedure: endservent Close the stream used by ‘getservent’. The return value is unspecified. -- Scheme Procedure: setserv [stayopen] -- C Function: scm_setserv (stayopen) If STAYOPEN is omitted, this is equivalent to ‘endservent’. Otherwise it is equivalent to ‘setservent stayopen’. 7.2.11.3 Network Socket Address ............................... A “socket address” object identifies a socket endpoint for communication. In the case of ‘AF_INET’ for instance, the socket address object comprises the host address (or interface on the host) and a port number which specifies a particular open socket in a running client or server process. A socket address object can be created with, -- Scheme Procedure: make-socket-address AF_INET ipv4addr port -- Scheme Procedure: make-socket-address AF_INET6 ipv6addr port [flowinfo [scopeid]] -- Scheme Procedure: make-socket-address AF_UNIX path -- C Function: scm_make_socket_address (family, address, arglist) Return a new socket address object. The first argument is the address family, one of the ‘AF’ constants, then the arguments vary according to the family. For ‘AF_INET’ the arguments are an IPv4 network address number (*note Network Address Conversion::), and a port number. For ‘AF_INET6’ the arguments are an IPv6 network address number and a port number. Optional FLOWINFO and SCOPEID arguments may be given (both integers, default 0). For ‘AF_UNIX’ the argument is a filename (a string). The C function ‘scm_make_socket_address’ takes the FAMILY and ADDRESS arguments directly, then ARGLIST is a list of further arguments, being the port for IPv4, port and optional flowinfo and scopeid for IPv6, or the empty list ‘SCM_EOL’ for Unix domain. The following functions access the fields of a socket address object, -- Scheme Procedure: sockaddr:fam sa Return the address family from socket address object SA. This is one of the ‘AF’ constants (e.g. ‘AF_INET’). -- Scheme Procedure: sockaddr:path sa For an ‘AF_UNIX’ socket address object SA, return the filename. -- Scheme Procedure: sockaddr:addr sa For an ‘AF_INET’ or ‘AF_INET6’ socket address object SA, return the network address number. -- Scheme Procedure: sockaddr:port sa For an ‘AF_INET’ or ‘AF_INET6’ socket address object SA, return the port number. -- Scheme Procedure: sockaddr:flowinfo sa For an ‘AF_INET6’ socket address object SA, return the flowinfo value. -- Scheme Procedure: sockaddr:scopeid sa For an ‘AF_INET6’ socket address object SA, return the scope ID value. The functions below convert to and from the C ‘struct sockaddr’ (*note (libc)Address Formats::). That structure is a generic type, an application can cast to or from ‘struct sockaddr_in’, ‘struct sockaddr_in6’ or ‘struct sockaddr_un’ according to the address family. In a ‘struct sockaddr’ taken or returned, the byte ordering in the fields follows the C conventions (*note Byte Order Conversion: (libc)Byte Order.). This means network byte order for ‘AF_INET’ host address (‘sin_addr.s_addr’) and port number (‘sin_port’), and ‘AF_INET6’ port number (‘sin6_port’). But at the Scheme level these values are taken or returned in host byte order, so the port is an ordinary integer, and the host address likewise is an ordinary integer (as described in *note Network Address Conversion::). -- C Function: struct sockaddr * scm_c_make_socket_address (SCM family, SCM address, SCM args, size_t *outsize) Return a newly-‘malloc’ed ‘struct sockaddr’ created from arguments like those taken by ‘scm_make_socket_address’ above. The size (in bytes) of the ‘struct sockaddr’ return is stored into ‘*OUTSIZE’. An application must call ‘free’ to release the returned structure when no longer required. -- C Function: SCM scm_from_sockaddr (const struct sockaddr *address, unsigned address_size) Return a Scheme socket address object from the C ADDRESS structure. ADDRESS_SIZE is the size in bytes of ADDRESS. -- C Function: struct sockaddr * scm_to_sockaddr (SCM address, size_t *address_size) Return a newly-‘malloc’ed ‘struct sockaddr’ from a Scheme level socket address object. The size (in bytes) of the ‘struct sockaddr’ return is stored into ‘*OUTSIZE’. An application must call ‘free’ to release the returned structure when no longer required. 7.2.11.4 Network Sockets and Communication .......................................... Socket ports can be created using ‘socket’ and ‘socketpair’. The ports are initially unbuffered, to make reading and writing to the same port more reliable. A buffer can be added to the port using ‘setvbuf’ (*note Buffering::). Most systems have limits on how many files and sockets can be open, so it's strongly recommended that socket ports be closed explicitly when no longer required (*note Ports::). Some of the underlying C functions take values in network byte order, but the convention in Guile is that at the Scheme level everything is ordinary host byte order and conversions are made automatically where necessary. -- Scheme Procedure: socket family style proto -- C Function: scm_socket (family, style, proto) Return a new socket port of the type specified by FAMILY, STYLE and PROTO. All three parameters are integers. The possible values for FAMILY are as follows, where supported by the system, -- Variable: PF_UNIX -- Variable: PF_INET -- Variable: PF_INET6 The possible values for STYLE are as follows, again where supported by the system, -- Variable: SOCK_STREAM -- Variable: SOCK_DGRAM -- Variable: SOCK_RAW -- Variable: SOCK_RDM -- Variable: SOCK_SEQPACKET PROTO can be obtained from a protocol name using ‘getprotobyname’ (*note Network Databases::). A value of zero means the default protocol, which is usually right. A socket cannot by used for communication until it has been connected somewhere, usually with either ‘connect’ or ‘accept’ below. -- Scheme Procedure: socketpair family style proto -- C Function: scm_socketpair (family, style, proto) Return a pair, the ‘car’ and ‘cdr’ of which are two unnamed socket ports connected to each other. The connection is full-duplex, so data can be transferred in either direction between the two. FAMILY, STYLE and PROTO are as per ‘socket’ above. But many systems only support socket pairs in the ‘PF_UNIX’ family. Zero is likely to be the only meaningful value for PROTO. -- Scheme Procedure: getsockopt sock level optname -- Scheme Procedure: setsockopt sock level optname value -- C Function: scm_getsockopt (sock, level, optname) -- C Function: scm_setsockopt (sock, level, optname, value) Get or set an option on socket port SOCK. ‘getsockopt’ returns the current value. ‘setsockopt’ sets a value and the return is unspecified. LEVEL is an integer specifying a protocol layer, either ‘SOL_SOCKET’ for socket level options, or a protocol number from the ‘IPPROTO’ constants or ‘getprotoent’ (*note Network Databases::). -- Variable: SOL_SOCKET -- Variable: IPPROTO_IP -- Variable: IPPROTO_IPV6 -- Variable: IPPROTO_TCP -- Variable: IPPROTO_UDP OPTNAME is an integer specifying an option within the protocol layer. For ‘SOL_SOCKET’ level the following OPTNAMEs are defined (when provided by the system). For their meaning see *note (libc)Socket-Level Options::, or ‘man 7 socket’. -- Variable: SO_DEBUG -- Variable: SO_REUSEADDR -- Variable: SO_STYLE -- Variable: SO_TYPE -- Variable: SO_ERROR -- Variable: SO_DONTROUTE -- Variable: SO_BROADCAST -- Variable: SO_SNDBUF -- Variable: SO_RCVBUF -- Variable: SO_KEEPALIVE -- Variable: SO_OOBINLINE -- Variable: SO_NO_CHECK -- Variable: SO_PRIORITY -- Variable: SO_REUSEPORT -- Variable: SO_RCVTIMEO -- Variable: SO_SNDTIMEO The VALUE taken or returned is an integer. -- Variable: SO_LINGER The VALUE taken or returned is a pair of integers ‘(ENABLE . TIMEOUT)’. On old systems without timeout support (ie. without ‘struct linger’), only ENABLE has an effect but the value in Guile is always a pair. For IP level (‘IPPROTO_IP’) the following OPTNAMEs are defined (when provided by the system). See ‘man ip’ for what they mean. -- Variable: IP_MULTICAST_IF This sets the source interface used by multicast traffic. -- Variable: IP_MULTICAST_TTL This sets the default TTL for multicast traffic. This defaults to 1 and should be increased to allow traffic to pass beyond the local network. -- Variable: IP_ADD_MEMBERSHIP -- Variable: IP_DROP_MEMBERSHIP These can be used only with ‘setsockopt’, not ‘getsockopt’. VALUE is a pair ‘(MULTIADDR . INTERFACEADDR)’ of integer IPv4 addresses (*note Network Address Conversion::). MULTIADDR is a multicast address to be added to or dropped from the interface INTERFACEADDR. INTERFACEADDR can be ‘INADDR_ANY’ to have the system select the interface. INTERFACEADDR can also be an interface index number, on systems supporting that. Last, for IPv6 level (‘IPPROTO_IPV6’), the following OPTNAMEs are defined. See ‘man 7 ipv6’ for details. -- Variable: IPV6_V6ONLY Determines whether an ‘AF_INET6’ socket is restricted to transmitting IPv6 packets only, or whether it can also transmit packets for an IPv4-mapped IPv6 address. For ‘IPPROTO_TCP’ level the following OPTNAMEs are defined (when provided by the system). For their meaning see ‘man 7 tcp’. -- Variable: TCP_NODELAY -- Variable: TCP_CORK The VALUE taken or returned is an integer. -- Scheme Procedure: shutdown sock how -- C Function: scm_shutdown (sock, how) Sockets can be closed simply by using ‘close-port’. The ‘shutdown’ procedure allows reception or transmission on a connection to be shut down individually, according to the parameter HOW: 0 Stop receiving data for this socket. If further data arrives, reject it. 1 Stop trying to transmit data from this socket. Discard any data waiting to be sent. Stop looking for acknowledgement of data already sent; don't retransmit it if it is lost. 2 Stop both reception and transmission. The return value is unspecified. -- Scheme Procedure: connect sock sockaddr -- Scheme Procedure: connect sock AF_INET ipv4addr port -- Scheme Procedure: connect sock AF_INET6 ipv6addr port [flowinfo [scopeid]] -- Scheme Procedure: connect sock AF_UNIX path -- C Function: scm_connect (sock, fam, address, args) Initiate a connection on socket port SOCK to a given address. The destination is either a socket address object, or arguments the same as ‘make-socket-address’ would take to make such an object (*note Network Socket Address::). Return true unless the socket was configured as non-blocking and the connection could not be made immediately. (connect sock AF_INET INADDR_LOOPBACK 23) (connect sock (make-socket-address AF_INET INADDR_LOOPBACK 23)) -- Scheme Procedure: bind sock sockaddr -- Scheme Procedure: bind sock AF_INET ipv4addr port -- Scheme Procedure: bind sock AF_INET6 ipv6addr port [flowinfo [scopeid]] -- Scheme Procedure: bind sock AF_UNIX path -- C Function: scm_bind (sock, fam, address, args) Bind socket port SOCK to the given address. The address is either a socket address object, or arguments the same as ‘make-socket-address’ would take to make such an object (*note Network Socket Address::). The return value is unspecified. Generally a socket is only explicitly bound to a particular address when making a server, i.e. to listen on a particular port. For an outgoing connection the system will assign a local address automatically, if not already bound. (bind sock AF_INET INADDR_ANY 12345) (bind sock (make-socket-address AF_INET INADDR_ANY 12345)) -- Scheme Procedure: listen sock backlog -- C Function: scm_listen (sock, backlog) Enable SOCK to accept connection requests. BACKLOG is an integer specifying the maximum length of the queue for pending connections. If the queue fills, new clients will fail to connect until the server calls ‘accept’ to accept a connection from the queue. The return value is unspecified. -- Scheme Procedure: accept sock [flags] -- C Function: scm_accept (sock) Accept a connection from socket port SOCK which has been enabled for listening with ‘listen’ above. If there are no incoming connections in the queue, there are two possible behaviors, depending on whether SOCK has been configured for non-blocking operation or not: • If there is no connection waiting and the socket was set to non-blocking mode with the ‘O_NONBLOCK’ port option (*note ‘fcntl’: Ports and File Descriptors.), return ‘#f’ directly. • Otherwise wait until a connection is available. The return value is a pair. The ‘car’ is a new socket port, connected and ready to communicate. The ‘cdr’ is a socket address object (*note Network Socket Address::) which is where the remote connection is from (like ‘getpeername’ below). FLAGS, if given, may include ‘SOCK_CLOEXEC’ or ‘SOCK_NONBLOCK’, which like ‘O_CLOEXEC’ and ‘O_NONBLOCK’ apply to the newly accepted socket. All communication takes place using the new socket returned. The given SOCK remains bound and listening, and ‘accept’ may be called on it again to get another incoming connection when desired. -- Scheme Procedure: getsockname sock -- C Function: scm_getsockname (sock) Return a socket address object which is the where SOCK is bound locally. SOCK may have obtained its local address from ‘bind’ (above), or if a ‘connect’ is done with an otherwise unbound socket (which is usual) then the system will have assigned an address. Note that on many systems the address of a socket in the ‘AF_UNIX’ namespace cannot be read. -- Scheme Procedure: getpeername sock -- C Function: scm_getpeername (sock) Return a socket address object which is where SOCK is connected to, i.e. the remote endpoint. Note that on many systems the address of a socket in the ‘AF_UNIX’ namespace cannot be read. -- Scheme Procedure: recv! sock buf [flags] -- C Function: scm_recv (sock, buf, flags) Receive data from a socket port. SOCK must already be bound to the address from which data is to be received. BUF is a bytevector into which the data will be written. The size of BUF limits the amount of data which can be received: in the case of packet protocols, if a packet larger than this limit is encountered then some data will be irrevocably lost. The optional FLAGS argument is a value or bitwise OR of ‘MSG_OOB’, ‘MSG_PEEK’, ‘MSG_DONTROUTE’ etc. The value returned is the number of bytes read from the socket. Note that the data is read directly from the socket file descriptor: any unread buffered port data is ignored. -- Scheme Procedure: send sock message [flags] -- C Function: scm_send (sock, message, flags) Transmit bytevector MESSAGE on socket port SOCK. SOCK must already be bound to a destination address. The value returned is the number of bytes transmitted--it's possible for this to be less than the length of MESSAGE if the socket is set to be non-blocking. The optional FLAGS argument is a value or bitwise OR of ‘MSG_OOB’, ‘MSG_PEEK’, ‘MSG_DONTROUTE’ etc. Note that the data is written directly to the socket file descriptor: any unflushed buffered port data is ignored. -- Scheme Procedure: recvfrom! sock buf [flags [start [end]]] -- C Function: scm_recvfrom (sock, buf, flags, start, end) Receive data from socket port SOCK, returning the originating address as well as the data. This function is usually for datagram sockets, but can be used on stream-oriented sockets too. The data received is stored in bytevector BUF, using either the whole bytevector or just the region between the optional START and END positions. The size of BUF limits the amount of data that can be received. For datagram protocols if a packet larger than this is received then excess bytes are irrevocably lost. The return value is a pair. The ‘car’ is the number of bytes read. The ‘cdr’ is a socket address object (*note Network Socket Address::) which is where the data came from, or ‘#f’ if the origin is unknown. The optional FLAGS argument is a or bitwise-OR (‘logior’) of ‘MSG_OOB’, ‘MSG_PEEK’, ‘MSG_DONTROUTE’ etc. Data is read directly from the socket file descriptor, any buffered port data is ignored. On a GNU/Linux system ‘recvfrom!’ is not multi-threading, all threads stop while a ‘recvfrom!’ call is in progress. An application may need to use ‘select’, ‘O_NONBLOCK’ or ‘MSG_DONTWAIT’ to avoid this. -- Scheme Procedure: sendto sock message sockaddr [flags] -- Scheme Procedure: sendto sock message AF_INET ipv4addr port [flags] -- Scheme Procedure: sendto sock message AF_INET6 ipv6addr port [flowinfo [scopeid [flags]]] -- Scheme Procedure: sendto sock message AF_UNIX path [flags] -- C Function: scm_sendto (sock, message, fam, address, args_and_flags) Transmit bytevector MESSAGE as a datagram socket port SOCK. The destination is specified either as a socket address object, or as arguments the same as would be taken by ‘make-socket-address’ to create such an object (*note Network Socket Address::). The destination address may be followed by an optional FLAGS argument which is a ‘logior’ (*note Bitwise Operations::) of ‘MSG_OOB’, ‘MSG_PEEK’, ‘MSG_DONTROUTE’ etc. The value returned is the number of bytes transmitted - it's possible for this to be less than the length of MESSAGE if the socket is set to be non-blocking. Note that the data is written directly to the socket file descriptor: any unflushed buffered port data is ignored. 7.2.11.5 Network Socket Examples ................................ The following give examples of how to use network sockets. Internet Socket Client Example .............................. The following example demonstrates an Internet socket client. It connects to the HTTP daemon running on the local machine and returns the contents of the root index URL. (let ((s (socket PF_INET SOCK_STREAM 0))) (connect s AF_INET (inet-pton AF_INET "127.0.0.1") 80) (display "GET / HTTP/1.0\r\n\r\n" s) (do ((line (read-line s) (read-line s))) ((eof-object? line)) (display line) (newline))) Internet Socket Server Example .............................. The following example shows a simple Internet server which listens on port 2904 for incoming connections and sends a greeting back to the client. (let ((s (socket PF_INET SOCK_STREAM 0))) (setsockopt s SOL_SOCKET SO_REUSEADDR 1) ;; Specific address? ;; (bind s AF_INET (inet-pton AF_INET "127.0.0.1") 2904) (bind s AF_INET INADDR_ANY 2904) (listen s 5) (simple-format #t "Listening for clients in pid: ~S" (getpid)) (newline) (while #t (let* ((client-connection (accept s)) (client-details (cdr client-connection)) (client (car client-connection))) (simple-format #t "Got new client connection: ~S" client-details) (newline) (simple-format #t "Client address: ~S" (gethostbyaddr (sockaddr:addr client-details))) (newline) ;; Send back the greeting to the client port (display "Hello client\r\n" client) (close client)))) 7.2.12 System Identification ---------------------------- This section lists the various procedures Guile provides for accessing information about the system it runs on. -- Scheme Procedure: uname -- C Function: scm_uname () Return an object with some information about the computer system the program is running on. The following procedures accept an object as returned by ‘uname’ and return a selected component (all of which are strings). -- Scheme Procedure: utsname:sysname un The name of the operating system. -- Scheme Procedure: utsname:nodename un The network name of the computer. -- Scheme Procedure: utsname:release un The current release level of the operating system implementation. -- Scheme Procedure: utsname:version un The current version level within the release of the operating system. -- Scheme Procedure: utsname:machine un A description of the hardware. -- Scheme Procedure: gethostname -- C Function: scm_gethostname () Return the host name of the current processor. -- Scheme Procedure: sethostname name -- C Function: scm_sethostname (name) Set the host name of the current processor to NAME. May only be used by the superuser. The return value is not specified. 7.2.13 Locales -------------- -- Scheme Procedure: setlocale category [locale] -- C Function: scm_setlocale (category, locale) Get or set the current locale, used for various internationalizations. Locales are strings, such as ‘sv_SE’. If LOCALE is given then the locale for the given CATEGORY is set and the new value returned. If LOCALE is not given then the current value is returned. CATEGORY should be one of the following values (*note Categories of Activities that Locales Affect: (libc)Locale Categories.): -- Variable: LC_ALL -- Variable: LC_COLLATE -- Variable: LC_CTYPE -- Variable: LC_MESSAGES -- Variable: LC_MONETARY -- Variable: LC_NUMERIC -- Variable: LC_TIME A common usage is ‘(setlocale LC_ALL "")’, which initializes all categories based on standard environment variables (‘LANG’ etc). For full details on categories and locale names *note Locales and Internationalization: (libc)Locales. Note that ‘setlocale’ affects locale settings for the whole process. *Note locale objects and ‘make-locale’: i18n Introduction, for a thread-safe alternative. 7.2.14 Encryption ----------------- Please note that the procedures in this section are not suited for strong encryption, they are only interfaces to the well-known and common system library functions of the same name. They are just as good (or bad) as the underlying functions, so you should refer to your system documentation before using them (*note Encrypting Passwords: (libc)crypt.). -- Scheme Procedure: crypt key salt -- C Function: scm_crypt (key, salt) Encrypt KEY, with the addition of SALT (both strings), using the ‘crypt’ C library call. Although ‘getpass’ is not an encryption procedure per se, it appears here because it is often used in combination with ‘crypt’: -- Scheme Procedure: getpass prompt -- C Function: scm_getpass (prompt) Display PROMPT to the standard error output and read a password from ‘/dev/tty’. If this file is not accessible, it reads from standard input. The password may be up to 127 characters in length. Additional characters and the terminating newline character are discarded. While reading the password, echoing and the generation of signals by special characters is disabled. 7.3 HTTP, the Web, and All That =============================== It has always been possible to connect computers together and share information between them, but the rise of the World Wide Web over the last couple of decades has made it much easier to do so. The result is a richly connected network of computation, in which Guile forms a part. By "the web", we mean the HTTP protocol(1) as handled by servers, clients, proxies, caches, and the various kinds of messages and message components that can be sent and received by that protocol, notably HTML. On one level, the web is text in motion: the protocols themselves are textual (though the payload may be binary), and it's possible to create a socket and speak text to the web. But such an approach is obviously primitive. This section details the higher-level data types and operations provided by Guile: URIs, HTTP request and response records, and a conventional web server implementation. The material in this section is arranged in ascending order, in which later concepts build on previous ones. If you prefer to start with the highest-level perspective, *note Web Examples::, and work your way back. ---------- Footnotes ---------- (1) Yes, the P is for protocol, but this phrase appears repeatedly in RFC 2616. 7.3.1 Types and the Web ----------------------- It is a truth universally acknowledged, that a program with good use of data types, will be free from many common bugs. Unfortunately, the common practice in web programming seems to ignore this maxim. This subsection makes the case for expressive data types in web programming. By "expressive data types", we mean that the data types _say_ something about how a program solves a problem. For example, if we choose to represent dates using SRFI 19 date records (*note SRFI-19::), this indicates that there is a part of the program that will always have valid dates. Error handling for a number of basic cases, like invalid dates, occurs on the boundary in which we produce a SRFI 19 date record from other types, like strings. With regards to the web, data types are helpful in the two broad phases of HTTP messages: parsing and generation. Consider a server, which has to parse a request, and produce a response. Guile will parse the request into an HTTP request object (*note Requests::), with each header parsed into an appropriate Scheme data type. This transition from an incoming stream of characters to typed data is a state change in a program--the strings might parse, or they might not, and something has to happen if they do not. (Guile throws an error in this case.) But after you have the parsed request, "client" code (code built on top of the Guile web framework) will not have to check for syntactic validity. The types already make this information manifest. This state change on the parsing boundary makes programs more robust, as they themselves are freed from the need to do a number of common error checks, and they can use normal Scheme procedures to handle a request instead of ad-hoc string parsers. The need for types on the response generation side (in a server) is more subtle, though not less important. Consider the example of a POST handler, which prints out the text that a user submits from a form. Such a handler might include a procedure like this: ;; First, a helper procedure (define (para . contents) (string-append "

" (string-concatenate contents) "

")) ;; Now the meat of our simple web application (define (you-said text) (para "You said: " text)) (display (you-said "Hi!")) ⊣

You said: Hi!

This is a perfectly valid implementation, provided that the incoming text does not contain the special HTML characters ‘<’, ‘>’, or ‘&’. But this provision of a restricted character set is not reflected anywhere in the program itself: we must _assume_ that the programmer understands this, and performs the check elsewhere. Unfortunately, the short history of the practice of programming does not bear out this assumption. A “cross-site scripting” (XSS) vulnerability is just such a common error in which unfiltered user input is allowed into the output. A user could submit a crafted comment to your web site which results in visitors running malicious Javascript, within the security context of your domain: (display (you-said "