| 00:00 | <TabAtkins> | Every type has at least two monoids. |
| 00:00 | <SamB> | anyway, in provers you can usuallly just make the operator a parameter to the "typeclass" |
| 00:00 | <zewt> | a monoid sounds like something you go to the doctor to have removed |
| 00:00 | <SamB> | because dependant typing rocks like that |
| 00:01 | <TabAtkins> | Haskell just gives every object one monoid, and makes you use newtype (iirc?) to cast it into a new one. |
| 00:01 | <SamB> | TabAtkins: yeah |
| 00:01 | <SamB> | so it's not really a good idea to define one for Int or Integer |
| 00:01 | <JonathanNeal> | I get confused calling the same thing a “frame”, ”window”, and “viewport”. Is there one name for that thing when I’m referring to it in CSS? Is it the viewport? |
| 00:01 | <TabAtkins> | Okay, okay, got my terms together again. Any object that can be combined with other objects of the same type to produce a third object of the same type, is a magma. |
| 00:02 | <TabAtkins> | If the combining option is associative, it's a semigroup. If there's an identity element, monoid. Inverses, group. Commutative, abelian group. |
| 00:02 | <SamB> | JonathanNeal: viewport sounds like the thing you want? |
| 00:02 | <TabAtkins> | JonathanNeal: In CSS, "viewport". |
| 00:02 | <TabAtkins> | JonathanNeal: But be careful when talking about SVG, who uses the term to mean something else. :/ |
| 00:03 | <JonathanNeal> | TabAtkins: In SVG, does viewport mean something different than viewbox? |
| 00:03 | <SamB> | TabAtkins: is that a representation of *potential* viewport in SVG, then? |
| 00:03 | <TabAtkins> | Nah, that's what it means. |
| 00:03 | <JonathanNeal> | And in the scenario <div id=“viewport" style=“overflow:scroll”><div id=“something-that-triggers-overflow”> would id=“viewport” also be considered a viewport? |
| 00:03 | <TabAtkins> | SamB: No, SVG just uses "viewport" to mean "the coordinate space generated by an <svg>, or similar element that establishes its own coords". |
| 00:04 | <SamB> | TabAtkins: oh. |
| 00:04 | <SamB> | so they don't actually consider the edges? |
| 00:04 | <TabAtkins> | JonathanNeal: It's unclear how to port those SVG terms to other CSS layout modes, and I don't really want to. ^_^ |
| 00:04 | <TabAtkins> | SamB: What do you mean? |
| 00:04 | <SamB> | using viewport to refer to a coordinate space sounds very confused :-( |
| 00:14 | <SamB> | hmm, I guess sodipodi:namedview is not really standard ;-) |
| 00:15 | <zewt> | http://wtf.spec.whatwg.org |
| 08:02 | <zcorpan_> | you can't tell in javascript if an HTTPS resource is weak/deprecated right? |
| 08:09 | zcorpan_ | wonders if there are bugs with mixed content and document.domain |
| 08:19 | <annevk> | zcorpan_: I don't think that's exposed |
| 08:20 | <zcorpan_> | annevk: ok |
| 08:26 | <annevk> | I was wondering if there was a difference between certificates for public content and intranet content. As in, can we make CORS-less work over HTTPS? Although I guess if you set up HTTPS, adding one more header is easy... |
| 08:32 | <foolip> | annevk: what's the point of "A descendant browsing context's document has a non-empty fullscreen element stack" and why is it not in the fullscreen element ready check? |
| 08:33 | <foolip> | AFAICT, it's not possible for a descendant to a non-empty stack without an iframe in the current document being on the current stack, so... |
| 08:34 | <foolip> | +have |
| 08:49 | <annevk> | foolip: I guess it catches the case where <iframe> has a child |
| 08:50 | <annevk> | foolip: I didn't want to make it part of ready check as to minimize cross-process activity, but I could give up on that |
| 08:53 | <annevk> | I wish Aryeh Gregor was still around to fix bugs in ranges |
| 08:53 | <annevk> | I'm never quite sure what I'm doing when changing that section |
| 09:13 | <foolip> | annevk: how about just checking if there's an ancestor <iframe> and saying no? that wouldn't require any cross-process tinkering |
| 09:13 | <foolip> | and having the child of an iframe go fullscreen doesn't seem useful anyway |
| 09:13 | <annevk> | foolip: only <iframe> can pass fullscreen capabilities through right? |
| 09:14 | <foolip> | right |
| 09:14 | <annevk> | ok |
| 09:17 | <foolip> | although if that weren't the case one could say "element which is a browsing context container" or some such |
| 09:28 | <foolip> | annevk: should I file a bug or do you have a plan? |
| 09:29 | <annevk> | foolip: fixing now |
| 09:30 | <foolip> | annevk is teh awesome! |
| 09:52 | <foolip> | annevk: "The context object" should be <i>element</i> since we're not in requestFullscreen() anymore |
| 09:52 | <annevk> | shit |
| 09:53 | <annevk> | copied that from the previous bullet point which is also wrong |
| 09:53 | <foolip> | oh look, I didn't notice that |
| 09:55 | <annevk> | fixed both |
| 09:55 | <foolip> | confirmed |
| 09:55 | <foolip> | would you mind making "Fullscreen is not supported." a per-element thing? |
| 09:56 | <foolip> | currently Blink has a setting where only <video> elements can go fullscreen in Android WebView |
| 09:57 | <foolip> | if you feel like it, it's supposedly temporary... |
| 09:59 | <annevk> | hmm, discuss on WHATWG if we want to keep that? |
| 09:59 | <annevk> | if that actually remains the case we might want some API to figure out for which elements you can actually use it |
| 10:00 | <foolip> | makes sense |
| 10:01 | <foolip> | if it remains the case for long I'll come back to it |
| 10:01 | <foolip> | now lunch |
| 13:29 | <annevk> | JakeA: can we get a "needs input" label for issues? |
| 13:30 | <annevk> | JakeA: something that indicates it needs input from others before we can proceed? |
| 13:32 | <JakeA> | annevk: added |
| 13:34 | <annevk> | cool |
| 14:48 | <annevk> | I wrote http://annevankesteren.nl/2014/08/asynchronicity so we have a pointer when people are not queuing tasks or some such |
| 14:48 | <annevk> | Suggestions welcome |
| 14:53 | <jorendorff> | Hixie_: is there a way to clone/edit that huge graph you posted? |
| 14:55 | <Domenic> | annevk: related are the two sections starting at https://github.com/w3ctag/promises-guide#note-asynchronous-steps-explicitly |
| 14:55 | <jorendorff> | Hixie_: putting the pipeline in the right order should help |
| 14:56 | <Domenic> | annevk: your post approaches it from a different angle though which is probably more useful as a conceptual intro |
| 14:56 | <Domenic> | annevk: e.g. talking about things in parallel and how that could impact code |
| 14:57 | <annevk> | I guess I can add a pointer for more detailed instructions |
| 14:59 | <annevk> | done |
| 14:59 | <Domenic> | I think I'll add a pointer to yours for more conceptual background :) |
| 16:01 | <annevk> | https://twitter.com/W3CProphet/status/499213295023190017 I wonder what I'm missing |
| 16:03 | <caitp> | ¯\_(ツ)_/¯ |
| 16:36 | <SimonSapin> | Hixie_: http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting.html#selectors "Everything else (attribute values on HTML elements, IDs and classes in no-quirks mode and limited-quirks mode, and element names, attribute names, and attribute values in XML documents)" I don’t understand this. There are two "and", and it seems to leave attribute values on non-HTML elements in HTML documents |
| 16:36 | <SimonSapin> | undefined |
| 16:42 | <TabAtkins> | SimonSapin: Which set of multiple "and"s is confusing you? |
| 16:42 | <SimonSapin> | TabAtkins: in the parentheses I quoted |
| 16:43 | <TabAtkins> | SimonSapin: There are four "and"s there. ^_^ |
| 16:43 | <SimonSapin> | uh, maybe there is implied grouping, but it’s not clear what that should be |
| 16:44 | <TabAtkins> | (attribute values on html elements), (ids and classes) in (no-quirks mode and limited-quirks mode), and (element names, attribute names, and attribute values in XML documents). |
| 16:45 | <SimonSapin> | ((element names, attribute names, and attribute values) in XML documents) or (element names, attribute names, and (attribute values in XML documents)) ? |
| 16:46 | <Ms2ger> | Former |
| 16:46 | <TabAtkins> | Definitely former. |
| 16:48 | <SimonSapin> | ok, so attr values on non-HTML elements in HTML documents is not in "everything else" |
| 16:48 | <Ms2ger> | I'm not sure if the parenthetical is supposed to be exhaustive |
| 16:49 | <SimonSapin> | well |
| 16:49 | <SimonSapin> | in that case it sounds better to remove it entirely |
| 16:52 | <Ms2ger> | Yeah |
| 16:52 | <Ms2ger> | File a bug? |
| 17:01 | <SimonSapin> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=26560 |
| 17:02 | <SimonSapin> | yay bugzilla line breaking |
| 17:06 | <caitp> | didn't they have a gsoc project for making bugzilla support markdown? maybe the kids will improve the linewrapping, too :p |
| 17:08 | <Hixie_> | SimonSapin: generally speaking, parentheticals in prose i write aren't normative |
| 17:08 | <Hixie_> | SimonSapin: or rather, they're intended to be redundant with other text |
| 17:08 | <Hixie_> | SimonSapin: so in this case, since attributes in non-XML elements are already covered by the earlier paragraph, they're not "everything else" |
| 17:09 | <SimonSapin> | Hixie_: the earlier paragraph is about attr names, not values |
| 17:10 | <Hixie_> | "attribute values on HTML elements" is the first thing listed |
| 17:10 | <Hixie_> | in the parenthetical |
| 18:00 | <Hixie_> | jorendorff: looks like i can share it with you? |
| 18:36 | <annevk> | By the way, I reverted these edits: http://wiki.whatwg.org/wiki/Special:Contributions/Ramanjeet.taneja |
| 18:36 | <annevk> | They pointed to a URL that was not really working |
| 19:33 | <kriskowal> | i have not yet begun to lurk |
| 19:38 | <TabAtkins> | kriskowal: By definition, you just *stopped* lurking. |
| 19:39 | <caitp> | does it count as lurking if it's only for 5 minutes? |
| 20:09 | <jorendorff> | Hixie_: yeah, second thoughts -- might be counterproductive since it's for your understanding. |
| 20:14 | <Hixie_> | jorendorff: well you're welcome to a copy you can do whatever you want with :-) |
| 20:28 | <Hixie_> | jorendorff: any idea what CreateLinkedModuleInstance() is supposed to be? |
| 20:28 | <Hixie_> | mentioned in Reflect.Loader.prototype.newModule |
| 20:28 | <Hixie_> | but doesn't appear to be defined anywhere |
| 20:36 | <jorendorff> | Hixie_: not totally sure, because this is another area where allenwb changed some stuff without telling anybody |
| 20:36 | <Hixie_> | k |
| 20:37 | <jorendorff> | Hixie_: but I think what it's supposed to do is create a Module object that doesn't need to be linked with anything |
| 20:38 | <jorendorff> | the point of this loader.newModule() method is to support creating a Module object based on just provided keys and values |
| 20:39 | <Hixie_> | it's interesting that there doesn't seem to be a way to create a Module object directly |
| 20:39 | <Hixie_> | unless i'm missing something |
| 20:39 | <Hixie_> | like, new Module() |
| 20:39 | <jorendorff> | Hixie_: the original proposal offered exactly that and allenwb editorially changed it to loader.newModule |
| 20:40 | <Hixie_> | also, am i missing something or are Modules really very ES-specific? Like, there doesn't seem to be a way for the loader's [[Modules]] to map a name to something that isn't a JS module |
| 20:40 | <Hixie_> | like, an image, or a <link> element, or whatever |
| 20:40 | <jorendorff> | Hixie_: that's correct, and people have complained about it, and the rationale for that is not good imho |
| 20:41 | <jorendorff> | the rationale is, (1) it does true linking so if one module does export var x = 0; export function f() { x++; } then other modules that import x will observe its value changing |
| 20:42 | <jorendorff> | Reading an imported variable is a read from the actual variable (declared in the other module). |
| 20:42 | <jorendorff> | It's fast and you don't make copies of the variables. |
| 20:42 | <Hixie_> | sure, seems obvious that we should keep that |
| 20:42 | <Hixie_> | how does that affect the non-module case? |
| 20:43 | <jorendorff> | oh. well, that's a rationale for having the system "know about" module objects and use its privileged knowledge of their guts to do something that user scripts couldn't do |
| 20:43 | <jorendorff> | but then why not also allow other random objects, just without the magic behavior, i don't know |
| 20:44 | <jorendorff> | there's one more piece of rationale i can quote (without endorsing) which is |
| 20:44 | <jorendorff> | (2) at link time, we throw if you tried to import something and it isn't there |
| 20:44 | <jorendorff> | though, i guess you could *also* do that and still support non-module things in the [[Modules]] cache |
| 20:45 | <Hixie_> | yeah |
| 20:45 | <jorendorff> | but it's certainly nicer with just Modules because the set of names they expose is immutable |
| 20:45 | <Hixie_> | i'm thinking that e.g. style sheets would have a default export that is their <link> element or their StyleSheet object |
| 20:45 | <jorendorff> | i dunno. "nicer" :-P |
| 20:45 | <Hixie_> | and nothing else |
| 20:45 | <TabAtkins> | Hixie_: Their CSSStyleSheet object, please. |
| 20:45 | <Hixie_> | and images would have just their default export, an <img> element |
| 20:45 | <Hixie_> | and so on |
| 20:45 | <Hixie_> | TabAtkins: probably the <link> element in practice |
| 20:46 | <jorendorff> | Hixie_: Modules also aren't exposed until after they're loaded and linked |
| 20:46 | <TabAtkins> | Hixie_: If you're importing from a url that's a stylesheet, we're developing a stylesheet constructor, so there's no need for a <link>. |
| 20:46 | <Hixie_> | jorendorff: they can be (e.g. in the case of circular dependencies) |
| 20:47 | <Hixie_> | jorendorff: i'm actually expecting that we would make <script type=module> just expose the Module off the HTMLScriptElement object |
| 20:47 | <jorendorff> | Hixie_: even in the case of circular dependencies |
| 20:47 | <jorendorff> | Hixie_: they are linked before evaluation starts |
| 20:47 | <Hixie_> | jorendorff: ah |
| 20:47 | <Hixie_> | TabAtkins: how does the ordering work? |
| 20:47 | <jorendorff> | circular dependencies is the only case where a Module is exposed before all its dependencies are evaluated |
| 20:47 | <jorendorff> | so in "normal" cases you can even count on that |
| 20:47 | <TabAtkins> | Hixie_: You'll be able to add a Stylesheet to the document's list of stylesheets. |
| 20:48 | <jorendorff> | Hixie_: but my point was, people are going to want to know the load status of stuff, right? or are they? will that be exposed? |
| 20:48 | <jorendorff> | at least it seems like they can do it now |
| 20:48 | <Hixie_> | TabAtkins: will you be able to make two <link> elements that have one order in the DOM have a different order in the style sheets list? |
| 20:48 | <Hixie_> | jorendorff: yes, that's one reason i assumed we'd expose the Modules pre-linking |
| 20:48 | <TabAtkins> | Possibly, but unsure. It might be that document-created objects have a set order, dunno. |
| 20:49 | <Hixie_> | TabAtkins: i beg of you, please make sure there's only one order, even if both can be mutated somehow :-) |
| 20:49 | <TabAtkins> | Well, we won't have it rearrange the DOM. |
| 20:49 | <TabAtkins> | But, like, FontFaceSet always puts the CSS-created FontFaces first in matching order. |
| 20:49 | <jorendorff> | Hixie_: yeah. we didn't expose any of that. possibly a mistake on our part, but we didn't see prior art for that either. for code, it's maybe not common to want that |
| 20:50 | <Hixie_> | TabAtkins: yeah, not rearranging the dom seems wise (Especially given scoped style sheets deep in the DOM, etc) |
| 21:00 | <Hixie_> | hmmmmm |
| 21:00 | <Hixie_> | i guess "locate" doesn't have to return a URL, huh |
| 21:00 | <Hixie_> | it could just return the Element |
| 21:00 | <Hixie_> | nothing checks that [[Address]] is a string |
| 21:06 | <Hixie_> | jorendorff: is the output of "normalize" exposed anywhere? |
| 21:06 | <Hixie_> | e.g. can you walk the [[Modules]] list? |
| 21:07 | <jorendorff> | Hixie_: yeah, Reflect.Loader.prototype has methods {keys,values,entries} for walking and {get,has,set,delete}. Very Map-like. |
| 21:07 | <Hixie_> | and i guess the Name is exposed in the LoadObjects |
| 21:07 | <Hixie_> | damnit |
| 21:07 | <jorendorff> | Loads aren't exposed ... are they? |
| 21:07 | <Hixie_> | in the hooks |
| 21:07 | <jorendorff> | oh |
| 21:07 | <jorendorff> | yeah |
| 21:07 | <Hixie_> | i can't work out how to make normalize work |
| 21:09 | <jorendorff> | well ... i'm not sure how to make it work either. url syntax is pretty complete, it's not sensible to add to it |
| 21:09 | <jorendorff> | but it's also really annoying to use urls as module names |
| 21:09 | <Hixie_> | we need to support: import "packagefoo.subbar.baz"; import "http://example.com/foo.js";; import "anIDinTheDocument"; |
| 21:09 | <Hixie_> | (where the first one is some magical way of specifying a module that I don't yet understand) |
| 21:09 | <Hixie_> | (the thing you were alluding to yesterday) |
| 21:10 | <jorendorff> | the last one would be: import "#anIDinTheDocument" surely? |
| 21:11 | <Hixie_> | why? |
| 21:11 | <jorendorff> | well, it seems like it unifies the last two things |
| 21:11 | <Hixie_> | then people would think import "foo.html#anID" would work |
| 21:11 | <jorendorff> | i guess they would |
| 21:11 | <Hixie_> | we went down that route with usemap="" |
| 21:11 | <Hixie_> | it led to all kinds of hassles |
| 21:11 | <jorendorff> | ok |
| 21:12 | <Hixie_> | also, side question |
| 21:12 | <Hixie_> | wtf is a ModuleImport?? |
| 21:12 | <jorendorff> | but how do you distinguish an id from a relative url? |
| 21:12 | <Hixie_> | i've no idea how you distinguish anything here. that's my problem. |
| 21:12 | <jorendorff> | k |
| 21:12 | <Hixie_> | (how do you distinguish my.package.name from a url?) |
| 21:13 | <Hixie_> | what does module foo from "foo.js"; mean? |
| 21:13 | <jorendorff> | Hixie_: a ModuleImport creates a global binding like any other import, but its value is the Module object |
| 21:14 | <jorendorff> | rather than some exported value |
| 21:14 | <Hixie_> | so "foo" is now a variable whose value is the Module object? |
| 21:14 | <Hixie_> | instead of the default export? |
| 21:14 | <jorendorff> | yes. |
| 21:14 | <jorendorff> | it also creates a dependency edge like any other import. |
| 21:14 | <Hixie_> | ok, so, first of all, that's wildly confusing syntax for that. but ok. |
| 21:14 | <jorendorff> | the default export (if any) is then foo.default |
| 21:14 | <Hixie_> | what's the use case? |
| 21:15 | <jorendorff> | i dunno, why does python have both `import os` and `from os import system`? |
| 21:15 | <jorendorff> | haskell also has qualified and unqualified imports |
| 21:15 | <Hixie_> | huh |
| 21:15 | <Hixie_> | weird |
| 21:15 | <Hixie_> | seems very weird to have this be called "module" |
| 21:15 | <Hixie_> | doesn't sound like an import at all |
| 21:15 | <jorendorff> | i agree |
| 21:16 | <Hixie_> | sounds more like "hey, this is a module!" |
| 21:16 | <Hixie_> | which i wish we had, but that's another story |
| 21:16 | <jorendorff> | mmhmm |
| 21:16 | <Hixie_> | <script type=module id=a> ... </script> <script type=module> import a; </script> |
| 21:17 | <jorendorff> | Hixie_: there's a certain logic to this but having both this and default exports makes me cringe |
| 21:17 | <Hixie_> | er, import "a" |
| 21:17 | <jorendorff> | (where this = ModuleImport syntax) |
| 21:17 | <Hixie_> | i guess in that example, "locate" should return the actual HTMLScriptElement. |
| 21:17 | <Hixie_> | it's not a string, but nothing seems to check that in practice so we're ok |
| 21:18 | <jorendorff> | right, the not checking in practice is deliberate |
| 21:18 | <Hixie_> | but what should "normalize" return? it can't return a URL... |
| 21:18 | <jorendorff> | that's the same problem as before |
| 21:18 | <Hixie_> | yeah |
| 21:19 | <SamB> | calling it module is indeed insane |
| 21:20 | <Hixie_> | do the people who disagree with us ever hang out on irc? |
| 21:20 | <SamB> | painting yourselves into a corner, you are |
| 21:20 | <Hixie_> | it'd be good to get their perspective :-) |
| 21:20 | <jorendorff> | samth hangs out in moznet #jslang. dherman is occasionally on irc |
| 21:21 | <jorendorff> | samth is in either Central or Eastern time |
| 21:22 | <jorendorff> | i dislike the syntax, I feel like any one human being could design better syntax from scratch |
| 21:22 | <jorendorff> | strong words |
| 21:22 | <jorendorff> | working incrementally i don't know how to improve it, except by deleting features. |
| 21:22 | <Hixie_> | other than using "module" it's mostly fine imho |
| 21:23 | <Hixie_> | oh JS as a whole? |
| 21:23 | <Hixie_> | JS as a whole is a different matter :-) |
| 21:23 | <jorendorff> | the import syntax in particular. |
| 21:23 | <Hixie_> | too late for that though |
| 21:23 | <jorendorff> | quite. |
| 21:23 | <jorendorff> | that's our motto "too late for that though" |
| 21:23 | <SamB> | you really need to burn it with FIRE |
| 21:24 | <Hixie_> | you could do import "foo"; import "foo" as foo; import module "foo" as foo; import "foo" { explicit as foo, exports as bar }; |
| 21:25 | <Hixie_> | (that's all the features, right?) |
| 21:25 | <SamB> | which features? |
| 21:25 | <Hixie_> | of es6 imports |
| 21:25 | <jorendorff> | SamB: https://www.youtube.com/watch?v=aCbfMkh940Q |
| 21:25 | <SamB> | thought you might have meant of Python or Haskell imports |
| 21:26 | <Hixie_> | personally i think "import foo;" is enough, no need to change the name, no need to control what is imported, no need to expose the Module |
| 21:26 | <SamB> | what's the difference between 'import "foo";' and 'import module "foo";' |
| 21:26 | <Hixie_> | but i'm old fashioned ;-) |
| 21:27 | <Hixie_> | SamB: the same as today's import "foo"; vs module foo from "foo"; |
| 21:27 | <SamB> | that syntax is worse than Python's |
| 21:27 | <Hixie_> | mine or the current one? |
| 21:27 | <SamB> | and Python's was grown |
| 21:27 | <SamB> | the "module" one |
| 21:28 | <Hixie_> | well python doesn't have that feature |
| 21:28 | <Hixie_> | as far as i know |
| 21:28 | <SamB> | Python doesn't have a distinction |
| 21:28 | <jorendorff> | python does have that feature; `import os` binds the os module object to os |
| 21:28 | <jorendorff> | what python doesn't have is "default exports" |
| 21:28 | <Hixie_> | ah ok |
| 21:28 | <Hixie_> | my bad |
| 21:28 | <SamB> | jorendorff: isn't that what __all__ is? |
| 21:28 | <jorendorff> | __all__ only affects `from os import *` |
| 21:28 | <SamB> | ah |
| 21:29 | <jorendorff> | keep asking questions i know the answers to, makes me feel helpful |
| 21:29 | <SamB> | hmm |
| 21:29 | <SamB> | then you have Haskell, where there are no exports but the default exports |
| 21:30 | <SamB> | (but some things may not be exported *at all*) |
| 21:31 | <SamB> | but one important commonality between the two languages: all the forms contain the "import" keyword! |
| 21:32 | <SamB> | and, as you know, Haskell uses "module" to introduce the export list |
| 21:33 | <jorendorff> | Haskell's module system seems about on par with the ES6 module system in terms of syntactic beauty |
| 21:33 | <jorendorff> | Haskell doesn't have Module objects |
| 21:33 | <jorendorff> | though it does have `import qualified` in case you just enjoy using dot syntax |
| 21:34 | <SamB> | jorendorff: it's for avoiding clashes |
| 21:34 | <jorendorff> | yeah, there are a ton of modules that export super common Prelude names |
| 21:36 | <Hixie_> | jorendorff: do you know what the wildcard is supposed to do? https://github.com/ModuleLoader/es6-module-loader/blob/master/lib/system.js#L168 |
| 21:36 | <SamB> | so you'll typically "import qualified Data.Map as M" or something, iirc the syntax correctly |
| 21:36 | <jorendorff> | Hixie_: yeah, what this code is trying to do is let you say |
| 21:37 | <jorendorff> | loader.paths = { 'jquery': 'url/to/jquery', 'numerics/*': 'url/to/huge/numerical/package/*'} |
| 21:37 | <SamB> | jorendorff: Haskell at least knows that a construct beginning with "module" should declare a module |
| 21:37 | <jorendorff> | Hixie_: ^ and then |
| 21:38 | <Hixie_> | oh, i see |
| 21:38 | <Hixie_> | so numerics/foo becomes url/to/huge/numerical/package/foo |
| 21:38 | <jorendorff> | yup |
| 21:38 | <Hixie_> | somehow i missed that this was applying to the paths and not to the input to the locate hook |
| 21:38 | <Hixie_> | why is that in locate and not normalize? |
| 21:39 | <Hixie_> | maybe import foo from "#foo"; is the way to go after all |
| 21:39 | <Hixie_> | i don't see any other solution |
| 21:40 | <jorendorff> | the question being answered is "where can i download this module?" and .paths contains those answers |
| 21:40 | <Hixie_> | sure but this means that if someone does import "jquery" and someone else does import "url/to/jquery" they'll end up with two modules |
| 21:41 | <Hixie_> | why would you want that? |
| 21:41 | <SamB> | Hixie_: they'd probably use different mirrors anyway |
| 21:41 | <SamB> | or different versions |
| 21:41 | <SamB> | or something |
| 21:41 | <Hixie_> | these are the same final url |
| 21:42 | <jorendorff> | that's right, everyone should do |import "jquery"| because it's a bad idea to hardcode URLs in code that's going to be shared |
| 21:42 | <SamB> | so ... remind me why jquery doesn't start with 'module "jquery"' |
| 21:43 | <Hixie_> | SamB: because you need the name long before you've obtained the resource |
| 21:44 | <SamB> | well, sure |
| 21:44 | <Hixie_> | SamB: indeed you need the name before you know what resource to obtain |
| 21:44 | <jorendorff> | ES6 modules don't know their names, it's a little weird |
| 21:44 | <SamB> | that doesn't stop ELF modules from having sonames, does it? |
| 21:44 | <Hixie_> | the web is an extremely late-binding environment with extreme latency involved in finding resources |
| 21:44 | <Hixie_> | in this respect it's unlike most other systems |
| 21:45 | <jorendorff> | are .sonames enforced? if you try to link against something and the system can find that file, but the .soname doesn't match, is it an error? |
| 21:45 | <SamB> | it wouldn't be useful for anything except "WTF, you imported this module by the wrong name!" |
| 21:45 | <jorendorff> | well it'd be useful for making it clear to people looking at a JS module that they're looking at a module |
| 21:45 | <jorendorff> | i don't think the name buys you much of anything |
| 21:46 | <SamB> | jorendorff: well, the *linker* would get confused at least |
| 21:46 | <Hixie_> | having module foo { } would let us entirely get rid of type=module which alone would be a huge win imho |
| 21:46 | <SamB> | jorendorff: it could help everyone agree on WHAT name to import it by |
| 21:46 | <Hixie_> | but the es team seems unsold by this idea |
| 21:47 | <jorendorff> | Hixie_: actually i think that is going to happen in es7 |
| 21:47 | <SamB> | hmm, perhaps comparing to elisp libraries would be more apt? I don't know. |
| 21:47 | <Hixie_> | uh |
| 21:47 | <Hixie_> | why are we taking a detour through pain land in the meantime then |
| 21:47 | <zenparsing> | i pushed really hard for lexical modules in es6 |
| 21:50 | <zenparsing> | to no avail obviously |
| 21:50 | <SamB> | why is ECMA even involved |