Weekly Edition
Return to the Development page
| |||||||||||||||||||
GNU Guile 2.0.7 released
We are pleased to announce GNU Guile release 2.0.7, the next maintenance release for the 2.0.x stable series. The Guile web page is located at http://gnu.org/software/guile/ . Guile is an implementation of the Scheme programming language, with support for many SRFIs, packaged for use in a wide variety of environments. In addition to implementing the R5RS Scheme standard and a large subset of R6RS, Guile includes a module system, full access to POSIX system calls, networking support, multiple threads, dynamic linking, a foreign function call interface, and powerful string processing. Guile can run interactively, as a script interpreter, and as a Scheme compiler to VM bytecode suitable for stand-alone applications. It is also packaged as a library so that applications can easily incorporate a complete Scheme interpreter/VM. An application can use Guile as an extension language, a clean and powerful configuration language, or as multi-purpose "glue" to connect primitives provided by the application. Here are the compressed sources: ftp://ftp.gnu.org/gnu/guile/guile-2.0.7.tar.gz (6.9MB) ftp://ftp.gnu.org/gnu/guile/guile-2.0.7.tar.xz (4.3MB) Here are the GPG detached signatures[*]: ftp://ftp.gnu.org/gnu/guile/guile-2.0.7.tar.gz.sig ftp://ftp.gnu.org/gnu/guile/guile-2.0.7.tar.xz.sig Use a mirror for higher download bandwidth: http://www.gnu.org/order/ftp.html Here are the MD5 and SHA1 checksums: c18d48ba90296fb346f4cf2779f41598 guile-2.0.7.tar.gz 30ff9e94663a2e2098b52f8ce9d050b9 guile-2.0.7.tar.xz 4425cc1a60ffe5637972a328880f98746c2a0f5b guile-2.0.7.tar.gz cd6b061e76e36c6e75083168febab4807f1eadab guile-2.0.7.tar.xz [*] Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify guile-2.0.7.tar.gz.sig If that command fails because you don't have the required public key, then run this command to import it: gpg --keyserver keys.gnupg.net --recv-keys EA52ECF4 and rerun the 'gpg --verify' command. This release was bootstrapped with the following tools: Autoconf 2.69 Automake 1.12.2 Libtool 2.4.2 Gnulib v0.0-7695-g26c0590 This release provides many bug fixes, performance improvements, and some new features. Here are the highlights, taken from the `NEWS' file: * Notable changes ** SRFI-105 curly infix expressions are supported Curly infix expressions as described at http://srfi.schemers.org/srfi-105/srfi-105.html are now supported by Guile's reader. This allows users to write things like {a * {b + c}} instead of (* a (+ b c)). SRFI-105 support is enabled by using the `#!curly-infix' directive in source code, or the `curly-infix' reader option. See the manual for details. ** Reader options may now be per-port Historically, `read-options' and related procedures would manipulate global options, affecting the `read' procedure for all threads, and all current uses of `read'. Guile can now associate `read' options with specific ports, allowing different ports to use different options. For instance, the `#!fold-case' and `#!no-fold-case' reader directives have been implemented, and their effect is to modify the current read options of the current port only; similarly for `#!curly-infix'. Thus, it is possible, for instance, to have one port reading case-sensitive code, while another port reads case-insensitive code. ** Futures may now be nested Futures may now be nested: a future can itself spawn and then `touch' other futures. In addition, any thread that touches a future that has not completed now processes other futures while waiting for the touched future to completed. This allows all threads to be kept busy, and was made possible by the use of delimited continuations (see the manual for details.) Consequently, `par-map' and `par-for-each' have been rewritten and can now use all cores. ** `GUILE_LOAD_PATH' et al can now add directories to the end of the path `GUILE_LOAD_PATH' and `GUILE_LOAD_COMPILED_PATH' can now be used to add directories to both ends of the load path. If the special path component `...' (ellipsis) is present in these environment variables, then the default path is put in place of the ellipsis, otherwise the default path is placed at the end. See "Environment Variables" in the manual for details. ** `load-in-vicinity' search for `.go' files in `%load-compiled-path' Previously, `load-in-vicinity' would look for compiled files in the auto-compilation cache, but not in `%load-compiled-path'. This is now fixed. This affects `load', and the `-l' command-line flag. See <http://bugs.gnu.org/12519> for details. ** Extension search order fixed, and LD_LIBRARY_PATH preserved Up to 2.0.6, Guile would modify the `LD_LIBRARY_PATH' environment variable (or whichever is relevant for the host OS) to insert its own default extension directories in the search path (using GNU libltdl facilities was not possible here.) This approach was problematic in two ways. First, the `LD_LIBRARY_PATH' modification would be visible to sub-processes, and would also affect future calls to `dlopen', which could lead to subtle bugs in the application or sub-processes. Second, when the installation prefix is /usr, the `LD_LIBRARY_PATH' modification would typically end up inserting /usr/lib before /usr/local/lib in the search path, which is often the opposite of system-wide settings such as `ld.so.conf'. Both issues have now been fixed. ** `make-vtable-vtable' is now deprecated Programs should instead use `make-vtable' and `<standard-vtable>'. ** The `-Wduplicate-case-datum' and `-Wbad-case-datum' are enabled These recently introduced warnings have been documented and are now enabled by default when auto-compiling. ** Optimize calls to `equal?' or `eqv?' with a constant argument The compiler simplifies calls to `equal?' or `eqv?' with a constant argument to use `eq?' instead, when applicable. * Manual updates ** SRFI-9 records now documented under "Compound Data Types" The documentation of SRFI-9 record types has been moved in the "Compound Data Types", next to Guile's other record APIs. A new section introduces the various record APIs, and describes the trade-offs they make. These changes were made in an attempt to better guide users through the maze of records API, and to recommend SRFI-9 as the main API. The documentation of Guile's raw `struct' API has also been improved. ** (ice-9 and-let-star) and (ice-9 curried-definitions) now documented These modules were missing from the manual. * New interfaces ** New "functional record setters" as a GNU extension of SRFI-9 The (srfi srfi-9 gnu) module now provides three new macros to deal with "updates" of immutable records: `define-immutable-record-type', `set-field', and `set-fields'. The first one allows record type "functional setters" to be defined; such setters keep the record unchanged, and instead return a new record with only one different field. The remaining macros provide the same functionality, and also optimize updates of multiple or nested fields. See the manual for details. ** web: New `http-get*', `response-body-port', and `text-content-type?' procedures These procedures return a port from which to read the response's body. Unlike `http-get' and `read-response-body', they allow the body to be processed incrementally instead of being stored entirely in memory. The `text-content-type?' predicate allows users to determine whether the content type of a response is textual. See the manual for details. ** `string-split' accepts character sets and predicates The `string-split' procedure can now be given a SRFI-14 character set or a predicate, instead of just a character. ** R6RS SRFI support Previously, in R6RS modules, Guile incorrectly ignored components of SRFI module names after the SRFI number, making it impossible to specify sub-libraries. This release corrects this, bringing us into accordance with SRFI 97. ** `define-public' is no a longer curried definition by default The (ice-9 curried-definitions) should be used for such uses. See the manual for details. * Build fixes ** Remove reference to `scm_init_popen' when `fork' is unavailable This fixes a MinGW build issue (http://bugs.gnu.org/12477). ** Fix race between installing `guild' and the `guile-tools' symlink * Bug fixes ** Procedures returned by `eval' now have docstrings (http://bugs.gnu.org/12173) ** web client: correctly handle uri-query, etc. in relative URI headers (http://bugs.gnu.org/12827) ** Fix docs for R6RS `hashtable-copy' ** R6RS `string-for-each' now accepts multiple string arguments ** Fix out-of-range error in the compiler's CSE pass (http://bugs.gnu.org/12883) ** Add missing R6RS `open-file-input/output-port' procedure ** Futures: Avoid creating the worker pool more than once ** Fix invalid assertion about mutex ownership in threads.c (http://bugs.gnu.org/12719) ** Have `SCM_NUM2FLOAT' and `SCM_NUM2DOUBLE' use `scm_to_double' ** The `scandir' procedure now uses `lstat' instead of `stat' ** Fix `generalized-vector->list' indexing bug with shared arrays (http://bugs.gnu.org/12465) ** web: Change `http-get' to try all the addresses for the given URI ** Implement `hash' for structs (http://lists.gnu.org/archive/html/guile-devel/2012-10/msg...) ** `read' now adds source properties for data types beyond pairs ** Improve error reporting in `append!' ** In fold-matches, set regexp/notbol unless matching string start ** Don't stat(2) and access(2) the .go location before using it ** SRFI-19: use zero padding for hours in ISO 8601 format, not blanks ** web: Fix uri-encoding for strings with no unreserved chars, and octets 0-15 ** More robust texinfo alias handling ** Optimize `format' and `simple-format' (http://bugs.gnu.org/12033) ** Angle of -0.0 is pi, not zero You can follow Guile development in the Git repository and on the Guile mailing lists. Guile builds from the `master' branch of Git have version number 2.1.x. Guile versions with an odd middle number, e.g., 2.1.*, are unstable development versions. Even middle numbers indicate stable versions. This has been the case since the 1.3.* series. Please report bugs to `bug-guile@gnu.org'. We also welcome reports of successful builds, which can be sent to the same email address. Ludovic, on behalf of the Guile team. _______________________________________________ GNU Announcement mailing list <info-gnu@gnu.org> https://lists.gnu.org/mailman/listinfo/info-gnu (Log in to post comments)
Curly-infix and readable Lisp Posted Dec 3, 2012 19:04 UTC (Mon) by david.a.wheeler (guest, #72896) [Link] This is awesome news! I'm particularly excited that curly-infix is now in the released version of guile. The curly-infix notation, as defined in Scheme SRFI-105, is a subset of the work from the Readable Lisp S-expressions Project that I founded. If you are interested in making Lisps more readable, please join us.
Curly-infix and readable Lisp Posted Dec 3, 2012 22:08 UTC (Mon) by proski (subscriber, #104) [Link] As a user of GNU Lilypond, I have to admit that the learning curve for Guile has been rather steep for me. The infix syntax would have mitigated the problem somewhat.In addition to having more readable syntax, it would be nice to have a way to warn about potential mistakes, such as unused variables. I'm so used to compiler warnings in C that not having them in Guile would make me quite nervous when writing advanced code.
Curly-infix and readable Lisp Posted Dec 4, 2012 15:34 UTC (Tue) by dakas (guest, #88146) [Link] The infix syntax would have mitigated the problem somewhat.I doubt it. It is like imagining that a unidirectional word-by-word translator will enable you to write poetry in a language you don't know. You'll probably learn more about its grammar's dark corners than you ever wanted to know when trying to navigate by error messages. Driving through a superficial mechanical remapping layer will make things more rather than less baffling: the familiarity you hope for is not more than a front, and understanding just when this front does what you expect, and when it fails for what reason for what purposes, will require a deeper understanding than just writing in Scheme in the first place would. And you'll have a harder time communicating with others. Already trivial things like using totally different formatting and placement of parens cause code to become less readable to coworkers, and worse to manage for simple text-based replacements. An infix layer is not going to help, in particular since it does not really have a corresponding print form, so all output and all intermediate forms will look unfamiliar. Don't get me wrong: it is great that you can do this sort of transformation game in Scheme, and it is a nice exercise and proof of concept. But I don't consider it of practical relevance. It will be a project a number of people will enjoy and improve, but it will get used for very little "serious work" (TM), basically by almost nobody from the purported target clientele of people feeling unable to get their head wrapped around prefix syntax, and will eventually peter out.
Curly-infix and readable Lisp Posted Dec 4, 2012 17:09 UTC (Tue) by david.a.wheeler (guest, #72896) [Link] Poster says: the familiarity you hope for is not more than a front, and understanding just when this front does what you expect... will require a deeper understanding than just writing in Scheme in the first place would. The curly-infix notation is defined in terms of underlying list notations, so this fear is unwarranted. In Lisp, 'x is just an abbreviation for (quote x); this is just another abbreviation. It's important to note that curly-infix, unlike past infix notations, does not lose the Lisp advantages of homoiconicity and genericity; for details, see the SRFI-105 specification or the "readable" project materials. And you'll have a harder time communicating with others. Quite the reverse. If you've taken high school math, you know what infix notation is, so infix notation makes it easier to communicate with others. Infix notation isn't going away; ALL people, programmers or not, are trained to use infix operations with typical arithmetic operations, and failing to support infix notation is a real problem for Lisps. ... An infix layer is not going to help, in particular since it does not really have a corresponding print form, so all output and all intermediate forms will look unfamiliar. It has a corresponding print form, namely, {...}. ... it will get used for very little "serious work" (TM), basically by almost nobody from the purported target clientele of people feeling unable to get their head wrapped around prefix syntax, and will eventually peter out. Scheme and Common Lisp are often avoided today for new "serious work", period. I believe one of the reasons for this is that their syntax is repugnant to most developers. It's not a matter of not being able to get their head "wrapped around" a prefix system; the prefix system is easy. Many, many Scheme and Common Lisp systems have added infix notations, but they are all incompatible with each other. If we can get a SINGLE notation adopted by many such systems, that problem disappears.
Curly-infix and readable Lisp Posted Dec 4, 2012 19:03 UTC (Tue) by dakas (guest, #88146) [Link]
I have seen my fair share of trying to make a language/system appear like something else. An alternative read syntax does not buy you an alternative output syntax or alternative data structures. You'll either get
'#{ 3 + 4 } => (+ 3 4) or '(+ 3 4) => #{ 3 + 4 } and if you get the latter, it will be hard to figure the "flipping point" where #{ } will get used over normal list syntax in output, and where not.
And frankly, things like
Lisp forms are self-descriptive simple data structures, easily juggled around and interpreted by programs and macros. That's why we put up with this highly nested interpunction-sparse mess of a "language" (can you call something a language which just interprets the read form of data structures?) in the first place, and infix does not change this fundamental problem of having the whole nesting of the underlying data structure exposed.
Actually, not the whole. We are likely glad not to have to write out
But conversion to infix is a different beast than converting a conventional arrangement of dotted pairs to list syntax.
Curly-infix and readable Lisp Posted Dec 4, 2012 21:03 UTC (Tue) by david.a.wheeler (guest, #72896) [Link] Poster wrote: Lisp forms are self-descriptive simple data structures, easily juggled around and interpreted by programs and macros... infix does not change this fundamental problem of having the whole nesting of the underlying data structure exposed. Actually, not the whole. We are likely glad not to have to write out (+ . (3 . (4 . (5 . ())))) => 12 and instead have an alternative in- and output form for this automatically. But conversion to infix is a different beast than converting a conventional arrangement of dotted pairs to list syntax. I think that's the core of the disagreement. Unlike you, I believe that infix can be easily considered - and reasoned about - as just another abbreviation in Lisp-based languages. As you noted above, Lisp users are already used to other much more complex abbreviations, and abbreviations make common cases easier to deal with. In curly-infix, {AAA op BBB op CCC ...} is just a new abbreviation for (op AAA BBB CCC ...). That's all, it's just another abbreviation. A curly-infix user needs to be aware that this is an abbreviation, but it's really no big deal. It takes about 10 minutes or so to get used to it, and it works for any operation at all. And the payoff is big; many people prefer to use infix notation for arithmetic, comparisons, and so on. This notation really helps when communicating with others. Today's software is typically developed by many people, and in the case of open source software, being able to read others' code is key. Thus, the Lisp expression "(car '{a + b + c})" will evaluate to "+", because {a + b + c} is another way to write the list (+ a b c), and "car" returns the first item in a list. Sure, it's odd when you've never seen this before, but it's actually easy to learn. All you have to remember is that "{...}" presents a list in infix order instead of the straightforward order, and thus, you need to look at the infix position to find the operator. Because there are no precedence rules (by intent), there's no possibility of the complex reasoning that I think you're concerned about, and the whole thing is really easy to learn. Most software developers would prefer to be able to write {{a * b} - c} instead of having to write (- (* a b) c). Let's give them the tools they actually want.
Curly-infix and readable Lisp Posted Dec 5, 2012 9:59 UTC (Wed) by dakas (guest, #88146) [Link] Most software developers would prefer to be able to write {{a * b} - c} instead of having to write (- (* a b) c). Let's give them the tools they actually want.It is a common mistake to confuse "what they ask for" with "what they want". Its designers being aware of that difference and refusing a lot of those requests is probably one of the most important things giving Lua its clout. It is the task of the language designer to consolidate the (not necessarily consistent) specifications into a coherent whole. And if the requirement is "a language designed around infix notation", the answer is not Scheme. It may be possible to implement an answer nicely in Scheme, but that just means that Scheme is a good tool for the job, not that it is the job itself. If you asked Leonardo da Vinci for a picture of a warrior with a helmet, it is unlikely that he would delivered the Mona Lisa with a mustache and helmet. There is a book "Numerical Recipes" with code written in Fortran. Fortran is not really all that popular any more, so there had been a followup "Numerical Recipes in C". The array indices in that book start at 1, the indexing is row-first, and the syntax used for a(i,j) is a[i][j] by allocating for each matrix a row pointer array, and separate arrays for each row, all the time leaving index 0 unoccupied. That's a similar kind of "giving them tools they actually want". If my job were to do numerical work in C, I'd get the Fortran book and go from there. Ultimately, I have to talk to the computer, and make sense to it, and different languages have different inherent means to make sense. In this case, it would mean a sense-preserving translation into C (requiring explicit index arithmetic, or nowadays, C9x-like variable-dimensioned multidimensional arrays) or punting and using extern "Fortran" ...If somebody asked me for Swedish poetry, I would not propose Shell I cumpere-a zeee-a tu a soommer's dey? Bork Bork Bork!
Curly-infix and readable Lisp Posted Dec 5, 2012 11:56 UTC (Wed) by Zack (guest, #37335) [Link]
I think I understand -- and share -- your point of view. But due to the nature of scheme people *will* inevitably try and "fix" the prefix notation again and again, so you might as well have an SFRI for it so people can at least consistenly try to make the same mistake.
I also believe it's going to end up fairly useless for actual programming, but specifically in the case of guile -- as an embedded extension language -- I can see a valid usecase. That is: people copying, pasting and minimally modifying (configuration) snippets they found somewhere, without having to think about syntax or programming.
It's a mistake to ignore the customer Posted Dec 5, 2012 20:12 UTC (Wed) by david.a.wheeler (guest, #72896) [Link] Poster says: It is a common mistake to confuse "what they ask for" with "what they want..." Sure, but it is an even more common mistake to ignore repeated, strongly-stated requests from many customers. Eventually customers will move on to someone who listens to them instead. Which is what's happened to Scheme, Common Lisp, and so on; few people use them for serious new projects. After all, even 1K BASICs manage to support infix. A good designer provides what the customer wants, perhaps not exactly what they asked for, but that's because the designer deeply figures out what the customer *really* wanted and provides it. That's not the case at all here; software developers know very well what infix looks like. (- (* a b) c) is not infix. When they say, "I want/miss infix", saying "Lisp executes with prefix notation" doesn't deal with their request at all. if the requirement is "a language designed around infix notation", the answer is not Scheme.". In other words, Scheme fails to meet most developers' minimum requirements for a "practical" language. To me, that statement describes a *problem*, not something good or fundamental. The curly-infix notation fixes an old, well-known bug. I'd add that no language is "designed around infix notation" - infix is typically a small surface syntax issue. You cannot say "Scheme's design means it is not possible to add infix", because it has been done. It's true that past infix approaches lost Scheme's homoiconicity and generality, which is part of why they haven't been accepted. But curly-infix doesn't have those problems, so that argument is gone. "We've never solved that problem before" is not a good argument for ignoring a problem. I think we'll just have to agree to disagree on this.
It's a mistake to ignore the customer Posted Dec 6, 2012 0:28 UTC (Thu) by dvdeug (subscriber, #10998) [Link]
I don't understand the problem this is trying to fix. Is there really a huge audience of people who would wrap their minds around Scheme if only it supported an infix notation? The illusion that this is an infix language is going to disappear the instant you have to look at anyone else's code, even the most trivial. If you have to look up something in a manual, any non-trivial example will force you to figure out the original syntax.
The Bourne shell code uses the C preprocessor to look like Algol 68. I don't believe anyone who had to maintain it was amused.
I don't know that most developers care about superficial syntax when they're looking for a practical language. (And if so, you're completely misusing brackets there, as they aren't being used like in C.)
It's a mistake to ignore the customer Posted Dec 6, 2012 15:18 UTC (Thu) by david.a.wheeler (guest, #72896) [Link] First, a few quotes:
Now a few replies...
The illusion that this is an infix language is going to disappear the instant you have to look at anyone else's code, even the most trivial. There is no such thing as an "infix language". There are simply programming languages, nearly all of which allow the use of infix notation. Internally many language implementations store constructs in some sort of abstract syntax tree; does that make them "abstract syntax tree languages"? Is there really a huge audience of people who would wrap their minds around Scheme if only it supported an infix notation? I would argue the other way. There is a huge audience of people who will never consider Scheme seriously as long as it fails to support notation that 1K BASICs manage. And it's not just for "outsiders"; as noted above, some current LISPers want to use infix too.
If you have to look up something in a manual, any non-trivial example will force you to figure out the original syntax. There is no "figuring out"; I expect developers to learn the underlying traditional Lisp notation, and then learn that there's a new abbreviation for some common cases. Scheme developers already need to know other abbreviations to be effective. For example, 'x means (quote x). Are you suggesting that developers cannot follow code in a manual if it says (quote x)? Curly-infix is just another abbreviation. Python developers actually have to learn many more abbreviations, by the way; there's no evidence that this short ruleset causes any hardship. I don't know that most developers care about superficial syntax when they're looking for a practical language. I think you're wrong on this point. I think most developers do care about surface syntax. Surface syntax matters, because you have to read a lot of code when developing. If the code is hard to read, you won't want to do it. Python has caught on in many places precisely because it has good "superficial" syntax. By the way, "superficial" is misleading; it's actually tricky to create really good surface syntax. If you didn't care about superficial syntax, why are you complaining about curly-infix? It is, fundamentally, a surface syntax. Lisp fails many users and potential users because its syntax ossified in the late 1950s / early 1960s. Even its original developer (McCarthy) thought Lisp notation had many problems as a programming notation. It's been over 50 years... it's time to fix its most well-known problems.
It's a mistake to ignore the customer Posted Dec 6, 2012 19:39 UTC (Thu) by dvdeug (subscriber, #10998) [Link]
You're adding syntactical complexity. You keep referring to Python, which has a rule "There should be one--and preferably only one--obvious way to do it." It's not going to make it make it any easier to read existing code, nor access existing Scheme books or tutorials.
"There is a huge audience of people who will never consider Scheme seriously as long as it fails to support notation that 1K BASICs manage." is hard to take seriously. For one, where's my PEEKs and POKEs? For another, it's said so many times; if we just added this feature, everyone would jump all over our tool. Changing (+ 4 7) to {4 + 7} is not going change anything for most people.
If you really think that it will be useful to existing programmers, then perhaps it will be a useful feature, but it's tacking on additional duplicate syntax, not fundamentally fixing any problems.
It's a mistake to ignore the customer Posted Dec 7, 2012 15:01 UTC (Fri) by david.a.wheeler (guest, #72896) [Link] Poster said: You're adding syntactical complexity. You keep referring to Python, which has a rule "There should be one--and preferably only one--obvious way to do it." Is 'x okay? After all, that's just a syntactic complexity for (quote x). I'm proposing another abbreviation for a common case. Funny you should mention Python. Python, of course, already has two representations for arithmetic operations, prefix and infix, if you want to create types that support infix operators. The Python infix operators are simply an abbreviation for the prefix operators, when you use them this way, e.g., infix "+" is an abbreviation for "__add__". See the Python special names for more. Many people are unaware that Python supports prefix notation in this case, because the infix notation is what users expect and want to use.
It's a mistake to ignore the customer Posted Dec 7, 2012 19:52 UTC (Fri) by dvdeug (subscriber, #10998) [Link]
And personally I think it's an inelegance that quote exists at all.
I think you're misstating the cause; the people who are unaware that Python supports prefix notation in this case are unaware because it's obscure and rarely used outside operator overloading, which is in part because __add__ is seriously more clunky then +. If the notation were + (a, b) and a __add__ b then people would use the prefix notation more. Moreover, people being unaware of the prefix notation means there's for most purposes only one notation, with __add__ and friends existing solely for operator overloading. (It would have been more elegant to extend the characters available for function names.) You're setting up two competing syntaxes, and the arguably more friendly one is not the one used for 35 years in Scheme and since the dawn of time in Lisp. Either the new one will see little to no use, or both will be used.
It's a mistake to ignore the customer Posted Dec 10, 2012 2:22 UTC (Mon) by david.a.wheeler (guest, #72896) [Link] Poster said: personally I think it's an inelegance that quote exists at all. I think that is an extremely small minority position. I think most people are happy to have abbreviations for common situations.
If the notation were + (a, b) and a __add__ b then people would use the prefix notation more. Actually, I think people just wouldn't use the language at all, if those were your only options. I believe that for many developers, infix using symbols like "+" is a "bare minimum" requirement for a programming language. It matters how code looks, it really does. You're setting up two competing syntaxes, and the arguably more friendly one is not the one used for 35 years in Scheme and since the dawn of time in Lisp. Either the new one will see little to no use, or both will be used. If a notation is more friendly, why should people object to it? My hope is that both will be used, and that isn't a problem. People see (quote x) and 'x all the time, it hasn't hurt them.
It's a mistake to ignore the customer Posted Dec 12, 2012 13:09 UTC (Wed) by HelloWorld (guest, #56129) [Link]
> If the notation were + (a, b) and a __add__ b then people would use the prefix notation more.
Bollocks. In Haskell, you can use (+) a b instead of a + b, but nobody actually does that. The only reason the (+) syntax exists is to make it possible to pass + to a higher-order function.
It's a mistake to ignore the customer Posted Dec 13, 2012 1:19 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
Right, but it's closer to the question: Given:
> (+) a b
and
> a `add` b
as the "only" options, which would be more popular?
It's a mistake to ignore the customer Posted Dec 13, 2012 1:29 UTC (Thu) by mpr22 (subscriber, #60784) [Link] I'd go for option (c) Find the person who is requiring me to use this language clearly designed by either a parodist or a malicious idiot, and require them to explain to me in less than 150 syllables why I have to put up with it.
It's a mistake to ignore the customer Posted Dec 13, 2012 1:36 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
Ah, yes. I forgot that option :) . That's how I feel with the class/method names people tend to use in Java… Biggest thing it's missing is a "typedef" equivalent, IMO.
It's a mistake to ignore the customer Posted Dec 13, 2012 21:17 UTC (Thu) by mirabilos (subscriber, #84359) [Link]
Urgh. U+0060 should never be used. It should really have been a combining character, but ASCII doesn’t really have them. See also: http://www.cl.cam.ac.uk/~mgk25/ucs/apostrophe.html
It's a mistake to ignore the customer Posted Dec 12, 2012 13:56 UTC (Wed) by mpr22 (subscriber, #60784) [Link] If the notation were + (a, b) and a __add__ b then people would use the prefix notation more. Fortunately, programming languages seldom (INTERCAL doesn't count, being a parody) display such high levels of overt malice in their design, and such an arrangement could not (at least in our world where infix notation arithmetic is the norm) plausibly be the product of mere stupidity or laziness.
More quotes showing that readable syntax matters Posted Dec 6, 2012 16:05 UTC (Thu) by david.a.wheeler (guest, #72896) [Link] Here are some more relevant quotes showing that surface syntax matters to developers:
It's a mistake to ignore the customer Posted Dec 6, 2012 15:21 UTC (Thu) by jezuch (subscriber, #52988) [Link]
> After all, even 1K BASICs manage to support infix.
What I don't understand is why infix is so important. The only advantage of it I can think of is familiarity; in all other respects it's inferior to prefix and suffix notations. IMVHO, of course, but I think this opinion has a solid basis in reality ;)
It's a mistake to ignore the customer Posted Dec 6, 2012 16:10 UTC (Thu) by renox (subscriber, #23785) [Link]
> The only advantage of it I can think of is familiarity; in all other respects it's inferior to prefix and suffix notations.
I agree but familiarity is very important.
Nimrod ( http://nimrod-code.org ) is a bit like this: it has no postfix operators, only prefix and infix.
It's a mistake to ignore the customer Posted Dec 6, 2012 16:28 UTC (Thu) by david.a.wheeler (guest, #72896) [Link] The only advantage of (infix) I can think of is familiarity Yes, the only advantage of infix is that nearly all educated people spend 10 to 18 years in school using infix for all arithmetic work. People who do more math-related things (e.g., programming) tend to have even more experience using infix notations than the average person. Practically all math texts (where you might get useful algorithms) use infix, too. If people spent 10 to 18 years in school exclusively using prefix or postfix instead of infix, and nearly all books used prefix or postfix, they would prefer prefix or postfix instead. But this is not reality. Are you going to change all schools and math books, worldwide, to use infix? No? Infix is not going away. And most humans do prefer the familiar. A programming language is not just for the computer, it's also for the humans. Humans can learn to use prefix, but most humans prefer to use a notation similar to what they've used for 10 or more years. The Fortran developers figured out how to do infix years ago, it's time for Lisp implementations to catch up to the first version of Fortran :-).
It's a mistake to ignore the customer Posted Dec 6, 2012 21:50 UTC (Thu) by dakas (guest, #88146) [Link] Yes, the only advantage of infix is that nearly all educated people spend 10 to 18 years in school using infix for all arithmetic work. People who do more math-related things (e.g., programming) tend to have even more experience using infix notations than the average person. Practically all math texts (where you might get useful algorithms) use infix, too. If people spent 10 to 18 years in school exclusively using prefix or postfix instead of infix, and nearly all books used prefix or postfix, they would prefer prefix or postfix instead. But this is not reality.The reality is that the most popular calculators for engineers have been HP for decades, postfix. According to your rationale, that should have been impossible. Have HP ignored their customers?
It's a mistake to ignore the customer Posted Dec 7, 2012 5:43 UTC (Fri) by bronson (subscriber, #4806) [Link]
You clearly haven't seen calculator sales this decade or last. TI and Casio have absolutely crushed HP. Both are infix. Coincidence? (maybe, who knows...?)
Don't get me wrong, my HP 48 and RPN rocketed me through 4 years of EE. But most of the other pre-Es in my classes used TI-8x and Casio FX-xxx, I assume partly because they didn't require a tutorial to do the simplest things.
So, be careful rolling out the "most popular among X" argument. Not surprisingly, that almost always supports the infix crowd.
HP calculators Posted Dec 7, 2012 15:05 UTC (Fri) by david.a.wheeler (guest, #72896) [Link]
I have an HP calculator that uses RPN. I love it.
However, almost no one else I know of can even USE it, nor are they interested in learning how. If I offered the calculator to them, they'd say no thank you, and get a calculator that supports infix instead. Most people will immediately reject something that doesn't support infix today.
It's time to support modern expectations.
It's a mistake to ignore the customer Posted Dec 6, 2012 17:18 UTC (Thu) by etienne (subscriber, #25256) [Link]
> The only advantage of [infix] I can think of is familiarity
Just to add that the main disadvantage of infix is that you have to introduce operator precedence - and having "*" priority higher than "-" but only when "*" is used as multiply (and not content-of) and only when "-" is the substraction operator (and not a negative number).
It's a mistake to ignore the customer Posted Dec 6, 2012 18:27 UTC (Thu) by vonbrand (subscriber, #4458) [Link] "Precedence" is a red herring: The precedence of +-*/ is fixed, you can easily place "all others" in one (or two) categories). Yes, C went overboard with its 13 levels; APL went overboard the other way (all operators left associative with the same precedence). Come on, parsing infix (precedence and all) is ridiculously easy. A nice, top-down parser for C is described in Fraser and Hanson's book on LCC.
It's a mistake to ignore the customer Posted Dec 7, 2012 7:23 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
I like Haskell's solution: custom defined operators with 10 available precedence levels (I forget exactly, but I remember 10) with the "standard" ones spaced out along it.
It's a mistake to ignore the customer Posted Dec 7, 2012 9:39 UTC (Fri) by ekj (guest, #1524) [Link]
Isn't that terribly hard to read ?
How do you know what will happen with:
a + b [custom] c * d
Means:
(a+b) [custom] (c * d)
Or:
((a+b) [custom] c) * d
Or:
a + (b [custom] c) * d
It's a mistake to ignore the customer Posted Dec 7, 2012 16:18 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
Generally, the operators don't work just on numbers and so they don't mix much with the common ones much. Its to establish order within a class of operators (e.g., within the monad operators, arrow operators, and so on). If mathematical expressions tend to get passed in to them, make them lower precedence, otherwise you can play with the higher ones.
It's a mistake to ignore the customer Posted Dec 7, 2012 10:12 UTC (Fri) by etienne (subscriber, #25256) [Link]
> Come on, parsing infix (precedence and all) is ridiculously easy.
It is not the parsing which is a problem, it is the description of functions.
I do not see how you can define a single and simple function type when you use infix, so that in a complex class tree you can derive a class and replace a random function with a simple "addition" or "greater_than". Maybe define a priority for each and every functions? Can this priority change at run-time? at instantiation time?
Note that I am using infix for my programming, so I deal with it...
It's a mistake to ignore the customer Posted Dec 6, 2012 20:37 UTC (Thu) by neilbrown (subscriber, #359) [Link]
> Just to add that the main disadvantage of infix is that you have to introduce operator precedence
I was thinking exactly the reverse - a significant *advantage* of infix is that it allows the use of precedence to reduce bracket-noise.
Some care is needed in choose the precedence levels of course but it isn't hard if you apply care.
I really do not want to try to write (let along read)
if a + 2 < b*3+1 and c & 4 == 4
in anything but precedence-aware infix notation.
It's a mistake to ignore the customer Posted Dec 6, 2012 22:08 UTC (Thu) by dakas (guest, #88146) [Link] I really do not want to try to write (let along read)Thanks for proving how problematic infix can be. That example does not look like you are aware that == has higher precedence than &. So you are arguing for something beyond your capabilities. How would it look in Scheme as presumably intended?if a + 2 < b*3+1 and c & 4 == 4in anything but precedence-aware infix notation.
(if (and (< (+ a 2)
(+ (* b 3) 1))
(= (logand c 4) 4))
...)
It's a mistake to ignore the customer Posted Dec 6, 2012 22:22 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Thanks for pointing out stupidity of prefix syntax with your wonderful example of a one-liner turning into 5-liner.
It's a mistake to ignore the customer Posted Dec 6, 2012 22:48 UTC (Thu) by dakas (guest, #88146) [Link]
It is a 4-liner, and the material corresponding to the one-liner takes 3 lines. If mathematicians preferred minimal line count above readable grouping, why would they use fractions rather than in-line divisions?
It's a mistake to ignore the customer Posted Dec 6, 2012 23:09 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Because paper is a bit different medium and by using vertical layout it's possible to present information more efficiently?
It's a mistake to ignore the customer Posted Dec 6, 2012 23:54 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
> (if (and (< (+ a 2) (+ (* b 3) 1)) (= (logand c 4) 4)) ...)
> if (a + 2 < b * 3 + 1 && (c & 4) == 4) {...}
At 56 characters, not counting the ellipsis, the Scheme example fits easily into one line. Personally, I would probably have split it across two lines in either language, but to each his own. Granted, the corrected C version is only 42 characters, but that is offset by the need to remember the precedence of each operator, and you just demonstrated how difficult that can be. The fully parenthesized C version
> if (((a + 2) < ((b * 3) + 1)) && ((c & 4) == 4)) {...}
is 52 characters, which isn't much shorter (or more readable) than the Scheme code.
It's a mistake to ignore the customer Posted Dec 7, 2012 0:08 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
Nobody writes 2*3+1 as (2*3)+1 - everybody remembers THAT precedence rule.
So we realistically have: "if ((a+2 < b*3+1) && ((c&4) == 4)))" or 27 non-whitespace symbols. That's more compact and easier to understand.
And most people remember precedence rules of logical operators, so we have: "if (a+2 < b*3+1 && (c&4) == 4)" or 23 symbols.
Also, infix order has nice feature - it allows me to group relevant operations with whitespaces, with little "graphical" overhead.
It's a mistake to ignore the customer Posted Dec 8, 2012 9:57 UTC (Sat) by nix (subscriber, #2304) [Link] everybody remembers THAT precedence ruleI have fixed multiple bugs over the years caused by people thinking that + had higher precedence than *, or that C was strict left- or even right-associative. Yes, anyone with half a clue knows otherwise: but not every developer, alas, has half a clue to spare.
It's a mistake to ignore the customer Posted Dec 8, 2012 13:51 UTC (Sat) by paulj (subscriber, #341) [Link]
Also, clue level can vary significantly, even with a fixed, given programmer. E.g. regular diurnal patterns (pre-coffee, post-lunch, pre-knocking-off-time), when extremely tired at the end of a too-long hacking session, or even programming while drunk. :)
It's a mistake to ignore the customer Posted Dec 12, 2012 13:45 UTC (Wed) by HelloWorld (guest, #56129) [Link]
The solution to that isn't dumbing down the language but firing people who don't have half a clue.
It's a mistake to ignore the customer Posted Dec 13, 2012 11:39 UTC (Thu) by dakas (guest, #88146) [Link] The solution to that isn't dumbing down the language but firing people who don't have half a clue.Scheme is the ultimately dumbed-down language for the computer, to the degree that it does not require a parser for interpreting, just an expression reader and an evaluator. It is similarly dumbed-down to the human reader as commerce/Pidgin English is, meaning that it takes practice and control to consistently dumb down in the right manner. The purpose is having a common language for talking about programs shared between human and computer. Using infix in Scheme is like Yodish Pidgin English. Sort of defeats the original purpose of human and computer sharing a language for talking about code rather than humans expressing themselves to one another.
It's a mistake to ignore the customer Posted Dec 13, 2012 11:55 UTC (Thu) by mpr22 (subscriber, #60784) [Link] What a wonderful instance of "Humans can do the work, so machines have time to think."
It's a mistake to ignore the customer Posted Dec 13, 2012 17:26 UTC (Thu) by HelloWorld (guest, #56129) [Link]
> Scheme is the ultimately dumbed-down language for the computer,
No, it's not. As you were told multiple times by now, Scheme already has syntactic sugar for multiple constructs. 'x is (quote x), and (quote x) is (quote . (x . ())).
> Using infix in Scheme is like Yodish Pidgin English. Sort of defeats the original purpose of human and computer sharing a language for talking about code rather than humans expressing themselves to one another.
It's a mistake to ignore the customer Posted Dec 13, 2012 18:38 UTC (Thu) by viro (subscriber, #7872) [Link]
Not quite. The problem, in a sense, is that the structure chosen for representing program makes sense for optimizing interpreter a bit, at the cost of being very unnatural. Subtrees are not subexpressions. Sure, that way you avoid digging in to find the node where you'll be doing reduction, but that doesn't come for free. As the matter of fact (and you damn well know that, seeing that you seem to be familiar with e.g. Haskell), the things can be done the other way round - with APPLY being the fundamental primitive and CONS expressed via it. The same "easily represent program in the language's primary data structure" thing holds for a lot more than just LISP, e.g. when the primary data structure *is* partially evaluated expression. That's not what makes LISP LISP; neither is the syntax, of course.
It's a mistake to ignore the customer Posted Dec 7, 2012 0:22 UTC (Fri) by neilbrown (subscriber, #359) [Link]
> That example does not look like you are aware that == has higher precedence than &.
Sorry, but what language did you think I was using? Given that I used "and" and did not include () around the condition of the 'if', it certainly wasn't C. (It is missing a ':' at the end - sorry about that).
Much as I like C, it clearly got some precedence issues wrong. More modern languages do a much better job.
It's a mistake to ignore the customer Posted Dec 7, 2012 7:21 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
To be fair, there is a define for 'and' to '&&' in commonly included C headers (I forget which exactly). And since there's LISP floating around, parentheses sort of fade into the background after enough programming in it, so the error(s) made aren't completely obvious. The colon probably would have helped :) .
C alternative tokens Posted Dec 7, 2012 16:42 UTC (Fri) by dtlin (✭ supporter ✭, #36537) [Link] #include <iso646.h>defines macros for C. They're in C++ by default.
Precedence Posted Dec 7, 2012 17:16 UTC (Fri) by david.a.wheeler (guest, #72896) [Link] Poster said: Just to add that the main disadvantage of infix is that you have to introduce operator precedence No you don't. Infix means the operator is between the operands, that's all. Precedence can a lot of create problems, and the SRFI-105 has a very simple solution: No built-in precedence. You can still have precedence, though. If you use multiple operations that require precedence, the whole expression is changed to "($nfx$ ...)". You can then define "$nfx$" to do whatever you want. SRFI-105 contains a detailed rationale about its approach to precedence. In practice, {3 - {4 * 5}} isn't hard to read at all, and sure beats (- 3 (* 4 5)).
It's a mistake to ignore the customer Posted Dec 6, 2012 18:33 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
> What I don't understand is why infix is so important. The only advantage of it I can think of is familiarity
this attitude (that familiarity doesn't matter) is a major problem infecting current Linux userspace development. Gnome, Systemd, Unity, Wayland, (KDE4 to a much lesser degree) are all doing things that assume that familiarity with the existing stuff doesn't matter and that anyone who objects is just a stick-in-the-mud who needs to get with the times.
It's hard to overstate the value of familiarity. Even if the existing tools are inefficient, if they are familiar to people, it can be really bad to change them.
outside of software, one common example is the DORVAK vs QWERTY keyboard debate. Some people argue that DORVAK is significantly better (I'm not one of them by the way), but QWERTY remains dominant, even in things like phone on-screen keyboards, for the simple reason that it's familiar to people.
It's a mistake to ignore the customer Posted Dec 7, 2012 17:48 UTC (Fri) by sorpigal (subscriber, #36106) [Link]
Familiarity is a huge advantage that ought to outweigh almost anything. If, in the end, you have to spend a lot of time to understand how to write what you want, more time to read what you have written and even more time to read what someone else wrote, then you have consumed enormous amounts of time that could have been spent doing the actual work of telling the computer what to do. The time and attention of a developer is the single most valuable resource when developing just about any software today. Anything which decreases the amount of time it takes to understand a piece of code (whether writing or reading) increases productivity, all else being equal. It adds up.
maybe not only familiarity Posted Dec 7, 2012 20:57 UTC (Fri) by tpo (subscriber, #25713) [Link]
People in support of infix in this thread are using "familiarity" as an argument whereas critics are arguing that infix is *one* aspect of the Scheme language that you have to familiarise yourself with.
I'd like to propose that infix (maybe as well as prefix) as a way of thinking and understanding may be rooted in the human brain itself.
I've just read the "DCI manifesto" on Artima, where the authors are arguing that humans are understanding in terms of things and behaviors. Consequently they propose to model "things" and "behaviors" separately.
As a functional language Scheme would be on the outmost "behavior" side of the possible spectrum. Under the above stated theory it would be a compliment to the human brain that it *is* able to manipulate a symbolic problem representation that is very much focused on only one side of "things and behaviors". On the other hand it would hint to why prefix notation is hard to handle for humans - it supposedly simply doesn't match the "natural" way a brain works.
I'm completely ignorant about that topic and respective research and as such could be completely wrong, however I think we should not stop our thinking at the relatively trivial "familiarity" argument but ask whether the problem could be rooted deeper than that.
[1] "The DCI Architecture: A New Vision of Object-Oriented Programming"
maybe not only familiarity Posted Dec 10, 2012 8:38 UTC (Mon) by jezuch (subscriber, #52988) [Link]
> On the other hand it would hint to why prefix notation is hard to handle for humans - it supposedly simply doesn't match the "natural" way a brain works.
At best it's hard to handle for speakers of SVO languages. It's like arguing that Arabic (a VSO language, equivalent to prefix notation) or Japanese (a SOV language, equivalent to suffix notation) are "hard to handle" and "don't match the natural way a brain works". Try telling that to the Arabs and Japanese ;)
maybe not only familiarity Posted Dec 10, 2012 9:24 UTC (Mon) by tpo (subscriber, #25713) [Link]
I'm not familiar with VSO languages: do they also, as Scheme does, put *all* verbs at the start of the sentence in case of nested statements? As in:
(do (another_do (yet_another_do (and_more_do (and_still_more_do arg arg
aka
verb1 verb2 verb3 verb4 verb5 subject1 object 1 subject2 object2 object2a
I honestly do not know, but I'd guess even a VSO language will not work that way as opposed to Lisp'ish languages?
maybe not only familiarity Posted Dec 10, 2012 17:06 UTC (Mon) by nybble41 (subscriber, #55106) [Link] Deeply nested expressions are a problem in any language, moreso in natural languages which are not traditionally formatted to highlight the subexpressions. If you find yourself writing such expressions in Scheme, you may want to look into refactoring the code, or at least taking advantage of the "nest" macro to flatten the expression. An example: (do arg1
(another_do
(yet_another_do
(and_more_do arg2
(and_still_more_do arg3 arg4)))))
is equivalent to: (nest [(do arg1)
(another-do)
(yet-another-do)
(and-more-do arg2)
(and-still-more-do arg3)]
arg4)
Curly-infix and readable Lisp Posted Dec 4, 2012 21:10 UTC (Tue) by HelloWorld (guest, #56129) [Link] and if you get the latter, it will be hard to figure the "flipping point" where #{ } will get used over normal list syntax in output, and where not.The sweeten tool does this already. It employs heuristics to decide questions like these. They aren't perfect, but what's the worst that could happen? You get a string representation of a data structure that isn't as nice as it could have been, so what? And frankly, things like (second '#{ 3 + 4 #}) => 3 and (cddr '#{ 3 + 4 + 5 #}) => (4 5) will not particularly facilitate understanding.Then don't write it that way. Besides, it's no more confusing than (car ''x) => quote
But conversion to infix is a different beast than converting a conventional arrangement of dotted pairs to list syntax.I don't see why.
Curly-infix and readable Lisp Posted Dec 5, 2012 8:26 UTC (Wed) by dakas (guest, #88146) [Link] The sweeten tool does this already. It employs heuristics to decide questions like these.Meaning that the output is not predictable and can change from version to version. They aren't perfect, but what's the worst that could happen? You get a string representation of a data structure that isn't as nice as it could have been, so what?You need to be fluid in two languages instead of just one and transparently deal with either output. The whole point of infix notation is to reduce the amount of thinking you need to invest. Now you need to be fluid in two representations and transparently translate back if sweeten decided to "infixify" a list that was not intended as an arithmetic expression, and vice versa. At any rate, I am just making predictions. The only one in a position to dispel them is Father Time. I suspect I have had him visiting more often than you did, but at any rate I'm willing to take what he will eventually have to say in that matter.
Curly-infix and readable Lisp Posted Dec 5, 2012 21:10 UTC (Wed) by david.a.wheeler (guest, #72896) [Link] dakas said: Meaning that the output is not predictable and can change from version to version. You have the incorrect belief that that Scheme output is currently predictable and cannot change from version to version. That is not true, of either the Scheme spec or its implementations. The Scheme specification R7RS draft 7 for "write" is "Writes a representation of obj to the given textual output port". Note that this is *a* representation, not *the* representation, as there are many possible representations without curly-infix. Similar text exists for R6RS (library section 8.2.12 on put-datum), and R5RS (section 6.6.3); it always says "a" not "the" and does not proscribe a particular representation. Different Scheme implementations do write the same list differently, too. Let's run the trivial program (write (read)) and give the program the input ''x (x quoted twice). The scsh version 0.6.7 implementation reports ''x, while guile version 1.8.7 reports (quote (quote x)) - obviously different from scsh. Since Scheme does not guarantee a particular format for a list - and permits implementations to use abbreviations when they choose - curly-infix represents no change in this matter. The "sweeten" heuristic is to write infix form if there are 3-6 parameters, and the operator is punctuation, "and", or "or". It's a longer heuristic, but it means that users can see {a > b} instead of (> a b), and a lot of users prefer the latter.
You need to be fluid in two languages instead of just one and transparently deal with either output. There is no "two languages". There is an underlying list notation, and a simple abbreviation that you can optionally use. Yes, you have to fluid in the two representations. Give it 10 minutes, you'll get it. At any rate, I am just making predictions. The only one in a position to dispel them is Father Time. I suspect I have had him visiting more often than you did, but at any rate I'm willing to take what he will eventually have to say in that matter. Here we agree!
(Typo fix) Posted Dec 5, 2012 21:20 UTC (Wed) by david.a.wheeler (guest, #72896) [Link]
s/a lot of users prefer the latter/a lot of users prefer infix/
Curly-infix and readable Lisp Posted Dec 6, 2012 20:12 UTC (Thu) by vonbrand (subscriber, #4458) [Link] In my experience, each time you try to please everyone, you end up with an angry mob.
Curly-infix and readable Lisp Posted Dec 6, 2012 22:11 UTC (Thu) by dakas (guest, #88146) [Link]
Which is probably saying more about humanity than Scheme, but so true.
Curly-infix and readable Lisp Posted Dec 3, 2012 22:51 UTC (Mon) by HelloWorld (guest, #56129) [Link]
Thank you for the project, I'm sure that this will make Lisp more accessible to the many many people who were put off by its syntax. Too bad Guile didn't adopt all your syntax improvements...
Don't worry - we're not done! Posted Dec 3, 2012 23:11 UTC (Mon) by david.a.wheeler (guest, #72896) [Link]
In Scheme, changes are more widely accepted if they are formalized into a SRFI specification. Curly-infix was only recently formalized into a SRFI; the final version was only released a month ago (2012-11-01). The plan is to get sweet-expressions defined in a SRFI, and then get that implemented everywhere (like guile) as well. Since sweet-expressions build on curly-infix expressions, the release of SRFI-105 and its implementation in guile are key steps to getting there.
Don't worry - we're not done! Posted Dec 4, 2012 1:46 UTC (Tue) by HelloWorld (guest, #56129) [Link] The code generated by the sweeten tool doesn't seem optimal yet though. For example,(defun foo (bar baz) ...) is rewritten into defun foo bar(baz) .... I think the natural way to write this would be
defun foo bar baz ...But maybe that's just me.
Sweeten results Posted Dec 4, 2012 14:19 UTC (Tue) by david.a.wheeler (guest, #72896) [Link] Since "sweeten" is a pretty-printer, there will always be cases where people will differ on what's "pretty". That said, suggestions to improve it are very welcome; my hope is that "sweeten" will make it easy for people to switch to sweet-expressions. So let's take a look. First of all, we both agree that the expression: (defun foo (bar baz) ...)can be rewritten either as: defun foo bar(baz)or as:
defun foo
bar baz
...
So, when sweeten rewrites existing code, what form *should* it prefer? I think this format is sensible when you see stuff like this: define cos1 cos(1)which is why I wrote the heuristic to do this. The current heuristic for determining if something should be in one line is (in this case) implemented in the "sweeten-top" function, as follows:
if { {length-asline < max-unit-character-length} and
fits-width?(indent-already indent length-asline) and
{general-length(m) < max-unit-list-length} }
....
Since:
define maxwidth 78 define max-unit-character-length 60 define max-unit-list-length 8The current "sweeten" does what it does. Feel free to suggest a better heuristic! For more discussions, please join the "readable" mailing list, where this sort of discussion takes place: http://readable.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Sweeten results Posted Dec 4, 2012 15:42 UTC (Tue) by HelloWorld (guest, #56129) [Link] Hi David,
For personal reasons, I don't want to sign up to the mailing list. Anyway, whether the defun foo bar(baz) ...syntax is that the first argument is outside of the parenthesis, while the following arguments are within, suggesting that the first argument is somehow different even though it really isn't. defun foo bar baz ...fixes that. There's also another way to write it: defun foo (bar baz) ...(I thought that would be rewritten into (defun (foo bar baz) ...) at first, but it actually works due to the space following foo).
My main point here is that the heuristic should special-case some forms. defun is one, another obvious one is lambda for the same reason.
I've modified "sweeten" per your suggestion Posted Dec 5, 2012 2:01 UTC (Wed) by david.a.wheeler (guest, #72896) [Link] HelloWorld said:... The problem with the
defun foo bar(baz)
...
syntax is that the first argument is outside of the parenthesis, while the following arguments are within, suggesting that the first argument is somehow different even though it really isn't. ... There's also another way to write it:
defun foo (bar baz)
...
My main point here is that the heuristic should special-case some forms. defun is one, another obvious one is lambda for the same reason. The "sweeten" tool actually already special-cases some forms, but since I use it more for Scheme than Common Lisp, its special-case form for "defun" wasn't all that great. Thanks for the feedback, that's a good point. I've modified "sweeten" in the development branch, it now handles "defun" specially and will output the format you suggested above. This change will get rolled into the next "official" release, but feel free to try it out now. Enjoy!
I've modified "sweeten" per your suggestion Posted Dec 5, 2012 2:06 UTC (Wed) by HelloWorld (guest, #56129) [Link]
I'm glad I could help.
doesn't work :( Posted Dec 5, 2012 11:09 UTC (Wed) by HelloWorld (guest, #56129) [Link] Hey David, I just checked out sweeten from the git repository on sourceforge, and I can't see the change.$ ./sweeten <<< '(defun foo (bar baz) ...)' defun foo bar(baz) ...The first parameter is still outside the parenthesis :(
It works - you need to check out the develop branch Posted Dec 5, 2012 19:42 UTC (Wed) by david.a.wheeler (guest, #72896) [Link] It works, you just need to check out the *develop* branch in the git repo, not the *master* branch. The master branch represents the currently-released version. Our workflow is described in http://sourceforge.net/p/readable/wiki/Workflow/ and is based on Vincent Driessen's "successful git branching model" workflow. I get: $ ./sweeten <<< '(defun foo (bar baz) ...)' defun foo (bar baz) bar baz ... Which I believe is what you wanted.
It works - you need to check out the develop branch Posted Dec 5, 2012 19:54 UTC (Wed) by HelloWorld (guest, #56129) [Link] Hi, OK, I got the master branch now.$ ./sweeten <<< '(defun foo (bar baz) ...)' defun foo (bar baz) bar baz ...Yes, that is what I get too, but... how does it make sense? The function arguments are there twice now. I'm not much of a Lisp person, but shouldn't it be either defun foo (bar baz) ...or defun foo bar baz ...?
Whups! Bug fixed Posted Dec 5, 2012 21:34 UTC (Wed) by david.a.wheeler (guest, #72896) [Link] how does it make sense? The technical answer is, "because I screwed up" :-). A copy-and-paste error on my part, sorry. I was so focused on getting the first line right that I didn't pay attention to the second line once I got the first line right. I guess I'm still human. I've fixed the bug and posted it on the git repo. I knew there was a reason to have a development branch :-).
GNU Guile 2.0.7 released Posted Dec 4, 2012 0:06 UTC (Tue) by Corkscrew (subscriber, #65853) [Link]
N00b question: under what circumstances would Guile be a useful language to learn?
Does the language have specific favoured use cases, in the same way that Javascript is "for" asynchronous processing or Lua is "for" embedded scripting? Or is it simply a soft point of entry into the mind-blowing world of Lisp?
GNU Guile 2.0.7 released Posted Dec 4, 2012 0:45 UTC (Tue) by krakensden (subscriber, #72039) [Link]
It's targeted at embedding, like Lua- perhaps "embedded scripting for people who like metaprogramming".
GNU Guile 2.0.7 released Posted Dec 4, 2012 8:55 UTC (Tue) by civodul (subscriber, #58311) [Link] Guile is not a language; it's primarily an implementation of the Scheme and Emacs Lisp languages, and also comes with a less mature ECMAscript (aka. JavaScript) front-end.Scheme itself is a neat language to learn and work with. The famous Structure and Interpretation of Computer Programs (SICP) is considered by many an excellent introduction to Scheme and programming in general.
GNU Guile 2.0.7 released Posted Dec 4, 2012 10:40 UTC (Tue) by dakas (guest, #88146) [Link]
It is the extension language for LilyPond and quite tightly interwoven with it, though both conceptual and data structure integration are an ongoing task and we have not yet managed migration to Guilev2 which would make some things easier in that regard.
In some respects, Guilev2 is a step backwards for the sake of being an extension language and a step forward for a general-purpose programming system, mainly because of its larger complexity, things like file-level byte-compilation, its more complex architecture.
Now what are comparison points with regard to Lua, possibly its largest contender?
a) Lua is minimalistic regarding its available data types and structures. It has 8 data types, one of which is opaque "user data", and one is its sole data structure, the table. There is only one numerical data type implemented as a double. This minimalism is actually an advantage for extension languages since it makes the mapping of language features to extension language features straightforward. string or symbol? Not a question: Lua interns _all_ strings at some performance impact, and so the principal feature of a symbol, constant time comparison and fixed hash code, is available with every string. Guile, in contrast, has basically a type for each purpose which makes for best utilization of machine resources regarding storage representation. It also offers more potential for performance improvement by compiling to machine code, though trace compilers (like luajit) can usually keep the code optimized for the typical use cases, recompiling when expectations are violated.
b) Lua is a procedural language, Guile is functional. This makes Lua more pleasant for imperative programming, but Guile more syntactically embeddable since there are no boundaries between "constant", "expression", "statement" and "program". If you have a mechanism for referring to a constant in the extension language, all the rest falls into place. Even the Lua command line interpreter recognizes this shortcoming and offers a shortcut "=" for evaluating and printing an expression.
c) Lua has a simple syntax for coding, Guile has no syntax for coding. Guile code is executed by reading a Scheme expression, typically a list, and evaluating it. Lists can be nested, and there is nothing like operator precedences or anything else needed for evaluating a list. That makes it less pleasant for humans to interact with Guile (like most LISP-like languages), and fabulous to have programs interact with Guile: the read syntax basically already delivers the "parse tree", while Lua can only evaluate strings. Even though its syntax is simple, you can't manipulate programs sensibly through text manipulations. Guile has a powerful macro and syntax transform system that can easily be adapted to a lot of tasks.
d) since Lua can only evaluate chunks from a string, something like evaluating user-provided material in lexical closure is not feasible (basically, you would have to splice the user-provided material into a source code string and recompile the whole function). Guile can work with lexical closure in a number of ways. Check out <URL:http://news.lilynet.net/?The-LilyPond-Report-27#a_kind_of...> for an example of tight interweaving of user-provided material and preexisting code, crossing the border between LilyPond interpreter and Guile interpreter back-and-forth without apparent effort.
e) Lua only has doubles as numerical types, Guile has a full numeric stack with integers (arbitrary size), rationals, floats, and by now also complex numbers. If you want to do symbolic computation or other "I don't want to bother with the sideeffects from approximative results" work, that's certainly a boon.
I am a big fan of Lua's minimalism, and Guilev2 is a step backward in effortless integration due to its file-level compilation and other growing pains. And while a LilyPond based on Lua as extension language would certainly have been a quite feasible project as well, using Guile as a Scheme-based extension language for LilyPond has made a conceptual and programmatic integration possible that is not easily rearchitectable to an imperative language. There is still a lot of open potential, and the other large GNU projects showcasing Guile as an extension language (GNUcash and TeXmacs) don't have, as far as I can tell, a similarly invasive integration of code and concepts, so their language choice appears a bit more arbitrary than that of LilyPond, and there are more voices for replacing it.
Both Guile and Lua have some mechanisms to "grow with you", but Guile is quite larger at the start, and Lua more focuses on keeping good relations with your project while letting it grow alone.
Probably one of the most interesting "afterthought" extension projects using Lua is LuaTeX. Guile is harder to tack onto an existing project after the fact, you better start designing with it from the start.
GNU Guile 2.0.7 released Posted Dec 4, 2012 10:58 UTC (Tue) by mpr22 (subscriber, #60784) [Link] (e) is somewhat inaccurate. While it's true that a given instance of Lua only has a single numeric type, and the default configuration uses double, you can recompile your particular instance of Lua to use some other numeric type if that's what your use case indicates.
GNU Guile 2.0.7 released Posted Dec 4, 2012 11:30 UTC (Tue) by dakas (guest, #88146) [Link]
I don't consider it inaccurate. Yes, you can recompile Lua to use a single other numerical type, typically integer, possibly even complex, because the source code uses a #define for this and has been carefully written to avoid mixing its number type with actual internal operations. That is considerate, but it does not give Lua a numerical stack but merely changes its single type, so you then forego the use of double.
And you need to recompile Lua for that, whereas you can just link with the standard libguile whatever your number requirements may be.
You can consider me a Lua fanboy, so if I mention a disadvantage in passing, it is rarely an advantage to dwell on it as I might have good reason for my opinion.
GNU Guile 2.0.7 released Posted Dec 4, 2012 18:45 UTC (Tue) by beagnach (guest, #32987) [Link]
Thank you for the detailed technical overview of the relative merits of these two languages. I wish more people commenting on technical issues would adopt a similarly thorough and mature approach.
GNU Guile 2.0.7 released Posted Dec 4, 2012 18:49 UTC (Tue) by atai (subscriber, #10977) [Link]
A disadvantage of Guile is that it should offer good support for minimalist use, to be able to compete with Lua in many scenarios. Having a full tower of numerical types is a good feature, but for applications like a bootloader do you need all the numerical types? Grub 2 uses Lua, if I remember correctly
GNU Guile 2.0.7 released Posted Dec 4, 2012 19:36 UTC (Tue) by dakas (guest, #88146) [Link]
Yes, Guile is not minimalistic, and Guilev2 is a further step away. In particular when you are not designing a system from scratch but just looking for a simple way to extend an existing system with some programmability not bringing a whole lot of its own complexity into the game, Lua might be a better choice. Guile is moving into the direction of a system foundation rather than a system extension. That is basically its positioning for getting into Emacs, and that is getting more and more the way in which it is integrated with LilyPond.
But it is not exactly the niche of "extension language" that it is mostly being advertised for.
GNU Guile 2.0.7 released Posted Dec 4, 2012 20:49 UTC (Tue) by HelloWorld (guest, #56129) [Link]
> Grub 2 uses Lua, if I remember correctly
You don't, Grub 2 has its own sh-like scripting language.
GNU Guile 2.0.7 released Posted Dec 4, 2012 23:53 UTC (Tue) by atai (subscriber, #10977) [Link]
OK I did some search. Grub 2 did use Lua for some time and later dropped it.
GNU Guile 2.0.7 released Posted Dec 5, 2012 19:14 UTC (Wed) by cjwatson (subscriber, #7322) [Link]
Not quite true either. It was never the default; and we still support it as a bolt-on extension from grub-extras. It's the sort of thing you might build in if you have particularly complex scripting needs. For most purposes, we'd rather focus on the sh-like "GRUB script".
Grub script Posted Dec 12, 2012 13:57 UTC (Wed) by HelloWorld (guest, #56129) [Link] By the way, is there a way to iterate over the files in a directory with that language? There seems to be no command substitution and it doesn't seem possible to loop over the result of a globbing expression either.
GNU Guile 2.0.7 released Posted Dec 6, 2012 1:13 UTC (Thu) by geofft (subscriber, #59789) [Link]
It's in grub-extras, but not part of the GRUB core (and as far as I know not in any distro packages):
GNU Guile 2.0.7 released Posted Dec 5, 2012 6:31 UTC (Wed) by khim (subscriber, #9252) [Link] The main competitor of Lua (which is used more often then Guile!) is python which is hardly minimalistic.
Nitpicking Posted Dec 5, 2012 9:53 UTC (Wed) by renox (subscriber, #23785) [Link]
> Having a full tower of numerical types is a good feature
Yes, if the "full tower" was actually full: I hate the term "full tower" when it is used on languages which only provides floating point to describe real number, if these languages were also providing floating point **ranges** then I would agree that this is a "full tower of numerical types".
Nitpicking Posted Dec 5, 2012 14:08 UTC (Wed) by dakas (guest, #88146) [Link]
Well, add modular types and Galois fields and/or polynomials into the mix as they also belong to a "full numeric stack".
With Guile, you can easily extend the numeric stack using GOOPS, its OO system. The main disadvantage with GOOPS is that it is so hopelessly generic, invasive, and flavorless that it provides no guidance for how to actually cast your OO task into concepts, and it is hard to guess just what kind of usage might get streamlined for speed, and what not.
Extending the numeric stack, however, is rather straightforward, and the GOOPS manual illustrates it by demonstrating how one would implement a complex type if it was not already there.
Nitpicking Posted Dec 5, 2012 14:20 UTC (Wed) by renox (subscriber, #23785) [Link]
> Well, add modular types and Galois fields and/or polynomials into the mix as they also belong to a "full numeric stack".
A numeric stack can never be full OK, but I wouldn't put on the same level "Galois fields"(whatever they are) and a proper representation of real numbers(*)!
*:which I don't consider normal floating point representation to be.
Nitpicking Posted Dec 5, 2012 16:26 UTC (Wed) by HelloWorld (guest, #56129) [Link]
So what would you consider a "proper" representation of real numbers, and what's wrong with floating point numbers?
Nitpicking Posted Dec 5, 2012 16:50 UTC (Wed) by renox (subscriber, #23785) [Link]
> So what would you consider a "proper" representation of real numbers, and what's wrong with floating point numbers?
I guess I should have been clearer in http://lwn.net/Articles/528065/ ..
Nitpicking Posted Dec 5, 2012 19:05 UTC (Wed) by HelloWorld (guest, #56129) [Link]
Oh, that's interesting, thank you.
Nitpicking Posted Dec 6, 2012 0:14 UTC (Thu) by khim (subscriber, #9252) [Link] It's not all that interesting because once you start going in this directions you can never stop. Quite often intervals are not enough (when you have something like x=0.1±0.2 suddenly 1/x becomes almost useless) and then variety of approaches are used (aforementioned Wikipedia article mentions quite a few of them). I fail to see why general-purpose language needs all that cruft: guile gives you rationals (which are suitable for most purposes) and when you need speed you can fall back to FPU-provided float (with appropriate price paid in loss of precision). If and when our CPUs will start providing intervals arithmetic in hardware it'll be useful to give access to these, too, but till then... interval arithmetic belongs to the same bucket Galois fields and/or polynomials.
Nitpicking Posted Dec 6, 2012 8:42 UTC (Thu) by renox (subscriber, #23785) [Link]
> It's not all that interesting because once you start going in this directions you can never stop. Quite often intervals are not enough
This is the opposite IMHO, most of the time the precision you have with floating point is good enough, that's why nobody care about intervals, but without intervals when (very rarely) you have a precision issue, you don't notice it which can be very problematic as in your example if you're trying to do 1/x on x=0.1+-0.2 with floating points you have the result 10 and you're (mistakenly) happy, with intervals you can see that there is an issue.
Of course, the discussions about interval arithmetic talk about the potential issues of interval arithmetic where your computation are precise enough but the interval is too big (because you wrote x*x instead of x^2 for example), this doesn't mean that this happen often..
> guile gives you rationals (which are suitable for most purposes)
As for CPU speed, I'm not sure that for common operation (+,-,*,/) floating point ranges are much slower than rationals (on x86s which have powerful CPUs)..
Nitpicking Posted Dec 8, 2012 17:10 UTC (Sat) by khim (subscriber, #9252) [Link] As for CPU speed, I'm not sure that for common operation (+,-,*,/) floating point ranges are much slower than rationals (on x86s which have powerful CPUs).. It's not about speed. It's about exact calculations vs nonexact calculations (non-coincidentally "exact" is property of a number in scheme and thus guile). Arbitrary-precision rationals are top-of-the-pyramid for the exact calculations. As for inexact ones... they will always be non-exact and you can build whatever you want on top of what CPU (and guile) is offering. The fact that recent versions of both AMD and Intel CPUs added support for half-precision (16bit!) floating point numbers should say you something about this whole business. Exact calculations may be true or not - and guile gives you everything you need for these. Inexact calculations are always approximation and there are bazillion ways to do that approximation thus guile's approach to give you FPU-provided primitives and nothing else looks sensible. You may extend the tower using GOOPS in any direction you want. Unless you want to use "rare" things such as square root, logarithms, exponentials, cos/sin, etc? Indeed. All these things are extremely rare. What you need relatively often is rounded up (or sometimes down) square root, rounded up (or sometimes down) logarithm, etc. Floating points are usually enough for that. This is the opposite IMHO, most of the time the precision you have with floating point is good enough, that's why nobody care about intervals, but without intervals when (very rarely) you have a precision issue, you don't notice it which can be very problematic as in your example if you're trying to do 1/x on x=0.1+-0.2 with floating points you have the result 10 and you're (mistakenly) happy, with intervals you can see that there is an issue. And what can you do with your numbers at this point? The answer: usually nothing. You may be surprised but programs which produce useful result 99% of time but some nonsense 1% of time are preferred by users to programs which produce useful result 90% of time and refuse to even run 10% of time. Even if such programs never produce incorrect result. Of course, the discussions about interval arithmetic talk about the potential issues of interval arithmetic where your computation are precise enough but the interval is too big (because you wrote x*x instead of x^2 for example), this doesn't mean that this happen often.. This is wrong measure. Most of the time interval arithmetic and plain old IEEE arithmetic give you more-or-less the same answer. But in cases where interval arithmetic says that there are no useful result more often then not it's wrong. Why? Because numbers which you receive from real life don't adhere to the intervals idea! When you get something like 0.1±0.2 as an input usually it means that it's probably 0.1±0.05, but if stars were all aligned incorrectly when measurement took place and all possible sources of errors materialized at once it may become 0.3 or -0.1. IEEE will give you x=10 and most of the time it'll be good enough (because you don't really exploit all your systems at close to 100% of capacity and often spare power is quite large) so you'll be able to cope with 20 or 30, too. Intervals will give you the answer: "wrong input data" and you'll be forced to revamp the whole model. Interval arithmetic if not used everywhere and is not supported by FPUs for a reason. P.S. Funny that you mentioned
Embedding vs. extending Posted Dec 5, 2012 0:16 UTC (Wed) by civodul (subscriber, #58311) [Link] Note that it is often more fruitful to extend Guile (or Python, or ...), than to embed it. See this section of Guile's manual, and this article about Python for some discussion.
Embedding vs. extending Posted Dec 6, 2012 20:48 UTC (Thu) by dvdeug (subscriber, #10998) [Link]
The discussions don't seem to target my issues at all. When I'm thinking of embedding a language, it's because I have a program that I would like for people to be able to extend; say a graphics program that people want an easy way to write plugins for, or a game that people want to write AIs for. I may well want for certain environments to be able to not compile in a 3MB Python interpreter. The Python one asks "do you want your application to inter-operate with other applications that Python can use?" Why would I? I'm not building a library here; why is it vitally important that Gimp and Quake can run at the same time?
Embedding vs. extending Posted Dec 6, 2012 21:19 UTC (Thu) by andrel (subscriber, #5166) [Link]
Well if your goal is to automate a pipeline which starts with a Quake screenshot and process it in GIMP to get the final output, then yes you want them both running at the same time.
Embedding vs. extending Posted Dec 6, 2012 23:16 UTC (Thu) by dvdeug (subscriber, #10998) [Link]
Why? You produce the screenshot, and send it through the pipeline and send it into GIMP. No need to bring everything into one process.
|
|||||||||||||||||||