Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?
(Just my two cents, because in my scanning of this thread so far, I don’t *think* I have seen this…) Hmm; there are still languages where function and procedure are two syntactically-different things (and subroutine is a useful “overall" term there so you don’t have to always say “procedure or function”). For example, in PL/SQL, a function is a subroutine that returns a value, and a procedure is a subroutine that does not return a value, and their header syntaxes are distinct accordingly. (And I have wondered whether PL/SQL “inherited” that distinction from Ada, but I’ve never been sure about that.) (Of course, PL/SQL actually has three syntactically-distinct kinds of subroutines, as it also has triggers, which are not explicitly called at all, but get invoked before or after a triggering action, and have their own distinct header syntax accordingly… 8 - ) ) So, since the terms aren’t really synonyms, I would hope that Racket documentation would, over time, converge on using them in an agreed-upon way that goes with the history of those terms. (That is, decide in the community about how terms should work with regard to side-effects, and go from there. But, putting on my curmudgeon hat, by gum, functions return something and procedures don’t! 8 - ) ) — Sharon Tuttle -- Sharon M. Tuttle, Professor Department of Computer Science Humboldt State University, Arcata, CA sharon.tut...@humboldt.edu > On Jan 22, 2019, at 5:49 PM, Anthony Carrico wrote: > > On 1/22/19 6:56 PM, Jon Zeppieri wrote: >>[25 messages] >> >> >> I think Wadler's Law needs an update. > > Long live the internet! > > Op: Should we call them functions or procedures? > A: Functions! > B: Functions! > C: Functions! > D: Functions! > E: But it's a procedural language, and we've called them procedures for > 30 years, so why not call them procedures? > F: Functions don't really exist only procedures! So let's call them > functions! > G: Huh? > H: Wadler's Law > Me: Must... Resist... Being... A... Troll... > > Fail > > -- > Anthony Carrico > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] Scribble examples for languages other than Racket
I was thinking about how to document #lang plisqin, a language I am working
on. I wanted to use the "examples" procedure from scribble/example. But it
looks like when you use the #:lang option, it disables evaluation and
printing of results. (The typesetting works fine though.)
I came up with a workaround, in which I programmatically construct a
racketblock that looks like the standard examples. You can see a working,
single-file prototype here:
https://github.com/default-kramer/plisqin/blob/dev/scribblings/TEMP-scribble-lang-idea.scrbl
Since I control the evaluator, this should allow me to typeset a fragment
of #lang plisqin such as
{where x.Foo > 3}
but evaluate it as
(where (> (Foo x) 3))
which will allow me to print the result. (I might even try to typeset both
syntaxes side-by-side or something.)
Has anyone done something similar?
Does my approach seem reasonable?
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?
On 1/22/19 6:56 PM, Jon Zeppieri wrote: > [25 messages] > > > I think Wadler's Law needs an update. Long live the internet! Op: Should we call them functions or procedures? A: Functions! B: Functions! C: Functions! D: Functions! E: But it's a procedural language, and we've called them procedures for 30 years, so why not call them procedures? F: Functions don't really exist only procedures! So let's call them functions! G: Huh? H: Wadler's Law Me: Must... Resist... Being... A... Troll... Fail -- Anthony Carrico -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?
On 1/22/2019 6:25 PM, Zelphir Kaltstahl wrote: >> I disagree on one more point. It is not necessary to always remember >> the low level character of code running on a machine, if the language >> we are using abstracts it well and guarantees us, that there will not >> be strange effects in all the relevant cases for our programs. > > But a language CAN'T guarantee that there will not be effects - > "strange" or otherwise. Spectre attacks work even against code that > is correct WRT its programming language because languages either are > ignorant of - or are intentionally ignoring - side effects of those > fiddly little machine operations. That is a connection I do not fully understand. Spectre attack is something designed to break the system, or out of previously known bounds of what some code could do. Spectre is a family of related attacks. They are not against the program per se, they are against the *hardware* - the CPU and/or the memory system of the computer. They (ab)use side effects of those fiddly little machine operations that you seem determined to ignore. Modern CPUs provide many information channels that can leak data from running programs if you know how to force them to do so. Spectre attacks do not care what language was used to write the program, and they work against code which is perfectly correct at the language level. There's a lot of very technical information out there, but a pretty good primer on the problem and explanation of the 1st discovered variant is at: https://spectreattack.com/spectre.pdf Can such a thing happen unintentionally, when we write useful / constructive / productive / well meaning programs? I guess theoretically, but very very unlikely? Last I looked there were over 100 known Spectre variants - exploiting various information channels in various and different ways - with researchers announcing one or more new variants each week. I get that there is a chance of something having a strange effect, when the CPU is this kind of buggy (Intel cutting corners, still waiting for my free of charge sent replacement CPU, free from such bugs, being inserted in my machines for me by Intel :D), but that problem is on a lower layer of abstraction. If the language we use is in itself correct, isn't it then up to the lower layers to get things right? Afaik Spectre (or was that Meltdown?) are only possible, because of over optimistic branch prediction stuff (not an expert on such low level details at all, just from what I read online). Couldn't we construct hardware free of such mistakes? Or is there something fundamental, that will not allow that, so that we cannot ever have a language guaranteeing things? You absolutely can construct a CPU that is resistant to Spectre: one such WAS called the 80486 and it was obsolete 25 years ago. Branch prediction is only ONE variant of the problem - there are many others. And Intel is not unique in being vulnerable - Spectre affects chips from nearly every vendor, and in fact, it affects most chips on the market today. Spectre vulnerability can't be designed out without either a radical rethink of CPU architecture (e.g., the Mill, which still is vaporware - https://millcomputing.com) or by returning to the [lack of] performance of designs from decades past. Go poke around in comp.arch - they discuss Spectre rather frequently, and in more detail than you can imagine. George -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?
> > [25 messages] > I think Wadler's Law needs an update. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?
On 1/23/19 12:32 AM, Hendrik Boom wrote: > On Tue, Jan 22, 2019 at 01:52:15AM -0500, George Neuner wrote: > >> I am arguing that, in computing, functions and procedures have no >> significant difference, and that distinguishing them erroneously conflates >> computing with mathematics and thus confuses people. > The distinction I've heard from people that care abut these things and that > seems to make sense are fo divide these subrutines into > > * procedures > * do things, have side effects > * Value-returning procedures > * procedures that happen to return values > * functions > * that return values and have no side effects (or side dependencies?) > > But it hasn't been very practical to make these distinctions in computer > programs, because there is no effective way to distinguish such > functions from value-returning proedures. > > The restriction that functions can use only other functions doesn't > really work because > * Too many things that behave like functions use side-effects > internally while returning values that depend only on their arguments. > * Applied strictly, it rules out memo pads. > > The distinction, if it could be practically enforced, would give > optimisers significant opportunity for program tranformation. > > -- hendrik > I think this is a vocabulary and definitions question. It is very useful to be able to talk about these things and distinguish between them. For example, one could demand a side effect free thing to be able to easily write unit tests later on for that thing. Many parts of a program can consist of side effect free things, before at some point there will be side effects. Might be the only side effects are putting something out on command line and the whole rest is always only depending on arguments and never accessing anything global or outside of the scope. Also side effect free parts can be distinguished in natural language, by the way we talk about them and tested separately and more easily. Someone new to the field will hopefully ask what the differences are and will learn then and then be able to talk precisely about it as well. This is a reason why I personally think making the distinction is useful, even if you cannot have the side effect free stuff all the way through every part of a useful usable program. Communication is an important part, not only writing the code. The definition you gave of the categories of subroutines is what I heard / read / saw as well. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?
On Sun, Jan 20, 2019 at 12:10:13AM -0500, George Neuner wrote: > > As Ellen already mentioned, fixed width integers - although exact values - > have computational properties that are not shared with mathematical > integers. As soon as the computation overflows, all bets are off ... any > number of mathematical invariants may no longer hold. So Algol 68 called the usual integer type "int" instead of "integer". > > The troubles with floating point are caused by the representation, but they > aren't limited by it. FP numbers are not simply "limited precision" > approximations of real numbers, but actually are a fuzzy range that only > contains the "limited precision" approximation, and you don't know where > within that range the actual value lies. > > FP math bears little resemblance to real math: > > * FP numbers are neither associative nor distributive > * even simple invariants like (A+B)-B = A or A+A = 2*A may not hold > * FP numbers don't necessarily have a multiplicative inverse: not all >A have a B= 1/A such that A*B = 1 > * FP numbers are not continuous: e.g., B > 0 doesn't mean A+B > A > > and there is plenty more. The so-called BigFloat implementations don't > change these properties - they simply push them out further away from the > programmer [who still can be bitten by problems]. And that's why I approve of the practice of calling floating point types "float" instead of "real". -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?
On Tue, Jan 22, 2019 at 01:52:15AM -0500, George Neuner wrote: > > I am arguing that, in computing, functions and procedures have no > significant difference, and that distinguishing them erroneously conflates > computing with mathematics and thus confuses people. The distinction I've heard from people that care abut these things and that seems to make sense are fo divide these subrutines into * procedures * do things, have side effects * Value-returning procedures * procedures that happen to return values * functions * that return values and have no side effects (or side dependencies?) But it hasn't been very practical to make these distinctions in computer programs, because there is no effective way to distinguish such functions from value-returning proedures. The restriction that functions can use only other functions doesn't really work because * Too many things that behave like functions use side-effects internally while returning values that depend only on their arguments. * Applied strictly, it rules out memo pads. The distinction, if it could be practically enforced, would give optimisers significant opportunity for program tranformation. -- hendrik -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?
On 1/22/19 11:08 PM, George Neuner wrote: > > On 1/22/2019 2:31 PM, Zelphir Kaltstahl wrote: >> If the terms procedures and functions in computing have no >> significant difference, then why use two terms for the same thing, of >> which one is already used in mathematics, enabling confusion to appear? >> >> This would make a fine argument for not using the word "function" for >> computing at all and keep to using the term "procedure" all the way. > > That's what many older languages did - Fortran and Lisp being notable > exceptions, but they can be forgiven because they were the first > (abstraction able) programming languages, and their early users were > people who knew and understood the difference between computing and > mathematics. > > In the world of syntax design, wholesale use of the term "function" - > *relatively* - is a new thing. Hmmm. In general I have to say, I tend to "vote" for using the terms, that are most precise, even if people do not understand, in hope of making them wonder and maybe ask themselves, why someone would use that term instead of another: "Why are they talking about procedures all the time, instead of functions? Is there a difference?" and then maybe they will find out or ask. Also to not contribute to making people think it is the same as mathematical functions. I think using the term "function" rather hides that and does not inspire thinking about it. For example the recorded SICP lecture also made me more conscious about my usage of the word "function". So did some other FP articles and language tutorials. I ask myself: Shouldn't we strive to understand just as much as people before us, even if that means getting used to using their terminology, since they knew what they were talking about? >> I disagree on one more point. It is not necessary to always remember >> the low level character of code running on a machine, if the language >> we are using abstracts it well and guarantees us, that there will not >> be strange effects in all the relevant cases for our programs. > > But a language CAN'T guarantee that there will not be effects - > "strange" or otherwise. Spectre attacks work even against code that > is correct WRT its programming language because languages either are > ignorant of - or are intentionally ignoring - side effects of those > fiddly little machine operations. That is a connection I do not fully understand. Spectre attack is something designed to break the system, or out of previously known bounds of what some code could do. Can such a thing happen unintentionally, when we write useful / constructive / productive / well meaning programs? I guess theoretically, but very very unlikely? I get that there is a chance of something having a strange effect, when the CPU is this kind of buggy (Intel cutting corners, still waiting for my free of charge sent replacement CPU, free from such bugs, being inserted in my machines for me by Intel :D), but that problem is on a lower layer of abstraction. If the language we use is in itself correct, isn't it then up to the lower layers to get things right? Afaik Spectre (or was that Meltdown?) are only possible, because of over optimistic branch prediction stuff (not an expert on such low level details at all, just from what I read online). Couldn't we construct hardware free of such mistakes? Or is there something fundamental, that will not allow that, so that we cannot ever have a language guaranteeing things? >> What I am relating to is: >> >> > The computer abstraction of "applying a function" can only be >> stretched >> > so far. Those fiddly little "steps" that approximate the function >> can't >> > legitimately be ignored: they consumed time and energy, and [barring >> > bugs] in the end they gave you only an approximation - not an answer >> >> Yes it can only be stretched that far (not infinite resources, >> precision etc.), however, there are many situations, where I think >> the stepwise nature can be legitimately ignored. I would say, if a >> language is well designed and the interpreter / compiler and things >> in between that run it are proven to be correct, I do not see, why we >> should not ignore the stepwise nature of code execution. Why would it >> be useful to look at that, provided our program is sufficiently >> performant and does what we want? Furthermore they often do give me >> an answer. It may not always be the case for numbers, because of >> precision and such things, but think of things like joining together >> some strings, some constructs well defined in the language we use and >> the result of such procedure call would be an answer and not only an >> approximation. >> >> I don't think it's a good idea to conflate the meaning of "function", >> from my current level of experience at least ;) > > The problem is that there are far more situations where the > abstraction leaks (or fails utterly) than there are situations where > the abstraction holds. That's why programming should
Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?
On 1/22/2019 2:31 PM, Zelphir Kaltstahl wrote: If the terms procedures and functions in computing have no significant difference, then why use two terms for the same thing, of which one is already used in mathematics, enabling confusion to appear? This would make a fine argument for not using the word "function" for computing at all and keep to using the term "procedure" all the way. That's what many older languages did - Fortran and Lisp being notable exceptions, but they can be forgiven because they were the first (abstraction able) programming languages, and their early users were people who knew and understood the difference between computing and mathematics. In the world of syntax design, wholesale use of the term "function" - *relatively* - is a new thing. I disagree on one more point. It is not necessary to always remember the low level character of code running on a machine, if the language we are using abstracts it well and guarantees us, that there will not be strange effects in all the relevant cases for our programs. But a language CAN'T guarantee that there will not be effects - "strange" or otherwise. Spectre attacks work even against code that is correct WRT its programming language because languages either are ignorant of - or are intentionally ignoring - side effects of those fiddly little machine operations. What I am relating to is: > The computer abstraction of "applying a function" can only be stretched > so far. Those fiddly little "steps" that approximate the function can't > legitimately be ignored: they consumed time and energy, and [barring > bugs] in the end they gave you only an approximation - not an answer Yes it can only be stretched that far (not infinite resources, precision etc.), however, there are many situations, where I think the stepwise nature can be legitimately ignored. I would say, if a language is well designed and the interpreter / compiler and things in between that run it are proven to be correct, I do not see, why we should not ignore the stepwise nature of code execution. Why would it be useful to look at that, provided our program is sufficiently performant and does what we want? Furthermore they often do give me an answer. It may not always be the case for numbers, because of precision and such things, but think of things like joining together some strings, some constructs well defined in the language we use and the result of such procedure call would be an answer and not only an approximation. I don't think it's a good idea to conflate the meaning of "function", from my current level of experience at least ;) The problem is that there are far more situations where the abstraction leaks (or fails utterly) than there are situations where the abstraction holds. That's why programming should be considered engineering rather than science. [In truth, I think programming is more an art than an engineering discipline, but that's a different discussion.] As you noted, a major problem area is numerics. But it's more of a problem than you realize. The average programmer today has had no math beyond high school, and consequently most uses of floating point are unstable and buggy. There is far too much code that works by happenstance rather than by careful design. In the past, it was true that more programs worked with strings (or symbols) than with numbers, but that no longer is the case. Today, numerically dominated programs vastly outnumber symbolically dominated ones. There are quite a few CS scholars who think the default for safe programming languages should be arbitrary precision, decimal arithmetic. Rational arithmetic in Racket (and Scheme and Lisp) similarly is safe, but the fractional representation is off-putting to many people. Something more like BigFloat would be a more palatable choice for the masses. [1] You may (or not) remember that stock prices used to be quoted using fractions: e.g., $42 ^3 /_8 . When online brokerages allowed the masses to begin trading, stock pricing was changed to be in decimal units because it was found that ordinary people found it too difficult to compare prices expressed as fractions: e.g., is ^3 /_8 greater or less than ^11 /_32 ? [2] The tee shirt saying "5 out of 4 people have a problem with fractions" is, unfortunately, not a joke. YMMV, George -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?
If the terms procedures and functions in computing have no significant difference, then why use two terms for the same thing, of which one is already used in mathematics, enabling confusion to appear? This would make a fine argument for not using the word "function" for computing at all and keep to using the term "procedure" all the way. This is also btw. what I take from the recorded videos of SICP lectures (https://www.youtube.com/watch?v=2Op3QLzMgSY=PL8FE88AA54363BC46). Somewhere in the first lectures Abelson or Sussman state, that a "function" is a term used in mathematics and then he goes over to immediately talking about procedures instead. To me this makes perfect sense and makes a point of distinguishing between the two things, without introducing the word function into our programming or computing vocabulary. I disagree on one more point. It is not necessary to always remember the low level character of code running on a machine, if the language we are using abstracts it well and guarantees us, that there will not be strange effects in all the relevant cases for our programs. What I am relating to is: > The computer abstraction of "applying a function" can only be stretched > so far. Those fiddly little "steps" that approximate the function can't > legitimately be ignored: they consumed time and energy, and [barring > bugs] in the end they gave you only an approximation - not an answer Yes it can only be stretched that far (not infinite resources, precision etc.), however, there are many situations, where I think the stepwise nature can be legitimately ignored. I would say, if a language is well designed and the interpreter / compiler and things in between that run it are proven to be correct, I do not see, why we should not ignore the stepwise nature of code execution. Why would it be useful to look at that, provided our program is sufficiently performant and does what we want? Furthermore they often do give me an answer. It may not always be the case for numbers, because of precision and such things, but think of things like joining together some strings, some constructs well defined in the language we use and the result of such procedure call would be an answer and not only an approximation. I don't think it's a good idea to conflate the meaning of "function", from my current level of experience at least ;) On Tuesday, January 22, 2019 at 6:52:22 AM UTC, gneuner2 wrote: > > > On 1/21/2019 11:52 PM, Anthony Carrico wrote: > > On 1/18/19 6:36 PM, George Neuner wrote: > > > Historically, many computer language designers were mathematicians, > and > > > they deliberately sought to distinguish "computer" functions from > > > "mathematical" functions. > > > > > > It has yet to work completely - witness the legions of newbies every > > > year who don't understand that computer arithmetic differs from the > math > > > they were taught in school. > > > > > > George: Aren't you making my case here? The mathematicians actually have > > the same trouble with their components as we engineers! Stoy says, "a > > careful distinction is vital in the case of functions", admonishing us > > not to "confuse functions with the algorithms representing them." > > Weren't Schemers making this distinction with the word "procedure"? > > You and I may, in fact, agree on the basis - but I don't believe we are > arguing the same things. > > If I understand correctly, you are arguing that computing should > distinguish functions from procedures because functions have a > connection [however tenuous] to mathematics that procedures do not. > > I am arguing that, in computing, functions and procedures have no > significant difference, and that distinguishing them erroneously > conflates computing with mathematics and thus confuses people. > > > You began by saying: > >> However, for practical reasons, the programming community is now > >> placing more emphasis on the distinction between functional and > >> procedural abstraction, so I'm very surprised to see the Racket > >> community rally to eliminate it. Even within the same abstraction > >> mechanism, the two ideas are very useful. > > The problem I see is that the ideas AREN'T separate. > > Somewhere upward in this thread I wrote [not necessarily to you, > Anthony] that mathematical functions simply are, whereas their > corresponding computer "functions" are a series of steps that, at best, > can only approximate the result of the mathematical version. > > There is no "series of steps" distinction between a computer function > and procedure - they both are a series of steps. > > The computer abstraction of "applying a function" can only be stretched > so far. Those fiddly little "steps" that approximate the function can't > legitimately be ignored: they consumed time and energy, and [barring > bugs] in the end they gave you only an approximation - not an answer. > > For computing, "function" vs
Re: [racket-users] Distributed places question
On 1/22/2019 10:36 AM, Matt Jadud wrote: My initial wild guess is that the problem is in the queen. Going by the description it's way overly complicated, with plenty of opportunities for something to get lost. Perhaps. It's not a long driver, as code goes. Length really isn't relevant. Your description hints that it is heavily threaded - proportional to the number of places. Every additional message queue is one more potential bottleneck and spot where something can get lost. Your whole architecture seems overly complicated for what it does. Why is the coordinator (queen) so intimately involved? Why not have the workers process an ID end to end [read the source table, calculate, update the result table]? All the coordinator should do is load balance and ensure that all the IDs actually get processed. FWIW, to make sure that workers don't pull IDs on a duplicate basis, I have one process farming them out. Hence, the worker requests an ID, does the work, and submits the work back to the manager. The manager doles out IDs, and then stores results. I was only suggesting that the workers store their results to the DB directly. The coordinator still can - and for load balancing, should - dole out the work and check to make sure the workers finish and all the IDs are processed. The complexity of returning results to the coordinator and having it write the DB is unnecessary. And what is the DBMS? They're two SQLite tables. The readers should never block readers, to the best of my understanding, and there is only a single writer (to a completely separate DB/table). Ah. Now I understand the single writer approach. You might consider changing to a server DBMS instead. In any case I would work on reducing the complexity of the coordinator. Workers should never need to "request" anything - the coordinator should know whether they currently are busy or idle. And scads of router threads really are not necessary - routers are a convenience, but at a certain point they get in the way more than they help. It's really not difficult [and with lots of channels, I think, often clearer] to handle communications directly with put, get, and sync. I probably would use only a couple of threads: one to distribute work, and one to collect and write results to the database. YMMV, George -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Help on a fuction syntax (beginner)
On 21/01/2019 21:01, Neil Van Dyke wrote: Hi, > > That's an improper end to a list. It means a structure of pairs in > which the CDR (right element) of the last pair is not the null list. > Thanks again for your detailed and pedagogic answer. I have replaced 'cons' by 'list' and it is ok. Best regards, Alain -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[racket-users] How to expand the syntax using the foreign module namespace?
Hello, I am looking for some way to expand syntax (that is, without evaluation, just syntax -> syntax transform) during another macro expansion (main-test.rkt in the following example) using the foreign module namespace (need to use prog and simple-act transformation rules from foreign modules). I've managed to do the syntax expansion and evaluation with the desired namespace, but have a hard time with expansion only. *Expansion and evaluation sample (working):* main-test.rkt #lang racket (require (for-syntax racket/base syntax/parse racket/syntax) (for-syntax "foreign.rkt")) (define-syntax (prog stx) (syntax-parse stx [(_ body ...) (let ((x (parameterize ([current-namespace (module->namespace "foreign.rkt")]) (eval stx #'(begin body ...)) ])) (define-syntax (simple-act stx) (syntax-parse stx [(_ str) #'(writeln str) ])) (prog (simple-act "foo") (simple-act "bar")) --- foreign.rkt #lang racket (require (for-syntax racket/base syntax/parse racket/syntax)) (define-syntax (prog stx) (syntax-parse stx [(_ body ...) #'(begin body ...) ])) (define-syntax (simple-act stx) (syntax-parse stx [(_ str) #'(writeln (format "foreign expansion: ~a" str)) ])) --- *Separate expansion (not working)* *I have tried to do something like that:* main-test.rkt-- #lang racket (require (for-syntax racket/base syntax/parse racket/syntax) (for-syntax "foreign-0.rkt") (for-syntax "foreign-1.rkt")) (define-syntax (prog stx) (syntax-parse stx [(_ body ...) (let* ((expanded-by-foreign (parameterize ([current-namespace (module->namespace "foreign-0.rkt")]) (expand-syntax stx)))* ;; Expect it to expand macros in foreign-0.rkt, resuling syntax object is expanded later* (result-of-evaluation (parameterize ([current-namespace (module->namespace "foreign-1.rkt")]) (eval expanded-by-foreign *;; It should expand with foreign-1.rkt macros and evaluate expanded code* #'(begin body ...)) ])) (define-syntax (simple-act stx) (syntax-parse stx [(_ str) #'(writeln str) ])) (prog (simple-act "foo") (simple-act "bar")) - foreign-0.rkt #lang racket (require (for-syntax racket/base syntax/parse racket/syntax)) (define-syntax (prog stx) (syntax-parse stx [(_ body ...) #'(prog-0 body ...) ])) (define-syntax (simple-act stx) (syntax-parse stx [(_ str) #'(simple-act-0 str) ])) - foreign-1.rkt #lang racket (require (for-syntax racket/base syntax/parse racket/syntax)) (define-syntax (prog-0 stx) (syntax-parse stx [(_ body ...) #'(begin body ...) ])) (define-syntax (simple-act-0 stx) (syntax-parse stx [(_ str) #'(writeln (format "foreign-0 evaluation: ~v" str)) ])) - Got an error: ../../../../../Applications/Racket v7.1/collects/syntax/wrap-modbeg.rkt:46:4: prog: undefined; cannot reference an identifier before its definition I've tried to use a `local-expand` instead of `expand-syntax`, but compilation is running out the memory then (looks like the infinite loop while compilation, but I do not understand how to prevent it). Best regards, Ivan -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Distributed places question
> No kidding? > *cough* My initial wild guess is that the problem is in the queen. Going by the > description it's way overly complicated, with plenty of opportunities > for something to get lost. > Perhaps. It's not a long driver, as code goes. > > Your whole architecture seems overly complicated for what it does. Why > is the coordinator (queen) so intimately involved? Why not have the > workers process an ID end to end [read the source table, calculate, > update the result table]? All the coordinator should do is load balance > and ensure that all the IDs actually get processed. > FWIW, to make sure that workers don't pull IDs on a duplicate basis, I have one process farming them out. Hence, the worker requests an ID, does the work, and submits the work back to the manager. The manager doles out IDs, and then stores results. But, yes, I can look to simplify. Is the *source* table ever being updated outside of your program? > And what is the DBMS? > No. They're two SQLite tables. The readers should never block readers, to the best of my understanding, and there is only a single writer (to a completely separate DB/table). I'm not aware that DP channels can drop messages - they are built on top > of TCP for reliability. The whole idea is that places may be widely > separated and communicating by Internet. > Yep. respond. Instrumenting both sides would be best, but it should be > simple enough for the queen to check that there is 1:1 correspondence > Yep. There are myriad ways a distributed program can screw up. I can't claim > that the Racket place infrastructure is bullet-proof, but it certainly > is well tested. Any bugs are far more likely to be in your code. :-) > I agree. Appreciate having a sounding board. Thank you. Back into the fray. More simplification, more contracts, more logging, and simplify! simplify! simplify! Cheers, Matt -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?
On 1/22/19 6:49 AM, Jos Koot wrote: > "It is often the case that > arbitrary procedures don't compose meaningfully, whereas procedures that > represent functions always compose meaningfully. " > > functions f and g can be composed meaningfully only if the domain of > f is compatible with the co-domain of g. Perfect. -- Anthony Carrico -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Are the terms "function" and "procedure" synonymous in Racket?
You write: > "It is often the case that > arbitrary procedures don't compose meaningfully, whereas procedures that > represent functions always compose meaningfully. " > > functions f and g can be composed meaningfully only if the domain of f is > compatible with the co-domain of g. Jos -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Distributed places question
On 1/21/2019 8:56 PM, Matt Jadud wrote: Hi all, I have too much code for a "minimal working example." Every time I run a distributed places program, I get different results. Sadly, it's complex, and I'm confident there are multiple places I could be missing something. This is all running on a 256-core machine, and my distributed places are all ssh connections to localhost. Each worker spawned gets a unique port. I get non-deterministic results regardless of whether I am running 2 or 64 or 128 places. 1. I have a queen bee process that reads in IDs from a database table. 2. Workers request, via distributed place channel, an ID. 3. The queen (which has a separate router for each worker running in separate threads) sends an ID. This is dequeued from a semaphore-protected queue. 4. The workers do queries based on that ID, some arithmetic calculations, and then send a serializable struct back to the queen (received by the router assigned to that worker). All comms, actually, use serializable structs, and I match on those structs at both ends. 5. The queen uses a channel (local/internal) to send that struct to a thread managing a queue. 6. Because there are multiple writers to that internal channel, a semaphore is used within the processing thread to protect the queue. 7. A final thread picks elements off the queue (protected by the same semaphore), and those structs are written into a database. There is a separate DB for storing the results. There are no contention issues between the table from which data is read during runtime and the DB where data is stored at the end. It's... not the simplest structure. No kidding? My initial wild guess is that the problem is in the queen. Going by the description it's way overly complicated, with plenty of opportunities for something to get lost. Your whole architecture seems overly complicated for what it does. Why is the coordinator (queen) so intimately involved? Why not have the workers process an ID end to end [read the source table, calculate, update the result table]? All the coordinator should do is load balance and ensure that all the IDs actually get processed. That said, the comms between queen/worker are deterministic; from ID fetch to final result, there is no non-determinism. It is a bit of back-and-forth, but unrolled, it is a pipeline pattern. So, between queen and worker, there should be no impediments to communication, and no non-deterministic/branching communications. If I understand channels in Racket correctly, I can have multiple writers to a single channel end, so although there is non-determinism in the routers writing to the queuing thread, they should all be serviced. The queue itself is, therefore, doubly-protected, once by the comms structure, and once by the semaphore: it should not be possible for two threads to ever be in the queue, either to insert or dequeue. The database tables are either for reading or writing: never the two shall meet. Is the *source* table ever being updated outside of your program? And what is the DBMS? 1. If a worker chokes on something, will I ever know? I don't believe I have a logging/error interface set up for the workers. (Besides... if they die, how do they communicate that back over a channel before dying?) If they threw an exception, would I hear about it while I'm watching the queen run? 2. Is it possible for a distributed channel to drop data silently? Should I add logging that lets me trace all of my comms from Q->W and back again? I'm not aware that DP channels can drop messages - they are built on top of TCP for reliability. The whole idea is that places may be widely separated and communicating by Internet. If a remote place crashes, the only way to know is that it doesn't respond. Instrumenting both sides would be best, but it should be simple enough for the queen to check that there is 1:1 correspondence between work assigned and results returned. Of course, that doesn't give any assurance that the results are correct. 3. Should I have a set of logs (for queen and all workers) that let me reconstruct all comms/computations? I can do this, but I was hoping someone would say "X possibly fails in Y way...", and that would provide insight before I do all of that instrumentation work. Ultimately, I think the heart of my questions have to do with the way workers might silently die (if they can), and whether it is possible that distributed channels can silently drop data without my queen process knowing. (The latter would seem like an awfully big thing, and so I sincerely doubt that's the issue.) Those are two big holes in my mental map of how distributed places work, and I've spent enough time cleaning up/refactoring/simplifying things that I thought I would ask the community at this point. There are myriad ways a distributed program can screw up. I can't claim that the Racket place infrastructure is
