Re: [Readable-discuss] Readable Lisp 2.0, brainstorming
On Mon, 20 Feb 2017 15:36:22 -0600, luke wallace
wrote:
> Here's a similar but slightly different prototype
>
> https://i.imgur.com/vApN1Yt.png
Quick nitpick - please use these terms:
() - parentheses
[] - (square) brackets
{} - (curly) braces
I realize that some people call *all* of the paired characters "brackets",
but since we have to talk about paired characters often around here, it's
helpful to be very precise about these terms :-).
> This prototype uses a flatter version of tables, and much more 'magic'
> would have to be programmed into the editor
> cells shaded grey are prefix-comments, in this case, for the function
> 'define'.
There are bit minuses to this. This assumes that the editor
"knows" what terms like 'define' and '<=' and 'if' mean.
I imagine there are some uses for it, primarily if you use Lisp
exactly the same way as you'd use a fixed-syntax language like Java.
But fixed-syntax languages are going to be much better at being themselves
than a Lisp ever could. If you need a fixed-syntax language, there are
over a hundred of them. A key advantage to Lisp is that you can
embed many different languages & can trivially create your own.
Mini-languages abound! There's no particular reason that "<=" or "define"
would have the same meaning each time even within one line,
and there's no way an editor could determine the meaning in general
(it would have to recursively expand macros across all files,
and even then, there's no mechanism for capturing this information in general).
That said, *displaying* boxes is a good idea. I think it's been done before,
but it's fair to point out that modern systems make this *much* easier and
more practical. And you don't need *any* magic to display the boxes.
So, when will you be implementing a prototype :-) ?
--- David A. Wheeler
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Readable Lisp 2.0, brainstorming
On Mon, 20 Feb 2017 11:47:35 -0600, luke wallace
wrote:
> Here is my new idea for an ideal lisp authoring format, which relies on an
> html/css/js editor using pretty components around source lisp code. Source
> lisp code is still saved as a text file, but is, upon loading into this
> theoretical editor, "pretty formatted" as shown in the image below.
Very interesting. Even if it's not used for editing, I can imagine something
like this as the output of a pretty-printing process.
I wonder about *editing* while doing this, though.
Perhaps entering "(" would automatically add a closing ")",
show the box (if not preceded by whitespace), and move the user inside.
> Inside this editor, creating parentheses in the right context would instead
> create nested table cells as shown in the image. Instead of working with
> parentheses, newbies might find it easier to look at tables like this...
Newbies don't stay newbies. I'd like to think that any "readable Lisp"
would be just as useful to experts as to newbies. Experts have to read
a lot of code... making their lives easier is a good idea too :-).
> Using more html/css/js magic, it would be possible in such an editor to do
> things like display a tooltip when a user hovered over recognized symbols
> such as <= in the image. The tooltip could display an explanatory message
> like "less than or equal to". While experienced programmers may not need
> the <= symbol explained to them, by explaining every symbol, it should
> become even more readable in the editor.
One challenge is that "<=" doesn't have a fixed meaning; it might mean the
underlying Lisp implementation, or the meaning of "<=" as redefined in
some other language you're defining there.
> In this prototype image, the parentheses are shown as square table cells,
> but they could be rounded, given line width, background colors, or change
> colors on mouse-hover, keyboard focus, or when using a debugger to step
> through code line by line (indicating what portion of the table is being
> evaluated) etc. The possibilities are endless if we step out of the
> shackles of needing to see source code as the language dictates it.
Sure. You need to be cafeful, though; bugs are easy to hide if the developer
can't easily "see" what the code actually *is*. I think experimentation would
be necessary.
This probably wouldn't be too hard to prototype in an editor - I'd love to hear
if you give it a try.
--- David A. Wheeler
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] using sweeten with newlisp
>I suppose I could define a function that swaps the first 2 arguments
>then
>evaluates. In newlisp, this won't cause any slowdown.
Curly-infix does a little more than that. Feel free to steal its code, it is
under the MIT license.
If there are only three arguments, then it does indeed just swapped the first
two arguments. However, if there are an odd number of arguments, where the
number of arguments are three or more, and the even arguments are all
identical, then the one even argument is the front and the rest are the final
arguments. This lets you do things like this:
{a + b + c + {d * e }}
>ColorForth distinguishes between immediate and compiled words
> ... be
>nice to
>have that distinction in Lisp.
I've used several Forths and I own the book "Starting Forth".
Forth and Lisp are radically different. That said, lisp does have ways to
distinguish between actions taken while reading code, macros, and normal code.
Scheme does not have a standard way to adjust the readtable (to control what
happens while reading an expression) but common lisp does. Common Lisp also
has eval-when:
http://www.lispworks.com/documentation/lw50/CLHS/Body/s_eval_w.htm
I think that controlling infix is much better if handled by the reader in lisp.
--- David A.Wheeler
--
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] using sweeten with newlisp
On Tue, 20 Sep 2016 13:20:26 -0700, David Walther
wrote:
> Hi, nice work on sweet expressions.
Thanks! And thanks for contributing to this mailing list.
> Could you add a newlisp mode for sweeten?
I'm fine with adding a new mode for sweeten... but I'm kind of hoping that *you*
would provide those improvements. But I'd be happy to help you get there.
BTW, you probably want to improve "unsweeten", not "sweeten".
> The main issue is that the # character in newlisp is treated as "comment until
> end of line", and there are no #! (or #|?) style multiline comments.
Several things probably need parameters, e.g., the characters for
comments to the end of line, and multiline comments are supported.
Supporting Clojure has similar issues - there should be a few parameterizations.
There's already basic support for a Common Lisp mode. In Common Lisp
it's probably better to use the implementation specifically for Common Lisp,
but for generic data processing modifying "unsweeten" might be easier.
> # has no other special meanings, it isn't a prefix for special data types.
Again, this sounds like something needing parameterization.
> ; means the same thing as it does in regular LISP.
So *both* # and ; begin comments? Interesting.
But that's not a big problem.
> Also there are a few things from bbcode, like [cmd][/cmd], and [text][/text]
> tag pairs. [cmd][/cmd] is only used in interactive mode, but both tag pairs
> can be considered as literal multiline strings without escaping.
Another parameter, no big deal.
> Also, newLisp uses {} to delimit a literal string. I am ok with {} literal
> strings being turned into quoted "" strings. newlisp "" strings are escaped
> just like C and JavaScript.
Okay. Clojure uses {...} for hashes, so newLisp isn't the only Lisp where {}
has another meaning. The question is, how should infix be handled?
It really needs some paired characters, and (...) are spoken for.
Does newLisp already assign [...] a meaning?
If so, the best approach may be to use
«x + 1» : Left/right-pointing double-angle quotation mark, U+AB/U+BB. These are
very well-supported (e.g., they are used for French quotations and are in
Latin-1), and in many cases are the easiest to enter. There is a risk of them
being too similar to the comparison operators < and >, but this doesn't seem
too bad. Nested example: fact«n * «n - 1»»
I discuss this here:
https://sourceforge.net/p/readable/wiki/Clojure/
> Also, newlisp source code is in UTF-8. Is sweeten UTF-8 compatible?
It's *supposed* to be, as long as the underlying Scheme is. It probably hasn't
been adequately tested that way, but if it's not, it's a bug and needs to be
fixed.
--- David A. Wheeler
--
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Readable Lisp 2.0, brainstorming
On September 13, 2016 7:22:55 PM EDT, Alan Manuel Gloria
wrote:
>On Tue, Sep 13, 2016 at 8:11 AM, David A. Wheeler
>
>wrote:
>
>>
>> >4. Backquotes "invert" the use of a symbol: foo is a prefix symbol,
>> >`foo`
>> >is an infix symbol; while + is an infix symbol while `+` is a prefix
>> >symbol.
>>
>> How will you identify quasi quoting? Or do users simply have to use
>the
>> full name quasiquote ?
>>
>
>Full name, sadly ^^
>
>The target I'm planning for these rules is not, technically speaking, a
>Lisp (a dynamically-typed language whose primary data type is used to
>represent its code) but rather a Haskell-like language.
>
>The point of this is to allow a Scheme macro processor to be used on a
>Haskell-like language. So, quasiquote is a lot less needed.
>
>syntax `<-`
>syntax do
>. transform
>. . do
>. . . p <- x
>. to $ syntaxError "do: last form cannot be `p <- x'" p
>. transform
>. . do
>. . . x
>. to
>. . x
>. transform
>. . do
>. . . p <- x
>. . . y
>. . . ...
>. to
>. . . x >>= \ p -> do y ...
>. transform
>. . do
>. . . x
>. . . y
>. . . ...
>. to
>. . x >>= \ _ -> do y ...
>
>(well, "\" would also have to be prefix-defaulted, and the "function"
>syntax would be `->` rather than \ here, with \ being a dummy stand in)
>
>Still, let (or "where", which is a more common idiom in Haskell-like
>languages, although "let" does still exist) is difficult to express in
>a
>good indentation form
>
>fix :: ((a -> b) -> (a -> b)) -> (a -> b)
>map = value
>. fix rec
>. where
>. . rec map f (a:as) = f a:map f as
>. . rec map f Nil = Nil
>{-
>(map = (value
> (fix rec)
> (where
>((rec map f (a:as)) = ((f a):(map f as)))
>((rec map f NIl) = Nil
>-}
>
>blech!
>
>Sincerely,
>AmkG
I don't know if it would help your use case, but you could use vertical bars to
surround symbols that you don't intend to use as in fix. E.g.:
(1 + 2 ) => (+ 1 2)
while
(1 |+| 2 ) => (1 |+| 2)
Then you could more easily write expressions that would be interpreted the same
way on both traditional readers and your new reader.
However, if you're not really reading lisp code, then the sky is the limit.
Haskell includes its own system, as I'm sure you know.
Can you post a few examples of representative expressions, and then maybe we
can backtrack to see what alternatives exist?
--- David A.Wheeler--
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Readable Lisp 2.0, brainstorming
>4. Backquotes "invert" the use of a symbol: foo is a prefix symbol, >`foo` >is an infix symbol; while + is an infix symbol while `+` is a prefix >symbol. How will you identify quasi quoting? Or do users simply have to use the full name quasiquote ? --- David A.Wheeler -- ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] cl-metamath in sweet-expressions
Fyi, I've been implementing a library in common lisp using sweet expressions. It is not quite ready for prime time, but you might find it amusing here: https://github.com/david-a-wheeler/cl-metamath --- David A.Wheeler-- ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Readable Lisp 2.0, brainstorming
That's a cool approach. That said, I suspect trying to define precedence rules will be a pain in the butt. There is a looming problem if different forms have different presidence rules. You might be better off three defining precedence rules for a subset of operations, and then just requiring people to use parentheses otherwise. --- David A.Wheeler-- ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Readable Lisp 2.0, brainstorming
On Thu, 1 Sep 2016 19:37:43 -0400, luke wallace wrote: > My idea is that by converting lisp into a simplified abstract syntax tree > form, and then performing formatting options on that abstract syntax tree > (such as prefixing parts of it with syntactic sugar, or compacting some > levels of the tree, or reformatting the order of operators and operands, we > are able to create human-readable formatting for conventional lisp code > > Below are two theoretical examples: > > http://i.imgur.com/JNOXQ4M.png The pictures are fine representations of abstract syntax trees (ASTs). You need to handle "lists of lists" (like let's first argument); that can be tricky but is doable. If you mean for people to view them directly (say auto-generated as you edit), I'd be a little worried about screenspace - that's always limited compared to the amount of code being managed. If you only showed "the part you're working on" that might not be bad. Constantly updating a graphical AST representation of "what I'm working on" might be snappy; if you just keep regenerating from the text you completely eliminate the problem of selecting things, and you can highlight "where the cursor is". If you mean for people to *edit* those directly, it can be tricky work out how to select the "right spot" for insertion, etc. I think trying to edit that would be more work than useful. It's been done for stuff like mathematics: http://icm.mcs.kent.edu/reports/2006/ICM-200601-0001.pdf However, that presumes that you can know what a given operation is given its name, and how many parameters that operation would take, which is not true in Lisp. I'm guessing that you really mean to show those final representations, though, e.g., sqrt(a+b*(c-d)) or whatever. If you use a Lisp as a subset of Python that can work out fine but Python is a better Python. A key power of Lisp is that you can define your own languages (e.g., macros), use templating (e.g., ","), and other powerful techniques that exploit homomorphism. The earlier AST is trivially homomorphic. However, the "final" representation shown does *not* appear to be homomorphic. That's fatal. Trivial example: the final version added a "then" and "else" after an "if". But there's no reason to believe that the "if" is actually the built-in Lisp "if". I could easily define a macro that rewrites "if" into something else (and indeed, that's a common thing to do in packages). For example, maybe "if" means "interface" at that point. Similarly, "defun" (Common Lisp) or "define" (Scheme) might mean the specific names predefined in the language.. or not. If you just want a specialized language inside a larger Lisp program, feel free to create it. Many have. But if you want to write Lisp programs in a "more readable" way, your notation has to be homomorphic & handle arbitrary s-expressions. There's simply no way to know what the symbols "mean" while you're editing them. I'm *not* saying it's impossible. It's doable. Sweet-expressions are one solution, and the wisp developers have created another. But you have to consider the general case. If you limit yourself to symbols with fixed meanings, there are other languages that already do the job. If you're going to use a Lisp, it should be because Lisp provides some advantage to you. --- David A. Wheeler -- ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Readable Lisp 2.0, brainstorming
On Thu, 1 Sep 2016 19:37:43 -0400, luke wallace wrote: > Let's try to use wishful thinking in order to reinvent how to make lisp > more accessible and useful to complete newbies. Thanks for sharing your thoughts! I'd prefer this discussion be public, if possible, so that everyone can share in the results. > The editor would do all the box drawing for > you, and be saved as lisp in source files (the editor would just display it > in readable format once opened). As I understand it, you want to have a bidirectional translation within the editor, so that what is *saved* is traditional Lisp code, but what is *viewed* is some more readable format. Interestingly enough, bidirectional translation is already *partly* possible with the readable notations right now. We already have programs that translate each way. Presuming you choose the top level (sweet-expressions), you could convert to sweet, edit, then translate back on save. It's not ideal though (see below). However, there are several issues with bidirectional translation (translations on read and save): 1. You *really* have to trust the bi-directional translation tools. Even the slightest defect can cause problems, because "what you run" isn't "what you see". 2. You have to be careful on handling comments. The current sweetening routine drops comments outside the top level. This lossiness is not ideal, but for its intended purpose it's okay... but for bidirectional work it's not a good thing. 3. You either lose the formatting on both ends, or you spend a *lot* of time trying to "fix up" formatting. If someone formats it in a certain way in the traditional Lisp code, it's tricky to retain that, and the other way as well. 4. If you work with other people who use different formatting, you can end up with a lot of pseudo-changes, which would greatly interfere with version control systems (it'd look like you changed a lot of lines, when it was just reformatted). This is easy to solve: Pick a specific formatter and its options, and *always* run that before saving. It's certainly *possible* to do bidirectional translations. But it's a lot of work. Most GUI programming tools, for example, store a representation of the GUI display and only do 1-way translations from the GUI to the underlying representation. You're certainly welcome to try some things out - I'm a little skeptical that it's worth the work, but the proof is always in the doing. --- David A. Wheeler -- ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] S-exploration
Fyi, there is an interesting s-expression visualization tool here: https://github.com/ympbyc/s-exploration/ --- David A.Wheeler-- ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] "Readable" 1.0.9 posted
"Readable" library version 1.0.9 is now available! It has various minor changes. --- David A. Wheeler -- ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] Plan to post updated "readable" library
I plan to release an updated "readable" library, based on the current development version. The changes are relatively small, and most of the changes are for Common Lisp. If there are any issues, please post quickly. Thanks! --- David A. Wheeler -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] :depends-on "readable" not working
On Sat, 06 Dec 2014 12:17:31 -0800, Alexander Dunn wrote: > Hi readable, ... > If I execute (readable:enable-sweet) in the REPL before I execute > (ql:quickload “help"), it compiles just fine. But, I don’t understand why > the same doesn’t work when I put (readable:enable-sweet) inside my help.lisp. > Sorry about the bug. I just posted to the "devel" branch an updated version of the "readable" library that fixes the bug. This is a pretty important problem, so I plan to post an update to the package tonight on the master branch. If anyone objects, please let me know asap. The change is pretty straightforward; here's a quick summary. This version turns the enable-* functions into macros so that they can invoke "eval-when". During compilation the macros can only call functions that are *already* compiled, so the enabling macros have been moved into a separate file (so we can easily ensure that the macros only call already-compiled functions). It'll take a little time before QuickLisp picks up the updated master branch version. As a temporary workaround, I suggest replacing any call to (readable:enable-sweet) with: (eval-when (:compile-toplevel :load-toplevel :execute) (readable:enable-sweet)) Once QuickLisp picks up the update, the problem should disappear. --- David A. Wheeler -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] :depends-on "readable" not working
On Sat, 06 Dec 2014 12:17:31 -0800, Alexander Dunn wrote: > Hi readable, > Thanks for making this fantastic package! I’m new to LISP and this has made > LISP programming far more appealing. > I’m trying to use the Quicklisp package “readable" as a dependency in a > package I created using QuickLisp’s quickproject Okay, I'm back at a real computer instead of a smart phone. Try this: In your code, replace the line: (readable:enable-sweet) with the following: (eval-when (:compile-toplevel :load-toplevel :execute) (readable:enable-sweet)) It worked for me, but I want to know if it works for you. If it *does* work, then the next step is to decide what to do about it longer term. I certainly welcome comments from someone else. But let's get Alexander Dunn back to doing good things, first, and we then can decide how to make sure no one else has a problem. --- David A. Wheeler -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] :depends-on "readable" not working
On Sat, 06 Dec 2014 12:17:31 -0800, Alexander Dunn wrote: > If I execute (readable:enable-sweet) in the REPL before I execute > (ql:quickload “help"), it compiles just fine. But, I don’t understand why > the same doesn’t work when I put (readable:enable-sweet) inside my help.lisp. > On first blush, this looks like missing 'eval-when' clauses in the "readable" package. --- David A. Wheeler -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] :depends-on "readable" not working
On Sat, 06 Dec 2014 12:17:31 -0800, Alexander Dunn wrote: > Hi readable, > > Thanks for making this fantastic package! I’m new to LISP and this has made > LISP programming far more appealing. Great! > > I’m trying to use the Quicklisp package “readable" as a dependency in a > package I created using QuickLisp’s quickproject. > > Attached is an example project to demonstrate my problem. Thanks for the report! I can reproduce the problem, but I'm not sure how to best fix it, and I have to run off right now. Anyone else have thoughts? I can reproduce on Linux using: mkdir /home/dwheeler/local-projects/help ... unzipped and put .lisp, .asd, etc. in that directory ... sbcl (push #p"/home/dwheeler/local-projects/help/" asdf:*central-registry*) (ql:quickload "help") --- David A. Wheeler -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Discussion: Should leading "." in sweet-expressions have wisp semantics?
Arne can best give the wisp answer, but here is what I would expect: 1.: foo bar . aaa bbb ccc . ddd eee => (foo bar aaa bbb ccc ddd eee) 2.: foo bar . aaa bbb . ccc . ddd eee Error. Period after leading period. Perhaps more interestingly, I would expect this: foo bar aaa bbb ccc . ddd eee fff ggg hhh => (foo bar (aaa bbb ccc) ddd eee fff (ggg hhh)) On November 28, 2014 5:59:14 AM EST, "Jörg F. Wittenberger" wrote: >Am 27.11.2014 um 20:03 schrieb Arne Babenhauserheide: >> Am Donnerstag, 27. November 2014, 08:47:49 schrieb David A. Wheeler: >>>> However within "normal" s-expressions or neotheric expressions I'd >have >>> second thoughts. How would this be parsed?: >>> >>>> foo bar >>>> . aaa . bbb ccc >>> >>> I agree, that should be an error. It doesn't really make any sense >to me either. I expect this would continue to be ok: >>> >>> aaa bbb . ccc >>> => >>> (aaa bbb . ccc) >>> >>> And the following would still be an error: >>> aaa bbb . ccc ddd > >+1 > >> >> That’s also what wisp does: The leading dot is interpreted as >> continuation if it’s the first character in a line in >> indentation-sensitive code. >> >> It would be cool to see sweet and wisp move closer together here! > >+1 > >How does wisp deal with these? > >1.: > >foo bar > . aaa bbb ccc > . ddd eee > >2.: > >foo bar > . aaa bbb . ccc > . ddd eee --- David A.Wheeler-- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Discussion: Should leading "." in sweet-expressions have wisp semantics?
> However within "normal" s-expressions or neotheric expressions I'd have second thoughts. How would this be parsed?: > foo bar > . aaa . bbb ccc I agree, that should be an error. It doesn't really make any sense to me either. I expect this would continue to be ok: aaa bbb . ccc => (aaa bbb . ccc) And the following would still be an error: aaa bbb . ccc ddd On November 27, 2014 6:04:47 AM EST, "Jörg F. Wittenberger" wrote: >Am 26.11.2014 um 23:32 schrieb David A. Wheeler: >> This is a request for comment: >> In sweet-expressions, should a line beginning with "." have the same >semantics as wisp? >> >> In wisp, I understand that a line beginning with "." is interpreted >as a sequence of expressions at the same level. E.G.,: >> foo bar >> . aaa bbb ccc >> => >> (foo bar aaa bbb ccc). >> >> A "." with a single n-expression is interpreted this way now. >Currently, it's illegal to have more than 1 n-expression on a line; >this change would relax that rule. >> >> Anyway, thoughts welcome, pro or con. > >For indentation sensitive mode as the first element on a line: I fail >to >see what damage it could do. => pro > >However within "normal" s-expressions or neotheric expressions I'd have >second thoughts. How would this be parsed?: > >foo bar > . aaa . bbb ccc > >Here I'd prefer to get a parsing error. => con > >/Jörg > >-- >Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >from Actuate! Instantly Supercharge Your Business Reports and >Dashboards >with Interactivity, Sharing, Native Excel Exports, App Integration & >more >Get technology previously reserved for billion-dollar corporations, >FREE >http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk >___ >Readable-discuss mailing list >Readable-discuss@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/readable-discuss --- David A.Wheeler-- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] Discussion: Should leading "." in sweet-expressions have wisp semantics?
This is a request for comment: In sweet-expressions, should a line beginning with "." have the same semantics as wisp? In wisp, I understand that a line beginning with "." is interpreted as a sequence of expressions at the same level. E.G.,: foo bar . aaa bbb ccc => (foo bar aaa bbb ccc). A "." with a single n-expression is interpreted this way now. Currently, it's illegal to have more than 1 n-expression on a line; this change would relax that rule. Anyway, thoughts welcome, pro or con. --- David A. Wheeler -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] wisp and readable - common expressions
David A. Wheeler:
> > If wisp interpreted neoteric-expressions by default,
> > then many more expressions work in both systems...
On Fri, 21 Nov 2014 22:38:13 +0100, Arne Babenhauserheide
wrote:
> That’s true, but then lines with a single element would be treated
> differently than lines with multiple elements, and that is a gotcha I want to
> avoid.
As I've commented before, I think the wisp rule *seems* simpler ("each line is
new list"),
but in practice it is *itself* a gotcha, because it leads to bizarre behavior
like this.
Which is why both SRFI-49 and sweet-expressions don't do it.
But suspending that old discussion, let's focus on the example you mentioned...
> It hits you with things like newline
> wisp:
> define : hello
> display "Hello World!"
> newline
> define : hello2 who
> format #t "Hello ~A!\n" who
If you're using wisp you probably do *not* want to use
a neoteric expression as the *first* element on a line
(unless you're actually calculating what function/procedure to call).
So teach that style rule, and you avoid that (wisp) gotcha.
However, in *both* wisp and sweet-expressions there are MANY
uses for neoteric-expressions in the REST of the line.
For example, here's a line from math.slisp:
cons car(lyst) flatten-operation(op cdr(lyst))
It's pretty common to have several short parameters on a line;
neoteric-expressions are quite useful in this case. A quick grep finds many
examples.
You *can* do it using traditional s-expression notation, of course:
cons (car lyst) (flatten-operation op (cdr lyst))
However, I think the former is more readable. In particular,
the "car(lyst)" format is the same as mathematics and nearly all other
programming languages, making it much more familiar. I always use the
"car(lyst)" form when it's a call, never the "(car lyst)" form,
so there's no problem of "which format do I use".
Being readable in great part depends on building on what people already know,
and this is the more familiar notation.
Besides, neoteric-expressions are *already* supported in curly-infix.
--- David A. Wheeler
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] wisp and readable - common expressions
It is obviously possible to change the semantics of leading period. I am
hesitant to add yet another operator; you may disagree but I really tried to
make it a short list. I also really wanted to fix the notation, but leading
period is basically never used so that is probably not really a problem.
Let me think about it.
On November 21, 2014 4:38:13 PM EST, Arne Babenhauserheide
wrote:
>Am Mittwoch, 19. November 2014, 18:34:25 schrieb David A. Wheeler:
>> It's possible to write code that is interpreted *identically*
>> on both wisp and sweet when indentation is enabled.
>
>That’s cool!
>
>> In sweet, a "." at the
>> beginning of a line post-indent is basically ignored.
>
>Would it be possible to generalize this, so sweet would also make the
>full line a continuation instead of only ignoring the dot?
>
>That would make many uses of \\ unnecessary, and wisp would then be
>almost a subset of sweet.
>
>> Thus, in both sweet and wisp:
>> a b c
>> d e
>> . f
>> g h
>> becomes:
>> (a b c
>> (d e)
>> f
>> (g h))
>
>> If wisp interpreted neoteric-expressions by default,
>> then many more expressions work in both systems, e.g.:
>> defun factorial()
>> if {n <= 1}
>> . 1
>> {n * factorial{n - 1}}
>
>That’s true, but then lines with a single element would be treated
>differently than lines with multiple elements, and that is a gotcha I
>want to avoid.
>
>It hits you with things like newline
>
>wisp:
>define : hello
> display "Hello World!"
> newline
>define : hello2 who
> format #t "Hello ~A!\n" who
>hello2 "wisp"
>
>sweet:
>define hello()
> display "Hello World!"
> newline()
>hello()
>define hello(who)
> format #t "Hello ~A!\n" who
>hello2 "sweet"
>; or
>hello2("sweet")
>
>> So while neoteric-expressions provide two ways to write something,
>> in practice, there's a "more readable" way that better expresses the
>purpose
>> in each case.
>
>It’s almost as if you had intentionally motivated a quote I found
>yesterday but didn’t share because I didn’t know whether it would come
>off as offensive. With that kind of (unintentional?) prep-work:
>
>
> wisp-expressions are not as sweet as readable, but they KISS.
>
>
>:-)
>
>Best wishes,
>Arne
--- David A.Wheeler--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] wisp and readable - common expressions
BTW,
It's possible to write code that is interpreted *identically*
on both wisp and sweet when indentation is enabled. In sweet, a "." at the
beginning of a line post-indent is basically ignored. This was for consistency
with neoteric-expressions, and left there in part to be consistent with sweet.
In wisp, a leading "." is NECESSARY to disable automatic list-wrapping.
So if you begin any line with "." if it has a single element, and avoid the
additional markers like ":", "$", "\\", and <*...*>, they're identical.
Thus, in both sweet and wisp:
a b c
d e
. f
g h
becomes:
(a b c
(d e)
f
(g h))
Of course, once you open a list (...) and format it normally,
or start a curly-infix-expression {...}, they are identical.
If wisp interpreted neoteric-expressions by default,
then many more expressions work in both systems, e.g.:
defun factorial()
if {n <= 1}
. 1
{n * factorial{n - 1}}
In general I find that if the first element is a symbol, I normally
write it using f(...), e.g., cos(). That is ALWAYS true if it's
a procedure I'm calling. However, if the first element is not a symbol,
e.g., a number, then I write a normal list, e.g., '(1 2 3).
The pretty-printer exploits this; if something is a symbol, and the list
is not too long (e.g., 16 items or so), it's presented in f(...) format.
So while neoteric-expressions provide two ways to write something,
in practice, there's a "more readable" way that better expresses the purpose
in each case.
--- David A. Wheeler
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] "Readable" library version 1.0.6 released!
Version 1.0.6 of the "readable" library has been released.
This is mainly minor improvements for the Common Lisp implementation:
* Bug fix for a subtle rarely-encountered error in the
Common Lisp implementation of the sweet-expression reader.
Previously, the reader would not work correctly on
an n-expression if it was not a symbol, indentation processing
is active, and it begins with the punctuation symbols
"$", "\", "<", "*", or ".".
For example, (* 4 5) and {4 * 5} worked fine, but *(4 5) did not.
This bug took a long time to detect, because it
didn't affect infix or traditional s-expression
notation, and this is normally how such expressions would be used.
Also, the neoteric reader worked just fine.
* In Common Lisp, maintain the readtable-case setting with
enable-sweet (it already did so for other notations).
That way you can both type and show lowercase symbolic input
(by using the Common Lisp standard's "invert" setting).
* Modify sweet-sbcl to use the readtable-case invert setting.
* Added "math.slisp", a symbol math simplifier in Common Lisp
that demonstrates the readable notations.
--- David A. Wheeler
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] wisp now defaults to activating curly-infix
On Tue, 18 Nov 2014 23:46:44 +0100, Arne Babenhauserheide wrote: > ... Yes, if you know > all the sweet syntax, quite a few code snippets will likely look more > readable than those in wisp. But the additional syntax elements > provide a high barrier for learning, because they require retraining > the eyes. I think that's a trade worth making. More syntax *does* take more training, but if you look at a lot of code, then that additional syntax can pay back large dividends. > > "Less bad" is not exactly a high aspiration :-). > > It’s a different trade-off: Simplicity against less rough edges. ... > > Of course, this why I decided to NOT have all lines begin a function call > > in sweet-expressions. > > Both sweet-expressions and I-expressions (SRFI-49) have a different > > semantic, because it > > seems to be "what humans assume" in practice. > > It’s what lisp and scheme do, but for example it isn’t what the shell > does. I agree that lisp and scheme programmers tend to assume this, > but I don’t think that it is right for indentation-based scheme. But > since this is the main forking point between sweet and wisp, I guess > it isn’t a point which can be changed by argument ☺ Fair enough :-). > It comes down to personal preferences: The weight we give to different > aesthetic aspects of programming languages. For me, the syntactic > simplicity is one of the main selling points of lisp and scheme, and > sweet departs from that by adding more than the absolute minimum of > the required syntax elements for creating a general, indentation-based > representation of scheme-code. Neither Scheme nor Common Lisp are so simple to parse once you consider their full generality (e.g., number types). > The cost I pay for that is that there will be code snippets which will > look less elegant in wisp than in sweet. You could say, that they look > less sweet ☺ ... > Best wishes, > Arne You too! I view this as a friendly competition. We both agree that there's a need for a Lisp syntax that is general and homoiconic, and that indentation can help. We differ on how to best exploit that, that's all. Thanks. --- David A. Wheeler -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] Intend to post updated "readable" library soon
I intend to update the 'readable' library soon. It fixes a bug in the Common Lisp sweet-expression reader, and adds an example "math.slisp" Common Lisp demo. If you have last-minute comments, please post! --- David A. Wheeler -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] wisp now defaults to activating curly-infix
I said: > > Very cool! Have you considered making neoteric active by default as well? On Thu, 13 Nov 2014 21:56:19 +0100, Arne Babenhauserheide wrote: > I considered it, but decided against it, because in wisp that provides > less advantages than in sweet expressions, while adding ambiguity (one > more way to spell the same code). I don't think the ability to spell something more than one way is usually termed "ambiguous"; I don't know if there's a term for that; perhaps "multiple spellings"? In any case, "multiple spellings" (or whatever it's called) is inherent in Scheme and Common Lisp. For example, 'x and (quote x) are already two ways to write the same thing. Yes, it adds a different way to spell the same code, but in many cases it would be the more common way to do it (e.g., the normal way in math and other programming languages). > That expression in wisp is simply > stuff : cos a > > or > stuff > cos a Sure. You can also do that easily in Sweet-expressions: stuff $ cos a ... or ... stuff cos a > In sweet that would be a problem, as far as I know, because if you want to do > > (stuff (cos a) b c d e) > > without neoteric expressions, you have to do it as > > stuff > cos a > b > c > d > e > > Here neoteric experssions help a lot: > > stuff cos(a) b c d e That would be the normal way (and recommended) way to do it. There are alternatives if you hate neoteric expressions in sweet-expressions, e.g.: stuff cos a \\ b \\ c \\ d \\ e But it seems to that the "obvious" way is the right way: stuff cos(a) b c d e > But in wisp you’d just do > > stuff : cos a > . b c d e > > or > stuff > cos a > . b c d e > which, though still harder to read than sweet-expressions, is less bad :-). "Less bad" is not exactly a high aspiration :-). I think wisp is the wrong trade-off anyway, but since you're working on it, contrast that to: > stuff cos(a) > . b c d e which is still harder to read, but less harder :-). > On the other hand, this difference makes neoteric expressions much less > elegant in wisp than in sweet. In sweet you can just to > > stuff > cos(a) > > because a single element on a line is treated as that element, not as a > function call. In wisp you’d have to do > > stuff > . cos(a) > > because a line always begins a function call, except when started with a > period. Of course, this why I decided to NOT have all lines begin a function call in sweet-expressions. Both sweet-expressions and I-expressions (SRFI-49) have a different semantic, because it seems to be "what humans assume" in practice. I think you're right that in the wisp semantics, using a neoteric expression at the *beginning* of a line would be especially confusing. But not everything is at the beginning of a line, and using them afterwards would (I think) be sensible). E.G.: sqrt cos(a) sin(a) --- David A. Wheeler -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] wisp now defaults to activating curly-infix
On Mon, 10 Nov 2014 00:27:02 +0100, Arne Babenhauserheide wrote: > Hi, > > With the new release of wisp, curly infix is active by default: > > http://draketo.de/light/english/wisp-lisp-indentation-preprocessor#v0.8.0 > > Also the implementation became more similar to readable (using read > wherever possible). Very cool! Have you considered making neoteric active by default as well? Then you can do: stuff cos(a) --- David A. Wheeler -- ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] math.slisp: A readable notation demo in Common Lisp
FYI, here's a new demo file for readable notations, using Common Lisp. It implements a basic math expression simplifier: http://sourceforge.net/p/readable/code/ci/develop/tree/math.slisp Suggestions (or patches) welcome. To my knowledge the Common Lisp reader works on all Common Lisp implementations as-is, though it's been tested more on clisp and sbcl. --- David A. Wheeler -- ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Clojure supports UTF-8 (thus, easy Unicode support)
On Sun, 9 Nov 2014 07:54:11 +0800, Alan Manuel Gloria
wrote:
> Ugh. Non-ASCII is hard to type on a majority of keyboards unless you
> add special stuff. I don't think that'll increase acceptance.
The only reasonable option I see is #[...]. I don't think changing the
semantics of {...} would increase its likelihood of acceptance in Clojure.
Also, the BDFL of Clojure objected to *any* infix support a few years ago.
Don't know if that's still true or not.
--- David A. Wheeler
--
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Unicode matching brackets as alternatives to {...} for languages such as Clojure
I claimed: > > «x + 1» : Left/right-pointing double-angle quotation mark, > > U+AB/U+BB. These are very well-supported (e.g., they are used for > > French quotations and are in Latin-1), and in many cases are the easiest > > to enter. However, do they too similar to the comparison operators < > > and >? On Wed, 29 Oct 2014 20:10:36 -0400, John Cowan wrote: > The barrier is input, not display. I have a keyboard driver for Windows > that allows you to type about 1000 characters[1], but most people don't. > I would say these are the only brackets that are easy for anyone to type, > and even then they don't work for people using the U.S. keyboard and > standard drivers. (On X, there is a compose key, but only a few people > are using Linux on their desktops.) Input is obviously critical. I think the options are in place, though. There's a lot of info here: https://en.wikipedia.org/wiki/Unicode_input So - regarding Windows. Many applications have application-specific mechanisms. Windows programs that use the RichEdit control (like WordPad) let you enter the hex digits followed by alt-x. So "a" "b" "alt-x" will create U+AB. Emacs and vim have other mechanisms. You can also hold down ALT, and while holding it down, type 0 followed by the DECIMAL value and release on the numeric keypad. This depends on the input language. So "Hold-ALT 0 1 7 1 Release-ALT" inserts the left, and "Hold-ALT 0 1 8 7 Release-ALT" inserts the right. I just tried it out on a laptop without a separate keypad, and it still worked (I had to use Fn with the key it represented, but it did work). The most general solution in Windows is to first set the registry key HKEY_CURRENT_USER\Control Panel\Input Method EnableHexNumpad string type (REG_SZ) to 1. Then reboot. Then you can type "ALT + hex-of-Unicode release-ALT" (only the + on the numeric keypad works). This works on laptops without a numeric keypad too, just use the Fn key. That really should be the default; it's much faster and simpler. An annoying problem is that you have to set your editors to actually save as UTF-8 on Windows. Thankfully, that's a one-time step. If you want other applications to know it's UTF-8, you may need to insert the UTF-8 BOM, an abomination that's only useful on Windows but seems to be gracefully handled in many cases. I found that vim quietly keeps the UTF-8 BOM if it's there, and I suspect other applications do the same. There's no doubt that it is easier to use ASCII than anything else. On the other hand, we've been working to move to a Unicode world for years. Perhaps the world is finally ready :-). --- David A. Wheeler -- ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] Clojure supports UTF-8 (thus, easy Unicode support)
It appears that Clojure normally loads source files assuming they are UTF-8, which makes supporting Unicode much easier. This suggests that using a non-ASCII character might not be too hard for them to support. Source file src/jvm/clojure/lang/Compiler.java routine "loadFile" has this Java line, which I believe forces reading of source code as UTF-8: return load(new InputStreamReader(f, RT.UTF8), new File(file).getAbsolutePath(), (new File(file)).getName()); It's possible to do indirect loading where additional magic is necessary to force configuration of the encoding, as discussed here: https://stackoverflow.com/questions/1431008/enabling-utf-8-encoding-for-clojure-source-files --- David A. Wheeler -- ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] Unicode matching brackets as alternatives to {...} for languages such as Clojure
Both Scheme and Common Lisp do not assign a meaning to { and }, characters that
naturally pair and are available in ASCII.
So they are the obvious choice for surrounding infix lists in them.
Unfortunately, Clojure (and probably others) assign (), [], {}, and <> to
pre-existing meanings. (The < and > are used for comparisons). The best
backward-compatible syntax I see for Closure using just ASCII is using #[...],
which is ugly.
So I'd like to hear some opinions for this proposition: In Lisps where {} and
[] are already used, would a Unicode non-ASCII pair be okay instead? If so,
what pair?
First: is the world ready for Unicode in code? In particular, is support for
input, processing, and display easy enough?
Second, if so, what pair would serve best? These pages presume to list pairing
characters in Unicode:
* http://xahlee.info/comp/unicode_matching_brackets.html
* http://www.unicode.org/Public/UNIDATA/BidiBrackets.txt
There are a lot of characters, but issues with many:
* Many Chinese punctuation chars are full-width, which look odd when combined
with the so-called half-width characters in Western fonts.
* Support for some of the mathematical characters in some fonts seems dicey.
That said, it may be easier to get people to fix their fonts.
* Some characters are hard to distinguish from otehrs. For example, the
"left/right angle bracket with dot" pair has such a tiny dot on some fonts that
it would be missed.
These look like the best options (if your display can handle them!):
«x + 1» : Left/right-pointing double-angle quotation mark, U+AB/U+BB. These are
very well-supported (e.g., they are used for French quotations and are in
Latin-1), and in many cases are the easiest to enter. However, do they too
similar to the comparison operators < and >?
⦃x + 1⦄ : Left/Right white curly bracket, U+2983/U+2984. These are
nice-looking, they are similar to {}, and yet easily distinguished from them
and other characters. However, I have some concerns that they aren't uniformly
supported in fonts.
⟪x + 1⟫ : Mathematical left/right double angle bracket, U+27EA/U+27EB. Look
good, but may not be universally supported in fonts.
⟦x + 1⟧ : Mathematical left/right square bracket, U+27e6/U+27e7. Look good,
but may not be universally supported in fonts.
Some other options, don't look so good.
⦑x + 1⦒ : Left/Right angle bracket with dot. U+2992/U+2993. Not universally
supported in fonts. The dot is hard to see, so this is probably a bad choice.
【x + 1】: Left/right black lenticular bracket, U+3010/U+3011. Chinese, so they
are "full width" (and thus space odd with western letters).
《x + 1》 : Left/right double angle bracket, U+300a/U+300b. Chinese, so they are
"full width" (and thus space odd with western letters).
--- David A. Wheeler
--
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Using readable with clojure
On Mon, 27 Oct 2014 02:04:42 +0100, martijn brekelmans
wrote:
> Hello everybody,
>
>
> I'm fiddling around with clojure, and I'd like to use readable with clojure.
I've looked a little more at implementing "readable" (at least some tiers) in
Clojure, beyond http://clojure.org/reader.
Without changing the core code you could implement basic curly infix with a
somewhat different syntax and Clojure's tagged literals. Tagged literals let
you do "#my/tag element" - the reader then reads element, and passes through
my/tag. Reader tags without namespace qualifiers are reserved for Clojure,
however, so the tag will be multiple characters. So the best you could do
without changing the reader, as far as I can tell, would be something like
#n/fx (i >= 0), where "#n/fx" is an infix processor for curly-infix. That's
ugly, especially if they are embedded: #n/fx (i >= #n/fx (a + b)).
Clojure has nothing user-accessible like the Common Lisp readtable.
Implementing any of the readable tiers with a nicer-looking syntax will require
modifying the Clojure reader's source code. I took a quick peek at
src/jvm/clojure/lang/LispReader.java - that appears to be where the key reader
functionality is implemented. It doesn't look like it'd be hard to add a
variation of curly-infix or neoteric expressions, but getting those changes
*accepted* might be another matter.
I'm sure backwards-compatibility is critical for them, so using #[...] instead
of {...} is probably the only practical approach for them.
It might be sensible to start simple, just try to get #[...] accepted for as a
notation for basic curly-infix (with NO neoteric support). That has NO
possibility of conflict with existing code. We could warn users to NOT include
syntax in there of the form a(b) with the assumption that it would be
interpreted as "a (b)". The next step would be to get neoteric supported
inside #[...], at least in the sense of supporting a() as a synonym for (a
...). Maybe that version of neoteric could be supported at all times; the
problem is not writing the code, it's getting such a change *accepted*. It
would be possible to also interpret "x[y...]" as "(x #[y...])", which would be
full neoteric with a slightly different syntax. Note that unprefixed [...]
would continue to have its current meaning.
Any indentation-sensitive syntax would be a much bigger step - again, not
because it's hard to implement, but because it has to be *accepted*.
Example of infix notation in this situation:
#[#[a + b] > #[c * d]]
That is not as nice as {{a + b} > {c * d}}, but I don't see a nicer alternative
unless they're willing to use non-ASCII pairing characters (!).
In Clojure [...] and (...) have a different meaning, but it seems to me that we
should just leave [...] as-is. Parens are way more common for enclosing larger
scopes, as far as I can tell.
--- David A. Wheeler
--
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] Readable example: math.slisp
FYI, I have posted a simple math expression simplifier written in Common Lisp. It is written using sweet-expressions and itself reads and writes sweet-expressions: http://sourceforge.net/p/readable/code/ci/develop/tree/math.slisp --- David A.Wheeler-- ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Using readable with clojure
On Mon, 27 Oct 2014 08:55:55 -0400, John Cowan wrote: > Well, indentation can model () or it can model []; it can't do both. > In CL or Scheme that doesn't matter, because [] is inessential. In > Clojure it's essential. I've been assuming that it'd model (). Interesting thought though. You can model many other things by creating a macro that passes the parameters through it. --- David A. Wheeler -- ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Using readable with clojure
Not at all. The whole point is to have a syntax that is general, and not tied
to a particular semantic. Clearly it needs to be useful for a given semantic,
but not tied to it.
On October 26, 2014 10:43:17 PM EDT, John Cowan wrote:
>David A. Wheeler scripsit:
>
>> In Clojure, "{" is already taken for maps, and "#{" for sets. That
>interferes with {...} for infix.
>
>More importantly, [] is used to enclose lambda variables and in other
>situations in which Lisps use () for something other than application.
>I think that Readable would have to be substantially rethought, or at
>least enhanced greatly to understand the syntax (not just lexical
>syntax,
>but keyword syntax) of Clojure in order to be usable at all.
>
>--
>John Cowan http://www.ccil.org/~cowanco...@ccil.org
>Nobody expects the RESTifarian Inquisition! Our chief weapon is
>surprise ... surprise and tedium ... tedium and surprise
>Our two weapons are tedium and surprise ... and ruthless disregard
>for unpleasant facts Our three weapons are tedium, surprise, and
>ruthless disregard ... and an almost fanatical devotion to Roy
>Fielding
--- David A.Wheeler--
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Using readable with clojure
On Mon, 27 Oct 2014 02:04:42 +0100, martijn brekelmans
wrote:
> Hello everybody,
>
>
> I'm fiddling around with clojure, and I'd like to use readable with clojure.
> I've scanned the wiki and mailing list for any pointers on how to use
> readable within a clojure project, but found nothing.
>
> Clojure uses leiningen as its project and dependency management. There's a
> popular community repository for clojure libraries, but readable isn't on
> there. Apart from leiningen and the community repo, I have no idea how to get
> this working with clojure.
>
> So, I'm looking for any pointers on how to get readable working with my
> clojure projects.
Thanks! I'd love to see readable notations in Clojure,
but I have not tried to implement any of them in Clojure.
If you're willing to dive into it, that'd be great.
In some cases you could use the "unsweeten" as a preprocessor, at least as a
starting point.
However, I think changes would need to be to it for serious Clojure work.
The basic Clojure syntax is here:
http://clojure.org/reader
In Clojure, "{" is already taken for maps, and "#{" for sets. That interferes
with {...} for infix.
An implementation of the readable notations would have to determine if it will
use {...} for infix,
or switch to something else like #[...]. Clojure supports dispatching via "#",
so that might not be *too* bad.
An implementation could support both, but I'm guessing that it'd be best to
support a
backwards-compatible notation. I'm guessing that implementing x[...] as a
synonym for
(x #[...]) would be okay, but that needs investigation.
For *serious* work it should be possible to embed it as part of the reader.
The Common Lisp implementation does this for all tiers, and SRFI-105 is now
built into guile (at least).
--- David A. Wheeler
--
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] RELEASE of readable-1.0.5
We have a new release of "readable", version 1.0.5. This version is for the Common Lisp users; the Scheme materials are unchanged. It fixes a parsing bug in Common Lisp when sweet-expression ends without ending on EOL. It also adds built-in capabilities in Common Lisp to print using readable notations (Scheme already had this). The QuickLisp version should automatically update when they do their package updates. Enjoy! --- David A. Wheeler -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] New release of readable?
We have several improvements in the Common Lisp implementation
of "readable", so I think it's time to update. (Scheme-only users need not
bother.)
In particular, we have a bug-fix when an expression ends on something other
than EOL,
and basic mechanisms for printing. The mechanisms for printing simply call
"write"
on some types like array (including vector), but for a vast number of use cases
it works just fine.
Any objections or last-minute patches? Silence is consent.
Below I've attached the information about the ability to write in Common Lisp.
The text itself is written in Markdown.
--- David A. Wheeler
Writing readable expressions
The "develop" branch includes additional procedures to print expressions using
these readable notations, so you can easily print these notations as well as
read them. Their interfaces are intentionally similar to the standard Common
Lisp procedures, so they should be easy to use.
Procedure "write-readable" writes out its first parameter in a readable
notation, similar to the standard procedure write. It takes all the optional
parameters of write (such as :stream), plus the optional ":notation" parameter
for controlling the output notation. By default, the output notation is the
same as the input notation. The ":notation" parameter can be
'basic-curly-infix, 'full-curly-infix, 'neoteric, or 'sweet. "Write-readable"
will always use at least basic-curly-infix notation. Circularity detection is
available; use ":circle t" to enable it. It also includes similar procedures
print1-readable, princ-readable, and print-readable. You can write to strings
instead of the current output with write-to-string-readable,
prin1-to-string-readable, and princ-to-string-readable.
The current implementation directly supports circularity detection in cons
cells. The implementation directly supports the following Common Lisp types:
cons, symbol, number, character, pathname, string, and bit-vector. Note that
the "cons" is fully supported, which means that proper lists, dotted lists, and
circular lists are all supported. Other types are currently partly supported by
calling the underlying "write" implementation; this includes the types array
(including vector), hash-table, function, readtable, package, stream,
random-state, condition, and restart, as well as those created by defstruct,
define-condition, or defclass. In most cases this partial support is more than
enough, but you should be aware of its limitations. First, the contents of
partially-supported types will be presented in traditional Lisp notation
instead of a more readable notation (though it will still be a valid format).
Also, if you use circularity detection, the circularity detection in any p
artially-supported types will be separate and will not synchronize with the
detection in fully-supported types. There are merely limitations of the current
implementation, not of the fundamental concept. Patches are welcome!
Here are some examples, presuming that you use-package(:readable) first and
that the current notation is neoteric or sweet:
write-readable '(+ 1 2) ; Writes {1 + 2}
write-readable '(+ 1 (* 3 4)) ; Writes {1 + {3 * 4}}
write-readable '(COS X) ; Writes COS(X)
write-readable '(LOG 10 100) ; Writes LOG(10 100)
write-readable '(COS (* 2 X)) ; Writes COS{2 * X}
Syntax for basic writing procedures
---
**write-readable** object &key array base case circle escape gensym length
level lines miser-width pprint-dispatch pretty radix readably right-margin
stream notation => object
**prin1-readable** object &optional output-stream => object
**princ-readable** object &optional output-stream => object
**print-readable** object &optional output-stream => object
Arguments and values are the same as for write, with the addition of "notation"
in some cases.
write-readable is the general entry point to the readable Lisp printer. The
"notation" corresponds to \*print-notation\*.
prin1-readable produces output suitable for input to read. It binds
\*print-escape\* to true.
princ-readable is just like prin1 except that the output has no escape
characters. It binds \*print-escape\* to false and \*print-readably\* to false.
The general rule is that output from princ is intended to look good to people,
while output from prin1 is intended to be acceptable to read.
print-readable is just like prin1-readable except that the printed
representation of object is preceded by a newline and followed by a space.
Syntax for string writing procedures
---
**write-to-string-readable** object &key array base case circle escape gensym
length level lines mis
[Readable-discuss] Common Lisp printing pushed into "devel" branch
The Common Lisp implementation now has a set of printing routines, just like the Scheme implementation, on the "devel" branch. The external interface is designed to look like Common Lisp, not Scheme. For example, "write-readable" is intentionally similar to "write". Thus: (write-readable '(1 2 3)) does what you would expect. It takes a ":notation" parameter if you want to control the format; by default it uses the current format, but it will always use at least basic curly-infix. It implements circularity checking (if you enable it with :circle t). The current implementation handles atoms (e.g., numbers and symbols) and conses, though not other Common Lisp datatypes (yet). --- David A. Wheeler -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Error when no empty line at end of file
On Fri, 3 Oct 2014 02:18:32 +0200, martijn brekelmans wrote: > I'm trying out readable, and I'm already finding it brilliant. I found a > little bug however, in common lisp, when the file doesn't end with an empty > line, it will throw an Error, Error: Unexpected text after n-expression. > > Code can be found here > > When I add a newline at the end of the file, all works well again. I'm using > GNU CLISP 2.49. Ahah! I managed to duplicate the bug. Frankly, I *never* have source code without newline at end-of-file, so to me this is an incredibly weird case. That said, we should gracefully handle it. The fix turns out to be trivial, and is included below for your amusement. Basically, procedure "it-expr-real" didn't handle EOF-without-EOL gracefully. I expect this patch will be in the next release. --- David A. Wheeler === --- a/sweet.lisp +++ b/sweet.lisp @@ -665,6 +665,8 @@ (read-body stream new-indent) (list body-new-indent (my-append line-value body-value))) (list new-indent (monify line-value) + ((eof-objectp (my-peek-char stream)) +(list " " (monify line-value))) (t (read-error "Unexpected text after n-expression"))) ; Here, line-exprs begins with something special like GROUP-SPLIT: -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://p.sf.net/sfu/Zoho ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Sweetening code with #'
> On October 4, 2014 10:00:23 AM EDT, martijn brekelmans > wrote: > >I'm following practical lisp and there's a little bit of code using a > >#', I can't figure out how to sweeten this piece of code. Using the > >sweeten tool replaces #' with syntax, (the result is also in the > >pastebin link below), but it doesn't work when running, clisp tells me > >syntax is undefined. It may not be as obvious as it *should* be, but near the end of the Common Lisp tutorial is this text: > Sweeten is designed to read Scheme (or more specifically, Guile) S-expression > syntax. The "-C" option adds some support for Common Lisp notation instead, > in particular, #'function. So just use: sweeten -C filename.lisp > filename.slisp and you should have a sweetened version of "filename.lisp" in "filename.slisp". If it used #'function, it should continue to work. Sorry that you *have* to use -C, but the semantics of #' differ between Scheme and Common Lisp, so the "sweeten" program has to know that you're using Common Lisp semantics. --- David A. Wheeler -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://p.sf.net/sfu/Zoho ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Error when no empty line at end of file
On Fri, 3 Oct 2014 02:18:32 +0200, martijn brekelmans wrote: > I'm trying out readable, and I'm already finding it brilliant. Thanks! > I found a little bug however, in common lisp, when the file doesn't end with > an empty line, it will throw an Error, Error: Unexpected text after > n-expression. > > Code can be found here > > When I add a newline at the end of the file, all works well again. I'm using > GNU CLISP 2.49. I've been unable to reproduce the bug using clisp version 2.48. Your code works as expected on my systems. Can you give me more info on your setup? --- David A. Wheeler -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://p.sf.net/sfu/Zoho ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Sweetening code with #'
Are you using the -C option in sweeten? By default, sweeten assumes scheme syntax. You need -C so that it knows that you are processing Common Lisp On October 4, 2014 10:00:23 AM EDT, martijn brekelmans wrote: >I'm new to lisp and I thought using readable would be a great bridge >for learning lisp. So far it's been pretty good, except for one time :( >I'm following practical lisp and there's a little bit of code using a >#', I can't figure out how to sweeten this piece of code. Using the >sweeten tool replaces #' with syntax, (the result is also in the >pastebin link below), but it doesn't work when running, clisp tells me >syntax is undefined. > >Here's the piece of code that I'd like to sweeten. > >It would be great if the docs contained examples on sweetening >expressions that use #' (and probably also for similar symbols, like >'). > > > > >-- >Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS >Reports >Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > > > >___ >Readable-discuss mailing list >Readable-discuss@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/readable-discuss --- David A.Wheeler-- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] Fwd: Readable Lisp - conment from Yves Cloutier
Fyi: we got a nice email, below, and I got permission to share it. Original Message From: Yves Cloutier Sent: September 15, 2014 4:57:21 PM EDT To: dwhee...@dwheeler.com Subject: Readable Lisp Hello David, I just came across your Readable Lisp page and wow, I'm sold! I'm getting back into programming after almost 15 years of not doing it, spurred by a personal project idea. I started this project in Perl and then thought perhaps it could be done better in another language - which eventually brought me to Lisp/Scheme. Something really clicked with the Lisp/Scheme paradigm of doing things, but the syntax is a bit unfamiliar from most other languages. But the examples of Readable Lisp look quite familiar and I'm really interested in trying it out. Kudos for the initiative and work you are doing on this front. I think that if more people would know about this, it could be very important for Lisp/Scheme Regards, yves --- David A.Wheeler-- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Readable Lisp version 1.0.4 released!!
I haven't heard any complaints, so I presume version 1.0.4 fixed the earlier portability regressions. I did test it on a variety of systems. It *should* even work on guile 1.6, but I don't have test system for that. Alan: If you get a chance, let us know if it's working again on guile 1.6. The code is *written* with modern Scheme, but it tries to detect guile 1.6 and then patch as necessary. --- David A. Wheeler -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] Common Lisp printing - early feedback/comments?
The Scheme "readable" implementation includes ways to write out values using the new notations, but the Common Lisp implementation lacks these capabilities. I'd like to modify the Common Lisp implementation to add this (giving it parity with the Scheme functionality). Below is a start at adding them, focusing more on which functions to add. Any comments? The trick is to make it appear relatively "native" to Common Lisp. Currently I'm just defun'ing several standard Common Lisp functions with "-readable" in the names. Yes, they're in separate packages, but I want people to be able to bring them into their local namespace without problems. --- David A. Wheeler = Output routines for readable notations. Use *print-notation* to decide what notation to use when writing. Some of this code is derived from SBCL, which was in turn derived from the CMU CL system, which was written at Carnegie Mellon University and released into the public domain. (cl:in-package :readable) (defun write-readable (object &key ((:stream stream) *standard-output*) ((:escape *print-escape*) *print-escape*) ((:radix *print-radix*) *print-radix*) ((:base *print-base*) *print-base*) ((:circle *print-circle*) *print-circle*) ((:pretty *print-pretty*) *print-pretty*) ((:level *print-level*) *print-level*) ((:length *print-length*) *print-length*) ((:case *print-case*) *print-case*) ((:array *print-array*) *print-array*) ((:gensym *print-gensym*) *print-gensym*) ((:readably *print-readably*) *print-readably*) ((:right-margin *print-right-margin*) *print-right-margin*) ((:miser-width *print-miser-width*) *print-miser-width*) ((:lines *print-lines*) *print-lines*) ((:pprint-dispatch *print-pprint-dispatch*) *print-pprint-dispatch*) ((:suppress-errors *suppress-print-errors*) *suppress-print-errors*) ((:notation *print-notation*) *print-notation*)) #+sb-doc "Output OBJECT to the specified stream, defaulting to *STANDARD-OUTPUT*." (output-object-readable object (out-synonym-of stream)) object) (defun prin1-readable (object &optional stream) #+sb-doc "Output a mostly READable printed representation of OBJECT on the specified STREAM." (let ((*print-escape* t)) (output-object-readable object (out-synonym-of stream))) object) (defun princ-readable (object &optional stream) #+sb-doc "Output an aesthetic but not necessarily READable printed representation of OBJECT on the specified STREAM." (let ((*print-escape* nil) (*print-readably* nil)) (output-object-readable object (out-synonym-of stream))) object) (defun print-readable (object &optional stream) #+sb-doc "Output a newline, the mostly READable printed representation of OBJECT, and space to the specified STREAM." (let ((stream (out-synonym-of stream))) (terpri stream) (prin1 object stream) (write-char #\space stream) object)) (defun pprint-readable (object &optional stream) #+sb-doc "Prettily output OBJECT preceded by a newline." (let ((*print-pretty* t) (*print-escape* t) (stream (out-synonym-of stream))) (terpri stream) (output-object-readable object stream)) (values)) (defun write-to-string-readable (object &key ((:escape *print-escape*) *print-escape*) ((:radix *print-radix*) *print-radix*) ((:base *print-base*) *print-base*) ((:circle *print-circle*) *print-circle*) ((:pretty *print-pretty*) *print-pretty*) ((:level *print-level*) *print-level*) ((:length *print-length*) *print-length*) ((:case *print-case*) *print-case*) ((:array *print-array*) *print-array*) ((:gensym *print-gensym*) *print-gensym*) ((:readably *print-readably*) *print-readably*) ((:right-margin *print-right-margin*) *print-right-margin*) ((:miser-width *print-miser-width*) *print-miser-width*) ((:lines *print-lines*) *print-lines*) ((:pprint-dispatch *print-pprint-dispatch*) *print-pprint-dispatch*) ((:suppress-errors *suppress-print-errors*) *suppress-print-errors*) ((:notation *print-notation*) *print-notation*)) #+sb-doc "Return the printed representation of OBJECT as a string." (stringify-object object)) (d
[Readable-discuss] Readable Lisp version 1.0.4 released!!
The readable lisp library version 1.0.4 is now released!! This version improves its portability, so it should work on more systems; it includes a regression fix for guile 2. Download from: https://sourceforge.net/projects/readable/files/ Install instructions: https://sourceforge.net/p/readable/wiki/Install-howto/ Website for all other information: http://readable.sourceforge.net/ Enjoy! --- David A. Wheeler -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] All okay for an updated release?
The "develop" version includes a fix for the unintended guile 2.0 regression. I've made a few other changes to make it work on more systems, e.g., old autoconfs. I've even created a patch that I *think* will make it work on guile 1.6 (it replaces "else" with "#t" in the deployed code, but only if necessary). If anyone else could test it, that'd be great! I've tested this on several different systems. Also, patches to remove the warnings generated by guile 2.0 (listed below) while not interfering with other Schemes would be great. --- David A. Wheeler === guile 2.0 warnings === ;;; compiling /home/dwheeler/readable-code/readable-1.0.3/_build/readable/kernel.scm ;;; readable/kernel.scm:2526:16: warning: possibly unbound variable `srfi-69-make-hash-table' ;;; readable/kernel.scm:2531:48: warning: possibly unbound variable `type-printer' ;;; readable/kernel.scm:2533:12: warning: possibly unbound variable `hash-table-update!/default' ;;; readable/kernel.scm:2536:17: warning: possibly unbound variable `hash-table-ref' ;;; readable/kernel.scm:2545:31: warning: possibly unbound variable `type-num-slots' ;;; readable/kernel.scm:2548:31: warning: possibly unbound variable `slot-ref' ;;; readable/kernel.scm:2552:25: warning: possibly unbound variable `hash-table-ref/default' ;;; readable/kernel.scm:2553:16: warning: possibly unbound variable `hash-table-delete!' ;;; readable/kernel.scm:2555:17: warning: possibly unbound variable `srfi-69-make-hash-table' ;;; readable/kernel.scm:2556:8: warning: possibly unbound variable `hash-table-walk' ;;; readable/kernel.scm:2558:35: warning: possibly unbound variable `hash-table-set!' ;;; readable/kernel.scm:2567:50: warning: possibly unbound variable `type-printer' ;;; readable/kernel.scm:2568:25: warning: possibly unbound variable `hash-table-ref/default' ;;; readable/kernel.scm:2573:21: warning: possibly unbound variable `hash-table-ref/default' ;;; readable/kernel.scm:2585:24: warning: possibly unbound variable `hash-table-set!' ;;; readable/kernel.scm:2685:33: warning: possibly unbound variable `type-printer' ;;; compiled /home/dwheeler/.cache/guile/ccache/2.0-LE-8-2.0/home/dwheeler/readable-code/readable-1.0.3/_build/readable/kernel.scm.go ;;; unsweeten:184:16: warning: possibly unbound variable `pretty-print' -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Guile meta-commands
On Tue, 1 Jul 2014 11:58:20 -0400, Alex Rozenshteyn wrote: > There seems to be no way to get an input equivalent to ",h -c a" (note > the lack of parentheses) into the guile repl using guile-sweet. > > This makes it more difficult to use guile-sweet as a replacement for > the guile repl, since some guile meta-commands are not handled. The guile repl includes some magic commands and handles them specially. Unfortunately, it makes assumptions that the sweet reader falsifies. It'd be nice to find a way to invoke these commands directly... and then perhaps their ease could be restored. Here's what I know so far: Guile's source code can be viewed on savannah's git page, e.g.: http://git.savannah.gnu.org/gitweb/?p=guile.git;a=tree;f=module/system/repl;h=c767baf098d5dde0cb396eabcd6c40482608846c;hb=93e838423cba836fd90662f9acd362ddf3aa6fb1 The repl is implemented in "module/system/repl/", especially file "repl.scm". I suspect that procedure "meta-reader" is a key player. I haven't spent much time looking to see if there's a way to invoke the meta-commands more directly, but it *seems* like it should be possible! > Also, sweeten suggests that the solution would be ",h\n-c\na\n", but > both unsweeten and guile-sweet output before all three lines have been > input, and unsweeten does not collapse them onto the same line. > > I'm not sure how one could work around it or even if it's something > one could solve within the spec, but it just bit me, so I thought I'd > mention it. Thanks. Anyone have suggestions? --- David A. Wheeler -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Build error with guile-2.0
On Mon, 30 Jun 2014 22:42:35 -0400, Alex Rozenshteyn wrote: > Huh. I'm surprised that there was actually a problem. Thanks for > fixing it! (and sorry for spamming the list a bit) That's not spam at all. This list is *exactly* for discussing issues. I'm surprised that slipped through, but obviously it did, sorry about that. If you could confirm that it works on *your* system that'd be great. This is a serious problem, and I'd like to release a new version soon, but I'd rather make sure that it *stays* fix. --- David A. Wheeler -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Build error with guile-2.0
On Mon, 30 Jun 2014 14:44:02 -0400, Alex Rozenshteyn wrote: > I'm trying to build the 1.0.2 version on a 64-bit debian testing > machine. I have guile-2.0 (and guile-2.0-dev) installed. After running > ./configure --without-common-lisp, I try to run make, and I get the > attached error. > > I'm probably doing something wrong, but I'm not really sure what. Thanks for the report! The problem appears to be specific to guile 2.0. Sorry about that. I think I've fixed it, the update is on the "develop" branch on git. If you could test it out, that'd be great. The instructions here: http://sourceforge.net/p/readable/wiki/Install-howto/ Basically, you need to install git, autoconf, and automake. Then check out the code this way: git clone git://git.code.sf.net/p/readable/code readable-code cd readable-code git checkout -b develop origin/develop # Set up and switch to "develop" branch autoreconf -i Then configure, build, and test as usual: ./configure --prefix=/usr make make check --- David A. Wheeler -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Readable version 1.0.2 released!
On Sat, 28 Jun 2014 21:50:53 -0400, John Cowan wrote: > Another point is that not supporting `else` is non-conformant all the > way back to R2RS. Not supporting it makes Guile 1.6 a Not-Quite-Scheme. Which just shows the need for standards and standards test suites. To be fair, guile fixed this years ago. > A third point is that a one-line hack for Guile 1.6 fixes the problem: > > (define else #t) > > Just make sure this line isn't present for any real Scheme. I doubt that'll work. "else" is also used in (cond-expand ...) and (case ...). I don't have a guile 1.6 handy, but I do have guile 1.8. In 1.8, this works: (case #\a (else (display "hi"))) yet this fails: (define else #t) (case #\a (else (display "hi"))) and I suspect the same would be true for guile 1.6. Thanks for the idea though!! --- David A. Wheeler -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Readable version 1.0.2 released!
On Sat, 28 Jun 2014 08:15:15 +0800, Alan Manuel Gloria wrote: > Since I'm pretty much the only one who wants Guile 1.6 support, and > I'm pretty satisfied with the perfectly working old version, feel free > to drop Guile 1.6 support. I just wanted to make clear the reason for > why #t was used in the first place ^^. Okay. If you (or anyone else) thinks we need to re-add guile 1.6 support, we could do it using autoconf and text substitution. That way the source code would be clean modern code, and then transformed for execution only when needed. I'd be happy to add it, after all, you're co-author of the spec and your work has been instrumental in making the readable stuff happen. But you're satisfied, and I don't know of anyone else using such an old version of guile. GNU Guile 1.8.0 was released on 2006-02-12 (https://www.gnu.org/software/guile/old-news.html), over 8 years ago. Perhaps more importantly, GNU Guile 2.0.0 was released on 2011-02-16. That's enough time for most people to have updated beyond 1.6, and over time I expect that even fewer and fewer people will care about guile version 1.6. --- David A. Wheeler -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Readable version 1.0.2 released!
On Wed, 25 Jun 2014 05:28:39 +0800, Alan Manuel Gloria wrote: > (cond ... else) doesn't work in Guile 1.6 (it's why I coded them as > (cond .. #t) in the first place). Drat. As noted in the ChangeLog, (cond... #t) causes warnings in chicken Scheme. Hmm. We already do some text processing of kernel.scm in the final build. Perhaps we could detect if (cond ... else) is rejected in configure, and if it is, then substitute the relevant "(else ..." into "(#t ...". Does replacing all "(else " with "(#t " in kernel.scm work in guile 1.6? That would also affect some cond-expand and case statements, as well as cond statements. If we have to only substitute some & not others, we could insert some comments to enable or inhibit text substitution. That might be the simplest solution. That way most people just see "standard modern Scheme" while users of the old guile version 1.6 get working code. --- David A. Wheeler -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Readable version 1.0.2 released!
Drat. What do you suggest?
On June 24, 2014 5:28:39 PM EDT, Alan Manuel Gloria wrote:
>On Mon, Jun 23, 2014 at 3:41 AM, David A. Wheeler
> wrote:
>> Version 1.0.2 of the "readable" package is now available!!
>>
>> It's a collection of small tweaks and improvements, primarily in the
>documentation and Scheme implementation. Having many small
>improvements is a *good* thing. In particular, there are no
>incompatible interface/language changes; I view avoiding incompatible
>language changes as critically important.
>>
>> Below is the ChangeLog entry for this version, which describes the
>highlights. If you want more detail, "git log -p" will tell all.
>>
>> --- David A. Wheeler
>>
>>
>> ChangeLog for version 1.0.2:
>> * Various minor Scheme bug fixes, e.g., improve EOF handling
>during
>> symbol reading, fix detection of unsupported #.
>> * Many portability improvements, especially for Chicken
>Scheme and
>> rscheme. E.G., remove all "#:" in source,
>> change "throw" to "raise", rename internal "body" to
>"read-body".
>> Modify sweet-run so it works unchanged on Mac OS Darwin.
>> * Many changes to eliminate warnings in various Schemes,
>e.g.,
>> change (cond .. #t) to (cond .. else); either is legal
>Scheme,
>> but chicken Scheme emits warnings on the former.
>
>(cond ... else) doesn't work in Guile 1.6 (it's why I coded them as
>(cond .. #t) in the first place).
>
>> * Add the following as delimiters: #\' and #\` and #\.
>> These are not required to be delimiters in Scheme, but
>> they can be, and doing so means that we can detect syntax
>errors
>> of very dodgy constructs. This means that x'y will be
>> considered an error, not a 3-char symbol. We can already
>express
>> that as |x'y|, and (x 'y) or x('y) work for making a list.
>> * Optimize read-digits.
>> * Improve Scheme error reporting when giving "Unexpected text
>> after n-expression" by reporting the next (peeked)
>character.
>> * Add #!keyword-prefix and #!keyword-suffix support so can
>handle
>> syntax like STUFF: and :STUFF.
>> * Modify Scheme sweet-run so that it returns the program exit
>code.
>> * Add type annotations in chicken format, and ensure it does
>not
>> interfere with other Schemes like guile.
>>
>>
>>
>--
>> HPCC Systems Open Source Big Data Platform from LexisNexis Risk
>Solutions
>> Find What Matters Most in Your Big Data with HPCC Systems
>> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>> http://p.sf.net/sfu/hpccsystems
>> ___
>> Readable-discuss mailing list
>> Readable-discuss@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/readable-discuss
--- David A.Wheeler--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] Readable version 1.0.2 released!
Version 1.0.2 of the "readable" package is now available!!
It's a collection of small tweaks and improvements, primarily in the
documentation and Scheme implementation. Having many small improvements is a
*good* thing. In particular, there are no incompatible interface/language
changes; I view avoiding incompatible language changes as critically important.
Below is the ChangeLog entry for this version, which describes the highlights.
If you want more detail, "git log -p" will tell all.
--- David A. Wheeler
ChangeLog for version 1.0.2:
* Various minor Scheme bug fixes, e.g., improve EOF handling during
symbol reading, fix detection of unsupported #.
* Many portability improvements, especially for Chicken Scheme and
rscheme. E.G., remove all "#:" in source,
change "throw" to "raise", rename internal "body" to "read-body".
Modify sweet-run so it works unchanged on Mac OS Darwin.
* Many changes to eliminate warnings in various Schemes, e.g.,
change (cond .. #t) to (cond .. else); either is legal Scheme,
but chicken Scheme emits warnings on the former.
* Add the following as delimiters: #\' and #\` and #\.
These are not required to be delimiters in Scheme, but
they can be, and doing so means that we can detect syntax errors
of very dodgy constructs. This means that x'y will be
considered an error, not a 3-char symbol. We can already express
that as |x'y|, and (x 'y) or x('y) work for making a list.
* Optimize read-digits.
* Improve Scheme error reporting when giving "Unexpected text
after n-expression" by reporting the next (peeked) character.
* Add #!keyword-prefix and #!keyword-suffix support so can handle
syntax like STUFF: and :STUFF.
* Modify Scheme sweet-run so that it returns the program exit code.
* Add type annotations in chicken format, and ensure it does not
interfere with other Schemes like guile.
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] [PATCH] fix: sweet-run invokes mktemp in a Darwin-friendly way
On Sun, 15 Jun 2014 12:01:12 -0700 (PDT), "ELLIOTTCABLE" wrote: > I want to fix shebang semantics, but I am on the road right now. I will try > to get a patch together by tomorrow.— I already fixed sweet-run so that it returned the exit code of the underlying program. At least, I *think* I fixed it. Was there something else? --- David A. Wheeler -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] [PATCH] fix: sweet-run invokes mktemp in a Darwin-friendly way
On Sat, 14 Jun 2014 11:56:13 -0500, Elliott Cable wrote: > This fixes the following error arising on Mac OS X machines: > > > sweet-run something.sscp > usage: mktemp [-d] [-q] [-t prefix] [-u] template ... > mktemp [-d] [-q] [-u] -t prefix > /usr/local/bin/sweet-run: line 20: : No such file or directory > chmod: fts_open: No such file or directory > /usr/local/bin/sweet-run: line 30: ./: is a directory > > The meat of the solution is by "krinkle" [on Stack Overflow.][1] >[1]: <http://unix.stackexchange.com/a/84980> "Fix or alternative > for mktemp in OS X" Awesome, thanks!! That's now in the "devel" branch. I added a testcase specifically for sweet-run. In the process, I found that sweet-run didn't return the exit code of the executed program. So we now have a test case and another two improvements of sweet-run. Does anyone have any other changes before a new release? --- David A. Wheeler -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] Release updated "readable" package?
I'd like to release an updated readable package relatively soon. Any objections? There are no major changes, but we have a few minor ones, e.g., error-detection of x'x and static type declarations for systems that support them. There are also small documentation improvements. After trying it out a little bit I'm not sure I really want to create Lisp source files that have to undergo text processing. So although I started that discussion months ago, I doubt I'll go that direction... so there's no particular reason to wait. --- David A. Wheeler -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] readable 1.0.0 submitted to Homebrew for Mac OS X machines
On Fri, 13 Jun 2014 19:48:32 -0500, Elliott Cable wrote: > Installation on OS X is now as simple as `brew install readable`. (= That is awesome!! Thanks so much! > I'm not familiar with Common Lisp, or setting up a Common > Lisp-compatible system, so my formula only supports the Guile > installation. They accept pull-requests, if any of you wish to fix > that. > > Much love. <'3 I don't have a Mac, so I can't fix that. Perhaps someone else can! Many Common Lisp users use QuickLisp, or at least ASDF, so Mac users aren't completely out in the cold. But if we can make things better that'd be great. --- David A. Wheeler -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] spinoff wisp srfi
On Sun, 08 Jun 2014 19:50:45 +0200, Arne Babenhauserheide wrote: > > > Also despite the different focus we chose, I consider you folks to be the > > > experts on indentation-sensitive lisp, so I would be very happy to get > > > your opinion. > > > > > > > > > http://draketo.de/proj/wisp/srfi.html I didn't have a lot of time, but I took a few minutes & hope my comments help. I don't think that wisp "supercedes" SRFI-105 or SRFI-110; I would instead say it describes an "alternative to". Indeed, I suspect a system could simultaneously use SRFI-105 and wisp. "SRFI-110 improves a lot over the implementation of SRFI-49 and resolves the group-naming by introducing 3 different grouping-syntaxes ($, \\ and <* *>). These additional syntax-elements however hurt readability for newcomers a lot. They make some code written in SRFI-110 look quite similar to perl and bash:" I don't agree that they "hurt readability" at all, indeed, I think they help. I suggest changing this (and elsewhere) to something like "The author believes that these additional syntax elements impede readability because...". Also, I know both perl and bash, and the resulting code doesn't look anything like either. The "$" stuff looks like Haskell, if anything. The spec overview in 4.1 needs to clearly define *what* each syntax element does, at least as a basic case. Examples are great for clarifying definitions, but do not *replace* them. E.G., "A lone period at the beginning of a line (after any indentation) causes that line to continue the previous line." Or something like that. s/synatx/syntax/ I would move "justification" to separate section. Users often don't care WHY something is so... they just need to know what it is. I obviously agree that a better homoiconic syntax is needed for Lisp. I also obviously don't agree that the choices you've made are the best ones, since I made different choices :-). A few comments, though, besides ones already made. I have concerns that lone ":" is actually *widely* used for other purposes, e.g., type declarations, that this syntax interferes with. Similarly, "_" has many uses on its own. I think it'd be wise to grab a bunch of code and try to reformat it this way. I did that a *LOT* to create SRFI-110; a lot of syntax that SEEMS like a good idea doesn't actually work well with real code. And while simplicity is a *great* goal, too simple is its own problem. All we *really* need is 1 and 0; anything else is extraneous syntax :-). --- David A. Wheeler -- Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Damage done.
On Fri, 9 May 2014 16:00:58 -0400, John Cowan wrote: > In HTML, <* and *> Just Work, without a problem, at least if they are > surrounded by whitespace. Agreed. If I read the HTML5 spec on whatwg correctly, "<*" MUST be passed through as text in HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#tag-open-state --- David A. Wheeler -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Damage done.
> David A. Wheeler scripsit:
> > This would mean that {* x *} would be interpreted *differently*
> > by a curly-infix reader (or a neoteric reader) compared to a
> > sweet-expression reader.
On Fri, 9 May 2014 13:37:04 -0400, John Cowan wrote:
> I think that's a killer.
>
> Frankly, this is what CDATA sections were made for. Wrap your Lisp
> code in "" brackets, and < is no longer magic.
> (Note that > is never magic, though there is an escape for it anyway.)
Ah! Of course! CDATA was specifically created for this.
If you can limit yourself to XML (including XHTML) and SGML,
using CDATA sections is almost certainly the best answer.
The one caveat is that HTML doesn't support CDATA directly.
However, if you're just *processing* it as XML, you can always
read it as XML and then transform it however you like.
--- David A. Wheeler
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Unused procedures
On Fri, 09 May 2014 14:07:36 +0200, "Jörg F. Wittenberger" wrote: > BTW: I'm getting warnings about unused procedures: > > appende > > represent-as-brace-suffix? > > should those go? These *used* to be used, and my Scheme doesn't give those kinds of warnings. Hmm, I don't know of any reason they need to stay. I'd probably comment out appende, instead of removing it, just in case it has to return someday. --- David A. Wheeler -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Damage done.
On Fri, 09 May 2014 13:58:50 +0200, "Jörg F. Wittenberger"
> continuing on alias tokens for collecting lists.
>
> Two aspects have made my feelings stronger that I'd actually like {* and
> *}: A) As noted before, users usually know how to key them in. B) My
> emacs will make it easy to skip over the block in most editing modes.
>
> To get a feeling what it would take I go my hands dirty. Resulting diff
> below. Note that this code is a dirty hack by now. Where
> `my-read-delimited-list` returns '<* I should probably attach source
> info, shouldn't I?
Almost certainly yes, though I haven't examined it in detail.
> Let alone that I tend to believe that the token ought
> to be generated more generic. Furthermore there should be a
> configuration option to switch it off entirely as the other reader
> features already have.
>
> There is one more nice thing if the alias was actually to work correct:
> one could drop two more characters from the special set the programmer
> has to be aware of < and >.
>
> So far there is only so much test coverage. But I have not yet managed
> to write a test case which returns surprising results.
>
> To my current knowledge there is actually only one user-visible change
> besides {* *} becoming an alias for <* *>: the way one has to actually
> get a symbol "star" read after a {: separate it by white space to avoid
> it being taken as opening a collecting list. Is this actually all the
> damage it did? What am I missing?
This would mean that {* x *} would be interpreted *differently*
by a curly-infix reader (or a neoteric reader) compared to a sweet-expression
reader.
You might want to thoroughly test what happens as you vary the number
of parameters inside {*...*}, to ensure that you're aren't reordering in that
case.
For the Scheme implementation, I don't see any other issues offhand.
I'm not really a fan of the approach, but experimentation is always useful.
It's not clear that it'd be as easy to tweak the current Common Lisp
implementation.
The sweet-reader, once it sees "{", immediately dispatches to the reader until
}.
You might need to insert some additional logic to ensure that it doesn't do the
reordering that is normally done inside {...}.
--- David A. Wheeler
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] I've got a problem with the readability.
I exclaimed: > > Hmm. Technically I don't think "<*" is legal at all in XML. On Wed, 7 May 2014 20:05:52 -0400, John Cowan replied: > It's illegal in the surface syntax. To express it in element > content or an attribute value, you must write "<*". Yes. Which means you could write it, and then use some preprocessor to transform it into valid XML (or use a tweaked XML processor that interpreted it specially). --- David A> Wheeler -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] I've got a problem with the readability.
On Wed, 07 May 2014 21:18:34 +0200, "Jörg F. Wittenberger" said:
> ... However in my case the XML
> parser *always* gets the source code first. And the source is
> re-created from the parsed tree upon need. The sweet-read procedure
> only sees some element's literal content.
>
> In other words: the users sees all #\< and #\& characters within
> sweet-read LISP code always quoted according to XML.
Hmm. Technically I don't think "<*" is legal at all in XML.
It's not a legal Start-Tag in XML, for example, see:
http://www.w3.org/TR/xml/#dt-stag
http://www.w3.org/TR/xml/#NT-NameStartChar
HTML5 similarly says that "<*" won't be treated as a tag, and is instead
just output as text:
http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#tag-open-state
You might be able to exploit that fact to automatically convert in an
easy-to-use way.
In particular, you may be able to convince your library to just pass that
through
unscathed, or pre/post process it to make it work easily.
> Hm. I must admit that I understand much too little about Common List to
> make a qualified statement.
>
> Let alone that I'd dare to judge how hard the implementation would end
> up to be.
>
> However: Am I correct to understand that this would be one
> implementation problem?
Yes, though it's rather specific to {} and [].
> If so, than I'd rather wholesale defer the consideration. In favor of
> readability of the source code and "being the most natural choise"
> (whatever that would be ;-).
>
> At the moment I'm behind the language design, since I see this as the
> whole point of readable lisp. Once it's clear what would be the best
> thing to have, I'd return to consider the hardship of implementation.
> At worst that might end up being an iterative process.
Excellent!!
I said:
> > Here's an idea: Can you use full Unicode (encoded, say, as UTF-8)?
> For a couple of seconds I thought: this genius! I should have though of
> that.
...
> But there's the catch: we are still talking about source code to be
> keyed in by developers. Some keyboards might have additional pairing
> characters. Mine for instance has « and ».
>
> Though from a developers point of view, I'd expect myself to be in a
> situation sooner or later, where I need to key them in from a dump terminal.
>
> That's why I feel we should avoid those here.
Even "dumb" terminal emulators almost always have mechanisms to input other
characters.
The problem is that they differ from system to system, so you may have to look
up
how to do it. A survey is here:
https://en.wikipedia.org/wiki/Unicode_input
If you choose an unusual Unicode pair, and always use UTF-8 encoding,
it might be easy to pre/post process. Practically everyone's fonts have lots of
glyphs (though maybe not ALL the glyphs you want!).
> After all: If I have to deviate from the spec, it does not matter how
> much. The hardship of maintaining an implementation remains.
Some deviations are a lot easier to implement or undo later, though.
--- David A. Wheeler
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] I've got a problem with the readability.
On 07 May 2014 21:48:45 +0200, Jörg F. Wittenberger
wrote:
> it just occured to me that |* and *| might be good aliases to <* and *>
> too. If { and } could be problematic.
Those would *look* okay but wouldn't work on many Lisps (Common Lisp, Scheme).
The "|" introduces a literal atom on many Lisps.
> Just: those in turn... hm, does the sweet read code actually rely on the
> read implementation of the underlying Scheme? I had the impression that it
> would read char by char anyway.
There are currently at least 3 current implementations of sweet-expression
readers:
1. The Scheme one (tested mostly with guile)
2. Common Lisp
3. ANTLR/Java implementation (primarily for grammar analysis).
Anyone can always implement another. We want it to be as easy as possible
to implement it, while limiting the difficulties of doing so.
--- David A. Wheeler
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] I've got a problem with the readability.
On Thu, 01 May 2014 13:58:07 +0200, "Jörg F. Wittenberger"
> Q2: Would it be a good idea to allow this in the official spec?
> Embedding in XML seems to have broad uses these days and I foresee use
> cases for sweet list especially in domain specific languages.
I really want to keep the spec stable for a while (though that doesn't stop
experimentation with various extensions).
I've done some experiments generating HTML/XML, but like this:
!
! !
and with that approach there's no issue.
Using {*...*} would probably be a challenge for many implementations.
IIIRC, in the Common Lisp implementation "{" and "}" are treated a lot like
"(" and ")", that is, they are their own tokens, and there's no real
opportunity to re-connect them later. So I'd discourage the use of {*...*}
specifically.
Here's an idea: Can you use full Unicode (encoded, say, as UTF-8)?
You could then use additional pairing markers, there are a whole bunch
in math and quoting markers. Then there'd be no overlap.
For example, you could use the Ogham feather mark pairs:
U+169b Ps OGHAM FEATHER MARK ᚛
U+169c Pe OGHAM REVERSED FEATHER MARK ᚜
Or brackets with quills:
U+2045 Ps LEFT SQUARE BRACKET WITH QUILL ⁅
U+2046 Pe RIGHT SQUARE BRACKET WITH QUILL ⁆
Some folks have tried to create a list of these paired characters here:
https://stackoverflow.com/questions/13535172/list-of-all-unicodes-open-close-brackets
I'm not sure what the best symbols would be... we could try them out
on many systems to see how they look.
These could be considered synonyms, as extensions to the existing system.
--- David A. Wheeler
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] My first attempt: a process manager
> On Sat, Jan 4, 2014 at 12:07 AM, Mike Gran wrote:
> > Hi. I thought I'd take a stab at using your readable project
> >
> > Result is attached. It is a process manager: a structure holds
> > a list of functions and data and call the functions as a unit.
> > Functions that return #f are removed from the manager, and
> > functions that return #t are kept.
> >
> >
> > My impressions are pretty favorable. I didn't love the
> > let block syntax, so I used defines instead.
I'm really glad they were overall favorable.
On Fri, 10 Jan 2014 21:08:06 +0800, Alan Manuel Gloria
wrote:
> Yes, let syntax is a big drawback with the "indentation implies
> parentheses" strategy.
Nothing is perfect, but I think it's very reasonable
We have a general solution using leading "\\"
that easily handles all cases, and <*...*> is a useful shorthand for handling
let statements with short variable-definition blocks.
> As a complete aside, in Haskell, there's a special "fallback" rule
> where an error due to indentation matching will cause the parser to
> attempt to close a group. This rule usually triggers in Haskell's
> let...in syntax (basically, the "in" keyword is generally a syntax
> error except after a let group, so the parser usually errors here when
> indentation is used), which seems to imply to me that even Haskell has
> some trouble with let syntax, which was simply "fixed" with this
> hackish solution.
>
> xref http://www.haskell.org/onlinereport/syntax-iso.html#sect9.3 ,
> particularly Note 5.
Fair enough. Again, nothing's perfect.
> > Also, I used
> > 'cond' in lieu of 'if' because I liked the look of having
> > an 'else'.
>
> Yes, the "old" syntaxes like that tend to be very pretty in indentation
> syntax.
I think "if" looks great:
if {x < y}
! x
! y
Obviously if you want a *keyword* to mark the else clause, that doesn't do it,
but in that case "cond" is the better choice anyway.
--- David A. Wheeler
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] My first attempt: a process manager
That is awesome! Thanks for letting us know! Mike Gran wrote: >Hi. I thought I'd take a stab at using your readable project > >Result is attached. It is a process manager: a structure holds >a list of functions and data and call the functions as a unit. >Functions that return #f are removed from the manager, and >functions that return #t are kept. > > >My impressions are pretty favorable. I didn't love the > >let block syntax, so I used defines instead. Also, I used >'cond' in lieu of 'if' because I liked the look of having >an 'else'. > >It works for me with Guile 2.0.9 and Readable 1.0. >Thanks, > >Mike Gran > > > > >-- >Rapidly troubleshoot problems before they affect your business. Most IT > >organizations don't have a clear picture of how application performance > >affects their revenue. With AppDynamics, you get 100% visibility into >your >Java,.NET, & PHP application. Start your 15-day FREE TRIAL of >AppDynamics Pro! >http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > > > >___ >Readable-discuss mailing list >Readable-discuss@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/readable-discuss --- David A.Wheeler-- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] treatment of quote symbol
I said: > > To be honest, I think we should treat x'x as an error in the sample > > implementation (though guile treats x'x as a single symbol). You can > > always use |x'x| if you mean that, and if you mean (x 'x), we already > > have several much clearer ways to express that: > On Fri, 6 Dec 2013 10:58:25 -0500, John Cowan wrote: > +1 Okay, I've pushed that change, and it now reports more specifically what the problem is. That means that x'y is no longer legal... and it will *immediately* identify that as an error (and report the failing character, ' in this case). This was never specified in SRFI-110 (or Scheme), so it's not a spec change... it's just a way to more strict in a standards-compliant way. --- David A. Wheeler -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Reorganize to reduce namespace pollution and maximally create library
John Cowan dropped the following bad news: > >> Dude, you have a hold of the Tar Baby here. R6RS and R7RS libraries > >> can't be the result of a macro, neither as a whole nor in part. All > >> you've done is trade off one set of portability breakers for another. > > I said: > > Ugh. In that case, maybe we should just drop the > > "readable-kernel-module-contents" > > macro altogether, and just write straight code with weird names to > > reduce possible namespace problems. > > We can include cond-expand guile magic so that it works as-is as a guile > > module. > > > > Alan: Any objections? On Fri, 6 Dec 2013 12:12:51 +0800, Alan Manuel Gloria wrote: > None whatsoever. > > I think Jorg's proposal to make a file (the "shar") that makes the > output based on the detected Scheme implementation is good. We could > even run the file multiple times to generate different outputs, one > for each Scheme supported and detected. > > I propose this system: > > 1. We write as if we own the namespace. Select some suitable soup of > features from R4RS through R7RS, and define it in comments well in the > core implementation file. The core implementation file is then just a > bunch of (define ...) forms, possibly with some hooks on options like > "CL mode" or "Scheme mode". > > 2. Write a bunch of "shar"s, which take the original file and > transform it to code that a particular Scheme implementation-version > accepts. Basically, it just prepends and appends some additional > code, probably just plain text, to the core implementation file. The > shar can put the entire core implementation file within some sort of > (define-library... ) form, if needed. > > 3. If a particular Scheme implementation-version supports parameters, > then the "CL mode" option can be made into a parameter. If not, it > can be a global instead. We document this in, say, a USAGE.Chicken or > USAGE.Guile-1.8 or whatever file. > > For example, a "standard R5RS shar" would just wrap the implementation > file in something like: > > #! /bin/sh > > IN=$1 > OUT=$2 > > cat > $OUT < (define (readable%is-cl-mode) > readable%cl-mode) > (define readable%cl-mode #f) > > (define readable%whatevers > (let () > PREFIX > cat $IN >> $OUT > cat > $OUT < (list sweet-read neoteric-read curly-read) > ) ;let > ); define readable%whatevers > > (define sweet-read (car readable%whatevers)) > (define neoteric-read (cadr readable%whatevers)) > (define curly-read (caddr readable%whatevers)) > SUFFIX Hmm. Generating code is reasonable of course. One problem with the "shar" approach is that common code will be copied into different separate files, and eventually not consistently maintained. I'd like to say "one thing once" as much as possible (for maintenance). A variation would be to create ONE shell script that can generate (to stdout) Scheme code for the variant identified in a parameter; it could "cat" the main code at the right time. Something like: = #!/bin/env sh # $1 is the type to generate. case "$1" in GUILE) echo "..." ;; *) echo "..." ;; esac cat kernel.scm = A completely different approach is a cpp-like tool. I've cobbled together an awk implementation of cpp-like syntax so you can do this: #ifdef GUILE ... #elseifdef RSCHEME ... #else ... #endif Either one would mean that we only need to say something ONCE if it can be used in multiple circumstances. --- David A. Wheeler -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] treatment of quote symbol
> David A. Wheeler scripsit:
> > What do you think x'x *should* mean? That's incredibly ugly!
On Thu, 5 Dec 2013 13:08:53 -0500, John Cowan wrote:
> Its meaning is specifically left up to the implementation. Apostrophe
> is neither a (required to be treated as part of the
> identifier) nor a (required to be treated as not part of
> the identifier). Its general category is Po, which means that in R6RS
> and R7RS implementations are explicitly allowed to treat it as part of
> the identifier.
> <http://trac.sacrideo.us/wg/wiki/QuoteDelimiter> reports what Schemes
> actually do. Only a few of the major implementations actually allow
> x'x as an identifier.
SRFI-110 depends on other specs to define what symbols etc. are,
so formally SRFI-110 gives us a lot of freedom.
To be honest, I think we should treat x'x as an error in the sample
implementation
(though guile treats x'x as a single symbol). You can always use |x'x|
if you mean that, and if you mean (x 'x), we already have several
much clearer ways to express that:
(x 'x)
x('x)
x 'x
I'm guessing Joerg Wittenberger wants something else, though :-).
So let's talk about that.
It would probably be difficult to support x'x as 2 adjacent expressions
in many implementations in one special case: bare initial indents.
Since "read" must return, we depend on the unconsumed space or tab
to let us know that we're reading in the next item with an initial intend.
If we peek an apostrophe and don't consume it, there's no space or tab to
inform.
It might be possible to support x'x as 2 adjacent expressions in other cases,
though it might be awkward. Generally, if we consume an expression
and there's nonwhitespace left over, we complain about it,
as part of the general system to detect errors.
E.G., it-expr-real's complains about "Unexpected text after n-expression"
and we'd have to modify things to permit it.
It seems to me that x'x is almost certainly a mistake, and should cause an
immediate
read failure as part of early error detection. There are so few opportunities
for early error detection!! Thoughts, anyone?
--- David A. Wheeler
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] treatment of quote symbol
On Thu, 05 Dec 2013 13:14:34 +0100, "Jörg F. Wittenberger" wrote: > Hi all, > > it's beginning to annoy me: normal Scheme readers treat quote and > quasiquote symbols as terminating charachters when reading symbols. > > With the "readable reader" they suddenly become part of a symbol. That's > all rather confusing and causes so much incompatibility. > > Its this really intended or just an oversight? What do you think x'x *should* mean? That's incredibly ugly! --- David A. Wheeler -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Reorganize to reduce namespace pollution and maximally create library
I said: > > At the least, I could put things in different files, and then use "cat" > > to create files usable to different systems. On Tue, 26 Nov 2013 14:47:36 +0100, "Jörg F. Wittenberger": > Not too bad and idea. While it might not scale to whole programs, it's > certainly a valid way to get things done for something the size of a > srfi's implementation. Right. This thing is small. I don't see anything good for trivial preprocessing: * "scmxlate" appears too complex to get going. * "cpp" is a disaster for Lisp (it wants to parse '...' as character constants) * "m4" is easy to get wrong, and has too much functionality. I think I could create a simple "#ifdef ... #elifdef... #else... #endif" preprocessor in awk (which is in the POSIX standard) that would do the job. Then the whole thing could be in one file, and generate variations for different purposes. For those Schemes with cond-expand, we could put them in one file, so we wouldn't have to generate too many files. --- David A. Wheeler -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] using t-expressions
I said: > > The ONLY procedure that throws an exception is "read-error": > >(define (read-error message) On Tue, 26 Nov 2013 15:11:39 +0100, "Jörg F. Wittenberger" wrote: > I changed it's signature to match srfi-23 (for know) > > (: read-error (string &rest * -> *) Okay, but you'll need to modify the procedure definition to match. > But I tend to prefer a more restrictive, though compatible, syntax in > this case > > (: read-error (string input-port string &rest * -> *) Please don't. The intent was to be syntactically consistent with "error" as defined in srfi-23 and R7RS. Someone can always modify the error port to change where it goes. Oh, I presume you mean "output-port" not "input-port" there. > Whereby I'd require all calls to read-error to pass the port and the > last successfully read token in an effort to further improve error messages. Why not just pass "last successfully read token" as a parameter after the string? > > The ONLY procedure that catches an exception is t-expr-catch: > >(define (t-expr-catch port) > > (init-sweet) > > (guard > >(exception > > ((eq? exception 'readable) > > (read-to-unindented-line port) (t-expr-catch port))) > >(t-expr port))) > > > > Is there actually any scheme implementation which benefits from this > catching? I can't image. Our processing program does, because it tries to process as well as it can. But we could change the interface. > I'd feel it might be good to provide a "clean up read" like > `read-to-unindented-line` to help the implementor of a repl. But for > the default it just does not feel right to me. Okay. An easy approach would be to raise an exception on error, and add an option to permit the current behavior (catch and retry). That's an interface change, but the SRFI doesn't define specifics on how to handle errors (since Schemes vary in this matter), and it makes sense that people will want to get errors. Guile 1.8 doesn't support srfi-23 or R7RS, so that would need to be implemented separately on guile. --- David A. Wheeler -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Reorganize to reduce namespace pollution and maximally create library
I said: > > > I'll note that my Common Lisp implementation "just works", On Tue, 26 Nov 2013 11:29:49 -0500, John Cowan wrote: > Well, yes. Common Lisp is a pretty thorough standard, and as such > it has a fairly large number of actively developed implementations, > as languages go: ABCL, CCL, CLISP, CMUCL, ECL, MKCL, SBCL. But that's > nothing compared to Scheme's seventy-seven or so. It's not the number of implementations, it's the lack of a widely-implemented standard way to invoke basic capabilities, such as a module system, exception system, and hash tables. Heck, not even macros (a Lisp basic) are completely universal. If there were 77 Schemes that agreed on all those, it'd be fine. > As a developer, I stick to Chicken and Chibi, and resolutely ignore the > (mis)behavior of other Schemes. I have the same basic approach (using "guile" as the list). Here's hoping that R7RS, especially R7RS-large, will make it possible to unify the islands. I think Scheme would be more compelling if people could actually work together :-). --- David A. Wheeler -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Reorganize to reduce namespace pollution and maximally create library
> David A. Wheeler scripsit: > > How about cond-expands at the beginning to handle much of the shimming, On Mon, 25 Nov 2013 12:08:47 -0500, John Cowan wrote: > As of the last time I looked, cond-expand wasn't supported by Racket, > Scheme48/scsh, Larceny, Ypsilon, S7, or Sizzle. It just gets worser and worser. Putting the text in *different* files and leaving them there *also* appears to be non-portable: * R5RS "load" doesn't guarantee that loading is relative to the directory of the current file (or provide any other guarantee about current directory), and has no "include" at all. * R7RS does have "include" (4.1.7. Inclusion), though it merely "encourages" searching the same directory as the caller of include (and certainly doesn't guarantee searching there FIRST, so it's just begging for security vulnerabilities just like PATH=".:$PATH"). Maybe it's time to break out cpp or sed :-(, or use some other tool to generate various files for different Scheme implementations. The "configure" program already modifies the file anyway, so that might not be insane. At the least, I could put things in different files, and then use "cat" to create files usable to different systems. I'll note that my Common Lisp implementation "just works", and it even overrides the reader. In contrast, a common answer seems to be "don't bother trying to write portable Scheme": http://stackoverflow.com/questions/11062320/writing-portable-scheme-code-is-anything-standard-beyond-r5rs-itself I *like* Scheme, but it's starting to feel like an abusive relationship :-). --- David A. Wheeler -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] using t-expressions
On Mon, 25 Nov 2013 12:24:23 +0100, "Jörg F. Wittenberger" wrote: > Hi all, > > I'm just making my first experiences in actually using srfi-110. > > At this point I find myself forced to make serious changes to the > program logic. Beyond what's supported by simply configuring the source > code. > > The worst thing I found that it will complain on the error port when > reading badly formatted code and then continue to read. I really, > really need it to do what other Scheme readers usually do: error out. Easily done, and there are many ways to do it. The ONLY procedure that throws an exception is "read-error": (define (read-error message) (display "Error: " (current-error-port)) (display message (current-error-port)) (newline (current-error-port)) (flush-output-port (current-error-port)) (raise 'readable) '()) The ONLY procedure that catches an exception is t-expr-catch: (define (t-expr-catch port) (init-sweet) (guard (exception ((eq? exception 'readable) (read-to-unindented-line port) (t-expr-catch port))) (t-expr port))) > What's even worse: simply complaining and the *continue to read* as if > nothing had happened results in strange, stupid and wrong messages from > the interpreter caught later. Example: an error in (define x ..) ends > up and "x unbound". Quite irritating. Well, it actually consumes text until it hits a blank line. > Should this become yet another config option for the code, or should we > simply resort to the more "standard" behavior and error out via srfi-26 > compatible code? This could even be a run-time configuration option. Does anyone have a preference? --- David A. Wheeler -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Reorganize to reduce namespace pollution and maximally create library
John Cowan: > Dude, you have a hold of the Tar Baby here. R6RS and R7RS libraries > can't be the result of a macro, neither as a whole nor in part. All > you've done is trade off one set of portability breakers for another. Ugh. In that case, maybe we should just drop the "readable-kernel-module-contents" macro altogether, and just write straight code with weird names to reduce possible namespace problems. We can include cond-expand guile magic so that it works as-is as a guile module. Alan: Any objections? John: I take it that prefixed "%" is a universally-portable indicator we can use for "internal" names? > Adapting it to X Scheme's > notion of a module should be left to X Scheme experts. The notion that you have to be an "X Scheme expert" to merely define or use a module is absurdly broken. Here's to hoping that R7RS library module notation gets universally implemented, and quickly, so that such nonsense can go to the dustbin of history. > This is what I've been doing with my SRFI implementations: plain > code, plus a shim file to add stuff from R7RS-small that I need, > plus modules for Chicken (R5RS-plus) and Chibi (R7RS), both of which > fortunately support "include". Yes, it's more complex to use than one > all-singing-all-dancing file. But it's much easier to port, even if it > does less of the work for you. How about cond-expands at the beginning to handle much of the shimming, followed by clean code, and separate files to create modules and include them? That should be fairly widely available (I hope!). --- David A. Wheeler -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] Type declarations
We now have Chicken Scheme type declarations, thanks to the work by Jörg F. Wittenberger. Chicken Scheme type declarations are defined here: http://wiki.call-cc.org/man/4/Types Racket also includes type declaration language: http://docs.racket-lang.org/ts-guide/ Naturally, Racket's system is very similar but syntactically incompatible, continuing the usual Scheme hostility towards portability :-(. For such a beautiful language, ugly Scheme code is sure a common result :-(. Maybe we should use a term other than ":" and let macro systems define them into the local type system. That assumes that type systems like Chicken and Racket accept the results of macros. But *can* we use macros to generate "(: ...)" type declarations? Should we? --- David A. Wheeler -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] initial support for rscheme
"Jörg F. Wittenberger": > The problem is not cond-expand, but rscheme accepts define-macro only at top > level. R5RS also limits define-syntax to the top level. R6RS and R7RS relax this, but not everyone's there currently. (See below). We could use cond-expand to define top-level macros if the Scheme implementation provides no alternative. In the other cases, we could provide a cleaner namespace for invokers. We don't define many macros, I only see ":", "no-values", "readable-kernel-module-contents", and "let-splitter". We could rename "let-splitter" to "readable-let-splitter", and "no-values" to "readable-no-values", to reduce the risks of namespace issues. I'd hate to use something other ":". --- David A. Wheeler P.S.: Here's define-syntax info for R5RS, R6RS, and R7RS: * R5RS states that define-syntax syntax definitions "are valid only at the top level of a program" (section 5.3, Syntax definitions). This is relaxed later: * In R6RS, "Keyword bindings established by define-syntax are visible throughout the body in which they appear, except where shadowed by other bindings, and nowhere else, just like variable bindings established by define." (Section 11.2.2). * R7RS relaxes this restriction; it describes define-syntax and says that "syntax definitions can appear at the outermost level or nested within a body (section 5.4, syntax definitions). -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] initial support for rscheme
On Sat, 23 Nov 2013 11:28:22 +0100, "Jörg F. Wittenberger" wrote: > Did I say "next week"? I should rather do something else, but I can't > fight myself. :-/ Excellent! They're merged in the repo now, although I had to make a number of changes to make guile work. > Bad news this time. > I'd now rather take back my suggestion to macro-define around: while it > would work for the call site, I have no (good) idea how to change the > definition. No problem. I don't mind violating the naming convention for portability, as long as we document *why* in a comment. I added such a comment, and accepted your renames. > Furthermore bad news regarding the idea to move those cond-expand's into > the read-able-module-contents. > The problem is not cond-expand, but rscheme accepts define-macro only at > top level. Ugh. I see no way to avoid having some leakage into the invoker's namespace in those cases. We can probably rename those things to make them unlikely to matter, e.g., including "readable-" prefixes in them. We should probably split up the cond-expands so things that HAVE to be expanded outside, for a given implementation, are done... and everyone else has a cleaner interface. > The attached patch has a strange name in a way, considering that it > contains much more than this. However it also fixes a bug in > n-expr-or-scomment. Not a problem, I split it into multiple commits anyway. I ended up doing modifying it so that guile will work. Please test and see if my modifications also work for you! > David, could you merge this into the git repo? Done, with mods as noted above. In the longer term we should reorganize it, to limit name leakage, but it may be easier to first make sure it *runs* on these different Schemes. *grumble* Scheme should have had a standard module system, decades ago *grumble*. Using macros to work around the lack of a universally-implemented module system is awkward and imperfect. > The next thing I'd try > to get around would be making those settings port specific. But I'd > rather like to keep those diffs size down. Smaller diffs sounds awesome to me!! --- David A. Wheeler -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] initial support for rscheme
On Fri, 22 Nov 2013 10:26:58 +0100, "Jörg F. Wittenberger" wrote: > Against which file version should I do the patch? Please use the latest version in git repo on "develop" branch. I've already incorporated some of the changes you just submitted, basically the type annotations and a tweaked version of your "translate-cl". It's *easiest* for me if you use git, but you don't need to. If you don't want to install and use git, you can download the current version this way: http://sourceforge.net/p/readable/code/ci/develop/tree/src/kernel.scm?format=raw ... but please let me know when you downloaded it. That will make it is easier for me to integrate if there are other changes. > No, it does not compute any value upon entry... You're right, sorry. ... > > the case should compute and return ONLY what it needs to compute. > > I presume that this isn't working: > > '+++CL-QUASIQUOTE-abbreviation+++ > > but you could replace *just* that with this format, yes?: > > (string->symbol "+++CL-QUASIQUOTE-abbreviation+++") > > Yes, I could. But THIS would be one computation for each invocation (of > the matching case here). Now this is rather cheap: a hash table lookup > per quasiquote/unquote/unquote-splicing which in turn are rare. Okay. It's not clear to me that this optimization is worth it, but I think with the addition of a type declaration it'll be obvious enough. Let's just add the type declaration and do it as proposed. > > Why all the redefines from "body" to "read-body"? > > We normally use the same name as per the grammar. > > RScheme idiosyncratic: `body` is already a bound elsewhere within some > code required com compile this code. > Hence RScheme complains about the "semantic error" and that redefinition > would break things. > > The only reasonable way I saw was to change the name to avoid the conflict. > > However by re-considering the case now I understand that the desire to > keep `body` there literally to match the grammar. In that case we > should macro-define body into read-body for RScheme only. If Rscheme will accept that without complaint, that'd be very nice. Otherwise, I'm happy to rename definitions to make it work... I just want to minimize it, and document why there's a variance when it happens. > As I said, busy by now. Maybe next week if things go well. Okay! I look forward to it. Thanks so much for your time. --- David A. Wheeler -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] initial support for rscheme
I said: > > '+++CL-QUASIQUOTE-abbreviation+++ On Thu, 21 Nov 2013 22:56:10 -0500, John Cowan wrote: > Some Schemes may have problems with this kind of symbol, one that > begins with a character that can begin a number (+, -, and ... are > exceptions). Neither R5RS nor R6RS permits them. Yeah, and I knew better too. In any case, I think this should be fine: (string->symbol "+++CL-QUASIQUOTE-abbreviation+++") --- David A. Wheeler -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] initial support for rscheme
On Thu, 21 Nov 2013 12:29:58 +0100, "Jörg F. Wittenberger" wrote: > The attached diff makes the whole thing compile under rscheme too (and > run some simple tests). > No changes where made, which where not strictly necessary to that end. Excellent! Thanks so much for your work! I have a few comments and questions below... please modify after taking a look at the comments and resubmit. > I'm sure you'll take issues with the positioning of cond-expand'ed stuff. :-). > I tried for now to keep the compatibility layer before the actual > module. But that might leak definitions (like the rudimentary guard > implementation) outside, which would have to be avoided. For this to we > would have to move the whole section into the body of > `readable-kernel-module-contents`, right? Correct. To the extent that we *can*, I think we need to move things inside the macro that creates the module to minimize leakage. So if you would please maximally move the macro definitions inside the module creation macro, that'd be great. I'm pretty sure we cannot put the "create a module" macro inside the module. Guile's "define-module" lets us scope things, but I doubt that approach will work everywhere else. I don't see how to avoid that. But if we have to leak names, hopefully it'll be just be a single "readable-kernel-module-contents" macro, which is rather unlikely to conflict elsewhere :-). Someday in the great grand future all Scheme implementations will implement a standard module system. Then we wouldn't have the problem... but today is not that day. I really don't like how "translate-cl" was changed. I strongly prefer: (define (translate-cl x) over: (define translate-cl ... (lambda (x) ... )) because it's MUCH easier in the first format to determine that this is a procedure that accepts exactly one parameter. Also, the patched version will calculate 3 values on every entry; the case should compute and return ONLY what it needs to compute. I presume that this isn't working: '+++CL-QUASIQUOTE-abbreviation+++ but you could replace *just* that with this format, yes?: (string->symbol "+++CL-QUASIQUOTE-abbreviation+++") Why all the redefines from "body" to "read-body"? We normally use the same name as per the grammar. We could do that if it's important to port to rscheme, I just want to know why before making the change. I presume you had a reason; if so, we need to document why this is an exception to the naming convention. Basically, just add a comment at the definition of "read-body" to explain why the naming convention is NOT being followed. Could you resend the patch, per those comments? Overall this looks really promising. --- David A. Wheeler -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] A road block: #:
On Tue, 19 Nov 2013 09:36:50 +0100, "Jörg F. Wittenberger" wrote: > while all the Scheme's I > know process nested cond-expand forms I recall that srfi-0 explicit does > not requites this to be the case and suggest to avoid such use. Yes, the text you're remembering is: "The construct is restricted to the top level of a program in order to simplify its implementation and to force a more disciplined use of the construct (to facilitate reading and understanding programs) and to avoid (some) misunderstandings related to the scope of features. These restrictions can of course be lifted by some Scheme systems or by other SRFIs (in particular module system SRFIs)." However, as the SRFI-0 text anticipates, I don't see how to use cond-expand at *only* the top level, define a library using just R7RS constructs, *AND* avoid importing "other cruft" into the library's importer. I may be missing something obvious, suggestions welcome. Otherwise, at least one of those ideals will have to give, hopefully as minimally as possible. --- David A. Wheeler -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] A road block: #:
On Tue, 19 Nov 2013 09:36:50 +0100, "Jörg F. Wittenberger" wrote: > However I have a problem with another change: while all the Scheme's I > know process nested cond-expand forms I recall that srfi-0 explicit does > not requites this to be the case and suggest to avoid such use. > > Should be have these nested cond-expand's? I would *expect* it to work, but I don't see any information about nested cond-expands in: http://trac.sacrideo.us/wg/wiki/ImplementationContrasts John Cowan may know if nested cond-expands port in practice (among systems with cond-expand). > Also: often different Scheme's can share different code parts. Enforcing > a single cond-expand with nested cond-expands is not only against > srfi-10; I can foresee how this will complicate the code and require > quite some repetition and confusing logic in those conditions the > cond-expand's dispatch on. Let alone that alternatives, which belong > logically together are spread around in the file. That's a nightmare to > maintain. Hence: I'd prefer to cluster all cond-expands at the > beginning, but have one cond-expand per dispatch reason. Great rationale, makes sense. Okay, we can try it. My one concern is that we need to try to scope all of this shim stuff so that it *only* affects our module. Anything we define here should not affect names in other modules or the invoker (other than the functionality the invoker imports). I will say that a nontrivial amount of the guile stuff is interrelated, so I fear this approach may make it harder follow the guile portion. But maybe not. The obvious approach is to try and see. David A. Wheeler -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] A road block: #:
> Am 18.11.2013 15:25, schrieb David A. Wheeler: > > On Mon, 18 Nov 2013 13:23:32 +0100, "Jörg F. Wittenberger" > > wrote: > > > >> In a first attempt to feed the source to some other Scheme I went ahead > >> and sent it to the rscheme compiler. > >> > >> Doesn't work. It has the same problem as Guile: it will refuse to read > >> certain #sharp syntax. Okay, the source code no longer has "#:". The result is extremely magical guile code, to work around some wonkiness in old versions of guile, but the magic is explained in comments. --- David A. Wheeler -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] noop patch - add type information
On Mon, 18 Nov 2013 12:09:43 +0100, "Jörg F. Wittenberger" wrote: > Attached a slightly better version of the "add types" patch. This one > replaces (values) with a (no-values) syntax from the compatibility layer > and has those procedures, which used to return no values or undefined > values type-annotated as returning undefined. Thanks! I had to tweak them, but we now use (no-values). Note: Yesterday I added annotations for some of the procedures you didn't annotate. --- David A. Wheeler -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] A road block: #:
On Mon, 18 Nov 2013 19:21:51 +0100, "Jörg F. Wittenberger" wrote: > No comments so far on the possibility to put these things into > platform-specific files? I'd rather not. That raises the spectre of trying to read them back in, as well as getting them installed in the "right" places. E.G., if you refer to it, is that relative to your current directory or the directory of "this" file? A single file, with a portability front section and a clean main implementation, would be a lot easier to deal with given that Schemes can't seem to agree on pretty much anything when it comes to modules. --- David A. Wheeler -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Fwd: Re: Supporting SRFI-110 in chicken (Joerg Wittenberger)
On Mon, 18 Nov 2013 10:56:41 +0100, "Jörg F. Wittenberger" wrote: > So far I did not understand why does this have to be port-specific in > the first place. Maybe that would be the killer argument. It's by analogy to other read settings, such as fold-case, so it's spec'ed that way. > Maybe not: at least in my case, I'd be *happy* to have a way to > compile-time the feature away eventually, since I know these settings > will not change. The current implementation is close to that. Currently settings like these are global to the implementation. In practice, most people don't futz with these settings (except at program begin), so it's worked fine. --- David A. Wheeler -- DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Fwd: Re: Supporting SRFI-110 in chicken (Joerg Wittenberger)
On Mon, 18 Nov 2013 12:19:21 +0100, "Jörg F. Wittenberger" wrote: > I wonder: the code already creates "fake port" object wrappers. Wouldn't > this be the natural place to stick such per-port settings into??!! That's not a bad idea. I was hoping for the "fake port"s to be a temporary shim for certain cases, not something we end up using everywhere, but I think you're right that it's plausible. --- David A. Wheeler -- DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] A road block: #:
On Mon, 18 Nov 2013 13:23:32 +0100, "Jörg F. Wittenberger" wrote: > In a first attempt to feed the source to some other Scheme I went ahead > and sent it to the rscheme compiler. > > Doesn't work. It has the same problem as Guile: it will refuse to read > certain #sharp syntax. > > **HALT** > error: scan-token:439: #\# cannot be followed by #\: > > Is there a way in Guile to split source in multiple files? Would it > acceptable to split the compatibility section out of the main code for > sweet/kernel? Otherwise I don't see how to proceed for rscheme and > foresee the same problem around the corner for some other Schemes too. I presume the problem is in this guile-specific code: (use-modules ((srfi srfi-69) #:select We can't replace #:select with (symbol->keyword 'select) unfortunately; guile won't recognize it. I suspect what we should do is right there temporarily have guile use prefix keyword notation (:select), using something like (read-set! keywords 'prefix), and then restore whatever was there before. Then other Schemes can read it. --- David A. Wheeler -- DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] Getting the current development snapshot
On Mon, 18 Nov 2013 10:48:33 +0100, "Jörg F. Wittenberger" wrote: > I'll deal with that. David, should I just keep patching or do you have > a current snapshot of the accepted patches so far for me? It's always easiest to send me patches based on the git repo. Snag your own copy of the repo with: git clone git://git.code.sf.net/p/readable/code readable-code cd readable-code git checkout develop From then on, "git pull" will update from the remote repo. If you can't use git, you can snag just the kernel.scm file (develop version) from: https://sourceforge.net/p/readable/code/ci/develop/tree/src/kernel.scm?format=raw Note that the "develop" branch is what changes in development, while the "master" branch holds final distributed versions. --- David A. Wheeler -- DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] noop patch - add type information
On Sun, 17 Nov 2013 21:31:34 +0100, "Jörg F. Wittenberger" wrote: > In an attempt to better understand and document the source code I added > type annotations (using the chicken's syntax and using chicken to verify it). I've merged it in, thanks! I had to do some magic to make guile accept it, oddly enough. (*grumble* default stack too small *grumble* macro weirdness *grumble*.) --- David A. Wheeler -- DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] noop patch - add type information
> David A. Wheeler scripsit: > > I like this idea. In a few places this patch changes return values > > to intentionally return (values)... which is also okay by me. On Sun, 17 Nov 2013 20:33:16 -0500, John Cowan wrote: > For the record, I've never been a fan of returning zero values when you > have nothing in particular to return. R6RS and R7RS authorize returning > multiple values where the continuation ignores the values, but R5RS > does not, and indeed SCM, SigScheme, Shoe, and Owl Lisp do not permit > it: they throw errors to `(begin (values) 3)` and `(begin (values 1 2) > 3)`, rather than returning 3 as other R5RS systems do. Yec. That is just mistaken, erroneous, fallacious, ill-judged, and in a thousand other ways wrong. It may be standards-compliant, but still wrong. That is really awful, I would never have guessed that. Since the return value CAN'T matter, it SHOULD NOT matter!!! Thanks for letting us know - that would clearly impact portability. > In my own code, > I always return the value of `(if #f #f)`, which is typically a Scheme's > undefined-value value. Yes, but if that gets back to the REPL it may do something funny. By definition that is undefined. > But I can live with it. Yes, but I want to make this *more* portable not *less*. Maybe we should define our own "no-value" value, and use a macro to define it. Then it can be defined as (values) or (if #f #f) or whatever for the various Schemes. I prefer (values) since that cannot harm a REPL, but only when the Scheme won't blow up while using it. I wonder what a good name would be for "no useful value". (void)? --- David A. Wheeler -- DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
